./0002755000764400076440000000000013555642751010366 5ustar iustyiusty./draft-ietf-iasa2-consolidated-upd-07.txt0000644000764400076440000005301413441535203017615 0ustar iustyiusty IASA2 J. Klensin, Ed. Internet-Draft March 11, 2019 Updates: 2028, 2418, 3005, 3710, 3929, 4633, 6702 (if approved) Intended status: Best Current Practice Expires: September 12, 2019 Consolidated IASA 2.0 Updates of IETF Administrative Terminology draft-ietf-iasa2-consolidated-upd-07 Abstract In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes. 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 https://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 12, 2019. Copyright Notice Copyright (c) 2019 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 Klensin Expires September 12, 2019 [Page 1] Internet-Draft IASA2 Consolidated Updates March 2019 (https://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. Where Appropriate, Replacement of the IETF Executive Director position with the Managing Director, IETF Secretariat . . . . 3 3. Remove the IETF Executive Director as an Option . . . . . . . 4 4. Deprecated Documents . . . . . . . . . . . . . . . . . . . . 4 4.1. Documents Whose Context is Changed by This Specification 4 4.2. General Description of the IETF Adminstrative Model . . . 5 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 A.1. Changes from version -00 (2018-11-15) to -01 . . . . . . 7 A.2. Changes from version -01 (dated 2018-12-06 but posted 2012-12-07) to -02 . . . . . . . . . . . . . . . . 8 A.3. Changes from version -02 (2018-12-07) to -03 . . . . . . 8 A.4. Changes from version -03 (2018-12-12) to -04 . . . . . . 8 A.5. Changes from version -04 (2019-01-17) to -05 . . . . . . 9 A.6. Changes from version -05 (2019-01-31) to -06 . . . . . . 9 A.7. Changes from version -06 (2019-03-06) to -07 . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In 2018, the IETF began the transition to a new administrative structure, and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure [RFC-Struct]. Key IASA 2.0 changes have been specified in a series of documents, including changes to the IETF Trust [RFC-trust-update], the rationale for it [RFC-trust-rationale], a new defining document for the IETF Administration LLC [LLC-Agreement] (informally called the "IETF LLC" or just "the LLC" in places in this document and elsewhere) and adjustments to the procedures for nominations and selections for relevant positions [RFC-7437bis]. Klensin Expires September 12, 2019 [Page 2] Internet-Draft IASA2 Consolidated Updates March 2019 In addition to more substantive changes that are described in those and other documents, the IASA 2.0 structure changes several position titles and organizational relationships that are referenced in other documents. Rather than reissue those documents individually, this document provides a unified update to them. This document updates RFCs 2028, 2418, 3005, 3710, 3929, 4633, and 6702 (citations in context below) to make those terminology and related changes. In addition, with the authorization of the IAB, it requests that the Informational RFC 3716 be made Historic (see Section 4). The sections that follow identify the details of the relevant documents and the required changes. 2. Where Appropriate, Replacement of the IETF Executive Director position with the Managing Director, IETF Secretariat Under the IASA 2.0 structure, most of the responsibilities of the former position of IETF Executive Director been assigned to a new position (or at least title) of Managing Director of the IETF Secretariat. An "Executive Director" title is now associated with different, and largely new, responsibilities as an Officer of the IETF Administration LLC. These changes are described in the description of the new structural arrangements [RFC-Struct]. This document applies that change to the following: o RFC 2028, The Organizations Involved in the IETF Standards Process [RFC2028], Section 3.3. o RFC 2418, IETF Working Group Guidelines and Procedures [RFC2418], Section 1. o RFC 3710, An IESG Charter, Section 2 [RFC3710]. o RFC 3929, Alternative Decision Making Processes for Consensus- Blocked Decisions in the IETF [RFC3929], Sections 4.1.1 and 4.3 (twice). o RFC 4633, Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists [RFC4633], Section 1. o RFC 6702, Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules, Section 5 [RFC6702]. Note that the current description of the Internet Standards Process [RFC2026] does not require an update by this document for this purpose because the reference to the IETF Executive Director in RFC Klensin Expires September 12, 2019 [Page 3] Internet-Draft IASA2 Consolidated Updates March 2019 2026 was replaced by a document that precedes the current effort [RFC3979] and that was, in turn, obsoleted by RFC 8179 [RFC8179]. 3. Remove the IETF Executive Director as an Option In a few cases, it is no longer appropriate for either the Managing Director, IETF Secretariat (former IETF Executive Director position) or the new IETF Executive Director (for the LLC) to perform a particular historical function. The relevant documents are updated to remove the IETF Executive Director from the list of people with specific responsibilities or authority. Those documents will not be updated to use "Managing Director, IETF Secretariat" but, instead, the mention of the position will simply be dropped. This document applies that change to the following: o RFC 3005, IETF Discussion List Charter [RFC3005], section titled "Charter for the IETF Discussion List". This document is modified to remove the authorization for the IETF Executive Director to restrict people from posting, etc. 4. Deprecated Documents [[CREF1: Note to the WG, IESG, and RFC Editor: I hope this section correctly reflects the conclusions of discussions in and with the WG. If it does not, the issues should certainly be identified and fixed. However, details of some of the actions are the responsibility of the RFC Editor and RFC 3716 is an IAB document containing the report of an IAB Advisory Committee. If that text, especially the phrasing of various actions, is not quite right, I hope those involved can sort the language out with the RFC Editor rather than requiring that the WG iterate on the draft. --JcK, editor. RFC Editor: should this paragraph reach you, please remove it.]] 4.1. Documents Whose Context is Changed by This Specification Both of the documents that follow were obsoleted in 2017 by RFC 8179 [RFC8179], which changed mentions of the IETF Executive Director to point to the IETF Secretariat more generally. o RFC 3979 [RFC3979]. o RFC 4879 [RFC4879]. Klensin Expires September 12, 2019 [Page 4] Internet-Draft IASA2 Consolidated Updates March 2019 4.2. General Description of the IETF Adminstrative Model RFC 3716 [RFC3716] is a report of an IAB Advisory Committee that served as a starting point for the work that led to the original IASA structure. That report is an IAB document rather than an IETF one. The IAB approved a proposal to move RFC 3716 to Historic on March 6, 2019. 5. Acknowledgments Brian Carpenter's careful checking and identification of documents that did, and did not, require consideration was essential to the draft in its current form. He also made several other significant contributions. Bob Hinden also gave the document a careful reading and made useful suggestions. In additional to the above, Alissa Cooper, Eliot Lear, Heather Flanagan (the RFC Series Editor), and the current membership to the IAB helped sort out the handing of RFC 3716. 6. Contributors Jason Livingood did the hard work of identifying the documents that required updating and supplied considerable text used in this document. 7. IANA Considerations [[CREF2: RFC Editor: Please remove this section before publication.]] This memo includes no requests to or actions for IANA. 8. Security Considerations The changes specified in this document are matters of terminology and organizational structure derived from documents it references. It should have no effect on Internet security. 9. References 9.1. Normative References [LLC-Agreement] IETF Administration LLC, "Limited Liability Company Agreement of IETF Administration LLC", August 2018, . Klensin Expires September 12, 2019 [Page 5] Internet-Draft IASA2 Consolidated Updates March 2019 [RFC-7437bis] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", 2018, . [RFC-Struct] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", December 2018, . [RFC-trust-rationale] Arkko, J., "Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust", 2018, . [RFC-trust-update] Arkko, J. and T. Hardie, "Update to the Process for Selection of Trustees for the IETF Trust", 2018, . [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, DOI 10.17487/RFC2028, October 1996, . [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, . [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, DOI 10.17487/RFC3005, November 2000, . [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, DOI 10.17487/RFC3710, February 2004, . [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules", RFC 6702, DOI 10.17487/RFC6702, August 2012, . Klensin Expires September 12, 2019 [Page 6] Internet-Draft IASA2 Consolidated Updates March 2019 9.2. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC3716] IAB Advisory Committee, "The IETF in the Large: Administration and Execution", RFC 3716, DOI 10.17487/RFC3716, March 2004, . [RFC3929] Hardie, T., "Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF", RFC 3929, DOI 10.17487/RFC3929, October 2004, . [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", RFC 3979, DOI 10.17487/RFC3979, March 2005, . [RFC4633] Hartman, S., "Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists", RFC 4633, DOI 10.17487/RFC4633, August 2006, . [RFC4879] Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", RFC 4879, DOI 10.17487/RFC4879, April 2007, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, . Appendix A. Change Log RFC Editor: Please remove this appendix before publication. A.1. Changes from version -00 (2018-11-15) to -01 o Removed RFCs 3979 and 4879 from the "obsoletes" list because they had already been obsoleted (by 8179). It also removes RFC 8179 from the "updates" list because 8179 uses "IETF Secretariat" terminology rather than "IETF Executive Director". [[CREF3: Note in Draft: That suggests an idea which might considerably mitigate the name confusion issue: Instead of singling out the Managing Director of the Secretariat as a named Klensin Expires September 12, 2019 [Page 7] Internet-Draft IASA2 Consolidated Updates March 2019 individual, perhaps we should be referring to the Secretariat itself, leaving the contact point or address up to them as an internal administrative matter. Just a thought. --JcK]] o Added text to explain why RFC 2026 is not on the hit list. o Added an acknowledgment to Brian Carpenter. If he catches another batch of errors and supplies text, he gets promoted to Contributor. o Adjusted reference [RFC-Struct] to point to 4071bis. o Minor editorial corrections and changes. A.2. Changes from version -01 (dated 2018-12-06 but posted 2012-12-07) to -02 I accidentally omitted RFC 4844 from the document header "updates" list in Version 01 and noticed that in response to an unrelated question almost immediately after posting. The correction seemed important enough to justify almost immediate re-posting. Changes are only that header, the document file name, and the date. --JcK A.3. Changes from version -02 (2018-12-07) to -03 o Removed discussion and pointers to RFC 7500 - IAB will publish separately. o Added text to describe (very superficially) RFC 3716. That document was obsoleted in the previous version but not described. o Removed rant about titles and responsibilities from Section 2 and a subsequent editorial note I hope it is no longer needed --JcK. In additional, several blocks of text that were commented out in earlier versions of the XML have been removed entirely. A.4. Changes from version -03 (2018-12-12) to -04 o Removed RFC 4844 from the update list and discussion because the consensus in the WG seemed to be that it (and the RFC Editor) should be handled separately. o Removed RFC 5377 from the update list and discussion because it involves the Trust. o Editor's note in draft: Klensin Expires September 12, 2019 [Page 8] Internet-Draft IASA2 Consolidated Updates March 2019 The above changes and the earlier removal of RFC 7500 so the IAB could publish it own document completely eliminate the earlier Sections 2 and 3. That may call for a revision of the Introduction and/or Abstract, but I have not done a review for this iteration of whether such changes are needed. As documents and references are shuffled in and out of this one, it occurred to me that having a non-normative appendix somewhere that would identify all of the documents containing changes to reflect the IASA 1.x to 2.0 transition would be of great help to any future historian trying to understand what we did and probably helpful to the IETF if some of these changes don't work out and/or require further tuning. After a brief discussion, Jason and I concluded that appendix did not belong in this iteration of this document. A.5. Changes from version -04 (2019-01-17) to -05 o Changed title from "Consolidated IASA2-Related Document Updates" to "Consolidated IASA 2.0 Updates of IETF Administrative Terminology" per suggestions from Brian Carpenter and Bob Hinden and 2019-01-31 WG decision. o Removed CREF from Section 1 (should have been done in -04). The only remaining CREFs are the one in this section (above) that should probably be preserved through IETF Last Call and notes to the RFC Editor. o Updated acknowledgments. A.6. Changes from version -05 (2019-01-31) to -06 o Changes to text about documents that are updated and made historic, per advice from RFC Editor, WG Chairs, and IAB. This includes a statement about IAB action of 2019-03-06 that requests that the RFC Editor move RFC 3716 to Historic but does not obsolete that Informational report. When minimal changes were attempted, Section 4 became very hard to read and hence was restructured and somewhat rewritten (and then further modified to work around an xml2rfc glitch). Special attention should be paid to the note at the beginning of that section. o Updated the Acknowledgments section. Klensin Expires September 12, 2019 [Page 9] Internet-Draft IASA2 Consolidated Updates March 2019 A.7. Changes from version -06 (2019-03-06) to -07 o Moved RFCs 3929 and 4633 from "obsoleted" to "updated" and stripped text requested that they be made Historic at the direction of the IETF Chair, WG Co-chair, and an author. o Added a section number for a document listed in Section 2 that was missing. o Added some notes to the RFC Editor and others. o Updated the acknowledgments. Author's Address John C Klensin (editor) 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin Expires September 12, 2019 [Page 10] ./draft-aranda-dispatch-q4s-10.txt0000644000764400076440000054500713507622771016201 0ustar iustyiustyInternet Draft Intended status: Informational J.J. Garcia Aranda Expires: January 2020 Nokia M. Cortes J. Salvachua Univ. Politecnica de Madrid M. Narganes Tecnalia I. Martinez Sarriegui Optiva Media July 5, 2019 The Quality for Service Protocol draft-aranda-dispatch-q4s-10.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, 2020. Copyright Notice Copyright (c) 2018 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 Garcia Aranda Expires January 5, 2020 [Page 1] Internet-Draft The Quality for Services Protocol July 2019 carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo describes an application level protocol for the communication of end-to-end QoS compliance information based on the Hypertext Transfer Protocol (HTTP) and the Session Description Protocol (SDP). The Quality for Service Protocol (Q4S) provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet, and to alert whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this document, it is application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile). This protocol specification is the product of research conducted over a number of years, and is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus. Table of Contents 1 Introduction...................................................5 1.1 Scope....................................................6 1.2 Motivation...............................................7 1.3 Summary of Features......................................8 1.4 Differences with OWAMP/TWAMP.............................9 2 Terminology....................................................9 3 Overview of Operation.........................................10 4 Q4S Messages..................................................21 4.1 Requests................................................21 4.2 Responses...............................................22 4.3 Header Fields...........................................23 4.3.1 Common Q4S Header Fields..........................23 4.3.2 Specific Q4S Request Header Fields................24 4.3.3 Specific Q4S Response Header Fields...............25 4.4 Bodies..................................................26 Garcia Aranda Expires January 5, 2020 [Page 2] Internet-Draft The Quality for Services Protocol July 2019 4.4.1 Encoding..........................................26 5 Q4S Method Definitions........................................26 5.1 BEGIN...................................................27 5.2 READY...................................................27 5.3 PING....................................................27 5.4 BWIDTH..................................................28 5.5 Q4S-ALERT...............................................28 5.6 Q4S-RECOVERY............................................28 5.7 CANCEL..................................................29 6 Response Codes................................................29 6.1 100 Trying..............................................30 6.2 Success 2xx.............................................30 6.2.1 200 OK............................................30 6.3 Redirection 3xx.........................................30 6.4 Request Failure 4xx.....................................30 6.4.1 400 Bad Request...................................30 6.4.2 404 Not Found.....................................30 6.4.3 405 Method Not Allowed............................31 6.4.4 406 Not Acceptable................................31 6.4.5 408 Request Timeout...............................31 6.4.6 413 Request Entity Too Large......................31 6.4.7 414 Request-URI Too Long..........................31 6.4.8 415 Unsupported Media Type........................31 6.4.9 416 Unsupported URI Scheme........................31 6.5 Server Failure 5xx......................................32 6.5.1 500 Server Internal Error.........................32 6.5.2 501 Not Implemented...............................32 6.5.3 503 Service Unavailable...........................32 6.5.4 504 Server Time-out...............................32 6.5.5 505 Version Not Supported.........................32 6.5.6 513 Message Too Large.............................33 6.6 Global Failures 6xx.....................................33 6.6.1 600 session does not exist........................33 6.6.2 601 quality level not allowed.....................33 6.6.3 603 Session not allowed...........................33 6.6.4 604 authorization not allowed.....................33 7 Protocol......................................................33 7.1 Protocol Phases.........................................33 7.2 SDP Structure...........................................35 7.2.1 "qos-level" attribute.............................36 7.2.2 "alerting-mode" attribute.........................37 7.2.3 "alert-pause" attribute...........................37 7.2.4 "recovery-pause" attribute........................37 7.2.5 "public-address" attributes.......................38 7.2.6 "latency" attribute...............................38 7.2.7 "jitter" attribute................................38 7.2.8 "bandwidth" attribute.............................38 7.2.9 "packetloss" attribute............................39 7.2.10 "flow" attributes.................................39 7.2.11 "measurement" attributes..........................40 7.2.12 "max-content-length" attribute....................42 Garcia Aranda Expires January 5, 2020 [Page 3] Internet-Draft The Quality for Services Protocol July 2019 7.3 Measurements............................................42 7.3.1 Latency...........................................42 7.3.2 Jitter............................................43 7.3.3 Bandwidth.........................................43 7.3.4 Packet loss.......................................46 7.4 Handshake Phase.........................................46 7.5 Negotiation Phase.......................................47 7.5.1 Stage 0: Measurement of Latencies and Jitter......49 7.5.2 Stage 1: Measurement of Bandwidth and Packet Loss.52 7.5.3 Quality Constraints Not Reached...................55 7.5.3.1 Actuator Role..................................57 7.5.3.2 Policy Server Role.............................58 7.5.4 QoS Level Changes.................................58 7.6 Continuity Phase........................................59 7.7 Termination Phase.......................................62 7.8 Dynamic Constraints And Flows...........................63 7.9 Qos-level Upgrade And Downgrade Operation...............64 8 General User Agent Behavior...................................66 8.1 Roles in Peer-to-Peer Scenarios.........................66 8.2 Multiple Quality Sessions in Parallel...................67 8.3 General Client bBhavior.................................67 8.3.1 Generating Requests...............................68 8.4 General Server Behavior.................................69 9 Implementation Recommendations................................70 9.1 Default Client Constraints..............................70 9.2 Latency and Jitter Measurements.........................70 9.3 Bandwidth Measurements..................................71 9.4 Packet Loss Measurement Resolution......................72 9.5 Measurements and Reactions..............................72 9.6 Instability Treatments..................................72 9.6.1 Loss of Control Packets...........................73 9.6.2 Outlier Samples...................................73 9.7 Scenarios...............................................73 9.7.1 Client to ACP.....................................74 9.7.2 Client to Client..................................74 10 Security Considerations.......................................74 10.1 Confidentiality Issues..................................74 10.2 Integrity of Measurements and Authentication............75 10.3 Privacy of Measurements.................................75 10.4 Availability Issues.....................................75 10.5 Bandwidth Occupancy Issues..............................75 11 Future Code Point Requirements................................76 11.1 Service Port............................................76 12 References....................................................77 12.1 Normative References....................................77 12.2 Informative References..................................78 13 Acknowledgments...............................................80 14 Contributors..................................................81 15 Authors' Addresses............................................83 Garcia Aranda Expires January 5, 2020 [Page 4] Internet-Draft The Quality for Services Protocol July 2019 1 Introduction The World Wide Web (WWW) is a distributed hypermedia system which has gained widespread acceptance among Internet users. Although WWW browsers support other, preexisting Internet application protocols, the primary protocol used between WWW clients and servers became the HyperText Transfer Protocol (HTTP) (RFC 7230 [1], RFC 7231 [2], RFC 7232 [3], RFC 7233 [4], RFC 7234 [5], and RFC 7235 [6]). Since then, HTTP over TLS (known as HTTPS and described in RFC 2818 [7]) has become an imperative for providing secure and authenticated WWW access. The mechanisms described in this document are equally applicable to HTTP and HTTPS. The ease of use of the Web has prompted its widespread employment as a client/server architecture for many applications. Many of such applications require the client and the server to be able to communicate each other and exchange information with certain quality constraints. Quality in communications at the application level consists of four measurable parameters: o Latency: The time a message takes to travel from source to destination. It may be approximated to RTT/2 (Round trip time), assuming the networks are symmetrical. In this context we will consider the statistical median formula. o Jitter: latency variation. There are some formulas to calculate Jitter, and in this context we will consider the arithmetic mean formula. o Bandwidth: bit rate of communication. To assure quality, a protocol must assure the availability of the bandwidth needed by the application. o Packet loss: The percentage of packet loss is closely related to bandwidth and jitter. Affects bandwidth because a high packet loss implies sometimes retransmissions that also consumes extra bandwidth, other times the retransmissions are not achieved (for example in video streaming over UDP) and the information received is less than the required bandwidth. In terms of jitter, a packet loss sometimes is seen by the destination like a larger time between arrivals, causing a jitter growth. Any other communication parameter such as throughput, is not a network parameter because it depends on protocol window size and other implementation-dependent aspects. Garcia Aranda Expires January 5, 2020 [Page 5] Internet-Draft The Quality for Services Protocol July 2019 The Quality for Service Protocol (Q4S) provides a mechanism for quality monitoring based on an HTTP syntax and the Session Description protocol (SDP) in order to be easily integrated in WWW, but it may be used by any type of application, not only those based on HTTP. Quality requirements may be needed by any type of application that communicates using any kind of protocol, especially those with real-time constraints. Depending on the nature of each application the constraints may be different leading to different parameter thresholds that need to be met. Q4S is an application level Client/Server protocol that continuously measures session quality for a given flow (or set of flows), end-to-end (e2e) and in real-time; raising alerts if quality parameters are below a given pre-negotiated threshold and sending recoveries when quality parameters are restored. Q4S describes when these notifications, alerts and recoveries, need to be sent and the entity receiving them. The actions undertaken by the receiver of the alert are out of scope of the protocol. Q4S is session-independent from the application flows, to minimize the impact on them. To perform the measurements, two control flows are created on both communication paths (forward and reverse directions). This protocol specification is the product of research conducted over a number of years, and is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus. 1.1 Scope The purpose of Q4S is to measure end-to-end network quality in real-time. Q4S does not transport any application data. It means that Q4S is designed to be used jointly with other transport protocols such as Real Time Protocol (RTP)(RFC 3550 [8]), Transmission Control Protocol (TCP) (RFC 793 [16]), Quick UDP Internet Connections (QUIC)[9] , HTTP [1], etc. Some existent transport protocols are focused in real-time media transport and certain connection metrics are available, which is the case of RTP and Real Time Control Protocol (RTCP)[8]. Other protocols such as QUIC provide low connection latencies as well as advanced congestion control. These protocols transport data efficiently and provide lot of functionalities. However, there are currently no other quality measurement protocols offering the same level of function as Q4S. See Section 1.4 for a discussion of the IETF's OWAMP and TWAMP quality measurement protocols. Garcia Aranda Expires January 5, 2020 [Page 6] Internet-Draft The Quality for Services Protocol July 2019 Q4S enable applications to become reactive under e2e network quality changes. To achieve it, an independent Q4S stack application must run in parallel to target application. Then, Q4S metrics may be used to trigger actions on target application such as speed adaptation to latency in multiuser games, bitrate control at streaming services, intelligent commutation of delivery node at Content Delivery Networks, and whatever target application allow. 1.2 Motivation Monitoring quality of service (QoS) in computer networks is useful for several reasons: o Enable real-time services and applications to verify whether network resources achieve a certain QoS level. This helps real-time services and applications to run through the Internet, allowing the existence of Application Content Providers (ACPs) which offer guaranteed real-time services to the final users. o Real-time monitoring allows applications to adapt themselves to network conditions (Application-based QoS) and/or request more network quality to the Internet Service Provider (ISP) (if the ISP offers this possibility). o Monitoring may also be required by Peer to Peer (P2P) real- time applications for which Q4S can be used o Enable ISPs to offer QoS to any ACP or final user application in an accountable way o Enable e2e negotiation of QoS parameters, independently of the ISPs of both endpoints. A protocol to monitor QoS must address the following issues: o Must be ready to be used in conjunction with current standard protocols and applications, without forcing a change on them. o Must have a formal and compact way to specify quality constraints desired by the application to run. o Must have measurement mechanisms avoiding application disruption and minimizing network resources consumption. o Must have specific messages to alert about the violation of quality constraints in different directions (forward and reverse), because network routing may not be symmetrical, and of course, quality constraints may not be symmetrical. Garcia Aranda Expires January 5, 2020 [Page 7] Internet-Draft The Quality for Services Protocol July 2019 o After having alerted about the violation of quality constraints, must have specific messages to inform about recovery of quality constraints in corresponding directions (forward and reverse). o Must protect the data (constrains, measurements, QoS levels demanded from the network) in order to avoid the injection of malicious data in the measurements. 1.3 Summary of Features The Quality for Service Protocol (Q4S) is a message-oriented communication protocol that can be used in conjunction with any other application-level protocol. Q4S is a measurement protocol. Any action taken derived from its measurements are out of scope of the protocol. These actions depend on application provider and may be application-level adaptive reactions, may involve requests to ISP, or whatever application provider decide. The benefits in quality measurements provided by Q4S can be used by any type of application that uses any type of protocol for data transport. It provides a quality monitoring scheme for any communication that takes place between the client and the server, not only for the Q4S communication itself. Q4S does not establish multimedia sessions and it does not transport application data. It monitors the fulfillment of the quality requirements of the communication between the client and the server, and therefore does not impose any restrictions on the type of application, protocol or the type of usage of the monitored quality connection. Some applications may vary their quality requirements dynamically for any given quality parameter. Q4S is able to adapt to the changing application needs modifying the parameter thresholds to the new values and monitoring the network quality according to the new quality constraints. It will raise alerts if the new constraints are violated. Q4S session lifetime is composed of four phases with different purposes: Handshake, Negotiation, Continuity and Termination. Negotiation and Continuity phases perform network parameter measurements as per a negotiated measurement procedure. Different measurement procedures could be used inside Q4S, although one default measurement mechanism is needed for compatibility reasons and is the one defined in this document. Basically, Q4S defines how to transport application quality requirements and measurement results between client and server and providing monitoring and alerting too. Garcia Aranda Expires January 5, 2020 [Page 8] Internet-Draft The Quality for Services Protocol July 2019 Q4S must be executed just before starting a client-server application which needs a quality connection in terms of latency, jitter, bandwidth and/or packet loss. Once client and server have succeeded in establishing communication under quality constraints, the application can start, and Q4S continues measuring and alerting if necessary. The quality parameters can be suggested by the client in the first message of the handshake phase, but it's the server that accepts these parameter values or forces others. The server is in charge of deciding the final values of quality connection. 1.4 Differences with OWAMP/TWAMP OWAMP (RFC 4656) [27] and TWAMP (RFC 5357) [28] are two protocols to measure network quality in terms of RTT, but has a different goal than Q4S. The main difference is the scope: Q4S is designed to assist reactive applications, while OWAMP/TWAMP is designed just to measure network delay. Differences can be summarized in the following points: . OWAMP/TWAMP is not intended for measuring availability of resources (certain Bandwidth availability for example) but only RTT. However, Q4S is intended for measuring required bandwidth, packet-loss, jitter and latency in both directions. Available bandwidth is not measured by Q4S, but required bandwidth for specific application. . OWAMP/TWAMP does not have responsivity control (which defines the speed of protocol reactions under network quality changes), because this protocol is designed to measure network performance, not to assist reactive applications and does not detect the fluctuations of quality in certain time intervals to take reactive actions. However, responsivity control is a key feature of Q4S. . OWAMP/TWAMP is not intended to run in parallel with reactive applications, but Q4S' goal is to run in parallel and assist reactive applications to take decisions based on Q4S ALERT packets which may trigger actions. 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 Garcia Aranda Expires January 5, 2020 [Page 9] Internet-Draft The Quality for Services Protocol July 2019 described in BCP 14 RFC 2119 [11] RFC 8174 [21] when, and only when, they appear in all capitals, as shown here. 3 Overview of Operation This section introduces the basic operation of Q4S using simple examples. This section is of tutorial nature and does not contain any normative statements. The first example shows the basic functions of a Q4S: communication establishment between a client and a server, quality requirement negotiations for the requested application, application start and continuous quality parameter measurements, and finally communication termination. The client triggers the establishment of the communication requesting a specific service or application from the server. This first message must have a special URI (RFC 3986)[12], which may force the use of the Q4S protocol if it is implemented in a standard web browser. This message consists of a Q4S BEGIN method, which can optionally include a proposal for the communication quality requirements in an SDP body. This option gives the client a certain negotiation capacity about quality requirements, but it will be the server who finally decides about the stated requirements. This request is answered by the server with a Q4S 200 OK response letting the client know that it accepts the request. This response message must contain an SDP body with: o The assigned Q4S session id. o The quality constraints required by the requested application. o The measurement procedure to use. o The alerting mode: there are two different scenarios for sending alerts that trigger actions either on the network or in the application when measurements identify violated quality constraints. In both cases, alerts are triggered by the server. o a) Q4S-aware-network scenario: the network is Q4S aware, and reacts by itself to these alerts. In this scenario Q4S ALERT messages are sent by the server to the client, and network elements inspect and process these alert messages. The alerting mode in this scenario is called Q4S-aware-network alerting mode. Garcia Aranda Expires January 5, 2020 [Page 10] Internet-Draft The Quality for Services Protocol July 2019 o b) Reactive scenario: As shown in Figure 1, the network is not Q4S aware. In this scenario alert notifications are sent to a specific node, called an Actuator, which is in charge of taking decisions regarding what actions to trigger: either to change application behavior to adapt it to network conditions and/or invoke a network policy server in order to reconfigure the network and request more quality for application flows. +------+ +-----------+ | App |<----- app flows---------->|Application| |Client| +-----------+ +------+ A | +------+ +------+ +--------+ | Q4S |<----Q4S---->| Q4S |<----->|Actuator| |Client| |Server| +--------+ +------+ +------+ | V +-------------+ |policy server| +-------------+ Figure 1 Reactive scenario o The format of messages exchanged between the server stack and the Actuator, doesn't follow Q4S codification rules, but their format will be implementation dependent. In this way, we will call the messages sent from the server stack to the Actuator "notifications" (e.g., alert notifications), and the messages sent from the Actuator to the server stack in response to notifications "acknowledges" (e.g., alert acknowledges). o alert-pause: The amount of time between consecutive alerts. In the Q4S-aware-network scenario, the server has to wait this period of time between Q4S ALERT messages sent to the client. In the Reactive scenario, the server stack has to wait this period of time between alert notifications sent to the Actuator. Measurements are not stopped in Negotiation or Continuity Phases during this period of time, but no alerts are sent even with violated network quality constraints in order to leave time for network reconfiguration or for application adjustments. Garcia Aranda Expires January 5, 2020 [Page 11] Internet-Draft The Quality for Services Protocol July 2019 o recovery-pause: The amount of time the Q4S server waits before trying to recover the initial qos-level. After having detected violation of quality constraints several times, the qos-level will have been increased accordingly. If this violation detection finally stops, the server waits for a period of time (recovery time) and if the situation persists, it tries to recover to previous qos-level values gradually by sending Q4S RECOVERY messages to the client, in the Q4S- aware-network scenario, or recovery notifications to the Actuator, in the Reactive scenario. It is important to highlight that any Q4S 200 OK response sent by the server to the client at any time during the life of a quality session may contain an SDP body with new values of quality constraints required by the application. Depending on the phase and the state of the measurement procedure within the specific phase, the client will react accordingly so as to take into account the new quality constraints in the measurement procedure. Once the communication has been established (handshake phase is finished), the protocol will verify that the communication path between the client and the server meets the quality constraints on both directions, from and to the server (negotiation phase). This negotiation phase requires taking measurements of the quality parameters: latencies, jitter, bandwidth and packet loss. This phase is initiated with a client message containing a Q4S READY method, which will be answered by the server with a Q4S 200 OK response. Negotiation measurements are achieved in two sequential stages: o Stage 0: latency and jitter measurements o Stage 1: bandwidth and packet loss measurements Stage 0 measurements are being taken through Q4S PING messages sent both from both the client and the server. All Q4S PING requests will be answered by Q4S 200 OK messages to allow for bidirectional measurements. Different client and server implementations may send a different number of PING messages for measuring, although at least 255 messages should be considered to perform the latency measurement. The Stage 0 measurements only may be considered ended when neither client nor server receive new PING messages after an implementation-dependent guard time. Only after, client can send a "READY 1" message. Garcia Aranda Expires January 5, 2020 [Page 12] Internet-Draft The Quality for Services Protocol July 2019 After a pre-agreed number of measurements have been performed, determined by the measurement procedure sent by the server, three scenarios may be possible: a) Measurements do not meet the requirements: in this case the stage 0 is repeated after sending an alert from the server to the client or from the server stack to the Actuator, depending on the alerting mode defined in the Handshake phase. Notice that measurements continue to be taken but no alerts are sent during the alert-pause time. In the Reactive scenario, the Actuator will decide either to forward the alert notification to the network policy server or to the application, depending on where reconfiguration actions have to be taken. b) Measurements do meet the requirements: in this case client moves to stage 1 sending a new READY message. c) At any time during the measurement procedure, the Q4S 200 OK message sent by the server to the client, in response to a Q4S PING message, contains an SDP body with new values of quality constraints required by the application; this means the application has varied their quality requirements dynamically and therefore quality thresholds used while monitoring quality parameters have to be changed to the new constraints. In this case the client moves to the beginning of the Stage 0 for initiating the negotiation measurements again. Stage 1 is optional. Its purpose is to measure the availability of application needed bandwidth. This stage can be skipped by client sending a "READY 2" message after completion of stage 0 when bandwidth requirements is set to cero kbps in the SDP. Stage 1 measurements are achieved through Q4S BWIDTH messages sent both from the client and the server. Unlike PING messages, Q4S BWIDTH requests will not be answered. If Stage 0 and 1 meet the application quality constraints, the application may start. Q4S will enter the continuity phase measuring the network quality parameters through the Q4S PING message exchange on both connection paths, and raising alerts in case of violation. . Once the client wants to terminate the quality session it sends a Q4S CANCEL message, which will be acknowledged by the server with another Q4S CANCEL message. Termination of quality sessions are always initiated by the client because Q4S TCP requests follow the client server schema. Figure 2 depicts the message exchange in a successful scenario. Garcia Aranda Expires January 5, 2020 [Page 13] Internet-Draft The Quality for Services Protocol July 2019 +-------------------------------------------+ | | | Client Server | | | Handshake | --------- Q4S BEGIN -----------> | | <-------- Q4S 200 OK ----------- | | | Negotiation | | (Stage 0) | --------- Q4S READY 0----------> | | <-------- Q4S 200 OK ----------- | | | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | --------- Q4S PING ------------> | | <-------- Q4S PING ------------- | | --------- Q4S 200 OK ----------> | | <-------- Q4S 200 OK ----------- | | ... | Negotiation | | (Stage 1) | --------- Q4S READY 1----------> | | <-------- Q4S 200 OK ----------- | | | | --------- Q4S BWITDH ----------> | | <-------- Q4S BWIDTH------------ | | --------- Q4S BWITDH ----------> | | <-------- Q4S BWIDTH------------ | | ... | Continuity | --------- Q4S READY 2 ---------> | | <-------- Q4S 200 OK ----------- | app start | | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | | Termination | --------- Q4S CANCEL ----------> | app end | <-------- Q4S CANCEL ----------- | | | +-------------------------------------------+ Figure 2 Successful Q4S message exchange. Client and server measurements are included into PING and BWIDTH messages, allowing both sides of the communication to be are aware of all measurements in both directions. Garcia Aranda Expires January 5, 2020 [Page 14] Internet-Draft The Quality for Services Protocol July 2019 The following two examples show the behavior of the Q4S protocol when: quality constraints are violated, alerts are generated; and, later on, violation of quality constraints stops leading to the execution of the recovery process. The first example (Figure 3) shows the Q4S-aware-network alerting mode scenario: Garcia Aranda Expires January 5, 2020 [Page 15] Internet-Draft The Quality for Services Protocol July 2019 +-------------------------------------------+ | | | Client Server | | | Handshake | --------- Q4S BEGIN -----------> | | <-------- Q4S 200 OK ----------- | | | Negotiation | | (Stage 0) | --------- Q4S READY 0----------> | | <-------- Q4S 200 OK ----------- | | | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | ... | | | | <-------- Q4S ALERT ------------ | | -------- Q4S ALERT ------------> | | (alert-pause start) | Repetition | | of Stage 0 | --------- Q4S READY 0----------> | | <-------- Q4S 200 OK ----------- | | | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | ... | Negotiation | | (Stage 1) | --------- Q4S READY 1----------> | | <-------- Q4S 200 OK ----------- | | | | --------- Q4S BWITDH ----------> | | <-------- Q4S BWIDTH------------ | | ... | | | Continuity | --------- Q4S READY 2 ---------> | | <-------- Q4S 200 OK ----------- | app start | | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | ... | |(alert-pause expires & | | violated constraints) | | <-------- Q4S ALERT ------------ | | --------- Q4S ALERT -----------> | | | | (alert-pause start) | Garcia Aranda Expires January 5, 2020 [Page 16] Internet-Draft The Quality for Services Protocol July 2019 | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | --------- Q4S 200 OK ----------> | | ... | |(alert-pause expires & | | violated constraints) | | <-------- Q4S ALERT ------------ | | --------- Q4S ALERT -----------> | | (alert-pause) | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | ... | |(alert-pause expires & | | Fullfilled constraints) | | | | (recovery-pause start) | | | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | ... | |(recovery-pause expires & | | Fullfilled constraints) | | <--------- Q4S RECOVERY --------- | | -------- Q4S RECOVERY -----------> | | | | (recovery-pause start) | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | ... | | | Termination | --------- Q4S CANCEL ----------> | app end | <-------- Q4S CANCEL ----------- | | | +-------------------------------------------+ Figure 3 Q4S-aware-network alerting mode. In this Q4S-aware-network alerting mode scenario, the server may send Q4S alerts to the client at any time on detection of violated quality constraints. This alerting exchange must not interrupt the continuity quality parameter measurements between client and server. Garcia Aranda Expires January 5, 2020 [Page 17] Internet-Draft The Quality for Services Protocol July 2019 The second example depicted in the figure 4 represents the Reactive scenario, in which alert notifications are sent from the server stack to the Actuator which is in charge of deciding either to act over application behavior and/or invoke a network policy server. The Actuator is an entity that has a pre-defined set of different quality levels and decides how to act depending on the actions stated for each of these levels; it can take actions for making adjustments on the application or it can send a request to the policy server for acting on the network. The policy server also has a pre-defined set of different quality levels pre-agreed upon between the Application Content Provider and the ISP. The Reactive alerting mode is the default mode. Garcia Aranda Expires January 5, 2020 [Page 18] Internet-Draft The Quality for Services Protocol July 2019 +-------------------------------------------+ | | | Client Server Actuator | Handshake | ----- Q4S BEGIN -----> | | <---- Q4S 200 OK ----- | | | Negotiation | | (Stage 0) | ----- Q4S READY 0----> | | <---- Q4S 200 OK ----- | | | | ----- Q4S PING ------> | | <---- Q4S 200 OK ----- | | <---- Q4S PING ------- | | ---- Q4S 200 OK ----> | | ... | | (alert-pause start) | | --alert | | notification--> | | | | <--alert | | acknowledge--- | | | Repetition | | of Stage 0 | ----- Q4S READY 0----> | | <---- Q4S 200 OK ----- | | | | ----- Q4S PING ------> | | <---- Q4S 200 OK ----- | | <---- Q4S PING ------- | | ... | |(alert-pause expires & | | violated constraints) | | | | --alert | | notification--> | | | | <--alert | | acknowledge--- | | | | ----- Q4S PING ------> | | <---- Q4S 200 OK ----- | | <---- Q4S PING ------- | | ... | Negotiation | | (Stage 1) | ----- Q4S READY 1----> | | <---- Q4S 200 OK ----- | | | | ----- Q4S BWITDH ----> | | <---- Q4S BWIDTH------ | | ... | Garcia Aranda Expires January 5, 2020 [Page 19] Internet-Draft The Quality for Services Protocol July 2019 Continuity | ----- Q4S READY 2 ---> | | <---- Q4S 200 OK ----- | app start | | |(alert-pause expires & | | fulfilled constraints) | | | |(recovery-pause start) | | ----- Q4S PING ------> | | <---- Q4S 200 OK ----- | | <---- Q4S PING ------- | | ----- Q4S PING ------> | | | |(recovery-pause expires & | | fulfilled constraints) | | | | --recovery | | notification--> | | | | <--recovery | | acknowledge--- | | | |(recovery-pause start) | | <---- Q4S 200 OK ----- | | <---- Q4S PING ------- | | ----- Q4S 200 OK ----> | | ----- Q4S PING ------> | | ... | | | Termination | ----- Q4S CANCEL ----> | app end | --cancel | | notification--> | | | | <--cancel | | acknowledge-- | | <---- Q4S CANCEL ----- | | | +-------------------------------------------+ Figure 4 Reactive alerting mode. At the end of any Negotiation phase stage, the server sends an alert notification to the Actuator if quality constraints are violated. During the period of time defined by the alert-pause parameter, no further alert notifications are sent, but measurements are not interrupted. This way, both the client and the server will detect network improvements as soon as possible. In a similar way, during the continuity phase, the server may send alert notifications at any time to the Actuator on detection of violated quality constraints. This alerting exchange must not interrupt the continuity measurements between client and server. Garcia Aranda Expires January 5, 2020 [Page 20] Internet-Draft The Quality for Services Protocol July 2019 Finally, in the Termination phase, Q4S CANCEL messages sent from the client to the server must be forwarded from the server to the Actuator in order to release possible assigned resources for the session. 4 Q4S Messages Q4S is a text-based protocol and uses the UTF-8 charset (RFC 3629 [19]). A Q4S message is either a request or a response. Both Request and Response messages use the basic format of Internet Message Format (RFC 5322 [20]). Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message- body. The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not. generic-message = start-line CRLF *message-header CRLF CRLF [ message-body ] start-line = Request-Line / Status-Line Much of Q4S's messages and header field syntax are identical to HTTP/1.1. However, Q4S is not an extension of HTTP. 4.1 Requests Q4S requests are distinguished by having a Request-Line for a start-line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character. The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements. Request-Line = Method SP Request-URI SP Q4S-Version CRLF Garcia Aranda Expires January 5, 2020 [Page 21] Internet-Draft The Quality for Services Protocol July 2019 Method: This specification defines seven methods: BEGIN for starting and negotiate quality sessions, READY for synchronization of measurements, PING and BWIDTH for quality measurements purpose, CANCEL for terminating sessions, Q4S-ALERT for quality violations reporting, and Q4S-RECOVERY for quality recovery reporting. Request-URI: The Request-URI is a Q4S URI (RFC 2396) as described in 7.4. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in "<>". Q4S-Version: Both request and response messages include the version of Q4S in use. To be compliant with this specification, applications sending Q4S messages MUST include a Q4S-Version of "Q4S/1.0". The Q4S-Version string is case-insensitive, but implementations MUST send upper- case. Unlike HTTP/1.1, Q4S treats the version number as a literal string. In practice, this should make no difference. 4.2 Responses Q4S responses are distinguished from requests by having a Status- Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character. No CR or LF is allowed except in the final CRLF sequence. Status-Line = Q4S-Version SP Status-Code SP Reason-Phrase CRLF The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase. While this specification suggests specific wording for the reason phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response", any response with a status code between 200 and 299 as a "2xx response", and so on. Q4S/1.0 allows following values for the first digit: Garcia Aranda Expires January 5, 2020 [Page 22] Internet-Draft The Quality for Services Protocol July 2019 1xx: Provisional -- request received, continuing to process the request; 2xx: Success -- the action was successfully received, understood, and accepted; 3xx: Redirection -- further action needs to be taken in order to complete the request; 4xx: Request Failure -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; 6xx: Global Failure -- the request cannot be fulfilled at any server. The status codes are the same described in HTTP (RFC 7231 [2]). In the same way as HTTP, Q4S applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class. The Q4S-ALERT, Q4S-RECOVERY and CANCEL requests do not have to be responded. However, after receiving a Q4S-ALERT, Q4S-RECOVERY or CANCEL request, the server SHOULD send a Q4S-ALERT, Q4S-RECOVERY or CANCEL request to the client 4.3 Header Fields Q4S header fields are identical to HTTP header fields in both syntax and semantics. Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message not matching its category (such as a request header field in a response), it MUST be ignored. 4.3.1 Common Q4S Header Fields These fields may appear in Request and Response messages. Garcia Aranda Expires January 5, 2020 [Page 23] Internet-Draft The Quality for Services Protocol July 2019 o Session-Id: the value for this header is the same session id used in SDP (embedded in "o" SDP parameter) and is assigned by the server. The messages without SDP MUST include this header. If a message has and SDP body, this header is optional. The method of allocation is up to the creating tool, but it is suggested that a UTC timestamp be used to ensure uniqueness. o Sequence-Number: sequential and cyclic positive integer number assigned to PING and BWIDTH messages, and acknowledged in 200 OK responses. o Timestamp: this optional header contains the system time (with the best possible accuracy). It indicates the time in which the PING request was sent. If this header is present in PING messages, then the 200 OK response messages MUST include this value. o Stage: this is used in client's READY requests and server's 200 OK responses during the Negotiation and Continuity phases in order to synchronize the initiation of the measurements. Example: Stage: 0 4.3.2 Specific Q4S Request Header Fields In addition to HTTP header fields, these are the specific Q4S request header fields o User-Agent: this header contains information about the implementation of the user agent. This is for statistical purposes, the tracing of protocol violations, and the automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field MAY contain multiple product tokens and comments identifying the agent and any sub-products which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application. Garcia Aranda Expires January 5, 2020 [Page 24] Internet-Draft The Quality for Services Protocol July 2019 o Signature: this header contains a digital signature that can be used by the network, actuator or policy server to validate the SDP, preventing security attacks. The signature is an optional header generated by the server according to the pre- agreed security policies between the Application Content Provider and the ISP. For example, a hash algorithm and encryption method such as SHA256 (RFC 4634 [14]) and RSA (RFC 8017 [15]) based on the server certificate could be used. This certificate is supposed to be delivered by a Certification Authority (CA) or policy owner to the server. The signature is applied to the SDP body. Signature= RSA ( SHA256 (), ) If the signature is not present, other validation mechanism MAY be implemented in order to provide assured quality with security and control. o Measurements: this header carries the measurements of the quality parameters in PING and BWIDTH requests. The format is: Measurements: "l=" " "|[0..9999] ", j=" " "|[0..9999] ", pl=" " "|[0.00 .. 100.00] ", bw=" " "|[0..999999] Where "l" stands for latency followed by the measured value (in milliseconds)or an empty space, "j" stands for jitter followed by the measured value (in milliseconds) or an empty space, "pl" stands for packetloss followed by the measured value (in percentage with two decimals) or an empty space and "bw" stands for bandwidth followed by the measured value (in kbps) or an empty space. 4.3.3 Specific Q4S Response Header Fields o Expires: its purpose is to provide a sanity check and allow the server to close inactive sessions. If the client does not send a new request before the expiration time, the server MAY close the session. The value MUST be an integer and the measurement units are milliseconds. In order to keep the session open the server MUST send a Q4S alert before the session expiration (Expires header), with the same quality levels and an alert cause of "keep-alive". The purpose of this alert is to avoid TCP sockets (which were opened with READY message) from being closed, specially in NAT scenarios. Garcia Aranda Expires January 5, 2020 [Page 25] Internet-Draft The Quality for Services Protocol July 2019 4.4 Bodies Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted. The interpretation of the body depends on the request method. For response messages, the request method and the response status code determine the type and interpretation of any message body. All responses MAY include a body. The Internet media type of the message body MUST be given by the Content-Type header field. 4.4.1 Encoding The body MUST NOT be compressed. This mechanism is valid for other protocols such as HTTP and SIP (RFC 3261 [22]), but a compression/coding scheme will limit certain logical implementations of the way the request is parsed, thus, making the protocol concept more implementation dependent. In addition, bandwidth calculation may not be valid if compression is used. Therefore, the HTTP request header "Accept-Encoding" cannot be used in Q4S with different values than "identity" and if it is present in a request, the server MUST ignore it. In addition, the response header "Content-Encoding" is optional, but if present, the unique permitted value is "identity". The body length in bytes MUST be provided by the Content-Length header field. The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for Q4S (Note: The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each one with its own size indicator.) 5 Q4S Method Definitions The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case- sensitive. Method = "BEGIN" | "READY" | "PING" | "BWIDTH" | "Q4S-ALERT" | "Q4S-RECOVERY" | "CANCEL" | extension-method extension-method = token The list of methods allowed by a resource can be specified in an "Allow" header field (RFC 7231 [2]). The return code of the response always notifies the client when a method is currently allowed on a resource, since the set of allowed methods can change Garcia Aranda Expires January 5, 2020 [Page 26] Internet-Draft The Quality for Services Protocol July 2019 dynamically. Any server application SHOULD return the status code 405 (Method Not Allowed) if the method is known, but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the server. 5.1 BEGIN The BEGIN method requests information from a resource identified by a Q4S URI. The semantics of this method is the starting of a quality session. This method is only used during the handshake phase to retrieve the SDP containing session id and all quality and operation parameters for the desired application to run. When a BEGIN message is received by the server, any current quality session MUST be cancelled, and a new session should be created. The response to a Q4S BEGIN request is not cacheable. 5.2 READY The READY method is used to synchronize the starting time for sending of PING and BWIDTH messages over UDP between clients and servers. The stage header included in this method is mandatory. This message is only used in negotiation and continuity phases, and only just before making a measurement. Otherwise (out of this context), the server MUST ignore this method. 5.3 PING This message is used during the negotiation and continuity phases to measure the RTT and jitter of a session. The message MUST be sent only over UDP ports. The fundamental difference between the PING and BWIDTH requests is reflected in the different measurements achieved with them. PING is a short message, and MUST be answered in order to measure RTT and jitter, whereas BWIDTH is a long message and MUST NOT be answered. PING is a request method that can be originated by client but also by server. Client MUST also answer the server PING messages, assuming a "server role" for these messages during measurement process. The Measurements header included in this method is mandatory, and provides updated measurements values for latency, jitter and packet loss to the counterpart. Garcia Aranda Expires January 5, 2020 [Page 27] Internet-Draft The Quality for Services Protocol July 2019 5.4 BWIDTH This message is used only during the Negotiation phase to measure the bandwidth and packet loss of a session. The message MUST be sent only over UDP ports. BWIDTH is a request method that can be originated by the client but also by server. Both (client and server) MUST NOT answer BWIDTH messages. The Measurements header included in this method is mandatory and provides updated measurements values for bandwidth and packet loss to the counterpart. 5.5 Q4S-ALERT This is the request message that Q4S generates when the measurements indicate that quality constraints are being violated. It is used during the negotiation and continuity phases. This informative message indicates that the user experience is being degraded and includes the details of the problem (bandwidth, jitter, packet loss measurements). The Q4S-ALERT message does not contain any detail on the actions to be taken, which depends on the agreements between all involved parties. Q4S-ALERT request does not have to be answered with a response message unless there is an error condition, but with an answer formatted as a request Q4S-ALERT message. The response to a Q4S- ALERT request is not cacheable. This method MUST be initiated by the server in both alerting modes. In Q4S-aware-network alerting mode, the Q4S-ALERT messages are fired by the server and sent to the client, advising the network to react by itself. In Reactive alerting mode, alert notifications are triggered by the server stack and sent to the Actuator(see Figure1 "Reactive Scenario"). Client----q4s----SERVER STACK--->ACTUATOR-->APP OR POLICY SERVER The way in which the server stack notifies the Actuator is implementation dependent, and the communication between the Actuator and the network policy server is defined by the protocol and API that the policy server implements. 5.6 Q4S-RECOVERY This is the request message that Q4S generates when the measurements indicate that quality constraints were being violated Garcia Aranda Expires January 5, 2020 [Page 28] Internet-Draft The Quality for Services Protocol July 2019 but they have been fulfilled during a period of time already (recovery pause). It is used during the negotiation and continuity phases. This informative message indicates that the qos-level could be increased gradually until the initial qos-level is recovered (the qos-level established at the beginning os the session of that was decreased during violation of constraints). The Q4S-RECOVERY message does not contain any detail on the actions to be taken, which depends on the agreements between all involved parties. Q4S-RECOVERY request MUST NOT be answered with a response message unless there is an error condition, but with an answer formatted as a request Q4S-RECOVERY message. The response to a Q4S-RECOVERY request is not cacheable. As for the Q4S-ALERT message, the Q4S-RECOVERY method is always initiated by the server in both alerting modes. In Q4S-aware- network alerting mode, the Q4S-RECOVERY messages are fired by the server and sent to the client, advising the network to react by itself. In Reactive alerting mode, recovery notifications are triggered by the server stack and sent to the Actuator(see Figure1 "Reactive Scenario"). 5.7 CANCEL The semantics of CANCEL message is the release of the Q4S session id and the possible resources assigned to the session. This message could be triggered by Q4S stack or by the application using the stack (through an implementation dependent API). In the same way as Q4S-ALERT, CANCEL must not be answered with a response message, but with an answer formatted as a request Q4S- CANCEL message. In the Reactive scenario, the server stack MUST react to the Q4S CANCEL messages received from the client by forwarding a cancel notification to the Actuator, in order to release possible assigned resources for the session (at application or at policy server). The Actuator MUST answer the cancel notification with a cancel acknowledge towards the server stack, acknowledging the reception. 6 Response Codes Q4S response codes are used for TCP and UDP. However, in UDP only the response code 200 is used. Garcia Aranda Expires January 5, 2020 [Page 29] Internet-Draft The Quality for Services Protocol July 2019 The receiver of an unknown response code must take a generic action for the received error group (1XX, 2XX, 3XX, 4XX, 5XX, 6XX). In case of unknown error group, the expected action should be the same as with 6XX error group. 6.1 100 Trying This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this request (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of a Q4S-ALERT during the alert-pause time. 6.2 Success 2xx 2xx responses give information about success of a request. 6.2.1 200 OK The request has succeeded. 6.3 Redirection 3xx 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the request. The requesting client SHOULD retry the request at the new address(es) given by the Location header field. 6.4 Request Failure 4xx 4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate headers or SDP values). However, the same request to a different server might be successful. 6.4.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, "Missing Sequence-Number header field". 6.4.2 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also Garcia Aranda Expires January 5, 2020 [Page 30] Internet-Draft The Quality for Services Protocol July 2019 returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. 6.4.3 405 Method Not Allowed The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the indicated address. 6.4.4 406 Not Acceptable The resource identified by the request is only able of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request. 6.4.5 408 Request Timeout The server could not produce a response within a suitable amount of time, and the client MAY repeat the request without modifications at any later time 6.4.6 413 Request Entity Too Large The server is refusing to process a request because the request entity-body is larger than the one that the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. 6.4.7 414 Request-URI Too Long The server is refusing to process the request because the Request- URI is longer than the one that the server accepts. 6.4.8 415 Unsupported Media Type The server is refusing to process the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. 6.4.9 416 Unsupported URI Scheme The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. Garcia Aranda Expires January 5, 2020 [Page 31] Internet-Draft The Quality for Services Protocol July 2019 6.5 Server Failure 5xx 5xx responses are failure responses given when a server itself is having trouble. 6.5.1 500 Server Internal Error The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds. 6.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when a Server does not recognize the request method and it is not capable of supporting it for any user. Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported. 6.5.3 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response. A client receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable). 6.5.4 504 Server Time-out The server did not receive a timely response from an external server it accessed in attempting to process the request. 6.5.5 505 Version Not Supported The server does not support, or refuses to support, the Q4S protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. Garcia Aranda Expires January 5, 2020 [Page 32] Internet-Draft The Quality for Services Protocol July 2019 In the case that Q4S version is not supported, this error may be sent by the server in handshake phase just after receiving the first BEGIN message from client. 6.5.6 513 Message Too Large The server was unable to process the request since the message length exceeded its capabilities. 6.6 Global Failures 6xx 6xx responses indicate that a server has definitive information about a particular policy not satisfied for processing the request. 6.6.1 600 session does not exist The Session-Id is not valid 6.6.2 601 quality level not allowed The QOS level requested is not allowed for the pair client/server 6.6.3 603 Session not allowed The session is not allowed due to some policy (number of sessions allowed for the server is exceeded, or the time band of the Q4S- ALERT is not allowed for the pair client/server, etc.). 6.6.4 604 authorization not allowed The policy server does not authorize the Q4S-ALERT quality session improvement operation due to an internal or external reason. 7 Protocol This section describes the measurement procedures, the SDP structure of the Q4S messages, the different Q4S protocol phases and the messages exchanged in them. 7.1 Protocol Phases All elements of the IP network contribute to the quality in terms of latency, jitter, bandwidth and packet loss. All these elements have their own quality policies in terms of priorities, traffic mode, etc. and each element has its own way to manage the quality. The purpose of a quality connection is to establish an end-to-end communication with enough quality for the application to function flawlessly. Garcia Aranda Expires January 5, 2020 [Page 33] Internet-Draft The Quality for Services Protocol July 2019 To monitor quality constraints of the application, four phases are defined and can be seen in figure 5: +---------------------------------------------------------------+ | | | | | Handshake ---> Negotiation -+--> Continuity ----> Termination | | A | (app start) | (app end) | | | V A V A | | | violated | violated | | | | constraints | constraints | | | | | | |_______| ____| | | | | | +-------+ | | | | | | | | | +------+ +---------------------+ | | | +---------------------------------------------------------------+ Figure 5 Session lifetime phases. o Handshake phase: in which the server is contacted by the client and in the answer message the quality constraints for the application is communicated embedded in an SDP. o Negotiation phase: in which the quality of the connection is measured in both directions (latency, jitter, bandwidth and packet loss), and Q4S messages may be sent in order to alert if the measured quality does not meet the constraints. This phase is iterative until quality constraints are reached, or the session is cancelled after a number of measurement cycles with consistent violation of the quality constraints. The number of measurement cycles executed depends on the qos- level which is incremented in each cycle until a maximum qos- level value is reached. Just after reaching the quality requirements, Q4S provides a simple optional mechanism using HTTP to start the application. o Continuity phase: in which quality is continuously measured. In this phase the measurements MUST avoid disturbing the application by consuming network resources. If quality constraints are not met, the server stack will notify the Actuator with an alert notification. If later the quality improves, the server stack will notify the Actuator, in this case with a recovery notification. After several alert notifications with no quality improvements, the Q4S stack SHOULD move to Termination phase. o Termination phase: in which the Q4S session is terminated. The application may be closed too or may not start. Garcia Aranda Expires January 5, 2020 [Page 34] Internet-Draft The Quality for Services Protocol July 2019 7.2 SDP Structure The original goal of SDP was to announce necessary information for the participants and multicast MBONE (Multicast Backbone) applications. Right now, its use has been extended to the announcement and the negotiation of multimedia sessions. The purpose of Q4S is not to establish media stream sessions, but to monitor a quality connection. This connection may be later used to establish any type of session including media sessions; Q4S does not impose any conditions on the type of communication requiring quality parameters. SDP will be used by Q4S to exchange quality constraints and will therefore always have all the media attributes ("m") set to zero. The SDP embedded in the messages is the container of the quality parameters. As these may vary depending on the direction of the communication (to and from the client) all quality parameters need to specify the uplink and downlink values: / . When one or both of these values are empty, it MUST be understood as needing no constraint on that parameter and/or that direction. The uplink direction MUST be considered as being the communication from the client to the server. The downlink direction MUST be considered as being the communication from the server to the client. The SDP information can comprise all or some of the following parameters shown in the example below. This is an example of an SDP message used by Q4S included in the 200 OK response to a Q4S BEGIN request. Garcia Aranda Expires January 5, 2020 [Page 35] Internet-Draft The Quality for Services Protocol July 2019 v=0 o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 s=Q4S i=Q4S parameters t=0 0 a=qos-level:0/0 a=alerting-mode:Reactive a=alert-pause:5000 a=public-address:client IP4 198.51.100.51 a=public-address:server IP4 198.51.100.58 a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) a=latency:40 a=jitter:10/10 a=bandwidth:20/6000 a=packetloss:0.50/0.50 a=flow:app clientListeningPort TCP/10000-20000 a=flow:app clientListeningPort UDP/15000-18000 a=flow:app serverListeningPort TCP/56000 a=flow:app serverListeningPort UDP/56000 a=flow:q4s clientListeningPort UDP/55000 a=flow:q4s clientListeningPort TCP/55001 a=flow:q4s serverListeningPort UDP/56000 a=flow:q4s serverListeningPort TCP/56001 As quality constraints may be changed by applications at any time during the Q4S session lifetime, any Q4S 200 OK response sent by the server to the client in the Negotiation and Continuity phases could also include an SDP body with the new quality requirements stated by the applications from then on. Therefore, in response to any PING request sent by the client to the server, the server could send a Q4S 200 OK with an SDP message embedded that specifies new quality constraints requested by the application. 7.2.1 "qos-level" attribute The "qos-level" attribute contains the QoS level for uplink and downlink. Default values are 0 for both directions. The meaning of each level is out of scope of Q4S, but a higher level SHOULD correspond to a better service quality. Appropriate attribute values: [0..9] "/" [0..9] The "qos-level" attribute may be changed during the session lifetime raising or lowering the value as necessary following the network measurements and the application needs. Garcia Aranda Expires January 5, 2020 [Page 36] Internet-Draft The Quality for Services Protocol July 2019 7.2.2 "alerting-mode" attribute The "alerting-mode" attribute specifies the player in charge of triggering Q4S alerts in case of constraint violation. There are two possible values: Appropriate attribute values: <"Q4S-aware-network"|"Reactive"> a) Q4S-aware-network: Q4S ALERT messages are triggered by the server to the client. In this case the network is supposed to be Q4S aware, and reacts by itself to these alerts. b) Reactive: alert notifications are sent by the server stack to the Actuator. In this case the network is not Q4S aware and a specific node (Actuator) is in charge of triggering tuning mechanisms., either on the network or in the application. The "alerting-mode" attribute is optional and if not present Reactive alerting mode is assumed. 7.2.3 "alert-pause" attribute In the Q4S-aware-network scenario, the "alert-pause" attribute specifies the amount of time (in milliseconds) the server waits between consecutive Q4S ALERT messages sent to the client. In the Reactive scenario, the "alert-pause" attribute specifies the amount of time (in milliseconds) the server stack waits between consecutive alert notifications sent to the Actuator. Measurements are not stopped in Negotiation or Continuity Phases during this period of time, but no Q4S ALERT messages or alert notifications are fired, even with violated quality constraints, allowing either network reconfigurations or application adjustments. Appropriate attribute values: [0..60000] 7.2.4 "recovery-pause" attribute In the Q4S-aware-network scenario, the "recovery-pause" attribute specifies the amount of time (in milliseconds) the server waits for initiating the qos-level recovery process. Once the recovery process has started, the "recovery-pause" attribute also states the amount of time (in milliseconds) between consecutive Q4S- RECOVERY messages sent by the server to the client (in the Q4S- aware-network scenario), or between recovery notifications sent by the server stack to the Actuator (in the Reactive scenario). Garcia Aranda Expires January 5, 2020 [Page 37] Internet-Draft The Quality for Services Protocol July 2019 Appropriate attribute values: [0..60000] 7.2.5 "public-address" attributes This attribute contains the public IP address of the client and the server. The server fills these attributes with his own public IP address and the public IP address of the first message received from the client in the handshake phase. The purpose of these attributes is to make available the addressing information to network policy server or other external entities in charge of processing Q4S-ALERT messages. Appropriate attribute values:<"client"|"server"><"IP4"|"IP6"> 7.2.6 "latency" attribute The maximum latency (considered equal for uplink and downlink) tolerance are specified in the "latency" attribute, expressed in milliseconds. In the Q4S-aware-network scenario, if the latency constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, if the latency constraints are not met, an alert notification will be sent to the Actuator. If the "latency" attribute is not present or has a 0 value, no latency constraints need to be met and no measurements MAY be taken. Appropriate attribute values: [0..9999] 7.2.7 "jitter" attribute The maximum uplink and downlink jitter tolerance are specified in the "jitter" attribute, expressed in milliseconds. In the Q4S- aware-network scenario, if the jitter constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, if the latency constraints are not met, an alert notification will be sent to the Actuator. If "jitter" attribute is not present or has a 0 value, no jitter constraints need to be met and no measurements MAY be taken. Appropriate attribute values: [0..9999] "/" [0..9999] 7.2.8 "bandwidth" attribute The minimum uplink and downlink bandwidth are specified in the "bandwidth" attribute, expressed in kbps. In the Q4S-aware-network Garcia Aranda Expires January 5, 2020 [Page 38] Internet-Draft The Quality for Services Protocol July 2019 scenario, if the bandwidth constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, an alert notification will be sent to the Actuator. If "bandwidth" attribute is not present or has a 0 value, no bandwidth constraints need to be met and no measurements MAY be taken. Appropriate attribute values: [0..99999] "/" [0..99999] 7.2.9 "packetloss" attribute The maximum uplink and downlink packet loss tolerance are specified in the "packetloss" attribute expressed in percentage (two decimal accuracy). In the Q4S-aware-network scenario, if the packetloss constraints are not met, a Q4S-ALERT method will be sent to the client. In the Reactive scenario, an alert notification will be sent to the Actuator. If "packetloss" attribute is not present or has a 0 value, no packetloss constraints need to be met and no measurements MAY be taken. Appropriate attribute values: [0.00 ..100.00] "/"[0.00 ..100.00] 7.2.10 "flow" attributes These attributes specify the flows (protocol, destination IP/ports) of data over TCP and UDP ports to be used in uplink and downlink communications. Several "flow" attributes can be defined. These flows identify the listening port (client or server), the protocol (TCP or UDP) (RFC 793 [16] and RFC 768 [17]) with the range of ports that are going to be used by the application and, of course, by the Q4S protocol (for quality measurements). All defined flows (app and q4s) will be considered within the same quality profile, which is determined by the qos-level attribute in each direction. This allows to assume that measurements on q4s flows are the same experimented by the application which is using app flows. During negotiation and continuity phases the specified Q4S ports in the "flow:q4s" attributes of SDP will be used for Q4S messages. The Q4S flows comprise two UDP flows and two TCP flows (one uplink and one downlink for each one) whereas application traffic MAY consist of many flows, depending on its nature. The handshake phase takes place through the Q4S Contact URI, using the standard Q4S TCP port. However, the negotiation and continuity phases will take place on the specified Q4S ports (UDP and TCP) specified in the SDP. Garcia Aranda Expires January 5, 2020 [Page 39] Internet-Draft The Quality for Services Protocol July 2019 The "clientListeningPort" is a port in which the client listens for server requests and MUST be used as origin port of client responses. The "serverListeningPort" is a port in which server is listening for incoming messages from the client. The origin port of server responses may be different than "serverListeningPort" value. If "clientListeningPort" is zero (a=flow:q4s clientListeningPort TCP/0), the client MAY choose one randomly as per OS standard rules. Client ports inside the SDP must always be matched against actual received port values on the server side in order to deal with NAT/NATP devices. If zero value or incorrect value is present, server must set the value to the received origin port in the next message with SDP (200 OK, ALERT and CANCEL messages). Attribute values: <"q4s"|"app"> <"serverListeningPort"|"clientListeningPort"> <"UDP"|"TCP"> <0..65535>[ "-" [0..65535]] 7.2.11 "measurement" attributes These attributes contain the measurement procedure and the results of the quality measurements. Measurement parameters are included using the session attribute "measurement". The first measurement parameter is the procedure. Q4S provides a "default" procedure for measurements, but others like RTP/RTCP might be used and defined later. This document will only define and explain the "default" procedure. In the initial client request a set of measurement procedures can be sent to the server for negotiation. One measurement procedure line MUST be included in the SDP message for each proposed method. The server MUST answer with only one line with the chosen procedure. For each procedure, a set of values of parameters separated by "," can be included in the same attribute line. The amount and type of parameters depends on the procedure type. In the following example the "default" procedure type is chosen: a=measurement:procedure default(50/50,75/75,5000,40/80,100/256) In the "default" procedure, the meaning of these parameters is: Garcia Aranda Expires January 5, 2020 [Page 40] Internet-Draft The Quality for Services Protocol July 2019 o The first parameter is the interval of time (in milliseconds) between PING requests during the negotiation phase. Uplink and downlink values from the client's point of view are separated by "/". This allows having different responsiveness values depending on the control resources used in each direction. o The second parameter is the time interval (in milliseconds) between PING requests during the continuity phase. Uplink and downlink values are separated by "/". This allows having two different responsiveness values depending on the control resources used in each direction. o The third parameter is the time interval to be used to measure bandwidth during the negotiation phase. o The fourth parameter indicates the window size for jitter and latency calculations. Uplink and downlink values are separated by "/". o The fifth parameter indicates the window size for packet loss calculations. Uplink and downlink values are separated by "/". There are four more measurement attributes: a=measurement:latency 45 a=measurement:jitter 3/12 a=measurement:bandwidth 200/9800 a=measurement:packetloss 0.00/1.00 The latency, jitter, bandwidth and packet-loss measurement attributes contain the values measured for each of these quality parameters in uplink and downlink directions. Notice that latency is considered equal for uplink and downlink directions. Quality parameter values in these measurement attributes provide a snapshot of the quality reached and MUST only be included in Q4S- ALERT messages in the SDP body such that they can be protected from malicious attacks as these alerts include a signature of the SDP body in the header. The rest of messages will include the measured values in the Measurements header. In the case of procedure "default", the valid values are: a=measurement:procedure default,[0..999]"/" [0..999] "," [0..999] "/" [0..999] "," [0..9999] "," [0..999]/[0..999] "," [0..999]/[0..999] Garcia Aranda Expires January 5, 2020 [Page 41] Internet-Draft The Quality for Services Protocol July 2019 7.2.12 "max-content-length" attribute The adaptation of measurement traffic to approximate the actual data streams' characteristics is convenient to accurately estimate the expected QoS for applications. Particularly, packet size can have a remarkable effect on bandwidth estimations. Moreover, this can produce problems depending on the MTU of the end hosts and links along the path. Therefore, the maximum content length MAY be set in an attribute denoted as "max-content-length". Its value MUST be given in bytes and MUST NOT include application, transport, network or link layer headers, i.e., size of the content length at the application layer. If not set, the value MUST be 1000 bytes. Furthermore, this attribute MAY be used to inform about MTU limits in end points, hence reducing possible bias as a result of network-layer fragmentation. For instance: a=max-content-length:1300 7.3 Measurements This section describes the way quality parameters are measured as defined by the "default" procedure. Measurements MUST be taken for any quality parameter with constraints, that is, specified in the SDP attributes with non-zero values. For non-present attributes measurements MAY be omitted. 7.3.1 Latency Latency measurements will be performed if the latency attribute and/or the application latency attribute are present and with non- zero values. Q4S defines a PING method in order to exchange packets between the client and the server. Based on this PING exchange the client and the server are able to calculate the round-trip time (RTT). The RTT is the sum of downlink latency (normally named "reverse latency") and uplink latency (normally named "forward latency"). At least 255 samples of RTT MUST be taken by the client and server. As the forward and reverse latencies are impossible to measure, client and server will assume that both latencies are identical (symmetric network assumption). The latency will therefore be calculated as the statistical median value of all the RTT samples divided by 2. Garcia Aranda Expires January 5, 2020 [Page 42] Internet-Draft The Quality for Services Protocol July 2019 7.3.2 Jitter Jitter measurements will be performed if the jitter attribute and/or the application jitter attribute are present and with non- zero values. The jitter can be calculated independently by the client and by the server. The downlink jitter is calculated by the client taking into account the time interval between PING requests as defined by the measurement procedure attribute in the first or second parameter depending on the Q4S protocol phase. The client and the server MUST send these PING requests at the specified intervals. The client measures the downlink jitter whereas the server measures the uplink jitter. Note that PING responses are not taken into account when calculating jitter values. Every time a PING request message is received by an endpoint (either server or client), the corresponding jitter value is updated using the Statistical Jitter value calculated on the first 255 packets received using the arithmetic mean of the absolute values of elapsed times. Each endpoint sends a PING periodically with a fixed interval, each value of "elapsed time" (ET) should be very close to this interval. If a PING message is lost, the elapsed time value is doubled. Identifying lost PING messages, however, is not an issue because all PING messages are labeled with a Sequence-Number header. Therefore the receiver can discard this elapsed time value. In order to have the first jitter sample, the receiver MUST wait until it receives 3 PING requests, because each ET is the time between two PINGs and a Jitter needs at least two ET. The client measures the values of RTT and downlink jitter and the server measures RTT and uplink jitter, but all measurements are shared with the counterpart by means of "Measurements" header of PING message. 7.3.3 Bandwidth Bandwidth measurements will be performed if the bandwidth attribute and/or the application bandwidth attribute is present and with non-zero values. In order to measure the available bandwidth, both the client and the server MUST start sending BWIDTH messages simultaneously using the UDP control ports exchanged during the handshake phase in the SDP message, at the needed rate to verify the availability of the Garcia Aranda Expires January 5, 2020 [Page 43] Internet-Draft The Quality for Services Protocol July 2019 bandwidth constraint in each direction. The messages are sent during the period of time defined in the third parameter of the SDP measurement default procedure attribute in millisecond units. a=measurement:procedure default(50/50,75/75,5000,256/256,256/256) +------------------------------------------------+ | Rate | | A | | | | |downlink rate-|-------------------+ <-- traffic | | | | sent by | | | | server | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | uplink rate-|-------------------+ <-- traffic | | | | sent by | | | | client | | | | | | | | | | |---|---|---|---|---|----> time | | 0 1 2 3 4 5 (sec.) | | | +------------------------------------------------+ Figure 6 Bandwidth and packet loss measurements. The goal of these measurements is not to identify the available bandwidth of the communication path but to determine if the required bandwidth is available, meeting the application's constraints. Therefore, the requested bandwidth MUST be measured sending only the highest bit rate required by the bandwidth attribute. This is illustrated in Figure 6. During bandwidth measurement time, ALERTS are not expected, but only at the end of the measurement time. Garcia Aranda Expires January 5, 2020 [Page 44] Internet-Draft The Quality for Services Protocol July 2019 When measuring bandwidth, all BWIDTH requests sent MUST be 1 kilobyte in length (UDP payload length by default), and MUST include a Sequence-Number header with a sequential number starting at 0, and their content MUST consist of randomly generated values to minimize the effect of compression elements along the path. The Sequence-Number MUST be incremented by 1 with each BWIDTH packet sent. If any measurement stage needs to be repeated, the sequence number MUST start at zero again. BWIDTH requests MUST NOT be answered. Examples: Client message: ========================= BWIDTH q4s://www.example.com Q4S/1.0 User-Agent: q4s-ua-experimental-1.0 Session-Id: 53655765 Sequence-Number: 0 Content-Type: text Content-Length: XXXX Measurements: l=22, j=10, pl=0.00, bw=3000 VkZaU1FrNVZNVlZSV0doT1ZrZ (to complete up to "max-content- length" bytes UDP payload length) ========================= The client MUST send BWIDTH packets to the server to allow the server to measure the uplink bandwidth. The server MUST send BWIDTH packets to the client to allow the client to measure the downlink bandwidth. Server message: ========================= BWIDTH q4s://www.example.com Q4S/1.0 Session-Id: 53655765 Sequence-Number: 0 Content-Type: text Content-Length: XXXX Measurements: l=22, j=7, pl=0.00, bw=200 ZY0VaT1ZURlZVVmhyUFE9PQ (to complete up to max-content- length UDP payload length) ========================= Garcia Aranda Expires January 5, 2020 [Page 45] Internet-Draft The Quality for Services Protocol July 2019 7.3.4 Packet loss Packet loss and bandwidth are measured simultaneously using the BWIDTH packets sent by both the client and the server. Because the BWIDTH packets contain a Sequence-Number header incremented sequentially with each sent packet, lost packets can be easily identified. The lost packets MUST be counted during the measurement time. 7.4 Handshake Phase The first phase consists of a Q4S BEGIN method issued from the client to the server as shown in Figure 7. The first Q4S message MUST have a special URI (RFC 3986 [12]), which forces the use of the Q4S protocol if it is implemented in a standard web browser. This URI, named "Contact URI", is used to request the start of a session. Its scheme MUST be: "q4s:" "//" host [":" port] [path["?" query] Optionally, the client can send the desired quality parameters enclosed in the body of the message as an SDP document. The server MAY take them into account when building the answer message with the final values in the SDP body, following a request / response schema (RFC 3264 [13]). If the request is accepted, the server MUST answer it with a Q4S 200 OK message, which MUST contain an SDP body (RFC 4566 [10]) with the assigned session id (embedded in the "o" SDP parameter), the IP addresses to be used, the flow ports to be used, the measurement procedure to be followed and information about the required quality constraints. Additionally, the alerting-mode and alert-pause time parameters may be included. Q4S responses should use the protocol designator "Q4S/1.0". After these two messages are exchanged, the first phase is completed. The quality parameter thresholds have been sent to the client. The next step is to measure the actual quality of the communication path between the client and the server and alert if the Service Level Agreement (SLA) is being violated. Garcia Aranda Expires January 5, 2020 [Page 46] Internet-Draft The Quality for Services Protocol July 2019 +------------------------------------------------+ | | | Client Server | | | | ------- Q4S BEGIN ------------> | | | | <------ Q4S 200 OK ------------ | | | | | +------------------------------------------------+ Figure 7 Handshake phase. Example of Client Request and Server Answer: Client Request: ========================= BEGIN q4s://www.example.com Q4S/1.0 Content-Type: application/sdp User-Agent: q4s-ua-experimental-1.0 Content-Length: 142 (SDP not shown) ========================= Server Answer: ========================= Q4S/1.0 200 OK Date: Mon, 10 Jun 2010 10:00:01 GMT Content-Type: application/sdp Expires: 3000 Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 Content-Length: 131 (SDP not shown) ========================= The headers used are explained in section 4.3. 7.5 Negotiation Phase The negotiation phase is in charge of measuring the quality parameters and verifying that the communication paths meet the required quality constraints on both directions as specified in the SDP body. The measured parameters will be compared with the quality constraints specified in the SDP body. If the quality session is Garcia Aranda Expires January 5, 2020 [Page 47] Internet-Draft The Quality for Services Protocol July 2019 compliant with all the quality constraints the application can start. o If the quality constraints are not met, a higher quality service level will be demanded. Depending on the scenario, this quality upgrade will be managed as follows: In the Q4S- aware-network scenario: a Q4S-ALERT method will be triggered by the server to the client and the client will answer with the same Q4S-ALERT method. After receiving the same Q4S-ALERT from the counterpart, no other alerts will be triggered by the server during the "alert-pause" period of time, in order to allow the network to react, but measurements will continue to be taken to achieve early detection of improved network quality conditions and a fast application start. o In the Reactive scenario: an alert notification will be sent by the server stack to the Actuator, and the Actuator will answer with an alert acknowledgement. After receiving the alert acknowledgement from the Actuator, the server stack will not send other alert notifications during the "alert- pause" period of time, in order to allow the Actuator to react and trigger actions on the application or on the policy server, but measurements will continue to be taken to achieve early detection of improved network quality conditions and a fast application start. In both scenarios stated above, if after several measurement cycles, the network constraints cannot be met the quality session is terminated. Concretely when under all possible actions taken by Actuator the quality remains below requirements, the session must be terminated. The steps to be taken in this phase depend on the measurement procedure exchanged during the handshake phase. This document only describes the "default" procedure, but others can be used, like RTP/RTCP (RFC 3550 [18]). Measurements of latency and jitter are done calculating the differences in arrival times of packets and can be achieved with little bandwidth consumption. The bandwidth measurement, on the other hand, involves higher bandwidth consumption in both directions (uplink and downlink). To avoid wasting unnecessary network resources these two types of measurements will be performed in two separate stages. If the required latencies and jitters cannot be reached, it makes no sense to waste network resources measuring bandwidth. In addition, if achieving the required latency and jitter thresholds implies upgrading the quality session level, the chance of obtaining compliant bandwidth measurements without retries is higher, saving Garcia Aranda Expires January 5, 2020 [Page 48] Internet-Draft The Quality for Services Protocol July 2019 network traffic again. Therefore, the default procedure, determines that the measurements are taken in two stages: o Stage 0: Measurement of latencies, jitters and packet loss o Stage 1: Measurement of bandwidths and packet loss Notice that packet loss can be measured in both stages, as all messages exchanged include a sequence-number header that allows for easy packet loss detection. The client starts the negotiation phase sending a READY request using the TCP Q4S ports defined in the SDP. This READY request includes a "Stage" header that indicates the measurement stage. If either jitter, latency or both are specified, the negotiation phase begins with the measurement of latencies and jitters (stage 0). If none of those attributes are specified, stage 0 is skipped. 7.5.1 Stage 0: Measurement of Latencies and Jitter The Stage 0 MUST start with a synchronization message exchange initiated with the client's READY message. Client request, READY message: ========================= READY q4s://www.example.com Q4S/1.0 Stage: 0 Session-Id: 53655765 User-Agent: q4s-ua-experimental-1.0 Content-Length: 0 ========================= Server Response: ========================= Q4S/1.0 200 OK Session-Id: 53655765 Stage:0 Content-Length: 0 ========================= This triggers the exchange of a sequence of PING requests and responses that will lead to the calculation of RTT (latency), jitter and packet loss. Garcia Aranda Expires January 5, 2020 [Page 49] Internet-Draft The Quality for Services Protocol July 2019 After receiving 200 OK, the client must send the first PING message and the server will wait to send PINGs until the reception of this first client PING. Client and server MUST send PING requests to each other. The Sequence-Number header of the first PING MUST be set to 0. Client and server will manage their own sequence numbers. +------------------------------------------------+ | | | Client Server | | | | --------- Q4S READY 0 ---------> | | <-------- Q4S 200 OK ----------- | | | | --------- Q4S PING ------------> | | <-------- Q4S 200 OK ----------- | | <-------- Q4S PING ------------- | | -------- Q4S 200 OK ----------> | | --------- Q4S PING ------------> | | <-------- Q4S PING ------------- | | --------- Q4S 200 OK ----------> | | <-------- Q4S 200 OK ----------- | | ... | | | +------------------------------------------------+ Figure 8 Simultaneous exchange of PING request and responses. Figure 8 shows an example of the PING request sent from the client and the server's response: Garcia Aranda Expires January 5, 2020 [Page 50] Internet-Draft The Quality for Services Protocol July 2019 Client Request: ========================= PING q4s://www.example.com Q4S/1.0 Session-Id: 53655765 Sequence-Number: 0 User-Agent: q4s-ua-experimental-1.0 Measurements: l=22, j=12, pl=0.20, bw= Content-Length: 0 ========================= Server Response: ========================= Q4S/1.0 200 OK Session-Id: 53655765 Sequence-Number: 0 Content-Length: 0 ========================= The function of the PING method is similar to the ICMP echo request message. The server MUST answer as soon as it receives the message. Both endpoints MUST send Q4S PING messages with the periodicity specified in the first parameter of SDP measurement procedure attribute, using always the same UDP ports and incrementing the Sequence-Number with each message. In the following example, the SDP measurement procedure attribute, this value is 50 milliseconds (from the client to the server) and 60ms (from the server to the client). a=measurement:procedure default(50/60,50/50,5000,256/256,256/256) They MUST NOT wait for a response to send the next PING request. The "Sequence-Number" header value is incremented sequentially and MUST start at zero. If this stage is repeated, the initial Sequence-Number MUST start at zero again. All PING requests MUST contain a "Measurements" header, with the values of the latency, jitter and packet loss measured by each entity up to that moment. The client will send its measurements to the server and the server his measurements to the client. Example: Measurements: l=22, j=13, pl=0.10, bw= Where l stands for latency, j for jitter, pl for packetloss and bw for bandwidth. The bandwidth value is omitted, as it is not measured at this stage. Optionally the PING request can include a "Timestamp" header, with the time in which the message has been sent. In case the header is Garcia Aranda Expires January 5, 2020 [Page 51] Internet-Draft The Quality for Services Protocol July 2019 present, the server MUST include the header in the response without changing the value. A minimum number of PING messages MUST be exchanged in order to be able to measure latency, jitter and packet-loss with certain accuracy (at least 256 samples are RECOMMENDED to get a accurate packet loss measurement). Both the client and the server calculate the respective measured parameter values. The mechanisms to calculate the different parameters are described in section 7.3. At the end of this stage 0, there are three possibilities: o The latency, jitter and packet loss constraints are reached in both directions o The latency, jitter and packet loss constraints are not reached in one or both directions In the first case, Stage 0 is finished. Client and server are ready for Stage 1: bandwidth and packet loss measurement. The client moves to stage 1 by sending a READY message including the header "Stage: 1". If the bandwidth constraints are empty or with value zero, the negotiation phase MUST terminate and both client and server may initiate the Continuity Phase. In this case client moves to Continuity phase by sending a READY message including the header "Stage: 2". The second case, in which one or more quality constraints have not been met, is detailed in section 7.5.4. 7.5.2 Stage 1: Measurement of Bandwidth and Packet Loss This stage begins in a similar way to stage 0, sending a READY request over TCP. This READY message "Stage" header value is 1. The server answers with a Q4S 200 OK message to synchronize the initiation of the measurements as shown in Figure 9. Garcia Aranda Expires January 5, 2020 [Page 52] Internet-Draft The Quality for Services Protocol July 2019 +------------------------------------------------+ | | | Client Server | | | | --------- Q4S READY 1 -----------> | | <-------- Q4S 200 OK ------------- | | | | --------- Q4S BWIDTH -----------> | | <-------- Q4S BWIDTH ------------ | | --------- Q4S BWIDTH -----------> | | <-------- Q4S BWIDTH ------------ | | ... | | | +------------------------------------------------+ Figure 9 Starting bandwidth and packet loss measurement Client Request: ========================= READY q4s://www.example.com Q4S/1.0 User-Agent: q4s-ua-experimental-1.0 Stage: 1 Session-Id: 53655765 Content-Length: 0 ========================= Server Response: ========================= Q4S/1.0 200 OK Session-Id: 53655765 Stage: 1 Content-Length: 0 ========================= Just after receiving the 200 OK, both the client and the server MUST start sending BWIDTH messages simultaneously using the UDP q4s ports. Section 7.3.3 describes the bandwidth measurement in detail. At the end of this stage 1, there are three possibilities: o The bandwidth and packet loss constraints are reached in both directions Garcia Aranda Expires January 5, 2020 [Page 53] Internet-Draft The Quality for Services Protocol July 2019 o The bandwidth and packet loss constraints are not reached in one both directions. In the first case, Stage 1 is finished. Client and server are ready for Continuity phase. The client moves to this phase by sending a READY message including the header "Stage: 2". The server answer MUST be 200 OK as shown in Figure 10. +------------------------------------------------+ | | | Client Server | | | | --------- Q4S READY 2 --------------> | | <---- Q4S 200 OK with trigger URI----- | | | | --------- HTTP GET ----------------> | | | | (Application starts) | | | +------------------------------------------------+ Figure 10 Trigger the application using HTTP URI Garcia Aranda Expires January 5, 2020 [Page 54] Internet-Draft The Quality for Services Protocol July 2019 Client Request: ========================= READY q4s://www.example.com Q4S/1.0 User-Agent: q4s-ua-experimental-1.0 Stage: 2 Session-Id: 53655765 Content-Length: 0 ========================= Server Answer: ========================= Q4S/1.0 200 OK Date: Mon, 10 Jun 2010 10:00:01 GMT Session-Id: 53655765 Trigger-URI: http://www.example.com/app_start Expires: 3000 Content-Type: application/sdp Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 Content-Length: 131 (SDP not shown) ========================= If the "Trigger-URI" header is present, the client SHOULD send an HTTP request to this URI. The second case, with violated network constraints is explained in 7.5.4. 7.5.3 Quality Constraints Not Reached After finishing Stage 1 of the Negotiation phase, the client and the server have each other measured parameter values as these have been exchanged in the "Measurements" headers of the PING and BWIDTH messages. If there is one or more parameters that do not comply with the uplink or downlink application constraints required both the server and the client are aware of it. If there is any quality parameter that does not meet the uplink or downlink quality constraints specified in the SDP message, two scenarios are possible depending on the specified alerting-mode (if not present, default value is "Reactive" alerting mode): Garcia Aranda Expires January 5, 2020 [Page 55] Internet-Draft The Quality for Services Protocol July 2019 a) Q4S-aware-network alerting mode: the server MUST send a Q4S- ALERT message to the client including the digital signature header, and the client MUST answer with the same Q4S-ALERT message. The Signature header contains the signed hash value of the SDP body in order to protect all the SDP the data and therefore it MUST contain the measurement parameters in the body. Server request ========================= Q4S-ALERT q4s://www.example.com Q4S/1.0 Host: www.example.com User-Agent: q4s-ua-experimental-1.0 Session-Id: 53655765 Content-Type: application/sdp Content-Length: 142 v=0 o=q4s-UA 53655765 2353687637 IN IP4 192.0.2.33 s=Q4S i=Q4S parameters t=0 0 a=qos-level:1/2 a=alerting-mode: Q4S-aware-network a=alert-pause:5000 a=public-address:client IP4 198.51.100.51 a=public-address:server IP4 198.51.100.58 a=latency:40 a=jitter:10/10 a=bandwidth:20/6000 a=packetloss:0.50/0.50 a=flow:app downlink TCP/10000-20000 a=flow:app uplink TCP/56000 a=flow:q4s downlink UDP/55000 a=flow:q4s downlink TCP/55001 a=flow:q4s uplink UDP/56000 a=flow:q4s uplink TCP/56001 a=measurement:procedure default(50/50,50/50,5000,256/256,256/256) a=measurement:latency 30 a=measurement:jitter 6/4 a=measurement:bandwidth 200/4000 a=measurement:packetloss 0.20/0.33 ========================= At this point, both client and server keep on measuring but without sending new Q4S ALERT messages during the "alert-pause" milliseconds. Garcia Aranda Expires January 5, 2020 [Page 56] Internet-Draft The Quality for Services Protocol July 2019 b) Reactive alerting mode: the server stack MUST send an alert notification to the Actuator, and the Actuator MUST answer with an acknowledgement to the received alert notification. The alert notification sent to the Actuator by the server stack doesn't follow Q4S message style but should have all the information the Actuator will need for the actions to be taken, which will be implementation dependent. At this point, during Negotiation phase, both client and server keep on measuring without sending new alert notifications to the Actuator during the "alert-pause" milliseconds specified in the SDP. This way, both client and server will detect any improvement in network conditions as soon as the network reacts. The application can start as soon as the number of measurements indicated in the measurement procedure attribute indicates that the quality parameters are met. Same applies to Continuity phase: the measurement dialog between client and server must not be interrupted by any possible ALERT message. 7.5.3.1 Actuator Role Actuator receives notifications of unmet requirements from the Q4S server stack, and act upon the application or the network policy server, according to logic out of scope of this protocol. The Actuator logic activates mechanisms at application level or/and network level based on a quality level dictionary, in which each level meaning is implementation dependent and each level involve different actions based on rules to keep certain user experience quality. The type of actions that an Actuator can take at application level are application dependent and MAY involve: o Reduction of application functionalities, such as limitation of application speed or application options. o Reduction of application resources usage, such as reduction of frames per second in a video app or any other parameter modification in order to adapt to network conditions. Apart from actions at application level, the Actuator MAY act at network level if a network policy server is available. Garcia Aranda Expires January 5, 2020 [Page 57] Internet-Draft The Quality for Services Protocol July 2019 7.5.3.2 Policy Server Role A network policy server may be part of the reactive scenario and it is in charge of managing network quality provision. Network policy server may implement all or some of these features (but not exclusive to): o Server validation in terms of quality constraints. o Authentication (Signature validation) and security (block malicious clients) o Policy rules (following rules are only examples): - Maximum quality level allowed for the ACP - Time bands allowed for providing quality sessions - Number of simultaneous quality sessions allowed - Maximum time used by allowed quality sessions - Etc. If any of the policy rules fail, a Q4S-ALERT message MUST be answered by a 6XX error, indicating the cause. 7.5.4 QoS Level Changes If any constraint was violated, server MAY trigger a Q4S-ALERT asking for higher qos-level attribute. The maximum qos-level allowed is 9, both uplink and downlink. If the qos-level has reached the maximum value for downlink or uplink without matching the constraints, then a CANCEL request MUST be sent by the client using the TCP port determined in the handshake phase in order to release the session. In reaction to the reception of the CANCEL request, the server MUST send a CANCEL request too. If no CANCEL request is received, the expiration time cancels the session at server side. Garcia Aranda Expires January 5, 2020 [Page 58] Internet-Draft The Quality for Services Protocol July 2019 Client Request: ========================= CANCEL q4s://www.example.com Q4S/1.0 User-Agent: q4s-ua-experimental-1.0 Session-Id: 53655765 Content-Type: application/sdp Content-Length: 142 (SDP not shown) ========================= Server Request in reaction to Client Request: ========================= CANCEL q4s://www.example.com Q4S/1.0 Session-Id: 53655765 Expires: 0 Content-Type: application/sdp Signature: 6ec1ba40e2adf2d783de530ae254acd4f3477ac4 Content-Length: 131 (SDP not shown) ========================= 7.6 Continuity Phase During the negotiation phase, latency, jitter, bandwidth and packet loss have been measured. During the continuity phase bandwidth will not be measured again because bandwidth measurements may disturb application performance. This phase is supposed to be executed at the same time as the real-time application is being used. This document only covers the default procedure. The continuity operation with default procedure is based on a sliding window of samples. The number of samples involved in the sliding window may be different for jitter and latency than for packet-loss calculations according to the fifth and sixth parameters of the measurement procedure attribute. In the example, shown in Figure 11, the jitter and latency sliding window comprises 40 samples whereas the size of the packet-loss sliding window is 100 samples: a=measurement:procedure default(50/50,75/75,5000,40/40,100/100) In addition, the sizes of these windows are configurable per direction: uplink and downlink values may differ. PING requests are sent continuously (in both directions) and when the Sequence-Number header reaches the maximum value, the client Garcia Aranda Expires January 5, 2020 [Page 59] Internet-Draft The Quality for Services Protocol July 2019 continues sending PING messages with the Sequence-Number header starting again at zero. When the server PING Sequence-Number header reaches the maximum value, it does the same, starting again from zero. On the client side, the measured values of downlink jitter, downlink packet loss and latency are calculated using the last samples, discarding older ones, in a sliding window schema. +--------------------------------------------------+ | | | 55 56 57 . . . 253 254 255 0 1 2 . . . 55 56 | | A A | | | | | | +-----------------------------------+ | | | +--------------------------------------------------+ Figure 11 Sliding samples window Only if the server detects that the measured values (downlink or uplink jitter, packet loss or latency) are not reaching the quality constraints, a Q4S ALERT is triggered and sent either to the client or to the Actuator, depending on the alerting mode, and the alert-pause timer is started. In Q4S-aware-network alerting mode shown in Figure 12, if the client receives a Q4S ALERT message, it MUST answer sending the Q4S ALERT request message back to the server including the SDP (with its corresponding digital signature). Both client and server will keep performing measurements but no other Q4S ALERT message MUST be sent during "alert-pause" milliseconds. The operations needed to act on the network and the agents in charge of them are out of scope of this draft. Garcia Aranda Expires January 5, 2020 [Page 60] Internet-Draft The Quality for Services Protocol July 2019 +------------------------------------------------+ | | | Client Server | | | | ... | | ----------- PING ----------> | | <--------- 200 OK ---------- | | <------- Q4S-ALERT --------- | | -------- Q4S-ALERT --------> | | <---------- PING ----------- | | ---------- 200 OK ---------> | | ----------- PING ----------> | | <--------- 200 OK ---------- | | <---------- PING ----------- | | ---------- 200 OK ---------> | | ... | | | +------------------------------------------------+ Figure 12 Continuity in Q4S-aware-network alerting mode In the Reactive scenario shown in Figure 13, if the server detects that the measured values (downlink or uplink jitter, packet loss or latency) are not reaching the quality constraints, an alert notification is triggered and sent to the Actuator. The Actuator MUST then answer to the server stack with an alert acknowledgement The measurement dialog between the client and the server MUST NOT be interrupted by any possible ALERT message. Garcia Aranda Expires January 5, 2020 [Page 61] Internet-Draft The Quality for Services Protocol July 2019 +------------------------------------------------+ | | | Client Server Actuator | | ... | | --- PING ----------> | | <-- 200 OK---------- | | <----- PING -------- | | <--- 200 OK -------- ---- alert | | notification --> | | | | --- PING ----------> <--- alert | | acknowledge --- | | <-- 200 OK---------- | | <----- PING -------- | | --- 200 OK --------> | | ... | | | +------------------------------------------------+ Figure 13 Continuity in Reactive alerting mode 7.7 Termination Phase The Termination phase is the end point for the established Q4S session that is reached in the following cases: . A CANCEL message has been received. The client sends a CANCEL message due to the impossibility of the network to meet the required quality constraints. The client and server application will be notified by the respective Q4S stack. . Session expires: if after the Expires time no client or server activity is detected, that end cancels the session. . A BEGIN message has been received by the server. The pre- existing Q4S quality session is cancelled and a new session will be initiated. The meaning of Termination phase in terms of release of resources or accounting is application dependent and out of scope of the Q4S protocol. In Reactive alerting mode, Q4S CANCEL messages received by the Q4S server must cause the sending of cancel notifications sent from the server stack to the Actuator in order to release possible assigned resources for the session. 7.7.1. Sanity Check of Quality Sessions Garcia Aranda Expires January 5, 2020 [Page 62] Internet-Draft The Quality for Services Protocol July 2019 A session may finish due to several reasons (client shutdown, client CANCEL request, constraints not reached, etc), and any session finished MUST release the assigned resources. In order to release the assigned server resources for the session, the "Expires" header indicates the maximum interval of time without exchanging any Q4S message. 7.8 Dynamic Constraints And Flows Depending on the nature of the application, the quality constraints to be reached may evolve, changing some or all quality constraint values in any direction. The client MUST be able to deal with this possibility. When the server sends an SDP document attached to a response (200 OK, or Q4S-ALERT, etc), the client MUST take all the new received values, overriding any previous value in use. The dynamic changes on the quality constraints can be as a result of two possibilities: o The application communicates to the Q4S server a change in the constraints. In this case the application requirements can evolve and the Q4S server will be aware of them. o The application uses TCP flows. In that case, in order to guarantee a constant throughput, the nature of TCP behavior forces the use of a composite constraint function, which depends on RTT, packet loss and window control mechanism implemented in each TCP stack. TCP throughput can be less than actual bandwidth if the Bandwidth-Delay Product (BDP) is large or if the network suffers from a high packet loss rate. In both cases, TCP congestion control algorithms may result in a suboptimal performance. Different TCP congestion control implementations like Reno [23], High Speed TCP (RFC 3649 [24]), CUBIC [25], Compound TCP (CTCP [26]), etc. reach different throughputs under the same network conditions of RTT and packet loss. In all cases, depending on the RTT measured value, the Q4S server could change dynamically the packetloss constraints (defined in SDP) in order to make possible to reach a required throughput or vice versa (use packetloss measurement to change dynamically latency constraints). Garcia Aranda Expires January 5, 2020 [Page 63] Internet-Draft The Quality for Services Protocol July 2019 A general guideline to calculate the packetloss constraint and RTT constraint consists in approximating the throughput using a simplified formula, which should take into account the TCP stack implementation of the receiver, in addition to RTT and packet loss: Th= Function( RTT, packet loss, ...) Then, depending on RTT measured values, set dynamically the packetloss constraint. It is possible to easily calculate a worst-case boundary for the Reno algorithm, which should ensure for all algorithms that the target throughput is actually achieved. Except that, high-speed algorithms will then have even a larger throughput, if more bandwidth is available. For the Reno algorithm, the Mathis' formula may be used [23] for the upper bound on the throughput: Th <= (MSS/RTT)*(1 / sqrt{p}) In absence of packet loss, a practical limit for the TCP throughput is the receiver_window_size divided by the round-trip time. However, if the TCP implementation uses a window scale option, this limit can reach the available bandwidth value. 7.9 Qos-level Upgrade And Downgrade Operation Each time the server detects violation of constraints, the alert mechanism is triggered, the alert-pause timer is started, and the qos-level is increased. When this happens repeatedly, and the qos- level reaches its maximum value (value 9), the session is cancelled. But when the violation of constraints stops before reaching qos-level maximum value, the recovery mechanism allows for the qos-level upgrade gradually. Following, this downgrade and upgrade of qos-level is explained with an example: 1. A Q4S session is initiated successfully with qos-level=0. 2. During the continuity phase, violation of constraints is detected; qos-level is increased to 1, a Q4S-ALERT is sent by the server to the client and alert-pause timer is started. 3. Alert-pause timer expires and still violation of constraints is detected; qos-level is increased to 2, a Q4S-ALERT is sent by the server to the client and alert-pause timer is started. Garcia Aranda Expires January 5, 2020 [Page 64] Internet-Draft The Quality for Services Protocol July 2019 4. Alert-pause timer expires but violation of constraints has stopped; recovery-pause is started. 5. Recovery-pause timer expires, and no violation of constraints has been detected meanwhile; qos-level is decreased to 1, a Q4S-RECOVERY is sent by the server to the client and recovery-pause timer is started again. 6. Recovery-pause timer expires again and no violation of constraints has been detected meanwhile; qos-level is decreased to 0 and a Q4S-RECOVERY is sent by the server to the client; recovery-pause timer is not started this time as qos-level has reached its initial value. When the network configuration allows for the possibility of managing Q4S flows and application flows independently (either is a network-based QoS or a Q4S aware network), the qos-level downgrade process could be managed more efficiently using a strategy that allows for carrying out qos-level downgrades excluding app flows from SDP dynamically. The Q4S flows would be downgraded to allow for measurements on a lower quality level without interference of the application flows. A Q4S client MUST allow this kind of SDP modifications by the server. Periodically (every several minutes, depending on the implementation) a Q4S-ALERT could be triggered, in which the level is downgraded for Q4S flows, excluding application flows from the embedded SDP of that request. This mechanism allows to measure at lower levels of quality while application flows continue using a higher qos level value. o If the measurements in the lower level meet the quality constraints, then a Q4S-RECOVERY message to this lower qos- level may be triggered, in which the SDP includes the application flows in addition to Q4S flows. o If the measurements in the lower level do not meet the constraints, then a new Q4S-ALERT to the previous qos-level MUST be triggered, in which the SDP includes only the Q4S flows. Garcia Aranda Expires January 5, 2020 [Page 65] Internet-Draft The Quality for Services Protocol July 2019 +------------------------------------------------+ | | | qos-level | | A | | | | | 4| | | | | | 3| +------+ | | | | | | | 2| +----+ +----+ +--- | | | | | | | | 1| +----+ +-----+ | | | | | | 0+---+---------------------------------> time | | | +------------------------------------------------+ Figure 14 Possible evolution of qos-level This mechanism, illustrated in Figure 14, avoids the risk of disturbing the application, while the measurements are being run in lower levels. However, this optional optimization of resources MUST be used carefully. The chosen period to measure a lower qos level is implementation dependent. Therefore, it is not included as a measurement procedure parameter. It is RECOMMENDED to use a large value, such as 20 minutes. 8 General User Agent Behavior 8.1 Roles in Peer-to-Peer Scenarios In order to allow peer to peer applications, a Q4S User Agent (UA) MUST be able to assume both client and server role. The role assumed depends on who sends the first message. In a communication between two UAs, the UA that sends the Q4S BEGIN request in the first place, for starting the handshake phase, shall assume the client role. If both UASs send the BEGIN request at the same time, they will wait for a random time to restart again as shown in Figure 15. Otherwise, an UA may be configured to act only as server (e.g., content provider's side). Garcia Aranda Expires January 5, 2020 [Page 66] Internet-Draft The Quality for Services Protocol July 2019 +-----------------------------------------------+ | | | UA(Client) UA(Server) | | | | -------- Q4S BEGIN -------------> | | <------- Q4S BEGIN -------------- | | | | ------- Q4S BEGIN --------------> | | <------ Q4S 200 OK -------------- | | | | | +-----------------------------------------------+ Figure 15 P2P roles. 8.2 Multiple Quality Sessions in Parallel A Q4S session is intended to be used for an application. It means that for using the application, the client MUST establish only one Q4S session against the server. Indeed, the relation between session-id and application is 1 to 1. If a user wants to participate in several independent Q4S sessions simultaneously against different servers (or against the same server) it can execute different Q4S clients to establish separately different Q4S sessions but it is NOT RECOMMENDED, because: o The establishment of a new Q4S session may affect other running applications over other Q4S sessions during bandwidth measurement. o If the negotiation phase is executed separately before running any application, the summation of bandwidth requirements could not be met when the applications are running in parallel. 8.3 General Client bBhavior A Q4S Client has different behaviors. We will use letters X,Y,Z to designate each different behavior (follow the letter bullets in figure 16). X) When it sends messages over TCP (methods BEGIN, READY, Q4S- ALERT, Q4S-RECOVERY and CANCEL) it behaves strictly like a state machine that sends requests and waits for responses. Depending on the response type it enters in a new state. Garcia Aranda Expires January 5, 2020 [Page 67] Internet-Draft The Quality for Services Protocol July 2019 When it sends UDP messages (methods PING and BWIDTH), a Q4S client is not strictly a state machine that sends messages and waits for responses because: Y) At latency, jitter and packet loss measurement, the PING requests are sent periodically, not after receiving the response to the previous request. In addition, the client MUST answer the PING requests coming from the server, therefore the client assumes temporarily the role of a server. Z) At bandwidth and packet loss measurement stage, the client does not expect to receive responses when sending BWIDTH requests to the server. In addition, it MUST receive and process all server messages in order to achieve the downlink measurement. The Q4S-ALERT and CANCEL may have a conventional answer if an error is produced, otherwise the corresponding answer is formatted as a request message. +-----------+------------------------+-----------+-----------+ | Handshake | Negotiation |Continuity |Termination| | Phase | Phase | Phase | Phase | | | | | | | X ---------> Y --> X --> Z --> X ---> Y --> X ---> X | | | A | A | | A | | | | | | | | | | | | | | | | +-----+ +-----+ | +-----+ | | | | | | | +------------------------------------------------+-----------+ Figure 16 Phases & client behaviors. 8.3.1 Generating Requests A valid Q4S request formulated by a Client MUST, at a minimum, contains the following header fields: o If no SDP is included: the header Session-Id and Sequence- Number are mandatory. o If SDP is included: Session-Id is embedded into SDP, therefore the inclusion of Session-Id header is optional but if present must have the same value. Measurements are embedded into the SDP only for Q4S-ALERT messages in order to be signed. Garcia Aranda Expires January 5, 2020 [Page 68] Internet-Draft The Quality for Services Protocol July 2019 At any time, if the server sends a new SDP with updated values, client MUST take it into account. 8.4 General Server Behavior If a server does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. The role of the server is changed at negotiation and continuity phases, in which server MUST send packets to measure jitter, latency and bandwidth. Therefore, the different behaviors of server are (follow the letter bullets in the figure 17): R) When the client sends messages over TCP (methods BEGIN, READY Q4S-ALERT, Q4S-RECOVERY and CANCEL) it behaves strictly like a state machine that receives messages and sends responses. When the client begins to send UDP messages (methods PING and BWIDTH), a Q4S server is not strictly a state machine that receives messages and sends responses because: S) At latency, jitter and packet loss measurement, the PING requests are sent periodically by the client but also by the server. In this case the server behaves as a server answering client requests but also behaves temporarily as a client, sending PING requests toward the client and receiving responses. T) At bandwidth and packet loss measurement, the server sends BWIDTH requests to the client. In addition, it MUST receive and process client messages in order to achieve the uplink measurement. The Q4S-ALERT and CANCEL may have a conventional answer if an error is produced, otherwise the corresponding answer is formatted as a request message. Garcia Aranda Expires January 5, 2020 [Page 69] Internet-Draft The Quality for Services Protocol July 2019 +-----------+------------------------+-----------+-----------+ | Handshake | Negotiation |Continuity |Termination| | Phase | Phase | Phase | Phase | | | | | | | R ---------> S --> R --> T --> R ---> S --> R ---> R | | | A | A | | A | | | | | | | | | | | | | | | | +-----+ +-----+ | +-----+ | | | | | | | +------------------------------------------------+-----------+ Figure 17 Phases & server behaviours. 9 Implementation Recommendations 9.1 Default Client Constraints To provide a default configuration, it would be good that the client had a configurable set of Quality headers in the implementation settings menu. Otherwise these quality headers will not be present in the first message. Different business models (out of scope of this proposal) may be achieved: depending on who pays for the quality session, the server can accept certain Client parameters sent in the first message, or force billing parameters on the server side. 9.2 Latency and Jitter Measurements Different client and server implementations may send a different number of PING messages for measuring, although at least 255 messages should be considered to perform the latency measurement. The Stage 0 measurements only may be considered ended when neither client nor server receive new PING messages after an implementation-dependent guard time. Only after, client can send a "READY 1" message. In execution systems, where the timers are not accurate, a recommended approach consists of including the optional header "Timestamp" in the PING request with the time in which the message has been sent. This allows an accurate measurement of the jitter even with no identical intervals of time between PINGs. Garcia Aranda Expires January 5, 2020 [Page 70] Internet-Draft The Quality for Services Protocol July 2019 9.3 Bandwidth Measurements In programming languages or Operating Systems with limited timers or clock resolution, it is recommended to use an approach based on several intervals to send messages of 1KB (= 8000 bits), in order to reach the required bandwidth consumption using a rate as close as possible to a constant rate. For example, if the resolution is 1 millisecond, and the bandwidth to reach is 11Mbps, a good approach consists of sending: 1 message of 1KB every 1 millisecond + 1 message of 1KB every 3 milliseconds + 1 message of 1KB every 23 milliseconds The number of intervals depends on required bandwidth and accuracy that the programmer wants to achieve. Considering messages of 1KB (= 8000 bits), a general approach to determine these intervals is 1) Compute Target bandwidth / 8000 bits. In the example above is 11Mbps/8000 = 1375 messages per second 2) Divide the number of messages per second by 1000 to determine the number of messages per millisecond. 1375/1000 = 1'375. The integer value is the number of messages per millisecond (in this case, one). The pending bandwidth is now 375 messages per second 3) To achieve the 375 messages per second, use a sub-multiple of 1000 which must be less than 375 1000/2 = 500 > 375 1000/3 = 333 < 375 In this case a message every 3 ms is suitable. The new pending target bandwidth is 375 -333 = 42 messages per second 4) Repeat the same strategy as point 3, to reach the pending bandwidth. In this case, 23 ms is suitable because: 1000/22 = 45 >42 1000/23 = 43 >42 1000 / 24 = 41.6 < 42 Garcia Aranda Expires January 5, 2020 [Page 71] Internet-Draft The Quality for Services Protocol July 2019 We can choose 24 ms but then we need to cover additional 0.4 messages per second (42-41.6=0.4) and 43 is a number higher than 42 but very close to it. In execution systems where the timers are not accurate, a recommended approach consists of checking at each interval the number of packets that should have been sent at this timestamp since origin and send the needed number of packets in order to reach the required bandwidth. The shorter packets are used, the more constant is the rate of bandwidth measurement. However, this may stress the execution system in charge of receiving and processing packets. As a consequence, some packets may be lost because of stack overflows. To deal with this potential issue, a larger packet is RECOMMENDED (2KB or more) taking into account the overhead produced by the chunks headers. 9.4 Packet Loss Measurement Resolution Depending on application nature and network conditions, a packet loss resolution less than 1% may be needed. In such cases, there is no limit to the number of samples used for this calculation. A tradeoff between time and resolution should be reached in each case. For example, in order to have a resolution of 1/10000, the last 10000 samples should be considered in the packet loss measured value. The problem of this approach is the reliability of old samples. If the interval used between PING messages is 50ms, then to have a resolution of 1/1000 it takes 50 seconds and a resolution of 1/10000 takes 500 seconds (more than 8 minutes). The reliability of a packet loss calculation based on a sliding window of 8 minutes depends on how fast network conditions evolve. 9.5 Measurements and Reactions Q4S can be used as a mechanism to measure and trigger network tuning and application level actions (i.e. lowering video bit- rate, reduce multiplayer interaction speed, etc) in real-time in order to reach the application constraints, addressing measured possible network degradation. 9.6 Instability Treatments There are two scenarios in which Q4S can be affected by network problems: loss of Q4S packets and outlier samples. Garcia Aranda Expires January 5, 2020 [Page 72] Internet-Draft The Quality for Services Protocol July 2019 9.6.1 Loss of Control Packets Lost UDP packets (PING or BWIDTH messages) don't cause any problems for the Q4S state machine, but if TCP packets are delivered too late (which we will consider as "lost"), some undesirable consequences could arise. Q4S does have protection mechanisms to overcome these situations. Examples: o If a BEGIN packet is lost or its corresponding answer, after a certain timeout, the client SHOULD resend another BEGIN packet, resetting the session o If a READY packet is lost, after a certain timeout, the client SHOULD resend another READY packet. o If a QOS ALERT request is lost or its corresponding answer, after a certain timeout, the originator SHOULD resend another Q4S-ALERT packet. o If a CANCEL request is lost or its corresponding answer, after a certain timeout, the originator SHOULD resend another CANCEL packet. 9.6.2 Outlier Samples Outlier samples are those jitter or latency values far from the general/average values of most samples. Hence Q4S default measurement method uses the statistical median formula for latency calculation, the outlier samples are neutralized. This is a very common filtering for noise or errors on signal and image processing. 9.7 Scenarios Q4S could be used in two scenarios: o client to ACP (Application content provider) o client to client (peer to peer scenario) Garcia Aranda Expires January 5, 2020 [Page 73] Internet-Draft The Quality for Services Protocol July 2019 9.7.1 Client to ACP One server: It is the common scenario in which client contact server to establish a Q4S session. N servers: In Content Delivery Networks and in general applications where delivery of contents can be achieved by different delivery nodes, two working mechanisms can be defined o Starting mode: End-user may run Q4S against several delivery nodes and after some seconds choose the best one to start the multimedia session o Prevention mode: During streaming session, user keeps several Q4S dialogs against different alternative delivery nodes. In case of congestion, end-user MAY change to the best alternative delivery node 9.7.2 Client to Client In order to solve the client to client scenario, a Q4S register function MUST be implemented. This allows clients contact each other for sending the BEGIN message. In this scenario, the Register server would be used by peers to publish their Q4S- Resource-Server header and their public IP address to make possible the assumption of server role. The register function is out of scope of this protocol version, because different HTTP mechanisms can be used and Q4S MUST NOT force any. 10 Security Considerations 10.1 Confidentiality Issues Hence Q4S does not transport any application data, Q4S does not jeopardize the security of application data. However, other certain considerations may take place, like identity impersonation and measurements privacy and integrity. Garcia Aranda Expires January 5, 2020 [Page 74] Internet-Draft The Quality for Services Protocol July 2019 10.2 Integrity of Measurements and Authentication Identity impersonation could potentially produce anomalous Q4S measurements. If this attack is based on spoofing of server IP address, it can be avoided using the digital signature mechanism, included in the SDP. The network can easily validate this digital signature using the public key of the server certificate. Integrity of Q4S measurements under any malicious manipulation (such as Man-in-the-Middle (MITM) attack) relay on the same mechanism, the SDP signature. The Signature header contains the signed hash value of the SDP body in order to protect all the SDP data, including the measurements. This signature not only protects the integrity of data but also authenticates the server. 10.3 Privacy of Measurements This protocol could be supported over IPSec. Q4S relays on UDP and TCP, and IPSec supports both. If Q4S is used for application-based QoS, then IPsec is operationally valid but if Q4S is used to trigger network-based actions, then measurements could be wrong, unless IPSec ports be considered at any potential action over the network (such as prioritization of certain application flows). 10.4 Availability Issues Any loss of connectivity may interrupt the availability of Q4S service, and results in higher packet-loss measurements, which is just the desired behavior in these situations. In order to mitigate availability issues caused by malicious attacks (such as DoS and DDoS), a good practice is to enable Q4S service only for authenticated users. Q4S can be launched after user is authenticated by the application. At this moment, his IP address is known and the Q4S service may be enabled for this IP address. Otherwise Q4S service should appear unreachable. 10.5 Bandwidth Occupancy Issues Q4S bandwidth measurement is limited to the application needs. It means that all available bandwidth is not measured, but only the fraction required by the application. This allows other applications to use normally the rest of available bandwidth. However, a malicious Q4S client could re-starts Q4S sessions just after finishing the negotiation phase. The consequence would be to waste bandwidth for nothing. Garcia Aranda Expires January 5, 2020 [Page 75] Internet-Draft The Quality for Services Protocol July 2019 In order to mitigate this possible anomalous behavior, it is RECOMMENDED to configure the server to reject sessions from the same end-point when this situation is detected. 11 Future Code Point Requirements If the ideas described in this document are pursued to become a protocol specification, then the code points described in this document will need to be assigned by IANA. 11.1 Service Port The need for an assigned PORT is to make possible a future Q4S aware network, capable of react by itself to Q4S alerts. A specific port would simplify the identification of the protocol by network elements in charge of take possible reactive decisions. Therefore, the need for a port by IANA may be postponed to the need for a future Q4S aware network. Service Name: Q4S Transport Protocol(s): TCP Assignee : Name : Jose Javier Garcia Aranda Email: jose_javier.garcia_aranda@nokia.com Contact : Name : Jose Javier Garcia Aranda Email: jose_javier.garcia_aranda@nokia.com Description : The service associated with this request is in charge of the establishment of new Q4S sessions, and during the session manages the pass to a new protocol stage (handshake, negotiation and continuity) as well as inform of alerts when measurements do not meet the requirements. Reference : this document. This service does not use IP-layer broadcast, multicast, or anycast communication. Garcia Aranda Expires January 5, 2020 [Page 76] Internet-Draft The Quality for Services Protocol July 2019 12 References 12.1 Normative References [1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. [2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [3] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. [4] Fielding, R., Ed., Y. Lafon, Ed. and J. Reschke, Ed. "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014. [5] Fielding, R., Ed., M. Nottingham, Ed. and J. Reschke, Ed. "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014. [6] Fielding, R., Ed. and J. Reschke, Ed. "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. [7] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000 [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [9] Thomson, M., "Version-Independent Properties of QUIC", April 2019 [10] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 4566, July 2006. [11] Bradner, S., "Key words for use in RFCs to Indicate RequirementLevels", BCP 14, RFC 2119, March 1997. [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005. [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002. [14] Eastlake, D. and Hansen, T. "US Secure Hash Algorithms", RFC 4634, May 1992. Garcia Aranda Expires January 5, 2020 [Page 77] Internet-Draft The Quality for Services Protocol July 2019 [15] Moriarty, K., Johnsson, J., B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications version 2.2", RFC 8017, November 2016. [16] Defense Advanced Research Projects Agency, " Transmission Control Protocol", RFC 793, September 1981. [17] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [18] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V. "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, july 2003. [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [20] Resnick, P., "Internet Message Format", RFC 5322, October 2008 [21] Leiba, S., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2007 12.2 Informative References [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A. Peterson, J., Sparks, R., Handley, M. and Schooler, E. , "SIP: Session Initiation Protocol", RFC 3261, June 2002. [23] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communications Review, 27(3), July 1997. [24] Floyd, S., "HighSpeed TCP for a Large Congestion Windows", RFC 3649, December 2003. [25] Rhee, I., Xu, L., Ha, S., "CUBIC for Fast Long-Distance Networks", Internet-draft draft-rhee-tcpm-cubic-02, February 2009. [26] Sridharan, M., Tan, K., Bansal, D., Thaler, D., "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", Internet-draft draft-sridharan-tcpm- ctcp-02, November, 2008. Garcia Aranda Expires January 5, 2020 [Page 78] Internet-Draft The Quality for Services Protocol July 2019 [27] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [28] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. Garcia Aranda Expires January 5, 2020 [Page 79] Internet-Draft The Quality for Services Protocol July 2019 13 Acknowledgments Many people have made comments and suggestions contributing to this document. In particular, we would like to thank: Victor Villagra, Sonia Herranz, Clara Cubillo Pastor, Francisco Duran Pina, Michael Scharf, Jesus Soto Viso and Federico Guillen. Additionally, we want to thank the Spanish Centre for the Development of Industrial Technology (CDTI) as well as the Spanish Science and Tech Ministry which funds this initiative through their innovation programs. Garcia Aranda Expires January 5, 2020 [Page 80] Internet-Draft The Quality for Services Protocol July 2019 14 Contributors Jacobo Perez Lajo Nokia Spain Email: jacobo.perez@nokia.com Luis Miguel Diaz Vizcaino Nokia Spain Email: Luismi.Diaz@nokia.com Gonzalo Munoz Fernandez Nokia Spain Email: gonzalo.munoz_fernandez.ext@nokia.com Manuel Alarcon Granero Nokia Spain Email: manuel.alarcon_granero.ext@nokia.com Francisco Jose juan Quintanilla Nokia Spain Email: francisco_jose.juan_quintanilla.ext@nokia.com Carlos Barcenilla Universidad Politecnica de Madrid Juan Quemada Universidad Politecnica de Madrid Email: jquemada@dit.upm.es Ignacio Maestro Tecnalia Research & Innovation Email: ignacio.maestro@tecnalia.com Lara Fajardo Ibanez Optiva Media Email: lara.fajardo@optivamedia.com Pablo Lopez Zapico Optiva Media Email: Pablo.lopez@optivamedia.com David Muelas Recuenco Universidad Autonoma de Madrid Email: dav.muelas@uam.es Garcia Aranda Expires January 5, 2020 [Page 81] Internet-Draft The Quality for Services Protocol July 2019 Jesus Molina Merchan Universidad Autonoma de Madrid jesus.molina@uam.es Jorge E. Lopez de Vergara Mendez Universidad Autonoma de Madrid Email: jorge.lopez_vergara@uam.es Victor Manuel Maroto Ortega Optiva Media Email: victor.maroto@optivamedia.com Garcia Aranda Expires January 5, 2020 [Page 82] Internet-Draft The Quality for Services Protocol July 2019 15 Authors' Addresses Jose Javier Garcia Aranda Nokia C/Maria Tubau 9 28050 Madrid Spain Phone: +34 91 330 4348 Email: jose_javier.garcia_aranda@nokia.com Monica Cortes Universidad Politecnica de Madrid Avenida Complutense 30 28040 Madrid Spain Email: cortesm@dit.upm.es Joaquin Salvachua Universidad Politecnica de Madrid Avenida Complutense 30 28040 Madrid Spain Phone: +34 91 0672134 Email: jsalvachua@dit.upm.es Maribel Narganes Tecnalia Research & Innovation Parque Cientifico y Tecnologico de Bizkaia Geldo Auzoa, Edificio 700 E-48160 Derio (Bizkaia) Spain Phone: +34 946 430 850 Email: maribel.narganes@tecnalia.com Inaki Martinez Sarriegui Optiva Media Edificio Europa II, Calle Musgo 2, 1G, 28023 Madrid Spain Phone: +34 91 297 7271 Email: inaki.martinez@optivamedia.com Garcia Aranda Expires January 5, 2020 [Page 83] ./draft-ietf-dots-data-channel-31.txt0000644000764400076440000040673713515242644016671 0ustar iustyiusty DOTS M. Boucadair, Ed. Internet-Draft Orange Intended status: Standards Track T. Reddy, Ed. Expires: January 23, 2020 McAfee July 22, 2019 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification draft-ietf-dots-data-channel-31 Abstract The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; o reference: RFC XXXX Please update the "revision" date of the YANG module. 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 https://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 Boucadair & Reddy Expires January 23, 2020 [Page 1] Internet-Draft DOTS Data Channel Protocol July 2019 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 23, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. DOTS Data Channel . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 5 3.2. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8 3.3. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Detect and Prevent Infinite Loops . . . . . . . . . . . . 9 3.5. Stale Entries . . . . . . . . . . . . . . . . . . . . . . 10 4. DOTS Data Channel YANG Module . . . . . . . . . . . . . . . . 10 4.1. Generic Tree Structure . . . . . . . . . . . . . . . . . 10 4.2. Filtering Fields . . . . . . . . . . . . . . . . . . . . 13 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20 5. Managing DOTS Clients . . . . . . . . . . . . . . . . . . . . 37 5.1. Registering DOTS Clients . . . . . . . . . . . . . . . . 37 5.2. Unregistering DOTS Clients . . . . . . . . . . . . . . . 40 6. Managing DOTS Aliases . . . . . . . . . . . . . . . . . . . . 40 6.1. Create Aliases . . . . . . . . . . . . . . . . . . . . . 41 6.2. Retrieve Installed Aliases . . . . . . . . . . . . . . . 45 6.3. Delete Aliases . . . . . . . . . . . . . . . . . . . . . 47 7. Managing DOTS Filtering Rules . . . . . . . . . . . . . . . . 47 7.1. Retrieve DOTS Filtering Capabilities . . . . . . . . . . 47 7.2. Install Filtering Rules . . . . . . . . . . . . . . . . . 49 7.3. Retrieve Installed Filtering Rules . . . . . . . . . . . 52 7.4. Remove Filtering Rules . . . . . . . . . . . . . . . . . 59 8. Operational Considerations . . . . . . . . . . . . . . . . . 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 Boucadair & Reddy Expires January 23, 2020 [Page 2] Internet-Draft DOTS Data Channel Protocol July 2019 10. Security Considerations . . . . . . . . . . . . . . . . . . . 61 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 63 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 14.1. Normative References . . . . . . . . . . . . . . . . . . 65 14.2. Informative References . . . . . . . . . . . . . . . . . 66 Appendix A. Sample Examples: Filtering Fragments . . . . . . . . 68 Appendix B. Sample Examples: Filtering TCP Messages . . . . . . 71 B.1. Discard TCP Null Attack . . . . . . . . . . . . . . . . . 71 B.2. Rate-Limit SYN Flooding . . . . . . . . . . . . . . . . . 72 B.3. Rate-Limit ACK Flooding . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 1. Introduction A distributed denial-of-service (DDoS) attack is an attempt to make machines or network resources unavailable to their intended users. In most cases, sufficient scale can be achieved by compromising enough end-hosts and using those infected hosts to perpetrate and amplify the attack. The victim of such attack can be an application server, a router, a firewall, an entire network, etc. As discussed in [RFC8612], the lack of a common method to coordinate a real-time response among involved actors and network domains inhibits the speed and effectiveness of DDoS attack mitigation. From that standpoint, DDoS Open Threat Signaling (DOTS) defines an architecture that allows a DOTS client to send requests to a DOTS server for DDoS attack mitigation [I-D.ietf-dots-architecture]. The DOTS approach is thus meant to minimize the impact of DDoS attacks, thereby contributing to the enforcement of more efficient defensive if not proactive security strategies. To that aim, DOTS defines two channels: the signal and the data channels (Figure 1). +---------------+ +---------------+ | | <------- Signal Channel ------> | | | DOTS Client | | DOTS Server | | | <======= Data Channel ======> | | +---------------+ +---------------+ Figure 1: DOTS Channels The DOTS signal channel is used to carry information about a device or a network (or a part thereof) that is under a DDoS attack. Such information is sent by a DOTS client to an upstream DOTS server so that appropriate mitigation actions are undertaken on traffic deemed suspicious. The DOTS signal channel is further elaborated in [I-D.ietf-dots-signal-channel]. Boucadair & Reddy Expires January 23, 2020 [Page 3] Internet-Draft DOTS Data Channel Protocol July 2019 As for the DOTS data channel, it is used for infrequent bulk data exchange between DOTS agents to significantly improve the coordination of all the parties involved in the response to the attack. Section 2 of [I-D.ietf-dots-architecture] mentions that the DOTS data channel is used to perform the following tasks: o Creating aliases for resources for which mitigation may be requested. A DOTS client may submit to its DOTS server a collection of prefixes which it would like to refer to by an alias when requesting mitigation. The DOTS server can respond to this request with either a success or failure response (see Section 2 in [I-D.ietf-dots-architecture]). Refer to Section 6 for more details. o Policy management, which enables a DOTS client to request the installation or withdrawal of traffic filters, dropping or rate- limiting unwanted traffic, and permitting accept-listed traffic. A DOTS client is entitled to instruct filtering rules only on IP resources that belong to its domain. Sample use cases for populating drop- or accept-list filtering rules are detailed hereafter: * If a network resource (DOTS client) is informed about a potential DDoS attack from a set of IP addresses, the DOTS client informs its servicing DOTS gateway of all suspect IP addresses that need to be drop-listed for further investigation. The DOTS client could also specify a list of protocols and port numbers in the drop-list rule. The DOTS gateway then propagates the drop-listed IP addresses to a DOTS server which will undertake appropriate actions so that traffic originated by these IP addresses to the target network (specified by the DOTS client) is blocked. * A network, that has partner sites from which only legitimate traffic arrives, may want to ensure that the traffic from these sites is not subjected to DDoS attack mitigation. The DOTS client uses the DOTS data channel to convey the accept-listed IP prefixes of the partner sites to its DOTS server. The DOTS server uses this information to accept-list flows originated by such IP prefixes and which reach the network. Refer to Section 7 for more details. Boucadair & Reddy Expires January 23, 2020 [Page 4] Internet-Draft DOTS Data Channel Protocol July 2019 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] [RFC8174] when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the terms defined in [RFC8612]. The terminology for describing YANG modules is defined in [RFC7950]. The meaning of the symbols in the tree diagrams is defined in [RFC8340]. This document generalizes the notion of Access Control List (ACL) so that it is not device-specific [RFC8519]. As such, this document defines an ACL as an ordered set of rules that is used to filter traffic. Each rule is represented by an Access Control Entry (ACE). ACLs communicated via the DOTS data channel are not bound to a device interface. For the sake of simplicity, all of the examples in this document use "/restconf" as the discovered RESTCONF API root path. 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. 3. DOTS Data Channel 3.1. Design Overview Unlike the DOTS signal channel, which must remain operational even when confronted with signal degradation due to packets loss, the DOTS data channel is not expected to be fully operational at all times, especially when a DDoS attack is underway. The requirements for a DOTS data channel protocol are documented in [RFC8612]. This specification does not require an order of DOTS signal and data channel creations nor mandates a time interval between them. These considerations are implementation- and deployment-specific. As the primary function of the data channel is data exchange, a reliable transport mode is required in order for DOTS agents to detect data delivery success or failure. This document uses RESTCONF Boucadair & Reddy Expires January 23, 2020 [Page 5] Internet-Draft DOTS Data Channel Protocol July 2019 [RFC8040] over TLS over TCP as the DOTS data channel protocol. The abstract layering of DOTS data channel is shown in Figure 2. +-------------------+ | DOTS Data Channel | +-------------------+ | RESTCONF | +-------------------+ | TLS | +-------------------+ | TCP | +-------------------+ | IP | +-------------------+ Figure 2: Abstract Layering of DOTS Data Channel The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data resources represented by DOTS data channel YANG modules. These basic edit operations allow the DOTS data channel running configuration to be altered by a DOTS client. Rules for generating and processing RESTCONF methods are defined in Section 4 of [RFC8040]. DOTS data channel configuration information as well as state information can be retrieved with the GET method. An HTTP status- line is returned for each request to report success or failure for RESTCONF operations (Section 5.4 of [RFC8040]). The "error-tag" provides more information about encountered errors (Section 7 of [RFC8040]). DOTS clients perform the root resource discovery procedure discussed in Section 3.1 of [RFC8040] to determine the root of the RESTCONF API. After discovering the RESTCONF API root, a DOTS client uses this value as the initial part of the path in the request URI in any subsequent request to the DOTS server. The DOTS server may support the retrieval of the YANG modules it supports (Section 3.7 in [RFC8040]). For example, a DOTS client may use RESTCONF to retrieve the vendor-specific YANG modules supported by its DOTS server. JavaScript Object Notation (JSON) [RFC8259] payloads are used to propagate the DOTS data-channel-specific payload messages that carry request parameters and response information, such as errors. This specification uses the encoding rules defined in [RFC7951] for representing DOTS data channel configuration data using YANG (Section 4) as JSON text. A DOTS client registers itself to its DOTS server(s) in order to set up DOTS data channel-related configuration data and receive state Boucadair & Reddy Expires January 23, 2020 [Page 6] Internet-Draft DOTS Data Channel Protocol July 2019 data (i.e., non-configuration data) from the DOTS server(s) (Section 5). Mutual authentication considerations are specified in Section 8 of [I-D.ietf-dots-signal-channel]. The coupling of signal and data channels is discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel]. A DOTS client can either maintain a persistent connection or periodic connections with its DOTS server(s). If the DOTS client needs to frequently update the drop-list or accept-list filtering rules or aliases, it maintains a persistent connection with the DOTS server. For example, CAPTCHA and cryptographic puzzles can be used by the mitigation service in the DOTS client domain to determine whether the IP address is used for legitimate purpose or not, and the DOTS client can frequently update the drop-list filtering rules. A persistent connection is also useful if the DOTS client subscribes to event notifications (Section 6.3 of [RFC8040]). Additional considerations related to RESTCONF connection management (including, configuring the connection type or the reconnect strategy) can be found in [I-D.ietf-netconf-restconf-client-server]. A single DOTS data channel between DOTS agents can be used to exchange multiple requests and multiple responses. To reduce DOTS client and DOTS server workload, DOTS clients SHOULD re-use the same TLS session. While the communication to the DOTS server is quiescent, the DOTS client MAY probe the server to ensure it has maintained cryptographic state. Such probes can also keep alive firewall and/or NAT bindings. A TLS heartbeat [RFC6520] verifies that the DOTS server still has TLS state by returning a TLS message. A DOTS server may detect conflicting filtering requests from distinct DOTS clients which belong to the same domain. For example, a DOTS client could request to drop-list a prefix by specifying the source prefix, while another DOTS client could request to accept-list that same source prefix, but both having the same destination prefix. DOTS servers SHOULD support a configuration parameter to indicate the behavior to follow when a conflict is detected (e.g., reject all, reject the new request, notify an administrator for validation). Section 7.2 specifies a default behavior when no instruction is supplied to a DOTS server. How a DOTS client synchronizes its configuration with the one maintained by its DOTS server(s) is implementation-specific. For example: o a DOTS client can systematically send a GET message before and/or after a configuration change request. Boucadair & Reddy Expires January 23, 2020 [Page 7] Internet-Draft DOTS Data Channel Protocol July 2019 o a DOTS client can re-establish the disconnected DOTS session after an attack is mitigated and sends a GET message before a configuration change request. NAT considerations for the DOTS data channel are similar to those discussed in Section 3 of [I-D.ietf-dots-signal-channel]. How filtering rules that are instantiated on a DOTS server are translated into network configurations actions is out of scope of this specification. Some of the fields introduced in Section 4 are also discussed in Sections 5, 6, and 7. These sections are authoritative for these fields. 3.2. DOTS Server(s) Discovery This document assumes that DOTS clients are provisioned with a way to know how to reach their DOTS server(s), which could occur by a variety of means (e.g., local configuration, or dynamic means such as DHCP [I-D.ietf-dots-server-discovery]). The specification of such means are out of scope of this document. Likewise, it is out of scope of this document to specify the behavior to be followed by a DOTS client to send DOTS requests when multiple DOTS servers are provisioned (e.g., contact all DOTS servers, select one DOTS server among the list). 3.3. DOTS Gateways When a server-domain DOTS gateway is involved in DOTS data channel exchanges, the same considerations for manipulating the 'cdid' (client domain identifier) parameter specified in [I-D.ietf-dots-signal-channel] MUST be followed by DOTS agents. As a reminder, 'cdid' is meant to assist the DOTS server to enforce some policies (e.g., limit the number of filtering rules per DOTS client or per DOTS client domain). A loop detect mechanism for DOTS gateways is specified in Section 3.4. If a DOTS gateway is involved, the DOTS gateway verifies that the DOTS client is authorized to undertake a data channel action (e.g., instantiate filtering rules). If the DOTS client is authorized, it propagates the rules to the upstream DOTS server. Likewise, the DOTS server verifies that the DOTS gateway is authorized to relay data channel actions. For example, to create or purge filters, a DOTS client sends its request to its DOTS gateway. The DOTS gateway validates the rules in the request and proxies the requests containing the filtering rules to its DOTS server. When the DOTS Boucadair & Reddy Expires January 23, 2020 [Page 8] Internet-Draft DOTS Data Channel Protocol July 2019 gateway receives the associated response from the DOTS server, it propagates the response back to the DOTS client. 3.4. Detect and Prevent Infinite Loops In order to detect and prevent infinite loops, DOTS gateways MUST support the procedure defined in Section 5.7.1 of [RFC7230]. In particular, each intermediate DOTS gateway MUST check that none of its own information (e.g., server names, literal IP addresses) is present in the "Via" header field of a DOTS message it receives: o If it detects that its own information is present in the "Via" header field, the DOTS gateway MUST NOT forward the DOTS message. Messages that cannot be forwarded because of a loop SHOULD be logged with a "508 Loop Detected" status-line returned sent back to the DOTS peer. The structure of the reported error is depicted in Figure 3. error-app-tag: loop-detected error-tag: operation-failed error-type: transport, application error-info: : A copy of the Via header field when the loop was detected. Description: An infinite loop has been detected when forwarding a requests via a proxy. Figure 3: Loop Detected Error It is RECOMMENDED that DOTS clients and gateways support methods to alert administrators about loop errors so that appropriate actions are undertaken. o Otherwise, the DOTS agent MUST update or insert the "Via" header by appending its own information. Unless configured otherwise, DOTS gateways at the boundaries of a DOTS client domain SHOULD remove the previous "Via" header field information after checking for a loop before forwarding. This behavior is required for topology hiding purposes but can also serve to minimize potential conflicts that may arise if overlapping information is used in distinct DOTS domains (e.g., private IPv4 addresses, non globally unique aliases). Boucadair & Reddy Expires January 23, 2020 [Page 9] Internet-Draft DOTS Data Channel Protocol July 2019 3.5. Stale Entries In order to avoid stale entries, a lifetime is associated with alias and filtering entries created by DOTS clients. Also, DOTS servers may track the inactivity timeout of DOTS clients to detect stale entries. 4. DOTS Data Channel YANG Module 4.1. Generic Tree Structure The DOTS data channel YANG module (ietf-dots-data-channel) provides a method for DOTS clients to manage aliases for resources for which mitigation may be requested. Such aliases may be used in subsequent DOTS signal channel exchanges to refer more efficiently to the resources under attack. Note that the full module's tree has been split across several figures to aid the exposition of the various sub-trees. The tree structure for the DOTS alias is depicted in Figure 4. module: ietf-dots-data-channel +--rw dots-data +--rw dots-client* [cuid] | +--rw cuid string | +--rw cdid? string | +--rw aliases | | +--rw alias* [name] | | +--rw name string | | +--rw target-prefix* inet:ip-prefix | | +--rw target-port-range* [lower-port] | | | +--rw lower-port inet:port-number | | | +--rw upper-port? inet:port-number | | +--rw target-protocol* uint8 | | +--rw target-fqdn* inet:domain-name | | +--rw target-uri* inet:uri | | +--ro pending-lifetime? int32 | +--rw acls | ... +--ro capabilities ... Figure 4: DOTS Alias Subtree Also, the 'ietf-dots-data-channel' module provides a method for DOTS clients to manage filtering rules. Examples of filtering management in a DOTS context include, but not limited to: Boucadair & Reddy Expires January 23, 2020 [Page 10] Internet-Draft DOTS Data Channel Protocol July 2019 o Drop-list management, which enables a DOTS client to inform a DOTS server about sources from which traffic should be discarded. o Accept-list management, which enables a DOTS client to inform a DOTS server about sources from which traffic should always be accepted. o Policy management, which enables a DOTS client to request the installation or withdrawal of traffic filters, dropping or rate- limiting unwanted traffic and permitting accept-listed traffic. The tree structure for the DOTS filtering entries is depicted in Figure 5. Investigations into the prospect of augmenting 'ietf-access-control- list' to meet DOTS requirements concluded that such a design approach did not support many of the DOTS requirements, e.g., o Retrieve a filtering entry (or all entries) created by a DOTS client. o Delete a filtering entry that was instantiated by a DOTS client. Accordingly, new DOTS filtering entries (i.e., Access Control List (ACL)) are defined that mimic the structure specified in [RFC8519]. Concretely, DOTS agents are assumed to manipulate an ordered list of ACLs; each ACL contains a separately ordered list of Access Control Entries (ACEs). Each ACE has a group of match and a group of action criteria. Once all the ACE entries have been iterated though with no match, then all the following ACL's ACE entries are iterated through until the first match at which point the specified action is applied. If there is no match during 'idle' time (i.e., no mitigation is active), then there is no further action to be taken against the packet. If there is no match during active mitigation, then the packet will still be scrubbed by the DDoS mitigator. Boucadair & Reddy Expires January 23, 2020 [Page 11] Internet-Draft DOTS Data Channel Protocol July 2019 module: ietf-dots-data-channel +--rw dots-data +--rw dots-client* [cuid] | +--rw cuid string | +--rw cdid? string | +--rw aliases | | ... | +--rw acls | +--rw acl* [name] | +--rw name string | +--rw type? ietf-acl:acl-type | +--rw activation-type? activation-type | +--ro pending-lifetime? int32 | +--rw aces | +--rw ace* [name] | +--rw name string | +--rw matches | | +--rw (l3)? | | | +--:(ipv4) | | | | ... | | | +--:(ipv6) | | | ... | | +--rw (l4)? | | +--:(tcp) | | | ... | | +--:(udp) | | | ... | | +--:(icmp) | | ... | +--rw actions | | +--rw forwarding identityref | | +--rw rate-limit? decimal64 | +--ro statistics | +--ro matched-packets? yang:counter64 | +--ro matched-octets? yang:counter64 +--ro capabilities ... Figure 5: DOTS ACLs Subtree Filtering rules instructed by a DOTS client assumes a default direction: the destination is the DOTS client domain. DOTS forwarding actions can be 'accept' (i.e., accept matching traffic) or 'drop' (i.e., drop matching traffic without sending any ICMP error message). Accepted traffic can be subject to rate- limiting 'rate-limit'. Note that 'reject' action (i.e., drop matching traffic and send an ICMP error message to the source) is not Boucadair & Reddy Expires January 23, 2020 [Page 12] Internet-Draft DOTS Data Channel Protocol July 2019 supported in 'ietf-dots-data-channel' because it is not appropriate in the context of DDoS mitigation. Generating ICMP messages to notify drops when mitigating a DDoS attack will exacerbate the DDoS attack. Furthermore, these ICMP messages will be used by an attacker as an explicit signal that the traffic is being blocked. 4.2. Filtering Fields The 'ietf-dots-data-channel' module reuses the packet fields module 'ietf-packet-fields' [RFC8519] which defines matching on fields in the packet including IPv4, IPv6, and transport layer fields. The 'ietf-dots-data-channel' module can be augmented, for example, to support additional protocol-specific matching fields. This specification defines a new IPv4/IPv6 matching field called 'fragment' to efficiently handle fragment-related filtering rules. Indeed, [RFC8519] does not support such capability for IPv6 but offers a partial support for IPv4 by means of 'flags'. Nevertheless, the use of 'flags' is problematic since it does not allow to define a bitmask. For example, setting other bits not covered by the 'flags' filtering clause in a packet will allow that packet to get through (because it won't match the ACE). Sample examples to illustrate how 'fragment' can be used are provided in Appendix A. Figure 6 shows the IPv4 match subtree. Boucadair & Reddy Expires January 23, 2020 [Page 13] Internet-Draft DOTS Data Channel Protocol July 2019 module: ietf-dots-data-channel +--rw dots-data +--rw dots-client* [cuid] | ... | +--rw acls | +--rw acl* [name] | ... | +--rw aces | +--rw ace* [name] | +--rw name string | +--rw matches | | +--rw (l3)? | | | +--:(ipv4) | | | | +--rw ipv4 | | | | +--rw dscp? inet:dscp | | | | +--rw ecn? uint8 | | | | +--rw length? uint16 | | | | +--rw ttl? uint8 | | | | +--rw protocol? uint8 | | | | +--rw ihl? uint8 | | | | +--rw flags? bits | | | | +--rw offset? uint16 | | | | +--rw identification? uint16 | | | | +--rw (destination-network)? | | | | | +--:(destination-ipv4-network) | | | | | +--rw destination-ipv4-network? | | | | | inet:ipv4-prefix | | | | +--rw (source-network)? | | | | | +--:(source-ipv4-network) | | | | | +--rw source-ipv4-network? | | | | | inet:ipv4-prefix | | | | +--rw fragment | | | | +--rw operator? operator | | | | +--rw type fragment-type | | | +--:(ipv6) | | | ... | | +--rw (l4)? | | ... | +--rw actions | | ... | +--ro statistics | ... +--ro capabilities ... Figure 6: DOTS ACLs Subtree (IPv4 Match) Figure 7 shows the IPv6 match subtree. Boucadair & Reddy Expires January 23, 2020 [Page 14] Internet-Draft DOTS Data Channel Protocol July 2019 module: ietf-dots-data-channel +--rw dots-data +--rw dots-client* [cuid] | ... | +--rw acls | +--rw acl* [name] | ... | +--rw aces | +--rw ace* [name] | +--rw name string | +--rw matches | | +--rw (l3)? | | | +--:(ipv4) | | | | ... | | | +--:(ipv6) | | | +--rw ipv6 | | | +--rw dscp? inet:dscp | | | +--rw ecn? uint8 | | | +--rw length? uint16 | | | +--rw ttl? uint8 | | | +--rw protocol? uint8 | | | +--rw (destination-network)? | | | | +--:(destination-ipv6-network) | | | | +--rw destination-ipv6-network? | | | | inet:ipv6-prefix | | | +--rw (source-network)? | | | | +--:(source-ipv6-network) | | | | +--rw source-ipv6-network? | | | | inet:ipv6-prefix | | | +--rw flow-label? | | | | inet:ipv6-flow-label | | | +--rw fragment | | | +--rw operator? operator | | | +--rw type fragment-type | | +--rw (l4)? | | ... | +--rw actions | | ... | +--ro statistics | ... +--ro capabilities ... Figure 7: DOTS ACLs Subtree (IPv6 Match) Figure 8 shows the TCP match subtree. In addition to the fields defined in [RFC8519], this specification defines a new TCP matching Boucadair & Reddy Expires January 23, 2020 [Page 15] Internet-Draft DOTS Data Channel Protocol July 2019 field, called 'flags-bitmask', to efficiently handle TCP flags filtering rules. Some examples are provided in Appendix B. module: ietf-dots-data-channel +--rw dots-data +-rw dots-client* [cuid] | ... | +-rw acls | +-rw acl* [name] | ... | +-rw aces | +-rw ace* [name] | +-rw name string | +-rw matches | | +-rw (l3)? | | | ... | | +-rw (l4)? | | +-:(tcp) | | | +-rw tcp | | | +--rw sequence-number? uint32 | | | +--rw acknowledgement-number? uint32 | | | +--rw data-offset? uint8 | | | +--rw reserved? uint8 | | | +--rw flags? bits | | | +--rw window-size? uint16 | | | +--rw urgent-pointer? uint16 | | | +--rw options? binary | | | +--rw flags-bitmask | | | | +--rw operator? operator | | | | +--rw bitmask uint16 | | | +--rw (source-port)? | | | | +--:(source-port-range-or-operator) | | | | +--rw source-port-range-or-operator | | | | +--rw (port-range-or-operator)? | | | | +--:(range) | | | | | +--rw lower-port | | | | | | inet:port-number | | | | | +--rw upper-port | | | | | inet:port-number | | | | +--:(operator) | | | | +--rw operator? | | | | | operator | | | | +--rw port | | | | inet:port-number | | | +--rw (destination-port)? | | | +--:(destination-port-range-or-operator) | | | +--rw destination-port-range-or-operator | | | +--rw (port-range-or-operator)? Boucadair & Reddy Expires January 23, 2020 [Page 16] Internet-Draft DOTS Data Channel Protocol July 2019 | | | +--:(range) | | | | +--rw lower-port | | | | | inet:port-number | | | | +--rw upper-port | | | | inet:port-number | | | +--:(operator) | | | +--rw operator? | | | | operator | | | +--rw port | | | inet:port-number | | +-:(udp) | | | ... | | +-:(icmp) | | ... | +-rw actions | | ... | +-ro statistics | ... +-ro capabilities ... Figure 8: DOTS ACLs Subtree (TCP Match) Figure 9 shows the UDP and ICMP match subtrees. The same structure is used for both ICMP and ICMPv6. The indication whether an ACL is about ICMP or ICMPv6 is governed by the 'l3' match or the ACL type. module: ietf-dots-data-channel +-rw dots-data +-rw dots-client* [cuid] | ... | +-rw acls | +-rw acl* [name] | ... | +-rw aces | +-rw ace* [name] | +--rw name string | +--rw matches | | +--rw (l3)? | | | ... | | +--rw (l4)? | | +--:(tcp) | | | ... | | +--:(udp) | | | +--rw udp | | | +--rw length? uint16 | | | +--rw (source-port)? | | | | +--:(source-port-range-or-operator) Boucadair & Reddy Expires January 23, 2020 [Page 17] Internet-Draft DOTS Data Channel Protocol July 2019 | | | | +--rw source-port-range-or-operator | | | | +--rw (port-range-or-operator)? | | | | +--:(range) | | | | | +--rw lower-port | | | | | | inet:port-number | | | | | +--rw upper-port | | | | | inet:port-number | | | | +--:(operator) | | | | +--rw operator? | | | | | operator | | | | +--rw port | | | | inet:port-number | | | +--rw (destination-port)? | | | +--:(destination-port-range-or-operator) | | | +--rw destination-port-range-or-operator | | | +--rw (port-range-or-operator)? | | | +--:(range) | | | | +--rw lower-port | | | | | inet:port-number | | | | +--rw upper-port | | | | inet:port-number | | | +--:(operator) | | | +--rw operator? | | | | operator | | | +--rw port | | | inet:port-number | | +--:(icmp) | | +--rw icmp | | +--rw type? uint8 | | +--rw code? uint8 | | +--rw rest-of-header? binary | +--rw actions | | ... | +--ro statistics | ... +-ro capabilities ... Figure 9: DOTS ACLs Subtree (UDP and ICMP Match) DOTS implementations MUST support the following matching criteria: match based on the IP header (IPv4 and IPv6), match based on the transport header (TCP, UDP, and ICMP), and any combination thereof. The same matching fields are used for both ICMP and ICMPv6. Boucadair & Reddy Expires January 23, 2020 [Page 18] Internet-Draft DOTS Data Channel Protocol July 2019 The following match fields MUST be supported by DOTS implementations (Table 1): ACL Mandatory Fields Match ------- ------------------------------------------------------------- ipv4 length, protocol, destination-ipv4-network, source- ipv4-network, and fragment ipv6 length, protocol, destination-ipv6-network, source- ipv6-network, and fragment tcp flags-bitmask, source-port-range-or-operator, and destination-port-range-or-operator udp length, source-port-range-or-operator, and destination-port- range-or-operator icmp type and code Table 1: Mandatory DOTS Channel Match Fields Implementations MAY support other filtering match fields and actions. The 'ietf-dots-data-channel' provides a method for an implementation to expose its filtering capabilities. The tree structure of the 'capabilities' is shown in Figure 10. DOTS clients that support both 'fragment' and 'flags' (or 'flags-bitmask' and 'flags') matching fields MUST NOT set these fields in the same request. module: ietf-dots-data-channel +--rw dots-data ... +--ro capabilities +--ro address-family* enumeration +--ro forwarding-actions* identityref +--ro rate-limit? boolean +--ro transport-protocols* uint8 +--ro ipv4 | +--ro dscp? boolean | +--ro ecn? boolean | +--ro length? boolean | +--ro ttl? boolean | +--ro protocol? boolean | +--ro ihl? boolean | +--ro flags? boolean | +--ro offset? boolean | +--ro identification? boolean | +--ro source-prefix? boolean | +--ro destination-prefix? boolean | +--ro fragment? boolean +--ro ipv6 | +--ro dscp? boolean Boucadair & Reddy Expires January 23, 2020 [Page 19] Internet-Draft DOTS Data Channel Protocol July 2019 | +--ro ecn? boolean | +--ro length? boolean | +--ro hoplimit? boolean | +--ro protocol? boolean | +--ro destination-prefix? boolean | +--ro source-prefix? boolean | +--ro flow-label? boolean | +--ro fragment? boolean +--ro tcp | +--ro sequence-number? boolean | +--ro acknowledgement-number? boolean | +--ro data-offset? boolean | +--ro reserved? boolean | +--ro flags? boolean | +--ro window-size? boolean | +--ro urgent-pointer? boolean | +--ro options? boolean | +--ro flags-bitmask? boolean | +--ro source-port? boolean | +--ro destination-port? boolean | +--ro port-range? boolean +--ro udp | +--ro length? boolean | +--ro source-port? boolean | +--ro destination-port? boolean | +--ro port-range? boolean +--ro icmp +--ro type? boolean +--ro code? boolean +--ro rest-of-header? boolean Figure 10: Filtering Capabilities Subtree 4.3. YANG Module This module uses the common YANG types defined in [RFC6991] and types defined in [RFC8519]. file "ietf-dots-data-channel@2019-05-09.yang" module ietf-dots-data-channel { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-data-channel"; prefix data-channel; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } Boucadair & Reddy Expires January 23, 2020 [Page 20] Internet-Draft DOTS Data Channel Protocol July 2019 import ietf-access-control-list { prefix ietf-acl; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } import ietf-packet-fields { prefix packet-fields; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; contact "WG Web: WG List: Editor: Mohamed Boucadair Editor: Konda, Tirumaleswar Reddy Author: Jon Shallow Author: Kaname Nishizuka Author: Liang Xia Author: Prashanth Patil Author: Andrew Mortensen Author: Nik Teague "; description "This module contains YANG definition for configuring aliases for resources and filtering rules using DOTS data channel. Copyright (c) 2019 IETF Trust and the persons identified as Boucadair & Reddy Expires January 23, 2020 [Page 21] Internet-Draft DOTS Data Channel Protocol July 2019 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."; revision 2019-05-09 { description "Initial revision."; reference "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; } typedef activation-type { type enumeration { enum "activate-when-mitigating" { value 1; description "The Access Control List (ACL) is installed only when a mitigation is active for the DOTS client."; } enum "immediate" { value 2; description "The ACL is immediately activated."; } enum "deactivate" { value 3; description "The ACL is maintained by the DOTS server, but it is deactivated."; } } description "Indicates the activation type of an ACL."; } typedef operator { type bits { bit not { position 0; Boucadair & Reddy Expires January 23, 2020 [Page 22] Internet-Draft DOTS Data Channel Protocol July 2019 description "If set, logical negation of operation."; } bit match { position 1; description "Match bit. This is a bitwise match operation defined as '(data & value) == value'."; } bit any { position 3; description "Any bit. This is a match on any of the bits in bitmask. It evaluates to 'true' if any of the bits in the value mask are set in the data, i.e., '(data & value) != 0'."; } } description "Specifies how to apply the defined bitmask."; } grouping tcp-flags { leaf operator { type operator; default "match"; description "Specifies how to interpret the TCP flags."; } leaf bitmask { type uint16; mandatory true; description "The bitmask matches the last 4 bits of byte 12 and byte 13 of the TCP header. For clarity, the 4 bits of byte 12 corresponding to the TCP data offset field are not included in any matching."; } description "Operations on TCP flags."; } typedef fragment-type { type bits { bit df { position 0; description "Don't fragment bit for IPv4. Boucadair & Reddy Expires January 23, 2020 [Page 23] Internet-Draft DOTS Data Channel Protocol July 2019 Must be set to 0 when it appears in an IPv6 filter."; } bit isf { position 1; description "Is a fragment."; } bit ff { position 2; description "First fragment."; } bit lf { position 3; description "Last fragment."; } } description "Different fragment types to match against."; } grouping target { description "Specifies the targets of the mitigation request."; leaf-list target-prefix { type inet:ip-prefix; description "IPv4 or IPv6 prefix identifying the target."; } list target-port-range { key "lower-port"; description "Port range. When only lower-port is present, it represents a single port number."; leaf lower-port { type inet:port-number; mandatory true; description "Lower port number of the port range."; } leaf upper-port { type inet:port-number; must '. >= ../lower-port' { error-message "The upper port number must be greater than or equal to the lower-port number."; } Boucadair & Reddy Expires January 23, 2020 [Page 24] Internet-Draft DOTS Data Channel Protocol July 2019 description "Upper port number of the port range."; } } leaf-list target-protocol { type uint8; description "Identifies the target protocol number. Values are taken from the IANA protocol registry: https://www.iana.org/assignments/protocol-numbers/ protocol-numbers.xhtml For example, 6 for TCP or 17 for UDP."; } leaf-list target-fqdn { type inet:domain-name; description "FQDN identifying the target."; } leaf-list target-uri { type inet:uri; description "URI identifying the target."; } } grouping fragment-fields { leaf operator { type operator; default "match"; description "Specifies how to interpret the fragment type."; } leaf type { type fragment-type; mandatory true; description "Indicates what fragment type to look for."; } description "Operations on fragment types."; } grouping aliases { description "Top level container for aliases."; list alias { Boucadair & Reddy Expires January 23, 2020 [Page 25] Internet-Draft DOTS Data Channel Protocol July 2019 key "name"; description "List of aliases."; leaf name { type string; description "The name of the alias."; } uses target; leaf pending-lifetime { type int32; units "minutes"; config false; description "Indicates the pending validity lifetime of the alias entry."; } } } grouping ports { choice source-port { container source-port-range-or-operator { uses packet-fields:port-range-or-operator; description "Source port definition."; } description "Choice of specifying the source port or referring to a group of source port numbers."; } choice destination-port { container destination-port-range-or-operator { uses packet-fields:port-range-or-operator; description "Destination port definition."; } description "Choice of specifying a destination port or referring to a group of destination port numbers."; } description "Choice of specifying a source or destination port numbers."; } grouping access-lists { description "Specifies the ordered set of Access Control Lists."; Boucadair & Reddy Expires January 23, 2020 [Page 26] Internet-Draft DOTS Data Channel Protocol July 2019 list acl { key "name"; ordered-by user; description "An ACL is an ordered list of Access Control Entries (ACE). Each ACE has a list of match criteria and a list of actions."; leaf name { type string { length "1..64"; } description "The name of the access list."; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } leaf type { type ietf-acl:acl-type; description "Type of access control list. Indicates the primary intended type of match criteria (e.g., IPv4, IPv6) used in the list instance."; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } leaf activation-type { type activation-type; default "activate-when-mitigating"; description "Indicates the activation type of an ACL. An ACL can be deactivated, installed immediately, or installed when a mitigation is active."; } leaf pending-lifetime { type int32; units "minutes"; config false; description "Indicates the pending validity lifetime of the ACL entry."; } container aces { description "The Access Control Entries container contains a list of ACEs."; list ace { key "name"; Boucadair & Reddy Expires January 23, 2020 [Page 27] Internet-Draft DOTS Data Channel Protocol July 2019 ordered-by user; description "List of access list entries."; leaf name { type string { length "1..64"; } description "A unique name identifying this ACE."; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } container matches { description "The rules in this set determine what fields will be matched upon before any action is taken on them. If no matches are defined in a particular container, then any packet will match that container. If no matches are specified at all in an ACE, then any packet will match the ACE."; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; choice l3 { container ipv4 { when "derived-from(../../../../type, " + "'ietf-acl:ipv4-acl-type')"; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; container fragment { description "Indicates how to handle IPv4 fragments."; uses fragment-fields; } description "Rule set that matches IPv4 header."; } container ipv6 { when "derived-from(../../../../type, " + "'ietf-acl:ipv6-acl-type')"; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv6-header-fields; container fragment { description "Indicates how to handle IPv6 fragments."; Boucadair & Reddy Expires January 23, 2020 [Page 28] Internet-Draft DOTS Data Channel Protocol July 2019 uses fragment-fields; } description "Rule set that matches IPv6 header."; } description "Either IPv4 or IPv6."; } choice l4 { container tcp { uses packet-fields:acl-tcp-header-fields; container flags-bitmask { description "Indicates how to handle TCP flags."; uses tcp-flags; } uses ports; description "Rule set that matches TCP header."; } container udp { uses packet-fields:acl-udp-header-fields; uses ports; description "Rule set that matches UDP header."; } container icmp { uses packet-fields:acl-icmp-header-fields; description "Rule set that matches ICMP/ICMPv6 header."; } description "Can be TCP, UDP, or ICMP/ICMPv6"; } } container actions { description "Definitions of action for this ACE."; leaf forwarding { type identityref { base ietf-acl:forwarding-action; } mandatory true; description "Specifies the forwarding action per ACE."; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; Boucadair & Reddy Expires January 23, 2020 [Page 29] Internet-Draft DOTS Data Channel Protocol July 2019 } leaf rate-limit { when "../forwarding = 'ietf-acl:accept'" { description "Rate-limit is valid only when accept action is used."; } type decimal64 { fraction-digits 2; } units "bytes per second"; description "Specifies how to rate-limit the traffic."; } } container statistics { config false; description "Aggregate statistics."; uses ietf-acl:acl-counters; } } } } } container dots-data { description "Main container for DOTS data channel."; list dots-client { key "cuid"; description "List of DOTS clients."; leaf cuid { type string; description "A unique identifier that is generated by a DOTS client to prevent request collisions."; reference "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } leaf cdid { type string; description "A client domain identifier conveyed by a server-domain DOTS gateway to a remote DOTS server."; reference Boucadair & Reddy Expires January 23, 2020 [Page 30] Internet-Draft DOTS Data Channel Protocol July 2019 "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } container aliases { description "Set of aliases that are bound to a DOTS client."; uses aliases; } container acls { description "Access lists that are bound to a DOTS client."; uses access-lists; } } container capabilities { config false; description "Match capabilities"; leaf-list address-family { type enumeration { enum "ipv4" { description "IPv4 is supported."; } enum "ipv6" { description "IPv6 is supported."; } } description "Indicates the IP address families supported by the DOTS server."; } leaf-list forwarding-actions { type identityref { base ietf-acl:forwarding-action; } description "Supported forwarding action(s)."; } leaf rate-limit { type boolean; description "Support of rate-limit action."; } leaf-list transport-protocols { type uint8; description Boucadair & Reddy Expires January 23, 2020 [Page 31] Internet-Draft DOTS Data Channel Protocol July 2019 "Upper-layer protocol associated with a filtering rule. Values are taken from the IANA protocol registry: https://www.iana.org/assignments/protocol-numbers/ protocol-numbers.xhtml For example, this field contains 1 for ICMP, 6 for TCP 17 for UDP, or 58 for ICMPv6."; } container ipv4 { description "Indicates IPv4 header fields that are supported to enforce ACLs."; leaf dscp { type boolean; description "Support of filtering based on Differentiated Services Code Point (DSCP)."; } leaf ecn { type boolean; description "Support of filtering based on Explicit Congestion Notification (ECN)."; } leaf length { type boolean; description "Support of filtering based on the Total Length."; } leaf ttl { type boolean; description "Support of filtering based on the Time to Live (TTL)."; } leaf protocol { type boolean; description "Support of filtering based on protocol field."; } leaf ihl { type boolean; description "Support of filtering based on the Internet Header Length (IHL)."; } leaf flags { type boolean; Boucadair & Reddy Expires January 23, 2020 [Page 32] Internet-Draft DOTS Data Channel Protocol July 2019 description "Support of filtering based on the 'flags'."; } leaf offset { type boolean; description "Support of filtering based on the 'offset'."; } leaf identification { type boolean; description "Support of filtering based on the 'identification'."; } leaf source-prefix { type boolean; description "Support of filtering based on the source prefix."; } leaf destination-prefix { type boolean; description "Support of filtering based on the destination prefix."; } leaf fragment { type boolean; description "Indicates the capability of a DOTS server to enforce filters on IPv4 fragments. That is, the match functionality based on the Layer 3 'fragment' clause is supported."; } } container ipv6 { description "Indicates IPv6 header fields that are supported to enforce ACLs."; leaf dscp { type boolean; description "Support of filtering based on DSCP."; } leaf ecn { type boolean; description "Support of filtering based on ECN."; } leaf length { type boolean; Boucadair & Reddy Expires January 23, 2020 [Page 33] Internet-Draft DOTS Data Channel Protocol July 2019 description "Support of filtering based on the Payload Length."; } leaf hoplimit { type boolean; description "Support of filtering based on the Hop Limit."; } leaf protocol { type boolean; description "Support of filtering based on the Next Header field."; } leaf destination-prefix { type boolean; description "Support of filtering based on the destination prefix."; } leaf source-prefix { type boolean; description "Support of filtering based on the source prefix."; } leaf flow-label { type boolean; description "Support of filtering based on the Flow label."; } leaf fragment { type boolean; description "Indicates the capability of a DOTS server to enforce filters on IPv6 fragments."; } } container tcp { description "Set of TCP fields that are supported by the DOTS server to enforce filters."; leaf sequence-number { type boolean; description "Support of filtering based on the TCP sequence number."; } leaf acknowledgement-number { type boolean; description "Support of filtering based on the TCP acknowledgement Boucadair & Reddy Expires January 23, 2020 [Page 34] Internet-Draft DOTS Data Channel Protocol July 2019 number."; } leaf data-offset { type boolean; description "Support of filtering based on the TCP data-offset."; } leaf reserved { type boolean; description "Support of filtering based on the TCP reserved field."; } leaf flags { type boolean; description "Support of filtering, as defined in RFC 8519, based on the TCP flags."; } leaf window-size { type boolean; description "Support of filtering based on the TCP window size."; } leaf urgent-pointer { type boolean; description "Support of filtering based on the TCP urgent pointer."; } leaf options { type boolean; description "Support of filtering based on the TCP options."; } leaf flags-bitmask { type boolean; description "Support of filtering based on the TCP flags bitmask."; } leaf source-port { type boolean; description "Support of filtering based on the source port number."; } leaf destination-port { type boolean; description "Support of filtering based on the destination port number."; Boucadair & Reddy Expires January 23, 2020 [Page 35] Internet-Draft DOTS Data Channel Protocol July 2019 } leaf port-range { type boolean; description "Support of filtering based on a port range. This includes filtering based on a source port range, destination port range, or both. All operators (i.e, less than or equal to, greater than or equal to, equal to, and not equal to) are supported."; } } container udp { description "Set of UDP fields that are supported by the DOTS server to enforce filters."; leaf length { type boolean; description "Support of filtering based on the UDP length."; } leaf source-port { type boolean; description "Support of filtering based on the source port number."; } leaf destination-port { type boolean; description "Support of filtering based on the destination port number."; } leaf port-range { type boolean; description "Support of filtering based on a port range. This includes filtering based on a source port range, destination port range, or both. All operators (i.e, less than or equal, greater than or equal, equal to, and not equal to) are supported."; } } container icmp { description "Set of ICMP/ICMPv6 fields that are supported by the DOTS server to enforce filters."; leaf type { Boucadair & Reddy Expires January 23, 2020 [Page 36] Internet-Draft DOTS Data Channel Protocol July 2019 type boolean; description "Support of filtering based on the ICMP/ICMPv6 type."; } leaf code { type boolean; description "Support of filtering based on the ICMP/ICMPv6 code."; } leaf rest-of-header { type boolean; description "Support of filtering based on the ICMP four-bytes field / the ICMPv6 message body."; } } } } } 5. Managing DOTS Clients 5.1. Registering DOTS Clients In order to make use of DOTS data channel, a DOTS client MUST register to its DOTS server(s) by creating a DOTS client ('dots- client') resource. To that aim, DOTS clients SHOULD send a POST request (shown in Figure 11). POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:dots-client": [ { "cuid": "string" } ] } Figure 11: POST to Register Schema The 'cuid' (client unique identifier) parameter is described below: cuid: A globally unique identifier that is meant to prevent collisions among DOTS clients. This attribute has the same Boucadair & Reddy Expires January 23, 2020 [Page 37] Internet-Draft DOTS Data Channel Protocol July 2019 meaning, syntax, and processing rules as the 'cuid' attribute defined in [I-D.ietf-dots-signal-channel]. DOTS clients MUST use the same 'cuid' for both signal and data channels. This is a mandatory attribute. In deployments where server-domain DOTS gateways are enabled, identity information about the origin source client domain SHOULD be supplied to the DOTS server. That information is meant to assist the DOTS server to enforce some policies. These policies can be enforced per-client, per-client domain, or both. Figure 12 shows a schema example of a request relayed by a server-domain DOTS gateway. POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:dots-client": [ { "cuid": "string", "cdid": "string" } ] } Figure 12: POST to Register Schema (via a Server-Domain DOTS Gateway) A server-domain DOTS gateway SHOULD add the following attribute: cdid: This attribute has the same meaning, syntax, and processing rules as the 'cdid' attribute defined in [I-D.ietf-dots-signal-channel]. In deployments where server-domain DOTS gateways are enabled, 'cdid' does not need to be inserted when relaying DOTS methods to manage aliases (Section 6) or filtering rules (Section 7). DOTS servers are responsible for maintaining the association between 'cdid' and 'cuid' for policy enforcement purposes. This is an optional attribute. A request example to create a 'dots-client' resource is depicted in Figure 13. This request is relayed by a server-domain DOTS gateway as hinted by the presence of the 'cdid' attribute. Boucadair & Reddy Expires January 23, 2020 [Page 38] Internet-Draft DOTS Data Channel Protocol July 2019 POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:dots-client": [ { "cuid": "dz6pHjaADkaFTbjr0JGBpw", "cdid": "7eeaf349529eb55ed50113" } ] } Figure 13: POST to Register (DOTS gateway) As a reminder, DOTS gateways may rewrite the 'cuid' used by peer DOTS clients (Section 4.4.1 of [I-D.ietf-dots-signal-channel]). DOTS servers can identify the DOTS client domain using the 'cdid' parameter or using the client's DNS name specified in the Subject Alternative Name extension's dNSName type in the client certificate [RFC6125]. DOTS servers MUST limit the number of 'dots-client' resources to be created by the same DOTS client to 1 per request. Requests with multiple 'dots-client' resources MUST be rejected by DOTS servers. To that aim, the DOTS server MUST rely on the same procedure to unambiguously identify a DOTS client as discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel]. The DOTS server indicates the result of processing the POST request using status-line codes. Status codes in the range "2xx" codes are success, "4xx" codes are some sort of invalid requests and "5xx" codes are returned if the DOTS server has erred or is incapable of accepting the creation of the 'dots-client' resource. In particular, o "201 Created" status-line is returned in the response, if the DOTS server has accepted the request. o "400 Bad Request" status-line is returned by the DOTS server, if the request does not include a 'cuid' parameter. The error-tag "missing-attribute" is used in this case. o "409 Conflict" status-line is returned to the requesting DOTS client, if the data resource already exists. The error-tag "resource-denied" is used in this case. Boucadair & Reddy Expires January 23, 2020 [Page 39] Internet-Draft DOTS Data Channel Protocol July 2019 Once a DOTS client registers itself to a DOTS server, it can create/delete/retrieve aliases (Section 6) and filtering rules (Section 7). A DOTS client MAY use the PUT request (Section 4.5 in [RFC8040]) to register a DOTS client within the DOTS server. An example is shown in Figure 14. PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:dots-client": [ { "cuid": "dz6pHjaADkaFTbjr0JGBpw" } ] } Figure 14: PUT to Register The DOTS gateway that inserted a 'cdid' in a PUT request MUST strip the 'cdid' parameter in the corresponding response before forwarding the response to the DOTS client. 5.2. Unregistering DOTS Clients A DOTS client de-registers from its DOTS server(s) by deleting the 'cuid' resource(s). Resources bound to this DOTS client will be deleted by the DOTS server. An example of a de-register request is shown in Figure 15. DELETE /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 Host: example.com Figure 15: De-register a DOTS Client 6. Managing DOTS Aliases The following sub-sections define means for a DOTS client to create aliases (Section 6.1), retrieve one or a list of aliases (Section 6.2), and delete an alias (Section 6.3). Boucadair & Reddy Expires January 23, 2020 [Page 40] Internet-Draft DOTS Data Channel Protocol July 2019 6.1. Create Aliases A POST or PUT request is used by a DOTS client to create aliases, for resources for which a mitigation may be requested. Such aliases may be used in subsequent DOTS signal channel exchanges to refer more efficiently to the resources under attack. DOTS clients within the same domain can create different aliases for the same resource. The structure of POST requests used to create aliases is shown in Figure 16. POST /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=cuid HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:aliases": { "alias": [ { "name": "string", "target-prefix": [ "string" ], "target-port-range": [ { "lower-port": integer, "upper-port": integer } ], "target-protocol": [ integer ], "target-fqdn": [ "string" ], "target-uri": [ "string" ] } ] } } Figure 16: POST to Create Aliases (Request Schema) Boucadair & Reddy Expires January 23, 2020 [Page 41] Internet-Draft DOTS Data Channel Protocol July 2019 The parameters are described below: name: Name of the alias. This is a mandatory attribute. target-prefix: Prefixes are separated by commas. Prefixes are represented using Classless Inter-domain Routing (CIDR) notation [RFC4632]. As a reminder, the prefix length must be less than or equal to 32 (resp. 128) for IPv4 (resp. IPv6). The prefix list MUST NOT include broadcast, loopback, or multicast addresses. These addresses are considered as invalid values. In addition, the DOTS server MUST validate that these prefixes are within the scope of the DOTS client domain. Other validation checks may be supported by DOTS servers. This is an optional attribute. target-port-range: A range of port numbers. The port range is defined by two bounds, a lower port number (lower-port) and an upper port number (upper-port). The range is considered to include both the lower and upper bounds. When only 'lower-port' is present, it represents a single port number. For TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], or Datagram Congestion Control Protocol (DCCP) [RFC4340], the range of port numbers can be, for example, 1024-65535. This is an optional attribute. target-protocol: A list of protocols. Values are taken from the IANA protocol registry [proto_numbers]. If 'target-protocol' is not specified, then the request applies to any protocol. This is an optional attribute. target-fqdn: A list of Fully Qualified Domain Names (FQDNs) identifying resources under attack [RFC8499]. How a name is passed to an underlying name resolution library is implementation- and deployment-specific. Nevertheless, once the Boucadair & Reddy Expires January 23, 2020 [Page 42] Internet-Draft DOTS Data Channel Protocol July 2019 name is resolved into one or multiple IP addresses, DOTS servers MUST apply the same validation checks as those for 'target- prefix'. The use of FQDNs may be suboptimal because it does not guarantee that the DOTS server will resolve a name to the same IP addresses that the DOTS client does. This is an optional attribute. target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986]. The same validation checks used for 'target-fqdn' MUST be followed by DOTS servers to validate a target URI. This is an optional attribute. In POST or PUT requests, at least one of the 'target-prefix', 'target-fqdn', or 'target-uri' attributes MUST be present. DOTS agents can safely ignore Vendor-Specific parameters they don't understand. If more than one 'target-*' scope types (e.g., 'target-prefix' and 'target-fqdn' or 'target-fqdn' and 'target-uri') are included in a POST or PUT request, the DOTS server binds all resulting IP addresses/prefixes to the same resource. Figure 17 shows a POST request to create an alias called "https1" for HTTPS servers with IP addresses 2001:db8:6401::1 and 2001:db8:6401::2 listening on TCP port number 443. Boucadair & Reddy Expires January 23, 2020 [Page 43] Internet-Draft DOTS Data Channel Protocol July 2019 POST /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 Host: www.example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:aliases": { "alias": [ { "name": "https1", "target-protocol": [ 6 ], "target-prefix": [ "2001:db8:6401::1/128", "2001:db8:6401::2/128" ], "target-port-range": [ { "lower-port": 443 } ] } ] } } Figure 17: Example of a POST to Create an Alias "201 Created" status-line MUST be returned in the response if the DOTS server has accepted the alias. "409 Conflict" status-line MUST be returned to the requesting DOTS client, if the request is conflicting with an existing alias name. The error-tag "resource-denied" is used in this case. If the request is missing a mandatory attribute or it contains an invalid or unknown parameter, "400 Bad Request" status-line MUST be returned by the DOTS server. The error-tag is set to "missing- attribute", "invalid-value", or "unknown-element" as a function of the encountered error. If the request is received via a server-domain DOTS gateway, but the DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' is expected to be supplied, the DOTS server MUST reply with "403 Forbidden" status-line and the error-tag "access-denied". Upon receipt of this message, the DOTS client MUST register (Section 5). Boucadair & Reddy Expires January 23, 2020 [Page 44] Internet-Draft DOTS Data Channel Protocol July 2019 A DOTS client uses the PUT request to modify the aliases in the DOTS server. In particular, a DOTS client MUST update its alias entries upon change of the prefix indicated in the 'target-prefix'. A DOTS server MUST maintain an alias for at least 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. 6.2. Retrieve Installed Aliases A GET request is used to retrieve one or all installed aliases by a DOTS client from a DOTS server (Section 3.3.1 in [RFC8040]). If no 'name' is included in the request, this is an indication that the request is about retrieving all aliases instantiated by the DOTS client. Figure 18 shows an example to retrieve all the aliases that were instantiated by the requesting DOTS client. The "content" query parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\ /aliases?content=all HTTP/1.1 Host: example.com Accept: application/yang-data+json Figure 18: GET to Retrieve All Installed Aliases Figure 19 shows an example of the response message body that includes all the aliases that are maintained by the DOTS server for the DOTS client identified by the 'cuid' parameter. Boucadair & Reddy Expires January 23, 2020 [Page 45] Internet-Draft DOTS Data Channel Protocol July 2019 { "ietf-dots-data-channel:aliases": { "alias": [ { "name": "Server1", "target-protocol": [ 6 ], "target-prefix": [ "2001:db8:6401::1/128", "2001:db8:6401::2/128" ], "target-port-range": [ { "lower-port": 443 } ], "pending-lifetime": 3596 }, { "name": "Server2", "target-protocol": [ 6 ], "target-prefix": [ "2001:db8:6401::10/128", "2001:db8:6401::20/128" ], "target-port-range": [ { "lower-port": 80 } ], "pending-lifetime": 9869 } ] } } Figure 19: An Example of Response Body Listing All Installed Aliases Figure 20 shows an example of a GET request to retrieve the alias "Server2" that was instantiated by the DOTS client. Boucadair & Reddy Expires January 23, 2020 [Page 46] Internet-Draft DOTS Data Channel Protocol July 2019 GET /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\ /aliases/alias=Server2?content=all HTTP/1.1 Host: example.com Accept: application/yang-data+json Figure 20: GET to Retrieve an Alias If an alias name ('name') is included in the request, but the DOTS server does not find that alias name for this DOTS client in its configuration data, it MUST respond with a "404 Not Found" status- line. 6.3. Delete Aliases A DELETE request is used to delete an alias maintained by a DOTS server. If the DOTS server does not find the alias name, conveyed in the DELETE request, in its configuration data for this DOTS client, it MUST respond with a "404 Not Found" status-line. The DOTS server successfully acknowledges a DOTS client's request to remove the alias using "204 No Content" status-line in the response. Figure 21 shows an example of a request to delete an alias. DELETE /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\ /aliases/alias=Server1 HTTP/1.1 Host: example.com Figure 21: Delete an Alias 7. Managing DOTS Filtering Rules The following sub-sections define means for a DOTS client to retrieve DOTS filtering capabilities (Section 7.1), create filtering rules (Section 7.2), retrieve active filtering rules (Section 7.3), and delete a filtering rule (Section 7.4). 7.1. Retrieve DOTS Filtering Capabilities A DOTS client MAY send a GET request to retrieve the filtering capabilities supported by a DOTS server. Figure 22 shows an example of such request. Boucadair & Reddy Expires January 23, 2020 [Page 47] Internet-Draft DOTS Data Channel Protocol July 2019 GET /restconf/data/ietf-dots-data-channel:dots-data\ /capabilities HTTP/1.1 Host: example.com Accept: application/yang-data+json Figure 22: GET to Retrieve the Capabilities of a DOTS Server A DOTS client which issued a GET request to retrieve the filtering capabilities supported by its DOTS server, SHOULD NOT request for filtering actions that are not supported by that DOTS server. Figure 23 shows an example of a response body received from a DOTS server which supports: o IPv4, IPv6, TCP, UDP, ICMP, and ICMPv6 mandatory match criteria listed in Section 4.2. o 'accept', 'drop', and 'rate-limit' actions. Boucadair & Reddy Expires January 23, 2020 [Page 48] Internet-Draft DOTS Data Channel Protocol July 2019 { "ietf-dots-data-channel:capabilities": { "address-family": ["ipv4", "ipv6"], "forwarding-actions": ["drop", "accept"], "rate-limit": true, "transport-protocols": [1, 6, 17, 58], "ipv4": { "length": true, "protocol": true, "destination-prefix": true, "source-prefix": true, "fragment": true }, "ipv6": { "length": true, "protocol": true, "destination-prefix": true, "source-prefix": true, "fragment": true }, "tcp": { "flags-bitmask": true, "source-port": true, "destination-port": true, "port-range": true }, "udp": { "length": true, "source-port": true, "destination-port": true, "port-range": true }, "icmp": { "type": true, "code": true } } } Figure 23: Reply to a GET Request with Filtering Capabilities (Message Body) 7.2. Install Filtering Rules A POST or PUT request is used by a DOTS client to communicate filtering rules to a DOTS server. Boucadair & Reddy Expires January 23, 2020 [Page 49] Internet-Draft DOTS Data Channel Protocol July 2019 Figure 24 shows a POST request example to block traffic from 192.0.2.0/24 and destined to 198.51.100.0/24. Other examples are discussed in Appendix A. POST /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "sample-ipv4-acl", "type": "ipv4-acl-type", "activation-type": "activate-when-mitigating", "aces": { "ace": [ { "name": "rule1", "matches": { "ipv4": { "destination-ipv4-network": "198.51.100.0/24", "source-ipv4-network": "192.0.2.0/24" } }, "actions": { "forwarding": "drop" } } ] } } ] } } Figure 24: POST to Install Filtering Rules The meaning of these parameters is as follows: name: The name of the access list. This is a mandatory attribute. type: Indicates the primary intended type of match criteria (e.g., IPv4, IPv6). It is set to 'ipv4-acl-type' in the example of Figure 24. Boucadair & Reddy Expires January 23, 2020 [Page 50] Internet-Draft DOTS Data Channel Protocol July 2019 This is an optional attribute. activation-type: Indicates whether an ACL has to be activated (immediately or during mitigation time) or instantiated without being activated (deactivated). Deactivated ACLs can be activated using a variety of means such as manual configuration on a DOTS server or using the DOTS data channel. If this attribute is not provided, the DOTS server MUST use 'activate-when-mitigating' as default value. When a mitigation is in progress, the DOTS server MUST only activate 'activate-when-mitigating' filters that are bound to the DOTS client that triggered the mitigation. This is an optional attribute. matches: Define criteria used to identify a flow on which to apply the rule. It can be "l3" (IPv4, IPv6) or "l4" (TCP, UDP, ..). The detailed match parameters are specified in Section 4. In the example depicted in Figure 24, an IPv4 matching criteria is used. This is an optional attribute. destination-ipv4-network: The destination IPv4 prefix. DOTS servers MUST validate that these prefixes are within the scope of the DOTS client domain. Other validation checks may be supported by DOTS servers. If this attribute is not provided, the DOTS server enforces the ACL on any destination IP address that belong to the DOTS client domain. This is a mandatory attribute in requests with an 'activation- type' set to 'immediate'. source-ipv4-network: The source IPv4 prefix. This is an optional attribute. actions: Actions in the forwarding ACL category can be "drop" or "accept". The "accept" action is used to accept-list traffic. The "drop" action is used to drop-list traffic. Accepted traffic may be subject to "rate-limit"; the allowed traffic rate is represented in bytes per second. This unit is the same as the one used for "traffic-rate" in [RFC5575]. Boucadair & Reddy Expires January 23, 2020 [Page 51] Internet-Draft DOTS Data Channel Protocol July 2019 This is a mandatory attribute. The DOTS server indicates the result of processing the POST request using the status-line. Concretely, "201 Created" status-line MUST be returned in the response if the DOTS server has accepted the filtering rules. If the request is missing a mandatory attribute or contains an invalid or unknown parameter (e.g., a match field not supported by the DOTS server), "400 Bad Request" status-line MUST be returned by the DOTS server in the response. The error-tag is set to "missing-attribute", "invalid-value", or "unknown-element" as a function of the encountered error. If the request is received via a server-domain DOTS gateway, but the DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid' is expected to be supplied, the DOTS server MUST reply with "403 Forbidden" status-line and the error-tag "access-denied". Upon receipt of this message, the DOTS client MUST register (Figure 11). If the request is conflicting with an existing filtering installed by another DOTS client of the domain, absent any local policy, the DOTS server returns "409 Conflict" status-line to the requesting DOTS client. The error-tag "resource-denied" is used in this case. The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be used to specify how an access control entry is inserted within an ACL and how an ACL is inserted within an ACL set. The DOTS client uses the PUT request to modify its filtering rules maintained by the DOTS server. In particular, a DOTS client MUST update its filtering entries upon change of the destination-prefix. How such change is detected is out of scope. A DOTS server MUST maintain a filtering rule for at least 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. Typically, a refresh request is a PUT request which echoes the content of a response to a GET request with all of the read-only parameters stripped out (e.g., pending-lifetime). 7.3. Retrieve Installed Filtering Rules A DOTS client periodically queries its DOTS server to check the counters for installed filtering rules. A GET request is used to retrieve filtering rules from a DOTS server. In order to indicate which type of data is requested in a GET request, the DOTS client sets adequately the "content" query parameter. Boucadair & Reddy Expires January 23, 2020 [Page 52] Internet-Draft DOTS Data Channel Protocol July 2019 If the DOTS server does not find the access list name conveyed in the GET request in its configuration data for this DOTS client, it responds with a "404 Not Found" status-line. In order to illustrate the intended behavior, consider the example depicted in Figure 25. In reference to this example, the DOTS client requests the creation of an immediate ACL called "test-acl-ipv6-udp". Boucadair & Reddy Expires January 23, 2020 [Page 53] Internet-Draft DOTS Data Channel Protocol July 2019 PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=test-acl-ipv6-udp HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "test-acl-ipv6-udp", "type": "ipv6-acl-type", "activation-type": "immediate", "aces": { "ace": [ { "name": "my-test-ace", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/96", "protocol": 17, "flow-label": 10000 }, "udp": { "source-port": { "operator": "lte", "port": 80 }, "destination-port": { "operator": "neq", "port": 1010 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 25: Example of a PUT Request to Create a Filtering Boucadair & Reddy Expires January 23, 2020 [Page 54] Internet-Draft DOTS Data Channel Protocol July 2019 The peer DOTS server follows the procedure specified in Section 7.2 to process the request. We consider in the following that a positive response is sent back to the requesting DOTS client to confirm that the "test-acl-ipv6-udp" ACL is successfully installed by the DOTS server. The DOTS client can issue a GET request to retrieve all its filtering rules and the number of matches for the installed filtering rules as illustrated in Figure 26. The "content" query parameter is set to 'all'. The message body of the response to this GET request is shown in Figure 27. GET /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw\ /acls?content=all HTTP/1.1 Host: example.com Accept: application/yang-data+json Figure 26: Retrieve the Configuration Data and State Data for the Filtering Rules (GET Request) Boucadair & Reddy Expires January 23, 2020 [Page 55] Internet-Draft DOTS Data Channel Protocol July 2019 { "ietf-dots-data-channel:acls": { "acl": [ { "name": "test-acl-ipv6-udp", "type": "ipv6-acl-type", "activation-type": "immediate", "pending-lifetime":9080, "aces": { "ace": [ { "name": "my-test-ace", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/96", "protocol": 17, "flow-label": 10000 }, "udp": { "source-port": { "operator": "lte", "port": 80 }, "destination-port": { "operator": "neq", "port": 1010 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 27: Retrieve the Configuration Data and State Data for the Filtering Rules (Response Message Body) Also, a DOTS client can issue a GET request to retrieve only configuration data related to an ACL as shown in Figure 28. It does so by setting the "content" query parameter to 'config'. Boucadair & Reddy Expires January 23, 2020 [Page 56] Internet-Draft DOTS Data Channel Protocol July 2019 GET /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=test-acl-ipv6-udp?content=config HTTP/1.1 Host: example.com Accept: application/yang-data+json Figure 28: Retrieve the Configuration Data for a Filtering Rule (GET Request) A response to this GET request is shown in Figure 29. Boucadair & Reddy Expires January 23, 2020 [Page 57] Internet-Draft DOTS Data Channel Protocol July 2019 { "ietf-dots-data-channel:acls": { "acl": [ { "name": "test-acl-ipv6-udp", "type": "ipv6-acl-type", "activation-type": "immediate", "aces": { "ace": [ { "name": "my-test-ace", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/96", "protocol": 17, "flow-label": 10000 }, "udp": { "source-port": { "operator": "lte", "port": 80 }, "destination-port": { "operator": "neq", "port": 1010 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 29: Retrieve the Configuration Data for a Filtering Rule (Response Message Body) A DOTS client can also issue a GET request with a "content" query parameter set to 'non-config' to exclusively retrieve non- configuration data bound to a given ACL as shown in Figure 30. A response to this GET request is shown in Figure 31. Boucadair & Reddy Expires January 23, 2020 [Page 58] Internet-Draft DOTS Data Channel Protocol July 2019 GET /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=test-acl-ipv6-udp?content=non-config HTTP/1.1 Host: example.com Accept: application/yang-data+json Figure 30: Retrieve the Non-Configuration Data for a Filtering Rule (GET Request) { "ietf-dots-data-channel:acls": { "acl": [ { "name": "test-acl-ipv6-udp", "pending-lifetime": 8000, "aces": { "ace": [ { "name": "my-test-ace" } ] } } ] } } Figure 31: Retrieve the Non-Configuration Data for a Filtering Rule (Response Message Body) 7.4. Remove Filtering Rules A DELETE request is used by a DOTS client to delete filtering rules from a DOTS server. If the DOTS server does not find the access list name carried in the DELETE request in its configuration data for this DOTS client, it MUST respond with a "404 Not Found" status-line. The DOTS server successfully acknowledges a DOTS client's request to withdraw the filtering rules using "204 No Content" status-line, and removes the filtering rules accordingly. Figure 32 shows an example of a request to remove the IPv4 ACL "sample-ipv4-acl" created in Section 7.2. Boucadair & Reddy Expires January 23, 2020 [Page 59] Internet-Draft DOTS Data Channel Protocol July 2019 DELETE /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw/acls\ /acl=sample-ipv4-acl HTTP/1.1 Host: example.com Figure 32: Remove a Filtering Rule (DELETE Request) Figure 33 shows an example of a response received from the DOTS server to confirm the deletion of "sample-ipv4-acl". HTTP/1.1 204 No Content Server: Apache Date: Fri, 27 Jul 2018 10:05:15 GMT Cache-Control: no-cache Content-Type: application/yang-data+json Content-Length: 0 Connection: Keep-Alive Figure 33: Remove a Filtering Rule (Response) 8. Operational Considerations The following operational considerations should be taken into account: o DOTS servers MUST NOT enable both DOTS data channel and direct configuration, to avoid race conditions and inconsistent configurations arising from simultaneous updates from multiple sources. o DOTS agents SHOULD enable the DOTS data channel to configure aliases and ACLs, and only use direct configuration as a stop-gap mechanism to test DOTS signal channel with aliases and ACLs. Further, direct configuration SHOULD only be used when the on-path DOTS agents are within the same domain. o If a DOTS server has enabled direct configuration, it can reject the DOTS data channel connection using hard ICMP error [RFC1122] or RST (Reset) bit in the TCP header or reject the RESTCONF request using an error response containing a "503 Service Unavailable" status-line. 9. IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: Boucadair & Reddy Expires January 23, 2020 [Page 60] Internet-Draft DOTS Data Channel Protocol July 2019 URI: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry [RFC7950] within the "YANG Parameters" registry. Name: ietf-dots-data-channel Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-data-channel Prefix: data-channel Reference: RFC XXXX This module is not maintained by IANA. 10. Security Considerations RESTCONF security considerations are discussed in [RFC8040]. In particular, DOTS agents MUST follow the security recommendations in Sections 2 and 12 of [RFC8040]. Also, DOTS agents MUST support the mutual authentication TLS profile discussed in Sections 7.1 and 8 of [I-D.ietf-dots-signal-channel]. Authenticated encryption MUST be used for data confidentiality and message integrity. The interaction between the DOTS agents requires Transport Layer Security (TLS) with a cipher suite offering confidentiality protection and the guidance given in [RFC7525] MUST be followed to avoid attacks on TLS. The installation of drop- or accept-list rules using RESTCONF over TLS reveals the attacker IP addresses and legitimate IP addresses only to the DOTS server trusted by the DOTS client. The secure communication channel between DOTS agents provides privacy and prevents a network eavesdropper from directly gaining access to the drop- and accept-listed IP addresses. An attacker may be able to inject RST packets, bogus application segments, etc., regardless of whether TLS authentication is used. Because the application data is TLS protected, this will not result in the application receiving bogus data, but it will constitute a DoS on the connection. This attack can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then any bogus packets injected by an attacker will be rejected by the TCP-AO integrity check and therefore will never reach the TLS layer. In order to prevent leaking internal information outside a client- domain, client-side DOTS gateways SHOULD NOT reveal the identity of Boucadair & Reddy Expires January 23, 2020 [Page 61] Internet-Draft DOTS Data Channel Protocol July 2019 internal DOTS clients (e.g., source IP address, client's hostname) unless explicitly configured to do so. DOTS servers MUST verify that requesting DOTS clients are entitled to enforce filtering rules on a given IP prefix. That is, only filtering rules on IP resources that belong to the DOTS client domain can be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client domain is deployment-specific. Rate-limiting DOTS requests, including those with new 'cuid' values, from the same DOTS client defends against DoS attacks that would result from varying the 'cuid' to exhaust DOTS server resources. Rate-limit policies SHOULD be enforced on DOTS gateways (if deployed) and DOTS servers. Applying resources quota per DOTS client and/or per DOTS client domain (e.g., limit the number of aliases and filters to be installed by DOTS clients) prevents DOTS server resources to be aggressively used by some DOTS clients and ensures, therefore, DDoS mitigation usage fairness. Additionally, DOTS servers may limit the number of DOTS clients that can be enabled per domain. When FQDNs are used as targets, the DOTS server MUST rely upon DNS privacy enabling protocols (e.g., DNS over TLS [RFC7858] or DoH [RFC8484]) to prevent eavesdroppers from possibly identifying the target resources protected by the DDoS mitigation service, and means to ensure the target FQDN resolution is authentic (e.g., DNSSEC [RFC4034]). The presence of DOTS gateways may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, a mechanism is defined in Section 3.4. All data nodes defined in the YANG module which can be created, modified, and deleted (i.e., config true, which is the default) are considered sensitive. Write operations applied to these data nodes without proper protection can negatively affect network operations. This module reuses YANG structures from [RFC8519], and the security considerations for those nodes continue to apply for this usage. Appropriate security measures are recommended to prevent illegitimate users from invoking DOTS data channel primitives. Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: o Setting an arbitrarily low rate-limit, which may prevent legitimate traffic from being forwarded (rate-limit). Boucadair & Reddy Expires January 23, 2020 [Page 62] Internet-Draft DOTS Data Channel Protocol July 2019 o Setting an arbitrarily high rate-limit, which may lead to the forwarding of illegitimate DDoS traffic (rate-limit). o Communicating invalid aliases to the server (alias), which will cause the failure of associating both data and signal channels. o Setting invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. 11. Contributing Authors The following individuals co-authored this document: Boucadair & Reddy Expires January 23, 2020 [Page 63] Internet-Draft DOTS Data Channel Protocol July 2019 Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Email: kaname@nttv6.jp Liang Xia Huawei 101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China Email: frank.xialiang@huawei.com Prashanth Patil Cisco Systems, Inc. Email: praspati@cisco.com Andrew Mortensen Arbor Networks, Inc. 2727 S. State St Ann Arbor, MI 48104 United States Email: andrew.mortensen@netscout.com Nik Teague Iron Mountain Data Centers United Kingdom Email: nteague@ironmountain.co.uk 12. Contributors The following individuals have contributed to this document: o Dan Wing, Email: dwing-ietf@fuggles.com o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.com Boucadair & Reddy Expires January 23, 2020 [Page 64] Internet-Draft DOTS Data Channel Protocol July 2019 13. Acknowledgements Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Ehud Doron, Russ White, Gilbert Clark, Kathleen Moriarty, Nesredien Suleiman, Roni Even, and Brian Trammel for the discussion and comments. The authors would like to give special thanks to Kaname Nishizuka and Jon Shallow for their efforts in implementing the protocol and performing interop testing at IETF Hackathons. Many thanks to Ben Kaduk for the detailed AD review. Thanks to Martin Bjorklund for the guidance on RESTCONF. Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja Kuehlewind, and Warren Kumari for the review. 14. References 14.1. Normative References [I-D.ietf-dots-signal-channel] K, R., Boucadair, M., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", draft- ietf-dots-signal-channel-35 (work in progress), July 2019. [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, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [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, . Boucadair & Reddy Expires January 23, 2020 [Page 65] Internet-Draft DOTS Data Channel Protocol July 2019 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [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, . [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, . [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, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, . 14.2. Informative References [I-D.ietf-dots-architecture] Mortensen, A., K, R., Andreasen, F., Teague, N., and R. Compton, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", draft-ietf-dots- architecture-14 (work in progress), May 2019. Boucadair & Reddy Expires January 23, 2020 [Page 66] Internet-Draft DOTS Data Channel Protocol July 2019 [I-D.ietf-dots-server-discovery] Boucadair, M. and R. K, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery", draft- ietf-dots-server-discovery-04 (work in progress), June 2019. [I-D.ietf-netconf-restconf-client-server] Watsen, K., "RESTCONF Client and Server Models", draft- ietf-netconf-restconf-client-server-14 (work in progress), July 2019. [proto_numbers] "IANA, "Protocol Numbers"", 2011, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [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, . [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, . [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, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . Boucadair & Reddy Expires January 23, 2020 [Page 67] Internet-Draft DOTS Data Channel Protocol July 2019 [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, . [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, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, . Appendix A. Sample Examples: Filtering Fragments This specification strongly recommends the use of "fragment" for handling fragments. Figure 34 shows the content of the POST request to be issued by a DOTS client to its DOTS server to allow the traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop all fragmented packets. The following ACEs are defined (in this order): o "drop-all-fragments" ACE: discards all fragments. o "allow-dns-packets" ACE: accepts DNS packets destined to 198.51.100.0/24. POST /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 Host: example.com Content-Type: application/yang-data+json Boucadair & Reddy Expires January 23, 2020 [Page 68] Internet-Draft DOTS Data Channel Protocol July 2019 { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv4-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv4": { "fragment": { "operator": "match", "type": "isf" } } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv4": { "destination-ipv4-network": "198.51.100.0/24" } "udp": { "destination-port": { "operator": "eq", "port": 53 } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 34: Filtering IPv4 Fragmented Packets Boucadair & Reddy Expires January 23, 2020 [Page 69] Internet-Draft DOTS Data Channel Protocol July 2019 Figure 35 shows a POST request example issued by a DOTS client to its DOTS server to allow the traffic destined to 2001:db8::/32 and UDP port number 53, but to drop all fragmented packets. The following ACEs are defined (in this order): o "drop-all-fragments" ACE: discards all fragments (including atomic fragments). That is, IPv6 packets which include a Fragment header (44) are dropped. o "allow-dns-packets" ACE: accepts DNS packets destined to 2001:db8::/32. POST /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "fragment": { "operator": "match", "type": "isf" } } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { Boucadair & Reddy Expires January 23, 2020 [Page 70] Internet-Draft DOTS Data Channel Protocol July 2019 "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 35: Filtering IPv6 Fragmented Packets Appendix B. Sample Examples: Filtering TCP Messages This section provides sample examples to illustrate TCP-specific filtering based on the flag bits. These examples should not be interpreted as recommended filtering behaviors under specific DDoS attacks. B.1. Discard TCP Null Attack Figure 36 shows an example of a DOTS request sent by a DOTS client to install immediately a filter to discard incoming TCP messages having all flags unset. The bitmask can be set to 255 to check against the (CWR, ECE, URG, ACK, PSH, RST, SYN, FIN) flags. Boucadair & Reddy Expires January 23, 2020 [Page 71] Internet-Draft DOTS Data Channel Protocol July 2019 PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=tcp-flags-example HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [{ "name": "tcp-flags-example", "activation-type": "immediate", "aces": { "ace": [{ "name": "null-attack", "matches": { "tcp": { "flags-bitmask": { "operator": "not any", "bitmask": 4095 } } }, "actions": { "forwarding": "drop" } }] } }] } } Figure 36: Example of a DOTS Request to Deny TCP Null Attack Messages B.2. Rate-Limit SYN Flooding Figure 37 shows an ACL example to rate-limit incoming SYNs during a SYN-flood attack. Boucadair & Reddy Expires January 23, 2020 [Page 72] Internet-Draft DOTS Data Channel Protocol July 2019 PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=tcp-flags-example HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [{ "name": "tcp-flags-example", "activation-type": "activate-when-mitigating", "aces": { "ace": [{ "name": "rate-limit-syn", "matches": { "tcp": { "flags-bitmask": { "operator": "match", "bitmask": 2 } } }, "actions": { "forwarding": "accept", "rate-limit": "20.00" } }] } }] } } Figure 37: Example of DOTS Request to Rate-Limit Incoming TCP SYNs B.3. Rate-Limit ACK Flooding Figure 38 shows an ACL example to rate-limit incoming ACKs during an ACK-flood attack. Boucadair & Reddy Expires January 23, 2020 [Page 73] Internet-Draft DOTS Data Channel Protocol July 2019 PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=tcp-flags-example HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [{ "name": "tcp-flags-example", "type": "ipv4-acl-type", "activation-type": "activate-when-mitigating", "aces": { "ace": [{ "name": "rate-limit-ack", "matches": { "tcp": { "flags-bitmask": { "operator": "match", "bitmask": 16 } } }, "actions": { "forwarding": "accept", "rate-limit": "20.00" } }] } }] } } Figure 38: Example of DOTS Request to Rate-Limit Incoming TCP ACKs Authors' Addresses Mohamed Boucadair (editor) Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Boucadair & Reddy Expires January 23, 2020 [Page 74] Internet-Draft DOTS Data Channel Protocol July 2019 Tirumaleswar Reddy (editor) McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: kondtir@gmail.com Boucadair & Reddy Expires January 23, 2020 [Page 75] ./draft-bruckert-brainpool-for-tls13-07.txt0000644000764400076440000004776613543132373020016 0ustar iustyiusty Network Working Group L. Bruckert Internet-Draft J. Merkle Intended status: Informational secunet Security Networks Expires: March 29, 2020 M. Lochter BSI September 26, 2019 ECC Brainpool Curves for Transport Layer Security (TLS) Version 1.3 draft-bruckert-brainpool-for-tls13-07 Abstract ECC Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2, but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS 1.3. This document provides the necessary protocol mechanisms for using ECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF. 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 https://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 29, 2020. Copyright Notice Copyright (c) 2019 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 Bruckert, et al. Expires March 29, 2020 [Page 1] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 (https://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 Terminology . . . . . . . . . . . . . . . . . . 3 3. Brainpool NamedGroup Types . . . . . . . . . . . . . . . . . 3 4. Brainpool SignatureScheme Types . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 8 A.1. 256 Bit Curve . . . . . . . . . . . . . . . . . . . . . . 8 A.2. 384 Bit Curve . . . . . . . . . . . . . . . . . . . . . . 9 A.3. 512 Bit Curve . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction [RFC5639] specifies a new set of elliptic curve groups over finite prime fields for use in cryptographic applications. These groups, denoted as ECC Brainpool curves, were generated in a verifiably pseudo-random way and comply with the security requirements of relevant standards from ISO [ISO1] [ISO2], ANSI [ANSI1], NIST [FIPS], and SecG [SEC2]. [RFC8422] defines the usage of elliptic curves for authentication and key agreement in TLS 1.2 and earlier versions, and [RFC7027] defines the usage of the ECC Brainpool curves for authentication and key exchange in TLS. The latter is applicable to TLS 1.2 and earlier versions, but not to TLS 1.3 that deprecates the ECC Brainpool Curve IDs defined in [RFC7027] due to the lack of widespread deployment However, there is some interest in using these curves in TLS 1.3. The negotiation of ECC Brainpool Curves for key exchange in TLS 1.3 according to [RFC8446] requires the definition and assignment of additional NamedGroup IDs. This document provides the necessary definition and assignment of additional SignatureScheme IDs for using three ECC Brainpool Curves from [RFC5639]. Bruckert, et al. Expires March 29, 2020 [Page 2] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 This approach is not endorsed by the IETF. Implementers and deployers need to be aware of the strengths and weaknesses of all security mechanisms that they use. 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]. 3. Brainpool NamedGroup Types According to [RFC8446], the "supported_groups" extension is used for the negotiation of Diffie-Hellman groups and elliptic curve groups for key exchange during a handshake starting a new TLS session. This document adds new named groups for three elliptic curves defined in [RFC5639] to the "supported_groups" extension as follows. enum { brainpoolP256r1tls13(31), brainpoolP384r1tls13(32), brainpoolP512r1tls13(33) } NamedGroup; The encoding of ECDHE parameters for sec256r1, secp384r1, and secp521r1 as defined in section 4.2.8.2 of [RFC8446] also applies to this document. Test vectors for a Diffie-Hellman key exchange using these elliptic curves are provided in Appendix A. 4. Brainpool SignatureScheme Types According to [RFC8446], the name space SignatureScheme is used for the negotiation of elliptic curve groups for authentication via the "signature_algorithms" extension. Besides, it is required to specify the hash function that is used to hash the message before signing. This document adds new SignatureScheme types for three elliptic curves defined in [RFC5639] as follows. enum { ecdsa_brainpoolP256r1tls13_sha256(0x081A), ecdsa_brainpoolP384r1tls13_sha384(0x081B), ecdsa_brainpoolP512r1tls13_sha512(0x081C) } SignatureScheme; Bruckert, et al. Expires March 29, 2020 [Page 3] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 5. IANA Considerations IANA is requested to update the references for the ECC Brainpool curves listed in the Transport Layer Security (TLS) Parameters registry "TLS Supported Groups" [IANA-TLS] to this document. +-------+----------------------+---------+-------------+-----------+ | Value | Description | DTLS-OK | Recommended | Reference | +-------+----------------------+---------+-------------+-----------+ | 31 | brainpoolP256r1tls13 | Y | N | This doc | | | | | | | | 32 | brainpoolP384r1tls13 | Y | N | This doc | | | | | | | | 33 | brainpoolP512r1tls13 | Y | N | This doc | +-------+----------------------+---------+-------------+-----------+ Table 1 IANA is requested to update the references for the ECC Brainpool curves in the Transport Layer Security (TLS) Parameters registry "TLS SignatureScheme" [IANA-TLS] to this document. +--------+----------------------+---------+-------------+-----------+ | Value | Description | DTLS-OK | Recommended | Reference | +--------+----------------------+---------+-------------+-----------+ | 0x081A | ecdsa_brainpoolP256r | Y | N | This doc | | | 1tls13_sha256 | | | | | | | | | | | 0x081B | ecdsa_brainpoolP384r | Y | N | This doc | | | 1tls13_sha384 | | | | | | | | | | | 0x081C | ecdsa_brainpoolP512r | Y | N | This doc | | | 1tls13_sha512 | | | | +--------+----------------------+---------+-------------+-----------+ Table 2 6. Security Considerations The security considerations of [RFC8446] apply accordingly. The confidentiality, authenticity and integrity of the TLS communication is limited by the weakest cryptographic primitive applied. In order to achieve a maximum security level when using one of the elliptic curves from Table 1 for key exchange and / or one of the signature algorithms from Table 2 for authentication in TLS, the key derivation function, the algorithms and key lengths of symmetric encryption and message authentication as well as the algorithm, bit Bruckert, et al. Expires March 29, 2020 [Page 4] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 length and hash function used for signature generation should be chosen at commensurate strengths, for example according to the recommendations of [NIST800-57] and [RFC5639]. Furthermore, the private Diffie-Hellman keys should be generated from a random keystream with a length equal to the length of the order of the group E(GF(p)) defined in [RFC5639]. The value of the private Diffie- Hellman keys should be less than the order of the group E(GF(p)). When using ECDHE key agreement with the curves brainpoolP256r1tls13, brainpoolP384r1tls13 or brainpoolP512r1tls13, the peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve. If this check is not conducted, an attacker can force the key exchange into a small subgroup, and the resulting shared secret can be guessed with significantly less effort. Implementations of elliptic curve cryptography for TLS may be susceptible to side-channel attacks. Particular care should be taken for implementations that internally transform curve points to points on the corresponding "twisted curve", using the map (x',y') = (x*Z^2, y*Z^3) with the coefficient Z specified for that curve in [RFC5639], in order to take advantage of an an efficient arithmetic based on the twisted curve's special parameters (A = -3): although the twisted curve itself offers the same level of security as the corresponding random curve (through mathematical equivalence), arithmetic based on small curve parameters may be harder to protect against side-channel attacks. General guidance on resistence of elliptic curve cryptography implementations against side-channel-attacks is given in [BSI1] and [HMV]. 7. References 7.1. Normative References [IANA-TLS] Internet Assigned Numbers Authority, "Transport Layer Security (TLS) Parameters", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", RFC 5639, March 2010. Bruckert, et al. Expires March 29, 2020 [Page 5] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 [RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)", RFC 7027, DOI 10.17487/RFC7027, October 2013, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 7.2. Informative References [ANSI1] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 2005. [BSI1] Bundesamt fuer Sicherheit in der Informationstechnik, "Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations", July 2011. [FIPS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-2, December 1998. [HMV] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to Elliptic Curve Cryptography", Springer Verlag, 2004. [ISO1] International Organization for Standardization, "Information Technology - Security Techniques - Digital Signatures with Appendix - Part 3: Discrete Logarithm Based Mechanisms", ISO/IEC 14888-3, 2006. [ISO2] International Organization for Standardization, "Information Technology - Security Techniques - Cryptographic Techniques Based on Elliptic Curves - Part 2: Digital signatures", ISO/IEC 15946-2, 2002. [NIST800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, January 2016. Bruckert, et al. Expires March 29, 2020 [Page 6] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 [SEC1] Certicom Research, "Elliptic Curve Cryptography", Standards for Efficient Cryptography (SEC) 1, September 2000. [SEC2] Certicom Research, "Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography (SEC) 2, September 2000. Bruckert, et al. Expires March 29, 2020 [Page 7] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 Appendix A. Test Vectors This non-normative Appendix provides some test vectors for example Diffie-Hellman key exchanges using each of the curves defined in Table 1 . In all of the following sections the following notation is used: d_A: the secret key of party A x_qA: the x-coordinate of the public key of party A y_qA: the y-coordinate of the public key of party A d_B: the secret key of party B x_qB: the x-coordinate of the public key of party B y_qB: the y-coordinate of the public key of party B x_Z: the x-coordinate of the shared secret that results from completion of the Diffie-Hellman computation, i.e. the hex representation of the pre-master secret y_Z: the y-coordinate of the shared secret that results from completion of the Diffie-Hellman computation The field elements x_qA, y_qA, x_qB, y_qB, x_Z, y_Z are represented as hexadecimal values using the FieldElement-to-OctetString conversion method specified in [SEC1]. A.1. 256 Bit Curve Curve brainpoolP256r1 dA = 81DB1EE100150FF2EA338D708271BE38300CB54241D79950F77B063039804F1D x_qA = 44106E913F92BC02A1705D9953A8414DB95E1AAA49E81D9E85F929A8E3100BE5 y_qA = 8AB4846F11CACCB73CE49CBDD120F5A900A69FD32C272223F789EF10EB089BDC dB = 55E40BC41E37E3E2AD25C3C6654511FFA8474A91A0032087593852D3E7D76BD3 x_qB = 8D2D688C6CF93E1160AD04CC4429117DC2C41825E1E9FCA0ADDD34E6F1B39F7B Bruckert, et al. Expires March 29, 2020 [Page 8] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 y_qB = 990C57520812BE512641E47034832106BC7D3E8DD0E4C7F1136D7006547CEC6A x_Z = 89AFC39D41D3B327814B80940B042590F96556EC91E6AE7939BCE31F3A18BF2B y_Z = 49C27868F4ECA2179BFD7D59B1E3BF34C1DBDE61AE12931648F43E59632504DE A.2. 384 Bit Curve Curve brainpoolP384r1 dA = 1E20F5E048A5886F1F157C74E91BDE2B98C8B52D58E5003D57053FC4B0BD6 5D6F15EB5D1EE1610DF870795143627D042 x_qA = 68B665DD91C195800650CDD363C625F4E742E8134667B767B1B47679358 8F885AB698C852D4A6E77A252D6380FCAF068 y_qA = 55BC91A39C9EC01DEE36017B7D673A931236D2F1F5C83942D049E3FA206 07493E0D038FF2FD30C2AB67D15C85F7FAA59 dB = 032640BC6003C59260F7250C3DB58CE647F98E1260ACCE4ACDA3DD869F74E 01F8BA5E0324309DB6A9831497ABAC96670 x_qB = 4D44326F269A597A5B58BBA565DA5556ED7FD9A8A9EB76C25F46DB69D19 DC8CE6AD18E404B15738B2086DF37E71D1EB4 y_qB = 62D692136DE56CBE93BF5FA3188EF58BC8A3A0EC6C1E151A21038A42E91 85329B5B275903D192F8D4E1F32FE9CC78C48 x_Z = 0BD9D3A7EA0B3D519D09D8E48D0785FB744A6B355E6304BC51C229FBBCE2 39BBADF6403715C35D4FB2A5444F575D4F42 y_Z = 0DF213417EBE4D8E40A5F76F66C56470C489A3478D146DECF6DF0D94BAE9 E598157290F8756066975F1DB34B2324B7BD A.3. 512 Bit Curve Curve brainpoolP512r1 dA = 16302FF0DBBB5A8D733DAB7141C1B45ACBC8715939677F6A56850A38BD87B D59B09E80279609FF333EB9D4C061231FB26F92EEB04982A5F1D1764CAD5766542 2 x_qA = 0A420517E406AAC0ACDCE90FCD71487718D3B953EFD7FBEC5F7F27E28C6 149999397E91E029E06457DB2D3E640668B392C2A7E737A7F0BF04436D11640FD0 9FD Bruckert, et al. Expires March 29, 2020 [Page 9] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 y_qA = 72E6882E8DB28AAD36237CD25D580DB23783961C8DC52DFA2EC138AD472 A0FCEF3887CF62B623B2A87DE5C588301EA3E5FC269B373B60724F5E82A6AD147F DE7 dB = 230E18E1BCC88A362FA54E4EA3902009292F7F8033624FD471B5D8ACE49D1 2CFABBC19963DAB8E2F1EBA00BFFB29E4D72D13F2224562F405CB80503666B2542 9 x_qB = 9D45F66DE5D67E2E6DB6E93A59CE0BB48106097FF78A081DE781CDB31FC E8CCBAAEA8DD4320C4119F1E9CD437A2EAB3731FA9668AB268D871DEDA55A54731 99F y_qB = 2FDC313095BCDD5FB3A91636F07A959C8E86B5636A1E930E8396049CB48 1961D365CC11453A06C719835475B12CB52FC3C383BCE35E27EF194512B7187628 5FA x_Z = A7927098655F1F9976FA50A9D566865DC530331846381C87256BAF322624 4B76D36403C024D7BBF0AA0803EAFF405D3D24F11A9B5C0BEF679FE1454B21C4CD 1F y_Z = 7DB71C3DEF63212841C463E881BDCF055523BD368240E6C3143BD8DEF8B3 B3223B95E0F53082FF5E412F4222537A43DF1C6D25729DDB51620A832BE6A26680 A2 Authors' Addresses Leonie Bruckert secunet Security Networks Ammonstr. 74 01067 Dresden Germany Phone: +49 201 5454 3819 EMail: leonie.bruckert@secunet.com Johannes Merkle secunet Security Networks Mergenthaler Allee 77 65760 Eschborn Germany Phone: +49 201 5454 3091 EMail: johannes.merkle@secunet.com Bruckert, et al. Expires March 29, 2020 [Page 10] Internet-Draft ECC Brainpool Curves for TLS 1.3 September 2019 Manfred Lochter BSI Postfach 200363 53133 Bonn Germany Phone: +49 228 9582 5643 EMail: manfred.lochter@bsi.bund.de Bruckert, et al. Expires March 29, 2020 [Page 11] ./draft-ietf-lamps-pkix-shake-15.txt0000644000764400076440000010332213515345751016546 0ustar iustyiusty LAMPS WG P. Kampanakis Internet-Draft Cisco Systems Updates: 3279 (if approved) Q. Dang Intended status: Standards Track NIST Expires: January 22, 2020 July 21, 2019 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs draft-ietf-lamps-pkix-shake-15 Abstract Digital signatures are used to sign messages, X.509 certificates and CRLs. This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile" (RFC3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. 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 https://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 22, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Kampanakis & Dang Expires January 22, 2020 [Page 1] Internet-Draft SHAKE identifiers in X.509 July 2019 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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use in PKIX . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7 5.1.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8 5.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Change Log [ EDNOTE: Remove this section before publication. ] o draft-ietf-lamps-pkix-shake-15: * Minor editorial nits. o draft-ietf-lamps-pkix-shake-14: * Fixing error with incorrect preimage resistance bits for SHA128 and SHA256. o draft-ietf-lamps-pkix-shake-13: * Addressing one applicable comment from Dan M. about sec levels while in secdir review of draft-ietf-lamps-cms-shakes. * Addressing comment from Scott B.'s opsdir review about references in the abstract. o draft-ietf-lamps-pkix-shake-12: Kampanakis & Dang Expires January 22, 2020 [Page 2] Internet-Draft SHAKE identifiers in X.509 July 2019 * Nits identified by Roman, Eric V. Ben K., Barry L. in ballot position review. o draft-ietf-lamps-pkix-shake-11: * Nits identified by Roman in AD Review. o draft-ietf-lamps-pkix-shake-10: * Updated IANA considerations section to request for OID assignments. o draft-ietf-lamps-pkix-shake-09: * Fixed minor text nits. * Added text name allocation for SHAKEs in IANA considerations. * Updates in Sec Considerations section. o draft-ietf-lamps-pkix-shake-08: * Small nits from Russ while in WGLC. o draft-ietf-lamps-pkix-shake-07: * Incorporated Eric's suggestion from WGLC. o draft-ietf-lamps-pkix-shake-06: * Added informative references. * Updated ASN.1 so it compiles. * Updated IANA considerations. o draft-ietf-lamps-pkix-shake-05: * Added RFC8174 reference and text. * Explicitly explained why RSASSA-PSS-params are omitted in section 5.1.1. * Simplified Public Keys section by removing redundant info from RFCs. o draft-ietf-lamps-pkix-shake-04: Kampanakis & Dang Expires January 22, 2020 [Page 3] Internet-Draft SHAKE identifiers in X.509 July 2019 * Removed paragraph suggesting KMAC to be used in generating k in Deterministic ECDSA. That should be RFC6979-bis. * Removed paragraph from Security Considerations that talks about randomness of k because we are using deterministic ECDSA. * Various ASN.1 fixes. * Text fixes. o draft-ietf-lamps-pkix-shake-03: * Updates based on suggestions and clarifications by Jim. * Added ASN.1. o draft-ietf-lamps-pkix-shake-02: * Significant reorganization of the sections to simplify the introduction, the new OIDs and their use in PKIX. * Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, according the WG consensus. * Updated Public Key section to use the new RSASSA-PSS OIDs and clarify the algorithm identifier usage. * Removed the no longer used SHAKE OIDs from section 3.1. * Consolidated subsection for message digest algorithms. * Text fixes. o draft-ietf-lamps-pkix-shake-01: * Changed titles and section names. * Removed DSA after WG discussions. * Updated shake OID names and parameters, added MGF1 section. * Updated RSASSA-PSS section. * Added Public key algorithm OIDs. * Populated Introduction and IANA sections. o draft-ietf-lamps-pkix-shake-00: Kampanakis & Dang Expires January 22, 2020 [Page 4] Internet-Draft SHAKE identifiers in X.509 July 2019 * Initial version 2. Introduction [RFC3279] defines cryptographic algorithm identifiers for the Internet X.509 Certificate and Certificate Revocation Lists (CRL) profile [RFC5280]. This document updates RFC3279 and defines identifiers for several cryptographic algorithms that use variable length output SHAKE functions introduced in [SHA3] which can be used with . In the SHA-3 family, two extendable-output functions (SHAKEs), SHAKE128 and SHAKE256, are defined. Four other hash function instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also defined but are out of scope for this document. A SHAKE is a variable length hash function defined as SHAKE(M, d) where the output is a d-bits-long digest of message M. The corresponding collision and second-preimage-resistance strengths for SHAKE128 are min(d/2,128) and min(d,128) bits, respectively (Appendix A.1 [SHA3]). And the corresponding collision and second-preimage-resistance strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, respectively. A SHAKE can be used as the message digest function (to hash the message to be signed) in RSASSA-PSS [RFC8017] and ECDSA [X9.62] and as the hash in the mask generation function (MGF) in RSASSA-PSS. 3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Identifiers This section defines four new object identifiers (OIDs), for RSASSA- PSS and ECDSA with each of SHAKE128 and SHAKE256. The same algorithm identifiers can be used for identifying a public key in RSASSA-PSS. The new identifiers for RSASSA-PSS signatures using SHAKEs are below. Kampanakis & Dang Expires January 22, 2020 [Page 5] Internet-Draft SHAKE identifiers in X.509 July 2019 id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD1 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD2 } The new algorithm identifiers of ECDSA signatures using SHAKEs are below. id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD3 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD4 } The parameters for the four identifiers above MUST be absent. That is, the identifier SHALL be a SEQUENCE of one component, the OID. Section 5.1.1 and Section 5.1.2 specify the required output length for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In summary, when hashing messages to be signed, output lengths of SHAKE128 and SHAKE256 are 256 and 512 bits respectively. When the SHAKEs are used as mask generation functions RSASSA-PSS, their output length is (8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, respectively, where n is the RSA modulus size in bits. 5. Use in PKIX 5.1. Signatures Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 representation from [RFC5280] below, in an X.509 certificate, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. Kampanakis & Dang Expires January 22, 2020 [Page 6] Internet-Draft SHAKE identifiers in X.509 July 2019 Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } The identifiers defined in Section 4 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate and the signature field in the sequence TBSCertificate in X.509 [RFC5280]. The parameters of these signature algorithms are absent as explained in Section 4. Conforming CA implementations MUST specify the algorithms explicitly by using the OIDs specified in Section 4 when encoding RSASSA-PSS or ECDSA with SHAKE signatures in certificates and CRLs. Conforming client implementations that process certificates and CRLs using RSASSA-PSS or ECDSA with SHAKE MUST recognize the corresponding OIDs. Encoding rules for RSASSA-PSS and ECDSA signature values are specified in [RFC4055] and [RFC5480], respectively. When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA curve order SHOULD be chosen in line with the SHAKE output length. Refer to Section 7 for more details. 5.1.1. RSASSA-PSS Signatures The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is used, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- PSS-params that are used to define the algorithms and inputs to the algorithm. This specification does not use parameters because the hash, mask generation algorithm, trailer and salt are embedded in the OID definition. The hash algorithm to hash a message being signed and the hash algorithm used as the mask generation function in RSASSA-PSS MUST be the same: both SHAKE128 or both SHAKE256. The output length of the hash algorithm which hashes the message SHALL be 32 (for SHAKE128) or 64 bytes (for SHAKE256). The mask generation function takes an octet string of variable length and a desired output length as input, and outputs an octet string of the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be used natively as the MGF function, instead of the MGF1 algorithm that uses the hash function in multiple iterations as specified in Section B.2.1 of [RFC8017]. In other words, the MGF is defined as the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS- Kampanakis & Dang Expires January 22, 2020 [Page 7] Internet-Draft SHAKE identifiers in X.509 July 2019 SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is the seed from which mask is generated, an octet string [RFC8017]. As explained in Step 9 of section 9.1.1 of [RFC8017], the output length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. Thus when SHAKE is used as the MGF, the SHAKE output length maskLen is (8*emLen - 264) or (8*emLen - 520) bits, respectively. For example, when RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, respectively. The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField MUST be 1, which represents the trailer field with hexadecimal value 0xBC [RFC8017]. 5.1.2. ECDSA Signatures The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 (specified in Section 4) algorithm identifier appears, the respective SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id- ecdsa-with-shake128 or id-ecdsa-with-shake256. For simplicity and compliance with the ECDSA standard specification, the output length of the hash function must be explicitly determined. The output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 256 or 512 bits, respectively. Conforming CA implementations that generate ECDSA with SHAKE signatures in certificates or CRLs SHOULD generate such signatures with a deterministically generated, non-random k in accordance with all the requirements specified in [RFC6979]. They MAY also generate such signatures in accordance with all other recommendations in [X9.62] or [SEC1] if they have a stated policy that requires conformance to those standards. Those standards have not specified SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 with output length being 32 and 64 octets, respectively, can be used instead of 256 and 512-bit output hash algorithms such as SHA256 and SHA512. Kampanakis & Dang Expires January 22, 2020 [Page 8] Internet-Draft SHAKE identifiers in X.509 July 2019 5.2. Public Keys Certificates conforming to [RFC5280] can convey a public key for any public key algorithm. The certificate indicates the public key algorithm through an algorithm identifier. This algorithm identifier is an OID and optionally associated parameters. The conventions and encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers are as specified in Section 2.3.1 and 2.3.5 of [RFC3279], Section 3.1 of [RFC4055] and Section 2.1 of [RFC5480]. Traditionally, the rsaEncryption object identifier is used to identify RSA public keys. The rsaEncryption object identifier continues to identify the subject public key when the RSA private key owner does not wish to limit the use of the public key exclusively to RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS with SHAKEs, the AlgorithmIdentifiers for RSASSA-PSS defined in Section 4 SHOULD be used as the algorithm field in the SubjectPublicKeyInfo sequence [RFC5280]. Conforming client implementations that process RSASSA-PSS with SHAKE public keys when processing certificates and CRLs MUST recognize the corresponding OIDs. Conforming CA implementations MUST specify the X.509 public key algorithm explicitly by using the OIDs specified in Section 4 when encoding ECDSA with SHAKE public keys in certificates and CRLs. Conforming client implementations that process ECDSA with SHAKE public keys when processing certificates and CRLs MUST recognize the corresponding OIDs. The identifier parameters, as explained in Section 4, MUST be absent. 6. IANA Considerations One object identifier for the ASN.1 module in Appendix A is requested for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) registry: +---------+--------------------------+--------------------+ | Decimal | Description | References | +---------+--------------------------+--------------------+ | TBD | id-mod-pkix1-shakes-2019 | [EDNOTE: THIS RFC] | +---------+--------------------------+--------------------+ IANA is requested to update the SMI Security for PKIX Algorithms [SMI-PKIX] (1.3.6.1.5.5.7.6) registry with four additional entries: Kampanakis & Dang Expires January 22, 2020 [Page 9] Internet-Draft SHAKE identifiers in X.509 July 2019 +---------+------------------------+--------------------+ | Decimal | Description | References | +---------+------------------------+--------------------+ | TBD1 | id-RSASSA-PSS-SHAKE128 | [EDNOTE: THIS RFC] | | TBD2 | id-RSASSA-PSS-SHAKE256 | [EDNOTE: THIS RFC] | | TBD3 | id-ecdsa-with-shake128 | [EDNOTE: THIS RFC] | | TBD4 | id-ecdsa-with-shake256 | [EDNOTE: THIS RFC] | +---------+------------------------+--------------------+ IANA is also requested to update the Hash Function Textual Names Registry [Hash-Texts] with two additional entries for SHAKE128 and SHAKE256: +--------------------+-------------------------+--------------------+ | Hash Function Name | OID | Reference | +--------------------+-------------------------+--------------------+ | shake128 | 2.16.840.1.101.3.4.2.11 | [EDNOTE: THIS RFC] | | shake256 | 2.16.840.1.101.3.4.2.12 | [EDNOTE: THIS RFC] | +--------------------+-------------------------+--------------------+ 7. Security Considerations This document updates [RFC3279]. The security considerations section of that document applies to this specification as well. NIST has defined appropriate use of the hash functions in terms of the algorithm strengths and expected time frames for secure use in Special Publications (SPs) [SP800-78-4] and [SP800-107]. These documents can be used as guides to choose appropriate key sizes for various security scenarios. SHAKE128 with output length of 256-bits offers 128-bits of collision and preimage resistance. Thus, SHAKE128 OIDs in this specification are RECOMMENDED with 2048 (112-bit security) or 3072-bit (128-bit security) RSA modulus or curves with group order of 256-bits (128-bit security). SHAKE256 with 512-bits output length offers 256-bits of collision and preimage resistance. Thus, the SHAKE256 OIDs in this specification are RECOMMENDED with 4096-bit RSA modulus or higher or curves with group order of at least 521-bits (256-bit security). Note that we recommended 4096-bit RSA because we would need 15360-bit modulus for 256-bits of security which is impractical for today's technology. 8. Acknowledgements We would like to thank Sean Turner, Jim Schaad and Eric Rescorla for their valuable contributions to this document. Kampanakis & Dang Expires January 22, 2020 [Page 10] Internet-Draft SHAKE identifiers in X.509 July 2019 The authors would like to thank Russ Housley for his guidance and very valuable contributions with the ASN.1 module. 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, . [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002, . [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, . [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, . [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, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Kampanakis & Dang Expires January 22, 2020 [Page 11] Internet-Draft SHAKE identifiers in X.509 July 2019 [SHA3] National Institute of Standards and Technology (NIST), "SHA-3 Standard - Permutation-Based Hash and Extendable- Output Functions FIPS PUB 202", August 2015, . 9.2. Informative References [Hash-Texts] IANA, "Hash Function Textual Names", July 2017, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [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, . [SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", May 2009, . [SMI-PKIX] IANA, "SMI Security for PKIX Algorithms", March 2019, . [SP800-107] National Institute of Standards and Technology (NIST), "SP800-107: Recommendation for Applications Using Approved Hash Algorithms", May 2014, . [SP800-78-4] National Institute of Standards and Technology (NIST), "SP800-78-4: Cryptographic Algorithms and Key Sizes for Personal Identity Verification", May 2014, . Kampanakis & Dang Expires January 22, 2020 [Page 12] Internet-Draft SHAKE identifiers in X.509 July 2019 [X9.62] American National Standard for Financial Services (ANSI), "X9.62-2005: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA)", November 2005. Appendix A. ASN.1 module This appendix includes the ASN.1 module for SHAKEs in X.509. This module does not come from any existing RFC. PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-shakes-2019(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL; IMPORTS -- FROM [RFC5912] PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS 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) } -- FROM [RFC5912] RSAPublicKey, rsaEncryption, pk-rsa, pk-ec, CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms2008-02(56) } ; -- -- Message Digest Algorithms (mda-) -- DigestAlgorithms DIGEST-ALGORITHM ::= { -- This expands DigestAlgorithms from [RFC5912] mda-shake128 | mda-shake256, ... } Kampanakis & Dang Expires January 22, 2020 [Page 13] Internet-Draft SHAKE identifiers in X.509 July 2019 -- -- One-Way Hash Functions -- -- SHAKE128 mda-shake128 DIGEST-ALGORITHM ::= { IDENTIFIER id-shake128 -- with output length 32 bytes. } id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 11 } -- SHAKE256 mda-shake256 DIGEST-ALGORITHM ::= { IDENTIFIER id-shake256 -- with output length 64 bytes. } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 12 } -- -- Public Key (pk-) Algorithms -- PublicKeys PUBLIC-KEY ::= { -- This expands PublicKeys from [RFC5912] pk-rsaSSA-PSS-SHAKE128 | pk-rsaSSA-PSS-SHAKE256, ... } -- The hashAlgorithm is mda-shake128 -- The maskGenAlgorithm is id-shake128 -- Mask Gen Algorithm is SHAKE128 with output length -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA -- modulus in bits. -- The saltLength is 32. The trailerField is 1. pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= { IDENTIFIER id-RSASSA-PSS-SHAKE128 KEY RSAPublicKey PARAMS ARE absent -- Private key format not in this module -- CERT-KEY-USAGE { nonRepudiation, digitalSignature, keyCertSign, cRLSign } } -- The hashAlgorithm is mda-shake256 Kampanakis & Dang Expires January 22, 2020 [Page 14] Internet-Draft SHAKE identifiers in X.509 July 2019 -- The maskGenAlgorithm is id-shake256 -- Mask Gen Algorithm is SHAKE256 with output length -- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA -- modulus in bits. -- The saltLength is 64. The trailerField is 1. pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= { IDENTIFIER id-RSASSA-PSS-SHAKE256 KEY RSAPublicKey PARAMS ARE absent -- Private key format not in this module -- CERT-KEY-USAGE { nonRepudiation, digitalSignature, keyCertSign, cRLSign } } -- -- Signature Algorithms (sa-) -- SignatureAlgs SIGNATURE-ALGORITHM ::= { -- This expands SignatureAlgorithms from [RFC5912] sa-rsassapssWithSHAKE128 | sa-rsassapssWithSHAKE256 | sa-ecdsaWithSHAKE128 | sa-ecdsaWithSHAKE256, ... } -- -- SMIME Capabilities (sa-) -- SMimeCaps SMIME-CAPS ::= { -- The expands SMimeCaps from [RFC5912] sa-rsassapssWithSHAKE128.&smimeCaps | sa-rsassapssWithSHAKE256.&smimeCaps | sa-ecdsaWithSHAKE128.&smimeCaps | sa-ecdsaWithSHAKE256.&smimeCaps, ... } -- RSASSA-PSS with SHAKE128 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-RSASSA-PSS-SHAKE128 PARAMS ARE absent -- The hashAlgorithm is mda-shake128 -- The maskGenAlgorithm is id-shake128 -- Mask Gen Algorithm is SHAKE128 with output length -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA -- modulus in bits. -- The saltLength is 32. The trailerField is 1 Kampanakis & Dang Expires January 22, 2020 [Page 15] Internet-Draft SHAKE identifiers in X.509 July 2019 HASHES { mda-shake128 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } } id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD1 } -- RSASSA-PSS with SHAKE256 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-RSASSA-PSS-SHAKE256 PARAMS ARE absent -- The hashAlgorithm is mda-shake256 -- The maskGenAlgorithm is id-shake256 -- Mask Gen Algorithm is SHAKE256 with output length -- (8*ceil((n-1)/8) - 520)-bits, where n is the -- RSA modulus in bits. -- The saltLength is 64. The trailerField is 1. HASHES { mda-shake256 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD2 } -- ECDSA with SHAKE128 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-shake128 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake128 } PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } } id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD3 } -- ECDSA with SHAKE256 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-shake256 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake256 } Kampanakis & Dang Expires January 22, 2020 [Page 16] Internet-Draft SHAKE identifiers in X.509 July 2019 PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD4 } END Authors' Addresses Panos Kampanakis Cisco Systems Email: pkampana@cisco.com Quynh Dang NIST 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899-8930 USA Email: quynh.dang@nist.gov Kampanakis & Dang Expires January 22, 2020 [Page 17] ./draft-iab-fiftyyears-01.txt0000644000764400076440000020650113523323133015344 0ustar iustyiusty Network Working Group H. Flanagan, Ed. Internet-Draft RFC Editor Updates2555, 5540 (if approved) August 9, 2019 Intended status: Informational Expires: February 10, 2020 Fifty Years of RFCs draft-iab-fiftyyears-01 Abstract This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points, as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540. 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 https://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 10, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Flanagan Expires February 10, 2020 [Page 1] Internet-Draft Fifty Years of RFCs August 2019 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. Key Moments in RFC History . . . . . . . . . . . . . . . . . 4 3. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The Origins of RFCs - by Stephen D. Crocker . . . . . . 6 3.2. The RFC Management and Editing Team - Vint Cerf . . . . . 11 3.3. Formalizing the RFC Editor Model - Leslie Daigle . . . . 11 3.4. The Continuation, or Creation, of a Stream - Nevil Brownlee . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. A View from Inside the RFC Editor - Sandy Ginoza . . . . 16 4. The Next Fifty Years of RFCs . . . . . . . . . . . . . . . . 20 4.1. Preservation . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Evolution of the RFC Format . . . . . . . . . . . . . . . 20 4.3. Stream Structure . . . . . . . . . . . . . . . . . . . . 21 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Informative References . . . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The RFC Series began in April 1969 with the publication of "Host Software" by Steve Crocker. The early RFCs were, in fact, requests for comments on ideas and proposals; the goal was to start conversations, rather than to create an archival record of a standard or best practice. This goal changed over time, as the formality of the publication process evolved, and the community consuming the material grew. Today, over 8500 RFCs have been published, ranging across best practice information, experimental protocols, informational material, and, of course, Internet standards. Material is accepted for publication through the IETF, the IAB, the IRTF, and the Independent Submissions stream, each with clear processes on how drafts are submitted and potentially approved for publication as an RFC. Ultimately, the goal of the RFC Series is to provide a canonical source for the material published by the RFC Editor, and to support the preservation of that material in perpetuity. The RFC Editor as a role came a few years after the first RFC was published. The actual date when the term was first used is unknown, but it was formalized by [RFC0902] in July 1984; Jon Postel, the first RFC Editor, defined the role by his actions and later by Flanagan Expires February 10, 2020 [Page 2] Internet-Draft Fifty Years of RFCs August 2019 defining the initial processes surrounding the publication of RFCs. What is certain is that the RFC Editor is responsible for making sure that the editorial quality of the RFCs published is high, and that the archival record of what has been published is maintained. Change does come to the Series, albeit slowly. First, we saw the distribution method change from postal mail to FTP and email. RFCs could not be distributed electronically from the beginning, as the means to do that distribution would not be defined until years after the first RFC was published. Not all early RFCs were even created electronically; some were written out by hand, or on a typewriter. Eventually the process for creating RFCs became more structured; authors were provided guidance on how to write an RFC. The editorial staff went from one person, Jon Postel, to a team of five to seven. The actual editing and publishing work split from the service for registration of protocol code points. The whole RFC Editor structure was reviewed [RFC4844] and refined [RFC5620] and refined again [RFC6635]. And, in the last few years, we have started the process to change the format of the RFC documents themselves. This is evolution, and the Series will continue to adapt in order to meet the needs and expectations of the community of authors, operators, historians, and users of the RFC Series. These changes will be always be balanced against the core mission of the Series: to maintain a strong, stable, archival record of technical specifications, protocols, and other information relevant to the ARPANET and Internet networking communities. There is more to the history of the RFC Series than can be covered in this document. Readers interested in earlier perspectives may find the following RFCs of particular interest that focus on the enormous contributions of Jon Postel, Czar of Socket Numbers [RFC0433] and first RFC Editor: [RFC2441]"Working with Jon, Tribute delivered at UCLA" [RFC2555]"30 Years of RFCs" [RFC5540]"40 Years of RFCs" In this document, the history of the series is viewed through the eyes of several individuals who have been a part of shaping the Series. Narratives of this nature offer a limited perspective on events; there are almost certainly other viewpoints, memories, and perspective on events that are equally valid and would reflect a different history. So, while these retrospectives are enormously valuable and provide an insight to events of the day, they are just one lens on the history of the RFC Series. Flanagan Expires February 10, 2020 [Page 3] Internet-Draft Fifty Years of RFCs August 2019 Steve Crocker, author of RFC 1, offers his thoughts on how and why the Series began. Leslie Daigle, a major influence in the development of the RFC Editor model, offers her thoughts on the change of the RFC Editor to a stronger, contracted function. Nevil Brownlee, Independent Submissions Editor from 2010 through February 2018, shares his view on the clarification of the IS and its transition from Bob Braden. As the current RFC Series Editor, I will put my thoughts in on the most recent changes in formalizing the digital preservation of the Series, the process to modernize the format while respecting the need for stability, and my thoughts on the next fifty years of RFCs. This document updates the perspectives offered in RFCs 2555 and 5540. 2. Key Moments in RFC History +--------------------+-----------+---------------------------------+ | Marker | Date | Event | +====================+===========+=================================+ | [RFC0001] | 1969 | First RFC published | +--------------------+-----------+---------------------------------+ | [RFC0114] | 1971 | First distribution of RFCs over | | | | the network | +--------------------+-----------+---------------------------------+ | [RFC0433] | December | First mention of the Czar of | | | 1972 | Socket Numbers and the proposal | | | | for a formal registry | +--------------------+-----------+---------------------------------+ | [RFC0690] | June 1975 | Relationship starts between ISI | | | | and the RFC Editor, judging by | | | | Jon Postel's affiliation change | +--------------------+-----------+---------------------------------+ | [RFC0748] | March | First April 1st RFC | | | 1977 | | +--------------------+-----------+---------------------------------+ | [IETF1] | January | First Internet Engineering Task | | | 1986 | Force (IETF) meeting | +--------------------+-----------+---------------------------------+ | [RFC1083] | October | Three stage standards process | | | 1989 | first defined | +--------------------+-----------+---------------------------------+ | [RFC1122][RFC1123] | December | First major effort to review | | | 1988 | key specifications and write | | | | applicability statements | +--------------------+-----------+---------------------------------+ | [RFC1150] | March | FYI sub-series started | | | 1990 | | +--------------------+-----------+---------------------------------+ Flanagan Expires February 10, 2020 [Page 4] Internet-Draft Fifty Years of RFCs August 2019 | [RFC1311] | March | STD sub-series started | | | 1992 | | +--------------------+-----------+---------------------------------+ | [RFC1818] | August | BCP sub-series started | | | 1995 | | +--------------------+-----------+---------------------------------+ | [RFC-ONLINE] | (approx) | RFC Online Project to restore | | | 1998-2010 | lost early RFCs | +--------------------+-----------+---------------------------------+ | [IAB-19880712] | July 1988 | IAB approved the creation of an | | | | Internet Draft series | +--------------------+-----------+---------------------------------+ | [RFC2441] | 15 | Jon Postel's death | | | October | | | | 1998 | | +--------------------+-----------+---------------------------------+ | [ISI-to-AMS] | October | Transition starts from ISI to | | | 2009 | Association Management | | | | Solutions (AMS) | +--------------------+-----------+---------------------------------+ | [RFC4844] | July 2007 | RFC Stream structure | +--------------------+-----------+---------------------------------+ | [RFC4846] | July 2007 | Formalize the Independent | | | | Submission document stream | +--------------------+-----------+---------------------------------+ | [RFC5743] | December | Formalize the Internet Research | | | 2009 | Task Force document stream | +--------------------+-----------+---------------------------------+ | [RFC6360] | August | FYI sub-series ended | | | 2011 | | +--------------------+-----------+---------------------------------+ | [RFC6410] | October | Two stage standards process | | | 2011 | formalized | +--------------------+-----------+---------------------------------+ | [RFC6949] | May 2013 | RFC Format change project | | | | started | +--------------------+-----------+---------------------------------+ | [RFC8153] | April | RFCs no longer printed to paper | | | 2017 | upon publication | +--------------------+-----------+---------------------------------+ Table 1: Key Moments in RFC History 3. Perspectives Flanagan Expires February 10, 2020 [Page 5] Internet-Draft Fifty Years of RFCs August 2019 3.1. The Origins of RFCs - by Stephen D. Crocker [This is a revision of material included in [RFC1000] August 1987, more than thirty years ago.] The Internet community now includes millions of nodes and billions of users. It owes its beginning to the ARPANET, which was once but a gleam in the eyes of J. C. R. Licklider, Bob Taylor, and Larry Roberts of ARPA. While much of the development proceeded according to plan, the initial design of the protocols and the creation of the RFCs was largely accidental. The procurement of the ARPANET was initiated in the summer of 1968 --remember Vietnam, flower children, etc.? There had been prior experiments at various ARPA sites to link together computer systems, but this was the first version to explore packet-switching as a core part of the communication strategy. ("ARPA" didn't become "DARPA" until 1972. It briefly changed back to ARPA in 1993 and then back again to DARPA.) The government's Request for Quotations (RFQ) called for four packet-switching devices, called Interface Message Processors ("IMPs"), to be delivered to four sites in the western part of the United States: University of California, Los Angeles (UCLA); SRI International in Menlo Park, CA; University of California, Santa Barbara; the University of Utah in Salt Lake City. These sites, respectively, were running a Scientific Data Systems (SDS) Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10. These machines not only had different operating systems, but even details like character sets and byte sizes varied, and other sites would have further variations. The focus was on the basic movement of data. The precise use of the ARPANET was not spelled out in advance, thus requiring the research community to take some initiative. To stimulate this process, a meeting was called in August 1968 with representatives from the selected sites, chaired by Elmer Shapiro from SRI. Based on Shapiro's notes from that meeting, the attendees were Dave Hopper and Jeff Rulifson from SRI, Glen Culler and Gordon Buck from Santa Barbara, R. Stephenson, C. Stephen Carr and W. Boam from Utah, Vint Cerf and me from UCLA, and a few others from potential future sites. That first meeting was seminal. We had lots of questions. How IMPs and "hosts" (I think that was the first time I was exposed to that term) would be connected? What would hosts say to each other? What applications would be supported? The only concrete answers were remote login as a replacement for dial-up, telephone based interactive terminal access, and file transfer, but we knew the vision had to be larger. We found ourselves imagining all kinds of Flanagan Expires February 10, 2020 [Page 6] Internet-Draft Fifty Years of RFCs August 2019 possibilities -- interactive graphics, cooperating processes, automatic data base query, electronic mail -- but no one knew where to begin. We weren't sure whether there was really room to think hard about these problems; surely someone senior and in charge, likely from the East, would be along by and by to bring the word. But we did come to one conclusion: we ought to meet again. Over the next several months, we met at each of our sites, thereby setting the precedent for regular face to face meetings. We also instantly felt the irony. This new network was supposed to make it possible to work together at a distance, and the first thing we did was schedule a significant amount of travel. Over the next several months, a small, fairly consistent set of graduate students and staff members from the first four sites met. We used the term Network Working Group (NWG) to designate ourselves. This was the same term Elmer Shapiro had used when he convened our first meeting, although it had been used until that point to refer to the principal investigators and ARPA personnel -- senior people who had been planning the network. Our group was junior and disjoint from the prior group, except, of course, that each of us worked for one of the principal investigators. The first few meetings were quite tenuous, primarily because we weren't sure how narrow or expansive our goals should be. We had no official charter or leadership, and it remained unclear, at least to me, whether someone or some group would show up with the official authority and responsibility to take over the problems we were dealing with. Without clear definition of what the host-IMP interface would look like, or even a precise definition of what functions the IMP would provide, we focused on broader ideas. We envisioned the possibility of application specific protocols, with code downloaded to user sites, and we took a crack at designing a language to support this. The first version was known as DEL, for "Decode-Encode Language" and a later version was called NIL, for "Network Interchange Language." In late 1968 Bolt Beranek and Newman (BBN) in Cambridge, MA won the contract for the IMPs and began work in January 1969. A few of us flew to Boston in the middle of February to meet the BBN crew. The BBN folks, led by Frank Heart, included Bob Kahn, Severo Ornstein, Ben Barker, Will Crowther, Bernie Cosell and Dave Walden. They were organized, professional and focused. Their first concern was how to meet their contract schedule of delivering the first IMP to UCLA at the beginning of September and how to get bits to flow quickly and reliably. The details of the host-IMP interface were not yet firm; the specification came a few months later as BBN Report 1822. In particular, BBN didn't take over our protocol design process, nor did Flanagan Expires February 10, 2020 [Page 7] Internet-Draft Fifty Years of RFCs August 2019 any other source of authority appear. Thus, we doggedly continued debating and designing the protocols. A month later our small NWG met in Utah. As the meeting came toward an end, it became clear to us that we should start writing down our discussions. We had accumulated a few notes on the design of DEL and other matters, and we decided to put them together in a set of notes. We assigned writing chores to each of us, and I took on the additional task of organizing the notes. Though I initiated the RFCs, my role was far less than an editor. Each of the RFCs were numbered in sequence. The only rule I imposed was the note had to be complete before I assigned a number because I wanted to minimize the number of holes in the sequence. I tried a couple of times to write a note on how the notes would be organized, but I found myself full of trepidation. Would these notes look as if we were asserting authority we didn't have? Would we unintentionally offend whomever the official protocol designers were? Finally, unable to sleep, I wrote the a few humble words. The basic ground rules were that anyone could say anything and that nothing was official. And to emphasize the point, I used Bill Duvall's suggestion and labeled the notes "Request for Comments." I never dreamed these notes would eventually be distributed through the very medium we were discussing in these notes. Talk about Sorcerer's Apprentice! After BBN distributed the specification for the hardware and software interface to the IMPs to the initial ARPANET sites, our attention shifted to low-level matters. The ambitious ideas for automatic downloading of code evaporated. It would be several years before ideas like mobile code, remote procedure calls, ActiveX, JAVA and RESTful interfaces appeared. Over the spring and summer of that year we grappled with the detailed problems of protocol design. Although we had a vision of the vast potential for intercomputer communication, designing usable protocols was another matter. We knew a custom hardware interface and a custom software addition in the operating system was going to be required for anything we designed, and we anticipated these would pose some difficulty at each of the sites. We looked for existing abstractions to use. It would have been convenient if we could have made the network simply look like a regular device, e.g., a tape drive, but we knew that wouldn't do. The essence of this network was peer-to-peer cooperation among the machines and the processes running inside them, not a central machine controlling dependent devices. We settled on a virtual bit stream layer as the basic building block for the protocols, but even back then we knew that some applications like voice might need to avoid that layer of software. (Why a virtual bit Flanagan Expires February 10, 2020 [Page 8] Internet-Draft Fifty Years of RFCs August 2019 stream instead of a virtual byte stream? Because each computer had its own notion of how many bits were in a byte. Eight-bit bytes didn't become standard until a few years later.) Over the next two years, we developed, exchanged, and implemented ideas. I took a leave from UCLA in June 1971 to spend time working at ARPA. Jon Postel took over the care and feeding of the RFCs, evolving the process and adding collaborators over the next twenty- seven years. The rapid growth of the network and the working group also led to a large pile of RFCs. When the 100th RFC was in sight, Peggy Karp at MITRE took on the task of indexing them. That seemed like a large task then, and we could have hardly anticipated seeing more than a 1000 RFCs several years later, and the evolution toward Internet Drafts yet later. When we first started working on the protocols, the network did not exist. Except for our occasional face-to-face meetings, RFCs were our only means of communication. In [RFC0003], I set the bar as low as possible: The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished. Philosophical positions without examples or other specifics, specific suggestions or implementation techniques without introductory or background explication, and explicit questions without any attempted answers are all acceptable. The minimum length for a NWG note is one sentence. These standards (or lack of them) are stated explicitly for two reasons. First, there is a tendency to view a written statement as ipso facto authoritative, and we hope to promote the exchange and discussion of considerably less than authoritative ideas. Second, there is a natural hesitancy to publish something unpolished, and we hope to ease this inhibition. Making the RFCs informal was not only a way of encouraging participation; it was also important in making the communication effective. One of the early participants said he was having trouble writing and sending an RFC because his institution wanted to subject them to publication review. These are not "publications," I declared, and the problem went away. Another small detail, handled instinctively and without debate, was the distribution model. Each institution was required to send a copy directly to each of the other handful of participating institutions. Each institution handled internal copies and distribution itself. Submission to a central Flanagan Expires February 10, 2020 [Page 9] Internet-Draft Fifty Years of RFCs August 2019 point for redistribution was not required, so as to minimize delays. SRI's Network Information Center, however, did maintain a central repository of everything and provided an invaluable record. We didn't intentionally set out to challenge the existing standards organizations, but our natural mode of operation yielded some striking results. The RFCs are open in two important respects: anyone can write one for free and anyone get them for free. At the time, virtually everyone in the ARPANET community was sponsored by the government, so there was little competition and no need to use documents as a way of raising money. Of course, as soon as we had email working on the ARPANET, we distributed RFCs electronically. When the ARPANET became just a portion of the Internet, this distribution process became worldwide. The effect of this openness is often overlooked. Students and young professionals all over the world have been able to download the RFCs, learn about the many pieces of technology, and then build the most amazing software. And they still are. [They are also a fantastic resource for historians.] Where will it end? The ARPANET begat the Internet and the underlying technology transitioned from the original host-host protocol to TCP/ IP, but the superstructure of protocol layers, community driven protocol design, and the RFCs continued. Through the many changes in physical layer technology - analog copper circuits, digital circuits, fiber and wireless -- resulting in speed increases from thousands to billions of bits per second and a similar increase from thousands to billions of users, this superstructure, including the RFCs has continued to serve the community. All of the computers have changed, as have all of the transmission lines. But the RFCs march on. Maybe I'll write a few words for RFC 10,000. Quite obviously the circumstances have changed. Email and other media are most often used for the immediate exchange of inchoate thoughts. Internet Drafts are the means for exchanging substantial, albeit sometimes speculative content. And RFCs are reserved for fully polished, reviewed, edited and approved specifications. Comments to RFCs are not requested, although usage-related discussions and other commentary on mailing lists often takes place nonetheless. Rather than bemoan the change, I take it as a remarkable example of adaptation. RFCs continue to serve the protocol development community. Indeed, they are the bedrock of a very vibrant and productive process that has fueled and guided the Internet revolution. Flanagan Expires February 10, 2020 [Page 10] Internet-Draft Fifty Years of RFCs August 2019 3.2. The RFC Management and Editing Team - Vint Cerf As Steve Crocker mentions in Section 3.1, Jon Postel assumed the role of RFC manager in 1971 when Steve left UCLA for ARPA. Jon took on this role in addition to his subsequent "numbers Czar" responsibilities. Initially, his focus was largely on assigning RFC numbers to aspiring writers but with time, and as the standardization of the ARPANET and Internet protocols continued apace, he began to serve in an editorial capacity. Moreover, as an accomplished software engineer, he had opinions about technical content in addition to writing style and did not hesitate to exercise editorial discretion as would-be published authors presented their offerings for his scrutiny. As the load increased, he recruited additional "volunteer" talent, most notably Joyce K. Reynolds, a fellow researcher at USC/ISI. Over the ensuing years, he also drafted Robert (Bob) Braden into the team and when Jon unexpectedly passed away in October 1998 (see [RFC2468]), Joyce and Bob undertook to carry on with the RFC work in his stead, adding Sandy Ginoza to the team. During the period when Jon and Joyce worked closely together, Joyce would challenge me to tell which edits had been made by Jon and which by her. I found this impossible, so aligned were they in their editorial sensibilities. Sadly, three of these tireless Internauts have passed on and we have only the product of their joint work and Sandy Ginoza's and others' corporate memory by which to recall history. 3.3. Formalizing the RFC Editor Model - Leslie Daigle I was the chair of the Internet Architecture Board, the board responsible for the general oversight of the RFC Series, at a particular inflection point in the evolution of all Internet technology institutions. To understand what we did, and why we had to, let me first paint a broader picture of the arc of these institutions. Like many others who were in decision-making roles in the mid -00's, I wasn't present when the Internet was born. The lore passed down to me was that, out of the group of talented researchers that developed the core specifications and established the direction of the Internet, different individuals stepped up to take on roles necessary to keep the process of specification development organized and open. As the work of specification expanded, those individuals were generally supported by organizations that carried on in the same spirit. This was mostly Jon Postel, managing the allocation and assignment of names and numbers, as well as working as the editor of RFCs, but there were also individuals and institutions supporting the IETF's Secretariat function. By the late 20th century, even this model was wearing thin - the support functions were growing, and Flanagan Expires February 10, 2020 [Page 11] Internet-Draft Fifty Years of RFCs August 2019 organizations didn't have the ability to donate even more resources to run them. In some cases (IANA) there was significant industry and international dependence on the function and its neutrality. The IETF, too, had grown in size, stature, and commercial reliance. This system of institutional pieces "flying in formation" was not providing the kind of contractual regularity or integrated development that the IETF needed. People who hadn't been there as the institutions developed, including IETF decision-makers, didn't innately understand why things "had to be the way they were", and were frustrated when trying to get individual systems updated for new requirements, and better integrated across the spectrum of activities. Internet engineering had expanded beyond the point of being supportable by a loosely-coupled set of organizations of people who had been there since the beginning and knew each other well. New forms of governance were needed, as well as a rationalized funding model. The IANA function was absorbed into a purpose-built international not-for-profit organization. The IETF stepped up to manage its own organizational destiny, creating the IETF Administrative Support Activity (IASA), and the Secretariat became one of its contracted functions. This left the RFC Editor function as an Internet Society-supported, independent effort. That independent nature was necessary for the historic role of the RFC Series in considering all technical contributions. But, at that inflection point in the Series' history, it needed a new governance and funding model, just as the other Internet technical specification supporting organizations had. Also, the IETF leadership had some concerns it felt needed to be addressed in its own technical publication stream. While the RFC Series had been established before there was an IETF, and had historically continued to have documents in it that didn't originate from the IETF, the IETF was its largest and most organized contributor. There was no particular organization of independent contributors. Equally, the funding for the RFC Editor was at that point coming from the Internet Society in the guise of "support for the IETF". For people who hadn't been involved with the institution from the outset, it was pretty easy to perceive the RFC Series uniquely as the IETF's publication series. So, the challenge was to identify and address the IETF's issues, along with governance and funding, without sacrificing the fundamental nature of the RFC Series as a broader-than-IETF publication series. To give a sense of the kinds of tensions that were prevalent, let me share that the one phrase that sticks in my mind from those Flanagan Expires February 10, 2020 [Page 12] Internet-Draft Fifty Years of RFCs August 2019 discussions is: "push to publish". There were those in IETF leadership who felt that it would significantly reduce costs and improve timeliness if an RFC could be published by, literally, pushing a button on a web interface the moment it was approved by the IESG. It would also, they argued, remove the specification issues being introduced by copy-editors that were hired as occasional workers to help with improving publication rates, but who weren't necessarily up to speed on terms of art in technical specifications. (There were some pretty egregious examples of copyeditors introducing changes that significantly changed the technical meaning of the text that I forbear from citing here; let's just say it wasn't strictly a problem of Internet engineers getting uptight about their cheese being moved.) While "push to publish" would have addressed those issues, it would not have addressed the loss of clarity from the many significant text improvements copy editors successfully introduced, or the fact that not all RFCs are approved by the IESG. Institutionally, it was clear that the target was to have the RFC Editor function governance within the reach of the Internet technical community (as opposed to any particular private organization), without tying it specifically to the IETF. That was reasonably achievable by ensuring that the resultant pieces were established under the oversight of the IAB (which is, itself, independent of the IETF, even as it is supported by the IASA organization). The IETF worked on a document outlining functional requirements for its technical specification publication. This could have been useful for establishing its own series, but it also was helpful in establishing awareness of the challenges in document publishing (it always looks easy when you haven't thought about it), and also to lay the ground work for dialogue with the RFC Editor. The requirements document was published as [RFC4714], as an Informational RFC that stands today to provide guidance in the editing processes surrounding IETF publications. There was still, however, a certain lack of clarity about responsibilities for making decisions and changes in the RFC Series itself. To that end, I and the IAB worked with the various involved parties to produce [RFC4844]. That document captured the RFC Series mission (for a purpose greater than IETF technical specification publication), as well as the roles and responsibilities of the parties involved. The RFC Editor has responsibility for ensuring the implementation of the mission. The IAB continues to have oversight responsibilities, including policy oversight, which it could act on by changing the person (organization) in the role of RFC Editor. At the same time, operational oversight was migrated to the IASA support function of the IETF (and IAB). Flanagan Expires February 10, 2020 [Page 13] Internet-Draft Fifty Years of RFCs August 2019 The discussions, and the resulting publication of RFC 4844, allowed greater visibility into and commitment to the RFC Series, as a general Internet publication. It also meant that subsequent adjustments could be made, as requirements evolved - the responsible parties are clearly identified. 3.4. The Continuation, or Creation, of a Stream - Nevil Brownlee Arguably starting in 2006 with [RFC4714], the IAB and the IETF community spent some time in the mid-2000's evolving the structure of the RFC Series. This work included defining how those groups that published into the RFC Series (initially including the IETF, the IAB [RFC4845], and the Independent Submissions stream [RFC4846], and later growing to include the IRTF [RFC5743]) would handle approving documents to be published as RFCs. In 2009, the IAB published 'RFC Editor (Version 1)' [RFC5620]. In this model, a new role was created within the RFC Editor, the RFC Series Editor (RSE), an individual that would oversee RFC publishing and development, while leaving the process for approving documents for publication outside his or her mandate. While arguably this was a role long filled by people like Jon Postel, Bob Braden, and Joyce Reynolds, RFC 5620 saw the role of RFC Series Editor defined in such a way as to distinctly separate it from that of the Independent Submissions Editor (ISE). Before 2009 the RFC Editor could accept 'Independent' submissions from individuals, and - if he judged they were significant - publish them as RFCs; the Independent Stream was set up to continue that function. From February 2010 through February 2018, I was the Independent Stream Editor (ISE) and I began by reading [RFC4846], then went on to develop the Independent Stream (IS). First I spent several days at the RFC Production Centre at ISI in Marina Del Ray with the RFC Editor (Bob Braden) and Sandy Ginoza and Alice Hagens, so as to learn how RFCs were actually edited and published. All RFCs reach the Production Centre as Internet Drafts; they are copy-edited, until the edited version can be approved by their authors (AUTH48). At any stage authors can check their draft's status in the RFC Editor Database. For the Independent Submissions, Bob kept a journal (a simple ASCII file) of his interactions with authors for every draft, indexed by the draft name. Bob also entered the Independent drafts into the RFC Editor database, so that authors could track their draft's status. After my few days with his team at ISI, he handed that journal (covering about 30 drafts) over to me and said "now it's over to you!" Flanagan Expires February 10, 2020 [Page 14] Internet-Draft Fifty Years of RFCs August 2019 I began by following in Bob's footsteps, maintaining a journal and tracking each draft's status in the RFC Editor database. My first consideration was that every serious Internet draft submitted needs several careful reviews. If the ISE knows suitable reviewers, he can simply ask them. Otherwise, if the draft relates to an IETF or IRTF Working Group, he can ask Working Group chairs or Area Directors to suggest reviewers. As well, the ISE has an Independent Submissions Editorial Board (Ed Board) that he can ask for reviewers. My experience with reviewers was that most of those I approached were happy to help. Most drafts were straightforward, but there were some that needed extra attention. Often a draft requests IANA code points, and for that IANA were always quick to offer help and support. Code points in some IANA Registries require Expert Review - sometimes the interactions with Expert reviewers took quite a long time! Again, sometimes a draft seemed to fit better in the IETF Stream; for these I would suggest that the draft authors try to find an Area Director to sponsor their work as in Individual submission to the IETF Stream. After my first few years as ISE, the IETF Tools Team developed the Data Tracker so that it could keep show draft status, and perform all the 'housekeeping' tasks for all of the streams. At that stage I switched to use the Data Tracker rather than the RFC Editor database. Once a draft has been reviewed, and the authors have revised it in dialogue with their reviewers, the ISE must submit that draft to the IESG for their "Conflict Review" [RFC5742]. Overall, each IS draft benefited from discussions (which were usually simple) with my Ed Board and the IESG. A (very) few drafts were somewhat controversial - for those I was able to work with the IESG to negotiate a suitable 'IESG Statement' and/or an 'ISE Statement' to make it clearer why the ISE published the draft. One rather special part of the Independent Stream is the April First drafts. These are humorous RFCs that are never formally posted as drafts and which have no formal review process. The authors must send them directly to the ISE or the RFC Editor. Only a few of them can be published each year; they are reviewed by the ISE and the RSE; Bob Braden's criteria for April First drafts were: They must relate to the Internet (like all drafts) Their readers should reach the end of page two before realizing this is an April First RFC They must actually be funny! Flanagan Expires February 10, 2020 [Page 15] Internet-Draft Fifty Years of RFCs August 2019 April First RFCs have a large following, and feedback from the Internet community on 1 April each year has been enthusiastic and quick! I published 159 Independent Stream RFCs during my eight years as ISE. Over those eight years I worked with, and often met with at IETF meetings, most of their authors. For me that was a very rewarding experience, so I thank all those contributors. Also, I've worked with most of the IESG members during those eight years, that also gave me a lot of helpful interaction. Last, I've always enjoyed working with the RFC Editor, and all the staff of the RFC Production Centre. The IETF (as a whole) is very fortunate to have such an effective team of talented Professional Staff. 3.5. A View from Inside the RFC Editor - Sandy Ginoza When I joined ISI, shortly after Jon Postel passed away, the RFC Editor as we know it today (as defined in RFC 5620, and as obsoleted by [RFC6548] and RFC 6635) did not exist. The RFC Editor functioned as one unit; there was no RSE, Production Center, Publisher, or Independent Submissions Editor. All of these roles were performed by the RFC Editor, which was comprised of four individuals: Bob Braden, Joyce Reynolds, a part-time student programmer, and me. Bob provided high-level guidance and reviewed Independent Submissions. While Bob was a researcher in "Div 7" (Networking) at ISI, ostensibly, the percentage of time he had for the RFC Editor was 10%, but he invested much more time to keep the series running. He pitched in where he could, especially when processing times were getting longer; at one point, he even NROFFed a couple of RFCs-to-be. Joyce was a full-time employee, but while continuing to ensure RFCs were published and serve as a User Services Area Director and a keynote speaker about the Internet, she was also temporarily on loan to IANA for 50% of her time while IANA was getting established after separating from ISI. The student programmer performed programming tasks as requested and was, at the time, responsible for parsing MIBs. I was a full-time staffer and had to quickly learn the ropes so RFCs would continue to be published. My primary tasks were to manage the publication queue, format and prepare documents for Joyce's review, carry out AUTH48 once Joyce completed her review, and publish, index, and archive the RFCs (both soft and hard copies). The workload increased significantly over the next few years. As the workload increased, the RFC Editor reacted and slowly grew their staff over time. To understand the team growth, let's first take a Flanagan Expires February 10, 2020 [Page 16] Internet-Draft Fifty Years of RFCs August 2019 look at the publication rates throughout history. The table below shows average annual publication rates during 5-year periods. +-------------+-------------------+ | Years | Avg Pubs per Year | +=============+===================+ | 1969 - 1972 | 80 | +-------------+-------------------+ | 1973 - 1977 | 55 | +-------------+-------------------+ | 1978 - 1982 | 20 | +-------------+-------------------+ | 1983 - 1987 | 39 | +-------------+-------------------+ | 1988 - 1992 | 69 | +-------------+-------------------+ | 1993 - 1997 | 171 | +-------------+-------------------+ | 1998 - 2002 | 237 | +-------------+-------------------+ | 2003 - 2007 | 325 | +-------------+-------------------+ | 2008 - 2012 | 333 | +-------------+-------------------+ | 2013 - 2017 | 295 | +-------------+-------------------+ Table 2: Annual Publication Rates There were significant jumps in the publication rates in the 90s and onward, with the number of publications almost doubling between 1993 and 2007. The annual submission count surpassed the 300 mark for the first time in 2004 and reached an all-time high of 385 in 2011. The submission rate did not drop below 300 until 2016 (284). As the submissions grew, the RFC Editor experienced growing pains. Processing times began to increase as the existing staff was unable to keep up with the expanding queue size. In an attempt to reduce the training hump and to avoid permanently hiring staff in case the submission burst was a fluke, ISI brought on temporary copy editors - this way, the staff could easily be resized as needed. However, as Leslie noted, this didn't work very well. The effects of the experiment would be lasting, as this led to a form of the process we have now, where the RFC Editor asks more questions during AUTH/AUTH48 and technical changes require approval from the relevant Area Directors or stream managers, depending on the document stream. These changes added to the workload and extended publication times; Flanagan Expires February 10, 2020 [Page 17] Internet-Draft Fifty Years of RFCs August 2019 many often now jokingly refer to AUTH48 as the authors' "48 days", "48 weeks", etc. Because the workload continued to increase (in more ways than just document submissions; tool testing, editorial process changes, and more) and the lessons learned with temporary copy editors, our team grew more permanently. While we had other editors in between, two additions are of particular interest, as they experienced much of the RFC Editor's growing pains, helped work us out of a backlogged state, shaped the RFC Editor function, and are still with the team today: Alice Russo joined the team in 2005 and Megan Ferguson joined us in 2007. With the understanding that the record breaking number of submissions was not an anomaly, we made significant upgrades to the infrastructure of the RFC Editor function to facilitate document tracking and reporting. For example, the illustrious "black binder" - an actual 3-ring binder used to track number assignment, a manually edited HTML file for the queue page, and a Rube-Goldberg set of text files and scripts that created queue statistics, all were eventually replaced; an errata system was proposed and implemented; and XML became a newly accepted source file. In 2009, RFC 5620 was published, introducing the initial version of the RFC Editor model we have now. While it was published in 2009, it did not go into effect until 2010, when the RFC Editor project as I knew it was disbanded and divvied up into four pieces: RFC Series Editor (RSE), Independent Submissions Editor (ISE), RFC Production Center (RPC), and Publisher. In addition, the RFC Series Advisory Group (RSAG) was created to "provide expert, informed guidance (chiefly, to the RSE) in matters affecting the RFC Series operation and development." In 2010, the RPC and Publisher contracts were awarded to Association Management Systems (AMS); we started with three existing team members (Alice Russo, Megan Ferguson, and me) and we were pleased to be joined by Lynne Bartholomew, a new colleague to anchor us in the AMS office, and later Rebecca VanRheenen shortly thereafter. I was wary of this model and was especially worried about the hole Bob Braden's departure would create. Luckily for us, Bob Braden provided wise counsel and insight during the transition (and beyond). He gave the staff transitioning to AMS particularly helpful parting words - "keep the RFCs coming" - and that is what we did. AMS embraced the RFC Series and helped us quickly get set up on new servers. The RFC Production Center and Publisher were now part of the AMS family and it was all hands on deck to make sure the Flanagan Expires February 10, 2020 [Page 18] Internet-Draft Fifty Years of RFCs August 2019 transition went smoothly to minimize the impact on document processing. Our focus during transition was to 1) keep the trains running; that is, we wanted to get ourselves up and running with minimal down time and 2) work with the Transitional RSE, the Independent Submissions Editor (Nevil Brownlee), RSAG, and the IETF Administrative Director (IAD) to better understand and implement the newly defined RFC Editor model. Though some portions of the transition were challenging and lasted longer than expected, the Acting RSE (Olaf Kolkman) officially handed the reins over to the RSE (Heather Flanagan) in 2012. She had to jump in, learn the RFC Editor and IETF culture, and work through a backlog of issues that had been left unattended. Two of the backlogged issues were so old, they were ones someone asked me about at my first IETF: when is the RFC Editor going to allow non-ASCII characters in RFCs, and when will the RFC Editor adopt a more modern publication format. At that time, while we understood the desire to move toward supporting a broader range of character sets and to have more modern outputs, we also routinely received emails from individuals requesting that we send them plain-text files (instead of pointing them to the website) because their Internet access was limited. We also regularly received complaints from rfc-editor.org users whenever something on the site didn't work correctly with their older browsers. In short, we could not advance without leaving a large number of users behind. However, we now find ourselves on the precipice of change. 2019 promises to be a BIG year for the RFC Series, as we expect to transition from publishing plaintext, ASCII-only files to publishing multiple file formats (XML, HTML, PDF/A-3, and TXT) that allow both non-ASCII characters and SVG art. Interestingly enough, I find that the RFC Editor has been in an almost constant state of change since I joined the team, even though the goal of the RFC Editor remains the same: to produce archival quality RFCs in a timely manner that are easily accessible for future generations. Flanagan Expires February 10, 2020 [Page 19] Internet-Draft Fifty Years of RFCs August 2019 4. The Next Fifty Years of RFCs As Steve Crocker mentioned, the Series began with a goal of communication over formality, openness over structure. As the Internet has grown and become a pervasive, global construct, we still aim for openness and communication, but recognize that for protocols and other information to support interoperability, there must be points of stability to build from. Small-time app developers to multi-billion dollar companies are on the same footing. Anyone should be able to look back at a point in time and understand what was done, and why. While the informality has given way to increased structure, the openness and solid foundation that the Series provides must continue. With that in mind, what is next for the next fifty years of RFCs? 4.1. Preservation The RFC Editor exists to edit, publish, and maintain an archive of documents published in the RFC Series. A proper digital archive, however, is more than just saving RFCs to disk and making sure the disks are backed up; the field of digital preservation has grown and transformed into an industry in and of itself. "Digital Preservation Considerations for the RFC Series" [RFC8153] reviews what a digital archive means today and describes ways to support the archive into the future, and recommends ways for the RFC Editor to take advantage of those organizations that specialize in this field. The future of digital preservation as far as the RFC Series is concerned will mean both finding new partners that can absorb and archive RFCs into a public, maintained digital archive, and reviewing the RFC format to ensure that the published documents are archivable according to whatever the industry best practice is over time. 4.2. Evolution of the RFC Format RFCs have been digital documents since very early in the days of the Series. While not always published in US-ASCII, that format has been the canonical format for decades. The fact that this format has lasted through so much evolution and change is remarkable. Unfortunately, the old US-ASCII format does not extend enough to meet the expectations and requirements of users today. The entire field of online document presentation, consumption, and preservation, has in some cases only been invented years after the first RFC was published. While it can (and has) been argued that those newer fields and their tools have not had a chance to stand the test of time, the RFC Series Editor (in consultation with the community) Flanagan Expires February 10, 2020 [Page 20] Internet-Draft Fifty Years of RFCs August 2019 started a concerted effort in 2012 to bring the RFC Series into alignment with a new array of possibilities for preservation and display. Information about the current RFC format project, the reasoning and requirements for the changes underway today, can be found in [RFC7990]. With the advent of these changes, the door has been opened to consider further changes in the future as the specifications for archiving digital material evolves, and as the expectation of web development advances. 4.3. Stream Structure In the eyes of many, particularly within the IETF, the RFC Series is synonymous with the IETF. While the Series itself predates the IETF by eighteen years, over time the IETF has become the source of the majority of documents submitted for publication to the RFC Editor. The policies developed for IETF stream drafts tend to apply across all four document streams, and publication-related tools tend to focus on the IETF as the primary audience for their use. It is difficult for people to see how, or even why, there is a distinction between the Series and the IETF. We are in the midst of that question now more than ever. What is the future of the Series? If people cannot tell where the IETF ends and the Series starts, should we consider this an artificial distinction and declare them to be the same entity? Ultimately, this will be something the community decides, and conversations are underway to consider the ramifications of possible changes. 5. Conclusion As the Internet evolves, expectations and possibilities evolve, too. Over the next fifty years, the Series will continue to demonstrate a balance between the need to stay true to the original mission of publication and preservation, while also staying relevant to the needs of the authors and consumers of RFCs. The tension in balancing those needs rests on the RFC Editor and the community to resolve. We will not run short of challenges. 6. IANA Considerations This document contains no actions for IANA. Flanagan Expires February 10, 2020 [Page 21] Internet-Draft Fifty Years of RFCs August 2019 7. Security Considerations This document has no security considerations. 8. Informative References [IAB-19880712] IAB, "IAB Minutes 1988-07-12", July 1988, . [IETF1] "First IETF; January 16-17, 1986; San Diego, California", January 1986, . [ISI-to-AMS] The IETF Administrative Support Activity, "RFC Production Center Agreement between Association Management Solutions, LLC, and the Internet Society", October 2009, . [RFC-ONLINE] RFC Editor, "History of RFC Online Project", February 2010, . [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, April 1969, . [RFC0003] Crocker, S.D., "Documentation conventions", RFC 3, DOI 10.17487/RFC0003, April 1969, . [RFC0114] Bhushan, A.K., "File Transfer Protocol", RFC 114, DOI 10.17487/RFC0114, April 1971, . [RFC0433] Postel, J., "Socket number list", RFC 433, DOI 10.17487/RFC0433, December 1972, . [RFC0690] Postel, J., "Comments on the proposed Host/IMP Protocol changes", RFC 690, DOI 10.17487/RFC0690, June 1975, . [RFC0748] Crispin, M.R., "Telnet randomly-lose option", RFC 748, Flanagan Expires February 10, 2020 [Page 22] Internet-Draft Fifty Years of RFCs August 2019 DOI 10.17487/RFC0748, April 1978, . [RFC0902] Reynolds, J.K. and J. Postel, "ARPA Internet Protocol policy", RFC 902, DOI 10.17487/RFC0902, July 1984, . [RFC1000] Reynolds, J.K. and J. Postel, "Request For Comments reference guide", RFC 1000, DOI 10.17487/RFC1000, August 1987, . [RFC1083] Defense Advanced Research Projects Agency and Internet Activities Board, "IAB official protocol standards", RFC 1083, DOI 10.17487/RFC1083, December 1988, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC1150] Malkin, G.S. and J.K. Reynolds, "FYI on FYI: Introduction to the FYI Notes", RFC 1150, DOI 10.17487/RFC1150, March 1990, . [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, DOI 10.17487/RFC1311, March 1992, . [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995, . [RFC2441] Cohen, D., "Working with Jon, Tribute delivered at UCLA, October 30, 1998", RFC 2441, DOI 10.17487/RFC2441, November 1998, . [RFC2468] Cerf, V., "I REMEMBER IANA", RFC 2468, DOI 10.17487/RFC2468, October 1998, . [RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555, Flanagan Expires February 10, 2020 [Page 23] Internet-Draft Fifty Years of RFCs August 2019 DOI 10.17487/RFC2555, April 1999, . [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, DOI 10.17487/RFC4714, October 2006, . [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, . [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process for Publication of IAB RFCs", RFC 4845, DOI 10.17487/RFC4845, July 2007, . [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, . [RFC5540] Editor, RFC., "40 Years of RFCs", RFC 5540, DOI 10.17487/RFC5540, April 2009, . [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", RFC 5620, DOI 10.17487/RFC5620, August 2009, . [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, . [RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, December 2009, . [RFC6360] Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, DOI 10.17487/RFC6360, August 2011, . [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, . Flanagan Expires February 10, 2020 [Page 24] Internet-Draft Fifty Years of RFCs August 2019 [RFC6548] Brownlee, N., Ed. and IAB, "Independent Submission Editor Model", RFC 6548, DOI 10.17487/RFC6548, June 2012, . [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 2012, . [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, . [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, December 2016, . [RFC8153] Flanagan, H., "Digital Preservation Considerations for the RFC Series", RFC 8153, DOI 10.17487/RFC8153, April 2017, . Acknowledgements With many thanks to John Klensin for his feedback and insights on the history of the Series, as someone who directly engaged and influenced many of the key individuals involved in developing the RFC Series. Additional thanks to members of the RFC Series Advisory group and the Independent Submissions Editorial Board, in particular Scott Bradner, Brian Carpenter, and Adrian Farrel, for their early reviews and input into the sequence of key moments in the history of the Series. Contributors Many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil Brownlee, and Sandy Ginoza for their perspectives on the Series, and their ongoing support. Author's Address Heather Flanagan (editor) RFC Editor Email: rse@rfc-editor.org URI: https://orcid.org/0000-0002-2647-2220 Flanagan Expires February 10, 2020 [Page 25] ./draft-ietf-lamps-rfc6844bis-07.txt0000644000764400076440000011625113474070344016303 0ustar iustyiusty Network Working Group P. Hallam-Baker Internet-Draft Obsoletes: 6844 (if approved) R. Stradling Intended status: Standards Track Sectigo Expires: December 1, 2019 J. Hoffman-Andrews Let's Encrypt May 30, 2019 DNS Certification Authority Authorization (CAA) Resource Record draft-ietf-lamps-rfc6844bis-07 Abstract 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 name. 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. This document obsoletes RFC 6844. 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 https://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 1, 2019. Copyright Notice Copyright (c) 2019 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 Hallam-Baker, et al. Expires December 1, 2019 [Page 1] Internet-Draft CAA May 2019 (https://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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 3. Relevant Resource Record Set . . . . . . . . . . . . . . . . 5 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Canonical Presentation Format . . . . . . . . . . . . 7 4.2. CAA issue Property . . . . . . . . . . . . . . . . . . . 8 4.3. CAA issuewild Property . . . . . . . . . . . . . . . . . 9 4.4. CAA iodef Property . . . . . . . . . . . . . . . . . . . 10 4.5. Critical Flag . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.1. Use of DNS Security . . . . . . . . . . . . . . . . . . . 12 5.2. Non-Compliance by Certification Authority . . . . . . . . 12 5.3. Mis-Issue by Authorized Certification Authority . . . . . 12 5.4. Suppression or Spoofing of CAA Records . . . . . . . . . 12 5.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 13 5.6. Abuse of the Critical Flag . . . . . . . . . . . . . . . 13 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 6.1. Blocked Queries or Responses . . . . . . . . . . . . . . 14 6.2. Rejected Queries and Malformed Responses . . . . . . . . 14 6.3. Delegation to Private Nameservers . . . . . . . . . . . . 14 6.4. Bogus DNSSEC Responses . . . . . . . . . . . . . . . . . 14 7. Differences versus RFC6844 . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain name. Publication of CAA Resource Records allows a public Hallam-Baker, et al. Expires December 1, 2019 [Page 2] Internet-Draft CAA May 2019 Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX [RFC6698] certificate data. The distinction between the two specifications is that CAA records specify an authorization control to be performed by a certificate issuer before issue of a certificate and TLSA records specify a verification control to be performed by a relying party after the certificate is issued. Conformance with a published CAA record is a necessary but not sufficient condition for issuance of a certificate. Criteria for inclusion of embedded trust anchor certificates in applications are outside the scope of this document. Typically, such criteria require the CA to publish a Certification Practices Statement (CPS) that specifies how the requirements of the Certificate Policy (CP) are achieved. It is also common for a CA to engage an independent third-party auditor to prepare an annual audit statement of its performance against its CPS. A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain name. Since certificates are valid for a period of time, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying parties MUST NOT use CAA records as part of certificate validation. CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take account of the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator. 2. Definitions 2.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Hallam-Baker, et al. Expires December 1, 2019 [Page 3] Internet-Draft CAA May 2019 2.2. Defined Terms The following terms are used in this document: Certificate: An X.509 Certificate, as specified in [RFC5280]. Certificate Evaluator: A party other than a Relying Party that evaluates the trustworthiness of certificates issued by Certification Authorities. Certification Authority (CA): An Issuer that issues certificates in accordance with a specified Certificate Policy. Certificate Policy (CP): Specifies the criteria that a Certification Authority undertakes to meet in its issue of certificates. See [RFC3647]. Certification Practices Statement (CPS): Specifies the means by which the criteria of the Certificate Policy are met. In most cases, this will be the document against which the operations of the Certification Authority are audited. See [RFC3647]. Domain Name: The label assigned to a node in the Domain Name System. Domain Name System (DNS): The Internet naming system specified in [RFC1034] and [RFC1035]. DNS Security (DNSSEC): Extensions to the DNS that provide authentication services as specified in [RFC4033], [RFC4034], [RFC4035], [RFC5155], and revisions. Fully-Qualified Domain Name (FQDN): A Domain Name that includes the labels of all superior nodes in the Domain Name System. Issuer: An entity that issues certificates. See [RFC5280]. Property: The tag-value portion of a CAA Resource Record. Property Tag: The tag portion of a CAA Resource Record. Property Value: The value portion of a CAA Resource Record. Resource Record (RR): A particular entry in the DNS including the owner name, class, type, time to live, and data, as defined in [RFC1034] and [RFC2181]. Resource Record Set (RRSet): A set of Resource Records of a particular owner name, class, and type. The time to live on all RRs Hallam-Baker, et al. Expires December 1, 2019 [Page 4] Internet-Draft CAA May 2019 within an RRSet is always the same, but the data may be different among RRs in the RRSet. Relevant Resource Record Set (Relevant RRSet): A set of CAA Resource Records resulting from applying the algorithm in Section 3 to a specific Fully-Qualified Domain Name or Wildcard Domain Name. Relying Party: A party that makes use of an application whose operation depends on use of a certificate for making a security decision. See [RFC5280]. Wildcard Domain Name: A Domain Name consisting of a single asterisk character followed by a single full stop character ("*.") followed by a Fully-Qualified Domain Name. 3. Relevant Resource Record Set Before issuing a certificate, a compliant CA MUST check for publication of a Relevant RRSet. If such an RRSet exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies. If the Relevant RRSet for a Fully-Qualified Domain Name or Wildcard Domain Name contains no Property Tags that restrict issuance (for instance, if it contains only iodef Property Tags, or only Property Tags unrecognized by the CA), CAA does not restrict issuance. A certificate request MAY specify more than one Fully-Qualified Domain Name and MAY specify Wildcard Domain Names. Issuers MUST verify authorization for all the Fully-Qualified Domain Names and Wildcard Domain Names specified in the request. The search for a CAA RRSet climbs the DNS name tree from the specified label up to but not including the DNS root '.' until a CAA RRSet is found. Given a request for a specific Fully-Qualified Domain Name X, or a request for a Wildcard Domain Name *.X, the Relevant Resource Record Set RelevantCAASet(X) is determined as follows (in pseudocode): Let CAA(X) be the RRSet returned by performing a CAA record query for the Fully-Qualified Domain Name X, according to the lookup algorithm specified in RFC 1034 section 4.3.2 (in particular chasing aliases). Let Parent(X) be the Fully-Qualified Domain Name produced by removing the leftmost label of X. Hallam-Baker, et al. Expires December 1, 2019 [Page 5] Internet-Draft CAA May 2019 RelevantCAASet(domain): while domain is not ".": if CAA(domain) is not Empty: return CAA(domain) domain = Parent(domain) return Empty For example, processing CAA for the Fully-Qualified Domain Name "X.Y.Z" where there are no CAA records at any level in the tree RelevantCAASet would have the following steps: CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z." CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z." CAA("Z.") = Empty; domain = Parent("Z.") = "." return Empty Processing CAA for the Fully-Qualified Domain Name "A.B.C" where there is a CAA record "issue example.com" at "B.C" would terminate early upon finding the CAA record: CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C." CAA("B.C.") = "issue example.com" return "issue example.com" 4. Mechanism 4.1. Syntax A CAA Resource Record contains a single Property consisting of a tag- value pair. A Fully-Qualified Domain Name MAY have multiple CAA RRs associated with it and a given Property Tag MAY be specified more than once across those RRs. The RDATA section for a CAA Resource Record contains one Property. A Property consists of the following: +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| | Flags | Tag Length = n | +----------------|----------------+...+---------------+ | Tag char 0 | Tag char 1 |...| Tag char n-1 | +----------------|----------------+...+---------------+ +----------------|----------------+.....+----------------+ | Value byte 0 | Value byte 1 |.....| Value byte m-1 | +----------------|----------------+.....+----------------+ Where n is the length specified in the Tag length field and m is the remaining octets in the Value field. They are related by (m = d - n - 2) where d is the length of the RDATA section. Hallam-Baker, et al. Expires December 1, 2019 [Page 6] Internet-Draft CAA May 2019 The fields are defined as follows: Flags: One octet containing the following field: Bit 0, Issuer Critical Flag: If the value is set to '1', the Property is critical. A Certification Authority MUST NOT issue certificates for any FQDN the Relevant RRSet for that FQDN contains a CAA critical Property for an unknown or unsupported Property Tag. Note that according to the conventions set out in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant Bit. Thus, the Flags value 1 means that bit 7 is set while a value of 128 means that bit 0 is set according to this convention. All other bit positions are reserved for future use. To ensure compatibility with future extensions to CAA, DNS records compliant with this version of the CAA specification MUST clear (set to "0") all reserved flags bits. Applications that interpret CAA records MUST ignore the value of all reserved flag bits. Tag Length: A single octet containing an unsigned integer specifying the tag length in octets. The tag length MUST be at least 1. Tag: The Property identifier, a sequence of US-ASCII characters. Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through 'Z', and the numbers 0 through 9. Tags MUST NOT contain any other characters. Matching of tags is case insensitive. Tags submitted for registration by IANA MUST NOT contain any characters other than the (lowercase) US-ASCII characters 'a' through 'z' and the numbers 0 through 9. Value: A sequence of octets representing the Property Value. Property Values are encoded as binary values and MAY employ sub- formats. The length of the value field is specified implicitly as the remaining length of the enclosing RDATA section. 4.1.1. Canonical Presentation Format The canonical presentation format of the CAA record is: CAA Where: Hallam-Baker, et al. Expires December 1, 2019 [Page 7] Internet-Draft CAA May 2019 Flags: Is an unsigned integer between 0 and 255. Tag: Is a non-zero-length sequence of US-ASCII letters and numbers in lower case. Value: The value field, expressed as a contiguous set of characters without interior spaces, or as a quoted string. See the format specified in [RFC1035], Section 5.1, but note that the value field contains no length byte and is not limited to 255 characters. 4.2. CAA issue Property If the issue Property Tag is present in the Relevant RRSet for a Fully-Qualified Domain Name, it is a request that Issuers 1. Perform CAA issue restriction processing for the FQDN, and 2. Grant authorization to issue certificates containing that FQDN to the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name. The CAA issue Property Value has the following sub-syntax (specified in ABNF as per [RFC5234]). issue-value = *WSP [issuer-domain-name *WSP] [";" *WSP [parameters *WSP]] issuer-domain-name = label *("." label) label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) parameters = (parameter *WSP ";" *WSP parameters) / parameter parameter = tag *WSP "=" *WSP value tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) value = *(%x21-3A / %x3C-7E) For consistency with other aspects of DNS administration, FQDN values are specified in letter-digit-hyphen Label (LDH-Label) form. The following CAA record set requests that no certificates be issued for the FQDN 'certs.example.com' by any Issuer other than ca1.example.net or ca2.example.org. certs.example.com CAA 0 issue "ca1.example.net" certs.example.com CAA 0 issue "ca2.example.org" Because the presence of an issue Property Tag in the Relevant RRSet for an FQDN restricts issuance, FQDN owners can use an issue Property Tag with no issuer-domain-name to request no issuance. Hallam-Baker, et al. Expires December 1, 2019 [Page 8] Internet-Draft CAA May 2019 For example, the following RRSet requests that no certificates be issued for the FQDN 'nocerts.example.com' by any Issuer. nocerts.example.com CAA 0 issue ";" An issue Property Tag where the issue-value does not match the ABNF grammar MUST be treated the same as one specifying an empty issuer- domain-name. For example, the following malformed CAA RRSet forbids issuance: malformed.example.com CAA 0 issue "%%%%%" CAA authorizations are additive; thus, the result of specifying both an empty issuer-domain-name and a non-empty issuer-domain-name is the same as specifying just the non-empty issuer-domain-name. An Issuer MAY choose to specify parameters that further constrain the issue of certificates by that Issuer, for example, specifying that certificates are to be subject to specific validation polices, billed to certain accounts, or issued under specific trust anchors. For example, if ca1.example.net has requested its customer accountable.example.com to specify their account number "230123" in each of the customer's CAA records using the (CA-defined) "account" parameter, it would look like this: accountable.example.com CAA 0 issue "ca1.example.net; account=230123" The semantics of parameters to the issue Property Tag are determined by the Issuer alone. 4.3. CAA issuewild Property The issuewild Property Tag has the same syntax and semantics as the issue Property Tag except that it only grants authorization to issue certificates that specify a Wildcard Domain Name and issuewild properties take precedence over issue properties when specified. Specifically: issuewild properties MUST be ignored when processing a request for a Fully-Qualified Domain Name that is not a Wildcard Domain Name. If at least one issuewild Property is specified in the Relevant RRSet for a Wildcard Domain Name, all issue properties MUST be ignored when processing a request for that Wildcard Domain Name. For example, the following RRSet requests that _only_ ca1.example.net issue certificates for "wild.example.com" or "sub.wild.example.com", Hallam-Baker, et al. Expires December 1, 2019 [Page 9] Internet-Draft CAA May 2019 and that _only_ ca2.example.org issue certificates for "*.wild.example.com" or "*.sub.wild.example.com). Note that this presumes there are no CAA RRs for sub.wild.example.com. wild.example.com CAA 0 issue "ca1.example.net" wild.example.com CAA 0 issuewild "ca2.example.org" The following RRSet requests that _only_ ca1.example.net issue certificates for "wild2.example.com", "*.wild2.example.com" or "*.sub.wild2.example.com". wild2.example.com CAA 0 issue "ca1.example.net" The following RRSet requests that _only_ ca2.example.org issue certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". It does not permit any Issuer to issue for "wild3.example.com" or "sub.wild3.example.com". wild3.example.com CAA 0 issuewild "ca2.example.org" wild3.example.com CAA 0 issue ";" The following RRSet requests that _only_ ca2.example.org issue certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". It permits any Issuer to issue for "wild3.example.com" or "sub.wild3.example.com". wild3.example.com CAA 0 issuewild "ca2.example.org" 4.4. CAA iodef Property The iodef Property specifies a means of reporting certificate issue requests or cases of certificate issue for domains for which the Property appears in the Relevant RRSet, when those requests or issuances violate the security policy of the Issuer or the FQDN holder. The Incident Object Description Exchange Format (IODEF) [RFC7970] is used to present the incident report in machine-readable form. The iodef Property Tag takes a URL as its Property Value. The URL scheme type determines the method used for reporting: mailto: The IODEF incident report is reported as a MIME email attachment to an SMTP email that is submitted to the mail address specified. The mail message sent SHOULD contain a brief text message to alert the recipient to the nature of the attachment. Hallam-Baker, et al. Expires December 1, 2019 [Page 10] Internet-Draft CAA May 2019 http or https: The IODEF report is submitted as a Web service request to the HTTP address specified using the protocol specified in [RFC6546]. These are the only supported URL schemes. The following RRSet specifies that reports may be made by means of email with the IODEF data as an attachment, a Web service [RFC6546], or both: report.example.com CAA 0 issue "ca1.example.net" report.example.com CAA 0 iodef "mailto:security@example.com" report.example.com CAA 0 iodef "http://iodef.example.com/" 4.5. Critical Flag The critical flag is intended to permit future versions of CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated FQDNs. In the following example, the Property with a Property Tag of 'tbs' is flagged as critical. Neither the ca1.example.net CA nor any other Issuer is authorized to issue for "new.example.com" (or any other domains for which this is the Relevant RRSet) unless the Issuer has implemented the processing rules for the 'tbs' Property Tag. new.example.com CAA 0 issue "ca1.example.net" new.example.com CAA 128 tbs "Unknown" 5. Security Considerations CAA records assert a security policy that the holder of an FDQN wishes to be observed by Issuers. The effectiveness of CAA records as an access control mechanism is thus dependent on observance of CAA constraints by Issuers. The objective of the CAA record properties described in this document is to reduce the risk of certificate mis-issue rather than avoid reliance on a certificate that has been mis-issued. DANE [RFC6698] describes a mechanism for avoiding reliance on mis-issued certificates. Hallam-Baker, et al. Expires December 1, 2019 [Page 11] Internet-Draft CAA May 2019 5.1. Use of DNS Security Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required. An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRSet, irrespective of whether the corresponding DNS records are signed. DNSSEC provides a proof of non-existence for both DNS Fully-Qualified Domain Names and RRSets within FQDNs. DNSSEC verification thus enables an Issuer to determine if the answer to a CAA record query is empty because the RRSet is empty or if it is non-empty but the response has been suppressed. Use of DNSSEC allows an Issuer to acquire and archive a proof that they were authorized to issue certificates for the FQDN. Verification of such archives may be an audit requirement to verify CAA record processing compliance. Publication of such archives may be a transparency requirement to verify CAA record processing compliance. 5.2. Non-Compliance by Certification Authority CAA records offer CAs a cost-effective means of mitigating the risk of certificate mis-issue: the cost of implementing CAA checks is very small and the potential costs of a mis-issue event include the removal of an embedded trust anchor. 5.3. Mis-Issue by Authorized Certification Authority Use of CAA records does not prevent mis-issue by an authorized Certification Authority, i.e., a CA that is authorized to issue certificates for the FQDN in question by CAA records. FQDN holders SHOULD verify that the CAs they authorize to issue certificates for their FQDNs employ appropriate controls to ensure that certificates are issued only to authorized parties within their organization. Such controls are most appropriately determined by the FQDN holder and the authorized CA(s) directly and are thus out of scope of this document. 5.4. Suppression or Spoofing of CAA Records Suppression of the CAA record or insertion of a bogus CAA record could enable an attacker to obtain a certificate from an Issuer that was not authorized to issue for an affected FQDN. Hallam-Baker, et al. Expires December 1, 2019 [Page 12] Internet-Draft CAA May 2019 Where possible, Issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets. In cases where DNSSEC is not deployed for a corresponding FQDN, an Issuer SHOULD attempt to mitigate this risk by employing appropriate DNS security controls. For example, all portions of the DNS lookup process SHOULD be performed against the authoritative name server. Data cached by third parties MUST NOT be relied on as the sole source of DNS CAA information but MAY be used to support additional anti- spoofing or anti-suppression controls. 5.5. Denial of Service Introduction of a malformed or malicious CAA RR could in theory enable a Denial-of-Service (DoS) attack. This could happen by modification of authoritative DNS records or by spoofing inflight DNS responses. This specific threat is not considered to add significantly to the risk of running an insecure DNS service. An attacker could, in principle, perform a DoS attack against an Issuer by requesting a certificate with a maliciously long DNS name. In practice, the DNS protocol imposes a maximum name length and CAA processing does not exacerbate the existing need to mitigate DoS attacks to any meaningful degree. 5.6. Abuse of the Critical Flag A Certification Authority could make use of the critical flag to trick customers into publishing records that prevent competing Certification Authorities from issuing certificates even though the customer intends to authorize multiple providers. This could happen if the customers were setting CAA records based on data provided by the CA rather than generating those records themselves. In practice, such an attack would be of minimal effect since any competent competitor that found itself unable to issue certificates due to lack of support for a Property marked critical should investigate the cause and report the reason to the customer. The customer will thus discover that they had been deceived. 6. Deployment Considerations A CA implementing CAA may find that they receive errors looking up CAA records. The following are some common causes of such errors, so that CAs may provide guidance to their subscribers on fixing the underlying problems. Hallam-Baker, et al. Expires December 1, 2019 [Page 13] Internet-Draft CAA May 2019 6.1. Blocked Queries or Responses Some middleboxes, in particular anti-DDoS appliances, may be configured to drop DNS packets of unknown types, or may start dropping such packets when they consider themselves under attack. This generally manifests as a timed-out DNS query, or a SERVFAIL at a local recursive resolver. 6.2. Rejected Queries and Malformed Responses Some authoritative nameservers respond with REJECTED or NOTIMP when queried for a Resource Record type they do not recognize. At least one authoritative resolver produces a malformed response (with the QR bit set to 0) when queried for unknown Resource Record types. Per RFC 1034, the correct response for unknown Resource Record types is NOERROR. 6.3. Delegation to Private Nameservers Some FQDN administrators make the contents of a subdomain unresolvable on the public Internet by delegating that subdomain to a nameserver whose IP address is private. A CA processing CAA records for such subdomains will receive SERVFAIL from its recursive resolver. The CA MAY interpret that as preventing issuance. FQDN administrators wishing to issue certificates for private FQDNs SHOULD use split-horizon DNS with a publicly available nameserver, so that CAs can receive a valid, empty CAA response for those FQDNs. 6.4. Bogus DNSSEC Responses Queries for CAA Resource Records are different from most DNS RR types, because a signed, empty response to a query for CAA RRs is meaningfully different from a bogus response. A signed, empty response indicates that there is definitely no CAA policy set at a given label. A bogus response may mean either a misconfigured zone, or an attacker tampering with records. DNSSEC implementations may have bugs with signatures on empty responses that go unnoticed, because for more common Resource Record types like A and AAAA, the difference to an end user between empty and bogus is irrelevant; they both mean a site is unavailable. In particular, at least two authoritative resolvers that implement live signing had bugs when returning empty Resource Record sets for DNSSEC-signed zones, in combination with mixed-case queries. Mixed- case queries, also known as DNS 0x20, are used by some recursive resolvers to increase resilience against DNS poisoning attacks. DNSSEC-signing authoritative resolvers are expected to copy the same capitalization from the query into their ANSWER section, but sign the Hallam-Baker, et al. Expires December 1, 2019 [Page 14] Internet-Draft CAA May 2019 response as if they had used all lowercase. In particular, PowerDNS versions prior to 4.0.4 had this bug. 7. Differences versus RFC6844 This document obsoletes RFC6844. The most important change is to the Certification Authority Processing section. RFC6844 specified an algorithm that performed DNS tree-climbing not only on the FQDN being processed, but also on all CNAMEs and DNAMEs encountered along the way. This made the processing algorithm very inefficient when used on FQDNs that utilize many CNAMEs, and would have made it difficult for hosting providers to set CAA policies on their own FQDNs without setting potentially unwanted CAA policies on their customers' FQDNs. This document specifies a simplified processing algorithm that only performs tree climbing on the FQDN being processed, and leaves processing of CNAMEs and DNAMEs up to the CA's recursive resolver. This document also includes a "Deployment Considerations" section detailing experience gained with practical deployment of CAA enforcement among CAs in the WebPKI. This document clarifies the ABNF grammar for the issue and issuewild tags and resolves some inconsistencies with the document text. In particular, it specifies that parameters are separated with semicolons. It also allows hyphens in Property Tags. This document also clarifies processing of a CAA RRset that is not empty, but contains no issue or issuewild tags. This document removes the section titled "The CAA RR Type," merging it with "Mechanism" because the definitions were mainly duplicates. It moves the "Use of DNS Security" section into Security Considerations. It renames "Certification Authority Processing" to "Relevant Resource Record Set," and emphasizes the use of that term to more clearly define which domains are affected by a given RRset. 8. IANA Considerations IANA is requested to add [[[ RFC Editor: Please replace with this RFC ]]] as a reference for the Certification Authority Restriction Flags and Certification Authority Restriction Properties registries, and update references to [RFC6844] within those registries to refer to [[[ RFC Editor: Please replace with this RFC ]]]. IANA is also requested to update the CAA TYPE in the DNS Parameters registry with a reference to [[[ RFC Editor: Please replace with this RFC ]]]. Hallam-Baker, et al. Expires December 1, 2019 [Page 15] Internet-Draft CAA May 2019 9. Acknowledgements The authors would like to thank the following people who contributed to the design and documentation of this work item: Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger, Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson. 10. References 10.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, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 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, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . Hallam-Baker, et al. Expires December 1, 2019 [Page 16] Internet-Draft CAA May 2019 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [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, . [RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, DOI 10.17487/RFC6546, April 2012, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, DOI 10.17487/RFC6844, January 2013, . [RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, . Authors' Addresses Phillip Hallam-Baker Email: phill@hallambaker.com Hallam-Baker, et al. Expires December 1, 2019 [Page 17] Internet-Draft CAA May 2019 Rob Stradling Sectigo Ltd. Email: rob@sectigo.com Jacob Hoffman-Andrews Let's Encrypt Email: jsha@letsencrypt.org Hallam-Baker, et al. Expires December 1, 2019 [Page 18] ./draft-iab-rfc7500-bis-00.txt0000644000764400076440000004107613504733711015031 0ustar iustyiusty INTERNET-DRAFT R. Housley, Ed. Internet Architecture Board (IAB) Vigil Security Obsoletes: 7500 (once approved) O. Kolkman, Ed. Intended Status: Informational Internet Society Expires: 26 December 2019 26 June 2019 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries draft-iab-rfc7500-bis-00 Abstract This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries. 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 Housley & Kolkman Informational [Page 1] RFC7500-bis June 2019 Copyright Notice Copyright (c) 2019 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 (https://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 0. Cover Note ..................................................... 2 1. Introduction ................................................... 2 2. Principles for the Operation of IANA Registries ................ 4 3. Discussion ..................................................... 4 3.1. Ensuring Uniqueness, Stability, and Predictability ........ 4 3.2. Public .................................................... 5 3.3. Open and Transparent ...................................... 5 3.4. Accountable ............................................... 5 4. Security Considerations ........................................ 6 5. Changes Since RFC 7500 ........................................ 6 6. Informative References ......................................... 6 IAB Members at the Time of Approval ............................... 8 Contributors and Acknowledgements ................................. 8 Authors' Addresses ................................................ 8 0. Cover Note {{ RFC Editor: Please remove this section prior to publication. }} Section 3.4 is changed for alignment with the new structure for the IETF Administrative Support Activity (IASA). 1. Introduction The Internet Engineering Task Force (IETF) and its predecessors have traditionally separated the publication of protocol specifications in immutable Request for Comments (RFCs) and the registries containing protocol parameters. Traditionally, the registries are maintained by a set of functions known collectively as the Internet Assigned Numbers Authority (IANA). Dating back to the earliest days of the Internet, specification publication and the registry operations were Housley & Kolkman Informational [Page 2] RFC7500-bis June 2019 tightly coupled: Jon Postel of the Information Sciences Institute (ISI) of the University of Southern California (USC) was responsible for both RFC publication and IANA registry operation. This tight coupling had advantages, but it was never a requirement. Indeed, today the RFC Editor and IANA registry operation are provided by different entities. Internet registries are critical to the operation of the Internet, because they provide a definitive record of the value and meaning of identifiers that protocols use when communicating with each other. Almost every Internet protocol makes use of registries in some form. At the time of writing, the IANA maintains more than two thousand protocol parameter registries. Internet registries hold protocol identifiers consisting of constants and other well-known values used by Internet protocols. These values can be numbers, strings, addresses, and so on. They are uniquely assigned for one particular purpose or use. Identifiers can be maintained in a central list (such as a list of cryptographic algorithms) or they can be hierarchically allocated and assigned by separate entities at different points in the hierarchy (such as IP addresses and domain names). To maximize trust and usefulness of the IANA registries, the principles in this document should be taken into consideration for centralized registries as well as hierarchically delegated registries. In hierarchically delegated registries, entries nearest to top level have broad scope, but lower-level entries have narrow scope. The Internet Architecture Board (IAB) will encourage support for these principles in all delegations of Internet identifiers. The registry system is built on trust and mutual cooperation. The use of the registries is voluntary and is not enforced by mandates or certification policies. While the use of registries is voluntary, it is noted that the success of the Internet creates enormous pressure to use Internet protocols and the identifier registries associated with them. This document provides principles for the operation of IANA registries, ensuring that protocol identifiers have consistent meanings and interpretations across all implementations and deployments, and thus providing the necessary trust in the IANA registries. Housley & Kolkman Informational [Page 3] RFC7500-bis June 2019 2. Principles for the Operation of IANA Registries The following key principles underscore the successful functioning of the IANA registries, and they provide a foundation for trust in those registries: Ensure Uniqueness: The same protocol identifier must not be used for more than one purpose. Stable: Protocol identifier assignment must be lasting. Predictable: The process for making assignments must not include unexpected steps. Public: The protocol identifiers must be made available in well- known locations in a manner that makes them freely available to everyone. Open: The process that sets the policy for protocol identifier assignment and registration must be open to all interested parties. Transparent: The protocol registries and their associated policies should be developed in a transparent manner. Accountable: Registry policy development and registry operations need to be accountable to the affected community. 3. Discussion The principles discussed in Section 2 provide trust and confidence in the IANA registries. This section expands on these principles. 3.1. Ensuring Uniqueness, Stability, and Predictability Protocol identifier assignment and registration must be unique, stable, and predictable. Developers, vendors, customers, and users depend on the registries for unique protocol identifiers that are assigned in a stable and predictable manner. A protocol identifier may only be reassigned for a different purpose after due consideration of the impact of such a reassignment, and if possible, with the consent of the original assignee. Recognizing that some assignments involve judgment, such as those involving a designated expert [RFC5226], a predictable process does not require completion in a predetermined number of days. Rather, it means that no unexpected steps are introduced in the process of Housley & Kolkman Informational [Page 4] RFC7500-bis June 2019 making an assignment. 3.2. Public Once assigned, the protocol identifiers must be made available in a manner that makes them freely available to everyone without restrictions. The use of a consistent publication location builds confidence in the registry. This does not mean that the publication location can never change, but it does mean that it must change infrequently and only after adequate prior notice. 3.3. Open and Transparent The process that sets the policy for protocol identifier assignment and registration must be open to all interested parties and operate in a transparent manner. When a registry is established, a policy is set for the addition of new entries and the updating of existing entries. While making additions and modifications, the registry operator may expose instances where policies lack clarity. When this occurs, the registry operator should provide helpful feedback to allow those policies to be improved. In addition, the registry operator not being involved in establishing registry policy avoids the risks associated with (perceptions of) favoritism and unfairness. Recognizing that some assignments involve judgment, such as those involving a designated expert [RFC5226], the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal. 3.4. Accountable The process that sets the policy for IANA registries and the operation of the registries must be accountable to the parties that rely on the protocol identifiers. Oversight is needed to ensure these are properly serving the affected community. In practice, accountability mechanisms for the registry operator may be defined by contract, memoranda of understanding, or service level agreements (SLAs). An oversight body uses these mechanisms to ensure that the registry operator is meeting the needs of the affected community. The oversight body is held accountable to the affected community by vastly different mechanisms, for instance recall and appeal processes. For protocol parameters [RFC6220], the general oversight of the IANA function is performed by the IAB as a chartered responsibility from Housley & Kolkman Informational [Page 5] RFC7500-bis June 2019 [RFC2850]. In addition, the IETF Administration Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), is responsible for IETF administrative and financial matters [I-D.ietf-iasa2-rfc4071bis], and in that role, the IETF LLC maintains a SLA with the current registry operator, the Internet Corporation for Assigned names and Numbers (ICANN), thereby specifying the operational requirements with respect to the coordination, maintenance, and publication of the protocol parameter registries. Both the IAB and the Board of the IETF LLC are accountable to the larger Internet community and are being held accountable through the IETF NomCom process [BCP10]. For the Internet Number Registries [RFC7249], oversight is performed by the Regional Internet Registries (RIRs) as described RFC 7020 [RFC7020]. The RIRs are member-based organizations, and they are accountable to the affected community by elected governance boards. Furthermore, per agreement between the RIRs and ICANN, the policy development for the global IANA number registries is coordinated by a community-elected number council and subject to process review before ratification by the ICANN Board of Trustees [ASOMOU]. 4. Security Considerations Internet Registries are critical to elements of Internet security. The principles described in this document are necessary for the Internet community to place trust in the IANA registries. 5. Changes Since RFC 7500 Section 3.4 has been updated to align with the restructuring of the IETF Administrative Support Activity (IASA). Under the new structure, the IETF LLC maintains a SLA with the protocol parameter registry operator. Under the old structure, the SLA was maintained by the IETF Administrative Oversight Committee (IAOC). 6. Informative References [ASOMOU] ICANN, "ICANN Address Supporting Organization (ASO) MoU", October 2004, . [BCP10] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 7437, January 2015, . Housley & Kolkman Informational [Page 6] RFC7500-bis June 2019 [I-D.ietf-iasa2-rfc4071bis] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", draft-ietf-iasa2-rfc4071bis-00 (work in progress), December 2018. [RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000, . [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, . [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., Huston, G., Ed., and Internet Architecture Board, "Defining the Role and Function of IETF Protocol Parameter Registry Operators", RFC 6220, April 2011, . [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, August 2013, . [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 2014, . Housley & Kolkman Informational [Page 7] RFC7500-bis June 2019 IAB Members at the Time of Approval {{ RFC Editor: Fill in the current membership. }} Contributors and Acknowledgements This text has been developed within the IAB IANA Evolution Program. The ideas and many text fragments, and corrections came from or were inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson, George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further inspiration and input was drawn from various meetings with IETF and other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership. Please do not assume those acknowledged endorse the resulting text. Authors' Addresses Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Olaf Kolkman Internet Society Science Park 400 Amsterdam 1098 XH The Netherlands EMail: kolkman@isoc.org Housley & Kolkman Informational [Page 8] ./draft-ietf-iasa2-rfc2031bis-08.txt0000644000764400076440000004571513531231036016144 0ustar iustyiusty IETF Administrative Support Activity 2 G. Camarillo Internet-Draft Ericsson Obsoletes: 2031 (if approved) J. Livingood Intended status: Informational Comcast Expires: February 27, 2020 August 26, 2019 The IETF-ISOC Relationship draft-ietf-iasa2-rfc2031bis-08 Abstract This document summarises the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031. 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 https://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 27, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Camarillo & Livingood Expires February 27, 2020 [Page 1] Internet-Draft The IETF-ISOC Relationship August 2019 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 History . . . . . . . . . . . . . . . . . . 2 2. Philosophical Relationship with ISOC . . . . . . . . . . . . 3 3. Main Division of Responsibilities between IETF and ISOC . . . 3 4. ISOC's Role in the IETF Standards Process . . . . . . . . . . 4 5. The IETF's Role in ISOC . . . . . . . . . . . . . . . . . . . 4 6. Legal Relationship with ISOC . . . . . . . . . . . . . . . . 5 7. Financial and Administrative Relationship with ISOC . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 12. Changes from Previous Versions . . . . . . . . . . . . . . . 6 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 13.1. Normative References . . . . . . . . . . . . . . . . . . 7 13.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction and History The Internet Society provides a corporate home for the administrative entity that supports the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB), and the Internet Research Task Force (IRTF), and supports the work of these groups through a variety of programs. The Internet Engineering Task Force (IETF) is the body that is responsible for the development and maintenance of the Internet Standards. The IETF is primarily a volunteer organization. Its driving force is a group of dedicated high-quality engineers from all over the world. In a structure of working groups, these engineers exchange ideas and experience, and through discussion and collaboration (both electronically and face-to-face) they strive to achieve rough consensus and implement the standards through running code. The growth of the Internet over several decades also led to the growth of the IETF. More and more people, organizations, and companies rely on Internet Standards. Non-technical issues, such as legal, administrative, and financial issues had long been an undesirable but unavoidable part of the IETF. To address these issues in 1995 the IETF established the Poised95 Working Group. Its Camarillo & Livingood Expires February 27, 2020 [Page 2] Internet-Draft The IETF-ISOC Relationship August 2019 goal was to structure and document the IETF processes in order to maximize the flexibility and freedom of IETF engineers so that they could work in the way the IETF had always been most successful and to honour the IETF credo: "Rough consensus and running code". The Poised95 Working Group concluded that the Internet Society (ISOC), which was formed in 1992, was the best organization to handle all of these legal, administrative, and financial tasks on behalf of and in close cooperation with the IETF. This led to documenting things such as the IETF standards process [RFC2026], the IETF organizational structure [RFC2028], the IETF Nominating Committee (NomCom) procedures , and the IETF-ISOC relationship [RFC2031]. As time passed and operational experience accumulated, additional structure was necessary. As a result, the Internet Administrative Support Activity (IASA) was defined in 2005 and documented in [RFC4071] and [RFC4371]. In 2018, the IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which made significant revisions to the IETF's administrative, legal, and financial structure. One critical outcome was the formation, in close cooperation between the IETF and ISOC, of the IETF Administration Limited Liability Company (IETF LLC) as a subsidiary of ISOC. As a result of the IASA 2.0 structure [I-D.ietf-iasa2-rfc4071bis] and formation of the IETF LLC, the relationship between the IETF and ISOC has changed. This document summarises the current state of the IETF- ISOC relationship at a high level and replaces [RFC2031]. 2. Philosophical Relationship with ISOC ISOC and the IETF have historically been philosophically aligned. ISOC's connection with the IETF community has always played an important role in its policy work, which has not changed. ISOC has always been and continues to be an advocate for multistakeholder processes, which includes the technical community. Open standards are an explicit part of one of the focus areas in ISOC's mission: Advancing the development and application of Internet infrastructure, technologies, and open standards . 3. Main Division of Responsibilities between IETF and ISOC The IETF remains responsible for the development and quality of the Internet Standards. Apart from the roles described below, the IETF and ISOC acknowledge that ISOC as an organization has no direct influence whatsoever on the technical content of Internet Standards Camarillo & Livingood Expires February 27, 2020 [Page 3] Internet-Draft The IETF-ISOC Relationship August 2019 (though ISOC employees may independently continue to make technical contributions as individuals). 4. ISOC's Role in the IETF Standards Process ISOC plays a small role in the IETF standards process. In particular, ISOC assists the standards process by appointing the IETF NomCom chair and by confirming IAB candidates who are put forward by the IETF NomCom, as described in [RFC7437], and by acting as the last resort in the appeals process, as described in [RFC2026]. ISOC maintains liaison relationships and memberships in other Standards Development Organizations (SDOs) and related organizations, which directly benefits the IETF. For example, ISOC is a Sector Member of the ITU-T. As a result, ISOC delegates are afforded the same rights as other ITU-T Sector Members [RFC6756]. ISOC also supports the IETF standards process more indirectly (e.g., by promoting it in relevant communities) through several programs. For example, ISOC's Policymakers Program to the IETF (usually referred to simply as ISOC's policy fellows program) gives policy experts an opportunity to interact directly with the IETF technical community. ISOC also performs technical work using the standards developed in the IETF as its basis. An example of that is ISOC's Deploy360 program, which helps encourage and support the deployment of IETF standards like DNSSEC [RFC4033] and IPv6 [RFC8200]. Otherwise, the involvement of ISOC's employees in the IETF standards process (e.g., as document editors or in leadership positions) is as individual contributors rather than on institutional grounds. 5. The IETF's Role in ISOC The IETF plays a role in the governance of ISOC. Per ISOC's by-laws, the IETF appoints a set of trustees to the ISOC Board. The process by which the IETF makes those appointments is defined in [RFC3677]. The charter of the IAB (Internet Architecture Board) [RFC2850] states that "the IAB acts as a source of advice and guidance to the Board of Trustees and Officers of the Internet Society concerning technical, architectural, procedural, and (where appropriate) policy matters pertaining to the Internet and its enabling technologies". This connection between the IAB and ISOC ensures that ISOC's proposals in the policy area are based on a sound understanding of the relevant technologies and architectures. ISOC's strong connection to the Internet technical community has always been one of its main strengths. Camarillo & Livingood Expires February 27, 2020 [Page 4] Internet-Draft The IETF-ISOC Relationship August 2019 6. Legal Relationship with ISOC The IETF LLC is a disregarded Limited Liability Company (LLC) of the Internet Society - established to provide a corporate legal framework for facilitating current and future activities related to the IETF, IAB, and IRTF. It was established by the ISOC/IETF LLC Agreement [OpAgreement] on August 27, 2018, and governs the relationship between the IETF LLC and ISOC. The IETF Trust, documented in [RFC5378], and updated in [I-D.ietf-iasa2-trust-rationale] and [I-D.ietf-iasa2-trust-update], provides legal protection for the RFC series of documents and other aspects of the IETF. This includes things such as protection for trademarks, copyrights, and intellectual property rights. As part of the IETF Trust arrangement, IETF standards documents can be freely downloaded, copied, and distributed without financial or other distribution restrictions, though all rights to change these documents lie with the IETF. The IETF Trust also provides legal protection in case of disputes over intellectual property rights and other rights. The creation of the IETF LLC has changed the way that the IETF Trust's trustees are selected but did not change the purpose or operation of the Trust. One of the IETF Trust's trustees is appointed by the ISOC's Board of Trustees. 7. Financial and Administrative Relationship with ISOC Under the terms of the Operating Agreement [OpAgreement] between ISOC and the IETF, ISOC has agreed to provide significant funding support for the IETF. In addition, the IETF LLC is responsible for creating and managing an annual operating budget for the IETF; for negotiating, signing, and overseeing contracts; for fundraising; for maintaining bank accounts; and for liability insurance. The IETF LLC is managed by a Board of Directors, one of whom is appointed by the ISOC's Board of Trustees. The intention is that ISOC and the IETF LLC operate at arm's length. The IETF LLC establishes contracts with third parties to provide different types of services to the IETF. Note that it is possible that some of those services may be provided by ISOC or involve ISOC staff. Under the new IASA 2.0 structure, the IETF LLC is solely responsible for its administration, including the IETF Trust, IAB, IESG, IETF working groups, and other IETF processes. A further exploration of this can be found in Section 4 of [I-D.ietf-iasa2-rfc4071bis]. Camarillo & Livingood Expires February 27, 2020 [Page 5] Internet-Draft The IETF-ISOC Relationship August 2019 8. IANA Considerations This document introduces no new IANA considerations. 9. Security Considerations This document introduces no new security considerations. 10. Privacy Considerations This document introduces no new privacy considerations. 11. Acknowledgements The authors would like to thank Erik Huizer for his contribution as the author of [RFC2031], which this document replaces. 12. Changes from Previous Versions RFC Editor: Please remove this section upon publication. -00: Initial version published -01: Several key updates to prepare WGLC based on WG feedback -02: Fixed nits identified by Brian Carpenter on 12-21-2018, and text on the tax status from John Levine. -03: As we entered IESG review, added a short description of what ISOC does (in relation to the IETF) that can be used in external material by both the IETF and ISOC. -04: Clarification adding text to Section 6 on legal issue. -05: Fix nits -06: Fix nits and other changes from IESG review -07: Fixed one missed nit from IESG review -08: Fixed two typographical errors 13. References Camarillo & Livingood Expires February 27, 2020 [Page 6] Internet-Draft The IETF-ISOC Relationship August 2019 13.1. Normative References [I-D.ietf-iasa2-rfc4071bis] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", draft-ietf-iasa2-rfc4071bis-11 (work in progress), April 2019. 13.2. Informative References [BCP10] "BCP10", . [I-D.ietf-iasa2-trust-rationale] Arkko, J., "Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust", draft-ietf-iasa2-trust- rationale-03 (work in progress), October 2018. [I-D.ietf-iasa2-trust-update] Arkko, J. and T. Hardie, "Update to the Process for Selection of Trustees for the IETF Trust", draft-ietf- iasa2-trust-update-03 (work in progress), February 2019. [ISOC-Mission] "ISOC Mission", . [OpAgreement] "Limited Liability Company Agreement of IETF Administration LLC", August 2018, . [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, DOI 10.17487/RFC2028, October 1996, . [RFC2031] Huizer, E., "IETF-ISOC relationship", RFC 2031, DOI 10.17487/RFC2031, October 1996, . Camarillo & Livingood Expires February 27, 2020 [Page 7] Internet-Draft The IETF-ISOC Relationship August 2019 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, . [RFC3677] Daigle, L., Ed. and Internet Architecture Board, "IETF ISOC Board of Trustee Appointment Procedures", BCP 77, RFC 3677, DOI 10.17487/RFC3677, December 2003, . [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, . [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, . [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, January 2006, . [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, . [RFC6756] Trowbridge, S., Ed., Lear, E., Ed., Fishman, G., Ed., and S. Bradner, Ed., "Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines", RFC 6756, DOI 10.17487/RFC6756, September 2012, . [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 7437, DOI 10.17487/RFC7437, January 2015, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . Camarillo & Livingood Expires February 27, 2020 [Page 8] Internet-Draft The IETF-ISOC Relationship August 2019 Authors' Addresses Gonzalo Camarillo Ericsson Email: Gonzalo.Camarillo@ericsson.com Jason Livingood Comcast Email: jason_livingood@comcast.com Camarillo & Livingood Expires February 27, 2020 [Page 9] ./draft-ietf-6lo-deadline-time-05.txt0000644000764400076440000013503313510745742016571 0ustar iustyiusty 6lo Lijo Thomas Internet-Draft C-DAC Intended status: Standards Track S. Anamalamudi Expires: January 9, 2020 SRM University-AP S.V.R.Anand Malati Hegde Indian Institute of Science C. Perkins Futurewei July 8, 2019 Packet Delivery Deadline time in 6LoWPAN Routing Header draft-ietf-6lo-deadline-time-05 Abstract This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time critical IoT machine to machine (M2M) applications that operate within time-synchronized networks that agree on the meaning of the time representations used for the deadline time values. 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 https://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 9, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Lijo Thomas, et al. Expires January 9, 2020 [Page 1] Internet-Draft 6lo Delivery Deadline Time July 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 8 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 9 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Changes from revision 04 to revision 05 . . . . . . 18 Appendix B. Changes from revision 03 to revision 04 . . . . . . 18 Appendix C. Changes from revision 02 to revision 03 . . . . . . 19 Appendix D. Changes from revision 01 to revision 02 . . . . . . 19 Appendix E. Changes between earlier versions . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Low Power and Lossy Networks (LLNs) are likely to be deployed for real time industrial applications requiring end-to-end delay guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network ("detnet") typically requires some data packets to reach their receivers within strict time bounds. Intermediate nodes use the deadline information to make appropriate packet forwarding and scheduling decisions to meet the time bounds. Lijo Thomas, et al. Expires January 9, 2020 [Page 2] Internet-Draft 6lo Delivery Deadline Time July 2019 This document specifies a new type for the Elective 6LoWPAN Routing Header (6LoRHE), so that the deadline time (i.e., the time of latest acceptable delivery) of data packets can be included within the 6LoWPAN routing header. [RFC8138] specifies the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL routing (source routing) operation [RFC6554], header compression of RPL Packet Information [RFC6553], and IP-in-IP encapsulation. This document also specifies handling of the deadline time when packets traverse between time- synchronized networks operating in different timezones or distinct reference clocks. Time synchronization techniques are outside the scope of this document. There are a number of standards available for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. The Deadline-6LoRHE can be used in any time synchronized 6Lo network. A 6TiSCH network is used to describe the implementation of the Deadline-6LoRHE, but this does not preclude its use in scenarios other than 6TiSCH. For instance, there is a growing interest in using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in industrial IoT [dotBLEMesh]. BLE mesh time synchronization is being explored by the Bluetooth community. There are also cases under consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN]. 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] [RFC8174]. This document uses the terminology defined in [RFC6550] and [I-D.ietf-6tisch-terminology]. 3. 6LoRHE Generic Format Note: this section is not normative and is included for convenience. The generic header format of the 6LoRHE is specified in [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE generic format. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ |1|0|1| Length | Type | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ <--- length ---> Figure 1: 6LoRHE format Lijo Thomas, et al. Expires January 9, 2020 [Page 3] Internet-Draft 6lo Delivery Deadline Time July 2019 o Length: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This enables a node to skip a 6LoRHE if the Type is not recognized/supported. o Type (variable length): Type of the 6LoRHE (see Section 7) 4. Deadline-6LoRHE The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6 datagram in a compressed form. Along with the deadline, the header can include the packet Origination Time Delta (OTD), the time at which the packet is enqueued for transmission (expressed as a value to be subtracted from DT); this enables a close estimate of the total delay incurred by a packet. The OTD field is initialized by the sender based on the current time at the outgoing network interface through which the packet is forwarded. Since the OTD is a delta, the length of the OTD field (i.e., OTL) will require fewer bits than the length of the DT field (i.e., DTL). The deadline field contains the value of the deadline time for the packet -- in other words, the time by which the application expects the packet to be delivered to the Receiver. packet_deadline_time = packet_origination_time + max_delay In order to support delay-sensitive deterministic applications, all nodes within the network should process the Deadline-6LoRHE. The packet deadline time (DT) and origination time (OTD) are represented in time units determined by a scaling parameter in the routing header. The Network ASN (Absolute Slot Number) can be used as a time unit in a time slotted synchronized network (for instance a 6TiSCH network, where global time is maintained in the units of slot lengths of a certain resolution). The delay experienced by packets in the network is a useful metric for network diagnostics and performance monitoring. Whenever a packet crosses into a network using a different reference clock, the Destination Time field is updated to represent the same Destination Time, but expressed using the reference clock of the interface into the new network. Then the origination time is the same as the current time when the packet is transmitted into the new network, minus the delay already experienced by the packet, say 'current_dly'. In this way, within the newly entered network, the packet will appear to have originated 'current_dly' time units earlier with respect to the reference clock of the new network. new_network_origin_time = time_now_in_new_network - current_dly Lijo Thomas, et al. Expires January 9, 2020 [Page 4] Internet-Draft 6lo Delivery Deadline Time July 2019 The following example illustrates these calculations when a packet travels between three networks, each in a different time zone. 'x' can be 1, 2 or 3. Suppose that the deadline time as measured in timezone 1 is 1050 and the origination time is 50. Suppose that the difference between TZ2 and TZ1 is 900, and the difference between TZ3 and TZ3 is 3600. In the figure, OT is the origination time as measured in the current timezone, and is equal to DT - OTD, that is, DT - 1000. Figure 2 uses the following abbreviations: TxA : Time of arrival of packet in the network 'x' TxD : Departure time of packet from the network 'x' dlyx : Delay experienced by the packet in the previous network(s) TZx : The time zone of network 'x' TZ1 TZ2 TZ3 T1A=50| | | |---- dly1=50 | | | \ | | | \ | | | \ T1D=100 |T2A=1000 | | -------->|----- dly2=450 | | | \ | | | \ | | | \ T2D=1400 | T3A=5000 | | ------------------->|----------> | | | v v v dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2 = 100-50 = 1400 - 950 = 50 = 450 OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2 = 50 = 1000-50 = 5000 - 450 = 950 = 4550 Figure 2: Destination Time Update example There are multiple ways that a packet can be delayed, including queuing delay, MAC layer contention delay, serialization delay, and propagation delays. Sometimes there are processing delays as well. For the purpose of determining whether or not the deadline has already passed, these various delays are not distinguished. Lijo Thomas, et al. Expires January 9, 2020 [Page 5] Internet-Draft 6lo Delivery Deadline Time July 2019 5. Deadline-6LoRHE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|1| Length | 6LoRH Type |D| TU| DTL | OTL | BinaryPt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DT (variable length) | OTD(variable length)(optional)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Deadline-6LoRHE format o Length (5 bits): Length represents the total length of the Deadline-6LoRHE type measured in octets. o 6LoRH Type: TBD (see Section 7) o D flag (1 bit): The 'D' flag, set by the Sender, qualifies the action to be taken when a 6LR detects that the deadline time has elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline time is elapsed. If 'D' bit is 0, the packet MAY be forwarded on an exception basis, if the forwarding node is NOT in a situation of constrained resource, and if there are reasons to suspect that downstream nodes might find it useful (delay measurements, interpolations, etc.). o TU (2 bits) : Indicates the time units for DT and OTD fields. The encodings for the DT and OTD fields use the same time units and precision. * 00 : Time represented in seconds and fractional seconds * 01 : Reserved * 10 : Network ASN * 11 : Reserved o DTL (4 bits): Length of DT field as an unsigned 4-bit integer, encoding the length of the field in hex digits, minus one. o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, encoding the length of the field in hex digits. If OTL == 0, the OTD field is not present. The value of OTL MUST NOT exceed the value of DTL plus one. * For example, DTL = 0b0000 means the deadline time in the 6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the origination time is 7 hex digits (28 bits) long. o Binary Pt (6 bits) : If zero, the number of bits of the integer part the DT is equal to the number of bits of the fractional part of the DT. if nonzero, the Binary Pt is a signed integer determining the position of the binary point within the value for the DT. Lijo Thomas, et al. Expires January 9, 2020 [Page 6] Internet-Draft 6lo Delivery Deadline Time July 2019 * If BinaryPt value is positive, then the number of bits for the integer part of the DT is increased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly reduced. This increases the range of DT. * If BinaryPt value is negative, then the number of bits for the integer part of the DT is decreased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly increased. This increases the precision of the fractional seconds part of DT. o DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits giving the Deadline Time value o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits giving the Origination Time as a negative offset from the DT value Whenever a sender initiates the IP datagram, it includes the Deadline-6LoRHE along with other 6LoRH information. For information about the time synchronization requirements between sender and receiver see Section 8. For the chosen time unit, a compressed time representation is available as follows. First, the application on the originating node has to determine how many time bits are needed to represent the difference between the time at which the packet is launched and the deadline time, including the representation of fractional time units. That number of bits (say, N_bits) determines DTL (the length of the Deadline Time (DT)) as follows: DTL = (N_bits mod 4) The number of bits determined by DTL allows counting any number of fractional time units in the range of interest determined by DT and the origination time OT. Denote this number of fractional time units to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL). Epoch_Range(DTL) = (2^(4*(DTL+1)) Each point of time between OT and DT is represented by a time unit and a fractional time unit; in this section, this combined representation is called a rational time unit (RTU). 1 RTU measures the smallest fractional time that can be represented between two points of time in the epoch (i.e., within the range of interest). DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). The values that can be represented in the current epoch are in the range [0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL, Lijo Thomas, et al. Expires January 9, 2020 [Page 7] Internet-Draft 6lo Delivery Deadline Time July 2019 wraparound is allowed but works naturally with the arithmetic modulo Epoch_Range. By default, DTL determines t_0 in the chosen RTUs as follows: t_0 = [current_time - (current_time mod Epoch_Range (DTL))]. Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current epoch. The last possible origination time representable in the current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)). In the RTUs chosen, the current epoch resides at the underlying time interval [t_0, t_last]. If DT - OT is greater than t_last - OT, then wraparound within the Epoch_Range occurs naturally. In all cases, OT is represented by the value (OT mod Epoch_Range) and DT is represented by the value (DT mod Epoch_Range). All arithmetic is to be performed modulo (Epoch_Range(DTL)), yielding only positive values for DT - OT. Example: Consider a 6TiSCH network with time-slot length of 10ms. Let the time units be ASNs (TU == (binary)0b10). Let the current ASN when the packet is originated be 54400, and the maximum allowable delay (max_delay) for the packet delivery be 1 second from the packet origination, then: deadline_time = packet_origination_time + max_delay = 0xD480 + 0x64 (Network ASNs) = 0xD4E4 (Network ASNs) Then, the Deadline-6LoRHE encoding with nonzero OTL is: DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD = 0x64 6. Deadline-6LoRHE in Three Network Scenarios In this section, Deadline-6LoRHE operation is described for 3 network scenarios. Figure 4 depicts a constrained time-synchronized LLN that has two subnets N1 and N2, connected through LBRs [I-D.ietf-6lo-backbone-router] with different reference clock times T1 and T2. Lijo Thomas, et al. Expires January 9, 2020 [Page 8] Internet-Draft 6lo Delivery Deadline Time July 2019 +-------------------+ | Time Synchronized | | Network | +---------+---------+ | | | +--------------+--------------+ | | +-----+ +-----+ | | Backbone | | Backbone o | | router | | router +-----+ +-----+ o o o o o o o o o o o o o LLN o o LLN o o o o o o o o o o o 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) Figure 4: Intra-network Timezone Scenario 6.1. Scenario 1: Endpoints in the same DODAG (N1) In scenario 1, shown in Figure 5, the Sender 'S' has an IP datagram to be routed to a Receiver 'R' within the same DODAG. For the route segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by encoding the deadline time contained in the packet. Subsequently, each 6LR will perform hop-by-hop routing to forward the packet towards the 6LBR. Once 6LBR receives the IP datagram, it sends the packet downstream towards 'R'. In case of a network running RPL non-storing mode, the 6LBR generates a IPv6-in-IPv6 encapsulated packet when sending the packet downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the Deadline-6LoRHE from the Sender originated IP header to the outer IP header. The Deadline-6LoRHE contained in the inner IP header is removed. Lijo Thomas, et al. Expires January 9, 2020 [Page 9] Internet-Draft 6lo Delivery Deadline Time July 2019 +-------+ ^ | 6LBR | | | | | | | +-------+ | Upward | / /| \ | Downward routing | (F) / | \ | routing | / \ (C) | (D) | | / \ | | / |\ | | (A) (B) : (E) : R | | /|\ | \ / \ | | S : : : : : : v Figure 5: End points within same DODAG (subnet N1) At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is copied back from the outer header to inner header, and the inner IP packet is delivered to 'R'. 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. In scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG 1) has IP datagram to be routed to a Receiver 'R' over a time- synchronized IPv6 network. For the route segment from 'S' to 6LBR, 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform hop-by-hop routing to forward the packet towards the 6LBR. Once the Deadline Time information reaches the border router, the packet will be encoded according to the mechanism prescribed in the other time- synchronized network depicted as "Time Synchronized Network" in the figure 6. The specific data encapsulation mechanisms followed in the new network are beyond the scope of this document. Lijo Thomas, et al. Expires January 9, 2020 [Page 10] Internet-Draft 6lo Delivery Deadline Time July 2019 +----------------+ | Time | | Synchronized |------R | Network | +----------------+ | | ----------+----------- ^ | | +---+---+ | | 6LBR | Upward | | | routing | +------++ | (F)/ /| \ | / \ / | \ | / \ (C) | (D) | (A) (B) | | / |\ | /|\ |\ : (E) : : | S : : : : / \ : : Figure 6: Packet transmission in Dissimilar L2 Technologies or Internet For instance, the IP datagram could be routed to another time synchronized deterministic network using the mechanism specified in the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time would be updated according to the measurement of the current time in the new network. 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2). Consider the scenario depicted in Figure 7, in which the Sender 'S' (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' belonging to another DODAG (DODAG 2). The operation of this scenario can be decomposed into combination of case 1 and case 2 scenarios. For the route segment from 'S' to 6LBR1, 'S' includes the Deadline- 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to forward the packet towards the 6LBR1. Once the IP datagram reaches 6LBR1 of DODAG1, it applies the same rule as described in Case 2 while routing the packet to 6LBR2 over a (likely) time synchronized wired backhaul. The wired side of 6LBR2 can be mapped to receiver of Case 2. Once the packet reaches 6LBR2, it updates the Deadline- 6LoRHE by adding or subtracting the difference of time of DODAG2 and sends the packet downstream towards 'R'. Lijo Thomas, et al. Expires January 9, 2020 [Page 11] Internet-Draft 6lo Delivery Deadline Time July 2019 Time Synchronized Network -+---------------------------+- | | DODAG1 +---+---+ +---+---+ DODAG2 | 6LBR1 | | 6LBR2 | | | | | +-------+ +-------+ (F)/ /| \ (F)/ /| \ / \ / | \ / \ / | \ / \ (C) | (D) / \ (C) | (D) (A) (B) | | / |\ (A) (B) | | |\ /|\ |\ : (E) : : /|\ |\ : (E) : : S : : : : / \ : : : : : / \ : : : R Network N1, time zone T1 Network N2, time zone T2 Figure 7: Packet transmission in different DODAGs(N1 to N2) Consider an example of a 6TiSCH network in which S in DODAG1 generates the packet at ASN 20000 to R in DODAG2. Let the maximum allowable delay be 1 second. The time-slot length in DODAG1 and DODAG2 is assumed to be 10ms. Once the deadline time is encoded in Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose the packet reaches 6LBR of DODAG1 at ASN 20030. current_time = ASN at LBR * slot_length_value remaining_time = deadline_time - current_time = ((packet_origination_time + max_delay) - current time) = (20000 + 100) - 20030 = 30 (in Network ASNs) = 30 * 10^3 milliseconds. Once the Deadline Time information reaches the border router, the packet will be encoded according to the mechanism prescribed in the other time-synchronized network. 7. IANA Considerations This document defines a new Elective 6LoWPAN Routing Header Type, and IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch Page1 number space for this purpose. Lijo Thomas, et al. Expires January 9, 2020 [Page 12] Internet-Draft 6lo Delivery Deadline Time July 2019 Elective 6LoRH Type Value +----------------------+--------+ | Deadline-6LoRHE | TBD | +----------------------+--------+ Figure 8: Deadline-6LoRHE type 8. Synchronization Aspects The document supports time representation of the deadline and origination times carried in the packets traversing through networks of different time zones having different time synchronization mechanisms. For instance, in a 6TiSCH network where the time is maintained as ASN time slots, the time synchronization is achieved through beaconing among the nodes as described in [RFC7554]. There could be 6lo networks that employ NTP where the nodes are synchronized with an external reference clock from an NTP server. The specification of the time synchronization method that need to be followed by a network is beyond the scope of the document. The number of hex digits chosen to represent DT, and the portion of that field allocated to represent integer number of seconds, determines the meaning of t_0, i.e., the meaning of DT == 0 in the chosen representation. If DTL == 0, then there are only 4 bits that can be used to count the time units, so that DT == 0 can never be more than 16 time units (or fractional time units) in the past. This then requires that the time synchronization between sender and receiver has to be tighter than 16 units. If the binary point were moved so that all the bits were used for fractional time units (e.g., fractional seconds or fractional ASNs), the time synchronization requirement would be correspondingly tighter. A 4-bit field for DT allows up to 16 hex digits, which is 64 bits. That is enough to represent the NTP [RFC5905] 64-bit timestamp format, which is more than enough for the purposes of establishing deadline times. Unless the binary point is moved, this is enough to represent time since year 1900. For example, suppose that DTL = 0b0000 and the DT bits are split evenly; then we can count up to 3.75 seconds by quarter-seconds. If DTL = 3 and the DT bits are again split evenly, then we can count up to 256 seconds (in steps of 1/256 of a second). In all cases, t_0 is defined as specified in Section 5 t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] Lijo Thomas, et al. Expires January 9, 2020 [Page 13] Internet-Draft 6lo Delivery Deadline Time July 2019 regardless of the choice of TU. For TU = 0b00, the time units are seconds. With DTL == 15, and Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00 UTC. The resolution is then (2 ^ (- 32)) seconds, which is the maximum possible. This time format wraps around every 2^32 seconds, which is roughly 136 years. For TU = 0b10, the time units are ASNs. The start time is relative, and updated by a mechanism out of scope for this document. With 10 ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for the ASN to wrap around. Typically, the number of hex digits allocated for TU = 0b10 would be less than 15. 9. Security Considerations The security considerations of [RFC4944], [RFC6282] and [RFC6553] apply. Using a compressed format as opposed to the full in-line format is logically equivalent and does not create an opening for a new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. The protocol elements specified in this document are designed to work in controlled operational environments (e.g., industrial process control and automation). In order to avoid misuse of the deadline information that could potentially result in a Denial of Service (DoS) attack, proper functioning of this deadline time mechanism requires the provisioning and management of network resources for supporting traffic flows with deadlines, performance monitoring, and admission control policy enforcement. The network provisioning can be done either centrally or in a distributed fashion. For example, tracks in a 6tisch network could be established by a centralized PCE, as described in the 6tisch architecture [I-D.ietf-6tisch-architecture]. The Security Considerations of Detnet architecture [I-D.ietf-detnet-architecture] mostly apply to this document as well, as follows. To secure the request and control of resources allocated for tracks, authentication and authorization can be used for each device, and network controller devices. In the case of distributed control protocols, security is expected to be provided by the security properties of the protocols in use. When deadline bearing flows are identified on a per-flow basis, which may provide attackers with additional information about the data flows, when compared to networks that do not include per-flow identification. The security implications of disclosing that additional information deserve consideration when implementing this deadline specification. Lijo Thomas, et al. Expires January 9, 2020 [Page 14] Internet-Draft 6lo Delivery Deadline Time July 2019 Because of the requirement of precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic can be found in [RFC7384]. 10. Acknowledgements The authors thank Pascal Thubert for suggesting the idea and encouraging the work. Thanks to Shwetha Bhandari's suggestions which were instrumental in extending the timing information to heterogeneous networks. The authors acknowledge the 6TiSCH WG members for their inputs on the mailing list. Special thanks to Jerry Daniel, Dan Frost (Routing Directorate) Charlie Kaufman (Security Directorate) Seema Kumar, Tal Mizrahi Avinash Mohan, Shalu Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for their support and valuable feedback. 11. References 11.1. Normative References [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-terminology-10 (work in progress), March 2018. [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- detnet-architecture-13 (work in progress), May 2019. [I-D.ietf-roll-routing-dispatch] Thubert, P., Bormann, C., Toutain, L., and R. Cragie, "6LoWPAN Routing Header", draft-ietf-roll-routing- dispatch-05 (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, . [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, . Lijo Thomas, et al. Expires January 9, 2020 [Page 15] Internet-Draft 6lo Delivery Deadline Time July 2019 [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, . [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, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, . [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, . [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, . [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Lijo Thomas, et al. Expires January 9, 2020 [Page 16] Internet-Draft 6lo Delivery Deadline Time July 2019 11.2. Informative References [dot15-tsch] "IEEE 802 Wireless", "IEEE Standard for Low-Rate Wireless Networks, Part 15.4, IEEE Std 802.15.4-2015", April 2016. [dot1AS-2011] "IEEE Standards", "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", March 2011. [dotBLEMesh] Leonardi, L., Pattim, G., and L. Lo Bello, "Multi-Hop Real-Time Communications Over Bluetooth Low Energy Industrial Wireless Mesh Networks", IEEE Access Vol 6, 26505-26519, May 2018. [dotWi-SUN] Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN Communication Systems", IEICE Transactions on Communications volume E100.B, Jan 2017. [I-D.ietf-6lo-backbone-router] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Backbone Router", draft-ietf-6lo-backbone-router-11 (work in progress), February 2019. [I-D.ietf-6lo-blemesh] Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", draft-ietf-6lo-blemesh-05 (work in progress), March 2019. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work in progress), July 2019. [I-D.ietf-detnet-use-cases] Grossman, E., "Deterministic Networking Use Cases", draft- ietf-detnet-use-cases-20 (work in progress), December 2018. Lijo Thomas, et al. Expires January 9, 2020 [Page 17] Internet-Draft 6lo Delivery Deadline Time July 2019 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- data-06 (work in progress), July 2019. [I-D.ietf-roll-useofrplinfo] Robles, I., Richardson, M., and P. Thubert, "Using RPL Option Type, Routing Header for Source Routes and IPv6-in- IPv6 encapsulation in the RPL Data Plane", draft-ietf- roll-useofrplinfo-31 (work in progress), July 2019. [ieee-1588] "IEEE Standards", "IEEE Std 1588-2008 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", July 2008. [Wi-SUN_PHY] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March 2016. Appendix A. Changes from revision 04 to revision 05 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-04.txt and ...-05.txt. o Included additional relevant material in Security Considerations regarding expected deployment scenarios and the effect of disclosing additional information during the travel of a packet. o Reworked the specification for using time ranges shorter than the maximum allowed by the choice of TU, so that fewer bits are needed to represent DT and OT. o Revised the figures and examples to use new parameters o Reordered the field definitions for the Deadline-6LoRHE. o Responded to numerous reviewer comments to improve terminology and editorial consistency. Appendix B. Changes from revision 03 to revision 04 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-03.txt and ...-04.txt. Lijo Thomas, et al. Expires January 9, 2020 [Page 18] Internet-Draft 6lo Delivery Deadline Time July 2019 o Replaced OT (Origination Time) field by OTD (Origination Time Delta), allowing a more compressed representation that needs less processing during transitions between networks. o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in favor of BinaryPt. o Revised the figures and examples to use new parameters o Added new section on Synchronization Aspects to supply pertinent information about how nodes agree on the meaning of t=0. o Responded to numerous reviewer comments to improve editorial consistency and improve terminology. Appendix C. Changes from revision 02 to revision 03 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-02.txt and ...-03.txt. o Added non-normative 6LoRHE description, citing RFC 8138. o Specified that the Origination Time (OT) is the time that packet is enqueued for transmission. o Mentioned more sources of packet delay. o Clarified reasons that packet MAY be forwarded if 'D' bit is 0. o Clarified that DT, OT, DTL and OTL are unsigned integers. o Updated bibliographic citations, including BLEmesh and Wi-SUN. Appendix D. Changes from revision 01 to revision 02 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-01.txt and ...-02.txt. o Replaced 6LoRHE description by reference to RFC 8138. o Added figure to illustrate change to Origination Time when a packet crosses timezone boundaries. o Clarified that use of 6tisch networks is descriptive, not normative. o Clarified that In-Band OAM is used as an example and is not normative. Lijo Thomas, et al. Expires January 9, 2020 [Page 19] Internet-Draft 6lo Delivery Deadline Time July 2019 o Updated bibliographic citations. o Alphabetized contributor names. Appendix E. Changes between earlier versions This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-00.txt and ...-01.txt. o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is passed (see Section 5). o Added explanatory text about how packet delays might arise. (see Section 4). o Mentioned availability of time-synchronization protocols (see Section 1). o Updated bibliographic citations. o Alphabetized contributor names. o Added this section. Authors' Addresses Lijo Thomas C-DAC Centre for Development of Advanced Computing (C-DAC), Vellayambalam Trivandrum 695033 India Email: lijo@cdac.in Satish Anamalamudi SRM University-AP Amaravati Campus Amaravati, Andhra Pradesh 522 502 India Email: satishnaidu80@gmail.com Lijo Thomas, et al. Expires January 9, 2020 [Page 20] Internet-Draft 6lo Delivery Deadline Time July 2019 S.V.R Anand Indian Institute of Science Bangalore 560012 India Email: anand@ece.iisc.ernet.in Malati Hegde Indian Institute of Science Bangalore 560012 India Email: malati@ece.iisc.ernet.in Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara 95050 Unites States Email: charliep@computer.org Lijo Thomas, et al. Expires January 9, 2020 [Page 21] ./draft-ietf-curdle-ssh-ed25519-ed448-11.txt0000644000764400076440000002762713535642106017270 0ustar iustyiusty Internet Engineering Task Force B. Harris Internet-Draft Updates: RFC4253 (if approved) L. Velvindron Intended status: Standards Track cyberstorm.mu Expires: March 12, 2020 September 9, 2019 Ed25519 and Ed448 public key algorithms for the Secure Shell (SSH) protocol draft-ietf-curdle-ssh-ed25519-ed448-11 Abstract This document describes the use of the Ed25519 and Ed448 digital signature algorithm in the Secure Shell (SSH) 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 https://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 12, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Harris & Velvindron Expires March 12, 2020 [Page 1] Internet-Draft Ed25519 for SSH September 2019 1. Introduction Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. It provides for an extensible variety of public key algorithms for identifying servers and users to one another. Ed25519 [RFC8032] is a digital signature system. OpenSSH 6.5 [OpenSSH-6.5] introduced support for using Ed25519 for server and user authentication and was then followed by other SSH implementations. This document describes the method implemented by OpenSSH and others, and formalizes its use of the name "ssh-ed25519". Additionally, it also describes the use of Ed448 and formalizes its use of the name "ssh-ed448". [TO BE REMOVED: Please send comments on this draft to curdle@ietf.org.] 2. Conventions Used in This Document The descriptions of key and signature formats use the notation introduced in [RFC4251], Section 3 [RFC4251] and the string data type from [RFC4251], Section 5 [RFC4251]. 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] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Public Key Algorithm This document describes a public key algorithm for use with SSH in accordance with [RFC4253], Section 6.6 [RFC4253]. The name of the algorithm is "ssh-ed25519". This algorithm only supports signing and not encryption. Additionally, this document describes another public key algorithm. The name of the algorithm is "ssh-ed448". This algorithm only supports signing and not encryption. Standard implementations of SSH SHOULD implement these signature algorithms. Harris & Velvindron Expires March 12, 2020 [Page 2] Internet-Draft Ed25519 for SSH September 2019 4. Public Key Format The "ssh-ed25519" key format has the following encoding: string "ssh-ed25519" string key Here 'key' is the 32-octet public key described by [RFC8032], Section 5.1.5 [RFC8032]. The "ssh-ed448" key format has the following encoding: string "ssh-ed448" string key Here 'key' is the 57-octet public key described by [RFC8032], Section 5.2.5 [RFC8032]. 5. Signature Algorithm Signatures are generated according to the procedure in [RFC8032], Section 5.1.6 and Section 5.2.6 [RFC8032]. 6. Signature Format The "ssh-ed25519" key format has the following encoding: string "ssh-ed25519" string signature Here 'signature' is the 64-octet signature produced in accordance with [RFC8032], Section 5.1.6 [RFC8032]. The "ssh-ed448" key format has the following encoding: string "ssh-ed448" string signature Here 'signature' is the 114-octet signature produced in accordance with [RFC8032], Section 5.2.6 [RFC8032]. 7. Verification Algorithm Ed25519 signatures are verified according to the procedure in [RFC8032], Section 5.1.7 [RFC8032]. Ed448 signatures are verified according to the procedure in [RFC8032], Section 5.2.7 [RFC8032]. Harris & Velvindron Expires March 12, 2020 [Page 3] Internet-Draft Ed25519 for SSH September 2019 8. SSHFP DNS resource records Usage and generation of SSHFP DNS resource record is described in [RFC4255]. The generation of SSHFP resource records for "ssh- ed25519" keys is described in [RFC7479]. This section illustrates the generation of SSHFP resource records for "ssh-ed448" keys and the document specifies the corresponding Ed448 code point to the "SSHFP RR Types for public key algorithms" IANA registry. The generation of SSHFP resource records for "ssh-ed25519" keys is described in [RFC7479]. The generation of SSHFP resource records for "ssh-ed448" keys is described as follows. The encoding of Ed448 public keys is described in [ED448]. In brief, an Ed448 public key is a 57-octet value representing a 455-bit y-coordinate of an elliptic curve point, and a sign bit indicating the the corresponding x-coordinate. The SSHFP Resource Record for the Ed448 public key with SHA-256 fingerprint would for example be: example.com. IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f2826723 34d90ed316d2b818ca9580ea384d924 01 ) The 2 here indicates SHA-256 [RFC6594]. 9. IANA Considerations This document augments the Public Key Algorithm Names in [RFC4250], Section 4.6.2 [RFC4250]. IANA is requested to add to the Public Key Algorithm Names registry [IANA-PKA] with the following entry: Public Key Algorithm Name Reference ------------------------- ---------- ssh-ed25519 This Draft ssh-ed448 This Draft IANA is requested to add the following entry to the "SSHFP RR Types for public key algorithms" registry [IANA-SSHFP]: +--------+-------------+------------+ | Value | Description | Reference | Harris & Velvindron Expires March 12, 2020 [Page 4] Internet-Draft Ed25519 for SSH September 2019 +--------+-------------+------------+ | TBD | Ed448 | [this-draft] | +--------+-------------+------------+ We strongly suggest 6 as value. [TO BE REMOVED: This registration should take place at the following location: ] 10. Security Considerations The security considerations in [RFC4251], Section 9 [RFC4251] apply to all SSH implementations, including those using Ed25519 and Ed448. The security considerations in [RFC8032], Section 8 [RFC8032] and [RFC7479] apply to all uses of Ed25519 and Ed448 including those in SSH. 11. Acknowledgements The OpenSSH implementation of Ed25519 in SSH was written by Markus Friedl. We are also grateful to Mark Baushke, Benjamin Kaduk and Daniel Migault for their comments. 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, . [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . Harris & Velvindron Expires March 12, 2020 [Page 5] Internet-Draft Ed25519 for SSH September 2019 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, DOI 10.17487/RFC4255, January 2006, . [RFC6594] Sury, O., "Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records", RFC 6594, DOI 10.17487/RFC6594, April 2012, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [ED448] Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", January 2015, . [IANA-PKA] Internet Assigned Numbers Authority (IANA), "Secure Shell (SSH) Protocol Parameters: Public Key Algorithm Names", May 2017, . [IANA-SSHFP] Internet Assigned Numbers Authority (IANA), "Secure Shell (SSH) Protocol Parameters: Public Key Algorithm Names", May 2017, . [OpenSSH-6.5] Friedl, M., Provos, N., de Raadt, T., Steves, K., Miller, D., Tucker, D., Rice, T., and B. Lindstrom, "OpenSSH 6.5 release notes", January 2014, . [RFC7479] Moonesamy, S., "Using Ed25519 in SSHFP Resource Records", RFC 7479, DOI 10.17487/RFC7479, March 2015, . Harris & Velvindron Expires March 12, 2020 [Page 6] Internet-Draft Ed25519 for SSH September 2019 Authors' Addresses Ben Harris 2A Eachard Road CAMBRIDGE CB3 0HY UNITED KINGDOM Email: bjh21@bjh21.me.uk Loganaden Velvindron cyberstorm.mu 88, Avenue De Plevitz Roches Brunes Mauritius Email: logan@cyberstorm.mu Harris & Velvindron Expires March 12, 2020 [Page 7] ./draft-ietf-6man-segment-routing-header-26.txt0000644000764400076440000020010613553662522020604 0ustar iustyiusty Network Working Group C. Filsfils, Ed. Internet-Draft D. Dukes, Ed. Intended status: Standards Track Cisco Systems, Inc. Expires: April 24, 2020 S. Previdi Huawei J. Leddy Individual S. Matsushima Softbank D. Voyer Bell Canada October 22, 2019 IPv6 Segment Routing Header (SRH) draft-ietf-6man-segment-routing-header-26 Abstract Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header. This document describes the Segment Routing Header and how it is used by Segment Routing capable nodes. 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 https://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 24, 2020. Copyright Notice Copyright (c) 2019 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 Filsfils, et al. Expires April 24, 2020 [Page 1] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 (https://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 . . . . . . . . . . . . . . . . . . 3 2. Segment Routing Header . . . . . . . . . . . . . . . . . . . 4 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 9 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 14 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 14 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID . . . . . 14 4.3.2. FIB Entry Is A Local Interface . . . . . . . . . . . 16 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 17 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 17 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 17 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 17 5.2. SR Domain as A Single System with Delegation Among Components . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19 5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 19 5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 19 5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 20 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 20 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 21 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 22 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 22 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 22 6.3.3. Inter SR Domain Packet - Internal to External . . . . 23 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 23 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 23 6.6. Delegation of Function with HMAC Verification . . . . . . 23 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 24 Filsfils, et al. Expires April 24, 2020 [Page 2] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 25 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 25 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 26 7.5. Applicability of AH . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8.1. Segment Routing Header Flags Registry . . . . . . . . . . 27 8.2. Segment Routing Header TLVs Registry . . . . . . . . . . 27 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 28 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 28 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Segment Routing can be applied to the IPv6 data plane using a new type of Routing Header called the Segment Routing Header. This document describes the Segment Routing Header and how it is used by Segment Routing capable nodes. The Segment Routing Architecture [RFC8402] describes Segment Routing and its instantiation in two data planes; MPLS and IPv6. The encoding of IPv6 segments in the Segment Routing Header is defined in this document. This document uses the terms Segment Routing, SR Domain, SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy as defined in [RFC8402]. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Filsfils, et al. Expires April 24, 2020 [Page 3] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 2. Segment Routing Header Routing Headers are defined in [RFC8200]. The Segment Routing Header has a new Routing Type (suggested value 4) to be assigned by IANA. The Segment Routing Header (SRH) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Entry | Flags | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment List[0] (128 bits IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment List[n] (128 bits IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // // Optional Type Length Value objects (variable) // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Next Header: Defined in [RFC8200] Section 4.4 o Hdr Ext Len: Defined in [RFC8200] Section 4.4 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). o Segments Left: Defined in [RFC8200] Section 4.4 o Last Entry: contains the index (zero based), in the Segment List, of the last element of the Segment List. Filsfils, et al. Expires April 24, 2020 [Page 4] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 o Flags: 8 bits of flags. Section 8.1 creates an IANA registry for new flags to be defined. The following flags are defined: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |U U U U U U U U| +-+-+-+-+-+-+-+-+ U: Unused and for future use. MUST be 0 on transmission and ignored on receipt. o Tag: tag a packet as part of a class or group of packets, e.g., packets sharing the same set of properties. When tag is not used at source it MUST be set to zero on transmission. When tag is not used during SRH Processing it SHOULD be ignored. Tag is not used when processing the SID defined in Section 4.3.1. It may be used when processing other SIDs that are not defined in this document. The allocation and use of tag is outside the scope of this document. o Segment List[n]: 128 bit IPv6 addresses representing the nth segment in the Segment List. The Segment List is encoded starting from the last segment of the SR Policy. I.e., the first element of the segment list (Segment List [0]) contains the last segment of the SR Policy, the second element contains the penultimate segment of the SR Policy and so on. o Type Length Value (TLV) are described in Section 2.1. In the SRH, the Next Header, Hdr Ext Len, Routing Type, and Segments Left fields are defined in Section 4.4 of [RFC8200]. Based on the constraints in that section, Next Header, Header Ext Len, and Routing Type are not mutable while Segments Left is mutable. The mutability of the TLV value is defined by the most significant bit in the type, as specified in Section 2.1. Section 4.3 defines the mutability of the remaining fields in the SRH (Flags, Tag, Segment List) in the context of the SID defined in this document. New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List and indicate how the HMAC TLV (Section 2.1.2) verification works. Note, that in effect these fields are mutable. Filsfils, et al. Expires April 24, 2020 [Page 5] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 Consistent with the source routing model, the source of the SRH always knows how to set the segment list, Flags, Tag and TLVs of the SRH for use within the SR Domain. How it achieves this is outside the scope of this document, but may be based on topology, available SIDs and their mutability properties, the SRH mutability requirements of the destination, or any other information. 2.1. SRH TLVs This section defines TLVs of the Segment Routing Header. A TLV provides meta-data for segment processing. The only TLVs defined in this document are the HMAC (Section 2.1.2) and PAD (Section 2.1.1) TLVs. While processing the SID defined in Section 4.3.1, all TLVs are ignored unless local configuration indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support is optional for any implementation, however, an implementation adding or parsing TLVs MUST support PAD TLVs. Other documents may define additional TLVs and processing rules for them. TLVs are present when the Hdr Ext Len is greater than (Last Entry+1)*2. While processing TLVs at a segment endpoint, TLVs MUST be fully contained within the SRH as determined by the Hdr Ext Len. Detection of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Hdr Ext Len field of the SRH, and the packet being discarded. An implementation MAY limit the number and/or length of TLVs it processes based on local configuration. It MAY: o Limit the number of consecutive Pad1 (Section 2.1.1.1) options to 1. If padding of more than one byte is required, then PadN (Section 2.1.1.2) should be used. o Limit the length in PadN to 5. o Limit the maximum number of non-Pad TLVs to be processed. o Limit the maximum length of all TLVs to be processed. The implementation MAY stop processing additional TLVs in the SRH when these configured limits are exceeded. Filsfils, et al. Expires April 24, 2020 [Page 6] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- | Type | Length | Variable length data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- Type: An 8 bit codepoint from Segment Routing Header TLVs Registry TBD IANA Reference. Unrecognized Types MUST be ignored on receipt. Length: The length of the Variable length data in bytes. Variable length data: Length bytes of data that is specific to the Type. Type Length Value (TLV) entries contain OPTIONAL information that may be used by the node identified in the Destination Address (DA) of the packet. Each TLV has its own length, format and semantic. The codepoint allocated (by IANA) to each TLV Type defines both the format and the semantic of the information carried in the TLV. Multiple TLVs may be encoded in the same SRH. The highest-order bit of the TLV type (bit 0) specifies whether or not the TLV data of that type can change en route to the packet's final destination: 0: TLV data does not change en route 1: TLV data does change en route All TLVs specify their alignment requirements using an xn+y format. The xn+y format is defined as per [RFC8200]. The SR Source nodes use the xn+y alignment requirements of TLVs and Padding TLVs when constructing an SRH. The "Length" field of the TLV is used to skip the TLV while inspecting the SRH in case the node doesn't support or recognize the Type. The "Length" defines the TLV length in octets, not including the "Type" and "Length" fields. The following TLVs are defined in this document: Padding TLVs HMAC TLV Additional TLVs may be defined in the future. Filsfils, et al. Expires April 24, 2020 [Page 7] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 2.1.1. Padding TLVs There are two types of Padding TLVs, pad1 and padN, the following applies to both: Padding TLVs are used for meeting the alignment requirement of the subsequent TLVs. Padding TLVs are used to pad the SRH to a multiple of 8 octets. Padding TLVs are ignored by a node processing the SRH TLV. Multiple Padding TLVs MAY be used in one SRH 2.1.1.1. PAD1 Alignment requirement: none 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+ Type: to be assigned by IANA (Suggested value 0) A single Pad1 TLV MUST be used when a single byte of padding is required. A Pad1 TLV MUST NOT be used if more than one consecutive byte of padding is required. 2.1.1.2. PADN Alignment requirement: none 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 | Padding (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Padding (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: to be assigned by IANA (suggested value 4). Length: 0 to 5 Padding: Length octets of padding. Padding bits have no semantic. They MUST be set to 0 on transmission and ignored on receipt. Filsfils, et al. Expires April 24, 2020 [Page 8] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 The PadN TLV MUST be used when more than one byte of padding is required. 2.1.2. HMAC TLV Alignment requirement: 8n The keyed Hashed Message Authentication Code (HMAC) TLV is OPTIONAL and 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 | Length |D| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC Key ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // | HMAC (Variable) // | // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: to be assigned by IANA (suggested value 5). o Length: The length of the variable length data in bytes. o D: 1 bit. 1 indicates the Destination Address verification is disabled due to use of reduced segment list, Section 4.1.1. o RESERVED: 15 bits. MUST be 0 on transmission. o HMAC Key ID: A 4 octet opaque number which uniquely identifies the pre-shared key and algorithm used to generate the HMAC. o HMAC: Keyed HMAC, in multiples of 8 octets, at most 32 octets. The HMAC TLV is used to verify that the SRH applied to a packet was selected by an authorized party, and to ensure that the segment list is not modified after generation. This also allows for verification that the current segment (by virtue of being in the authorized segment list) is authorized for use. The SR Domain ensures the source node is permitted to use the source address in the packet via ingress filtering mechanisms as defined in BCP 84 [RFC3704], or other strategies as appropriate. Filsfils, et al. Expires April 24, 2020 [Page 9] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 2.1.2.1. HMAC Generation and Verification Local configuration determines when to check for an HMAC. This local configuration is outside the scope of this document. It may be based on the active segment at an SR Segment endpoint node, the result of an ACL that considers incoming interface, HMAC Key ID, or other packet fields. An implementation that supports the generation and verification of the HMAC supports the following default behavior, as defined in the remainder of this section. The HMAC verification begins by checking the current segment is equal to the destination address of the IPv6 header. The check is successful when either o HMAC D bit is 1 and Segments Left is greater than Last Entry. o HMAC Segments Left is less than or equal to Last Entry and destination address is equal to Segment List [Segments Left]. The HMAC field is the output of the HMAC computation as defined in [RFC2104], using: o key: the pre-shared key identified by HMAC Key ID o HMAC algorithm: identified by the HMAC Key ID o Text: a concatenation of the following fields from the IPv6 header and the SRH, as it would be received at the node verifying the HMAC: * IPv6 header: source address (16 octets) * SRH: Last Entry (1 octet) * SRH: Flags (1 octet) * SRH: HMAC 16 bits following Length * SRH: HMAC Key ID (4 octets) * SRH: all addresses in the Segment List (variable octets) The HMAC digest is truncated to 32 octets and placed in the HMAC field of the HMAC TLV. Filsfils, et al. Expires April 24, 2020 [Page 10] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 For HMAC algorithms producing digests less than 32 octets, the digest is placed in the lowest order octets of the HMAC field. Subsequent octets MUST be set to zero such that the HMAC length is a multiple of 8 octets. If HMAC verification is successful, processing proceeds as normal. If HMAC verification fails, an ICMP error message (parameter problem, error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate limited) and SHOULD be logged and the packet discarded. 2.1.2.2. HMAC Pre-Shared Key Algorithm The HMAC Key ID field allows for the simultaneous existence of several hash algorithms (SHA-256, SHA3-256 ... or future ones) as well as pre-shared keys. The HMAC Key ID field is opaque, i.e., it has neither syntax nor semantic except as an identifier of the right combination of pre- shared key and hash algorithm. At the HMAC TLV generating and verification nodes, the Key ID uniquely identifies the pre-shared key and HMAC algorithm. At the HMAC TLV generating node, the Text for the HMAC computation is set to the IPv6 header fields and SRH fields as they would appear at the verification node(s), not necessarily the same as the source node sending a packet with the HMAC TLV. Pre-shared key roll-over is supported by having two key IDs in use while the HMAC TLV generating node and verifying node converge to a new key. The HMAC TLV generating node may need to revoke an SRH for which it previously generated an HMAC. Revocation is achieved by allocating a new key and key ID, then rolling over the key ID associated with the SRH to be revoked. The HMAC TLV verifying node drops packets with the revoked SRH. An implementation supporting HMAC can support multiple hash functions. An implementation supporting HMAC MUST implement SHA-2 [FIPS180-4] in its SHA-256 variant. The selection of pre-shared key and algorithm, and their distribution is outside the scope of this document. Some options may include: o in the configuration of the HMAC generating or verifying nodes, either by static configuration or any SDN oriented approach Filsfils, et al. Expires April 24, 2020 [Page 11] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 o dynamically using a trusted key distribution protocol such as [RFC6407] While key management is outside the scope of this document, the recommendations of BCP 107 [RFC4107] should be considered when choosing the key management system. 3. SR Nodes There are different types of nodes that may be involved in segment routing networks: source SR nodes originate packets with a segment in the destination address of the IPv6 header, transit nodes that forward packets destined to a remote segment, and SR segment endpoint nodes that process a local segment in the destination address of an IPv6 header. 3.1. Source SR Node A Source SR Node is any node that originates an IPv6 packet with a segment (i.e. SRv6 SID) in the destination address of the IPv6 header. The packet leaving the source SR Node may or may not contain an SRH. This includes either: A host originating an IPv6 packet. An SR domain ingress router encapsulating a received packet in an outer IPv6 header, followed by an optional SRH. The mechanism through which a segment in the destination address of the IPv6 header and the Segment List in the SRH, is derived is outside the scope of this document. 3.2. Transit Node A transit node is any node forwarding an IPv6 packet where the destination address of that packet is not locally configured as a segment nor a local interface. A transit node is not required to be capable of processing a segment nor SRH. 3.3. SR Segment Endpoint Node A SR segment endpoint node is any node receiving an IPv6 packet where the destination address of that packet is locally configured as a segment or local interface. Filsfils, et al. Expires April 24, 2020 [Page 12] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 4. Packet Processing This section describes SRv6 packet processing at the SR source, Transit and SR segment endpoint nodes. 4.1. Source SR Node A Source node steers a packet into an SR Policy. If the SR Policy results in a segment list containing a single segment, and there is no need to add information to the SRH flag or to add TLV, the DA is set to the single segment list entry and the SRH MAY be omitted. When needed, the SRH is created as follows: Next Header and Hdr Ext Len fields are set as specified in [RFC8200]. Routing Type field is set as TBD (to be allocated by IANA, suggested value 4). The DA of the packet is set with the value of the first segment. The first element of the SRH Segment List is the ultimate segment. The second element is the penultimate segment, and so on. The Segments Left field is set to n-1 where n is the number of elements in the SR Policy. The Last Entry field is set to n-1 where n is the number of elements in the SR Policy. TLVs (including HMAC) may be set according to their specification. The packet is forwarded toward the packet's Destination Address (the first segment). 4.1.1. Reduced SRH When a source does not require the entire SID list to be preserved in the SRH, a reduced SRH may be used. A reduced SRH does not contain the first segment of the related SR Policy (the first segment is the one already in the DA of the IPv6 header), and the Last Entry field is set to n-2 where n is the number of elements in the SR Policy. Filsfils, et al. Expires April 24, 2020 [Page 13] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 4.2. Transit Node As specified in [RFC8200], the only node allowed to inspect the Routing Extension Header (and therefore the SRH), is the node corresponding to the DA of the packet. Any other transit node MUST NOT inspect the underneath routing header and MUST forward the packet toward the DA according to its IPv6 routing table. When a SID is in the destination address of an IPv6 header of a packet, it's routed through an IPv6 network as an IPv6 address. SIDs, or the prefix(es) covering SIDs, and their reachability may be distributed by means outside the scope of this document. For example, [RFC5308] or [RFC5340] may be used to advertise a prefix covering the SIDs on a node. 4.3. SR Segment Endpoint Node Without constraining the details of an implementation, the SR segment endpoint node creates Forwarding Information Base (FIB) entries for its local SIDs. When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packets destination address. This lookup can return any of the following: * A FIB entry that represents a locally instantiated SRv6 SID * A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID * A FIB entry that represents a non-local route * No Match 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID This document, and section, defines a single SRv6 SID. Future documents may define additional SRv6 SIDs. In which case, the entire content of this section will be defined in that document. If the FIB entry represents a locally instantiated SRv6 SID, process the next header chain of the IPv6 header as defined in section 4 of [RFC8200]. Section 4.3.1.1 describes how to process an SRH, Section 4.3.1.2 describes how to process an upper layer header or no next header. Processing this SID modifies the Segments Left and, if configured to process TLVs, it may modify the "variable length data" of TLV types that change en route. Therefore Segments Left is mutable and TLVs that change en route are mutable. The remainder of the SRH (Flags, Filsfils, et al. Expires April 24, 2020 [Page 14] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 Tag, Segment List, and TLVs that do not change en route) are immutable while processing this SID. 4.3.1.1. SRH Processing S01. When an SRH is processed { S02. If Segments Left is equal to zero { S03. Proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. S04. } S05. Else { S06. If local configuration requires TLV processing { S07. Perform TLV processing (see TLV Processing) S08. } S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 S10. If ((Last Entry > max_last_entry) or S11. (Segments Left is greater than (Last Entry+1)) { S12. Send an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Segments Left field, and discard the packet. S13. } S14. Else { S15. Decrement Segments Left by 1. S16. Copy Segment List[Segments Left] from the SRH to the destination address of the IPv6 header. S17. If the IPv6 Hop Limit is less than or equal to 1 { S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address and discard the packet. S19. } S20. Else { S21. Decrement the Hop Limit by 1 S22. Resubmit the packet to the IPv6 module for transmission to the new destination. S23. } S24. } S25. } S26. } 4.3.1.1.1. TLV Processing Local configuration determines how TLVs are to be processed when the Active Segment is a local SID defined in this document. The definition of local configuration is outside the scope of this document. Filsfils, et al. Expires April 24, 2020 [Page 15] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 For illustration purpose only, two example local configurations that may be associated with a SID are provided below. Example 1: For any packet received from interface I2 Skip TLV processing Example 2: For any packet received from interface I1 If first TLV is HMAC { Process the HMAC TLV } Else { Discard the packet } 4.3.1.2. Upper-layer Header or No Next Header When processing the Upper-layer header of a packet matching a FIB entry locally instantiated as an SRv6 SID defined in this document. IF (Upper-layer Header is IPv4 or IPv6) and local configuration permits { Perform IPv6 decapsulation Resubmit the decapsulated packet to the IPv4 or IPv6 module } ELSE { Send an ICMP parameter problem message to the Source Address and discard the packet. Error code (TBD by IANA) "SR Upper-layer Header Error", pointer set to the offset of the upper-layer header. } A unique error code allows an SR Source node to recognize an error in SID processing at an endpoint. 4.3.2. FIB Entry Is A Local Interface If the FIB entry represents a local interface, not locally instantiated as an SRv6 SID, the SRH is processed as follows: If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing Header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type. Filsfils, et al. Expires April 24, 2020 [Page 16] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 4.3.3. FIB Entry Is A Non-Local Route Processing is not changed by this document. 4.3.4. FIB Entry Is A No Match Processing is not changed by this document. 5. Intra SR Domain Deployment Model The use of the SIDs exclusively within the SR Domain and solely for packets of the SR Domain is an important deployment model. This enables the SR Domain to act as a single routing system. This section covers: o securing the SR Domain from external attempt to use its SIDs o SR Domain as a single system with delegation between components o handling packets of the SR Domain 5.1. Securing the SR Domain Nodes outside the SR Domain are not trusted: they cannot directly use the SIDs of the domain. This is enforced by two levels of access control lists: 1. Any packet entering the SR Domain and destined to a SID within the SR Domain is dropped. This may be realized with the following logic. Other methods with equivalent outcome are considered compliant: * allocate all the SID's from a block S/s * configure each external interface of each edge node of the domain with an inbound infrastructure access list (IACL) which drops any incoming packet with a destination address in S/s * Failure to implement this method of ingress filtering exposes the SR Domain to source routing attacks as described and referenced in [RFC5095] 2. The distributed protection in #1 is complemented with per node protection, dropping packets to SIDs from source addresses outside the SR Domain. This may be realized with the following Filsfils, et al. Expires April 24, 2020 [Page 17] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 logic. Other methods with equivalent outcome are considered compliant: * assign all interface addresses from prefix A/a * at node k, all SIDs local to k are assigned from prefix Sk/sk * configure each internal interface of each SR node k in the SR Domain with an inbound IACL which drops any incoming packet with a destination address in Sk/sk if the source address is not in A/a. 5.2. SR Domain as A Single System with Delegation Among Components All intra SR Domain packets are of the SR Domain. The IPv6 header is originated by a node of the SR Domain, and is destined to a node of the SR Domain. All inter domain packets are encapsulated for the part of the packet journey that is within the SR Domain. The outer IPv6 header is originated by a node of the SR Domain, and is destined to a node of the SR Domain. As a consequence, any packet within the SR Domain is of the SR Domain. The SR Domain is a system in which the operator may want to distribute or delegate different operations of the outer most header to different nodes within the system. An operator of an SR domain may choose to delegate SRH addition to a host node within the SR domain, and validation of the contents of any SRH to a more trusted router or switch attached to the host. Consider a top of rack switch (T) connected to host (H) via interface (I). H receives an SRH (SRH1) with a computed HMAC via some SDN method outside the scope of this document. H classifies traffic it sources and adds SRH1 to traffic requiring a specific SLA. T is configured with an IACL on I requiring verification of the SRH for any packet destined to the SID block of the SR Domain (S/s). T checks and verifies that SRH1 is valid, contains an HMAC TLV and verifies the HMAC. An operator of the SR Domain may choose to have all segments in the SR Domain verify the HMAC. This mechanism would verify that the SRH segment list is not modified while traversing the SR Domain. Filsfils, et al. Expires April 24, 2020 [Page 18] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 5.3. MTU Considerations An SR Domain ingress edge node encapsulates packets traversing the SR Domain, and needs to consider the MTU of the SR Domain. Within the SR Domain, well known mitigation techniques are RECOMMENDED, such as deploying a greater MTU value within the SR Domain than at the ingress edges. Encapsulation with an outer IPv6 header and SRH share the same MTU and fragmentation considerations as IPv6 tunnels described in [RFC2473]. Further investigation on the limitation of various tunneling methods (including IPv6 tunnels) are discussed in [I-D.ietf-intarea-tunnels] and SHOULD be considered by operators when considering MTU within the SR Domain. 5.4. ICMP Error Processing ICMP error packets generated within the SR Domain are sent to source nodes within the SR Domain. The invoking packet in the ICMP error message may contain an SRH. Since the destination address of a packet with an SRH changes as each segment is processed, it may not be the destination used by the socket or application that generated the invoking packet. For the source of an invoking packet to process the ICMP error message, the ultimate destination address of the IPv6 header may be required. The following logic is used to determine the destination address for use by protocol error handlers. o Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding the upper layer header. * If routing header is type TBD IANA (SRH) + The SID at Segment List[0] may be used as the destination address of the invoking packet. ICMP errors are then processed by upper layer transports as defined in [RFC4443]. For IP packets encapsulated in an outer IPv6 header, ICMP error handling is as defined in [RFC2473]. 5.5. Load Balancing and ECMP For any inter domain packet, the SR Source node MUST impose a flow label computed based on the inner packet. The computation of the Filsfils, et al. Expires April 24, 2020 [Page 19] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 flow label is as recommended in [RFC6438] for the sending Tunnel End Point. For any intra domain packet, the SR Source node SHOULD impose a flow label computed as described in [RFC6437] to assist ECMP load balancing at transit nodes incapable of computing a 5-tuple beyond the SRH. At any transit node within an SR domain, the flow label MUST be used as defined in [RFC6438] to calculate the ECMP hash toward the destination address. If flow label is not used, the transit node would likely hash all packets between a pair of SR Edge nodes to the same link. At an SR segment endpoint node, the flow label MUST be used as defined in [RFC6438] to calculate any ECMP hash used to forward the processed packet to the next segment. 5.6. Other Deployments Other deployment models and their implications on security, MTU, HMAC, ICMP error processing and interaction with other extension headers are outside the scope of this document. 6. Illustrations This section provides illustrations of SRv6 packet processing at SR source, transit and SR segment endpoint nodes. 6.1. Abstract Representation of an SRH For a node k, its IPv6 address is represented as Ak, its SRv6 SID is represented as Sk. IPv6 headers are represented as the tuple of (source, destination). For example, a packet with source address A1 and destination address A2 is represented as (A1,A2). The payload of the packet is omitted. An SR Policy is a list of segments. A list of segments is represented as where S1 is the first SID to visit, S2 is the second SID to visit and S3 is the last SID to visit. (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: o Source Address is SA, Destination Addresses is DA, and next-header is SRH. o SRH with SID list with SegmentsLeft = SL. Filsfils, et al. Expires April 24, 2020 [Page 20] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 o Note the difference between the <> and () symbols. represents a SID list where the leftmost segment is the first segment. Whereas, (S3, S2, S1; SL) represents the same SID list but encoded in the SRH Segment List format where the leftmost segment is the last segment. When referring to an SR policy in a high-level use-case, it is simpler to use the notation. When referring to an illustration of detailed behavior, the (S3, S2, S1; SL) notation is more convenient. At its SR Policy headend, the Segment List results in SRH (S3,S2,S1; SL=2) represented fully as: Segments Left=2 Last Entry=2 Flags=0 Tag=0 Segment List[0]=S3 Segment List[1]=S2 Segment List[2]=S1 6.2. Example Topology The following topology is used in examples below: + * * * * * * * * * * * * * * * * * * * * + * [8] [9] * | | * | | * [1]----[3]--------[5]----------------[6]---------[4]---[2] * | | * | | * | | * +--------[7]-------+ * * + * * * * * * * SR Domain * * * * * * * + Figure 3 o 3 and 4 are SR Domain edge routers o 5, 6, and 7 are all SR Domain routers o 8 and 9 are hosts within the SR Domain o 1 and 2 are hosts outside the SR Domain Filsfils, et al. Expires April 24, 2020 [Page 21] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 o The SR domain implements ingress filtering as per Section 5.1 and no external packet can enter the domain with a destination address equal to a segment of the domain. 6.3. Source SR Node 6.3.1. Intra SR Domain Packet When host 8 sends a packet to host 9 via an SR Policy the packet is P1: (A8,S7)(A9,S7; SL=1) 6.3.1.1. Reduced Variant When host 8 sends a packet to host 9 via an SR Policy and it wants to use a reduced SRH, the packet is P2: (A8,S7)(A9; SL=1) 6.3.2. Inter SR Domain Packet - Transit When host 1 sends a packet to host 2, the packet is P3: (A1,A2) The SR Domain ingress router 3 receives P3 and steers it to SR Domain egress router 4 via an SR Policy . Router 3 encapsulates the received packet P3 in an outer header with an SRH. The packet is P4: (A3, S7)(S4, S7; SL=1)(A1, A2) If the SR Policy contains only one segment (the egress router 4), the ingress Router 3 encapsulates P3 into an outer header (A3, S4) without SRH. The packet is P5: (A3, S4)(A1, A2) 6.3.2.1. Reduced Variant The SR Domain ingress router 3 receives P3 and steers it to SR Domain egress router 4 via an SR Policy . If router 3 wants to use a reduced SRH, Router 3 encapsulates the received packet P3 in an outer header with a reduced SRH. The packet is P6: (A3, S7)(S4; SL=1)(A1, A2) Filsfils, et al. Expires April 24, 2020 [Page 22] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 6.3.3. Inter SR Domain Packet - Internal to External When host 8 sends a packet to host 1, the packet is encapsulated for the portion of its journey within the SR Domain. From 8 to 3 the packet is P7: (A8,S3)(A8,A1) In the opposite direction, the packet generated from 1 to 8 is P8: (A1,A8) At node 3 P8 is encapsulated for the portion of its journey within the SR domain, with the outer header destined to segment S8. Resulting in P9: (A3,S8)(A1,A8) At node 8 the outer IPv6 header is removed by S8 processing, then processed again when received by A8. 6.4. Transit Node Nodes 5 acts as transit nodes for packet P1, and sends packet P1: (A8,S7)(A9,S7;SL=1) on the interface toward node 7. 6.5. SR Segment Endpoint Node Node 7 receives packet P1 and, using the logic in Section 4.3.1, sends packet P7: (A8,A9)(A9,S7; SL=0) on the interface toward router 6. 6.6. Delegation of Function with HMAC Verification This section describes how a function may be delegated within the SR Domain. In the following sections consider a host 8 connected to a top of rack 5. Filsfils, et al. Expires April 24, 2020 [Page 23] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 6.6.1. SID List Verification An operator may prefer to apply the SRH at source 8, while 5 verifies the SID list is valid. For illustration purpose, an SDN controller provides 8 an SRH terminating at node 9, with segment list , and HMAC TLV computed for the SRH. The HMAC key ID and key associated with the HMAC TLV is shared with 5. Node 8 does not know the key. Node 5 is configured with an IACL applied to the interface connected to 8, requiring HMAC verification for any packet destined to S/s. Node 8 originates packets with the received SRH including HMAC TLV. P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) Node 5 receives and verifies the HMAC for the SRH, then forwards the packet to the next segment P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) Node 6 receives P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC) Node 9 receives P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC) This use of an HMAC is particularly valuable within an enterprise based SR Domain [SRN]. 7. Security Considerations This section reviews security considerations related to the SRH, given the SRH processing and deployment models discussed in this document. As described in Section 5, it is necessary to filter packets ingress to the SR Domain, destined to SIDs within the SR Domain (i.e., bearing a SID in the destination address). This ingress filtering is via an IACL at SR Domain ingress border nodes. Additional protection is applied via an IACL at each SR Segment Endpoint node, filtering packets not from within the SR Domain, destined to SIDs in the SR Domain. ACLs are easily supported for small numbers of prefixes, making summarization important, and when the prefixes requiring filtering is kept to a seldom changing set. Filsfils, et al. Expires April 24, 2020 [Page 24] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 Additionally, ingress filtering of IPv6 source addresses as recommended in BCP38 [RFC2827] SHOULD be used. 7.1. Source Routing Attacks An SR domain implements distributed and per node protection as described in section 5.1. Additionally, domains deny traffic with spoofed addresses by implementing the recommendations in BCP 84 [RFC3704]. Full implementation of the recommended protection blocks the attacks documented in [RFC5095] from outside the SR domain, including bypassing filtering devices, reaching otherwise unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast. Failure to implement distributed and per node protection allows attackers to bypass filtering devices and exposes the SR Domain to these attacks. Compromised nodes within the SR Domain may mount the attacks listed above along with other known attacks on IP networks (e.g. DOS/DDOS, topology discovery, man-in-the-middle, traffic interception/ siphoning). 7.2. Service Theft Service theft is defined as the use of a service offered by the SR Domain by a node not authorized to use the service. Service theft is not a concern within the SR Domain as all SR Source nodes and SR segment endpoint nodes within the domain are able to utilize the services of the Domain. If a node outside the SR Domain learns of segments or a topological service within the SR domain, IACL filtering denies access to those segments. 7.3. Topology Disclosure The SRH is unencrypted and may contain SIDs of some intermediate SR- nodes in the path towards the destination within the SR Domain. If packets can be snooped within the SR Domain, the SRH may reveal topology, traffic flows, and service usage. This is applicable within an SR Domain, but the disclosure is less relevant as an attacker has other means of learning topology, flows, and service usage. Filsfils, et al. Expires April 24, 2020 [Page 25] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 7.4. ICMP Generation The generation of ICMPv6 error messages may be used to attempt denial-of-service attacks by sending an error-causing destination address or SRH in back-to-back packets. An implementation that correctly follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-limiting mechanism. 7.5. Applicability of AH The SR Domain is a trusted domain, as defined in [RFC8402] Section 2 and Section 8.2. The SR Source is trusted to add an SRH (optionally verified as having been generated by a trusted source via the HMAC TLV in this document), and segments advertised within the domain are trusted to be accurate and advertised by trusted sources via a secure control plane. As such the SR Domain does not rely on the Authentication Header (AH) as defined in [RFC4302] to secure the SRH. The use of SRH with AH by an SR source node, and processing at a SR segment endpoint node is not defined in this document. Future documents may define use of SRH with AH and its processing. 8. IANA Considerations This document makes the following registrations in the Internet Protocol Version 6 (IPv6) Parameters "Routing Type" registry maintained by IANA: Suggested Description Reference Value ---------------------------------------------------------- 4 Segment Routing Header (SRH) This document This document makes the following registrations in "Type 4 - Parameter Problem" message of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry maintained by IANA: CODE NAME/DESCRIPTION ---------------------------------------------------------- TBD IANA SR Upper-layer Header Error This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the SRH, in accordance with BCP 26, [RFC8126]. The following terms are used here with the meanings defined in BCP 26: "namespace", "assigned value", "registration". Filsfils, et al. Expires April 24, 2020 [Page 26] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 The following policies are used here with the meanings defined in BCP 26 [RFC8126]: "IETF Review". 8.1. Segment Routing Header Flags Registry This document requests the creation of a new IANA managed registry to identify SRH Flags Bits. The registration procedure is "IETF Review". Suggested registry name is "Segment Routing Header Flags". Flags is 8 bits. 8.2. Segment Routing Header TLVs Registry This document requests the creation of a new IANA managed registry to identify SRH TLVs. The registration procedure is "IETF Review". Suggested registry name is "Segment Routing Header TLVs". A TLV is identified through an unsigned 8 bit codepoint value, with assigned values 0-127 for TLVs that do not change en route, and 128-255 for TLVs that may change en route. The following codepoints are defined in this document: Assigned Description Reference Value ----------------------------------------------------- 0 Pad1 TLV This document 1 Reserved This document 2 Reserved This document 3 Reserved This document 4 PadN TLV This document 5 HMAC TLV This document 6 Reserved This document 124-126 Experimentation and Test This document 127 Reserved This document 252-254 Experimentation and Test This document 255 Reserved This document Values 1,2,3,6 were defined in draft versions of this specification and are Reserved for backwards compatibility with early implementations and should not be reassigned. Values 127 and 255 are Reserved to allow for expansion of the Type field in future specifications if needed. 9. Implementation Status This section is to be removed prior to publishing as an RFC. See [I-D.matsushima-spring-srv6-deployment-status] for updated deployment and interoperability reports. Filsfils, et al. Expires April 24, 2020 [Page 27] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 9.1. Linux Name: Linux Kernel v4.14 Status: Production Implementation: adds SRH, performs END processing, supports HMAC TLV Details: https://irtf.org/anrw/2017/anrw17-final3.pdf and [I-D.filsfils-spring-srv6-interop] 9.2. Cisco Systems Name: IOS XR and IOS XE Status: Production (IOS XR), Pre-production (IOS XE) Implementation: adds SRH, performs END processing, no TLV processing Details: [I-D.filsfils-spring-srv6-interop] 9.3. FD.io Name: VPP/Segment Routing for IPv6 Status: Production Implementation: adds SRH, performs END processing, no TLV processing Details: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6 and [I-D.filsfils-spring-srv6-interop] 9.4. Barefoot Name: Barefoot Networks Tofino NPU Status: Prototype Implementation: performs END processing, no TLV processing Details: [I-D.filsfils-spring-srv6-interop] 9.5. Juniper Name: Juniper Networks Trio and vTrio NPU's Status: Prototype & Experimental Filsfils, et al. Expires April 24, 2020 [Page 28] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 Implementation: SRH insertion mode, Process SID where SID is an interface address, no TLV processing 9.6. Huawei Name: Huawei Systems VRP Platform Status: Production Implementation: adds SRH, performs END processing, no TLV processing 10. Contributors Kamran Raza, Zafar Ali, Brian Field, Daniel Bernier, Ida Leung, Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James Connolly, Aloys Augustin contributed to the content of this document. 11. Acknowledgements The authors would like to thank Ole Troan, Bob Hinden, Ron Bonica, Fred Baker, Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, David Lebrun, Benjamin Kaduk, Frank Xialiang, Mirja Kuhlewind, Roman Danyliw, Joe Touch, and Magnus Westerlund for their comments to this document. 12. References 12.1. Normative References [FIPS180-4] National Institute of Standards and Technology, "FIPS 180-4 Secure Hash Standard (SHS)", March 2012, . [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, . Filsfils, et al. Expires April 24, 2020 [Page 29] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [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, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, . [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . Filsfils, et al. Expires April 24, 2020 [Page 30] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 12.2. Informative References [I-D.filsfils-spring-srv6-interop] Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., Salsano, S., Bonaventure, O., Horn, J., and J. Liste, "SRv6 interoperability report", draft-filsfils-spring- srv6-interop-02 (work in progress), March 2019. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-10 (work in progress), September 2019. [I-D.matsushima-spring-srv6-deployment-status] Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 Implementation and Deployment Status", draft-matsushima- spring-srv6-deployment-status-02 (work in progress), October 2019. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [SRN] Lebrun, D., Jadin, M., Clad, F., Filsfils, C., and O. Bonaventure, "Software Resolved Networks: Rethinking Enterprise Networks with IPv6 Segment Routing", 2018, . Filsfils, et al. Expires April 24, 2020 [Page 31] Internet-Draft IPv6 Segment Routing Header (SRH) October 2019 Authors' Addresses Clarence Filsfils (editor) Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Darren Dukes (editor) Cisco Systems, Inc. Ottawa CA Email: ddukes@cisco.com Stefano Previdi Huawei Italy Email: stefano@previdi.net John Leddy Individual US Email: john@leddy.net Satoru Matsushima Softbank Email: satoru.matsushima@g.softbank.co.jp Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca Filsfils, et al. Expires April 24, 2020 [Page 32] ./draft-ietf-lisp-introduction-13.txt0000644000764400076440000020266012507232506017052 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-acme-caa-10.txt0000644000764400076440000005635213503006713015011 0ustar iustyiusty ACME Working Group H. Landau Internet-Draft June 20, 2019 Intended status: Standards Track Expires: December 22, 2019 CAA Record Extensions for Account URI and ACME Method Binding draft-ietf-acme-caa-10 Abstract The Certification Authority Authorization (CAA) DNS record allows a domain to communicate issuance policy to Certification Authorities (CAs), but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be 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 https://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 22, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Landau Expires December 22, 2019 [Page 1] Internet-Draft ACME-CAA June 2019 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. Extensions to the CAA Record: accounturi Parameter . . . . . 3 3.1. Use with ACME . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Use without ACME . . . . . . . . . . . . . . . . . . . . 3 4. Extensions to the CAA Record: validationmethods Parameter . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5.1. Limited to CAs Processing CAA Records . . . . . . . . . . 5 5.2. Restrictions Ineffective without CA Recognition . . . . . 5 5.3. Mandatory Consistency in CA Recognition . . . . . . . . . 5 5.4. URI Ambiguity . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Authorization Freshness . . . . . . . . . . . . . . . . . 7 5.6. Use with and without DNSSEC . . . . . . . . . . . . . . . 7 5.7. Restrictions Supercedable by DNS Delegation . . . . . . . 8 5.8. Misconfiguration Hazards . . . . . . . . . . . . . . . . 9 5.9. Revelation of Account URIs . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This specification defines two parameters for the "issue" and "issuewild" properties of the Certification Authority Authorization (CAA) DNS resource record [I-D.ietf-lamps-rfc6844bis]. The first, "accounturi", allows authorization conferred by a CAA policy to be restricted to specific accounts of a CA, which are identified by URIs. The second, "validationmethods", allows the set of validation methods supported by a CA to validate domain control to be limited to a subset of the full set of methods which it supports. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Landau Expires December 22, 2019 [Page 2] Internet-Draft ACME-CAA June 2019 3. Extensions to the CAA Record: accounturi Parameter A CAA parameter "accounturi" is defined for the "issue" and "issuewild" properties defined by [I-D.ietf-lamps-rfc6844bis]. The value of this parameter, if specified, MUST be a URI [RFC3986] identifying a specific CA account. "CA account" means an object, maintained by a specific CA and which may request the issuance of certificates, which represents a specific entity or group of related entities. The presence of this parameter constrains the property to which it is attached. Where a CAA property has an "accounturi" parameter, a CA MUST only consider that property to authorize issuance in the context of a given certificate issuance request if the CA recognises the URI specified in the value portion of that parameter as identifying the account making that request. A property without an "accounturi" parameter matches any account. A property with an invalid or unrecognised "accounturi" parameter is unsatisfiable. A property with multiple "accounturi" parameters is unsatisfiable. The presence of an "accounturi" parameter does not replace or supercede the need to validate the domain name specified in an "issue" or "issuewild" record in the manner described in the CAA specification. CAs MUST still perform such validation. For example, a CAA "issue" property which specifies a domain name belonging to CA A and an "accounturi" parameter identifying an account at CA B is unsatisfiable. 3.1. Use with ACME An ACME [RFC8555] account object MAY be identified by setting the "accounturi" parameter to the URI of the ACME account object. Implementations of this specification which also implement ACME MUST recognise such URIs. 3.2. Use without ACME The "accounturi" specification provides a general mechanism to identify entities which may request certificate issuance via URIs. The use of specific kinds of URI may be specified in future RFCs, and CAs not implementing ACME MAY assign and recognise their own URIs arbitrarily. Landau Expires December 22, 2019 [Page 3] Internet-Draft ACME-CAA June 2019 4. Extensions to the CAA Record: validationmethods Parameter A CAA parameter "validationmethods" is also defined for the "issue" and "issuewild" properties. The value of this parameter, if specified, MUST be a comma-separated string of zero or more validation method labels. A validation method label identifies a validation method. A validation method is a particular way in which a CA can validate control over a domain. The presence of this parameter constrains the property to which it is attached. A CA MUST only consider a property with the "validationmethods" parameter to authorize issuance where the validation method being used is identified by one of the validation method labels listed in the comma-separated list. Each validation method label MUST be either the label of a method defined in the ACME Validation Methods IANA registry, or a CA- specific non-ACME validation method label as defined below. Where a CA supports both the "validationmethods" parameter and one or more non-ACME validation methods, it MUST assign labels to those methods. If appropriate non-ACME labels are not present in the ACME Validation Methods IANA registry, the CA MUST use labels beginning with the string "ca-", which are defined to have CA-specific meaning. The value of the "validationmethods" parameter MUST comply with the following ABNF [RFC5234]: value = [*(label ",") label] label = 1*(ALPHA / DIGIT / "-") 5. Security Considerations This specification describes an extension to the CAA record specification increasing the granularity at which CAA policy can be expressed. This allows the set of entities capable of successfully requesting issuance of certificates for a given domain to be restricted beyond that which would otherwise be possible, while still allowing issuance for specific accounts of a CA. This improves the security of issuance for domains which choose to employ it, when combined with a CA which implements this specification. Landau Expires December 22, 2019 [Page 4] Internet-Draft ACME-CAA June 2019 5.1. Limited to CAs Processing CAA Records All of the security considerations of the CAA specification are inherited by this document. This specification merely enables a domain with an existing relationship with a CA to further constrain that CA in its issuance practices, where that CA implements this specification. In particular, it provides no additional security above that provided by use of the unextended CAA specification alone as concerns matters relating to any other CA. The capacity of any other CA to issue certificates for the given domain is completely unchanged. As such, a domain which via CAA records authorizes only CAs adopting this specification, and which constrains its policy by means of this specification, remains vulnerable to unauthorized issuance by CAs which do not honour CAA records, or which honour them only on an advisory basis. Where a domain uses DNSSEC, it also remains vulnerable to CAs which honour CAA records but which do not validate CAA records by means of a trusted DNSSEC-validating resolver. 5.2. Restrictions Ineffective without CA Recognition Because the parameters of "issue" or "issuewild" CAA properties constitute a CA-specific namespace, the CA identified by an "issue" or "issuewild" property decides what parameters to recognise and their semantics. Accordingly, the CAA parameters defined in this specification rely on their being recognised by the CA named by an "issue" or "issuewild" CAA property, and are not an effective means of control over issuance unless a CA's support for the parameters is established beforehand. CAs which implement this specification SHOULD make available documentation indicating as such, including explicit statements as to which parameters are supported. Domains configuring CAA records for a CA MUST NOT assume that the restrictions implied by the "accounturi" and "validationmethods" parameters are effective in the absence of explicit indication as such from that CA. CAs SHOULD also document whether they implement DNSSEC validation for DNS lookups done for validation purposes, as this affects the security of the "accounturi" and "validationmethods" parameters. 5.3. Mandatory Consistency in CA Recognition A CA MUST ensure that its support for the "accounturi" and "validationmethods" parameters is fully consistent for a given domain name which a CA recognises as identifying itself in a CAA "issue" or "issuewild" property. If a CA has multiple issuance systems (for Landau Expires December 22, 2019 [Page 5] Internet-Draft ACME-CAA June 2019 example, an ACME-based issuance system and a non-ACME based issuance system, or two different issuance systems resulting from a corporate merger), it MUST ensure that all issuance systems recognise the same parameters. A CA which is unable to do this MAY still implement the parameters by splitting the CA into two domain names for the purposes of CAA processing. For example, a CA "example.com" with an ACME-based issuance system and a non-ACME-based issuance system could recognise only "acme.example.com" for the former and "example.com" for the latter, and then implement support for the "accounturi" and "validationmethods" parameters for "acme.example.com" only. A CA which is unable to ensure consistent processing of the "accounturi" or "validationmethods" parameters for a given CA domain name as specifiable in CAA "issue" or "issuewild" properties MUST NOT implement support for these parameters. Failure to do so would result in an implementation of these parameters which does not provide effective security. 5.4. URI Ambiguity Suppose that CA A recognises "a.example.com" as identifying itself, CA B is a subsidiary of CA A which recognises both "a.example.com" and "b.example.com" as identifying itself. Suppose that both CA A and CA B issue account URIs of the form "urn:example:account-id:1234" If the CA domain name in a CAA record is specified as "a.example.com" then this could be construed as identifying account number 1234 at CA A or at CA B. These may be different accounts, creating ambiguity. Thus, CAs MUST ensure that the URIs they recognise as pertaining to a specific account of that CA are unique within the scope of all domain names which they recognise as identifying that CA for the purpose of CAA record validation. CAs SHOULD satisfy this requirement by using URIs which include an authority (see Section 3.2 of [RFC3986]): "https://a.example.com/account/1234" Landau Expires December 22, 2019 [Page 6] Internet-Draft ACME-CAA June 2019 5.5. Authorization Freshness The CAA specification governs the act of issuance by a CA. In some cases, a CA may establish authorization for an account to request certificate issuance for a specific domain separately to the act of issuance itself. Such authorization may occur substantially prior to a certificate issuance request. The CAA policy expressed by a domain may have changed in the meantime, creating the risk that a CA will issue certificates in a manner inconsistent with the presently published CAA policy. CAs SHOULD adopt practices to reduce the risk of such circumstances. Possible countermeasures include issuing authorizations with very limited validity periods, such as an hour, or revalidating the CAA policy for a domain at certificate issuance time. 5.6. Use with and without DNSSEC The "domain validation" model of validation commonly used for certificate issuance cannot ordinarily protect against adversaries who can conduct global man-in-the-middle attacks against a particular domain. A global man-in-the-middle attack is an attack which can intercept traffic to or from a given domain, regardless of the origin or destination of that traffic. Such an adversary can intercept all validation traffic initiated by a CA and thus appear to have control of the given domain. Where a domain is signed using DNSSEC, the authenticity of its DNS data can be assured, providing that a given CA makes all DNS resolutions via a trusted DNSSEC-validating resolver. A domain can use this property to protect itself from the threat posed by an adversary capable of performing a global man-in-the-middle attack against that domain. In order to facilitate this, a CA validation process must either rely solely on information obtained via DNSSEC, or meaningfully bind the other parts of the validation transaction using material obtained via DNSSEC. The CAA parameters described in this specification can be used to ensure that only validation methods meeting these criteria are used. In particular, a domain secured via DNSSEC SHOULD either: 1. Use the "accounturi" parameter to ensure that only accounts which it controls are authorized to obtain certificates, or Landau Expires December 22, 2019 [Page 7] Internet-Draft ACME-CAA June 2019 2. Exclusively use validation methods which rely solely on information obtained via DNSSEC, and use the "validationmethods" parameter to ensure that only such methods are used. A CA supporting the "accounturi" or "validationmethods" parameters MUST perform CAA validation using a trusted, DNSSEC-validating resolver. "Trusted" in this context means that the CA both trusts the resolver itself and ensures that the communications path between the resolver and the system performing CAA validation are secure. It is RECOMMENDED that a CA ensure this by using a DNSSEC-validating resolver running on the same machine as the system performing CAA validation. Use of the "accounturi" or "validationmethods" parameters does not confer additional security against an attacker capable of performing a man-in-the-middle attack against all validation attempts made by a given CA which is authorized by CAA where: 1. A domain does not secure its nameservers using DNSSEC, or 2. That CA does not perform CAA validation using a trusted DNSSEC- validating resolver. Moreover, use of the "accounturi" or "validationmethods" parameters does not mitigate against man-in-the-middle attacks against CAs which do not validate CAA records, or which do not do so using a trusted DNSSEC-validating resolver, regardless of whether those CAs are authorized by CAA or not; see Section 5.1. In these cases, the "accounturi" and "validationmethods" parameters still provide an effective means of administrative control over issuance, except where control over DNS is subdelegated (see below). 5.7. Restrictions Supercedable by DNS Delegation CAA records are located during validation by walking up the DNS hierarchy until one or more records are found. CAA records are therefore not an effective way of restricting or controlling issuance for subdomains of a domain, where control over those subdomains is delegated to another party (such as via DNS delegation or by providing limited access to manage subdomain DNS records). Landau Expires December 22, 2019 [Page 8] Internet-Draft ACME-CAA June 2019 5.8. Misconfiguration Hazards Because the "accounturi" and "validationmethods" parameters express restrictive security policies, misconfiguration of said parameters may result in legitimate issuance requests being refused. 5.9. Revelation of Account URIs Because CAA records are publically accessible, use of the "accounturi" parameter enables third parties to observe the authorized account URIs for a domain. This may allow third parties to identify a correlation between domains if those domains use the same account URIs. CAs are encouraged to select and process account URIs under the assumption that untrusted third parties may learn of them. 6. IANA Considerations None. As per the CAA specification, the parameter namespace for the CAA "issue" and "issuewild" properties has CA-defined semantics and the identifiers within that namespace may be freely and arbitrarily assigned by a CA. This document merely specifies recommended semantics for parameters of the names "accounturi" and "validationmethods", which CAs may choose to adopt. 7. Normative References [I-D.ietf-lamps-rfc6844bis] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", draft-ietf-lamps-rfc6844bis-07 (work in progress), May 2019. [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, . Landau Expires December 22, 2019 [Page 9] Internet-Draft ACME-CAA June 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . Appendix A. Examples The following shows an example DNS zone file fragment which nominates two account URIs as authorized to issue certificates for the domain "example.com". Issuance is restricted to the CA "example.net". example.com. IN CAA 0 issue "example.net; \ accounturi=https://example.net/account/1234" example.com. IN CAA 0 issue "example.net; \ accounturi=https://example.net/account/2345" The following shows a zone file fragment which restricts the ACME methods which can be used; only ACME methods "dns-01" and "xyz-01" can be used. example.com. IN CAA 0 issue "example.net; \ validationmethods=dns-01,xyz-01" The following shows an equivalent way of expressing the same restriction: example.com. IN CAA 0 issue "example.net; validationmethods=dns-01" example.com. IN CAA 0 issue "example.net; validationmethods=xyz-01" The following shows a zone file fragment in which one account can be used to issue with the "dns-01" method and one account can be used to issue with the "http-01" method. example.com. IN CAA 0 issue "example.net; \ accounturi=https://example.net/account/1234; \ validationmethods=dns-01" example.com. IN CAA 0 issue "example.net; \ accounturi=https://example.net/account/2345; \ validationmethods=http-01" The following shows a zone file fragment in which only ACME method "dns-01" or a CA-specific method "ca-foo" can be used. Landau Expires December 22, 2019 [Page 10] Internet-Draft ACME-CAA June 2019 example.com. IN CAA 0 issue "example.net; \ validationmethods=dns-01,ca-foo" Author's Address Hugo Landau Email: hlandau@devever.net Landau Expires December 22, 2019 [Page 11] ./draft-ietf-lisp-rfc8113bis-03.txt0000644000764400076440000002404513422536530016115 0ustar iustyiusty LISP M. Boucadair Internet-Draft C. Jacquenet Obsoletes: 8113 (if approved) Orange Intended status: Standards Track January 25, 2019 Expires: July 29, 2019 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations draft-ietf-lisp-rfc8113bis-03 Abstract This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. This document obsoletes RFC 8113. 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 https://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 29, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Boucadair & Jacquenet Expires July 29, 2019 [Page 1] Internet-Draft LISP Packet Type Allocations January 2019 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 . . . . . . . . . . . . . . . . . . . . 2 3. LISP Shared Extension Message Type . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5.1. LISP Packet Types . . . . . . . . . . . . . . . . . . . . 3 5.2. Sub-Types . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Changes from RFC 8113 . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Locator/ID Separation Protocol (LISP) base specification, [I-D.ietf-lisp-rfc6833bis], defines a set of primitives that are identified with a packet type code. Several extensions have been proposed to add more LISP functionalities. It is expected that additional LISP extensions will be proposed in the future. The "LISP Packet Types" IANA registry (see Section 5) is used to ease the tracking of LISP message types. Because of the limited type space [I-D.ietf-lisp-rfc6833bis] and the need to conduct experiments to assess new LISP extensions, this document specifies a shared LISP extension message type and describes a procedure for registering LISP shared extension sub-types (see Section 3). Concretely, one single LISP message type code is dedicated to future LISP extensions; sub-types are used to uniquely identify a given LISP extension making use of the shared LISP extension message type. These identifiers are selected by the author(s) of the corresponding LISP specification that introduces a new LISP extension message type. 2. Requirements Language 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. Boucadair & Jacquenet Expires July 29, 2019 [Page 2] Internet-Draft LISP Packet Type Allocations January 2019 3. LISP Shared Extension Message Type Figure 1 depicts the common format of the LISP shared extension message. The type field MUST be set to 15 (see Section 5). 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=15| Sub-type | extension-specific | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // extension-specific // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LISP Shared Extension Message Type The "Sub-type" field conveys a unique identifier that MUST be registered with IANA (see Section 5.2). The exact structure of the 'extension-specific' portion of the message is specified in the corresponding specification document. 4. Security Considerations This document does not introduce any additional security issues other than those discussed in [I-D.ietf-lisp-rfc6833bis]. 5. IANA Considerations 5.1. LISP Packet Types IANA has created a protocol registry for LISP Packet Types, numbered 0-15. Values can be assigned via Standards Action [RFC8126]. Documents that request for a new LISP packet type may indicate a preferred value in the corresponding IANA sections. IANA is requested to replace the reference to RFC8113 with the RFC number to be assigned to this document. Also, IANA is requested to update the table as follows: Boucadair & Jacquenet Expires July 29, 2019 [Page 3] Internet-Draft LISP Packet Type Allocations January 2019 OLD: Message Code Reference ================================= ==== =============== LISP Shared Extension Message 15 [RFC8113] NEW: Message Code Reference ================================= ==== =============== LISP Shared Extension Message 15 [ThisDocument] 5.2. Sub-Types IANA has created the "LISP Shared Extension Message Type Sub-types" registry. IANA is requested to update that registry by replacing the reference to RFC8113 with the RFC number to be assigned to this document. The values in the range 0-1023 are assigned via Standards Action. This range is provisioned to anticipate, in particular, the exhaustion of the LISP Packet types. The values in the range 1024-4095 are assigned on a First Come, First Served (FCFS) basis. The registration procedure should provide IANA with the desired codepoint and a point of contact; providing a short description (together with an acronym, if relevant) of the foreseen usage of the extension message is also encouraged. 6. Changes from RFC 8113 The following changes were made from RFC 8113: o Change the status from Experimental to Standard track. o Indicate explicitly that the shared extension is used for two purposes: extend the type space and conduct experiments to assess new LISP extensions. o Delete pointers to some examples illustrating how the shared extension message is used to extend the LISP protocol. o Request IANA to update the "IANA LISP Packet Types" and "LISP Shared Extension Message Type Sub-types" registries to point to this document instead of RFC8113. Boucadair & Jacquenet Expires July 29, 2019 [Page 4] Internet-Draft LISP Packet Type Allocations January 2019 7. Acknowledgments This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 009-X. Many thanks to Luigi Iannone, Dino Farinacci, and Alvaro Retana for the review. Thanks to Geoff Huston, Brian Carpenter, Barry Leiba, and Suresh Krishnan for the review. 8. Normative References [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-23 (work in progress), December 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France EMail: mohamed.boucadair@orange.com Boucadair & Jacquenet Expires July 29, 2019 [Page 5] Internet-Draft LISP Packet Type Allocations January 2019 Christian Jacquenet Orange Rennes 35000 France EMail: christian.jacquenet@orange.com Boucadair & Jacquenet Expires July 29, 2019 [Page 6] ./draft-ietf-acme-ip-08.txt0000644000764400076440000002524113544707350014707 0ustar iustyiusty ACME Working Group R. Shoemaker Internet-Draft ISRG Intended status: Standards Track October 01, 2019 Expires: April 3, 2020 ACME IP Identifier Validation Extension draft-ietf-acme-ip-08 Abstract This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. 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 https://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 3, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Shoemaker Expires April 3, 2020 [Page 1] Internet-Draft ACME-IP October 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. IP Identifier . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Identifier Validation Challenges . . . . . . . . . . . . . . 3 5. HTTP Challenge . . . . . . . . . . . . . . . . . . . . . . . 3 6. TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 3 7. DNS Challenge . . . . . . . . . . . . . . . . . . . . . . . . 3 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 8.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 3 8.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 4 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4 9.1. CA Policy Considerations . . . . . . . . . . . . . . . . 4 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 11. Normative References . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Automatic Certificate Management Environment (ACME) [RFC8555] only defines challenges for validating control of DNS host name identifiers, which limits its use to being used for issuing certificates for DNS identifiers. In order to allow validation of IPv4 and IPv6 identifiers for inclusion in X.509 certificates, this document specifies how challenges defined in the original ACME specification and the TLS-ALPN extension specification [I-D.ietf-acme-tls-alpn] can be used to validate IP identifiers. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. IP Identifier [RFC8555] only defines the identifier type "dns", which is used to refer to fully qualified domain names. If an ACME server wishes to request proof that a user controls a IPv4 or IPv6 address, it MUST create an authorization with the identifier type "ip". The value field of the identifier MUST contain the textual form of the address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC5952] Section 4 for IPv6. Shoemaker Expires April 3, 2020 [Page 2] Internet-Draft ACME-IP October 2019 An identifier for the IPv6 address 2001:db8::1 would be formatted like so: {"type": "ip", "value": "2001:db8::1"} 4. Identifier Validation Challenges IP identifiers MAY be used with the existing "http-01" (see Section 8.3 of [RFC8555]) and "tls-alpn-01" (see Section 3 of [I-D.ietf-acme-tls-alpn]). To use IP identifiers with these challenges, their initial DNS resolution step MUST be skipped, and the IP address used for validation MUST be the value of the identifier. 5. HTTP Challenge For the "http-01" challenge, the Host header field MUST be set to the IP address being used for validation per [RFC7230]. The textual form of this address MUST be as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC5952] Section 4 for IPv6. 6. TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge For the "tls-alpn-01" challenge, the subjectAltName extension in the validation certificate MUST contain a single iPAddress that matches the address being validated. As [RFC6066] does not permit IP addresses to be used in the SNI extension HostName field, the server MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP address as the HostName field value instead of the IP address string representation itself. For example, if the IP address being validated is 2001:db8::1, the SNI HostName field should contain "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d .0.1.0.0.2.ip6.arpa". 7. DNS Challenge The existing "dns-01" challenge MUST NOT be used to validate IP identifiers. 8. IANA Considerations 8.1. Identifier Types Adds a new type to the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555] with Label "ip" and Reference "I-D.ietf- acme-ip". Shoemaker Expires April 3, 2020 [Page 3] Internet-Draft ACME-IP October 2019 8.2. Challenge Types Adds two new entries to the "ACME Validation Methods" registry defined in Section 9.7.8 of [RFC8555]. These entries are defined below: +-------------+-----------------+------+------------------+ | Label | Identifier Type | ACME | Reference | +-------------+-----------------+------+------------------+ | http-01 | ip | Y | I-D.ietf-acme-ip | | | | | | | tls-alpn-01 | ip | Y | I-D.ietf-acme-ip | +-------------+-----------------+------+------------------+ 9. Security Considerations The extensions to ACME described in this document do not deviate from the broader threat model described in [RFC8555] Section 10.1. 9.1. CA Policy Considerations This document only specifies how a ACME server may validate that a certificate applicant controls a IP identifier at the time of validation. The CA may wish to perform additional checks not specified in this document. For example, if the CA believes an IP identifier belongs to a ISP or cloud service provider with short delegation periods, they may wish to impose additional restrictions on certificates requested for that identifier. 10. Acknowledgments The author would like to thank those who contributed to this document and offered editorial and technical input, especially Jacob Hoffman- Andrews and Daniel McCarney. 11. Normative References [I-D.ietf-acme-tls-alpn] Shoemaker, R., "ACME TLS ALPN Challenge Extension", draft- ietf-acme-tls-alpn-06 (work in progress), September 2019. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . Shoemaker Expires April 3, 2020 [Page 4] Internet-Draft ACME-IP October 2019 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . Author's Address Roland Bracewell Shoemaker Internet Security Research Group Email: roland@letsencrypt.org Shoemaker Expires April 3, 2020 [Page 5] ./draft-ietf-lwig-cellular-06.txt0000644000764400076440000011550712642451747016146 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-acme-star-11.txt0000644000764400076440000017726113554324615015254 0ustar iustyiusty ACME Working Group Y. Sheffer Internet-Draft Intuit Intended status: Standards Track D. Lopez Expires: April 26, 2020 O. Gonzalez de Dios A. Pastor Perales Telefonica I+D T. Fossati ARM October 24, 2019 Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME) draft-ietf-acme-star-11 Abstract Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short-term and automatically renewed (STAR) X.509 certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR. 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 https://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 26, 2020. Sheffer, et al. Expires April 26, 2020 [Page 1] Internet-Draft ACME STAR October 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Name Delegation Use Case . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Conventions used in this document . . . . . . . . . . . . 4 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 3.1. ACME Extensions . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Extending the Order Resource . . . . . . . . . . . . 7 3.1.2. Canceling an Auto-renewal Order . . . . . . . . . . . 8 3.2. Capability Discovery . . . . . . . . . . . . . . . . . . 10 3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 11 3.4. Negotiating an unauthenticated GET . . . . . . . . . . . 13 3.5. Computing notBefore and notAfter of STAR Certificates . . 14 3.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15 4. Operational Considerations . . . . . . . . . . . . . . . . . 15 4.1. The Meaning of "Short Term" and the Impact of Skewed Clocks . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Impact on Certificate Transparency (CT) Logs . . . . . . 16 4.3. HTTP Caching and Dependability . . . . . . . . . . . . . 16 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 18 5.1.2. STAR Proxy . . . . . . . . . . . . . . . . . . . . . 18 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 18 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 19 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 19 5.6. Implementation experience . . . . . . . . . . . . . . . . 19 Sheffer, et al. Expires April 26, 2020 [Page 2] Internet-Draft ACME STAR October 2019 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 19 6.2. New Error Types . . . . . . . . . . . . . . . . . . . . . 20 6.3. New fields in Order Objects . . . . . . . . . . . . . . . 20 6.4. Fields in the "auto-renewal" Object within an Order Object . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.5. New fields in the "meta" Object within a Directory Object 21 6.6. Fields in the "auto-renewal" Object within a Directory Metadata Object . . . . . . . . . . . . . . . . . . . . . 22 6.7. Cert-Not-Before and Cert-Not-After HTTP Headers . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.1. No revocation . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Denial of Service Considerations . . . . . . . . . . . . 23 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 24 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Document History . . . . . . . . . . . . . . . . . . 27 A.1. draft-ietf-acme-star-11 . . . . . . . . . . . . . . . . . 27 A.2. draft-ietf-acme-star-10 . . . . . . . . . . . . . . . . . 27 A.3. draft-ietf-acme-star-09 . . . . . . . . . . . . . . . . . 27 A.4. draft-ietf-acme-star-08 . . . . . . . . . . . . . . . . . 27 A.5. draft-ietf-acme-star-07 . . . . . . . . . . . . . . . . . 27 A.6. draft-ietf-acme-star-06 . . . . . . . . . . . . . . . . . 27 A.7. draft-ietf-acme-star-05 . . . . . . . . . . . . . . . . . 28 A.8. draft-ietf-acme-star-04 . . . . . . . . . . . . . . . . . 28 A.9. draft-ietf-acme-star-03 . . . . . . . . . . . . . . . . . 28 A.10. draft-ietf-acme-star-02 . . . . . . . . . . . . . . . . . 28 A.11. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 28 A.12. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 28 A.13. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 29 A.14. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 29 A.15. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 29 A.16. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The ACME protocol [RFC8555] automates the process of issuing a certificate to a named entity (an Identifier Owner or IdO). Typically, but not always, the identifier is a domain name. If the IdO wishes to obtain a string of short-term certificates originating from the same private key (see [Topalovic] about why using short-lived certificates might be preferable to explicit revocation), she must go through the whole ACME protocol each time a Sheffer, et al. Expires April 26, 2020 [Page 3] Internet-Draft ACME STAR October 2019 new short-term certificate is needed - e.g., every 2-3 days. If done this way, the process would involve frequent interactions between the registration function of the ACME Certification Authority (CA) and the identity provider infrastructure (e.g.: DNS, web servers), therefore making the issuance of short-term certificates exceedingly dependent on the reliability of both. This document presents an extension of the ACME protocol that optimizes this process by making short-term certificates first class objects in the ACME ecosystem. Once the Order for a string of short- term certificates is accepted, the CA is responsible for publishing the next certificate at an agreed upon URL before the previous one expires. The IdO can terminate the automatic renewal before the negotiated deadline, if needed - e.g., on key compromise. For a more generic treatment of STAR certificates, readers are referred to [I-D.nir-saag-star]. 1.1. Name Delegation Use Case The proposed mechanism can be used as a building block of an efficient name-delegation protocol, for example one that exists between a CDN or a cloud provider and its customers [I-D.ietf-acme-star-delegation]. At any time, the service customer (i.e., the IdO) can terminate the delegation by simply instructing the CA to stop the automatic renewal and letting the currently active certificate expire shortly thereafter. Note that in the name delegation use case the delegated entity needs to access the auto-renewed certificate without being in possession of the ACME account key that was used for initiating the STAR issuance. This leads to the optional use of unauthenticated GET in this protocol (Section 3.4). 1.2. Terminology IdO Identifier Owner, the owner of an identifier, e.g.: a domain name, a telephone number. STAR Short-Term and Automatically Renewed X.509 certificates. 1.3. Conventions used in this document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Sheffer, et al. Expires April 26, 2020 [Page 4] Internet-Draft ACME STAR October 2019 2. Protocol Flow The following subsections describe the three main phases of the protocol: o Bootstrap: the IdO asks an ACME CA to create a short-term and automatically-renewed (STAR) certificate (Section 2.1); o Auto-renewal: the ACME CA periodically re-issues the short-term certificate and posts it to the star-certificate URL (Section 2.2); o Termination: the IdO requests the ACME CA to discontinue the automatic renewal of the certificate (Section 2.3). 2.1. Bootstrap The IdO, in its role as an ACME client, requests the CA to issue a STAR certificate, i.e., one that: o Has a short validity, e.g., 24 to 72 hours. Note that the exact definition of "short" depends on the use case; o Is automatically renewed by the CA for a certain period of time; o Is downloadable from a (highly available) location. Other than that, the ACME protocol flows as usual between IdO and CA. In particular, IdO is responsible for satisfying the requested ACME challenges until the CA is willing to issue the requested certificate. Per normal ACME processing, the IdO is given back an Order resource associated with the STAR certificate to be used in subsequent interaction with the CA (e.g., if the certificate needs to be terminated.) The bootstrap phase ends when the ACME CA updates the Order resource to include the URL for the issued STAR certificate. 2.2. Refresh The CA issues the initial certificate after the authorization completes successfully. It then automatically re-issues the certificate using the same CSR (and therefore the same identifier and public key) before the previous one expires, and publishes it to the URL that was returned to the IdO at the end of the bootstrap phase. The certificate user, which could be either the IdO itself or a delegated third party, as described in [I-D.ietf-acme-star-delegation], obtains the certificate (Section 3.3) and uses it. The refresh process (Figure 1) goes on until either: Sheffer, et al. Expires April 26, 2020 [Page 5] Internet-Draft ACME STAR October 2019 o IdO explicitly terminates the automatic renewal (Section 2.3); or o Automatic renewal expires. Certificate ACME/STAR User Server | Retrieve cert | [...] |---------------------->| | | +------. / | | | / | | Automatic renewal : | | | \ | |<-----' \ | Retrieve cert | | |---------------------->| short validity period | | | | +------. / | | | / | | Automatic renewal : | | | \ | |<-----' \ | Retrieve cert | | |---------------------->| short validity period | | | | +------. / | | | / | | Automatic renewal : | | | \ | |<-----' \ | | | | [...] | [...] Figure 1: Auto renewal 2.3. Termination The IdO may request early termination of the STAR certificate by sending a cancellation request to the Order resource, as described in Section 3.1.2. After the CA receives and verifies the request, it shall: o Cancel the automatic renewal process for the STAR certificate; o Change the certificate publication resource to return an error indicating the termination of the issuance; o Change the status of the Order to "canceled". Note that it is not necessary to explicitly revoke the short-term certificate. Sheffer, et al. Expires April 26, 2020 [Page 6] Internet-Draft ACME STAR October 2019 Certificate ACME/STAR User IdO Server | | | | | Cancel Order | | +---------------------->| | | +-------. | | | | | | | End auto renewal | | | Remove cert link | | | etc. | | | | | | Done |<------' | |<----------------------+ | | | | | | Retrieve cert | +---------------------------------------------->| | Error: autoRenewalCanceled | |<----------------------------------------------+ | | Figure 2: Termination 3. Protocol Details This section describes the protocol details, namely the extensions to the ACME protocol required to issue STAR certificates. 3.1. ACME Extensions This protocol extends the ACME protocol, to allow for automatically renewed Orders. 3.1.1. Extending the Order Resource The Order resource is extended with a new "auto-renewal" object that MUST be present for STAR certificates. The "auto-renewal" object has the following structure: o start-date (optional, string): the earliest date of validity of the first certificate issued, in [RFC3339] format. When omitted, the start date is as soon as authorization is complete. o end-date (required, string): the latest date of validity of the last certificate issued, in [RFC3339] format. o lifetime (required, integer): the maximum validity period of each STAR certificate, an integer that denotes a number of seconds. This is a nominal value which does not include any extra validity time due to server or client adjustment (see below). Sheffer, et al. Expires April 26, 2020 [Page 7] Internet-Draft ACME STAR October 2019 o lifetime-adjust (optional, integer): amount of "left pad" added to each STAR certificate, an integer that denotes a number of seconds. The default is 0. If present, the value of the notBefore field that would otherwise appear in the STAR certificates is pre-dated by the specified number of seconds. See also Section 4.1 for why a client might want to use this control and Section 3.5 for how the effective certificate lifetime is computed. The value reflected by the server, together with the value of the lifetime attribute, can be used by the client as a hint to configure its polling timer. o allow-certificate-get (optional, boolean): see Section 3.4. These attributes are included in a POST message when creating the Order, as part of the "payload" encoded object. They are returned when the Order has been created, and the ACME server MAY adjust them at will, according to its local policy (see also Section 3.2). The optional notBefore and notAfter fields defined in Section 7.1.3 of [RFC8555] MUST NOT be present in a STAR Order. If they are included, the server MUST return an error with status code 400 "Bad Request" and type "malformedRequest". Section 7.1.6 of [RFC8555] defines the following values for the Order resource's status: "pending", "ready", "processing", "valid", and "invalid". In the case of auto-renewal Orders, the status MUST be "valid" as long as STAR certificates are being issued. We add a new status value: "canceled", see Section 3.1.2. A STAR certificate is by definition a dynamic resource, i.e., it refers to an entity that varies over time. Instead of overloading the semantics of the "certificate" attribute, this document defines a new attribute "star-certificate" to be used instead of "certificate". o star-certificate (optional, string): A URL for the (rolling) STAR certificate that has been issued in response to this Order. 3.1.2. Canceling an Auto-renewal Order An important property of the auto-renewal Order is that it can be canceled by the IdO, with no need for certificate revocation. To cancel the Order, the ACME client sends a POST to the Order URL as shown in Figure 3. Sheffer, et al. Expires April 26, 2020 [Page 8] Internet-Draft ACME STAR October 2019 POST /acme/order/ogfr8EcolOT HTTP/1.1 Host: example.org Content-Type: application/jose+json { "protected": base64url({ "alg": "ES256", "kid": "https://example.com/acme/acct/gw06UNhKfOve", "nonce": "Alc00Ap6Rt7GMkEl3L1JX5", "url": "https://example.com/acme/order/ogfr8EcolOT" }), "payload": base64url({ "status": "canceled" }), "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H" } Figure 3: Canceling an Auto-renewal Order After a successful cancellation, the server MUST NOT issue any additional certificates for this Order. When the Order is canceled, the server: o MUST update the status of the Order resource to "canceled" and MUST set an appropriate "expires" date; o MUST respond with 403 (Forbidden) to any requests to the star- certificate endpoint. The response SHOULD provide additional information using a problem document [RFC7807] with type "urn:ietf:params:acme:error:autoRenewalCanceled". Issuing a cancellation for an Order that is not in "valid" state is not allowed. A client MUST NOT send such a request, and a server MUST return an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:autoRenewalCancellationInvalid". The state machine described in Section 7.1.6 of [RFC8555] is extended as illustrated in Figure 4 (State Transitions for Order Objects). Sheffer, et al. Expires April 26, 2020 [Page 9] Internet-Draft ACME STAR October 2019 pending --------------+ | | | All authz | | "valid" | V | ready ---------------+ | | | Receive | | finalize | | request | V | processing ------------+ | | | First | | certificate | Error or | issued | Authorization failure V V valid invalid | | STAR | Certificate | canceled V canceled Figure 4 Explicit certificate revocation using the revokeCert interface (Section 7.6 of [RFC8555]) is not supported for STAR certificates. A server receiving a revocation request for a STAR certificate MUST return an error response with status code 403 (Forbidden) and type "urn:ietf:params:acme:error:autoRenewalRevocationNotSupported". 3.2. Capability Discovery In order to support the discovery of STAR capabilities, the "meta" field inside the directory object defined in Section 9.7.6 of [RFC8555] is extended with a new "auto-renewal" object. The "auto- renewal" object MUST be present if the server supports STAR. Its structure is as follows: o min-lifetime (required, integer): minimum acceptable value for auto-renewal lifetime, in seconds. o max-duration (required, integer): maximum delta between the auto- renewal end-date and start-date, in seconds. o allow-certificate-get (optional, boolean): see Section 3.4. Sheffer, et al. Expires April 26, 2020 [Page 10] Internet-Draft ACME STAR October 2019 An example directory object advertising STAR support with one day min-lifetime and one year max-duration, and supporting certificate fetching with an HTTP GET is shown in Figure 5. { "new-nonce": "https://example.com/acme/new-nonce", "new-account": "https://example.com/acme/new-account", "new-order": "https://example.com/acme/new-order", "new-authz": "https://example.com/acme/new-authz", "revoke-cert": "https://example.com/acme/revoke-cert", "key-change": "https://example.com/acme/key-change", "meta": { "terms-of-service": "https://example.com/acme/terms/2017-5-30", "website": "https://www.example.com/", "caa-identities": ["example.com"], "auto-renewal": { "min-lifetime": 86400, "max-duration": 31536000, "allow-certificate-get": true } } } Figure 5: Directory object with STAR support 3.3. Fetching the Certificates The certificate is fetched from the star-certificate endpoint with POST-as-GET as per [RFC8555] Section 7.4.2, unless client and server have successfully negotiated the "unauthenticated GET" option described in Section 3.4. In such case, the client can simply issue a GET to the star-certificate resource without authenticating itself to the server as illustrated in Figure 6. Sheffer, et al. Expires April 26, 2020 [Page 11] Internet-Draft ACME STAR October 2019 GET /acme/cert/g7m3ZQeTEqa HTTP/1.1 Host: example.org Accept: application/pem-certificate-chain HTTP/1.1 200 OK Content-Type: application/pem-certificate-chain Link: ;rel="index" Cert-Not-Before: Thu, 3 Oct 2019 00:00:00 GMT Cert-Not-After: Thu, 10 Oct 2019 00:00:00 GMT -----BEGIN CERTIFICATE----- [End-entity certificate contents] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [Issuer certificate contents] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [Other certificate contents] -----END CERTIFICATE----- Figure 6: Fetching a STAR certificate with unauthenticated GET The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After" HTTP header fields in the response. When they exist, they MUST be equal to the respective fields inside the end-entity certificate. Their format is "HTTP-date" as defined in Section 7.1.1.2 of [RFC7231]. Their purpose is to enable client implementations that do not parse the certificate. Following are further clarifications regarding usage of these header fields, as per [RFC7231] Sec. 8.3.1. All apply to both headers. o This header field is a single value, not a list. o The header field is used only in responses to GET, HEAD and POST- as-GET requests, and only for MIME types that denote public key certificates. o Header field semantics are independent of context. o The header field is not hop-by-hop. o Intermediaries MAY insert or delete the value; o If an intermediary inserts the value, it MUST ensure that the newly added value matches the corresponding value in the certificate. o The header field is not appropriate for a Vary field. o The header field is allowed within message trailers. o The header field is not appropriate within redirects. o The header field does not introduce additional security considerations. It discloses in a simpler form information that is already available inside the certificate. Sheffer, et al. Expires April 26, 2020 [Page 12] Internet-Draft ACME STAR October 2019 To improve robustness, the next certificate MUST be made available by the ACME CA at the URL pointed by "star-certificate" at the latest halfway through the lifetime of the currently active certificate. It is worth noting that this has an implication in case of cancellation: in fact, from the time the next certificate is made available, the cancellation is not completely effective until the "next" certificate also expires. To avoid the client accidentally entering a broken state, the notBefore of the "next" certificate MUST be set so that the certificate is already valid when it is published at the "star- certificate" URL. Note that the server might need to increase the auto-renewal lifetime-adjust value to satisfy the latter requirement. For a detailed description of the renewal scheduling logic, see Section 3.5. For further rationale on the need for adjusting the certificate validity, see Section 4.1. The server MUST NOT issue any certificates for this Order with notAfter after the auto-renewal end-date. For expired Orders, the server MUST respond with 403 (Forbidden) to any requests to the star-certificate endpoint. The response SHOULD provide additional information using a problem document [RFC7807] with type "urn:ietf:params:acme:error:autoRenewalExpired". Note that the Order resource's state remains "valid", as per the base protocol. 3.4. Negotiating an unauthenticated GET In order to enable the name delegation workflow defined in [I-D.ietf-acme-star-delegation] as well as to increase the reliability of the STAR ecosystem (see Section 4.3 for details), this document defines a mechanism that allows a server to advertise support for accessing star-certificate resources via unauthenticated GET (in addition to POST-as-GET), and a client to enable this service with per-Order granularity. Specifically, a server states its availability to grant unauthenticated access to a client's Order star-certificate by setting the allow-certificate-get attribute to true in the auto- renewal object of the meta field inside the Directory object: o allow-certificate-get (optional, boolean): If this field is present and set to true, the server allows GET (and HEAD) requests to star-certificate URLs. A client states its desire to access the issued star-certificate via unauthenticated GET by adding an allow-certificate-get attribute to the auto-renewal object of the payload of its newOrder request and setting it to true. Sheffer, et al. Expires April 26, 2020 [Page 13] Internet-Draft ACME STAR October 2019 o allow-certificate-get (optional, boolean): If this field is present and set to true, the client requests the server to allow unauthenticated GET (and HEAD) to the star-certificate associated with this Order. If the server accepts the request, it MUST reflect the attribute setting in the resulting Order object. Note that even when the use of unauthenticated GET has been agreed, the server MUST also allow POST-as-GET requests to the star- certificate resource. 3.5. Computing notBefore and notAfter of STAR Certificates We define "nominal renewal date" as the point in time when a new short-term certificate for a given STAR Order is due. Its cadence is a multiple of the Order's auto-renewal lifetime that starts with the issuance of the first short-term certificate and is upper-bounded by the Order's auto-renewal end-date (Figure 7). T - STAR Order's auto-renewal lifetime end - STAR Order's auto-renewal end-date nrd[i] - nominal renewal date of the i-th STAR certificate .- T -. .- T -. .- T -. .__. / \ / \ / \ / end -----------o---------o---------o---------o----X-------> t nrd[0] nrd[1] nrd[2] nrd[3] Figure 7: Nominal Renewal Date The rules to determine the notBefore and notAfter values of the i-th STAR certificate are as follows: notAfter = min(nrd[i] + T, end) notBefore = nrd[i] - max(adjust_client, adjust_server) Where "adjust_client" is the min between the auto-renewal lifetime- adjust value ("la"), optionally supplied by the client, and the auto- renewal lifetime of each short-term certificate ("T"); "adjust_server" is the amount of padding added by the ACME server to make sure that all certificates being published are valid at the time of publication. The server padding is a fraction f of T (i.e., f * T with .5 <= f < 1, see Section 3.3): adjust_client = min(T, la) adjust_server = f * T Sheffer, et al. Expires April 26, 2020 [Page 14] Internet-Draft ACME STAR October 2019 Note that the ACME server MUST NOT set the notBefore of the first STAR certificate to a date prior to the auto-renewal start-date. 3.5.1. Example Given a server that intends to publish the next STAR certificate halfway through the lifetime of the previous one, and a STAR Order with the following attributes: "auto-renewal": { "start-date": "2019-01-10T00:00:00Z", "end-date": "2019-01-20T00:00:00Z", "lifetime": 345600, // 4 days "lifetime-adjust": 259200 // 3 days } The amount of time that needs to be subtracted from each nominal renewal date is 3 days - i.e., max(min(345600, 259200), 345600 * .5). The notBefore and notAfter of each short-term certificate are: +----------------------+----------------------+ | notBefore | notAfter | +----------------------+----------------------+ | 2019-01-10T00:00:00Z | 2019-01-14T00:00:00Z | | 2019-01-11T00:00:00Z | 2019-01-18T00:00:00Z | | 2019-01-15T00:00:00Z | 2019-01-20T00:00:00Z | +----------------------+----------------------+ The value of the notBefore is also the time at which the client should expect the new certificate to be available from the star- certificate endpoint. 4. Operational Considerations 4.1. The Meaning of "Short Term" and the Impact of Skewed Clocks "Short Term" is a relative concept, therefore trying to define a cut- off point that works in all cases would be a useless exercise. In practice, the expected lifetime of a STAR certificate will be counted in minutes, hours or days, depending on different factors: the underlying requirements for revocation, how much clock synchronization is expected among relying parties and the issuing CA, etc. Nevertheless, this section attempts to provide reasonable suggestions for the Web use case, informed by current operational and research experience. Sheffer, et al. Expires April 26, 2020 [Page 15] Internet-Draft ACME STAR October 2019 Acer et al. [Acer] find that one of the main causes of "HTTPS error" warnings in browsers is misconfigured client clocks. In particular, they observe that roughly 95% of the "severe" clock skews - the 6.7% of clock-related breakage reports which account for clients that are more than 24 hours behind - happen to be within 6-7 days. In order to avoid these spurious warnings about a not (yet) valid server certificate, site owners could use the auto-renewal lifetime- adjust attribute to control the effective lifetime of their Web facing certificates. The exact number depends on the percentage of the "clock-skewed" population that the site owner expects to protect - 5 days cover 97.3%, 7 days cover 99.6% - as well as the nominal auto-renewal lifetime of the STAR Order. Note that exact choice is also likely to depend on the kinds of client that is prevalent for a given site or app - for example, Android and Mac OS clients are known to behave better than Windows clients. These considerations are clearly out of scope of the present document. In terms of security, STAR certificates and certificates with OCSP must-staple [RFC7633] can be considered roughly equivalent if the STAR certificate's and the OCSP response's lifetimes are the same. Given OCSP responses can be cached on average for 4 days [Stark], it is RECOMMENDED that a STAR certificate that is used on the Web has an "effective" lifetime (excluding any adjustment to account for clock skews) no longer than 4 days. 4.2. Impact on Certificate Transparency (CT) Logs Even in the highly unlikely case STAR becomes the only certificate issuance model, discussion with the IETF TRANS Working Group and Certificate Transparency (CT) logs implementers suggests that existing CT Log Server implementations are capable of sustaining the resulting 100-fold increase in ingestion rate. Additionally, such a future, higher load could be managed with a variety of techniques (e.g., sharding by modulo of certificate hash, using "smart" load- balancing CT proxies, etc.). With regards to the increase in the log size, current CT log growth is already being managed with schemes like Chrome's Log Policy [OBrien] which allow Operators to define their log life-cycle; and allowing the CAs, User Agents, Monitors, and any other interested entities to build-in support for that life- cycle ahead of time. 4.3. HTTP Caching and Dependability When using authenticated POST-as-GET, the HTTPS endpoint from where the STAR certificate is fetched can't be easily replicated by an on- path HTTP cache. Reducing the caching properties of the protocol makes STAR clients increasingly dependent on the ACME server Sheffer, et al. Expires April 26, 2020 [Page 16] Internet-Draft ACME STAR October 2019 availability. This might be problematic given the relatively high rate of client-server interactions in a STAR ecosystem and especially when multiple endpoints (e.g., a high number of CDN edge nodes) end up requesting the same certificate. Clients and servers should consider using the mechanism described in Section 3.4 to mitigate the risk. When using unauthenticated GET to fetch the STAR certificate, the server SHALL use the appropriate cache directives to set the freshness lifetime of the response (Section 5.2 of [RFC7234]) such that on-path caches will consider it stale before or at the time its effective lifetime is due to expire. 5. Implementation Status Note to RFC Editor: please remove this section before publication, including the reference to [RFC7942] and [I-D.sheffer-acme-star-request]. 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. It is up to the individual working groups to use this information as they see fit". 5.1. Overview The implementation is constructed around 3 elements: STAR Client for the Name Delegation Client (NDC), STAR Proxy for IdO and ACME Server for CA. The communication between them is over an IP network and the HTTPS protocol. The software of the implementation is available at: https://github.com/mami-project/lurk Sheffer, et al. Expires April 26, 2020 [Page 17] Internet-Draft ACME STAR October 2019 The following subsections offer a basic description, detailed information is available in https://github.com/mami- project/lurk/blob/master/proxySTAR_v2/README.md 5.1.1. ACME Server with STAR extension This is a fork of the Let's Encrypt Boulder project that implements an ACME compliant CA. It includes modifications to extend the ACME protocol as it is specified in this draft, to support recurrent Orders and cancelling Orders. The implementation understands the new "recurrent" attributes as part of the Certificate issuance in the POST request for a new resource. An additional process "renewalManager.go" has been included in parallel that reads the details of each recurrent request, automatically produces a "cron" Linux based task that issues the recurrent certificates, until the lifetime ends or the Order is canceled. This process is also in charge of maintaining a fixed URI to enable the NDC to download certificates, unlike Boulder's regular process of producing a unique URI per certificate. 5.1.2. STAR Proxy The STAR Proxy has a double role as ACME client and STAR Server. The former is a fork of the EFF Certbot project that implements an ACME compliant client with the STAR extension. The latter is a basic HTTP REST API server. The STAR Proxy understands the basic API request with a server. The current implementation of the API is defined in draft-ietf-acme-star- 01. Registration or Order cancellation triggers the modified Certbot client that requests, or cancels, the recurrent generation of certificates using the STAR extension over ACME protocol. The URI with the location of the recurrent certificate is delivered to the STAR client as a response. 5.2. Level of Maturity This is a prototype. 5.3. Coverage A STAR Client is not included in this implementation, but done by direct HTTP request with any open HTTP REST API tool. This is expected to be covered as part of the [I-D.sheffer-acme-star-request] implementation. Sheffer, et al. Expires April 26, 2020 [Page 18] Internet-Draft ACME STAR October 2019 This implementation completely covers STAR Proxy and ACME Server with STAR extension. 5.4. Version Compatibility The implementation is compatible with version draft-ietf-acme-star- 01. The implementation is based on the Boulder and Certbot code release from 7-Aug-2017. 5.5. Licensing This implementation inherits the Boulder license (Mozilla Public License 2.0) and Certbot license (Apache License Version 2.0 ). 5.6. Implementation experience To prove the concept all the implementation has been done with a self-signed CA, to avoid impact on real domains. To be able to do it we use the FAKE_DNS property of Boulder and static /etc/hosts entries with domains names. Nonetheless this implementation should run with real domains. Most of the implementation has been made to avoid deep changes inside of Boulder or Certbot, for example, the recurrent certificates issuance by the CA is based on an external process that auto- configures the standard Linux "cron" daemon in the ACME CA server. The reference setup recommended is one physical host with 3 virtual machines, one for each of the 3 components (client, proxy and server) and the connectivity based on host bridge. Network security is not enabled (iptables default policies are "accept" and all rules removed) in this implementation to simplify and test the protocol. 5.7. Contact Information See author details below. 6. IANA Considerations [[RFC Editor: please replace XXXX below by the RFC number.]] 6.1. New Registries This document requests that IANA create the following new registries: o ACME Order Auto Renewal Fields (Section 6.4) Sheffer, et al. Expires April 26, 2020 [Page 19] Internet-Draft ACME STAR October 2019 o ACME Directory Metadata Auto Renewal Fields (Section 6.6) All of these registries are administered under a Specification Required policy [RFC8126]. 6.2. New Error Types This document adds the following entries to the ACME Error Type registry: +-----------------------------------+-------------------+-----------+ | Type | Description | Reference | +-----------------------------------+-------------------+-----------+ | autoRenewalCanceled | The short-term | RFC XXXX | | | certificate is no | | | | longer available | | | | because the auto- | | | | renewal Order has | | | | been explicitly | | | | canceled by the | | | | IdO | | | autoRenewalExpired | The short-term | RFC XXXX | | | certificate is no | | | | longer available | | | | because the auto- | | | | renewal Order has | | | | expired | | | autoRenewalCancellationInvalid | A request to | RFC XXXX | | | cancel a auto- | | | | renewal Order | | | | that is not in | | | | state "valid" has | | | | been received | | | autoRenewalRevocationNotSupported | A request to | RFC XXXX | | | revoke a auto- | | | | renewal Order has | | | | been received | | +-----------------------------------+-------------------+-----------+ 6.3. New fields in Order Objects This document adds the following entries to the ACME Order Object Fields registry: Sheffer, et al. Expires April 26, 2020 [Page 20] Internet-Draft ACME STAR October 2019 +------------------+------------+--------------+-----------+ | Field Name | Field Type | Configurable | Reference | +------------------+------------+--------------+-----------+ | auto-renewal | object | true | RFC XXXX | | star-certificate | string | false | RFC XXXX | +------------------+------------+--------------+-----------+ 6.4. Fields in the "auto-renewal" Object within an Order Object The "ACME Order Auto Renewal Fields" registry lists field names that are defined for use in the JSON object included in the "auto-renewal" field of an ACME order object. Template: o Field name: The string to be used as a field name in the JSON object o Field type: The type of value to be provided, e.g., string, boolean, array of string o Configurable: Boolean indicating whether the server should accept values provided by the client o Reference: Where this field is defined Initial contents: The fields and descriptions defined in Section 3.1.1. +-----------------------+------------+--------------+-----------+ | Field Name | Field Type | Configurable | Reference | +-----------------------+------------+--------------+-----------+ | start-date | string | true | RFC XXXX | | end-date | string | true | RFC XXXX | | lifetime | integer | true | RFC XXXX | | lifetime-adjust | integer | true | RFC XXXX | | allow-certificate-get | boolean | true | RFC XXXX | +-----------------------+------------+--------------+-----------+ 6.5. New fields in the "meta" Object within a Directory Object This document adds the following entry to the ACME Directory Metadata Fields: +--------------+------------+-----------+ | Field Name | Field Type | Reference | +--------------+------------+-----------+ | auto-renewal | object | RFC XXXX | +--------------+------------+-----------+ Sheffer, et al. Expires April 26, 2020 [Page 21] Internet-Draft ACME STAR October 2019 6.6. Fields in the "auto-renewal" Object within a Directory Metadata Object The "ACME Directory Metadata Auto Renewal Fields" registry lists field names that are defined for use in the JSON object included in the "auto-renewal" field of an ACME directory "meta" object. Template: o Field name: The string to be used as a field name in the JSON object o Field type: The type of value to be provided, e.g., string, boolean, array of string o Reference: Where this field is defined Initial contents: The fields and descriptions defined in Section 3.2. +-----------------------+------------+-----------+ | Field Name | Field Type | Reference | +-----------------------+------------+-----------+ | min-lifetime | integer | RFC XXXX | | max-duration | integer | RFC XXXX | | allow-certificate-get | boolean | RFC XXXX | +-----------------------+------------+-----------+ 6.7. Cert-Not-Before and Cert-Not-After HTTP Headers The "Message Headers" registry should be updated with the following additional values: +-------------------+----------+----------+-----------------------+ | Header Field Name | Protocol | Status | Reference | +-------------------+----------+----------+-----------------------+ | Cert-Not-Before | http | standard | RFC XXXX, Section 3.3 | | Cert-Not-After | http | standard | RFC XXXX, Section 3.3 | +-------------------+----------+----------+-----------------------+ 7. Security Considerations 7.1. No revocation STAR certificates eliminate an important security feature of PKI which is the ability to revoke certificates. Revocation allows the administrator to limit the damage done by a rogue node or an adversary who has control of the private key. With STAR certificates, expiration replaces revocation so there is potential for lack of timeliness in the revocation taking effect. To that end, see also the discussion on clock skew in Section 4.1. Sheffer, et al. Expires April 26, 2020 [Page 22] Internet-Draft ACME STAR October 2019 It should be noted that revocation also has timeliness issues, because both CRLs and OCSP responses have nextUpdate fields that tell relying parties (RPs) how long they should trust this revocation data. These fields are typically set to hours, days, or even weeks in the future. Any revocation that happens before the time in nextUpdate goes unnoticed by the RP. One situation where the lack of explicit revocation could create a security risk to the IdO is when the Order is created with start-date some appreciable amount of time in the future. Recall that when authorizations have been fulfilled, the Order moves to the "valid" state and the star-certificate endpoint is populated with the first cert (Figure 4). So, if an attacker manages to get hold of the private key as well as of the first (post-dated) certificate, there is a time window in the future when they will be able to successfully impersonate the IdO. Note that cancellation is pointless in this case. In order to mitigate the described threat, it is RECOMMENDED that IdO place their Orders at a time that is close to the Order's start-date. More discussion of the security of STAR certificates is available in [Topalovic]. 7.2. Denial of Service Considerations STAR adds a new attack vector that increases the threat of denial of service attacks, caused by the change to the CA's behavior. Each STAR request amplifies the resource demands upon the CA, where one Order produces not one, but potentially dozens or hundreds of certificates, depending on the auto-renewal "lifetime" parameter. An attacker can use this property to aggressively reduce the auto- renewal "lifetime" (e.g. 1 sec.) jointly with other ACME attack vectors identified in Sec. 10 of [RFC8555]. Other collateral impact is related to the certificate endpoint resource where the client can retrieve the certificates periodically. If this resource is external to the CA (e.g. a hosted web server), the previous attack will be reflected to that resource. Mitigation recommendations from ACME still apply, but some of them need to be adjusted. For example, applying rate limiting to the initial request, by the nature of the auto-renewal behavior cannot solve the above problem. The CA server needs complementary mitigation and specifically, it SHOULD enforce a minimum value on auto-renewal "lifetime". Alternatively, the CA can set an internal certificate generation processes rate limit. Note that this limit has to take account of already-scheduled renewal issuances as well as new incoming requests. Sheffer, et al. Expires April 26, 2020 [Page 23] Internet-Draft ACME STAR October 2019 7.3. Privacy Considerations In order to avoid correlation of certificates by account, if unauthenticated GET is negotiated (Section 3.4) the recommendation in Section 10.5 of [RFC8555] regarding the choice of URL structure applies, i.e. servers SHOULD choose URLs of certificate resources in a non-guessable way, for example using capability URLs [W3C.WD-capability-urls-20140218]. 8. Acknowledgments This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI). This support does not imply endorsement. Thanks to Ben Kaduk, Richard Barnes, Roman Danyliw, Jon Peterson, Eric Rescorla, Ryan Sleevi, Sean Turner, Alexey Melnikov, Adam Roach, Martin Thomson and Mehmet Ersue for helpful comments and discussions that have shaped 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, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [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, . [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, . Sheffer, et al. Expires April 26, 2020 [Page 24] Internet-Draft ACME STAR October 2019 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . 9.2. Informative References [Acer] Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R., Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz, "Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors", DOI 10.1145/3133956.3134007, 2017, . [I-D.ietf-acme-star-delegation] Sheffer, Y., Lopez, D., Pastor, A., and T. Fossati, "An ACME Profile for Generating Delegated STAR Certificates", draft-ietf-acme-star-delegation-01 (work in progress), August 2019. [I-D.nir-saag-star] Nir, Y., Fossati, T., Sheffer, Y., and T. Eckert, "Considerations For Using Short Term Certificates", draft- nir-saag-star-01 (work in progress), March 2018. [I-D.sheffer-acme-star-request] Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Fossati, "Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates", draft-sheffer- acme-star-request-02 (work in progress), June 2018. [OBrien] O'Brien, D. and R. Sleevi, "Chromium Certificate Transparency Log Policy", 2017, . [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) Feature Extension", RFC 7633, DOI 10.17487/RFC7633, October 2015, . Sheffer, et al. Expires April 26, 2020 [Page 25] Internet-Draft ACME STAR October 2019 [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, . [Stark] Stark, E., Huang, L., Israni, D., Jackson, C., and D. Boneh, "The case for prefetching and prevalidating TLS server certificates", 2012, . [Topalovic] Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. Boneh, "Towards Short-Lived Certificates", 2012, . [W3C.WD-capability-urls-20140218] Tennison, J., "Good Practices for Capability URLs", World Wide Web Consortium WD WD-capability-urls-20140218, February 2014, . Sheffer, et al. Expires April 26, 2020 [Page 26] Internet-Draft ACME STAR October 2019 Appendix A. Document History [[Note to RFC Editor: please remove before publication.]] A.1. draft-ietf-acme-star-11 o One more nit re: random URL A.2. draft-ietf-acme-star-10 IESG processing: o More clarity on IANA registration (Alexey); o HTTP header requirements adjustments (Adam); o Misc editorial (Ben) A.3. draft-ietf-acme-star-09 Richard and Ryan's review resulted in the following updates: o STAR Order and Directory Meta attributes renamed slightly and grouped under two brand new "auto-renewal" objects; o IANA registration updated accordingly (note that two new registries have been added as a consequence); o Unbounded pre-dating of certificates removed so that STAR certs are never issued with their notBefore in the past; o Changed "recurrent" to "autoRenewal" in error codes; o Changed "recurrent" to "auto-renewal" in reference to Orders; o Added operational considerations for HTTP caches. A.4. draft-ietf-acme-star-08 o Improved text on interaction with CT Logs, responding to Mehmet Ersue's review. A.5. draft-ietf-acme-star-07 o Changed the HTTP headers names and clarified the IANA registration, following feedback from the IANA expert reviewer A.6. draft-ietf-acme-star-06 o Roman's AD review Sheffer, et al. Expires April 26, 2020 [Page 27] Internet-Draft ACME STAR October 2019 A.7. draft-ietf-acme-star-05 o EKR's AD review o A detailed example of the timing of certificate issuance and predating o Added an explicit client-side parameter for predating o Security considerations around unauthenticated GET A.8. draft-ietf-acme-star-04 o WG last call comments by Sean Turner o revokeCert interface handling o Allow negotiating plain-GET for certs o In STAR Orders, use star-certificate instead of certificate A.9. draft-ietf-acme-star-03 o Clock skew considerations o Recommendations for "short" in the Web use case o CT log considerations A.10. draft-ietf-acme-star-02 o Discovery of STAR capabilities via the directory object o Use the more generic term Identifier Owner (IdO) instead of Domain Name Owner (DNO) o More precision about what goes in the order o Detail server side behavior on cancellation A.11. draft-ietf-acme-star-01 o Generalized the introduction, separating out the specifics of CDNs. o Clean out LURK-specific text. o Using a POST to ensure cancellation is authenticated. o First and last date of recurrent cert, as absolute dates. Validity of certs in seconds. o Use RFC7807 "Problem Details" in error responses. o Add IANA considerations. o Changed the document's title. A.12. draft-ietf-acme-star-00 o Initial working group version. o Removed the STAR interface, the protocol between NDC and DNO. What remains is only the extended ACME protocol. Sheffer, et al. Expires April 26, 2020 [Page 28] Internet-Draft ACME STAR October 2019 A.13. draft-sheffer-acme-star-02 o Using a more generic term for the delegation client, NDC. o Added an additional use case: public cloud services. o More detail on ACME authorization. A.14. draft-sheffer-acme-star-01 o A terminology section. o Some cleanup. A.15. draft-sheffer-acme-star-00 o Renamed draft to prevent confusion with other work in this space. o Added an initial STAR protocol: a REST API. o Discussion of CDNI use cases. A.16. draft-sheffer-acme-star-lurk-00 o Initial version. Authors' Addresses Yaron Sheffer Intuit EMail: yaronf.ietf@gmail.com Diego Lopez Telefonica I+D EMail: diego.r.lopez@telefonica.com Oscar Gonzalez de Dios Telefonica I+D EMail: oscar.gonzalezdedios@telefonica.com Antonio Agustin Pastor Perales Telefonica I+D EMail: antonio.pastorperales@telefonica.com Sheffer, et al. Expires April 26, 2020 [Page 29] Internet-Draft ACME STAR October 2019 Thomas Fossati ARM EMail: thomas.fossati@arm.com Sheffer, et al. Expires April 26, 2020 [Page 30] ./draft-ietf-iasa2-rfc4071bis-11.txt0000644000764400076440000015563513454071476016165 0ustar iustyiusty IASA2 B. Haberman Internet-Draft Johns Hopkins University Obsoletes: 4071, 4333, 7691 (if J. Hall approved) CDT Intended status: Best Current Practice J. Livingood Expires: October 14, 2019 Comcast April 12, 2019 Structure of the IETF Administrative Support Activity, Version 2.0 draft-ietf-iasa2-rfc4071bis-11 Abstract The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this document is to document and describe the IETF Administrative Support Activity, version 2 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board, the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF Administration LLC Board. This document obsoletes RFC 4071, RFC 4333, and RFC 7691. 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 https://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 14, 2019. Haberman, et al. Expires October 14, 2019 [Page 1] Internet-Draft IASA2 April 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Scope Limitation . . . . . . . . . . . . . . . . . . . . . . 4 3. LLC Agreement with the Internet Society . . . . . . . . . . . 4 4. Definitions and Principles . . . . . . . . . . . . . . . . . 5 4.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Key Differences From the Old IASA Structure to IASA 2.0 . 6 4.3. General IETF LLC Responsibilities . . . . . . . . . . . . 6 4.4. IETF LLC Working Principles . . . . . . . . . . . . . . . 7 4.5. Principles of the IETF and ISOC Relationship . . . . . . 8 4.6. Relationship of the IETF LLC Board to the IETF Leadership 8 4.7. Review of IETF Executive Director and IETF LLC Board Decisions . . . . . . . . . . . . . . . . . . . . . . . . 8 4.8. Termination and Change . . . . . . . . . . . . . . . . . 9 5. Structure of IASA2 . . . . . . . . . . . . . . . . . . . . . 9 5.1. IETF Executive Director and Staff Responsibilities . . . 9 5.2. IETF LLC Board Responsibilities . . . . . . . . . . . . . 11 5.3. Board Design Goals . . . . . . . . . . . . . . . . . . . 12 6. IETF LLC Board Membership, Selection and Accountability . . . 13 6.1. Board Composition . . . . . . . . . . . . . . . . . . . . 13 6.2. IETF LLC-Appointed Directors . . . . . . . . . . . . . . 14 6.3. Recruiting IETF LLC Board Directors . . . . . . . . . . . 14 6.4. IETF LLC Board Director Term Length . . . . . . . . . . . 14 6.5. IETF LLC Board Director Limit . . . . . . . . . . . . . . 15 6.6. Staggered Terms . . . . . . . . . . . . . . . . . . . . . 15 6.7. IETF LLC Board Director Removal . . . . . . . . . . . . . 15 6.8. Filling an IETF LLC Board Director Vacancy . . . . . . . 16 6.9. Quorum . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.10. Board Voting . . . . . . . . . . . . . . . . . . . . . . 16 6.11. Interim Board . . . . . . . . . . . . . . . . . . . . . . 16 6.12. Board Positions . . . . . . . . . . . . . . . . . . . . . 17 7. IETF LLC Funding . . . . . . . . . . . . . . . . . . . . . . 17 Haberman, et al. Expires October 14, 2019 [Page 2] Internet-Draft IASA2 April 2019 7.1. Financial Statements . . . . . . . . . . . . . . . . . . 17 7.2. Bank and Investment Accounts . . . . . . . . . . . . . . 18 7.3. Financial Audits . . . . . . . . . . . . . . . . . . . . 18 7.4. ISOC Financial Support . . . . . . . . . . . . . . . . . 18 7.5. IETF Meeting Revenues . . . . . . . . . . . . . . . . . . 18 7.6. Sponsorships and Donations to the IETF LLC . . . . . . . 18 7.7. Focus of Funding Support . . . . . . . . . . . . . . . . 19 7.8. Charitable Fundraising Practices . . . . . . . . . . . . 19 7.9. Operating Reserve . . . . . . . . . . . . . . . . . . . . 19 7.10. Annual Budget Process . . . . . . . . . . . . . . . . . . 19 8. IETF LLC Policies . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Conflict of Interest Policy . . . . . . . . . . . . . . . 20 8.2. Other Policies . . . . . . . . . . . . . . . . . . . . . 21 8.3. Compliance . . . . . . . . . . . . . . . . . . . . . . . 21 9. Three-Year Assessment . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. Pronouns . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this document is to document and describe the IASA 2.0 structure. Under IASA 2.0, the work of the IETF's administrative and fundraising tasks is conducted by an administrative organization, the IETF Administration Limited Liability Company ("IETF LLC"). Under this structure, the IETF Administrative Oversight Committee (IAOC) is eliminated, and its oversight and advising functions transferred to the IETF LLC Board. The IETF LLC provides the corporate legal home for the IETF, the Internet Architecture Board (IAB), and the Internet Research Task Force (IRTF), and financial support for the operation of the RFC Editor. [I-D.haberman-iasa20dt-recs] discusses the challenges facing the original IASA structure as well as several options for reorganizing the IETF's administration under different legal structures. This document outlines how the chosen option is structured and describes Haberman, et al. Expires October 14, 2019 [Page 3] Internet-Draft IASA2 April 2019 how the organization fits together with existing and new IETF community structures. Under IASA 2.0, most of the responsibilities that [RFC4071] assigned to the IETF Administrative Director (IAD) and the Internet Society (ISOC) were transferred to the IETF LLC and IETF Administration LLC Executive Director (IETF Executive Director). It is the job of the IETF LLC to meet the administrative needs of the IETF and to ensure that the IETF LLC meets the needs of the IETF community. Eliminating the IAOC meant that changes were required in how trustees could be appointed to the IETF Trust. The details of how this is done are outside the scope of this document but are covered in [I-D.ietf-iasa2-trust-update]. This document obsoletes [RFC4071], which specified the original IASA, [RFC4333], which specified the selection guidelines and process for IAOC members and [RFC7691], which specified terms for IAOC members. 2. Scope Limitation The document does not propose any changes related to the standards process as currently conducted by the Internet Engineering Steering Group (IESG) and Internet Architecture Board (IAB) (see BCP 9 [RFC2026], BCP 39 [RFC2850]). In addition, no changes are made to the appeals chain, the process for making and confirming IETF and IAB appointments (see BCP 10 [I-D.ietf-iasa2-rfc7437bis]), the technical work of the Internet Research Task Force (IRTF) (see BCP 8 [RFC2014]), or to ISOC's membership in or support of other organizations. 3. LLC Agreement with the Internet Society The LLC Agreement between the IETF LLC and ISOC is available at [IETF-LLC-A]. This IASA2 structure, and thus this document, depends on the LLC Agreement and will refer to it to help explain certain aspects of the legal relationship between the IETF LLC and ISOC. The LLC Agreement was developed between legal representatives of the IETF and ISOC and includes all critical terms of the relationship, while still enabling maximum unilateral flexibility for the IETF LLC Board. The LLC Agreement includes only basic details about how the Board manages itself or manages IETF LLC staff, so that the Board has flexibility to make changes without amending the agreement. The Board can independently develop policy or procedures documents that fill gaps. Haberman, et al. Expires October 14, 2019 [Page 4] Internet-Draft IASA2 April 2019 4. Definitions and Principles 4.1. Terminology Although most of the terms, abbreviations, and acronyms used in this document are reasonably well known, first-time readers may find some terminology confusing. This section therefore attempts to provide a quick summary. IAB: Internet Architecture Board (see [RFC2026], [RFC2850]). IAD: IETF Administrative Director, a role obsoleted by this document and the ISOC/IETF LLC Agreement ([IETF-LLC-A]) and replaced by the IETF LLC Executive Director. IAOC: IETF Administrative Oversight Committee, a committee that oversaw IETF administrative activity. The IAOC is obsoleted by this document and replaced by the IETF LLC Board. The IETF Trust was formerly populated by IAOC members. Its membership is now distinct from that of the IETF LLC Board (See [I-D.ietf-iasa2-trust-update]).) IASA: The IETF Administrative Support Activity, consists of the IETF LLC board, employees, and contractors. Uses of the term 'IASA' as a proper noun may imply a subset of these roles, or all of them. IASA 2.0: Version 2.0 of the IETF Administrative Support Activity, defined by this document. IESG: Internet Engineering Steering Group (see [RFC2026], [RFC3710]). IETF: Internet Engineering Task Force (see [RFC3233]). IETF Administration LLC: The legal entity - a disregarded Limited Liability Company (LLC) of The Internet Society - established to provide a corporate legal framework for facilitating current and future activities related to the IETF, IAB, and IRTF. It was established by the ISOC/IETF LLC Agreement ([IETF-LLC-A]) and is referred to as "IETF LLC." IETF LLC Executive Director: the Executive Director for the IETF LLC, responsible for day-to-day administrative and operational direction (See Section 5.1). Also referred to as "IETF Executive Director". IETF LLC Board: The Board of Directors of the IETF LLC. The IETF LLC Board is formally a multi-member "manager" of the IETF LLC on behalf of ISOC (See Section 5.2). ISOC: Internet Society (see [I-D.ietf-iasa2-rfc2031bis] and [ISOC]). Haberman, et al. Expires October 14, 2019 [Page 5] Internet-Draft IASA2 April 2019 4.2. Key Differences From the Old IASA Structure to IASA 2.0 o The IAOC and IAD roles defined in RFC 4071 are eliminated. o The former ISOC and IAD responsibilities are assigned to a new organization, IETF Administration LLC. o The Board of Directors of the IETF LLC - formally a multi-member "manager" of the IETF LLC on behalf of ISOC - assumes the oversight responsibilities from the IAOC. o The Board of the IETF LLC is more focused on strategy and oversight than the IAOC was, with the IETF Executive Director and their team in charge of day-to-day operations. o The IAD role is replaced with the IETF Executive Director role. o The role that was previously referred to as "IETF Executive Director" in older documents such as [RFC2026] is now "Managing Director, IETF Secretariat". 4.3. General IETF LLC Responsibilities The IETF LLC is established to provide administrative support to the IETF. It has no authority over the standards development activities of the IETF. The responsibilities of the IETF LLC are: o Operations. The IETF LLC is responsible for supporting the ongoing operations of the IETF, including meetings and non-meeting activities. o Finances. The IETF LLC is responsible for managing the IETF's finances and budget. o Fundraising. The IETF LLC is responsible for raising money on behalf of the IETF. o Compliance. The IETF LLC is responsible for establishing and enforcing policies to ensure compliance with applicable laws, regulations, and rules. The manner by which these responsibilities under the IETF LLC are organized is intended to address the problems described in Sections 3.1.1., 3.1.2, and 3.1.3 of [I-D.haberman-iasa20dt-recs]. Specifically, this is intended to bring greater clarity around roles, responsibilities, representation, decision-making, and authority. Haberman, et al. Expires October 14, 2019 [Page 6] Internet-Draft IASA2 April 2019 In addition, by having the IETF LLC manage the IETF's finances and conduct the IETF's fundraising, confusion about who is responsible for representing the IETF to sponsors and who directs the uses of sponsorship funds should have been eliminated. Finally, having the IETF LLC reside in a defined, distinct legal entity, and taking responsibility for operations, enables the organization to execute its own contracts without the need for review and approval by ISOC. 4.4. IETF LLC Working Principles The IETF LLC is expected to conduct its work according to the following principles: o Transparency. The IETF LLC is expected to keep the IETF community informed about its work, subject to reasonable confidentiality concerns, and to engage with the community to obtain consensus- based community input on key issues and otherwise as needed. The IETF community expects complete visibility into the financial and legal structure of the IETF LLC. This includes information about the IETF LLC annual budget and associated regular financial reports, results of financial and any other independent audits, tax filings, significant contracts or other significant long-term financial commitments that bind the IETF LLC. Whatever doesn't have a specific justification for being kept confidential is expected to be made public. The Board is expected to develop and maintain a public list of confidential items, describing the nature of the information and the reason for confidentiality. The Board will also publish its operating procedures. o Responsiveness to the community. The IETF LLC is expected to act consistently with the documented consensus of the IETF community, to be responsive to the community's needs, and to adapt its decisions in response to consensus-based community feedback. o Diligence. The IETF LLC is expected to act responsibly so as to minimize risks to IETF participants and to the future of the IETF as a whole, such as financial risks. o Unification: The IETF LLC provides the corporate legal home for the IETF, the Internet Architecture Board (IAB), and the Internet Research Task Force (IRTF), and financial support for the operation of the RFC Editor. o Transfer or Dissolution: Consistent with [IETF-LLC-A], the IETF LLC subsidiary may be transferred from ISOC to another organization, at the request of either party. Similarly, the IETF LLC may be dissolved if necessary. Should either event occur, the IETF community should be closely involved in any decisions and Haberman, et al. Expires October 14, 2019 [Page 7] Internet-Draft IASA2 April 2019 plans. Any transfer, transition, or dissolution should be conducted carefully and with minimal potential disruption to the IETF. The transparency and responsiveness principles are designed to address the concern outlined in Section 3.3 of [I-D.haberman-iasa20dt-recs] about the need for improved timeliness of sharing of information and decisions and seeking community comments. The issue of increased transparency was important throughout the IASA 2.0 process, with little to no dissent. It was recognized that there will naturally be confidentiality requirements about some aspects of contracting, personnel matters, and other narrow areas. 4.5. Principles of the IETF and ISOC Relationship The principles of the relationship between the IETF and ISOC are outlined in [I-D.ietf-iasa2-rfc2031bis]. In short, the IETF is responsible for the development of the Internet Standards and ISOC aids the IETF by providing it a legal entity within which the IETF LLC exists, as well as with financial support. 4.6. Relationship of the IETF LLC Board to the IETF Leadership The IETF LLC Board is directly accountable to the IETF community for the performance of the IASA 2.0. However, the nature of the Board's work involves treating the IESG, IRTF, and IAB as major internal customers of the administrative support services. The Board and the IETF Executive Director should not consider their work successful unless the IESG, IRTF, and IAB are also satisfied with the administrative support that the IETF is receiving. 4.7. Review of IETF Executive Director and IETF LLC Board Decisions The IETF LLC Board is directly accountable to the IETF community for the performance of the IASA 2.0, including hiring and managing the IETF Executive Director. In extreme cases of dissatisfaction with the IETF LLC, the IETF community can utilize the recall process as noted in Section 6.7. Anyone in the community of IETF participants may ask the Board for a formal review of a decision or action by the IETF Executive Director or Board if they believe this was not undertaken in accordance with IETF BCPs or IETF LLC Board policies and procedures. A formal request for review must be addressed to the IETF LLC Board chair and must include a description of the decision or action to be reviewed, an explanation of how, in the requestor's opinion, the Haberman, et al. Expires October 14, 2019 [Page 8] Internet-Draft IASA2 April 2019 decision or action violates the BCPs or IASA 2.0 operational guidelines, and a suggestion for how the situation could be rectified. The IETF LLC shall respond to such requests within a reasonable period, typically within 90 days, and shall publicly publish information about the request and the corresponding response and/or result. 4.8. Termination and Change Any major change to the IASA 2.0 arrangements shall require community consensus and deliberation and shall be reflected by a subsequent Best Current Practice (BCP) document. 5. Structure of IASA2 5.1. IETF Executive Director and Staff Responsibilities The IETF LLC is led by an IETF Executive Director chosen by the Board. The IETF Executive Director is responsible for managing the day-to-day operations of the IETF LLC, including hiring staff to perform various operational functions. The IETF Executive Director and any staff may be employees or independent contractors. Allowing for the division of responsibilities among multiple staff members and contractors is designed to address some of the concerns raised in Section 3.2 (Lack of Resources) and Section 3.4 (Funding/ Operating Model Mismatch and Rising Costs) of [I-D.haberman-iasa20dt-recs]. Based on the amount of work previously undertaken by the IAD and others involved in the IETF administration, the design of the IETF LLC anticipated that the IETF Executive Director may need to hire multiple additional staff members. For example, resources to manage fundraising, to manage the various contractors that are engaged to fulfill the IETF's administrative needs, and to support outreach and communications were envisioned. The IETF has historically benefited from the use of contractors for accounting, finance, meeting planning, administrative assistance, legal counsel, tools, and web site support, as well as other services related to the standards process (RFC Editor and IANA). Prior to making the transition from IASA to IASA 2.0, the IETF budget reflected specific support from ISOC for communications and fundraising as well as some general support for accounting, finance, legal, and other services. The division of responsibilities between Haberman, et al. Expires October 14, 2019 [Page 9] Internet-Draft IASA2 April 2019 staff and contractors is at the discretion of the IETF Executive Director and their staff. The IETF has a long history of community involvement in the execution of certain administrative functions, in particular development of IETF tools, the NOC's operation of the meeting network, and some outreach and communications activities conducted by the Education and Mentoring Directorate. The IETF LLC staff is expected to respect the IETF community's wishes about community involvement in these and other functions going forward as long as the staff feels that they can meet the otherwise-stated needs of the community. Establishing the framework to allow the IETF LLC to staff each administrative function as appropriate may require the IETF community to document its consensus expectations in areas where no documentation currently exists. In summary, the IETF Executive Director, with support from the team that they alone direct and lead, is responsible for: o Developing and refining an annual budget and other strategic financial planning documents at the direction of the Board. o Executing on the annual budget, including reporting to the Board regularly with forecasts and actual performance to budget. o Hiring and/or contracting the necessary resources to meet their goals, within the defined limits of the IETF Executive Director's authority and within the approved budget. This includes managing and leading any such resources, including performing regular performance reviews. o Following the pre-approval guidelines set forth by the Board for contracts or other decisions that have financial costs that exceed a certain threshold of significance. Such thresholds are expected to be set reasonably high so that the need for such approvals is infrequent and only occurs when something is truly significant or otherwise exceptional. It is expected that the IETF Executive Director is sufficiently empowered to perform the job on a day-to- day basis, being held accountable for meeting high level goals rather than micromanaged. o Regularly updating the Board on operations and other notable issues as reasonable and appropriate. o Ensuring that all staff and/or other resources comply with any applicable policies established or approved by the Board, such as ethics guidelines and/or a code of conduct. Haberman, et al. Expires October 14, 2019 [Page 10] Internet-Draft IASA2 April 2019 5.2. IETF LLC Board Responsibilities This section is intended to provide a summary of key IETF LLC Board responsibilities, but the precise and legally binding responsibilities are defined in the LLC Agreement [IETF-LLC-A] and applicable law. To the extent to which there are unintentional differences or other confusion between this document and these authoritative sources, these sources will control over this document. Board members have fiduciary obligations imposed by the LLC Agreement and applicable law, including duties of loyalty, care and good faith. The Board is responsible to set broad strategic direction for the LLC, and adopt an annual budget, hire or terminate an IETF Executive Director (or amend the terms of their engagement), adopt any employee benefit plans, consult the relevant IETF communities on matters related to the LLC as appropriate, approve any changes to the LLC governance structure, incur any debt, and approve entering into agreements that meet a significant materiality threshold to be determined by the Board. The IETF LLC Board is expected to delegate management of day-to-day activities and related decision-making to staff. Per Section 5(d) of the LLC Agreement and as also described in Section 4.4, the Board shall, as appropriate, act transparently and provide the IETF community with an opportunity to review and discuss any proposed changes to the IETF LLC structure prior to their adoption. The role of the Board is to ensure that the strategy and conduct of the IETF LLC is consistent with the IETF's needs - both its concrete needs and its needs for transparency and accountability. The Board is not intended to directly define the IETF's needs; to the extent that is required, the IETF community should document its needs in consensus-based RFCs (e.g., as the community did in [I-D.ietf-mtgvenue-iaoc-venue-selection-process]) and provide more detailed input via consultations with the Board (such as takes place on email discussion lists or at IETF meetings). Key IETF LLC Board responsibilities include: o Set broad strategic direction for the LLC. o Hire or terminate an IETF Executive Director (or amending the terms of their engagement). o Delegate management of day-to-day activities and related decision- making to staff. Haberman, et al. Expires October 14, 2019 [Page 11] Internet-Draft IASA2 April 2019 o Adopt any employee benefit plans. o Consult the relevant IETF communities on matters related to the LLC, as appropriate. o Approve any changes to the LLC governance structure. o Adopt an annual budget and, as necessary, incur any debt. o Prepare accurate and timely financial statements for ISOC, and in accordance with generally accepted accounting principles. o Provide assistance to help facilitate ISOC's tax compliance, including but not limited to assistance related to preparing the Form 990 and responding to any IRS questions and audits. o Approve entering into agreements that that meet a significant materiality threshold to be determined by the Board. o Limit its activities to the purposes as set forth in Section 4 of the LLC Agreement, in a manner consistent with ISOC's charitable purposes. o Establish an investment policy. o Use best efforts to conduct all of its activities in strict compliance with the LLC Agreement and all applicable laws, rules and regulations. o Ensure that IETF LLC is run in a manner that is transparent and accountable to the IETF community; o Develop policies, including those noted in Section 8), procedures, and a compliance program. o Obtain Commercial General Liability and other appropriate insurance policies, with agreed-upon coverage limits. o Recruit new Directors for consideration in all of the various appointment processes. 5.3. Board Design Goals A goal of this Board composition is to balance the need for the IETF LLC to be accountable to the IETF community with the need for this Board to have the expertise necessary to oversee a small non-profit company. The Board is smaller than the previous IAOC and the other leadership bodies of the IETF, in part to keep the Board focused on Haberman, et al. Expires October 14, 2019 [Page 12] Internet-Draft IASA2 April 2019 its rather limited set of strategic responsibilities as noted in Section 5.2. This board structure, with limited strategic responsibilities noted in Section 5.2 and limited size, together with the staff responsibilities noted in Section 5.1, is designed to overcome the challenges described in Section 3.1.4 of [I-D.haberman-iasa20dt-recs] concerning oversight. This establishes a clear line of oversight over staff performance: the IETF LLC Board oversees the IETF Executive Director's performance and has actual legal authority to remove a non-performing IETF Executive Director. The IETF Executive Director is responsible for the day-to-day operation of the IETF LLC. Finally, the Board would be expected to operate transparently, to further address the concern raised in Section 3.3 of [I-D.haberman-iasa20dt-recs]. The default transparency rule arrived at during the IASA 2.0 design process is detailed above in Section 4.4. The Board will need to establish how it will meet that commitment. 6. IETF LLC Board Membership, Selection and Accountability The section outlines the composition of the IETF LLC Board, selection of IETF LLC Board Directors, and related details. 6.1. Board Composition There is a minimum of 5 directors, expandable to 6 or 7. o 1 IETF Chair or delegate selected by the IESG o 1 Appointed by the ISOC Board of Trustees o 3 Selected by the IETF NomCom, confirmed by the IESG o Up to 2 Appointed by the IETF LLC board itself, on an as-needed basis, confirmed by the IESG For the first slot listed above, the presumption is that the IETF Chair will serve on the board. At the IESG's discretion, another area director may serve instead, or exceptionally the IESG may run a selection process to appoint a director. The goal of having this slot on the board is to maintain coordination and communication between the board and the IESG. Haberman, et al. Expires October 14, 2019 [Page 13] Internet-Draft IASA2 April 2019 6.2. IETF LLC-Appointed Directors As noted above, a maximum of two Directors may be appointed by the IETF LLC Board. They can obviously choose to appoint none, one, or two. These appointments need not be on an exceptional basis, but can be routine, and may occur at any time of the year since it is on an as-needed basis. The appointment of a Board-appointed Director requires a two-thirds majority vote of the Directors then in office, and the appointee shall take office immediately upon appointment and IESG confirmation. The term of each appointment is designated by the Board, with the maximum term being three years, or until their earlier resignation, removal or death. The Board may decide on a case-by-case basis how long each term shall be, factoring in the restriction for consecutive terms in Section 6.5. 6.3. Recruiting IETF LLC Board Directors The Board itself is expected to take an active role in recruiting potential new Directors, regardless of the process that may be used to appoint them. In particular, the NomCom is primarily focused on considering requirements expressed by the Board and others, reviewing community feedback on candidates, conducting candidate interviews, and ultimately appointing Directors. The Board and others can recruit potential Directors and get them into the consideration process of the NomCom or into open considerations processes of the other appointing bodies if those bodies choose to use such processes. 6.4. IETF LLC Board Director Term Length The term length for a Director is three years. The exceptions to this guideline are: o For the terms for some Directors during the first full formation of the IETF LLC Board in order to establish staggered terms and for any appointments to fill a vacancy. o The Director slot occupied by the IETF Chair ex officio or a delegate selected by the IESG will serve a two-year term. This applies regardless of whether the appointed individual is on the IESG, rotates off the IESG during the two-year term, or is not on the IESG. This makes the term length for this slot the same as the term lengths established in [I-D.ietf-iasa2-rfc7437bis], Section 3.4. Haberman, et al. Expires October 14, 2019 [Page 14] Internet-Draft IASA2 April 2019 6.5. IETF LLC Board Director Limit A director may serve no more than two consecutive terms. A director cannot serve a third term until three years have passed since their second consecutive term. An exception is if a Director role is occupied by the IETF Chair ex officio, since that person's service is governed instead by the term lengths established in [I-D.ietf-iasa2-rfc7437bis], Section 3.4. The term limits specified above apply to an individual, even if that individual is appointed in different ways over time. For example, an individual appointed to two terms by the ISOC Board of Trustees may not immediately be appointed to a third term by the IETF NomCom. A Director appointed by the IETF LLC itself may only serve for one term by that appointment method, and any subsequent terms would have to be via other methods; in any case, the term limits above apply to that individual. Lastly, partial terms of less than three years for the initial appointments to the first full board, for which some Directors will have terms of one or two years, do not count against the term limit. The limit on consecutive terms supports the healthy regular introduction of new ideas and energy into the Board and mitigates potential long-term risk of ossification or conflict, without adversely impacting the potential pool of director candidates over time. 6.6. Staggered Terms The Internet Society Board of Trustees, the IESG, the Nominating Committee, and the Board are expected to coordinate with each other to ensure that collectively their appointment or selection processes provide for no more than three Directors' terms concluding in the same year. 6.7. IETF LLC Board Director Removal NomCom-appointed and IESG-appointed Directors may be removed with or without cause. A vote in favor of removal must be no fewer than the number of Directors less two. So for example, if there are seven directors, then five votes are required. Directors may also be removed via the IETF recall process defined in [I-D.ietf-iasa2-rfc7437bis], Section 7. Haberman, et al. Expires October 14, 2019 [Page 15] Internet-Draft IASA2 April 2019 6.8. Filling an IETF LLC Board Director Vacancy It shall be the responsibility of each respective body that appointed or selected a Director that vacates the Board to appoint a new Director to fill the vacancy. For example, if a Director selected by the NomCom departs the Board prior to the end of their term for whatever reason, then it is the responsibility of the NomCom (using its mid-term rules, as specified in [I-D.ietf-iasa2-rfc7437bis], Section 3.5) as the original appointing body to designate a replacement that will serve out the remainder of the term of the departed Director. However, this obligation will not apply to vacancies in Board-appointed positions. 6.9. Quorum At all meetings of the Board, two-thirds of the Directors then in office shall constitute a quorum for the transaction of business. Unless a greater affirmative vote is expressly required for an action under applicable law, the LLC Agreement, or an applicable Board policy, the affirmative vote of two-thirds of the Directors then in office shall be an act of the Board. 6.10. Board Voting Board decisions may be made either by vote communicated in a meeting of the Board (including telephonic and video), or via an asynchronous written (including electronic) process. Absentee voting and voting by proxy shall not be permitted. If a quorum is not present at any meeting of the Board, the Directors present may adjourn the meeting without notice, other than announcement at the meeting, until a quorum is present. Voting thresholds for Director removal are described in Section 6.7. 6.11. Interim Board An initial interim Board was necessary in order to legally form and bootstrap the IETF LLC. As a result, an Interim Board was formed on a temporary basis until the first full board was constituted. The interim Board was comprised of: o The IETF chair, ex officio o The IAOC chair, ex officio o The IAB chair, ex officio o One ISOC trustee, selected by the ISOC Board of Trustees Haberman, et al. Expires October 14, 2019 [Page 16] Internet-Draft IASA2 April 2019 6.12. Board Positions Following the formation of the first permanent Board, and annually thereafter, the Directors shall elect a Director to serve as Board Chair by majority vote. The IETF, IAB and IRTF chairs, and the chair of ISOC's Board, will be ineligible for this Board Chair role. The Board may also form committees of the Board and/or define other roles for Board Directors as necessary. 7. IETF LLC Funding The IETF LLC must function within a budget of costs balanced against limited revenues. The IETF community expects the IETF LLC to work to attain that goal, in order to maintain a viable support function that provides the environment within which the work of the IETF, IAB, IRTF, and RFC Editor can remain vibrant and productive. The IETF LLC was generating income from a few key sources at the time that this document was written, as enumerated below. Additional sources of income may be developed in the future, within the general bounds noted in Section 7.8, and some of these may decline in relevance or go away. As a result this list is subject to change over time and is merely an example of the primary sources of income for the IETF LLC at the time of this writing: 1. ISOC support 2. IETF meeting revenues 3. Sponsorships (monetary and/or in-kind) 4. Donations (monetary and/or in-kind) 7.1. Financial Statements As noted in Section 5.2, the IETF LLC must comply with relevant tax laws, such as filing an annual IRS Form 990. Other official financial statements may also be required. In addition to these official financial statements and forms, the IETF LLC is also expected to report on a regular basis to the IETF community on the current and future annual budget, budget forecasts vs. actuals over the course of a fiscal year, and on other significant projects as needed. This regular reporting to the IETF community is expected to be reported in the form of standard financial statements that reflect the income, expenses, assets, and liabilities of the IETF LLC. Haberman, et al. Expires October 14, 2019 [Page 17] Internet-Draft IASA2 April 2019 7.2. Bank and Investment Accounts The IETF LLC maintains its own bank account, separate and distinct from ISOC. The IETF LLC may at its discretion create additional accounts as needed. Similarly, the IETF LLC may as needed create investment accounts in support of its financial goals and objectives. 7.3. Financial Audits The IETF LLC is expected to retain and work with an independent auditor. Reports from the auditor are expected to be shared with the IETF community and other groups and organizations as needed or as required by law. 7.4. ISOC Financial Support ISOC currently provides significant financial support to the IETF LLC. Exhibit B of the [IETF-LLC-A] summarizes the financial support from ISOC for the foreseeable future. It is expected that this support will be periodically reviewed and revised, via a cooperative assessment process between ISOC and the IETF LLC. 7.5. IETF Meeting Revenues Meeting revenues are another important source of funding that supports the IETF, coming mainly from the fees paid by IETF meeting participants. The IETF Executive Director sets those meeting fees, in consultation with other IETF LLC staff and the IETF community, with approval by the IETF LLC Board. Setting these fees and projecting the number of participants at future meetings is a key part of the annual budget process. 7.6. Sponsorships and Donations to the IETF LLC Sponsorships and donations are an essential component of the financial support for the IETF. Within the general bounds noted in Section 7.8, the IETF LLC is responsible for fundraising activities in order to establish, maintain, and grow a strong foundation of donation revenues. This can and does include both direct financial contributions as well as in-kind contributions, such as equipment, software licenses, and services. Sponsorships and donations to the IETF LLC do not (and must not) convey to sponsors and donors any special oversight or direct influence over the IETF's technical work or other activities of the IETF or IETF LLC. This helps ensure that no undue influence may be ascribed to those from whom funds are raised, and so helps to maintain an open and consensus-based IETF standards process. Haberman, et al. Expires October 14, 2019 [Page 18] Internet-Draft IASA2 April 2019 To the extent that the IETF LLC needs to undertake any significant special projects for the IETF, the IETF LLC may need to fundraise distinctly for those special projects. As a result, the IETF LLC may conduct fundraising to support the IETF in general as well as one or more special fundraising efforts (which may also be accounted for distinctly and be held in a separate bank account or investment, as needed). 7.7. Focus of Funding Support The IETF LLC exists to support the IETF, IAB, and IRTF. Therefore, the IETF LLC's funding and all revenues, in-kind contributions, and other income that comprise that funding shall be used solely to support activities related to the IETF, IAB, IRTF, and RFC Editor, and for no other purposes. 7.8. Charitable Fundraising Practices When the IETF LLC conducts fundraising, it substantiates charitable contributions on behalf of ISOC - meaning that according to US tax law, the IETF LLC must send a written acknowledgment of contributions to donors. The IETF LLC evaluates and facilitates state, federal, and other applicable law and regulatory compliance for ISOC and/or the LLC with respect to such fundraising activities. In addition, the IETF LLC ensures that all fundraising activities are conducted in compliance with any policies developed by the IETF LLC, including but not limited to those noted in Section 8. 7.9. Operating Reserve An initial target operating reserve has been specified in Exhibit B of the [IETF-LLC-A]. That says that the IETF LLC should maintain an operating reserve equal to the IETF LLC's budgeted Net Loss for 2019 multiplied times three. The IETF LLC, in cooperation with ISOC, may regularly review the financial target for this reserve fund, as noted in the [IETF-LLC-A] or as otherwise necessary. Should the IETF LLC generate an annual budget surplus, it may choose to direct all or part of the surplus towards the growth of the operating reserve. 7.10. Annual Budget Process As noted in Section 4.3, the IETF LLC is responsible for managing the IETF's finances and budget. A key part of this responsibility is establishing, maintaining, and successfully meeting an annual budget. This is essential to the continued operation and vibrancy of the IETF's technical activities and establishes trust with ISOC, Haberman, et al. Expires October 14, 2019 [Page 19] Internet-Draft IASA2 April 2019 sponsors, and donors that funds are being appropriately spent, and that financial oversight is being conducted properly. This is also essential to the IETF LLC meeting applicable legal and tax requirements and is a core part of the Board's fiduciary responsibilities. As explained in Section 5.1, the IETF Executive Director is expected to develop, execute, and report on the annual budget. Regular reporting is expected to include forecast vs. budget statements, including updated projections of income and expenses for the full fiscal year. The Board, as explained in Section 5.2, is expected to review and approve the budget, as well as to provide ongoing oversight of the budget and of any other significant financial matters. The annual budget is expected to be developed in an open, transparent, and collaborative manner, in accordance with Section 4.4. The specific timeline for the development, review, and approval of the IETF LLC annual budget is established by the Board and may be revised as needed. 8. IETF LLC Policies The Board is expected to maintain policies as necessary to achieve the goals of the IETF LLC, meet transparency expectations of the community, comply with applicable laws or regulations, or for other reasons as appropriate. All policies are expected to be developed with input from the IETF community. Some policies provided by ISOC and past policies developed by the previous IAOC may provide a useful starting point for the Board to consider. 8.1. Conflict of Interest Policy The Board is expected to maintain a Conflict of Interest policy for the IETF LLC. While the details are determined by the Board, at a minimum such policy is expected to include the following: o The IETF, ISOC Board, IAB, or IRTF chair cannot be chair of the IETF LLC Board, though they may serve as a Director. o A Director cannot be a paid consultant or employee of the IETF Executive Director or their sub-contractors, nor a paid consultant or employee of ISOC. Haberman, et al. Expires October 14, 2019 [Page 20] Internet-Draft IASA2 April 2019 8.2. Other Policies The Board is expected to maintain additional policies for the IETF LLC as necessary, covering Directors, employees, and contractors, concerning issues such as: o Acceptance of gifts and other non-cash compensation; o Travel and expense reimbursement; o Anti-bribery; o Code of conduct; o Anti-harassment; o Non-discrimination; o Whistleblower; o Document retention; o Export controls; o Anti-terrorism sanctions; o Data protection and privacy; o Social media 8.3. Compliance The IETF LLC is expected to implement a compliance program to ensure its compliance with all applicable laws, rules and regulations, including without limitation laws governing bribery, anti-terrorism sanctions, export controls, data protection/privacy, as well as other applicable policies noted in Section 8. In addition, actions and activities of the IETF LLC must be consistent with 501(c)(3) purposes. The IETF LLC is expected report to ISOC and the IETF community on the implementation of its compliance plan on an annual basis. 9. Three-Year Assessment The IETF LLC, with the involvement of the community, shall conduct and complete an assessment of the structure, processes, and operation of IASA 2.0 and the IETF LLC. This should be presented to the Haberman, et al. Expires October 14, 2019 [Page 21] Internet-Draft IASA2 April 2019 community after a period of roughly three years of operation. The assessment may potentially include recommendations for improvements or changes to the IASA2 and/or IETF LLC. 10. Security Considerations This document describes the structure of the IETF's Administrative Support Activity (IASA), version 2 (IASA2). It introduces no security considerations for the Internet. 11. IANA Considerations This document has no IANA considerations in the traditional sense. However, some of the information in this document may affect how the IETF standards process interfaces with the IANA, so the IANA may be interested in the contents. 12. Pronouns This document has used "they" and "their" as a non-gender-specific pronoun to refer to a single individual. 13. Acknowledgments Thanks to Jari Arkko, Richard Barnes, Brian E Carpenter, Alissa Cooper, John C Klensin, Bob Hinden, Jon Peterson, Sean Turner and the IASA2 Working Group for discussions of possible structures, and to the attorneys of Morgan Lewis and Brad Biddle for legal advice. 14. References 14.1. Normative References [I-D.ietf-iasa2-rfc2031bis] Camarillo, G. and J. Livingood, "The IETF-ISOC Relationship", draft-ietf-iasa2-rfc2031bis-04 (work in progress), February 2019. [I-D.ietf-iasa2-rfc7437bis] Kucherawy, M., Hinden, R., and J. Livingood, "IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", draft-ietf-iasa2-rfc7437bis-06 (work in progress), March 2019. Haberman, et al. Expires October 14, 2019 [Page 22] Internet-Draft IASA2 April 2019 [IETF-LLC-A] The Internet Society, "Limited Liability Company Agreement of IETF Administration LLC", August 2018, . 14.2. Informative References [I-D.haberman-iasa20dt-recs] Haberman, B., Arkko, J., Daigle, L., Livingood, J., Hall, J., and E. Rescorla, "IASA 2.0 Design Team Recommendations", draft-haberman-iasa20dt-recs-03 (work in progress), November 2018. [I-D.ietf-iasa2-trust-update] Arkko, J. and T. Hardie, "Update to the Process for Selection of Trustees for the IETF Trust", draft-ietf- iasa2-trust-update-03 (work in progress), February 2019. [I-D.ietf-mtgvenue-iaoc-venue-selection-process] Lear, E., "IETF Plenary Meeting Venue Selection Process", draft-ietf-mtgvenue-iaoc-venue-selection-process-16 (work in progress), June 2018. [ISOC] The Internet Society, "Amended and restated By-Laws of the Internet Society", July 2018, . [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, October 1996, . [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, . [RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC 3233, DOI 10.17487/RFC3233, February 2002, . Haberman, et al. Expires October 14, 2019 [Page 23] Internet-Draft IASA2 April 2019 [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, DOI 10.17487/RFC3710, February 2004, . [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, . [RFC4333] Huston, G., Ed. and B. Wijnen, Ed., "The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process", BCP 113, RFC 4333, DOI 10.17487/RFC4333, December 2005, . [RFC7691] Bradner, S., Ed., "Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members", BCP 101, RFC 7691, DOI 10.17487/RFC7691, November 2015, . Authors' Addresses Brian Haberman Johns Hopkins University Email: brian@innovationslab.net Joseph Lorenzo Hall CDT Email: joe@cdt.org Jason Livingood Comcast Email: jason_livingood@comcast.com Haberman, et al. Expires October 14, 2019 [Page 24] ./draft-ietf-acme-tls-alpn-07.txt0000644000764400076440000005174413544734212016034 0ustar iustyiusty ACME Working Group R. Shoemaker Internet-Draft ISRG Intended status: Standards Track October 01, 2019 Expires: April 3, 2020 ACME TLS ALPN Challenge Extension draft-ietf-acme-tls-alpn-07 Abstract This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS. 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 https://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 3, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Shoemaker Expires April 3, 2020 [Page 1] Internet-Draft ACME-TLS-ALPN October 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. TLS with Application Layer Protocol Negotiation (TLS ALPN) Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. acme-tls/1 Protocol Definition . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. SMI Security for PKIX Certificate Extension OID . . . . . 6 6.2. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 6 6.3. ACME Validation Method . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Automatic Certificate Management Environment (ACME) [RFC8555] specification describes methods for validating control of domain names via HTTP and DNS. Deployment experience has shown it is also useful to be able to validate domain control using the TLS layer alone. In particular, this allows hosting providers, CDNs, and TLS- terminating load balancers to validate domain control without modifying the HTTP handling behavior of their backends. This document specifies a new TLS-based challenge type, tls-alpn-01. This challenge requires negotiating a new application-layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension [RFC7301]. Because this protocol does not build on a preexisting deployment base, the ability to fulfill tls-alpn-01 challenges is effectively opt-in. A service provider must proactively deploy new code in order to implement tls-alpn-01, so we can specify stronger controls in that code, resulting in a stronger validation method. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Shoemaker Expires April 3, 2020 [Page 2] Internet-Draft ACME-TLS-ALPN October 2019 3. TLS with Application Layer Protocol Negotiation (TLS ALPN) Challenge The TLS with Application Layer Protocol Negotiation (TLS ALPN) validation method proves control over a domain name by requiring the ACME client to configure a TLS server to respond to specific connection attempts using the ALPN extension with identifying information. The ACME server validates control of the domain name by connecting to a TLS server at one of the addresses resolved for the domain name and verifying that a certificate with specific content is presented. The tls-alpn-01 ACME challenge object has the following format: type (required, string): The string "tls-alpn-01" token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet as described in [RFC4648] Section 5. Trailing '=' padding characters MUST be stripped. See [RFC4086] for additional information on randomness requirements. The client prepares for validation by constructing a self-signed certificate that MUST contain an acmeIdentifier extension and a subjectAlternativeName extension [RFC5280]. The subjectAlternativeName extension MUST contain a single dNSName entry where the value is the domain name being validated. The acmeIdentifier extension MUST contain the SHA-256 digest [FIPS180-4] of the key authorization [RFC8555] for the challenge. The acmeIdentifier extension MUST be critical so that the certificate isn't inadvertently used by non-ACME software. The acmeIdentifier extension is identified by the id-pe- acmeIdentifier object identifier (OID) in the id-pe arc [RFC5280]: id-pe-acmeIdentifier OBJECT IDENTIFIER ::= { id-pe 31 } The extension has the following ASN.1 [X.680] format : Authorization ::= OCTET STRING (SIZE (32)) The extnValue of the id-pe-acmeIdentifier extension is the ASN.1 DER encoding [X.690] of the Authorization structure, which contains the SHA-256 digest of the key authorization for the challenge. Once this certificate has been created it MUST be provisioned such that it is returned during a TLS handshake where the "acme-tls/1" application-layer protocol has been negotiated and a Server Name Shoemaker Expires April 3, 2020 [Page 3] Internet-Draft ACME-TLS-ALPN October 2019 Indication (SNI) extension [RFC6066] has been provided containing the domain name being validated. A client responds by POSTing an empty JSON object ({}) to the challenge URL to acknowledge that the challenge is ready to be validated by the server. The base64url encoding of the protected headers and payload is described in [RFC8555] Section 6.1. POST /acme/authz/1234/1 Host: example.com Content-Type: application/jose+json { "protected": base64url({ "alg": "ES256", "kid": "https://example.com/acme/acct/1", "nonce": "JHb54aT_KTXBWQOzGYkt9A", "url": "https://example.com/acme/authz/1234/1" }), "payload": base64url({}), "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" } On receiving this request from a client the server constructs and stores the key authorization from the challenge "token" value and the current client account key. The server then verifies the client's control over the domain by verifying that the TLS server was configured as expected using the following steps: 1. The ACME server computes the expected SHA-256 digest of the key authorization. 2. The ACME server resolves the domain name being validated and chooses one of the IP addresses returned for validation (the server MAY validate against multiple addresses if more than one is returned). 3. The ACME server initiates a TLS connection to the chosen IP address. This connection MUST use TCP port 443. The ACME server MUST provide an ALPN extension with the single protocol name "acme-tls/1" and an SNI extension containing only the domain name being validated during the TLS handshake. 4. The ACME server verifies that during the TLS handshake the application-layer protocol "acme-tls/1" was successfully Shoemaker Expires April 3, 2020 [Page 4] Internet-Draft ACME-TLS-ALPN October 2019 negotiated (and that the ALPN extension contained only the value "acme-tls/1") and that the certificate returned contains: * a subjectAltName extension containing the dNSName being validated and no other entries * a critical acmeIdentifier extension containing the expected SHA-256 digest computed in step 1 The comparison of dNSNames MUST be case insensitive [RFC4343]. Note that as ACME doesn't support Unicode identifiers all dNSNames MUST be encoded using [RFC3492] rules. If all of the above steps succeed then the validation is successful, otherwise it fails. 4. acme-tls/1 Protocol Definition The "acme-tls/1" protocol MUST only be used for validating ACME tls- alpn-01 challenges. The protocol consists of a TLS handshake in which the required validation information is transmitted. The "acme- tls/1" protocol does not carry application data, once the handshake is completed the client MUST NOT exchange any further data with the server and MUST immediately close the connection. While this protocol uses X.509 certificates, it does not use the authentication method described in [RFC5280] and as such does not require a valid signature on the provided certificate nor require the TLS handshake to complete successfully. An ACME server may wish to use an off the shelf TLS stack where it is not simple to allow these divergences in the protocol as defined. Because of this, an ACME server MAY choose to withhold authorization if either the certificate signature is invalid or the handshake doesn't fully complete. ACME servers that implement "acme-tls/1" MUST only negotiate TLS 1.2 [RFC5246] or higher when connecting to clients for validation. 5. Security Considerations The design of this challenge relies on some assumptions centered around how a HTTPS server behaves during validation. The first assumption is that when a HTTPS server is being used to serve content for multiple DNS names from a single IP address it properly segregates control of those names to the users that own them. This means that if User A registers Host A and User B registers Host B the HTTPS server should not allow a TLS request using an SNI value for Host A to be served by User B or a TLS connection with a server_name extension identifying Host B to be Shoemaker Expires April 3, 2020 [Page 5] Internet-Draft ACME-TLS-ALPN October 2019 answered by User A. If the HTTPS server allows User B to serve this request it allows them to illegitimately validate control of Host A to the ACME server. The second assumption is that a server will not violate [RFC7301] by blindly agreeing to use the "acme-tls/1" protocol without actually understanding it. To further mitigate the risk of users claiming domain names used by other users on the same infrastructure hosting providers, CDNs, and other service providers SHOULD NOT allow users to provide their own certificates for the TLS ALPN validation process. If providers wish to implement TLS ALPN validation they SHOULD only generate certificates used for validation themselves and not expose this functionality to users. The extensions to the ACME protocol described in this document build upon the Security Considerations and threat model defined in [RFC8555] Section 10.1. 6. IANA Considerations [[RFC Editor: please replace I-D.ietf-acme-tls-alpn below by the RFC number.]] 6.1. SMI Security for PKIX Certificate Extension OID Within the SMI-numbers registry, the "SMI Security for PKIX Certificate Extension (1.3.6.1.5.5.7.1)" table is to be updated to add the following entry: +---------+----------------------+------------------------+ | Decimal | Description | References | +---------+----------------------+------------------------+ | 31 | id-pe-acmeIdentifier | I-D.ietf-acme-tls-alpn | +---------+----------------------+------------------------+ 6.2. ALPN Protocol ID Within the Transport Layer Security (TLS) Extensions registry, the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" table is to be updated to add the following entry: Shoemaker Expires April 3, 2020 [Page 6] Internet-Draft ACME-TLS-ALPN October 2019 +------------+-----------------------------+------------------------+ | Protocol | Identification Sequence | Reference | +------------+-----------------------------+------------------------+ | acme-tls/1 | 0x61 0x63 0x6d 0x65 0x2d | I-D.ietf-acme-tls-alpn | | | 0x74 0x6c 0x73 0x2f 0x31 | | | | ("acme-tls/1") | | +------------+-----------------------------+------------------------+ 6.3. ACME Validation Method The "ACME Validation Methods" registry is to be updated to include the following entry: +-------------+-----------------+------+------------------------+ | Label | Identifier Type | ACME | Reference | +-------------+-----------------+------+------------------------+ | tls-alpn-01 | dns | Y | I-D.ietf-acme-tls-alpn | +-------------+-----------------+------+------------------------+ 7. Acknowledgements The author would like to thank all those whom have provided design insights and editorial review of this document, including Richard Barnes, Ryan Hurst, Adam Langley, Ryan Sleevi, Jacob Hoffman-Andrews, Daniel McCarney, Marcin Walas, Martin Thomson and especially Frans Rosen, who discovered the vulnerability in the TLS SNI method that necessitated the writing of this specification. 8. Normative References [FIPS180-4] Department of Commerce, National., "NIST FIPS 180-4, Secure Hash Standard", March 2012, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . Shoemaker Expires April 3, 2020 [Page 7] Internet-Draft ACME-TLS-ALPN October 2019 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [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, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . Shoemaker Expires April 3, 2020 [Page 8] Internet-Draft ACME-TLS-ALPN October 2019 [X.680] International Telecommunication Union, ., "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", 2015, . [X.690] International Telecommunication Union, ., "Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2015, . Appendix A. Design Rationale The TLS ALPN challenge exists to iterate on the TLS SNI challenge defined in the early ACME drafts. The TLS SNI challenge was convenient for service providers who were either operating large TLS layer load balancing systems at which they wanted to perform validation or running servers fronting large numbers of DNS names from a single host as it allowed validation purely within the TLS layer. The value provided by the TLS SNI challenge was considered large enough that this document was written in order to provide a new challenge type that addressed the existing security concerns. A security issue in the TLS SNI challenge was discovered by Frans Rosen, which allowed users of various service providers to illegitimately validate control of the DNS names of other users of the provider. When the TLS SNI challenge was designed it was assumed that a user would only be able to respond to TLS traffic via SNI for domain names they had registered with a service provider (i.e., if a user registered 'a.example' they would only be able to respond to SNI requests for 'a.example' and not for SNI requests for 'b.example'). It turns out that a number of large service providers do not honor this property. Because of this, users were able to respond to SNI requests for the names used by the TLS SNI challenge validation process. This meant that if User A and User B had registered Host A and Host B, respectively, User A would be able to claim the constructed SNI challenge name for Host B and when the validation connection was made that User A would be able to answer, proving 'control' of Host B. As the SNI name used was a subdomain of the domain name being validated, rather than the domain name itself, it was likely to not already be registered with the service provider for traffic routing, making it much easier for a hijack to occur. Shoemaker Expires April 3, 2020 [Page 9] Internet-Draft ACME-TLS-ALPN October 2019 Author's Address Roland Bracewell Shoemaker Internet Security Research Group Email: roland@letsencrypt.org Shoemaker Expires April 3, 2020 [Page 10] ./draft-ietf-iasa2-rfc5377bis-03.txt0000644000764400076440000004444513527426611016170 0ustar iustyiusty IASA2 J. Halpern, Ed. Internet-Draft Ericsson Obsoletes: 5377 (if approved) August 21, 2019 Intended status: Informational Expires: February 22, 2020 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents draft-ietf-iasa2-rfc5377bis-03 Abstract 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 accept 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 document obsoletes RFC 5377 solely for the purpose of removing references to the IAOC which was part of IASA. 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 https://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 22, 2020. Copyright Notice Copyright (c) 2019 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 Halpern Expires February 22, 2020 [Page 1] Internet-Draft Outbound Rights Advice August 2019 (https://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. Purpose in Granting Rights . . . . . . . . . . . . . . . . . 3 3. Powers and Authority . . . . . . . . . . . . . . . . . . . . 3 4. Recommended Grants of Right to Copy . . . . . . . . . . . . . 4 4.1. Rights Granted for Reproduction of RFCs . . . . . . . . . 5 4.2. Rights Granted for Quoting from IETF Contributions . . . 5 4.3. Rights Granted for Implementing Based on IETF Contributions . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Rights Granted for Use of Text from IETF Contributions . 6 4.5. Additional Licenses for IETF Contributions . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Under the current operational and administrative structures, IETF intellectual property rights are vested in the IETF Trust administered by a board of trustees. This includes the right to make use of IETF Contributions, as granted by Contributors under the rules laid out in [RFC5378]. The Trustees of the IETF Trust are therefore responsible for defining the rights to copy granted by the IETF to people who wish to make use of the material in these documents. For consistency and clarity, this document uses the same terminology laid out in [RFC5378] and uses the same meanings as defined in that document. The IETF Trust, by way of its Trustees, has indicated, as is consistent with the IETF structure, that it will respect the wishes of the IETF in regard to what these granted rights ought to be. It is therefore the IETF's responsibility to articulate those wishes. This document represents the wishes of the IETF regarding the rights granted to all users in regard to IETF Contributions, until it is superseded. Halpern Expires February 22, 2020 [Page 2] Internet-Draft Outbound Rights Advice August 2019 2. Purpose in Granting Rights In providing a description of the wishes of the IETF with regard to rights granted in RFCs, it is helpful to keep in mind the purpose of granting such rights. The mission of the IETF is to produce documents that make the Internet work better (see [RFC3935] for more details). These documents, when completed, are published as RFCs. An important subclass of RFCs is standards describing protocols; for these, the primary value to the Internet is the ability of implementors to build solutions (products, software, etc.) that interoperate using these standards. Hence, the IETF has a strong interest in seeing accurate, interoperable implementations of the material the IETF publishes. The IETF Trust grants rights to copy to people to make use of the text in the RFCs in order to encourage accurate and interoperable implementations. As early implementations from Internet-Drafts make use of descriptions in those Internet-Drafts, similar desires apply to Internet-Drafts. Similar considerations also apply to non-standard, non-protocol documents such as BCP (Best Current Practice) and Informational documents; in this document, we recommend a common approach to the issue of right-to-use licenses for all IETF documents. Previous documents regarding rights in IETF documents have included in the RFC text specific text to be used to achieve the stated goals. This has proved problematic. When problems are found with such text, even when the problem is not a change in intent, it is necessary to revise the RFC to fix the problem. At best, this delays fixing legal issues that need prompt attention. As such, this document describes the IETF desires to the Trustees of the IETF Trust, but does not provide the specific legal wording to address the goals. The selection, and updating as necessary, of legal wording is left to the Trustees of the IETF Trust. 3. Powers and Authority As described in the introduction, and formally specified in [RFC5378], the legal authority for determining and granting users rights to copy material in RFCs and other IETF Contributions rests with the Trustees for the IETF Trust. This document provides guidance to that body, based on the rough consensus of the IETF. The Trustees of the IETF Trust have the authority and responsibility to determine the exact text insertions (or other mechanisms), if any, Halpern Expires February 22, 2020 [Page 3] Internet-Draft Outbound Rights Advice August 2019 needed in Internet-Drafts, RFCs, and all IETF Contributions to meet these goals. The IETF Trust License Policy is available from [TRUST-LEGAL] https://trustee.ietf.org/docs/IETF-Trust-License- Policy.pdf To ensure continuity, the starting point for license text and other materials will be that previously created by the Trustees of the IETF under the authority of [RFC5377] which this document supersedes. Changes to the IETF documentation, and document policies themselves, take effect as determined by the Trustees of the IETF Trust. This document does not specify what rights the IETF Trust receives from others in IETF Contributions. That is left to another document ([RFC5378]). While care has been taken by the working group in developing this document, and care will be taken by the Trustees of the IETF Trust, to see that sufficient rights are granted to the IETF Trust in IETF Contributions, it is also the case that the Trust can not grant rights it has not or does not receive, and it is expected that policies will be in line with that fact. Similarly, the rights granted for pre-existing documents can not be expanded unless the holders of rights in those Contributions choose to grant expanded rights. Nonetheless, to the degree it can, and without embarking on a massive effort, it is desirable if similar rights to those described below can be granted in older RFCs. 4. Recommended Grants of Right to Copy The IETF grants rights to copy and modify parts of IETF Contributions in order to meet the objectives described earlier. As such, different circumstances and different parts of documents may need different grants. This section contains subsections for each such different grant that is currently envisioned. Each section is intended to describe a particular usage, to describe how that usage is recognizable, and to provide guidance to the Trustees of the IETF Trust as to what rights the IETF would like to see granted in that circumstance and what limitations should be put on such granting. These recommendations for outgoing rights are structured around the assumptions documented in [RFC5378]. Thus, this document is about granting rights derived from those granted to the IETF Trust. The recommendations below are how those granted rights should in turn be passed on to others using IETF documents in ways and for purposes that fit with the goals of the IETF. This discussion is also separate from discussion of the rights the IETF itself requires in documents to do its job, as those are not "outbound" rights. It is expected that the rights granted to the IETF will be a superset of those copying rights we wish to grant to others. Halpern Expires February 22, 2020 [Page 4] Internet-Draft Outbound Rights Advice August 2019 4.1. Rights Granted for Reproduction of RFCs It has long been IETF policy to encourage copying of RFCs in full. This permits wide dissemination of the material, without risking loss of context or meaning. The IETF wishes to continue to permit anyone to make full copies and translations of RFCs. 4.2. Rights Granted for Quoting from IETF Contributions There is rough consensus that it is useful to permit quoting without modification of excerpts from IETF Contributions. Such excerpts may be of any length and in any context. Translation of quotations is also to be permitted. All such quotations should be attributed properly to the IETF and the IETF Contribution from which they are taken. 4.3. Rights Granted for Implementing Based on IETF Contributions IETF Contributions often include components intended to be directly processed by a computer. Examples of these include ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, and classical programming code. These are included in IETF Contributions for clarity and precision in specification. It is clearly beneficial, when such items are included in IETF Contributions, to permit the inclusion of such code components in products that implement the Contribution. It has been pointed out that in several important contexts, use of such code requires the ability to modify the code. One common example of this is simply the need to adapt code for use in specific contexts (languages, compilers, tool systems, etc.) Such use frequently requires some changes to the text of the code from the IETF Contribution. Another example is that code included in open source products is frequently licensed to permit any and all of the code to be modified. Since we want this code included in such products, it follows that we need to permit such modification. While there has been discussion of restricting in some way the rights to make such modifications, the rough consensus of the IETF is that such restrictions are likely a bad idea, and are certainly very complex to define. As such, the rough consensus is that the IETF Trust is to grant rights such that code components of IETF Contributions can be extracted, modified, and used by anyone in any way desired. To enable the broadest possible extraction, modification, and usage, the IETF Trust should avoid adding software license obligations beyond those already present in a Contribution. The granted rights to extract, modify, and use code should allow creation of derived works outside the IETF that may carry additional license obligations. As the IETF Trust can not grant rights it does not receive, the rights Halpern Expires February 22, 2020 [Page 5] Internet-Draft Outbound Rights Advice August 2019 to extract, modify, and use code described in this paragraph can not be granted in IETF Contributions that are explicitly marked as not permitting derivative works. While it is up to the Trustees of the IETF Trust to determine the best way of meeting this objective, two mechanisms are suggested here that are believed to be helpful in documenting the intended grant to readers and users of IETF Contributions. Firstly, the Trustees of the IETF Trust should maintain, in a suitable, easily accessible fashion, a list of common RFC components that will be considered to be code. To start, this list should include at least the items listed above. The Trustees of the IETF Trust will add to this list as they deem suitable or as they are directed by the IETF. Additionally, the Trustees of the IETF Trust should define a textual representation to be included in an IETF Contribution to indicate that a portion of the document is considered by the authors (and later, the working group, and upon approval, the IETF) to be code and thus subject to the permissions granted to use code. 4.4. Rights Granted for Use of Text from IETF Contributions There is no consensus at this time to permit the use of text from RFCs in contexts where the right to modify the text is required. The authors of IETF Contributions may be able and willing to grant such rights independently of the rights they have granted to the IETF by making the Contribution. 4.5. Additional Licenses for IETF Contributions There have been contexts where the material in an IETF Contribution is also available under other license terms. The IETF wishes to be able to include content that is available under such licenses. It is desirable to indicate in the IETF Contribution that other licenses are available. It would be inappropriate and confusing if such additional licenses restricted the rights the IETF intends to grant in the content of RFCS. However, the IETF does not wish to have IETF Contributions contain additional licenses, as that introduces a number of additional difficulties. Specifically, additional text in the document, and any additional license referred to by permitted additional text, must not in any way restrict the rights the IETF intends to grant to others for using the contents of IETF Contributions. Halpern Expires February 22, 2020 [Page 6] Internet-Draft Outbound Rights Advice August 2019 Authors of Contributions retain all rights in their Contributions. As such, an author may directly grant any rights they wish separately from what the IETF grants. However, a reader wishing to determine or make use of such grants will need to either consult external sources of information, possibly including open source code and documents, or contact the author directly. 5. IANA Considerations No values are assigned in this document, no registries are created, and there is no action assigned to the IANA by this document. One list (of kinds of code sections) is anticipated, to be created and maintained by the Trustees of the IETF Trust. It is up to the Trustees of the IETF Trust whether they create such a list and whether they choose to involve the IANA in maintaining that list. 6. Security Considerations This document introduces no new security considerations. It is a process document about the IETF's IPR rights being granted to other people. While there may be attacks against the integrity or effectiveness of the IETF processes, this document does not address such issues. 7. References 7.1. Normative References [RFC5377] Halpern, J., Ed., "Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents", RFC 5377, DOI 10.17487/RFC5377, November 2008, . [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, October 2008. 7.2. Informative References [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, . [TRUST-LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", March 2015. http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf Halpern Expires February 22, 2020 [Page 7] Internet-Draft Outbound Rights Advice August 2019 Author's Address Joel M. Halpern (editor) Ericsson P. O. Box 6049 Leesburg, VA 20178 US EMail: joel.halpern@ericsson.com Halpern Expires February 22, 2020 [Page 8] ./draft-ietf-alto-xdom-disc-06.txt0000644000764400076440000027472513527031650016225 0ustar iustyiusty ALTO S. Kiesel Internet-Draft University of Stuttgart Intended status: Standards Track M. Stiemerling Expires: February 21, 2020 H-DA August 20, 2019 Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery draft-ietf-alto-xdom-disc-06 Abstract The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix. Kiesel & Stiemerling Expires February 21, 2020 [Page 1] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Terminology and Requirements Language This document makes use of the ALTO terminology defined in RFC 5693 [RFC5693]. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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, 2020. Copyright Notice Copyright (c) 2019 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. Kiesel & Stiemerling Expires February 21, 2020 [Page 2] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. ALTO Cross-Domain Server Discovery Procedure: Overview . . . . 5 3. ALTO Cross-Domain Server Discovery Procedure: Specification . 6 3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 7 3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 8 3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 9 3.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10 4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 11 4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 11 4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 12 4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 12 4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 12 4.5. Summary and Further Extensions . . . . . . . . . . . . . . 14 5. Implementation, Deployment, and Operational Considerations . . 15 5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 15 5.2. Considerations for Network Operators . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 19 6.2. Availability of the ALTO Server Discovery Procedure . . . 20 6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 21 6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. Solution Approaches for Partitioned ALTO Knowledge . 27 A.1. Classification of Solution Approaches . . . . . . . . . . 27 A.2. Discussion of Solution Approaches . . . . . . . . . . . . 28 A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 28 A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 29 A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 29 Appendix B. Requirements for Cross-Domain Server Discovery . . . 30 B.1. Discovery Client Application Programming Interface . . . . 30 B.2. Data Storage and Authority Requirements . . . . . . . . . 30 B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 30 B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 31 B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 31 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 32 C.1. A generic Tracker-based Peer-to-Peer Application . . . . . 32 C.2. Architectural Options for Placing the ALTO Client . . . . 33 C.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36 C.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix D. Contributors List and Acknowledgments . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Kiesel & Stiemerling Expires February 21, 2020 [Page 3] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 1. Introduction 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 [RFC5693]. ALTO is realized by an HTTP-based client-server protocol [RFC7285], which can be used in various scenarios [RFC7971]. The ALTO base protocol document [RFC7285] specifies the communication between an ALTO client and one ALTO server. In principle, the client may send any ALTO query. For example, it might ask for the routing cost between any two IP addresses, or it might request network and cost maps for the whole network, which might be the worldwide Internet. It is assumed that the server can answer any query, possibly with some kind of default value if no exact data is known. No special provisions were made for deployment scenarios with multiple ALTO servers, with some servers having more accurate information about some parts of the network topology while others having better information about other parts of the network ("partitioned knowledge"). Various ALTO use cases have been studied in the context of such scenarios. In some cases, one cannot assume that a topologically nearby ALTO server (e.g., a server discovered with the procedure specified in [RFC7286]) will always provide useful information to the client. One such scenario is detailed in Appendix C. Several solution approaches, such as redirecting a client to a server that has more accurate information or forwarding the request to it on behalf of the client, have been proposed and analyzed (see Appendix A), but none has been specified so far. Section 3 of this document specifies the "ALTO Cross-Domain Server Discovery Procedure" for client-side usage in these scenarios. An ALTO client that wants to send an ALTO query related to a specific IP address or prefix X, may call this procedure with X as a paramenter. It will use Domain Name System (DNS) lookups to find of one ore more ALTO servers that can provide a competent answer. The above wording "related to" was intentionally kept somewhat unspecific, as the exact semantics depends on the ALTO service to be used; see Section 4. Those who are in control of the "reverse DNS" for a given IP address or prefix (i.e., the corresponding subdomain of in-addr.arpa. or ip6.arpa.) - typically an Internet Service Provider (ISP), a corporate IT department, or a university's computing center - may add resource records to the DNS that point to one or more relevant ALTO server(s). In many cases, it may be an ALTO server run by that ISP or IT department, as they naturally have good insight into routing costs from and to their networks. However, they may also refer to an ALTO server provided by someone else, e.g., their upstream ISP. Kiesel & Stiemerling Expires February 21, 2020 [Page 4] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 2. ALTO Cross-Domain Server Discovery Procedure: Overview This section gives a non-normative overview on the ALTO Cross-Domain Server Discovery Procedure. The detailed specification will follow in the next section. This procedure was inspired by the "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses parts of the basic ALTO Server Discovery Procedure [RFC7286]. The basic idea is to use the Domain Name System (DNS), more specifically the "in-addr.arpa." or "ip6.arpa." trees, which are mostly used for "reverse mapping" of IP addresses to host names by means of PTR resource records. There, URI-enabled Naming Authority Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping of domain names to Uniform Resource Identifiers (URIs), are installed as needed. Thereby, it is possible to store a mapping from an IP address or prefix to one or more ALTO server URIs in the DNS. The ALTO Cross-Domain Server Discovery Procedure is called with one IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as parameters. The service parameter is usually set to "ALTO:https". However, other parameter values may be used in some scenarios, e.g., "ALTO:http" to search for a server that supports unencrypted transmission for debugging purposes, or other application protocol or service tags if applicable. The procedure performs DNS lookups and returns one or more URI(s) of information resources related to said IP address or prefix, usually the URI(s) of one or more ALTO Information Resource Directory (IRD, see Section 9 of [RFC7285]). The U-NAPTR records also provide preference values, which should be considered if more than one URI is returned. The discovery procedure sequentially tries two different lookup strategies: First, an ALTO-specific U-NAPTR record is searched in the "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. corresponding to the given IP address or prefix. If this lookup does not yield a usable result, the procedure tries further lookups with truncated domain names, which correspond to shorter prefix lengths. The goal is to allow deployment scenarios that require fine-grained discovery on a per-IP basis, as well as large-scale scenarios where discovery is to be enabled for a large number of IP addresses with a small number of additional DNS resource records. Kiesel & Stiemerling Expires February 21, 2020 [Page 5] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 3. ALTO Cross-Domain Server Discovery Procedure: Specification 3.1. Interface The procedure specified in this document takes two parameters, X and SP, where X is an IP address or prefix and SP is a U-NAPTR Service Parameter. The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". In both cases, X consists of an IP address A and a prefix length L. From the definition of IPv4 and IPv6 it follows that syntactically valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128 when AT=IPv6. However, not all syntactically valid values of L are actually supported by this procedure - Step 1 (see below) will check for unsupported values and report an error if neccessary. For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0 and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6, A=2001:0DB8::20 and L=128. In the intended usage scenario, the procedure is normally always called with the parameter SP set to "ALTO:https". However, for general applicabiliy and in order to support future extensions, the procedure MUST support being called with any valid U-NAPTR Service Parameter (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR Service Parameters and Section 5. of the same document for information about the IANA registries). The procedure performs DNS lookups and returns one or more URI(s) of information resources related to that IP address or prefix, usually the URI(s) of one or more ALTO Information Resource Directory (IRD, see Section 9 of [RFC7285]). For each URI, it also returns order and preference values (see Section 4.1 of [RFC3403]), which should be considered if more than one URI is returned. During execution of this procedure, various error conditions may occur and have to be reported to the caller; see Section 3.5. For the remainder of the document, we use the following notation for calling the ALTO Cross-Domain Server Discovery Procedure: IRD_URIS_X = XDOMDISC(X,"ALTO:https") Kiesel & Stiemerling Expires February 21, 2020 [Page 6] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup First, the procedure checks the prefix length L for unsupported values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the procedure aborts and indicates an "unsupported prefix length" error to the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts and indicates an "unsupported prefix length" error to the caller. Otherwise, the procedure continues. If AT=IPv4, the procedure will then produce a DNS domain name, which will be referred to as R32. This domain name is constructed according to the rules specified in Section 3.5 of [RFC1035] and it is rooted in the special domain "IN-ADDR.ARPA.". For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.". If AT=IPv6, a domain name. which will be called R128, is constructed according to the rules specified in Section 2.5 of [RFC3596] and the special domain "IP6.ARPA." is used. For example (note: a line break was added after the second line), A = 2001:0DB8::20 yields R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. 1.0.0.2.IP6.ARPA." Kiesel & Stiemerling Expires February 21, 2020 [Page 7] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 3.3. Step 2: Prepare Shortened Domain Names For this step, an auxiliary function "skip" is defined as follows: skip(str,n) will skip all characters in the string str, up to and including the n-th dot, and return the remaining part of str. For example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.". If AT=IPv4, the following additional domain names are generated from the result of the previous step: R24=skip(R32,1), R16=skip(R32,2), and R8=skip(R32,3). Removing one label from a domain name (i.e., one number of the "dotted quad notation") corresponds to shortening the prefix length by 8 bits. For example, R32="3.100.51.198.IN-ADDR.ARPA." yields R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and R8="198.IN-ADDR.ARPA.". If AT=IPv6, the following additional domain names are generated from the result of the previous step: R64=skip(R128,16), R56=skip(R128,18), R48=skip(R128,20), R40=skip(R128,22), and R32=skip(R128,24). Removing one label from a domain name (i.e., one hex digit) corresponds to shortening the prefix length by 4 bits. For example (note: a line break was added after the first line), R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. 1.0.0.2.IP6.ARPA." yields R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". Kiesel & Stiemerling Expires February 21, 2020 [Page 8] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 3.4. Step 3: Perform DNS U-NAPTR lookups The address type and the prefix length of X are matched against the first and the second column of the following table, respectively: +------------+------------+------------+----------------------------+ | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further | | Type AT | Length L | 1st lookup | lookups in that order | +------------+------------+------------+----------------------------+ | IPv4 | 32 | R32 | R24, R16, R8 | | IPv4 | 24 .. 31 | R24 | R16, R8 | | IPv4 | 16 .. 23 | R16 | R8 | | IPv4 | 8 .. 15 | R8 | (none) | | IPv4 | 0 .. 7 | (none, abort: unsupported prefix length)| +------------+------------+------------+----------------------------+ | IPv6 | 128 | R128 | R64, R56, R48, R40, R32 | | IPv6 | 64 (..127) | R64 | R56, R48, R40, R32 | | IPv6 | 56 .. 63 | R56 | R48, R40, R32 | | IPv6 | 48 .. 55 | R48 | R40, R32 | | IPv6 | 40 .. 47 | R40 | R32 | | IPv6 | 32 .. 39 | R32 | (none) | | IPv6 | 0 .. 31 | (none, abort: unsupported prefix length)| +------------+------------+------------+----------------------------+ Then, the domain name given in the 3rd column and the U-NAPTR Service Parameter SP the procedure was called with (usually "ALTO:https") MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one or more URIs (indicating protocol, host, and possibly path elements) for the ALTO server's Information Resource Directory (IRD). If such URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure returns that information to the caller and terminates successfully. For example, the following two U-NAPTR resource records can be used for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in the previous step) to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the former being preferred. 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto1.example.net/ird!" "" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" "!.*!https://alto2.example.net/ird!" "" If no matching U-NAPTR records can be found, the procedure SHOULD try further lookups, using the domain names from the fourth column in the indicated order, until one lookup succeeds. If no IRD URI could be found after looking up all domain names from the 3rd and 4th column, the procedure terminates unsuccessfully, returning an empty URI list. Kiesel & Stiemerling Expires February 21, 2020 [Page 9] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 3.5. Error Handling The ALTO Cross-Domain Server Discovery Procedure may fail for several reasons. If the procedure is called with syntactically invalid parameters or unsupported parameter values (in particular the prefix length L, see Section 3.2), the procedure aborts, no URI list will be returned and the error has to be reported to the caller. The procedure performs one or more DNS lookups in a well-defined order (corresponding to descending prefix lengths, see Section 3.4), until one produces a usable result. Each of these DNS lookups might not produce a usable result, either due to a normal condition (e.g., domain name exists, but no ALTO-specific NAPTR resource records are associated with it), a permanent error (e.g., non-existent domain name), or due to a temporary error (e.g., timeout). In all three cases, and as long as there are further domain names that can be looked up, the procedure SHOULD immediately try to lookup the next domain name (from column 4 in the table given in Section 3.4). Only after all domain names have been tried at least once, the procedure MAY retry those domain names that had caused temporary lookup errors. Generally speaking, ALTO provides advisory information for the optimization of applications (e.g., peer-to-peer applications, overlay networks, etc.), but applications should not rely on the availability of such information for their basic functionality (see Section 8.3.4.3 of RFC 7285 [RFC7285]). Consequently, the speedy detection of an ALTO server, even though it may give less accurate answers than other servers, or the quick realization that there is no suitable ALTO server, is in general more preferable than causing long delays by retrying failed queries. Nevertheless, the ALTO Cross- Domain Server Discovery Procedure SHOULD inform its caller, if DNS queries have failed due to temporary errors and that retrying the discovery at a later point in time might give more accurate results. Kiesel & Stiemerling Expires February 21, 2020 [Page 10] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 4. Using the ALTO Protocol with Cross-Domain Server Discovery Based on a modular design principle, ALTO provides several ALTO services, each consisting of a set of information resouces that can be accessed using the ALTO protocol. The information resources that are available at a specific ALTO server are listed in its Information Resource Directory (IRD, see Section 9 of [RFC7285]). The ALTO protocol specification defines the following ALTO services and their corresponding information resouces: o Network and Cost Map Service, see Section 11.2 of [RFC7285] o Map-Filtering Service, see Section 11.3 of [RFC7285] o Endpoint Property Service, see Section 11.4 of [RFC7285] o Endpoint Cost Service, see Section 11.5 of [RFC7285] The ALTO Cross-Domain Server Discovery Procedure is most useful in conjunction with the Endpoint Property Service and the Endpoint Cost Service. However, for the sake of completeness, possible interaction with all four services is discussed below. Extension documents may specify further information resources; however, these are out of scope of this document. 4.1. Network and Cost Map Service An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix "X" and get a list of one or more IRD URI(s), including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s) referenced by these URI(s) will always contain a network and a cost map, as these are mandatory information resources (see Section 11.2 of [RFC7285]). However, the cost matrix may be very sparse. If, according to the network map, PID_X is the PID that contains the IP address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDS, the cost map may look like this: From \ To PID_1 PID_2 PID_X PID_3 ------+----------------------------------- PID_1 | 92 PID_2 | 6 PID_X | 46 3 1 19 PID_3 | 38 In this example, all cells outside column "X" and row "X" are unspecified. A cost map with this structure contains the same information as what could be retrieved using the Endpoint Cost Kiesel & Stiemerling Expires February 21, 2020 [Page 11] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Service, cases 1 and 2 in Section 4.4. Accessing cells that are neither in column "X" nor row "X" may not yield useful results. Trying to assemble a more densely populated cost map from several cost maps with this very sparse structure may be a non-trivial task, as different ALTO servers may use different PID definitions (i.e., network maps) and incompatible scales for the costs, in particular for the "routingcost" metric. 4.2. Map-Filtering Service An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix "X" and get a list of one or more IRD URI(s), including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRD(s) may provide the optional Map-Filtering Service (see Section 11.3 of [RFC7285]). This service returns a subset of the full map, as specified by the client. As discussed in Section 4.1, a cost map may be very sparse in the envisioned deployment scenario. Therefore, depending on the filtering criteria provided by the client, this service may return results similar to the Endpoint Cost Service, or it may not return any useful result. 4.3. Endpoint Property Service If an ALTO client wants to query an Endpoint Property Service (see Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address "X" or a group of endpoints within IP prefix "X", respectively, it has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The result IRD_URIS_X is a list of one or more URIs of Information Resource Directories (IRD, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Property Service and query it. If the ALTO client wants to do a similar Endpoint Property query for a different IP address or prefix "Y", the whole procedure has to be repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a different list of IRD URIs. Of course, the results of individual DNS queries may be cached as indicated by their respective time-to-live (TTL) values. 4.4. Endpoint Cost Service The optional ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 7285 [RFC7285]) provides information about costs between individual endpoints and it also supports ranking. The ECS allows that endpoints may be denoted by IP addresses or prefixes. The ECS is Kiesel & Stiemerling Expires February 21, 2020 [Page 12] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 called with a list of one or more source IP addresses or prefixes, which we will call (S1, S2, S3, ...), and a list of one or more destination IP addresses or prefixes, called (D1, D2, D3, ...). This specification distinguishes several cases, regarding the number of elements in the list of source and destination addresses, respectively: 1. Exactly one source address S1 and more than one destination addresses D1, D2, D3, ... In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) with that single source address as a parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result IRD_URIS_S1 is a list of one or more URIs of Information Resource Directories (IRD, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Cost Service and query it. The ECS is an optional service (see Section 11.5.1 of RFC 7285 [RFC7285]) and therefore, it may well be that an IRD does not refer to an ECS. Calling the Cross-Domain Server Discovery Procedure only once with the single source address as a parameter - as opposed to multiple calls, e.g., one for each destination address - is not only a matter of efficiency. In the given scenario, it is advisable to send all ECS queries to the same ALTO server. This ensures that the results can be compared (e.g., for sorting candidate resource providers), even with cost metrics without a well-defined base unit, e.g., the "routingcost" metric. 2. More than one source addresses S1, S2, S3, ... and exactly one destination address D1. In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure with that single destination address as a parameter: IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result IRD_URIS_D1 is a list of one or more URIs of IRDs. Considering the order and preference values, the client has to check these IRDs for a suitable ECS and query it. 3. Exactly one source address S1 and exactly one destination address D1. The ALTO client may perform the same steps as in case 1, as specified above. As an alternative, it may also perform the same steps as in case 2, as specified above. 4. More than one source addresses S1, S2, S3, ... and more than one destination addresses D1, D2, D3, ... In this case, the ALTO client should split the list of desired queries based on source addresses and perform separately for each source address the same steps as in case 1, as specified above. As an alternative, the Kiesel & Stiemerling Expires February 21, 2020 [Page 13] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 ALTO client may also group the list based on destination addresses and perform separately for each destination address the same steps as in case 2, as specified above. However, comparing results between these sub-queries may be difficult, in particular if the cost metric is a relative preference without a well- defined base unit (e.g., the "routingcost" metric). See Appendix C for a detailed example showing the interaction of a tracker-based peer-to-peer application, the ALTO Endpoint Cost Service, and the ALTO Cross-Domain Server Discovery Procedure. 4.5. Summary and Further Extensions Considering the four services defined in the ALTO base protocol specification [RFC7285], the ALTO Cross-Domain Server Discovery Procedure works best with the Endpoint Property Service (EPS) and the Endpoint Cost Service (ECS). Both the EPS and the ECS take one or more IP addresses as a parameter. The previous sections specify how the parameter for calling the ALTO Cross-Domain Server Discovery Procedure has to be derived from these IP adresses. In contrast, the ALTO Cross-Domain Server Discovery Procedure seems less useful if the goal is to retrieve network and cost maps that cover the whole network topology. However, the procedure may be useful if a map centered at a specific IP address is desired (i.e., a map detailing the vicinity of said IP address or a map giving costs from said IP address to all potential destinations). The interaction between further ALTO services (and their corresponding information resources) needs to be investigated and defined once such further ALTO services are specified in an extension document. Kiesel & Stiemerling Expires February 21, 2020 [Page 14] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 5. Implementation, Deployment, and Operational Considerations 5.1. Considerations for ALTO Clients 5.1.1. Resource Consumer Initiated Discovery Resource consumer initiated ALTO server discovery (c.f. ALTO requirement AR-32 [RFC6708]) can be seen as a special case of cross- domain ALTO server discovery. To that end, an ALTO client embedded in a resource consumer would have to perform the ALTO Cross-Domain Server Discovery Procedure with its own IP address as a parameter. However, due to the widespread deployment of Network Address Translators (NAT), additional protocols and mechanisms such as STUN [RFC5389] are usually needed to detect the client's "public" IP address, before it can be used as a parameter to the discovery procedure. Note that a different approach for resource consumer initiated ALTO server discovery, which is based on DHCP, is specified in [RFC7286]. 5.1.2. IPv4/v6 Dual Stack, Multihoming and Host Mobility The procedure specified in this document can discover ALTO server URIs for a given IP address or prefix. The intention is, that a third party (e.g., a resource directory) that receives query messages from a resource consumer can use the source address in these messages to discover suitable ALTO servers for this specific resource consumer. However, resource consumers (as defined in Section 2 of [RFC5693]) may reside on hosts with more than one IP address, e.g., due to IPv4/v6 dual stack operation and/or multihoming. IP packets sent with different source addresses may be subject to different routing policies and path costs. In some deployment scenarios, it may even be required to ask different sets of ALTO servers for guidance. Furthermore, source addresses in IP packets may be modified en-route by Network Address Translators (NAT). If a resource consumer queries a resource directory for candidate resource providers, the locally selected (and possibly en-route translated) source address of the query message - as observed by the resource directory - will become the basis for the ALTO server discovery and the subsequent optimization of the resource directory's reply. If, however, the resource consumer then selects different source addresses to contact returned resource providers, the desired better-than-random "ALTO effect" may not occur. One solution approach for this problem is, that a dual stack or multihomed resource consumer could always use the same address for Kiesel & Stiemerling Expires February 21, 2020 [Page 15] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 contacting the resource directory and all resource providers, thus overriding the operating system's automatic source IP address selection. For example, when using the BSD socket API, one could always bind() the socket to one of the local IP addresses before trying to connect() to the resource directory or the resource providers, respectively. Another solution approach is to perform ALTO-influenced resource provider selection (and source address selection) locally in the resource consumer, in addition to or instead of performing it in the resource directory. See Section 5.1.1 for a discussion how to discover ALTO servers for local usage in the resource consumer. Similarly, resource consumers on mobile hosts SHOULD query the resource directory again after a change of IP address, in order to get a list of candidate resource providers that is optimized for the new IP address. 5.1.3. Interaction with Network Address Translation The ALTO Cross-Domain Server Discovery Procedure has been designed to enable the ALTO-based optimization of applications such as large- scale overlay networks, that span - on the IP layer - multiple adminstrative domains, possibly the whole Internet. Due to the widespread usage of Network Address Translators (NAT) it may well be that nodes of the overlay network (i.e., resource consumers or resource providers) are located behind a NAT, maybe even behind several cascaded NATs. If a resource directory is located in the public Internet (i.e., not behind a NAT) and if it receives a message from a resource consumer behind one or more NATs, the message's source address will be the public IP address of the outermost NAT in front of the resource consumer. The same applies if the resource directory is behind a different NAT than the resource consumer. The resource directory may call the ALTO Cross-Domain Server Discovery Procedure with the message's source address as a parameter. In effect, not the resource consumer's (private) IP address, but the public IP address of the outermost NAT in front of it will be used as a basis for ALTO- optimization. This will work fine as long as the network behind the NAT is not too big (e.g., if the NAT is in a residential gateway). If a resource directory receives a message from a resource consumer and the message's source address is a "private" IP address [RFC1918], this may be a sign that both of them are behind the same NAT. An invokation of the ALTO Cross-Domain Server Discovery Procedure with this private address may be problematic, as this will only yield usable results if a DNS "split horizon" and DNSSEC trust anchors are configured correctly. In this situation it may be more advisable to Kiesel & Stiemerling Expires February 21, 2020 [Page 16] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 query an ALTO server that has been discovered using [RFC7286] or any other local configuration. The interaction between intra-domain ALTO for large private domains (e.g., behind a "carrier-grade NAT") and cross-domain, Internet-wide optimization, is beyond the scope of this document. 5.2. Considerations for Network Operators 5.2.1. Flexibility vs. Load on the DNS The ALTO Cross-Domain Server Discovery Procedure, as specified in Section 3, first produces a list of domain names (steps 1 and 2) and then looks for relevant NAPTR records associated with these names, until a useful result can be found (step 3). The number of candidate domain names on this list is a compromise between flexibility when installing NAPTR records and avoiding excess load on the DNS. A single invocation of the ALTO Cross-Domain Server Discovery Procedure, with an IPv6 address as a parameter, may cause up to, but no more than, six DNS lookups for NAPTR records. For IPv4, the maximum is four lookups. Should the load on the DNS infrastructure caused by these lookups become a problem, one solution approach is to actually populate the DNS with ALTO-specific NAPTR records. If such records can be found for individual IP addresses (possibly installed using a wildcarding mechanism in the name server) or for long prefixes, the procedure will terminate successfully and not perform lookups for shorter prefix lengths, thus reducing the total number of DNS queries. Another approach for reducing the load on the DNS infrastructure is to increase the TTL for caching negative answers. On the other hand, the ALTO Cross-Domain Server Discovery Procedure trying to lookup truncated domain names allows for efficient configuration of large-scale scenarios, where discovery is to be enabled for a large number of IP addresses with a small number of additional DNS resource records. Note that expressly, it has not been a design goal of this procedure to give clients a means to understand the IP prefix delegation structure. Furthermore, this specification does not assume or reccomend that prefix delegations should preferrably occur at those prefix lengths that are used in Step 2 of this procedure (see Section 3.3). A network operator that uses, for example, an IPv4 /18 prefix and wants to install the NAPTR records efficiently, could either install 64 NAPTR records (one for each of the /24 prefixes contained within the /18 prefix), or they could try to team up with the owners of the other fragments of the enclosing /16 prefix, in order to run a common ALTO server to which only one NAPTR would point. Kiesel & Stiemerling Expires February 21, 2020 [Page 17] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 5.2.2. BCP20 and missing delegations of the reverse DNS RFC2317 [RFC2317], also known as BCP20, describes a way to delegate the "reverse DNS" (i.e., subdomains of in-addr.arpa.) for IPv4 address ranges with fewer than 256 addresses (i.e., less than a whole /24 prefix). The ALTO Cross-Domain Server Discovery procedure is compatible with this method. In some deployment scenarios, e.g., residential Internet access, where customers often dynamically receive a single IPv4 address (and/or a small IPv6 address block) from a pool of addresses, ISPs typically will not delegate the "reverse DNS" to their customers. This practice makes it impossible for these customers to populate the DNS with NAPTR resource records that point to an ALTO server of their choice. Yet, the ISP may publish NAPTR resource records in the "reverse DNS" for individual addresses or larger address pools (i.e., shorter prefix lengths). While ALTO is by no means technologically tied to the Border Gateway Protocol (BGP), it is anticipated that BGP will be an important source of information for ALTO and that the operator of the outermost BGP-enabled router will have a strong incentive to publish a digest of their routing policies and costs through ALTO. In contrast, an individual user or an organization that has been assigned only a small address range (i.e., an IPv4 prefix with a prefix length longer than /24) will typically connect to the Internet using only a single ISP, and they might not be interested in publishing their own ALTO information. Consequently, they might wish to leave the operation of an ALTO server up to their ISP. This ISP may install NAPTR resource records, which are needed for the ALTO Cross-Domain Server Discovery procedure, in the subdomain of in-addr.arpa. that corresponds to the whole /24 prefix (c.f., R24 in Section 3.3 of this document), even if BCP20-style delegations or no delegations at all are in use. Kiesel & Stiemerling Expires February 21, 2020 [Page 18] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 6. Security Considerations A high-level discussion of security issues related to ALTO is part of the ALTO problem statement [RFC5693]. A classification of unwanted information disclosure risks, as well as specific security-related requirements can be found in the ALTO requirements document [RFC6708]. The remainder of this section focuses on security threats and protection mechanisms for the cross-domain ALTO server discovery procedure as such. Once the ALTO server's URI has been discovered and the communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification [RFC7285] apply. 6.1. Integrity of the ALTO Server's URI Scenario Description An attacker could compromise the ALTO server discovery procedure or the underlying infrastructure in a way that ALTO clients would discover a "wrong" ALTO server URI. Threat Discussion The cross-domain ALTO server discovery procedure relies on a series of DNS lookups, in order to produce one or more URI(s). If an attacker was able to modify or spoof any of the DNS records, the resulting URI(s) could be replaced by forged URI(s). This is probably the most serious security concern related to ALTO server discovery. The discovered "wrong" ALTO server might not be able to give guidance to a given ALTO client at all, or it might give suboptimal or forged information. In the latter case, an attacker could try to use ALTO to affect the traffic distribution in the network or the performance of applications (see also Section 15.1. of [RFC7285]). Furthermore, a hostile ALTO server could threaten user privacy (see also Section 5.2.1, case (5a) in [RFC6708]). Protection Strategies and Mechanisms The application of DNS security (DNSSEC) [RFC4033] provides a means to detect and avert attacks that rely on modification of the DNS records while in transit. All implementations of the cross- domain ALTO server discovery procedure MUST support DNSSEC or be able to use such functionality provided by the underlying operating system. Network operators that publish U-NAPTR resource records to be used for the cross-domain ALTO server discovery procedure SHOULD use DNSSEC to protect their subdomains of in- addr.arpa. and/or ip6.arpa., respectively. Additional operational precautions for safely operating the DNS infrastructure are required in order to ensure that name servers do not sign forged Kiesel & Stiemerling Expires February 21, 2020 [Page 19] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 (or otherwise "wrong") resource records. Security considerations specific to U-NAPTR are described in more detail in [RFC4848]. In addition to active protection mechanisms, users and network operators can monitor application performance and network traffic patterns for poor performance or abnormalities. If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random results, the usage of the ALTO server may be discontinued (see also Section 15.2 of [RFC7285]). Note The cross-domain ALTO server discovery procedure finishes successfully when it has discovered one or more URI(s). Once an ALTO server's URI has been discovered and the communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification [RFC7285] apply. A threat related to the one considered above is the impersonation of an ALTO server after its correct URI has been discovered. This threat and protection strategies are discussed in Section 15.1 of [RFC7285]. The ALTO protocol's primary mechanism for protecting authenticity and integrity (as well as confidentiality) is the use of HTTPS-based transport, i.e., HTTP over TLS [RFC2818]. Typically, when the URI's host component is a host name, a further DNS lookup is needed to map it to an IP address, before the communication with the server can begin. This last DNS lookup (for A or AAAA resource records) does not necessarily have to be protected by DNSSEC, as the server identity checks specified in [RFC2818] are able to detect DNS spoofing or similar attacks, after the connection to the (possibly wrong) host has been established. However, this validation, which is based on the server certificate, can only protect the steps that occur after the server URI has been discovered. It cannot detect attacks against the authenticity of the U-NAPTR lookups needed for the cross-domain ALTO server discovery procedure, and therefore, these resource records have to be secured using DNSSEC. 6.2. Availability of the ALTO Server Discovery Procedure Scenario Description An attacker could compromise the cross-domain ALTO server discovery procedure or the underlying infrastructure in a way that ALTO clients would not be able to discover any ALTO server. Kiesel & Stiemerling Expires February 21, 2020 [Page 20] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Threat Discussion If no ALTO server can be discovered (although a suitable one exists) applications have to make their decisions without ALTO guidance. As ALTO could be temporarily unavailable for many reasons, applications must be prepared to do so. However, The resulting application performance and traffic distribution will correspond to a deployment scenario without ALTO. Protection Strategies and Mechanisms Operators should follow best current practices to secure their DNS and ALTO (see Section 15.5 of [RFC7285]) servers against Denial- of-Service (DoS) attacks. 6.3. Confidentiality of the ALTO Server's URI Scenario Description An unauthorized party could invoke the cross-domain ALTO server discovery procedure, or intercept discovery messages between an authorized ALTO client and the DNS servers, in order to acquire knowledge of the ALTO server URI for a specific IP address. Threat Discussion In the ALTO use cases that have been described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, the ALTO server's URI as such has always been considered as public information that does not need protection of confidentiality. Protection Strategies and Mechanisms No protection mechanisms for this scenario have been provided, as it has not been identified as a relevant threat. However, if a new use case is identified that requires this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly. 6.4. Privacy for ALTO Clients Scenario Description An unauthorized party could eavesdrop on the messages between an ALTO client and the DNS servers, and thereby find out the fact that said ALTO client uses (or at least tries to use) the ALTO service in order to optimize traffic from/to a specific IP address. Threat Discussion In the ALTO use cases that have been described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, this scenario has not been identified as a relevant threat. However, Pervasive Surveillance [RFC7624] and DNS Privacy Kiesel & Stiemerling Expires February 21, 2020 [Page 21] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Considerations [RFC7626] have seen significant attention in the Internet community in recent years. Protection Strategies and Mechanisms DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide means for protecting confidentiality (and integrity) of DNS traffic between a client (stub) and its recursive name servers, including DNS queries and replies caused by the ALTO Cross-Domain Server Discovery Procedure. Kiesel & Stiemerling Expires February 21, 2020 [Page 22] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 7. IANA Considerations This document does not require any IANA action. Kiesel & Stiemerling Expires February 21, 2020 [Page 23] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 8. References 8.1. Normative References [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, . [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [I-D.kiesel-alto-alto4alto] Kiesel, S., "Using ALTO for ALTO server selection", draft-kiesel-alto-alto4alto-00 (work in progress), July 2010. [I-D.kiesel-alto-ip-based-srv-disc] Kiesel, S. and R. Penno, "Application-Layer Traffic Optimization (ALTO) Anycast Address", draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), July 2014. [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, Kiesel & Stiemerling Expires February 21, 2020 [Page 24] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 . [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/ RFC2317, March 1998, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ RFC2818, May 2000, . [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, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, . [RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, September 2012, . [RFC7216] Thomson, M. and R. Bellis, "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS", RFC 7216, DOI 10.17487/RFC7216, April 2014, . [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", Kiesel & Stiemerling Expires February 21, 2020 [Page 25] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 RFC 7285, DOI 10.17487/RFC7285, September 2014, . [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "Application-Layer Traffic Optimization (ALTO) Server Discovery", RFC 7286, DOI 10.17487/RFC7286, November 2014, . [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, . [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [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, . [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "Application-Layer Traffic Optimization (ALTO) Deployment Considerations", RFC 7971, DOI 10.17487/ RFC7971, October 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . Kiesel & Stiemerling Expires February 21, 2020 [Page 26] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Appendix A. Solution Approaches for Partitioned ALTO Knowledge The ALTO base protocol document [RFC7285] specifies the communication between an ALTO client and a single ALTO server. It is implicitly assumed that this server can answer any query, possibly with some kind of default value if no exact data is known. No special provisions were made for the case that the ALTO information originates from multiple sources, which are possibly under the control of different administrative entities (e.g., different ISPs) or that the overall ALTO information is partitioned and stored on several ALTO servers. A.1. Classification of Solution Approaches Various protocol extensions and other solutions have been proposed to deal with multiple information sources and partitioned knowledge. They can be classified as follows: 1 Ensure that all ALTO servers have the same knowledge 1.1 Ensure data replication and synchronization within the provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]). 1.2 Use an Inter-ALTO-server data replication protocol. Possibly, the ALTO protocol itself - maybe with some extensions - could be used for that purpose; however, this has not been studied in detail so far. 2 Accept that different ALTO servers (possibly operated by different organizations, e.g., ISPs) do not have the same knowledge 2.1 Allow ALTO clients to send arbitrary queries to any ALTO server (e.g. the one discovered using [RFC7286]). If this server cannot answer the query itself, it will fetch the data on behalf of the client, using the ALTO protocol or a to-be-defined inter- ALTO-server request forwarding protocol. 2.2 Allow ALTO clients to send arbitrary queries to any ALTO server (e.g. the one discovered using [RFC7286]). If this server cannot answer the query itself, it will redirect the client to the "right" ALTO server that has the desired information, using a small to-be-defined extension of the ALTO protocol. 2.3 ALTO clients need to use some kind of "search engine" that indexes ALTO servers and redirects and/or gives cached results. Kiesel & Stiemerling Expires February 21, 2020 [Page 27] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 2.4 ALTO clients need to use a new discovery mechanism to discover the ALTO server that has the desired information and contact it directly. A.2. Discussion of Solution Approaches The provisioning or initialization protocol for ALTO servers (cf. RFC 5693, Fig 1 [RFC5693]) is currently not standardized. It was a conscious decision not to include this in the scope of the IETF ALTO working group. The reason is that there are many different kinds of information sources. This implementation specific protocol will adapt them to the ALTO server, which offers a standardized protocol to the ALTO clients. However, adding the task of synchronization between ALTO servers to this protocol (i.e., approach 1.1) would overload this protocol with a second functionality that requires standardization for seamless multi-domain operation. For the 1.? solution approaches, in addition to general technical feasibility and issues like overhead and caching efficiency, another aspect to consider is legal liability. Operator "A" might prefer not to publish information about nodes in or paths between the networks of operators "B" and "C" through A's ALTO server, even if A knew that information. This is not only a question of map size and processing load on A's ALTO server. Operator A could also face legal liability issues if that information had a bad impact on the traffic engineering between B's and C's networks, or on their business models. No specific actions to build a "search engine" based solution (approach 2.3) are currently known and it is unclear what could be the incentives to operate such an engine. Therefore, this approach is not considered in the remainder of this document. A.3. The Need for Cross-Domain ALTO Server Discovery Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the specification of an ALTO protocol extension or a new protocol that runs between ALTO servers. A large-scale, maybe Internet-wide, multi-domain deployment would also need mechanisms by which an ALTO server could discover other ALTO servers, learn which information is available where, and ideally also who is authorized to publish information related to a given part of the network. Approach 2.4 needs the same mechanisms, except that they are used on the client- side instead of the server-side. It is sometimes questioned whether there is a need for a solution that allows clients to ask arbitrary queries, even if the ALTO information is partitioned and stored on many ALTO servers. The main Kiesel & Stiemerling Expires February 21, 2020 [Page 28] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 argument is, that clients are supposed to optimize the traffic from and to themselves, and that the information needed for that is most likely stored on a "nearby" ALTO server, i.e., the one that can be discovered using [RFC7286]. However, there are scenarios where the ALTO client is not co-located with an endpoint of the to-be-optimized data transmission. Instead, the ALTO client is located at a third party, which takes part in the application signaling, e.g., a so- called "tracker" in a peer-to-peer application. One such scenario, where it is advantageous to place the ALTO client not at an endpoint of the user data transmission, is analyzed in Appendix C. A.4. Our Solution Approach Several solution approaches for cross-domain ALTO server discovery have been evaluated, using the criteria documented in Appendix B. One of them was to use the ALTO protocol itself for the exchange of information availability [I-D.kiesel-alto-alto4alto]. However, the drawback of that approach is that a new registration administration authority would have to be established. This document specifies a DNS-based procedure for cross-domain ALTO server discovery, which was inspired by "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The primary goal is that this procedure can be used on the client-side (i.e., approach 2.4), but together with new protocols or protocol extensions it could also be used to implement the other solution approaches itemized above. A.5. Relation to the ALTO Requirements During the design phase of the overall ALTO solution, two different server discovery scenarios have been identified and documented in the ALTO requirements document [RFC6708]. The first scenario, documented in Req. AR-32, can be supported using the discovery mechanisms specified in [RFC7286]. An alternative approach, based on IP anycast [I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This document, in contrast, tries to address Req. AR-33. Kiesel & Stiemerling Expires February 21, 2020 [Page 29] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Appendix B. Requirements for Cross-Domain Server Discovery This appendix itemizes requirements that have been collected before the design phase and that are reflected by the design of the ALTO Cross-Domain Server Discovery Procedure. B.1. Discovery Client Application Programming Interface The discovery client will be called through some kind of application programming interface (API) and the parameters will be an IP address and, for purposes of extensibility, a service identifier such as "ALTO". It will return one or more URI(s) that offers the requested service ("ALTO") for the given IP address. In other words, the client would be used to retrieve a mapping: (IP address, "ALTO") -> IRD-URI(s) where IRD-URI(s) is one or more URI(s) of Information Resource Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that can give reasonable guidance to a resource consumer with the indicated IP address. B.2. Data Storage and Authority Requirements The information for mapping IP addresses and service parameters to URIs should be stored in a - preferably distributed - database. It must be possible to delegate administration of parts of this database. Usually, the mapping from a specific IP address to an URI is defined by the authority that has administrative control over this IP address, e.g., the ISP in residential access networks or the IT department in enterprise, university, or similar networks. B.3. Cross-Domain Operations Requirements The cross-domain server discovery mechanism should be designed in such a way that it works across the public Internet and also in other IP-based networks. This in turn means that such mechanisms cannot rely on protocols that are not widely deployed across the Internet or protocols that require special handling within participating networks. An example is multicast, which is not generally available across the Internet. The ALTO Cross-Domain Server Discovery protocol must support gradual deployment without a network-wide flag day. If the mechanism needs some kind of well-known "rendezvous point", re-using an existing infrastructure (such as the DNS root servers or the WHOIS database) should be preferred over establishing a new one. Kiesel & Stiemerling Expires February 21, 2020 [Page 30] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 B.4. Protocol Requirements The protocol must be able to operate across middleboxes, especially across NATs and firewalls. The protocol shall not require any pre-knowledge from the client other than any information that is known to a regular IP host on the Internet. B.5. Further Requirements The ALTO cross domain server discovery cannot assume that the server discovery client and the server discovery responding entity are under the same administrative control. Kiesel & Stiemerling Expires February 21, 2020 [Page 31] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications This appendix provides a complete example of using ALTO and the ALTO Cross-Domain Server Discovery Procedure in one specific application scenario, namely a tracker-based peer-to-peer application. First, in subsection C.1, we introduce a generic model of such an application and show why ALTO optimization is desirable. Then, in C.2, we introduce two architectural options for integrating ALTO into the tracker-based peer-to-peer application - one option is based on the "regular" ALTO server discovery procedure [RFC7286], one relies on the ALTO Cross-Domain Server Discovery Procedure. In C.3, a simple mathematical model is used to show that the latter approach is expected to yield significantly better optimization results. The appendix concludes with subsection C.4, which details an exemplary complete walk-through of the ALTO Cross-Domain Server Discovery Procedure. C.1. A generic Tracker-based Peer-to-Peer Application The optimization of peer-to-peer (P2P) applications such as BitTorrent was one of the first use cases that lead to the inception of the IETF ALTO working group. Further use cases have been identified as well, yet we will use this scenario to illustrate the operation and usefulness of the ALTO Cross-Domain Server Discovery Procedure. For the remainder of this chapter we consider a generic, tracker- based peer-to-peer file sharing application. The goal is the dissemination of a large file, without using one large server with a correspondingly high upload bandwidth. The file is split into chunks. So-called "peers" assume the role of both a client and a server. That is, they may request chunks from other peers and they may serve the chunks they already possess to other peers at the same time, thereby contributing their upload bandwidth. Peers that want to share the same file participate in a "swarm". They use the peer- to-peer protocol to inform each other about the availability of chunks and to request and transfer chunks from one peer to another. A swarm may consist of a very large number of peers. Consequently, peers usually maintain logical connections only to a subset of all peers in the swarm. If a new peer wants to join a swarm, it first contacts a well-known server, the "tracker", which provides a list of IP addresses of peers in the swarm. A swarm is an overlay network on top of the IP network. Algorithms that determine the overlay topology and the traffic distribution in the overlay may consider information about the underlying IP network, such as topological distance, link bandwidth, (monetary) costs for sending traffic from one host to another, etc. ALTO is a protocol Kiesel & Stiemerling Expires February 21, 2020 [Page 32] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 for retrieving such information. The goal of such "topology aware" decisions is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure. C.2. Architectural Options for Placing the ALTO Client The ALTO protocol specification [RFC7285] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. However, in the considered scenario of a tracker-based P2P application, there are two fundamentally different possibilities where to place the ALTO client: 1. ALTO client in the resource consumer ("peer") 2. ALTO client in the resource directory ("tracker") In the following, both scenarios are compared in order to explain the need for ALTO queries on behalf of remote resource consumers. In the first scenario (see Figure 2), the resource consumer queries the resource directory for the desired resource (F1). The resource directory returns a list of potential resource providers without considering ALTO (F2). It is then the duty of the resource consumer to invoke ALTO (F3/F4), in order to solicit guidance regarding this list. In the second scenario (see Figure 4), the resource directory has an embedded ALTO client. After receiving a query for a given resource (F1) the resource directory invokes this ALTO client to evaluate all resource providers it knows (F2/F3). Then it returns a, possibly shortened, list containing the "best" resource providers to the resource consumer (F4). Kiesel & Stiemerling Expires February 21, 2020 [Page 33] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 ............................. ............................. : Tracker : : Peer : : ______ : : : : +-______-+ : : k good : : | | +--------+ : P2P App. : +--------+ peers +------+ : : | N | | random | : Protocol : | ALTO- |------>| data | : : | known |====>| pre- |*************>| biased | | ex- | : : | peers, | | selec- | : transmit : | peer |------>| cha- | : : | M good | | tion | : n peer : | select | n-k | nge | : : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : :...........................: :.....^.....................: | | ALTO protocol __|___ +-______-+ | | | ALTO | | server | +-______-+ Figure 1: Tracker-based P2P Application with random peer preselection Peer w. ALTO cli. Tracker ALTO Server --------+-------- --------+-------- --------+-------- | F1 Tracker query | | |======================>| | | F2 Tracker reply | | |<======================| | | F3 ALTO query | | |---------------------------------------------->| | F4 ALTO reply | | |<----------------------------------------------| | | | ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO protocol Figure 2: Basic message sequence chart for resource consumer- initiated ALTO query Kiesel & Stiemerling Expires February 21, 2020 [Page 34] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 ............................. ............................. : Tracker : : Peer : : ______ : : : : +-______-+ : : : : | | +--------+ : P2P App. : k good peers & +------+ : : | N | | ALTO- | : Protocol : n-k bad peers | data | : : | known |====>| biased |******************************>| ex- | : : | peers, | | peer | : transmit : | cha- | : : | M good | | select | : n peer : | nge | : : +-______-+ +--------+ : IDs : +------+ : :.....................^.....: :...........................: | | ALTO protocol __|___ +-______-+ | | | ALTO | | server | +-______-+ Figure 3: Tracker-based P2P Application with ALTO client in tracker Peer Tracker w. ALTO cli. ALTO Server --------+-------- --------+-------- --------+-------- | F1 Tracker query | | |======================>| | | | F2 ALTO query | | |---------------------->| | | F3 ALTO reply | | |<----------------------| | F4 Tracker reply | | |<======================| | | | | ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO protocol Figure 4: Basic message sequence chart for ALTO query on behalf of remote resource consumer Note: the message sequences depicted in Figure 2 and Figure 4 may occur both in the target-aware and the target-independent query mode (c.f. [RFC6708]). In the target-independent query mode no message exchange with the ALTO server might be needed after the tracker query, because the candidate resource providers could be evaluated using a locally cached "map", which has been retrieved from the ALTO server some time ago. Kiesel & Stiemerling Expires February 21, 2020 [Page 35] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 C.3. Evaluation The problem with the first approach is, that while the resource directory might know thousands of peers taking part in a swarm, the list returned to the resource consumer is usually shortened for efficiency reasons. Therefore, the "best" (in the sense of ALTO) potential resource providers might not be contained in that list anymore, even before ALTO can consider them. For illustration, consider a simple model of a swarm, in which all peers fall into one of only two categories: assume that there are "good" ("good" in the sense of ALTO's better-than-random peer selection, based on an arbitrary desired rating criterion) and "bad' peers only. Having more different categories makes the maths more complex but does not change anything to the basic outcome of this analysis. Assume that the swarm has a total number of N peers, out of which are M "good" and N-M "bad" peers, which are all known to the tracker. A new peer wants to join the swarm and therefore asks the tracker for a list of peers. If, according to the first approach, the tracker randomly picks n peers from the N known peers, the result can be described with the hypergeometric distribution. The probability that the tracker reply contains exactly k "good" peers (and n-k "bad" peers) is: / M \ / N - M \ \ k / \ n - k / P(X=k) = --------------------- / N \ \ n / / n \ n! with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 k! (n-k)! The probability that the reply contains at most k "good" peers is: P(X<=k)=P(X=0)+P(X=1)+..+P(X=k). For example, consider a swarm with N=10,000 peers known to the tracker, out of which M=100 are "good" peers. If the tracker randomly selects n=100 peers, the formula yields for the reply: P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36% this list does not contain a single "good" peer, and with 99% probability there are only four or less of the "good" peers on the Kiesel & Stiemerling Expires February 21, 2020 [Page 36] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 list. Processing this list with the guiding ALTO information will ensure that the few favorable peers are ranked to the top of the list; however, the benefit is rather limited as the number of favorable peers in the list is just too small. Much better traffic optimization could be achieved if the tracker would evaluate all known peers using ALTO, and return a list of 100 peers afterwards. This list would then include a significantly higher fraction of "good" peers. (Note, that if the tracker returned "good" peers only, there might be a risk that the swarm might disconnect and split into several disjunct partitions. However, finding the right mix of ALTO-biased and random peer selection is out of the scope of this document.) Therefore, from an overall optimization perspective, the second scenario with the ALTO client embedded in the resource directory is advantageous, because it is ensured that the addresses of the "best" resource providers are actually delivered to the resource consumer. An architectural implication of this insight is that the ALTO server discovery procedures must support ALTO queries on behalf of remote resource consumers. That is, as the tracker issues ALTO queries on behalf of the peer which contacted the tracker, the tracker must be able to discover an ALTO server that can give guidance suitable for that respective peer. This task can be solved using the ALTO Cross- Domain Server Discovery Procedure. Kiesel & Stiemerling Expires February 21, 2020 [Page 37] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 C.4. Example This section provides a complete example of the ALTO Cross-Domain Server Discovery Procedure in a tracker-based peer-to-peer scenario. The example is based on the network topology shown in Figure 5. Five access networks - Networks a, b, c, x, and t - are operated by five different network operators. They are interconnected by a backbone structure. Each network operator runs an ALTO server in their network, i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and ALTO_SRV_T, respectively. _____ __ _____ __ _____ __ __( )__( )_ __( )__( )_ __( )__( )_ ( Network a ) ( Network b ) ( Network c ) ( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C ) (__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __) (___)--(____) \ (___)--(____) / (___)--(____) \ / / ---+---------+-----------------+---- ( Backbone ) ------------+------------------+---- _____ __/ _____ \__ __( )__( )_ __( )__( )_ ( Network x ) ( Network t ) ( Res. Consumer X ) (Resource Directory) (_ ALTO_SRV_X __) (_ ALTO_SRV_T __) (___)--(____) (___)--(____) Figure 5: Example network topology A new peer of a peer-to-peer application wants to join a specific swarm (overlay network), in order to access a specific resource. This new peer will be called "Resource Consumer X" in accordance to the terminology of [RFC6708] and it is located in Network x. It contacts the tracker ("Resource Directory"), which is located in Network t. The mechanism by which the new peer discovers the tracker is out of the scope of this document. The tracker maintains a list of peers that take part in the overlay network, and hence it can determine that Resource Providers A, B, and C are candidate peers for Resource Consumer X. As shown in the previous section, a tracker-side ALTO optimization (c.f. Figure 3 and Figure 4) is more efficient than a client-side optimization. Consequently, the tracker wants to use the ALTO Endpoint Cost Service (ECS) to learn the routing costs between X and A, X and B, as well as X and C, in order to sort A, B, and C by their respective routing costs to X. Kiesel & Stiemerling Expires February 21, 2020 [Page 38] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 In theory, there are many options how the ALTO Cross-Domain Server Discovery Procedure could be used. For example, the tracker could do the following steps: IRD_URIS_A = XDOMDISC(A,"ALTO:https") COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A IRD_URIS_B = XDOMDISC(B,"ALTO:https") COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B IRD_URIS_C = XDOMDISC(C,"ALTO:https") COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C Maybe, the ALTO Cross-Domain Server Discovery Procedure queries would yield in this scenario: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. That is, each ECS query would be sent to a different ALTO server. The problem with this approach is that we are not neccessarily able to compare COST_X_A, COST_X_B, and COST_X_C with each other. The specification of the routingcost metric mandates that "A lower value indicates a higher preference", but "an ISP may internally compute routing cost using any method that it chooses" (see section 6.1.1.1. of [RFC7285]). Thus, COST_X_A could be 10 (milliseconds round-trip time), while COST_X_B could be 200 (kilometers great circle distance between the approximate geographic locations of the hosts) and COST_X_C could be 3 (router hops, corresponding to a decrease of the TTL field in the IP header). Each of these metrics fulfills the "lower value is more preferable" requirement on its own, but obviously, they cannot be compared with each other. Even if there was a reasonable formula to compare, for example, kilometers with milliseconds, we could not use it, as the units of measurement (or any other information about the computation method for the routingcost) are not sent along with the value in the ECS reply. To avoid this problem, the tracker tries to send all ECS queries to the same ALTO server. As specified in Section 4.4 of this document, case 2, it uses the IP address of Resource Consumer x as parameter to the discovery procedure: IRD_URIS_X = XDOMDISC(X,"ALTO:https") COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be compared with each other. Kiesel & Stiemerling Expires February 21, 2020 [Page 39] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 As discussed above, the tracker calls the ALTO Cross-Domain Server Discovery Procedure with IP address X as a parameter. For the reminder of this example, we assume that X = 2001:DB8:1:2:227:eff: fe6a:de42. Thus, the procedure call is IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https"). The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6 address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42, L = 128, and SP = "ALTO:https". The procedure constructs (see Step 1 in Section 3.2) R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0. 8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3) R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". In order to illustrate the third step of the ALTO Cross-Domain Server Discovery Procedure, we use the "dig" (domain information groper) DNS lookup utility that is available for many operating systems (e.g., Linux). A real implementation of the ALTO Cross-Domain Server Discovery Procedure would not be based on the "dig" utility, but use appropriate libraries and/or operating system APIs. Please note that the following steps have been performed in a controlled lab environment with a appropriately configured name server. A suitable DNS configuration will be needed to reproduce these results. Please also note that the rather verbose output of the "dig" tool has been shortened to the relevant lines. Since AT = IPv6 and L = 128, in the table given in Section 3.4, the sixth row (not counting the column headers) applies. As mandated by the third column, we start with a lookup of R128, looking for NAPTR resource records: | user@labpc:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\ | 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 The domain name R128 does not exist (status: NXDOMAIN), so we cannot get a useful result. Therefore, we continue with the fourth column of the table and do a lookup of R64: Kiesel & Stiemerling Expires February 21, 2020 [Page 40] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 | user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 The domain name R64 could be looked up (status: NOERROR), but there are no NAPTR resource records associated with it (ANSWER: 0). Maybe, there are some other resource records such as PTR, NS, or SOA, but we are not interested in them. Thus, we do not get a useful result and we continue with looking up R56: | user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | | ;; ANSWER SECTION: | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" | "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" . | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u" | "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" . The domain name R56 could be looked up and there are NAPTR resource records associated with it. However, each of these records has a service parameter that does not match our SP = "ALTO:https" (see [RFC7216] for "LIS:HELD"), and therefore, we have to ignore them. Consequently, we still do not have a useful result and continue with a lookup of R48: | user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | | ;; ANSWER SECTION: | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" | "ALTO:https" "!.*!https://alto1.example.net/ird!" . | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" | "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" . This lookup yields two NAPTR resource records. We have to ignore the second one as its service parameter does not match our SP, but the first NAPTR resource record has a matching service parameter. Therefore, the procedure terminates successfully and the final outcome is: IRD_URIS_X = "https://alto1.example.net/ird". Kiesel & Stiemerling Expires February 21, 2020 [Page 41] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 The ALTO client that is embedded in the tracker will access the ALTO Information Resource Directory (IRD, see Section 9 of [RFC7285]) at this URI, look for the Endpoint Cost Service (ECS, see Section 11.5 of [RFC7285]), and query the ECS for the costs between A and X, B and X, as well as C and X, before returning an ALTO-optimized list of candidate resource providers to resource consumer X. Kiesel & Stiemerling Expires February 21, 2020 [Page 42] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Appendix D. Contributors List and Acknowledgments The initial version of this document was co-authored by Marco Tomsu (Alcatel-Lucent). This document borrows some text from [RFC7286], as historically, it has been part of the draft that eventually became said RFC. Special thanks to Michael Scharf and Nico Schwan. Kiesel & Stiemerling Expires February 21, 2020 [Page 43] Internet-Draft ALTO Cross-Domain Server Discovery August 2019 Authors' Addresses Sebastian Kiesel University of Stuttgart Information Center Allmandring 30 Stuttgart 70550 Germany Email: ietf-alto@skiesel.de URI: http://www.izus.uni-stuttgart.de Martin Stiemerling University of Applied Sciences Darmstadt, Computer Science Dept. Haardtring 100 Darmstadt 64295 Germany Phone: +49 6151 16 37938 Email: mls.ietf@gmail.com URI: http://ietf.stiemerling.org Kiesel & Stiemerling Expires February 21, 2020 [Page 44] ./draft-ietf-iasa2-rfc7437bis-09.txt0000644000764400076440000026416713511732355016200 0ustar iustyiusty Network Working Group M. Kucherawy, Ed. Internet-Draft Obsoletes: 7437, 8318 (if approved) R. Hinden, Ed. Intended status: Best Current Practice Check Point Software Expires: January 12, 2020 J. Livingood, Ed. Comcast July 11, 2019 IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees draft-ietf-iasa2-rfc7437bis-09 Abstract The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF LLC are selected, confirmed, and recalled is specified in this document. This document is based on RFC7437. Only those updates required to reflect the changes introduced by IASA 2.0 have been included. Any other changes will be addressed in future documents. This document obsoletes RFC7437 and RFC8318. 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 12, 2020. Copyright Notice Copyright (c) 2019 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 Kucherawy, et al. Expires January 12, 2020 [Page 1] Internet-Draft NomCom July 2019 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Completion Due . . . . . . . . . . . . . . . . . . . . . 6 3.2. Nominating Committee Principal Functions . . . . . . . . 7 3.3. Positions To Be Reviewed . . . . . . . . . . . . . . . . 7 3.4. Term Lengths . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Mid-term Vacancies . . . . . . . . . . . . . . . . . . . 9 3.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 3.7. Advice and Consent Model . . . . . . . . . . . . . . . . 11 3.7.1. Positions To Be Reviewed . . . . . . . . . . . . . . 11 3.7.2. Candidate Selection . . . . . . . . . . . . . . . . . 11 3.7.3. Candidate Review . . . . . . . . . . . . . . . . . . 11 3.7.4. Confirmation . . . . . . . . . . . . . . . . . . . . 12 3.8. Sitting Members, Directors and Trustees . . . 12 3.9. Announcements . . . . . . . . . . . . . . . . . . . . . . 13 4. Nominating Committee Selection . . . . . . . . . . . . . . . 14 4.1. Timeline . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Term . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Structure . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Chair Duties . . . . . . . . . . . . . . . . . . . . . . 16 4.5. Chair Selection . . . . . . . . . . . . . . . . . . . . . 16 4.6. Temporary Chair . . . . . . . . . . . . . . . . . . . . . 16 4.7. Liaisons . . . . . . . . . . . . . . . . . . . . . . . . 17 4.8. Liaison Appointment . . . . . . . . . . . . . . . . . . . 17 4.9. Advisors . . . . . . . . . . . . . . . . . . . . . . . . 18 4.10. Past Chair . . . . . . . . . . . . . . . . . . . . . . . 18 4.11. Voting Volunteers . . . . . . . . . . . . . . . . . . . . 18 4.12. Milestones . . . . . . . . . . . . . . . . . . . . . . . 19 4.13. Open Positions . . . . . . . . . . . . . . . . . . . . . 19 4.14. Volunteer Qualification . . . . . . . . . . . . . . . . . 19 4.15. Not Qualified . . . . . . . . . . . . . . . . . . . . . . 20 4.16. Selection Process . . . . . . . . . . . . . . . . . . . . 20 4.17. Announcement of Selection Results . . . . . . . . . . . . 21 4.18. Committee Organization . . . . . . . . . . . . . . . . . 22 5. Nominating Committee Operation . . . . . . . . . . . . . . . 22 5.1. Discretion . . . . . . . . . . . . . . . . . . . . . . . 23 5.2. Selection Timeline . . . . . . . . . . . . . . . . . . . 23 Kucherawy, et al. Expires January 12, 2020 [Page 2] Internet-Draft NomCom July 2019 5.3. Confirmation Timeline . . . . . . . . . . . . . . . . . . 23 5.4. Milestones . . . . . . . . . . . . . . . . . . . . . . . 23 5.5. Voting Mechanism . . . . . . . . . . . . . . . . . . . . 24 5.6. Voting Quorum . . . . . . . . . . . . . . . . . . . . . . 24 5.7. Voting Member Recall . . . . . . . . . . . . . . . . . . 24 5.8. Chair Recall . . . . . . . . . . . . . . . . . . . . . . 25 5.9. Deliberations . . . . . . . . . . . . . . . . . . . . . . 25 5.10. Call for Nominees . . . . . . . . . . . . . . . . . . . . 25 5.11. Nominations . . . . . . . . . . . . . . . . . . . . . . . 26 5.12. Candidate Selection . . . . . . . . . . . . . . . . . . . 26 5.13. Consent to Nomination . . . . . . . . . . . . . . . . . . 27 5.14. Notifying Confirming Bodies . . . . . . . . . . . . . . . 27 5.15. Confirming Candidates . . . . . . . . . . . . . . . . . . 28 5.16. Archives . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Dispute Resolution Process . . . . . . . . . . . . . . . . . 28 7. Member, Trustee, and Director Recall . . . . . . . . . . . . 30 7.1. Petition . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1.1. Community Petition . . . . . . . . . . . . . . . . . 30 7.1.2. Ombudsteam Petition . . . . . . . . . . . . . . . . . 31 7.2. Recall Committee Chair . . . . . . . . . . . . . . . . . 31 7.3. Recall Committee Creation . . . . . . . . . . . . . . . . 31 7.4. Recall Committee Rules . . . . . . . . . . . . . . . . . 31 7.5. Recall Committee Operation . . . . . . . . . . . . . . . 31 7.6. 3/4 Majority . . . . . . . . . . . . . . . . . . . . . . 31 7.7. Position To Be Filled . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Changes Since RFC 3777 . . . . . . . . . . . . . . . 33 Appendix B. Changes Since RFC 7437 . . . . . . . . . . . . . . . 34 Appendix C. Oral Tradition . . . . . . . . . . . . . . . . . . . 35 Appendix D. Nominating Committee Timeline . . . . . . . . . . . 35 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 38 Appendix F. Change log [RFC Editor: Please remove] . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction This document is a revision of [RFC7437] that updates it to be consistent with the IETF Administrative Support Activity (IASA) 2.0 changes. RFC 7437 was based on [RFC3777] that consolidated and updated other RFCs that updated that document into a single specification. The result is a complete specification of the process by which members of the Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG), some Trustees of the IETF Kucherawy, et al. Expires January 12, 2020 [Page 3] Internet-Draft NomCom July 2019 Trust, and some Directors of the IETF Administration LLC (IETF LLC), are selected, confirmed, and recalled. This revision addresses only the changes required for IASA 2.0; should the community agree on other changes, they will be addressed in future documents. Section 2 of [I-D.ietf-iasa2-trust-update] provides further details about the IETF Trust Trustees positions that are filled by the IETF Nominating Committee (NomCom). Section 5 of [I-D.ietf-iasa2-rfc4071bis] provides further details about the IETF LLC Director positions that are filled by the NomCom. The following two assumptions continue to be true of this specification: 1. The Internet Research Task Force (IRTF) and Internet Research Steering Group (IRSG) are not a part of the process described here. 2. The organization (and reorganization) of the IESG is not a part of the process described here. The time frames specified here use IETF meetings as a frame of reference. The time frames assume that the IETF meets three times per calendar year with approximately equal amounts of time between them. The meetings are referred to as the First IETF, Second IETF, or Third IETF as needed. The next section lists the words and phrases commonly used throughout this document with their intended meaning. The majority of this document is divided into four major topics as follows: General: This is a set of rules and constraints that apply to the selection and confirmation process as a whole. Nominating Committee Selection: This is the process by which the volunteers who will serve on the NomCom are selected. Nominating Committee Operation: This is the set of principles, rules, and constraints that guide the activities of the NomCom, including the confirmation process. Member, Trustee, and Director Recall: This is the process by which the behavior of a sitting member of the IESG, or IAB, IETF Trust Kucherawy, et al. Expires January 12, 2020 [Page 4] Internet-Draft NomCom July 2019 Trustee, or IETF LLC Director may be questioned, perhaps resulting in the removal of the sitting member. See Section 2 for a description of what a sitting member means for each of these groups. A final section describes how this document differs from [RFC3777] and [RFC7437]. An appendix of useful facts and practices collected from previous NomComs is also included. This document updates the IAB, IESG, and IAOC Selection, Confirmation, and Recall Process to be aligned with IASA 2.0 Model [I-D.ietf-iasa2-rfc4071bis] that creates a IETF Administration Limited Liability Company ("IETF LLC") managed by a Board of Directors ("IETF LLC Board"). This document obsoletes [RFC7437] and [RFC8318]. 2. Definitions The following words and phrases are commonly used throughout this document. They are listed here with their intended meaning for the convenience of the reader. Candidate: A nominee who has been selected to be considered for confirmation by a confirming body. Confirmed Candidate: A candidate that has been reviewed and approved by a confirming body. Nominating Committee Term: The term begins when its members are officially announced, which is expected to be prior to the Third IETF to ensure it is fully operational at the Third IETF. The term ends at the Third IETF (not three meetings) after the next NomCom's term begins. IETF Executive Director: The person charged with day-to-day operation of the IETF's administrative functions. (See Section 4.1 of [I-D.ietf-iasa2-rfc4071bis]). Note: This was previously the name of the IETF Secretariat position that is now called the "Managing Director, IETF Secretariat". Managing Director, IETF Secretariat: The person charged with operation of the IETF Secretariat function. (See Section 2 of [RFC3710] and [I-D.ietf-iasa2-consolidated-upd]). Kucherawy, et al. Expires January 12, 2020 [Page 5] Internet-Draft NomCom July 2019 Nominee: A person who is being or has been considered for one or more open positions of the IESG, IAB, IETF Trust Trustee or IETF LLC. Sitting Member: A person who is currently serving as a member of the IESG or IAB. Sitting Director: A person who is currently serving as a Director of the IETF LLC. Sitting IETF Trust Trustee: A person who is currently serving as a Trustee of the IETF Trust. 3. General The following set of rules apply to the process as a whole. If necessary, a paragraph discussing the interpretation of each rule is included. 3.1. Completion Due The completion of the annual process is due within seven months. The completion of the annual process is due one month prior to the Friday of the week before the First IETF. It is expected to begin at least eight months prior to the Friday of the week before the First IETF. The process officially begins with the announcement of the Chair of the committee. The process officially ends when all confirmed candidates have been announced. The annual process is comprised of three major components as follows: 1. The selection and organization of the NomCom members. 2. The selection of candidates by the NomCom. 3. The confirmation of the candidates. There is an additional month set aside between when the annual process is expected to end and the term of the new candidates is to begin. This time may be used during unusual circumstances to extend the time allocated for any of the components listed above. Kucherawy, et al. Expires January 12, 2020 [Page 6] Internet-Draft NomCom July 2019 3.2. Nominating Committee Principal Functions The principal functions of the NomCom are to review each open IESG, IAB, IETF Trust, and IETF LLC Director position and to select either its incumbent or a superior candidate. Although there is no term limit for serving in any IESG, IAB, or IETF Trust position, the NomCom may use length of service as one of its criteria for evaluating an incumbent. The NomCom does not select the open positions to be reviewed; it is instructed as to which positions to review. The NomCom will be given the titles of the positions to be reviewed and a brief summary of the desired expertise of the candidate that is selected to fill each position. Incumbents must notify the NomCom if they wish to be nominated. The NomCom does not confirm its candidates; it presents its candidates to the appropriate confirming body as indicated below. A superior candidate is one who the NomCom believes would contribute in such a way as to improve or enhance the body to which he or she is nominated. 3.3. Positions To Be Reviewed Approximately one-half of each of the then current IESG and IAB positions, one IETF Trust position, and one IETF LLC Director position, is selected to be reviewed each year. The intent of this rule is to ensure the review of approximately one- half of each of the IESG and IAB sitting members, one of the three NomCom nominated IETF LLC Director positions, and one of the three nominated IETF Trust Trustee positions, each year. It is recognized that circumstances may exist that will require the NomCom to review more or less than the usual number of positions, e.g., if the IESG, IAB, IETF Trust, or IETF LLC Board have reorganized prior to this process and created new positions, if there are an odd number of current positions, or if a member, a director, or a trustee unexpectedly resigns. 3.4. Term Lengths Confirmed IESG and IAB candidates are expected to serve at least a two-year term. The intent of this rule is to ensure that members of Kucherawy, et al. Expires January 12, 2020 [Page 7] Internet-Draft NomCom July 2019 the IESG and IAB serve the number of years that best facilitates the review of one-half of the members each year. Confirmed IETF LLC Director candidates are expected to serve at least a three-year term, except if a nominating or selection body decides to use a shorter term to allow for initial staggered appointments. Please refer to Section 6 of [I-D.ietf-iasa2-rfc4071bis] for additional guidance on term length and term limits for the IETF LLC Board. Confirmed IETF Trust Trustee candidates are expected to serve at least a three-year term, except if a nominating or selection body decides to use a shorter term to allow for initial staggered appointments. Please refer to Section 2. of [I-D.ietf-iasa2-trust-update] for additional guidance on term length and term limits for the IETF Trust. The term of a confirmed candidate selected according to the mid-term vacancy rules may be less than a full term (two years for IESG and IAB, three years for the IETF Trust and IETF LLC), as stated elsewhere in this document. It is consistent with this rule for the NomCom to choose one or more of the currently open positions to which it may assign a term of not more than three years in order to ensure the ideal application of this rule in the future. It is consistent with this rule for the NomCom to choose one or more of the currently open positions that share responsibilities with other positions (both those being reviewed and those sitting) to which it may assign a term of not more than three years to ensure that all such members, directors, or trustees will not be reviewed at the same time. All sitting member terms end during the First IETF meeting corresponding to the end of the term for which they were confirmed. All confirmed candidate terms begin during the First IETF meeting corresponding to the beginning of the term for which they were confirmed. For confirmed candidates of the IESG, the terms begin no later than when the currently sitting members' terms end on the last day of the meeting. A term may begin or end no sooner than the first day of the meeting and no later than the last day of the meeting as determined by the mutual agreement of the currently sitting member and the confirmed candidate. A confirmed candidate's term may overlap the sitting member's term during the meeting as determined by their mutual agreement. Kucherawy, et al. Expires January 12, 2020 [Page 8] Internet-Draft NomCom July 2019 For confirmed candidates of the IAB, the terms overlap with the terms of the sitting members for the entire week of the meeting. For confirmed Trustee candidates of the IETF Trust, the term begins at the next IETF Trust meeting or as dictated by the policies and procedures of the IETF Trust. For confirmed Director candidates of the IETF LLC, the term begins at the next appropriate IETF LLC Board meeting or as dictated by the policies and procedures of the IETF LLC Board. For candidates confirmed under the mid-term vacancy rules, the term begins as soon as possible after the confirmation. 3.5. Mid-term Vacancies Mid-term vacancies are filled by the same rules as documented here with four qualifications, namely: 1. When there is only one official NomCom, the body with the mid- term vacancy relegates the responsibility to fill the vacancy to it. If the mid-term vacancy occurs during the period of time that the term of the prior year's NomCom overlaps with the term of the current year's NomCom, the body with the mid-term vacancy must relegate the responsibility to fill the vacancy to the prior year's NomCom. 2. If it is the case that the NomCom is reconvening to fill the mid- term vacancy, then the completion of the candidate selection and confirmation process is due within six weeks, with all other time periods otherwise unspecified prorated accordingly. 3. The confirming body has two weeks from the day it is notified of a candidate to reject the candidate, otherwise the candidate is assumed to have been confirmed. 4. The term of the confirmed candidate will be either: A. the remainder of the term of the open position if that remainder is not less than one year or B. the remainder of the term of the open position plus the next two-year term for IESG and IAB positions or three-year term for IETF LLC Director and IETF Trust positions if that remainder is less than one year. In both cases, a year is the period of time from a First IETF meeting to the next First IETF meeting. Kucherawy, et al. Expires January 12, 2020 [Page 9] Internet-Draft NomCom July 2019 3.6. Confidentiality All deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential. The NomCom and confirming body members will be exposed to confidential information as a result of their deliberations, their interactions with those they consult, and from those who provide requested supporting information. All members and all other participants are expected to handle this information in a manner consistent with its sensitivity. It is consistent with this rule for current NomCom members who have served on prior NomComs to advise the current committee on deliberations and results of the prior committee, as necessary and appropriate. The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees. The list of nominees disclosed for a specific position should contain only the names of nominees who are willing to be considered for the position under review. The NomCom may choose not to include some names in the disclosed list, at their discretion. The NomCom may disclose an updated list, at its discretion. For example, the NomCom might disclose an updated list if it identifies errors/omissions in a previously disclosed version of the disclosed list, or if the NomCom finds it necessary to call for additional nominees, and these nominees indicate a willingness to be considered before the NomCom has completed its deliberations. Nominees may choose to ask people to provide feedback to the NomCom but should not encourage any public statements of support. NomComs should consider nominee-encouraged lobbying and campaigning to be unacceptable behavior. IETF community members are encouraged to provide feedback on nominees to the NomCom but should not post statements of support/non-support for nominees in any public forum. Kucherawy, et al. Expires January 12, 2020 [Page 10] Internet-Draft NomCom July 2019 3.7. Advice and Consent Model Unless otherwise specified, the advice and consent model is used throughout the process. This model is characterized as follows. 3.7.1. Positions To Be Reviewed The chair of the IESG, IAB, IETF Trust and IETF LLC Board each informs the NomCom of their respective positions to be reviewed. The IESG, IAB, IETF Trust and IETF LLC are responsible for providing a summary of the expertise desired of the candidates selected for their respective open positions. The summaries are provided to the NomCom for its consideration. 3.7.2. Candidate Selection The NomCom selects candidates based on its understanding of the IETF community's consensus of the qualifications required and advises each confirming body of its respective candidates. 3.7.3. Candidate Review The confirming bodies review their respective candidates, they may at their discretion communicate with the NomCom, and then consent to some, all, or none of the candidates. The sitting IAB members review the IESG candidates. The Internet Society Board of Trustees reviews the IAB candidates. The sitting IESG members review the IETF Trust Trustee candidates. The IETF LLC Director candidate is reviewed as specified in [I-D.ietf-iasa2-rfc4071bis]. The confirming bodies conduct their review using all information and any means acceptable to them, including but not limited to the supporting information provided by the NomCom, information known personally to members of the confirming bodies and shared within the confirming body, the results of interactions within the confirming bodies, and the confirming bodies' interpretation of what is in the best interests of the IETF community. If all of the candidates are confirmed, the job of the NomCom with respect to those open positions is complete. Kucherawy, et al. Expires January 12, 2020 [Page 11] Internet-Draft NomCom July 2019 If some or none of the candidates submitted to a confirming body are confirmed, the confirming body should communicate with the NomCom both to explain the reason why all the candidates were not confirmed and to understand the NomCom's rationale for its candidates. The confirming body may reject individual candidates, in which case the NomCom must select alternate candidates for the rejected candidates. Any additional time required by the NomCom should not exceed its maximum time allotment. 3.7.4. Confirmation A confirming body decides whether it confirms each candidate using a confirmation decision rule chosen by the confirming body. If a confirming body has no specific confirmation decision rule, then confirming a given candidate should require at least one-half of the confirming body's sitting members to agree to that confirmation. The decision may be made by conducting a formal vote, by asserting consensus based on informal exchanges (e.g., email), or by any other mechanism that is used to conduct the normal business of the confirming body. Regardless of which decision rule the confirming body uses, any candidate that is not confirmed under that rule is considered to be rejected. The confirming body must make its decision within a reasonable time frame. The results from the confirming body must be reported promptly to the NomCom. 3.8. Sitting Members, Directors and Trustees The following rules apply to nominees and candidates who are currently sitting members of the IESG or IAB, IETF Trust Trustees, or IETF LLC Directors and who are not sitting in an open position being filled by the NomCom. The confirmation of a candidate to an open position does not automatically create a vacancy in the IESG, IAB, IETF Trust, or IETF LLC Board position currently occupied by the candidate. The mid-term vacancy cannot exist until, first, the candidate formally resigns from the current position and, second, the body with the vacancy formally decides for itself that it wants the NomCom to fill the mid- Kucherawy, et al. Expires January 12, 2020 [Page 12] Internet-Draft NomCom July 2019 term vacancy according to the rules for a mid-term vacancy documented elsewhere in this document. The resignation should be effective as of when the term of the new position begins. The resignation may remain confidential to the IESG, IAB, IETF Trust, IETF LLC Board, and NomCom until the confirmed candidate is announced for the new position. The process, according to rules set out elsewhere in this document, of filling the seat vacated by the confirmed candidate may begin as soon as the vacancy is publicly announced. Filling a mid-term vacancy is a separate and independent action from the customary action of filling open positions. In particular, a NomCom must complete its job with respect to filling the open positions and then separately proceed with the task of filling the mid-term vacancy according to the rules for a mid-term vacancy documented elsewhere in this document. However, the following exception is permitted in the case where the candidate for an open position is currently a sitting member of the IAB. It is consistent with these rules for the announcements of a resignation of a sitting member of the IAB and of the confirmed candidate for the mid-term vacancy created by that sitting member on the IAB to all occur at the same time as long as the actual sequence of events that occurred did so in the following order: 1. The NomCom completes the advice and consent process for the open position being filled by the candidate currently sitting on the IAB. 2. The newly confirmed candidate resigns from their current position on the IAB. 3. The IAB Chair (or the Managing Director, IETF Secretariat, if no Chair has been named or the vacancy was created via the departure of the IAB Chair) informs the NomCom of the mid-term vacancy. 4. The NomCom acts on the request to fill the mid-term vacancy. 3.9. Announcements All announcements must be made using at least the mechanism used by the IETF Secretariat for its announcements, including a notice on the IETF web site. As of the publication of this document, the current mechanism is an email message to both the "ietf" and the "ietf-announce" mailing lists. Kucherawy, et al. Expires January 12, 2020 [Page 13] Internet-Draft NomCom July 2019 4. Nominating Committee Selection The following set of rules apply to the creation of the NomCom and the selection of its members. 4.1. Timeline The completion of the process of selecting and organizing the members of the NomCom is due within three months. The completion of the selection and organization process is due at least one month prior to the Third IETF. This ensures the NomCom is fully operational and available for interviews and consultation during the Third IETF. 4.2. Term The term of a NomCom is expected to be 15 months. It is the intent of this rule that the end of a NomCom's term overlap by approximately three months the beginning of the term of the next NomCom. The term of a NomCom begins when its members are officially announced. The term ends at the Third IETF (not three meetings), i.e., the IETF meeting after the next NomCom's term begins. A term is expected to begin at least two months prior to the Third IETF to ensure the NomCom has at least one month to get organized before preparing for the Third IETF. A NomCom is expected to complete any work in progress before it is dissolved at the end of its term. During the period of time when the terms of the NomComs overlap, all mid-term vacancies are to be relegated to the prior year's NomCom. The prior year's NomCom has no other responsibilities during the overlap period. At all times other than the overlap period, there is exactly one official NomCom and it is responsible for all mid-term vacancies. When the prior year's NomCom is filling a mid-term vacancy during the period of time that the terms overlap, the NomCom operate independently. However, some coordination is needed between them. Since the prior year's Chair is a non-voting advisor to the current NomCom, the coordination is expected to be straightforward. Kucherawy, et al. Expires January 12, 2020 [Page 14] Internet-Draft NomCom July 2019 4.3. Structure The NomCom comprises at least a Chair, 10 voting volunteers, two liaisons, and an advisor. Any committee member may propose the addition of an advisor to participate in some or all of the deliberations of the committee. The addition must be approved by the committee according to its established voting mechanism. Advisors participate as individuals. Committee members are encouraged to propose the addition of advisor(s) who are knowledgeable about the operations of the IETF Trust and/or IETF LLC Board, whether or not that NomCom is reviewing an IETF Trust Trustee or IETF LLC Director position. The NomCom may choose to ask the IETF Trust and/or IETF LLC Board to suggest advisors who are knowledgeable about their operations but may select any advisor they vote to approve. Any committee member may propose the addition of a liaison from other unrepresented organizations to participate in some or all of the deliberations of the committee. The addition must be approved by the committee according to its established voting mechanism. Liaisons participate as representatives of their respective organizations. The Chair is selected according to rules stated elsewhere in this document. The 10 voting volunteers are selected according to rules stated elsewhere in this document. The IESG and IAB liaisons are selected according to rules stated elsewhere in this document. The Internet Society Board of Trustees may appoint a liaison to the NomCom at its own discretion. The IETF Trust may appoint a liaison to the NomCom at its own discretion. The IETF LLC Board may appoint a liaison to the NomCom at its own discretion. The Chair of the prior year's NomCom serves as an advisor according to rules stated elsewhere in this document. The Chair, liaisons, and advisors do not vote on the selection of candidates. They do vote on all other issues before the committee unless otherwise specified in this document. Kucherawy, et al. Expires January 12, 2020 [Page 15] Internet-Draft NomCom July 2019 4.4. Chair Duties The Chair of the NomCom is responsible for ensuring the NomCom completes its assigned duties in a timely fashion and performs in the best interests of the IETF community. The Chair must be thoroughly familiar with the rules and guidance indicated throughout this document. The Chair must ensure the NomCom completes its assigned duties in a manner that is consistent with this document. The Chair must attest by proclamation at a plenary session of the First IETF that the results of the committee represent its best effort and the best interests of the IETF community. The Chair does not vote on the selection of candidates. 4.5. Chair Selection The Internet Society President appoints the Chair, who must meet the same requirements for membership in the NomCom as a voting volunteer. The NomCom Chair must agree to invest the time necessary to ensure that the NomCom completes its assigned duties and to perform in the best interests of the IETF community in that role. The appointment is due no later than the Second IETF meeting to ensure it can be announced during a plenary session at that meeting. The completion of the appointment is necessary to ensure the annual process can complete at the time specified elsewhere in this document. 4.6. Temporary Chair A Chair, in consultation with the Internet Society President, may appoint a temporary substitute for the Chair position. There are a variety of ordinary circumstances that may arise from time to time that could result in a Chair being unavailable to oversee the activities of the committee. The Chair, in consultation with the Internet Society President, may appoint a substitute from a pool comprised of the liaisons currently serving on the committee and the prior year's Chair or designee. Any such appointment must be temporary and does not absolve the Chair of any or all responsibility for ensuring the NomCom completes its assigned duties in a timely fashion. Kucherawy, et al. Expires January 12, 2020 [Page 16] Internet-Draft NomCom July 2019 4.7. Liaisons Liaisons are responsible for ensuring the NomCom in general and the Chair in particular execute their assigned duties in the best interests of the IETF community. Liaisons are expected to represent the views of their respective organizations during the deliberations of the committee. They should provide information as requested or when they believe it would be helpful to the committee. Liaisons are expected to provide information to the NomCom regarding the operation, responsibility, and composition of their respective bodies. Liaisons are expected to convey questions from the committee to their respective organizations and responses to those questions to the committee, as requested by the committee. Liaisons are expected to review the operation and executing process of the NomCom and to report any concerns or issues to the Chair of the NomCom immediately. If they cannot resolve the issue between themselves, liaisons must report it according to the dispute resolution process stated elsewhere in this document. Liaisons from confirming bodies are expected to assist the committee in preparing the testimony it is required to provide with its candidates. Liaisons may have other NomCom responsibilities as required by their respective organizations or requested by the NomCom, except that such responsibilities may not conflict with any other provisions of this document. Liaisons do not vote on the selection of candidates. 4.8. Liaison Appointment The sitting IAB and IESG members each appoint a liaison from their current membership, someone who is not sitting in an open position, to serve on the NomCom. The sitting IETF Trust Trustees and IETF LLC Directors each may appoint a liaison from their current membership, someone who is not sitting in an open position, to serve on the NomCom. Kucherawy, et al. Expires January 12, 2020 [Page 17] Internet-Draft NomCom July 2019 4.9. Advisors An advisor is responsible for such duties as specified by the invitation that resulted in the appointment. Advisors do not vote on the selection of candidates. 4.10. Past Chair The Chair of the prior year's NomCom serves as an advisor to the current committee. The prior year's Chair is expected to review the actions and activities of the current Chair and to report any concerns or issues to the NomCom Chair immediately. If they cannot resolve the issue between themselves, the prior year's Chair must report it according to the dispute resolution process stated elsewhere in this document. The prior year's Chair may select a designee from a pool composed of the voting volunteers of the prior year's committee and all prior Chairs if the Chair is unavailable. If the prior year's Chair is unavailable or is unable or unwilling to make such a designation in a timely fashion, the Chair of the current year's committee may select a designee in consultation with the Internet Society President. Selecting a prior year's committee member as the designee permits the experience of the prior year's deliberations to be readily available to the current committee. Selecting an earlier prior year Chair as the designee permits the experience of being a Chair as well as that Chair's committee deliberations to be readily available to the current committee. All references to "prior year's Chair" in this document refer to the person serving in that role, whether it is the actual prior year's Chair or a designee. 4.11. Voting Volunteers Voting volunteers are responsible for completing the tasks of the NomCom in a timely fashion. Each voting volunteer is expected to participate in all activities of the NomCom with a level of effort approximately equal to all other voting volunteers. Specific tasks to be completed are established and managed by the Chair according to rules stated elsewhere in this document. Kucherawy, et al. Expires January 12, 2020 [Page 18] Internet-Draft NomCom July 2019 4.12. Milestones The Chair must establish and announce milestones for the selection of the NomCom members. There is a defined time period during which the selection process is due to be completed. The Chair must establish a set of milestones which, if met in a timely fashion, will result in the completion of the process on time. 4.13. Open Positions The Chair (or the Managing Director, IETF Secretariat, if no Chair has been named four weeks after the First IETF meeting of the year) obtains the list of positions to be reviewed and announces it along with a solicitation for names of volunteers from the IETF community willing to serve on the NomCom. If the Managing Director, IETF Secretariat issues the solicitation for volunteers, the Managing Director, IETF Secretariat must also collect responses to the solicitation and provide the names of volunteers to the incoming NomCom Chair when the incoming NomCom Chair is named. At the Chair's request, the IETF Secretariat may perform other clerical support tasks, as long as the task being performed does not require NomCom Chair judgment, in the NomCom Chair's opinion, and as long as the community is appropriately notified that this request is being made. This request may come from the incoming NomCom Chair (if one has been selected for this NomCom cycle) or the previous NomCom Chair (if the search for an incoming NomCom Chair is still underway). The solicitation must permit the community at least 30 days during which they may choose to volunteer to be selected for the NomCom. The list of open positions is published with the solicitation to facilitate community members choosing between volunteering for an open position and volunteering for the NomCom. 4.14. Volunteer Qualification Members of the IETF community must have attended at least three of the last five IETF meetings in order to volunteer. The five meetings are the five most recent meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Kucherawy, et al. Expires January 12, 2020 [Page 19] Internet-Draft NomCom July 2019 The IETF Secretariat is responsible for confirming that volunteers have met the attendance requirement. Volunteers must provide their full name, email address, and primary company or organization affiliation (if any) when volunteering. Volunteers are expected to be familiar with the IETF processes and procedures, which are readily learned by active participation in a working group and especially by serving as a document editor or working group chair. 4.15. Not Qualified Any person who serves on the Internet Society Board of Trustees, the IETF Trust, the IETF LLC Board of Directors, the IAB, or the IESG, including those who serve on these bodies in ex officio positions, may not volunteer to serve as voting members of the NomCom. In addition, employees or contractors of the IETF LLC may not volunteer to serve as voting members of the NomCom. Liaisons to these bodies from other bodies or organizations are not excluded by this rule. 4.16. Selection Process The Chair announces both the list of the pool of volunteers from which the 10 voting volunteers will be randomly selected and the method with which the selection will be completed. The announcement should be made at least one week prior to the date on which the random selection will occur. The pool of volunteers must be enumerated or otherwise indicated according to the needs of the selection method to be used. The announcement must specify the data that will be used as input to the selection method. The method must depend on random data whose value is not known or available until the date on which the random selection will occur. It must be possible to independently verify that the selection method used is both fair and unbiased. A method is fair if each eligible volunteer is equally likely to be selected. A method is unbiased if no one can influence its outcome in favor of a specific outcome. It must be possible to repeat the selection method, either through iteration or by restarting in such a way as to remain fair and unbiased. This is necessary to replace selected volunteers should they become unavailable after selection. Kucherawy, et al. Expires January 12, 2020 [Page 20] Internet-Draft NomCom July 2019 The selection method must produce an ordered list of volunteers. One possible selection method is described in [RFC3797]. 4.17. Announcement of Selection Results The Chair randomly selects the 10 voting volunteers from the pool of names of volunteers and announces the members of the NomCom. No more than two volunteers with the same primary affiliation may be selected for the NomCom. The Chair reviews the primary affiliation of each volunteer selected by the method in turn. If the primary affiliation for a volunteer is the same as two previously selected volunteers, that volunteer is removed from consideration and the method is repeated to identify the next eligible volunteer. There must be at least two announcements of all members of the NomCom. The first announcement should occur as soon after the random selection as is reasonable for the Chair. The community must have at least one week during which any member may challenge the results of the random selection. The challenge must be made in writing (email is acceptable) to the Chair. The Chair has 48 hours to review the challenge and offer a resolution to the member. If the resolution is not accepted by the member, that member may report the challenge according to the dispute resolution process stated elsewhere in this document. If a selected volunteer, upon reading the announcement with the list of selected volunteers, finds that two or more other volunteers have the same affiliation, then the volunteer should notify the Chair who will determine the appropriate action. During at least the one week challenge period, the Chair must contact each of the members and confirm their willingness and availability to serve. The Chair should make every reasonable effort to contact each member. o If the Chair is unable to contact a liaison, the problem is referred to the respective organization to resolve. The Chair should allow a reasonable amount of time for the organization to resolve the problem and then may proceed without the liaison. o If the Chair is unable to contact an advisor, the Chair may elect to proceed without the advisor, except for the prior year's Chair Kucherawy, et al. Expires January 12, 2020 [Page 21] Internet-Draft NomCom July 2019 for whom the Chair must consult with the Internet Society President as stated elsewhere in this document. o If the Chair is unable to contact a voting volunteer, the Chair must repeat the random selection process in order to replace the unavailable volunteer. There should be at least one day between the announcement of the iteration and the selection process. After at least one week and confirming that 10 voting volunteers are ready to serve, the Chair makes the second announcement of the members of the NomCom, which officially begins the term of the NomCom. 4.18. Committee Organization The Chair works with the members of the committee to organize itself in preparation for completing its assigned duties. The committee has approximately one month during which it can self- organize. Its responsibilities during this time include but are not limited to the following: o Setting up a regular teleconference schedule. o Setting up an internal web site. o Setting up a mailing list for internal discussions. o Setting up an email address for receiving community input. o Establishing operational procedures. o Establishing milestones in order to monitor the progress of the selection process. 5. Nominating Committee Operation The following rules apply to the operation of the NomCom. If necessary, a paragraph discussing the interpretation of each rule is included. The rules are organized approximately in the order in which they would be invoked. Kucherawy, et al. Expires January 12, 2020 [Page 22] Internet-Draft NomCom July 2019 5.1. Discretion All rules and special circumstances not otherwise specified are at the discretion of the committee. Exceptional circumstances will occasionally arise during the normal operation of the NomCom. This rule is intended to foster the continued forward progress of the committee. Any member of the committee may propose a rule for adoption by the committee. The rule must be approved by the committee according to its established voting mechanism. All members of the committee should consider whether the exception is worthy of mention in the next revision of this document and follow-up accordingly. 5.2. Selection Timeline The completion of the process of selecting candidates to be confirmed by their respective confirming body is due within three months. The completion of the selection process is due at least two months prior to the First IETF. This ensures the NomCom has sufficient time to complete the confirmation process. 5.3. Confirmation Timeline The completion of the process of confirming the candidates is due within one month. The completion of the confirmation process is due at least one month prior to the First IETF. 5.4. Milestones The Chair must establish a set of NomCom milestones for the candidate selection and confirmation process. There is a defined time period during which the candidate selection and confirmation process must be completed. The Chair must establish a set of milestones that, if met in a timely fashion, will result in the completion of the process on time. The Chair should allow time for iterating the activities of the committee if one or more candidates are not confirmed. The Chair should ensure that all committee members are aware of the milestones. Kucherawy, et al. Expires January 12, 2020 [Page 23] Internet-Draft NomCom July 2019 5.5. Voting Mechanism The Chair must establish a voting mechanism. The committee must be able to objectively determine when a decision has been made during its deliberations. The criteria for determining closure must be established and known to all members of the NomCom. 5.6. Voting Quorum At least a quorum of committee members must participate in a vote. Only voting volunteers vote on a candidate selection. For a candidate selection vote, a quorum is comprised of at least seven of the voting volunteers. At all other times, a quorum is present if at least 75% of the NomCom members are participating. 5.7. Voting Member Recall Any member of the NomCom may propose to the committee that any other member except the Chair be recalled. The process for recalling the Chair is defined elsewhere in this document. There are a variety of ordinary circumstances that may arise that could result in one or more members of the committee being unavailable to complete their assigned duties, for example, health concerns, family issues, or a change of priorities at work. A committee member may choose to resign for unspecified personal reasons. In addition, the committee may not function well as a group because a member may be disruptive or otherwise uncooperative. Regardless of the circumstances, if individual committee members cannot work out their differences between themselves, the entire committee may be called upon to discuss and review the circumstances. If a resolution is not forthcoming, a vote may be conducted. A member may be recalled if at least a quorum of all committee members agree, including the vote of the member being recalled. If a liaison member is recalled, the committee must notify the affected organization and must allow a reasonable amount of time for a replacement to be identified by the organization before proceeding. If an advisor member other than the prior year's Chair is recalled, the committee may choose to proceed without the advisor. In the case of the prior year's Chair, the Internet Society President must be notified and the current Chair must be allowed a reasonable amount of Kucherawy, et al. Expires January 12, 2020 [Page 24] Internet-Draft NomCom July 2019 time to consult with the Internet Society President to identify a replacement before proceeding. If a single voting volunteer position on the NomCom is vacated, regardless of the circumstances, the committee may choose to proceed with only nine voting volunteers at its own discretion. In all other cases, a new voting member must be selected, and the Chair must repeat the random selection process including an announcement of the iteration prior to the actual selection as stated elsewhere in this document. A change in the primary affiliation of a voting volunteer during the term of the NomCom is not a cause to request the recall of that volunteer, even if the change would result in more than two voting volunteers with the same affiliation. 5.8. Chair Recall Only the prior year's Chair may request the recall of the current Chair. It is the responsibility of the prior year's Chair to ensure the current Chair completes the assigned tasks in a manner consistent with this document and in the best interests of the IETF community. Any member of the committee who has an issue or concern regarding the Chair should report it to the prior year's Chair immediately. The prior year's Chair is expected to report it to the Chair immediately. If they cannot resolve the issue between themselves, the prior year's Chair must report it according to the dispute resolution process stated elsewhere in this document. 5.9. Deliberations All members of the NomCom may participate in all deliberations. The emphasis of this rule is that no member can be explicitly excluded from any deliberation. However, a member may individually choose not to participate in a deliberation. 5.10. Call for Nominees The Chair announces the open positions to be reviewed, the desired expertise provided by the Managing Director, IETF Secretariat, and the call for nominees. Kucherawy, et al. Expires January 12, 2020 [Page 25] Internet-Draft NomCom July 2019 The call for nominees must include a request for comments regarding the past performance of incumbents, which will be considered during the deliberations of the NomCom. The call must request that a nomination include a valid, working email address, a telephone number, or both for the nominee. The nomination must include the set of skills or expertise the nominator believes the nominee has that would be desirable. 5.11. Nominations Any member of the IETF community may nominate any member of the IETF community for any open position, whose eligibility to serve will be confirmed by the NomCom. A self-nomination is permitted. NomCom members are not eligible to be considered for filling any open position by the NomCom on which they serve. They become ineligible as soon as the term of the NomCom on which they serve officially begins. They remain ineligible for the duration of that NomCom's term. Although each NomCom's term overlaps with the following NomCom's term, NomCom members are eligible for nomination by the following committee if not otherwise disqualified. Members of the IETF community who were recalled from any IESG, IAB, IETF Trust, or IETF LLC Board position during the previous two years are not eligible to be considered for filling any open position. 5.12. Candidate Selection The NomCom selects candidates based on its understanding of the IETF community's consensus of the qualifications required to fill the open positions. The intent of this rule is to ensure that the NomCom consults with a broad base of the IETF community for input to its deliberations. In particular, the NomCom must determine if the desired expertise for the open positions matches its understanding of the qualifications desired by the IETF community. The consultations are permitted to include names of nominees, if all parties to the consultation agree to observe the same confidentiality rules as the NomCom itself, or the names are public as discussed in Section 3.6. Feedback on individual nominees should always be confidential. Kucherawy, et al. Expires January 12, 2020 [Page 26] Internet-Draft NomCom July 2019 A broad base of the community should include the existing members of the IESG and IAB, IETF Trust Trustees, and IETF LLC Directors, especially sitting members who share responsibilities with open positions, e.g., co-Area Directors, and working group chairs, especially those in the areas with open positions. Only voting volunteer members vote to select candidates. 5.13. Consent to Nomination Nominees should be advised that they are being considered and must consent to their nomination prior to being chosen as candidates. Although the NomCom will make every reasonable effort to contact and to remain in contact with nominees, any nominee whose contact information changes during the process and who wishes to still be considered should inform the NomCom of the changes. A nominee's consent must be written (email is acceptable) and must include a commitment to provide the resources necessary to fill the open position and an assurance that the nominee will perform the duties of the position for which they are being considered in the best interests of the IETF community. Consenting to a nomination must occur prior to a nominee being a candidate and may occur as soon after the nomination as needed by the NomCom. Consenting to a nomination must not imply the nominee will be a candidate. The NomCom should help nominees provide justification to their employers. 5.14. Notifying Confirming Bodies The NomCom advises the confirming bodies of their candidates, specifying a single candidate for each open position and testifying as to how each candidate meets the qualifications of an open position. For each candidate, the testimony must include a brief statement of the qualifications for the position that is being filled, which may be exactly the expertise that was requested. If the qualifications differ from the expertise originally requested, a brief statement explaining the difference must be included. Kucherawy, et al. Expires January 12, 2020 [Page 27] Internet-Draft NomCom July 2019 The testimony may include a brief resume of the candidate and/or a brief summary of the deliberations of the NomCom. 5.15. Confirming Candidates Confirmed candidates must consent to their confirmation, and rejected candidates and nominees must be notified before confirmed candidates are announced. It is not necessary to notify and get consent from all confirmed candidates together. A nominee may not know they were a candidate. This permits a candidate to be rejected by a confirming body without the nominee knowing about the rejection. Rejected nominees, who consented to their nomination, and rejected candidates must be notified prior to announcing the confirmed candidates. It is not necessary to announce all confirmed candidates together. The NomCom must ensure that all confirmed candidates are prepared to serve prior to announcing their confirmation. 5.16. Archives The NomCom should archive the information it has collected or produced for a period of time but not to exceed its term. The purpose of the archive is to assist the NomCom should it be necessary for it to fill a mid-term vacancy. The existence of an archive, how it is implemented, and what information to archive is at the discretion of the committee. The decision must be approved by a quorum of the voting volunteer members. The implementation of the archive should make every reasonable effort to ensure that the confidentiality of the information it contains is maintained. 6. Dispute Resolution Process The dispute resolution process described here is to be used as indicated elsewhere in this document. Its applicability in other circumstances is beyond the scope of this document. Kucherawy, et al. Expires January 12, 2020 [Page 28] Internet-Draft NomCom July 2019 The NomCom operates under a strict rule of confidentiality. For this reason, when process issues arise, it is best to make every reasonable effort to resolve them within the committee. However, when circumstances do not permit this, or no resolution is forthcoming, the process described here is to be used. The following rules apply to the process. 1. The results of this process are final and binding. There is no appeal. 2. The process begins with the submission of a request as described below to the Internet Society President. 3. As soon as the process begins, the NomCom may continue those activities that are unrelated to the issue to be resolved except that it must not submit any candidates to a confirming body until the issue is resolved. 4. All parties to the process are subject to the same confidentiality rules as each member of the NomCom. 5. The process should be completed within two weeks. The process is as follows: 1. The party seeking resolution submits a written request (email is acceptable) to the Internet Society President detailing the issue to be resolved. 2. The Internet Society President appoints an arbiter to investigate and resolve the issue. A self-appointment is permitted. 3. The arbiter investigates the issue making every reasonable effort to understand both sides of the issue. Since the arbiter is subject to the same confidentiality obligations as all NomCom members, all members are expected to cooperate fully with the arbiter and to provide all relevant information to the arbiter for review. 4. After consultation with the two principal parties to the issue, the arbiter decides on a resolution. Whatever actions are necessary to execute the resolution are immediately begun and completed as quickly as possible. 5. The arbiter summarizes the issue, the resolution, and the rationale for the resolution for the Internet Society President. Kucherawy, et al. Expires January 12, 2020 [Page 29] Internet-Draft NomCom July 2019 6. In consultation with the Internet Society President, the arbiter prepares a report of the dispute and its resolution. The report should include all information that in the judgment of the arbiter does not violate the confidentiality requirements of the NomCom. 7. The Chair includes the dispute report when reporting on the activities of the NomCom to the IETF community. 7. Member, Trustee, and Director Recall The following rules apply to the recall process. If necessary, a paragraph discussing the interpretation of each rule is included. It applies to IESG and IAB Members, the NomCom appointed IETF Trust Trustees, and the NomCom appointed IETF LLC Directors. 7.1. Petition At any time, a signed petition (email is acceptable) may be submitted to the Internet Society President to request the recall of any sitting IESG or IAB member, or NomCom appointed IETF Trust Trustee, or NomCom appointed IETF LLC Director. There are two different types of petitions: a petition by participants of the IETF community, and a petition by the Ombudsteam as described in [RFC7776]. 7.1.1. Community Petition A recall petition can be made by at least 20 members of the IETF community who are qualified to be voting members of a NomCom. All individual and collective qualifications of NomCom eligibility are applicable, including that no more than two signatories may have the same primary affiliation. Each signature must include a full name, email address, and primary company or organization affiliation. The IETF Secretariat is responsible for confirming that each signatory is qualified to be a voting member of a NomCom. A valid petition must be signed by at least 20 qualified signatories. The petition must include a statement of justification for the recall and all relevant and appropriate supporting documentation. The petition and its signatories must be announced to the IETF community. Kucherawy, et al. Expires January 12, 2020 [Page 30] Internet-Draft NomCom July 2019 7.1.2. Ombudsteam Petition The Ombudsteam process allows the Ombudsteam to form a recall petition on its own without requiring 20 signatories from the community. As defined in [RFC7776], the petition and its signatories (the Ombudsteam) shall be announced to the IETF community, and a Recall Committee Chair shall be appointed to complete the Recall Committee process. It is expected that the Recall Committee will receive a briefing from the Ombudsteam explaining why recall is considered an appropriate remedy. 7.2. Recall Committee Chair The Internet Society President shall appoint a Recall Committee Chair. The Internet Society President must not evaluate the recall request. It is explicitly the responsibility of the IETF community to evaluate the behavior of its leaders. 7.3. Recall Committee Creation The recall committee is created according to the same rules as is the NomCom with the qualifications that both the person being investigated and the parties requesting the recall must not be a member of the recall committee in any capacity. 7.4. Recall Committee Rules The recall committee operates according to the same rules as the NomCom with the qualification that there is no confirmation process. 7.5. Recall Committee Operation The recall committee investigates the circumstances of the justification for the recall and votes on its findings. The investigation must include at least both an opportunity for the member being recalled to present a written statement and consultation with third parties. 7.6. 3/4 Majority A 3/4 majority of the members who vote on the question is required for a recall. Kucherawy, et al. Expires January 12, 2020 [Page 31] Internet-Draft NomCom July 2019 7.7. Position To Be Filled If a sitting member is recalled, the open position is to be filled according to the mid-term vacancy rules. 8. IANA Considerations No IANA actions required. 9. Security Considerations Any selection, confirmation, or recall process necessarily involves investigation into the qualifications and activities of prospective candidates. The investigation may reveal confidential or otherwise private information about candidates to those participating in the process. Each person who participates in any aspect of the process must maintain the confidentiality of any and all information not explicitly identified as suitable for public dissemination. When the NomCom decides it is necessary to share confidential or otherwise private information with others, the dissemination must be minimal and must include a prior commitment from all persons consulted to observe the same confidentiality rules as the NomCom itself. 10. References 10.1. Normative References [I-D.ietf-iasa2-consolidated-upd] Klensin, J., "Consolidated IASA 2.0 Updates of IETF Administrative Terminology", draft-ietf-iasa2- consolidated-upd-07 (work in progress), March 2019. [I-D.ietf-iasa2-rfc4071bis] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", draft-ietf-iasa2-rfc4071bis-11 (work in progress), April 2019. [I-D.ietf-iasa2-trust-update] Arkko, J. and T. Hardie, "Update to the Process for Selection of Trustees for the IETF Trust", draft-ietf- iasa2-trust-update-03 (work in progress), February 2019. Kucherawy, et al. Expires January 12, 2020 [Page 32] Internet-Draft NomCom July 2019 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, . [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 7437, DOI 10.17487/RFC7437, January 2015, . [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 2016, . 10.2. Informative References [Err232] RFC Errata, "Erratum ID 232", RFC 3777. [Err4179] RFC Errata, "Erratum ID 4179", RFC 3777. [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, DOI 10.17487/ RFC3710, February 2004, . [RFC3797] Eastlake 3rd, D., "Publicly Verifiable Nominations Committee (NomCom) Random Selection", RFC 3797, DOI 10.17487/RFC3797, June 2004, . [RFC8318] Dawkins, S., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee", BCP 10, RFC 8318, DOI 10.17487/RFC8318, January 2018, . Appendix A. Changes Since RFC 3777 o Converted source file from nroff to XML, resulting in some reformatting. o Applied errata for RFC 3777 ([Err232] and [Err4179]). o Applied RFC 5078 update. o Applied RFC 5633 update. o Applied RFC 5680 update. Kucherawy, et al. Expires January 12, 2020 [Page 33] Internet-Draft NomCom July 2019 o Applied RFC 6859 update. o Corrected a few grammatical errors. o Added a reference to RFC 3710. Appendix B. Changes Since RFC 7437 o Changed all mentions of the Internet Administrative Oversight committee (IAOC), and replaced it with the appropriate references to the IETF Administration LLC (IETF LLC). This included making changes on an as needed basis to some aspects of the process for the IETF LLC, in accordance with IASA2. o Revised definition of IETF Executive Director, and added definition of "Managing Director, IETF Secretariat". Changed text to "Managing Director, IETF Secretariat" where appropriate. o Added references to appropriate IASA2 documents. o Modified the Advice and Consent model to enable IESG, IAB, and IETF LLC to communicate directly with the NomCom rather than via the Managing Director, IETF Secretariat. o Updated removal text to reflect the new LLC rules, which enables removal via the LLC or the IETF recall process, except for the ISOC-appointed Director. o Updated the document to clarify that there are members of the IAB and IESG, Trustees of the IETF Trust, and Director of the IETF LLC. o Updated document to also specify procedures for the NomCom appointed IETF Trust Trustees. o Revised Abstract and Introduction to provide current context. o Changed "nominating committee" to "NomCom" throughout the document because it is what most use to describe the IETF Nominating Committee. o Added that the IETF Trust Trustees and IETF LLC Directors, each may appoint a liaison to the NomCom. o Incorporated the update to RFC7437 done by RFC7776. o Incorporated the update to RFC7437 done by [RFC8318] and updated it to refer to the IETF Trust and IETF LLC, instead of the IAOC. Kucherawy, et al. Expires January 12, 2020 [Page 34] Internet-Draft NomCom July 2019 o Editorial changes. Appendix C. Oral Tradition Over the years, various NomComs have learned through oral tradition passed on by liaisons that there are certain consistencies in the process and information considered during deliberations. Some items from that oral tradition are collected here to facilitate its consideration by future NomComs. 1. It has been found that experience as an IETF Working Group Chair or an IRTF Research Group Chair is helpful in giving a nominee experience of what the job of an Area Director involves. It also helps a NomCom judge the technical, people, and process management skills of the nominee. 2. No person should serve both on the IAB and as an Area Director, except the IETF Chair whose roles as an IAB member and Area Director of the General Area are set out elsewhere. 3. The strength of the IAB is found in part in the balance of the demographics of its members (e.g., national distribution, years of experience, gender, etc.), the combined skill set of its members, and the combined sectors (e.g., industry, academia, etc.) represented by its members. 4. There are no term limits for IAB and IESG members explicitly because the issue of continuity versus turnover should be evaluated each year according to the expectations of the IETF community, as it is understood by each NomCom. 5. The number of NomCom members with the same primary affiliation is limited in order to avoid the appearance of improper bias in choosing the leadership of the IETF. Rather than defining precise rules for how to define "affiliation", the IETF community depends on the honor and integrity of the participants to make the process work. Appendix D. Nominating Committee Timeline This appendix is included for the convenience of the reader and is not to be interpreted as the definitive timeline. It is intended to capture the detail described elsewhere in this document in one place. Although every effort has been made to ensure the description here is consistent with the description elsewhere, if there are any conflicts the definitive rule is the one in the main body of this document. Kucherawy, et al. Expires January 12, 2020 [Page 35] Internet-Draft NomCom July 2019 The only absolute in the timeline rules for the annual process is that its completion is due by the First IETF of the year after the NomCom begins its term. This is supported by the fact that the confirmed candidate terms begin during the week of the First IETF. The overall annual process is designed to be completed in seven months. It is expected to start nine months prior to the First IETF. The time is split between three major components of the process roughly as follows: 1. First is the selection and organization of the committee members. Three months are allotted for this process. 2. Second is the selection of the candidates by the NomCom. Four months are allotted for this process. 3. Third is the confirmation of the candidates by their respective confirming bodies. Two months are allotted for this process. The following list captures the details of the milestones within each component. For illustrative purposes, the list presumes the Friday before the First IETF is March 1. Numbers shown in square brackets indicate the expected number of weeks at each step. 1. BEGIN Eight Months Prior to First IETF (approx. June 1); Internet Society President appoints the Chair. The appointment must be done no later than the Second IETF or eight months prior to the First IETF, whichever comes first. The Chair must be announced and recognized during a plenary session of the Second IETF. [0] 2. The Chair establishes and announces milestones to ensure the timely selection of the NomCom members. [1] 3. The Chair contacts the IESG, IAB, and Internet Society Board of Trustees, IETF Trust, and IETF LLC and requests a liaison. The Chair contacts the prior year's Chair and requests an advisor. The Chair obtains the list of IESG, IAB, IETF Trust, and IETF LLC open positions and descriptions from the chairs of each group. [0] 4. The Chair announces the solicitation for voting volunteer members that must remain open for at least 30 days. The announcement must be done no later than seven months and two weeks prior to the First IETF (approx. June 15). [6] 5. After the solicitation closes, the Chair announces the pool of volunteers and the date of the random selection, which must be Kucherawy, et al. Expires January 12, 2020 [Page 36] Internet-Draft NomCom July 2019 at least one week in the future. The announcement must be done no later than six months and two weeks prior to the First IETF (approx. July 15). [1] 6. On the appointed day, the random selection occurs and the Chair announces the members of the committee and the one week challenge period. The announcement must be done no later than six months and one week prior to the First IETF (approx. July 22). [1] 7. During the challenge period, the Chair contacts each of the committee members and confirms their availability to participate. [0] 8. After the challenge period closes, the Chair announces the members of the committee and its term begins. The announcement must be done no later than six months prior to the First IETF (approx. August 1). [1] 9. The committee has one month during which it is to self-organize in preparation for completing its assigned duties. This must be done no later than five months prior to the First IETF (approx. September 15). [6] 10. END the Committee Member Selection Process; BEGIN the Selection of Candidates; Time is at least five months prior to the First IETF (approx. September 22). [0] 11. The Chair establishes and announces the milestones to ensure the timely selection of the candidates, including a call for nominations for the open positions. The announcement must be done no later than five months prior to the First IETF (approx. October 1). [1] 12. Over the next three months, the NomCom collects input and deliberates. It should plan to conduct interviews and other consultations during the Third IETF. The committee is due to complete its candidate selection no later than two months prior to the First IETF (approx. January 1). [17] 13. END the Selection of Candidates; BEGIN the Confirmation of Candidates; Time is at least two months prior to the First IETF (approx. January 1). [0] 14. The committee presents its candidates to their respective confirming bodies. The presentation must be done no later than two months prior to the First IETF (approx. January 1). [0] Kucherawy, et al. Expires January 12, 2020 [Page 37] Internet-Draft NomCom July 2019 15. The confirming bodies have one month to deliberate and, in communication with the NomCom, accept or reject candidates. [4] 16. The Chair notifies and advises unsuccessful nominees that they have not been selected. [1] 17. The Chair announces the confirmed candidates. The announcement must be done no later than one month prior to the First IETF (approx. February 1). [4] Appendix E. Acknowledgments A great deal of work went into the RFCs that preceded this one. The 2014 NomCom and this editor would like to thank all of them once again for the time and energy it took to get us to where we are now. In no particular order, we acknowledge: Jeff Case Fred Baker John Curran Guy Almes Geoff Huston Mike St. Johns Donald Eastlake Avri Doria Bernard Adoba Ted T'so Phil Roberts Jim Galvin Harald Alvestrand Leslie Daigle Joel Halpern Thomas Narten Spencer Dawkins Barry Leiba Lars Eggert Ross Callon Brian Carpenter Robert Elz Bernie Hoeneisen John Klensin Danny McPherson S. Moonesamy Scott Bradner Ralph Droms Pekka Savola Allison Mankin and Russ White provided early reviews and feedback about this document. Jari Arkko was very helpful by independently verifying that the previous text from all the merged documents was marshaled correctly into this one, and Adrian Farrel and Brian Carpenter caught the nits that fell through the cracks. Appendix F. Change log [RFC Editor: Please remove] draft-ietf-iasa2-rfc74337bis-09, 2019-July-11 * Added text to Abstract noting that this revision addresses only the changes required for IASA 2.0 and other changes will be addressed in future documents. * Editorial changes based on IESG reviews: + Remove RFC3747 from Abstract because this document is only based on RFC7437. Kucherawy, et al. Expires January 12, 2020 [Page 38] Internet-Draft NomCom July 2019 + Making member, director, and trustee terminology consistent. + Changed "nominated" to "selected" in Section 3.2. + Add Trustee to end of second paragraph of Section 3.7.1. + Correct section reference to [I-D.ietf-iasa2-rfc4071bis] in Section 3.4 + Clarify that there are two and three terms in Section 3.5. bullet 4. B. + Add Trustee to Section 3.8 section title and first paragraph. + Clarify that there are only term limits for IAB and IESG members in Appendix C bullet 4. + Add IETF Trust and IETF LLC to Appendix D bullet 3. + Spelled out IETF Administrative Support Activity (IASA) on first use in Section 1. + Minor editorial changes draft-ietf-iasa2-rfc74337bis-08, 2019-June-26 * Added a paragraph to Section 1 "Introduction" noting that this revision addresses only the changes required for IASA 2.0 and that should the community agree on other changes, they will be addressed in future documents. draft-ietf-iasa2-rfc74337bis-07, 2019-June-7 * Added reference to [I-D.ietf-iasa2-consolidated-upd] in Section 2. * Changed reference to RFC3710 to Informational. * Removed step 3 from IAB mid-term vacancies in Section 3.8 as it was redundant with step 4. * Correct summary below for -06 version. * Editorial changes. draft-ietf-iasa2-rfc74337bis-06, 2019-March-26 * Removed IETF LLC from the list of positions who don't have term limits in Section 3.2. * Added IETF Trust to the list of positions who can be recalled in Section 5.11. * Editorial changes. draft-ietf-iasa2-rfc74337bis-05, 2019-January-11: Kucherawy, et al. Expires January 12, 2020 [Page 39] Internet-Draft NomCom July 2019 * Changed text to point to appropriate Sections of [I-D.ietf-iasa2-rfc4071bis]. * Editorial changes. draft-ietf-iasa2-rfc74337bis-04, 2019-January-3: * Added IETF Trust to the title. * Changed references to point to current IASA 2.0 structure document [I-D.ietf-iasa2-rfc4071bis] * Added IETF Trust to a few places it was missing. * Editorial changes. draft-ietf-iasa2-rfc74337bis-03, 2018-October-22: * Revised Section 7 to focus on repeal of the the NomCom appoint LLC Director positions. * Added that the IETF Trust Trustees and IETF LLC Directors, each may appoint a liaison to the NomCom. * Incorporated the update to RFC7437 done by RFC7776. * Incorporated the update to RFC7437 done by [RFC8318] and updated it to refer to the IETF Trust and IETF LLC. instead of the IAOC. * Editorial changes. draft-ietf-iasa2-rfc74337bis-02, 2018-October-19: * Added "IETF" before Nominating and Recall Committees in the title. * Added leading capitalization to Trustee(s) and Director(s) for consistency. * Fixed other minor grammatical, spelling, or abbreviation nits. draft-ietf-iasa2-rfc74337bis-01, 2018-October-16: * Modified the Advice and Consent model to enable IESG, IAB, and IETF LLC to communicate directly with the NomCom rather than via the Managing Director, IETF Secretariat. * Updated member removal text to reflect the new LLC rules, which enables removal via the LLC or the IETF recall process, except for the ISOC-appointed Director. * Removed discussion text from the volunteer eligibility section. This means that IETF LLC employees and contractors cannot volunteer for the NomCom but does not extend that prohibition to ISOC employees and contractors. Kucherawy, et al. Expires January 12, 2020 [Page 40] Internet-Draft NomCom July 2019 * Updated the document to clarify that there are members of the IAB and IESG, Trustees of the IETF Trust, and Directors of the IETF LLC. * Removed ISOC Board of Trustees members from the definition of "sitting members" because it doesn't apply. * Updated document to also include procedures for the NomCom appointed IETF Trust Trustees. * Revised Abstract and Introduction to provide current context. * Changed "nominating committee" to "NomCom" throughout the document because it is what most use to describe the IETF Nominating Committee. * Added an no-actions IANA Considerations Section. * Editorial changes. draft-ietf-iasa2-rfc74337bis-00, 2018-October-12: Initial bis draft, Changes include: * Changed all mentions of the Internet Administrative Oversight committee (IAOC), and replaced it with the appropriate references to the IETF Administration LLC (IETF LLC). This included making changes on an as needed basis to some aspects of the process for the IETF LLC, in accordance with IASA2. * Revised definition of IETF Executive Director, and added definition of "Managing Director, IETF Secretariat". Changed text to "Managing Director, IETF Secretariat" where appropriate. * Added references to appropriate IASA2 documents. * Corrected a few grammatical errors. Authors' Addresses Murray S. Kucherawy (editor) 270 Upland Drive San Francisco, CA 94127 United States Email: superuser@gmail.com Robert M. Hinden (editor) Check Point Software San Carlos, CA USA Email: bob.hinden@gmail.com Kucherawy, et al. Expires January 12, 2020 [Page 41] Internet-Draft NomCom July 2019 Jason Livingood (editor) Comcast Philadelphia, PA USA Email: jason_livingood@comcast.com Kucherawy, et al. Expires January 12, 2020 [Page 42] ./draft-ietf-anima-grasp-15.txt0000644000764400076440000054163513131667336015604 0ustar iustyiusty Network Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track B. Carpenter, Ed. Expires: January 8, 2018 Univ. of Auckland B. Liu, Ed. Huawei Technologies Co., Ltd July 7, 2017 A Generic Autonomic Signaling Protocol (GRASP) draft-ietf-anima-grasp-15 Abstract This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable 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 January 8, 2018. 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 Bormann, et al. Expires January 8, 2018 [Page 1] Internet-Draft GRASP July 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. High Level Deployment Model . . . . . . . . . . . . . . . 7 2.3. High Level Design . . . . . . . . . . . . . . . . . . . . 8 2.4. Quick Operating Overview . . . . . . . . . . . . . . . . 11 2.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 12 2.5.1. Required External Security Mechanism . . . . . . . . 12 2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP . . . . 13 2.5.3. Transport Layer Usage . . . . . . . . . . . . . . . . 14 2.5.4. Discovery Mechanism and Procedures . . . . . . . . . 15 2.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 19 2.5.6. Synchronization and Flooding Procedures . . . . . . . 21 2.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 23 2.7. Session Identifier (Session ID) . . . . . . . . . . . . . 24 2.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 25 2.8.1. Message Overview . . . . . . . . . . . . . . . . . . 25 2.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 25 2.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 26 2.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 26 2.8.5. Discovery Response Message . . . . . . . . . . . . . 28 2.8.6. Request Messages . . . . . . . . . . . . . . . . . . 29 2.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 30 2.8.8. Negotiation End Message . . . . . . . . . . . . . . . 30 2.8.9. Confirm Waiting Message . . . . . . . . . . . . . 30 2.8.10. Synchronization Message . . . . . . . . . . . . . . . 31 2.8.11. Flood Synchronization Message . . . . . . . . . . . . 31 2.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 32 2.8.13. No Operation Message . . . . . . . . . . . . . . . . 33 2.9. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 33 2.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 33 2.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 33 2.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 34 2.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 34 2.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 34 2.10. Objective Options . . . . . . . . . . . . . . . . . . . . 36 2.10.1. Format of Objective Options . . . . . . . . . . . . 36 2.10.2. Objective flags . . . . . . . . . . . . . . . . . . 38 Bormann, et al. Expires January 8, 2018 [Page 2] Internet-Draft GRASP July 2017 2.10.3. General Considerations for Objective Options . . . . 38 2.10.4. Organizing of Objective Options . . . . . . . . . . 39 2.10.5. Experimental and Example Objective Options . . . . . 41 3. Implementation Status [RFC Editor: please remove] . . . . . . 41 3.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 41 3.2. Python Implementation . . . . . . . . . . . . . . . . . . 42 4. Security Considerations . . . . . . . . . . . . . . . . . . . 42 5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 45 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . 49 8.2. Informative References . . . . . . . . . . . . . . . . . 50 Appendix A. Open Issues [RFC Editor: This section should be empty. Please remove] . . . . . . . . . . . . . . . 54 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 54 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 62 Appendix D. Example Message Formats . . . . . . . . . . . . . . 70 D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 71 D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 71 D.3. Synchronization Example . . . . . . . . . . . . . . . . . 71 D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 72 D.5. Complete Negotiation Example . . . . . . . . . . . . . . 72 Appendix E. Requirement Analysis of Discovery, Synchronization and Negotiation . . . . . . . . . . . . . . . . . . 73 E.1. Requirements for Discovery . . . . . . . . . . . . . . . 73 E.2. Requirements for Synchronization and Negotiation Capability . . . . . . . . . . . . . . . . . . . . . . . 75 E.3. Specific Technical Requirements . . . . . . . . . . . . . 77 Appendix F. Capability Analysis of Current Protocols . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 1. Introduction The success of the Internet has made IP-based networks bigger and more complicated. Large-scale ISP and enterprise networks have become more and more problematic for human based management. Also, operational costs are growing quickly. Consequently, there are increased requirements for autonomic behavior in the networks. General aspects of autonomic networks are discussed in [RFC7575] and [RFC7576]. One approach is to largely decentralize the logic of network management by migrating it into network elements. A reference model for autonomic networking on this basis is given in [I-D.ietf-anima-reference-model]. The reader should consult this document to understand how various autonomic components fit together. In order to fulfill autonomy, devices that embody Autonomic Service Bormann, et al. Expires January 8, 2018 [Page 3] Internet-Draft GRASP July 2017 Agents (ASAs, [RFC7575]) have specific signaling requirements. In particular they need to discover each other, to synchronize state with each other, and to negotiate parameters and resources directly with each other. There is no limitation on the types of parameters and resources concerned, which can include very basic information needed for addressing and routing, as well as anything else that might be configured in a conventional non-autonomic network. The atomic unit of discovery, synchronization or negotiation is referred to as a technical objective, i.e, a configurable parameter or set of parameters (defined more precisely in Section 2.1). Negotiation is an iterative process, requiring multiple message exchanges forming a closed loop between the negotiating entities. In fact, these entities are ASAs, normally but not necessarily in different network devices. State synchronization, when needed, can be regarded as a special case of negotiation, without iteration. Both negotiation and synchronization must logically follow discovery. More details of the requirements are found in Appendix E. Section 2.3 describes a behavior model for a protocol intended to support discovery, synchronization and negotiation. The design of GeneRic Autonomic Signaling Protocol (GRASP) in Section 2 of this document is based on this behavior model. The relevant capabilities of various existing protocols are reviewed in Appendix F. The proposed discovery mechanism is oriented towards synchronization and negotiation objectives. It is based on a neighbor discovery process on the local link, but also supports diversion to peers on other links. There is no assumption of any particular form of network topology. When a device starts up with no pre-configuration, it has no knowledge of the topology. The protocol itself is capable of being used in a small and/or flat network structure such as a small office or home network as well as in a large professionally managed network. Therefore, the discovery mechanism needs to be able to allow a device to bootstrap itself without making any prior assumptions about network structure. Because GRASP can be used as part of a decision process among distributed devices or between networks, it must run in a secure and strongly authenticated environment. In realistic deployments, not all devices will support GRASP. Therefore, some autonomic service agents will directly manage a group of non-autonomic nodes, and other non-autonomic nodes will be managed traditionally. Such mixed scenarios are not discussed in this specification. Bormann, et al. Expires January 8, 2018 [Page 4] Internet-Draft GRASP July 2017 2. GRASP Protocol Overview 2.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] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] key words. This document uses terminology defined in [RFC7575]. The following additional terms are used throughout this document: o Discovery: a process by which an ASA discovers peers according to a specific discovery objective. The discovery results may be different according to the different discovery objectives. The discovered peers may later be used as negotiation counterparts or as sources of synchronization data. o Negotiation: a process by which two ASAs interact iteratively to agree on parameter settings that best satisfy the objectives of both ASAs. o State Synchronization: a process by which ASAs interact to receive the current state of parameter values stored in other ASAs. This is a special case of negotiation in which information is sent but the ASAs do not request their peers to change parameter settings. All other definitions apply to both negotiation and synchronization. o Technical Objective (usually abbreviated as Objective): A technical objective is a data structure, whose main contents are a name and a value. The value consists of a single configurable parameter or a set of parameters of some kind. The exact format of an objective is defined in Section 2.10.1. An objective occurs in three contexts: Discovery, Negotiation and Synchronization. Normally, a given objective will not occur in negotiation and synchronization contexts simultaneously. * One ASA may support multiple independent objectives. * The parameter(s) in the value of a given objective apply to a specific service or function or action. They may in principle be anything that can be set to a specific logical, numerical or string value, or a more complex data structure, by a network Bormann, et al. Expires January 8, 2018 [Page 5] Internet-Draft GRASP July 2017 node. Each node is expected to contain one or more ASAs which may each manage subsidiary non-autonomic nodes. * Discovery Objective: an objective in the process of discovery. Its value may be undefined. * Synchronization Objective: an objective whose specific technical content needs to be synchronized among two or more ASAs. Thus, each ASA will maintain its own copy of the objective. * Negotiation Objective: an objective whose specific technical content needs to be decided in coordination with another ASA. Again, each ASA will maintain its own copy of the objective. A detailed discussion of objectives, including their format, is found in Section 2.10. o Discovery Initiator: an ASA that starts discovery by sending a discovery message referring to a specific discovery objective. o Discovery Responder: a peer that either contains an ASA supporting the discovery objective indicated by the discovery initiator, or caches the locator(s) of the ASA(s) supporting the objective. It sends a Discovery Response, as described later. o Synchronization Initiator: an ASA that starts synchronization by sending a request message referring to a specific synchronization objective. o Synchronization Responder: a peer ASA which responds with the value of a synchronization objective. o Negotiation Initiator: an ASA that starts negotiation by sending a request message referring to a specific negotiation objective. o Negotiation Counterpart: a peer with which the Negotiation Initiator negotiates a specific negotiation objective. o GRASP Instance: This refers to an instantiation of a GRASP protocol engine, likely including multiple threads or processes as well as dynamic data structures such as a discovery cache, running in a given security environment on a single device. o GRASP Core: This refers to the code and shared data structures of a GRASP instance, which will communicate with individual ASAs via a suitable Application Programming Interface (API). Bormann, et al. Expires January 8, 2018 [Page 6] Internet-Draft GRASP July 2017 o Interface or GRASP Interface: Unless otherwise stated, these refer to a network interface - which might be physical or virtual - that a specific instance of GRASP is currently using. A device might have other interfaces that are not used by GRASP and which are outside the scope of the autonomic network. 2.2. High Level Deployment Model A GRASP implementation will be part of the Autonomic Networking Infrastructure (ANI) in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. As a result, all autonomic nodes in the ACP are able to trust each other. It is expected that GRASP will access the ACP by using a typical socket programming interface and the ACP will make available only network interfaces within the autonomic network. If there is no ACP, the considerations described in Section 2.5.1 apply. There will also be one or more Autonomic Service Agents (ASAs). In the minimal case of a single-purpose device, these components might be fully integrated with GRASP and the ACP. A more common model is expected to be a multi-purpose device capable of containing several ASAs, such as a router or large switch. In this case it is expected that the ACP, GRASP and the ASAs will be implemented as separate processes, which are able to support asynchronous and simultaneous operations, for example by multi-threading. In some scenarios, a limited negotiation model might be deployed based on a limited trust relationship such as that between two administrative domains. ASAs might then exchange limited information and negotiate some particular configurations. GRASP is explicitly designed to operate within a single addressing realm. Its discovery and flooding mechanisms do not support autonomic operations that cross any form of address translator or upper layer proxy. A suitable Application Programming Interface (API) will be needed between GRASP and the ASAs. In some implementations, ASAs would run in user space with a GRASP library providing the API, and this library would in turn communicate via system calls with core GRASP functions. Details of the API are out of scope for the present document. For further details of possible deployment models, see [I-D.ietf-anima-reference-model]. An instance of GRASP must be aware of the network interfaces it will use, and of the appropriate global-scope and link-local addresses. Bormann, et al. Expires January 8, 2018 [Page 7] Internet-Draft GRASP July 2017 In the presence of the ACP, such information will be available from the adjacency table discussed in [I-D.ietf-anima-reference-model]. In other cases, GRASP must determine such information for itself. Details depend on the device and operating system. In the rest of this document, the terms 'interfaces' or 'GRASP interfaces' refers only to the set of network interfaces that a specific instance of GRASP is currently using. Because GRASP needs to work with very high reliability, especially during bootstrapping and during fault conditions, it is essential that every implementation continues to operate in adverse conditions. For example, discovery failures, or any kind of socket exception at any time, must not cause irrecoverable failures in GRASP itself, and must return suitable error codes through the API so that ASAs can also recover. GRASP must not depend upon non-volatile data storage. All run time error conditions, and events such as address renumbering, network interface failures, and CPU sleep/wake cycles, must be handled in such a way that GRASP will still operate correctly and securely (Section 2.5.1) afterwards. An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. Possible exceptions are mentioned below. 2.3. High Level Design This section describes the behavior model and general design of GRASP, supporting discovery, synchronization and negotiation, to act as a platform for different technical objectives. o A generic platform: The protocol design is generic and independent of the synchronization or negotiation contents. The technical contents will vary according to the various technical objectives and the different pairs of counterparts. o Normally, a single main instance of the GRASP protocol engine will exist in an autonomic node, and each ASA will run as an independent asynchronous process. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are possible (Section 2.5.2). In this case, each instance MUST listen independently for GRASP link- local multicasts, and all instances MUST be woken by each such multicast, in order for discovery and flooding to work correctly. Bormann, et al. Expires January 8, 2018 [Page 8] Internet-Draft GRASP July 2017 o Security infrastructure: As noted above, the protocol itself has no built-in security functionality, and relies on a separate secure infrastructure. o Discovery, synchronization and negotiation are designed together: The discovery method and the synchronization and negotiation methods are designed in the same way and can be combined when this is useful, allowing a rapid mode of operation described in Section 2.5.4. These processes can also be performed independently when appropriate. * Thus, for some objectives, especially those concerned with application layer services, another discovery mechanism such as the future DNS Service Discovery [RFC7558] MAY be used. The choice is left to the designers of individual ASAs. o A uniform pattern for technical objectives: The synchronization and negotiation objectives are defined according to a uniform pattern. The values that they contain could be carried either in a simple binary format or in a complex object format. The basic protocol design uses the Concise Binary Object Representation (CBOR) [RFC7049], which is readily extensible for unknown future requirements. o A flexible model for synchronization: GRASP supports synchronization between two nodes, which could be used repeatedly to perform synchronization among a small number of nodes. It also supports an unsolicited flooding mode when large groups of nodes, possibly including all autonomic nodes, need data for the same technical objective. * There may be some network parameters for which a more traditional flooding mechanism such as DNCP [RFC7787] is considered more appropriate. GRASP can coexist with DNCP. o A simple initiator/responder model for negotiation: Multi-party negotiations are very complicated to model and cannot readily be guaranteed to converge. GRASP uses a simple bilateral model and can support multi-party negotiations by indirect steps. Bormann, et al. Expires January 8, 2018 [Page 9] Internet-Draft GRASP July 2017 o Organizing of synchronization or negotiation content: The technical content transmitted by GRASP will be organized according to the relevant function or service. The objectives for different functions or services are kept separate, because they may be negotiated or synchronized with different counterparts or have different response times. Thus a normal arrangement would be a single ASA managing a small set of closely related objectives, with a version of that ASA in each relevant autonomic node. Further discussion of this aspect is out of scope for the current document. o Requests and responses in negotiation procedures: The initiator can negotiate a specific negotiation objective with relevant counterpart ASAs. It can request relevant information from a counterpart so that it can coordinate its local configuration. It can request the counterpart to make a matching configuration. It can request simulation or forecast results by sending some dry run conditions. Beyond the traditional yes/no answer, the responder can reply with a suggested alternative value for the objective concerned. This would start a bi-directional negotiation ending in a compromise between the two ASAs. o Convergence of negotiation procedures: To enable convergence, when a responder suggests a new value or condition in a negotiation step reply, it should be as close as possible to the original request or previous suggestion. The suggested value of later negotiation steps should be chosen between the suggested values from the previous two steps. GRASP provides mechanisms to guarantee convergence (or failure) in a small number of steps, namely a timeout and a maximum number of iterations. o Extensibility: GRASP intentionally does not have a version number, and can be extended by adding new message types and options. The Invalid Message (M_INVALID) will be used to signal that an implementation does not recognize a message or option sent by another Bormann, et al. Expires January 8, 2018 [Page 10] Internet-Draft GRASP July 2017 implementation. In normal use, new semantics will be added by defining new synchronization or negotiation objectives. 2.4. Quick Operating Overview An instance of GRASP is expected to run as a separate core module, providing an API (such as [I-D.liu-anima-grasp-api]) to interface to various ASAs. These ASAs may operate without special privilege, unless they need it for other reasons (such as configuring IP addresses or manipulating routing tables). The GRASP mechanisms used by the ASA are built around GRASP objectives defined as data structures containing administrative information such as the objective's unique name, and its current value. The format and size of the value is not restricted by the protocol, except that it must be possible to serialize it for transmission in CBOR, which is no restriction at all in practice. GRASP provides the following mechanisms: o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA can discover other ASAs supporting a given objective. o A negotiation request mechanism (M_REQ_NEG), by which an ASA can start negotiation of an objective with a counterpart ASA. Once a negotiation has started, the process is symmetrical, and there is a negotiation step message (M_NEGOTIATE) for each ASA to use in turn. Two other functions support negotiating steps (M_WAIT, M_END). o A synchronization mechanism (M_REQ_SYN), by which an ASA can request the current value of an objective from a counterpart ASA. With this, there is a corresponding response function (M_SYNCH) for an ASA that wishes to respond to synchronization requests. o A flood mechanism (M_FLOOD), by which an ASA can cause the current value of an objective to be flooded throughout the autonomic network so that any ASA can receive it. One application of this is to act as an announcement, avoiding the need for discovery of a widely applicable objective. Some example messages and simple message flows are provided in Appendix D. Bormann, et al. Expires January 8, 2018 [Page 11] Internet-Draft GRASP July 2017 2.5. GRASP Protocol Basic Properties and Mechanisms 2.5.1. Required External Security Mechanism GRASP does not specify transport security because it is meant to be adapted to different environments. Every solution adopting GRASP MUST specify a security and transport substrate used by GRASP in that solution. The substrate MUST enforce sending and receiving GRASP messages only between members of a mutually trusted group running GRASP. Each group member is an instance of GRASP. The group members are nodes of a connected graph. The group and graph is created by the security and transport substrate and called the GRASP domain. The substrate must support unicast messages between any group members and (link- local) multicast messages between adjacent group members. It must deny messages between group members and non group members. With this model, security is provided by enforcing group membership, but any member of the trusted group can attack the entire network until revoked. Substrates MUST use cryptographic member authentication and message integrity for GRASP messages. This can be end-to-end or hop-by-hop across the domain. The security and transport substrate MUST provide mechanisms to remove untrusted members from the group. If the substrate does not mandate and enforce GRASP message encryption then any service using GRASP in such a solution MUST provide protection and encryption for message elements whose exposure could constitute an attack vector. The security and transport substrate for GRASP in the ANI is the ACP. Unless otherwise noted, we assume this security and transport substrate in the remainder of this document. The ACP does mandate the use of encryption; therefore GRASP in the ANI can rely on GRASP message being encrypted. The GRASP domain is the ACP: all nodes in an autonomic domain connected by encrypted virtual links formed by the ACP. The ACP uses hop-by-hop security (authentication/ encryption) of messages. Removal of nodes relies on standard PKI certificate revocation or expiry of sufficiently short lived certificates. Refer to [I-D.ietf-anima-autonomic-control-plane] for more details. As mentioned in Section 2.3, some GRASP operations might be performed across an administrative domain boundary by mutual agreement, without the benefit of an ACP. Such operations MUST be confined to a separate instance of GRASP with its own copy of all GRASP data structures running across a separate GRASP domain with a security and Bormann, et al. Expires January 8, 2018 [Page 12] Internet-Draft GRASP July 2017 transport substrate. In the most simple case, each point-to-point interdomain GRASP peering could be a separate domain and the security and transport substrate could be built using transport or network layer security protocols. This is subject to future specifications. An exception to the requirements for the security and transport substrate exists for highly constrained subsets of GRASP meant to support the establishment of a security and transport substrate, described in the following section. 2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP Some services may need to use insecure GRASP discovery, response and flood messages without being able to use pre-existing security associations, for example as part of discovery for establishing security associations such as a security substrate for GRASP. Such operations being intrinsically insecure, they need to be confined to link-local use to minimize the risk of malicious actions. Possible examples include discovery of candidate ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps initialization services in networks using GRASP without being fully autonomic (e.g., no ACP). Such usage MUST be limited to link-local operations on a single interface and MUST be confined to a separate insecure instance of GRASP with its own copy of all GRASP data structures. This instance is nicknamed DULL - Discovery Unsolicited Link-Local. The detailed rules for the DULL instance of GRASP are as follows: o An initiator MAY send Discovery or Flood Synchronization link- local multicast messages which MUST have a loop count of 1, to prevent off-link operations. Other unsolicited GRASP message types MUST NOT be sent. o A responder MUST silently discard any message whose loop count is not 1. o A responder MUST silently discard any message referring to a GRASP Objective that is not directly part of a service that requires this insecure mode. o A responder MUST NOT relay any multicast messages. o A Discovery Response MUST indicate a link-local address. o A Discovery Response MUST NOT include a Divert option. Bormann, et al. Expires January 8, 2018 [Page 13] Internet-Draft GRASP July 2017 o A node MUST silently discard any message whose source address is not link-local. To minimize traffic possibly observed by third parties, GRASP traffic SHOULD be minimized by using only Flood Synchronization to announce objectives and their associated locators, rather than by using Discovery and Response. Further details are out of scope for this document 2.5.3. Transport Layer Usage All GRASP messages, after they are serialized as a CBOR byte string, are transmitted as such directly over the transport protocol in use. The transport protocol(s) for a GRASP domain are specified by the security and transport substrate as introduced in Section 2.5.1. GRASP discovery and flooding messages are designed for GRASP domain wide flooding through hop-by-hop link-local multicast forwarding between adjacent GRASP nodes. The GRASP security and transport substrate needs to specify how these link local multicasts are transported. This can be unreliable transport (UDP) but it SHOULD be reliable transport (e.g., TCP). If the substrate specifies an unreliable transport such as UDP for discovery and flooding messages, then it MUST NOT use IP fragmentation because of its loss characteristic, especially in multi-hop flooding. GRASP MUST then enforce at the user API level a limit to the size of discovery and flooding messages, so that no fragmentation can occur. For IPv6 transport this means that those messages must be at most 1280 bytes sized IPv6 packets (unless there is a known larger minimum link MTU across the whole GRASP domain). All other GRASP messages are unicast beteween group members of the GRASP domain. These MUST use a reliable transport protocol because GRASP itself does not provide for error detection, retransmission or flow control. Unless otherwise specified by the security and transport substrate, TCP MUST be used. The security and transport substrate for GRASP in the ANI is the ACP. Unless otherwise noted, we assume this security and transport substrate in the remainder of this document when describing GRASPs message transport. In the ACP, TCP is used for GRASP unicast messages. GRASP discovery and flooding messages also use TCP: These link-local messages are forwarded by replicating them to all adjacent GRASP nodes on the link via TCP connections to those adjacent GRASP nodes. Because of this, GRASP in the ANI has no limitations on the size of discovery and flooding messages with respect to fragmentation Bormann, et al. Expires January 8, 2018 [Page 14] Internet-Draft GRASP July 2017 issues. UDP is used in the ANI with GRASP only with DULL when the ACP is built to discover ACP/GRASP neighbors on links. For link-local UDP multicast, the GRASP protocol listens to the well- known GRASP Listen Port (Section 2.6). Transport connections for Discovery and Flooding on relay nodes must terminate in GRASP instances (eg: GRASP ASAs) so that link-local multicast, hop-by-hop flooding of M_DISCOVERY and M_FLOOD and hop-by-hop forwarding of M_RESPONSE and caching of those responses along the path work correctly. Unicast transport connections used for synchronization and negotiation can terminate directly in ASAs that implement objectives and therefore this traffic does not need to pass through GRASP instances. For this, the ASA listens on its own dynamically assigned ports, which are communicated to its peers during discovery. Alternatively, the GRASP instance can also terminate the unicast transport connections and pass the traffic from/to the ASA if that is preferrable in some implementation (eg: to better decouple ASAs from network connections). 2.5.4. Discovery Mechanism and Procedures 2.5.4.1. Separated discovery and negotiation mechanisms Although discovery and negotiation or synchronization are defined together in GRASP, they are separate mechanisms. The discovery process could run independently from the negotiation or synchronization process. Upon receiving a Discovery (Section 2.8.4) message, the recipient node should return a response message in which it either indicates itself as a discovery responder or diverts the initiator towards another more suitable ASA. However, this response may be delayed if the recipient needs to relay the discovery onwards, as described below. The discovery action (M_DISCOVERY) will normally be followed by a negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action. The discovery results could be utilized by the negotiation protocol to decide which ASA the initiator will negotiate with. The initiator of a discovery action for a given objective need not be capable of responding to that objective as a Negotiation Counterpart, as a Synchronization Responder or as source for flooding. For example, an ASA might perform discovery even if it only wishes to act a Synchronization Initiator or Negotiation Initiator. Such an ASA does not itself need to respond to discovery messages. Bormann, et al. Expires January 8, 2018 [Page 15] Internet-Draft GRASP July 2017 It is also entirely possible to use GRASP discovery without any subsequent negotiation or synchronization action. In this case, the discovered objective is simply used as a name during the discovery process and any subsequent operations between the peers are outside the scope of GRASP. 2.5.4.2. Discovery Overview A complete discovery process will start with a multicast (of M_DISCOVERY) on the local link. On-link neighbors supporting the discovery objective will respond directly (with M_RESPONSE). A neighbor with multiple interfaces may respond with a cached discovery response. If it has no cached response, it will relay the discovery on its other GRASP interfaces. If a node receiving the relayed discovery supports the discovery objective, it will respond to the relayed discovery. If it has a cached response, it will respond with that. If not, it will repeat the discovery process, which thereby becomes iterative. The loop count and timeout will ensure that the process ends. Further details are given below. A Discovery message MAY be sent unicast to a peer node, which SHOULD then proceed exactly as if the message had been multicast, except that when TCP is used, the response will be on the same socket as the query. However, this mode does not guarantee successful discovery in the general case. 2.5.4.3. Discovery Procedures Discovery starts as an on-link operation. The Divert option can tell the discovery initiator to contact an off-link ASA for that discovery objective. If the security and transport substrate of the GRASP domain (see Section 2.5.3) uses UDP link-local multicast then the discovery initiator sends these to the ALL_GRASP_NEIGHBORS link-local multicast address (Section 2.6) and and all GRASP nodes need to listen to this address to act as discovery responder. Because this port is unique in a device, this is a function of the GRASP instance and not of an individual ASA. As a result, each ASA will need to register the objectives that it supports with the local GRASP instance. If an ASA in a neighbor device supports the requested discovery objective, the device SHOULD respond to the link-local multicast with a unicast Discovery Response message (Section 2.8.5) with locator option(s), unless it is temporarily unavailable. Otherwise, if the neighbor has cached information about an ASA that supports the requested discovery objective (usually because it discovered the same objective before), it SHOULD respond with a Discovery Response message with a Divert option pointing to the appropriate Discovery Bormann, et al. Expires January 8, 2018 [Page 16] Internet-Draft GRASP July 2017 Responder. However, it SHOULD NOT respond with a cached response on an interface if it learnt that information from the same interface, because the peer in question will answer directly if still operational. If a device has no information about the requested discovery objective, and is not acting as a discovery relay (see below) it MUST silently discard the Discovery message. The discovery initiator MUST set a reasonable timeout on the discovery process. A suggested value is 100 milliseconds multiplied by the loop count embedded in the objective. If no discovery response is received within the timeout, the Discovery message MAY be repeated, with a newly generated Session ID (Section 2.7). An exponential backoff SHOULD be used for subsequent repetitions, to limit the load during busy periods. The details of the backoff algorithm will depend on the use case for the objective concerned but MUST be consistent with the recommendations in [RFC8085] for low data-volume multicast. Frequent repetition might be symptomatic of a denial of service attack. After a GRASP device successfully discovers a locator for a Discovery Responder supporting a specific objective, it SHOULD cache this information, including the interface index [RFC3493] via which it was discovered. This cache record MAY be used for future negotiation or synchronization, and the locator SHOULD be passed on when appropriate as a Divert option to another Discovery Initiator. The cache mechanism MUST include a lifetime for each entry. The lifetime is derived from a time-to-live (ttl) parameter in each Discovery Response message. Cached entries MUST be ignored or deleted after their lifetime expires. In some environments, unplanned address renumbering might occur. In such cases, the lifetime SHOULD be short compared to the typical address lifetime. The discovery mechanism needs to track the node's current address to ensure that Discovery Responses always indicate the correct address. If multiple Discovery Responders are found for the same objective, they SHOULD all be cached, unless this creates a resource shortage. The method of choosing between multiple responders is an implementation choice. This choice MUST be available to each ASA but the GRASP implementation SHOULD provide a default choice. Because Discovery Responders will be cached in a finite cache, they might be deleted at any time. In this case, discovery will need to be repeated. If an ASA exits for any reason, its locator might still Bormann, et al. Expires January 8, 2018 [Page 17] Internet-Draft GRASP July 2017 be cached for some time, and attempts to connect to it will fail. ASAs need to be robust in these circumstances. 2.5.4.4. Discovery Relaying A GRASP instance with multiple link-layer interfaces (typically running in a router) MUST support discovery on all GRASP interfaces. We refer to this as a 'relaying instance'. DULL Instances (Section 2.5.2) are always single-interface instances and therefore MUST NOT perform discovery relaying. If a relaying instance receives a Discovery message on a given interface for a specific objective that it does not support and for which it has not previously cached a Discovery Responder, it MUST relay the query by re-issuing a new Discovery message as a link-local multicast on its other GRASP interfaces. The relayed discovery message MUST have the same Session ID and Initiator field as the incoming (see Section 2.8.4). The Initiator IP address field is only used to allow for disambiguation of the Session ID and is never used to address Response packets. Response packets are sent back to the relaying instance, not the original initiator. The M_DISCOVERY message does not encode the transport address of the originator or relay. Response packets must therefore be sent to the transport layer address of the connection on which the M_DISCOVERY message was received. If the M_DISCOVERY was relayed via a reliable hop-by-hop transport connection, the response is simply sent back via the same connection. If the M_DISCOVERY was relayed via link-local (eg: UDP) multicast, the response is sent back via a reliable hop-by-hop transport connection with the same port number as the source port of the link- local multicast. Therefore, if link-local multicast is used and M_RESPONSE messages are required (which is the case in almost all GRASP instances except for the limited use of DULL instances in the ANI), GRASP needs to be able to bind to one port number on UDP from which to originate the link-local multicast M_DISCOVERY messages and the same port number on the reliable hop-by-hop transport (eg: TCP by default) to be able to respond to transport connections from responders that want to send M_RESPONSE messages back. Note that this port does not need to be the GRASP_LISTEN_PORT. The relaying instance MUST decrement the loop count within the objective, and MUST NOT relay the Discovery message if the result is zero. Also, it MUST limit the total rate at which it relays Bormann, et al. Expires January 8, 2018 [Page 18] Internet-Draft GRASP July 2017 discovery messages to a reasonable value, in order to mitigate possible denial of service attacks. For example, the rate limit could be set to a small multiple of the observed rate of discovery messages during normal operation. The relaying instance MUST cache the Session ID value and initiator address of each relayed Discovery message until any Discovery Responses have arrived or the discovery process has timed out. To prevent loops, it MUST NOT relay a Discovery message which carries a given cached Session ID and initiator address more than once. These precautions avoid discovery loops and mitigate potential overload. Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a suitable timeout for the relayed discovery. A suggested value is 100 milliseconds multiplied by the remaining loop count. The discovery results received by the relaying instance MUST in turn be sent as a Discovery Response message to the Discovery message that caused the relay action. 2.5.4.5. Rapid Mode (Discovery with Negotiation or Synchronization ) A Discovery message MAY include an Objective option. This allows a rapid mode of negotiation (Section 2.5.5.1) or synchronization (Section 2.5.6.3). Rapid mode is currently limited to a single objective for simplicity of design and implementation. A possible future extension is to allow multiple objectives in rapid mode for greater efficiency. 2.5.5. Negotiation Procedures A negotiation initiator opens a transport connection to a counterpart ASA using the address, protocol and port obtained during discovery. It then sends a negotiation request (using M_REQ_NEG) to the counterpart, including a specific negotiation objective. It may request the negotiation counterpart to make a specific configuration. Alternatively, it may request a certain simulation or forecast result by sending a dry run configuration. The details, including the distinction between a dry run and a live configuration change, will be defined separately for each type of negotiation objective. Any state associated with a dry run operation, such as temporarily reserving a resource for subsequent use in a live run, is entirely a matter for the designer of the ASA concerned. Each negotiation session as a whole is subject to a timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 2.6), initialised when the request is sent (see Section 2.8.6). If no reply message of any kind is received within the timeout, the negotiation request MAY be Bormann, et al. Expires January 8, 2018 [Page 19] Internet-Draft GRASP July 2017 repeated, with a newly generated Session ID (Section 2.7). An exponential backoff SHOULD be used for subsequent repetitions. The details of the backoff algorithm will depend on the use case for the objective concerned. If the counterpart can immediately apply the requested configuration, it will give an immediate positive (O_ACCEPT) answer (using M_END). This will end the negotiation phase immediately. Otherwise, it will negotiate (using M_NEGOTIATE). It will reply with a proposed alternative configuration that it can apply (typically, a configuration that uses fewer resources than requested by the negotiation initiator). This will start a bi-directional negotiation (using M_NEGOTIATE) to reach a compromise between the two ASAs. The negotiation procedure is ended when one of the negotiation peers sends a Negotiation Ending (M_END) message, which contains an accept (O_ACCEPT) or decline (O_DECLINE) option and does not need a response from the negotiation peer. Negotiation may also end in failure (equivalent to a decline) if a timeout is exceeded or a loop count is exceeded. When the procedure ends for whatever reason, the transport connection SHOULD be closed. A transport session failure is treated as a negotiation failure. A negotiation procedure concerns one objective and one counterpart. Both the initiator and the counterpart may take part in simultaneous negotiations with various other ASAs, or in simultaneous negotiations about different objectives. Thus, GRASP is expected to be used in a multi-threaded mode or its logical equivalent. Certain negotiation objectives may have restrictions on multi-threading, for example to avoid over-allocating resources. Some configuration actions, for example wavelength switching in optical networks, might take considerable time to execute. The ASA concerned needs to allow for this by design, but GRASP does allow for a peer to insert latency in a negotiation process if necessary (Section 2.8.9, M_WAIT). 2.5.5.1. Rapid Mode (Discovery/Negotiation Linkage) A Discovery message MAY include a Negotiation Objective option. In this case it is as if the initiator sent the sequence M_DISCOVERY, immediately followed by M_REQ_NEG. This has implications for the construction of the GRASP core, as it must carefully pass the contents of the Negotiation Objective option to the ASA so that it may evaluate the objective directly. When a Negotiation Objective option is present the ASA replies with an M_NEGOTIATE message (or M_END with O_ACCEPT if it is immediately satisfied with the Bormann, et al. Expires January 8, 2018 [Page 20] Internet-Draft GRASP July 2017 proposal), rather than with an M_RESPONSE. However, if the recipient node does not support rapid mode, discovery will continue normally. It is possible that a Discovery Response will arrive from a responder that does not support rapid mode, before such a Negotiation message arrives. In this case, rapid mode will not occur. This rapid mode could reduce the interactions between nodes so that a higher efficiency could be achieved. However, a network in which some nodes support rapid mode and others do not will have complex timing-dependent behaviors. Therefore, the rapid negotiation function SHOULD be disabled by default. 2.5.6. Synchronization and Flooding Procedures 2.5.6.1. Unicast Synchronization A synchronization initiator opens a transport connection to a counterpart ASA using the address, protocol and port obtained during discovery. It then sends a synchronization request (using M_REQ_SYN) to the counterpart, including a specific synchronization objective. The counterpart responds with a Synchronization message (M_SYNCH, Section 2.8.10) containing the current value of the requested synchronization objective. No further messages are needed and the transport connection SHOULD be closed. A transport session failure is treated as a synchronization failure. If no reply message of any kind is received within a given timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 2.6), the synchronization request MAY be repeated, with a newly generated Session ID (Section 2.7). An exponential backoff SHOULD be used for subsequent repetitions. The details of the backoff algorithm will depend on the use case for the objective concerned. 2.5.6.2. Flooding In the case just described, the message exchange is unicast and concerns only one synchronization objective. For large groups of nodes requiring the same data, synchronization flooding is available. For this, a flooding initiator MAY send an unsolicited Flood Synchronization message containing one or more Synchronization Objective option(s), if and only if the specification of those objectives permits it. This is sent as a multicast message to the ALL_GRASP_NEIGHBORS multicast address (Section 2.6). Receiving flood multicasts is a function of the GRASP core, as in the case of discovery multicasts (Section 2.5.4.3). Bormann, et al. Expires January 8, 2018 [Page 21] Internet-Draft GRASP July 2017 To ensure that flooding does not result in a loop, the originator of the Flood Synchronization message MUST set the loop count in the objectives to a suitable value (the default is GRASP_DEF_LOOPCT). Also, a suitable mechanism is needed to avoid excessive multicast traffic. This mechanism MUST be defined as part of the specification of the synchronization objective(s) concerned. It might be a simple rate limit or a more complex mechanism such as the Trickle algorithm [RFC6206]. A GRASP device with multiple link-layer interfaces (typically a router) MUST support synchronization flooding on all GRASP interfaces. If it receives a multicast Flood Synchronization message on a given interface, it MUST relay it by re-issuing a Flood Synchronization message as a link-local multicast on its other GRASP interfaces. The relayed message MUST have the same Session ID as the incoming message and MUST be tagged with the IP address of its original initiator. Link-layer Flooding is supported by GRASP by setting the loop count to 1, and sending with a link-local source address. Floods with link-local source addresses and a loop count other than 1 are invalid, and such messages MUST be discarded. The relaying device MUST decrement the loop count within the first objective, and MUST NOT relay the Flood Synchronization message if the result is zero. Also, it MUST limit the total rate at which it relays Flood Synchronization messages to a reasonable value, in order to mitigate possible denial of service attacks. For example, the rate limit could be set to a small multiple of the observed rate of flood messages during normal operation. The relaying device MUST cache the Session ID value and initiator address of each relayed Flood Synchronization message for a time not less than twice GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay a Flood Synchronization message which carries a given cached Session ID and initiator address more than once. These precautions avoid synchronization loops and mitigate potential overload. Note that this mechanism is unreliable in the case of sleeping nodes, or new nodes that join the network, or nodes that rejoin the network after a fault. An ASA that initiates a flood SHOULD repeat the flood at a suitable frequency, which MUST be consistent with the recommendations in [RFC8085] for low data-volume multicast. The ASA SHOULD also act as a synchronization responder for the objective(s) concerned. Thus nodes that require an objective subject to flooding can either wait for the next flood or request unicast synchronization for that objective. Bormann, et al. Expires January 8, 2018 [Page 22] Internet-Draft GRASP July 2017 The multicast messages for synchronization flooding are subject to the security rules in Section 2.5.1. In practice this means that they MUST NOT be transmitted and MUST be ignored on receipt unless there is an operational ACP or equivalent strong security in place. However, because of the security weakness of link-local multicast (Section 4), synchronization objectives that are flooded SHOULD NOT contain unencrypted private information and SHOULD be validated by the recipient ASA. 2.5.6.3. Rapid Mode (Discovery/Synchronization Linkage) A Discovery message MAY include a Synchronization Objective option. In this case the Discovery message also acts as a Request Synchronization message to indicate to the Discovery Responder that it could directly reply to the Discovery Initiator with a Synchronization message Section 2.8.10 with synchronization data for rapid processing, if the discovery target supports the corresponding synchronization objective. The design implications are similar to those discussed in Section 2.5.5.1. It is possible that a Discovery Response will arrive from a responder that does not support rapid mode, before such a Synchronization message arrives. In this case, rapid mode will not occur. This rapid mode could reduce the interactions between nodes so that a higher efficiency could be achieved. However, a network in which some nodes support rapid mode and others do not will have complex timing-dependent behaviors. Therefore, the rapid synchronization function SHOULD be configured off by default and MAY be configured on or off by Intent. 2.6. GRASP Constants o ALL_GRASP_NEIGHBORS A link-local scope multicast address used by a GRASP-enabled device to discover GRASP-enabled neighbor (i.e., on-link) devices. All devices that support GRASP are members of this multicast group. * IPv6 multicast address: TBD1 * IPv4 multicast address: TBD2 o GRASP_LISTEN_PORT (TBD3) A well-known UDP user port that every GRASP-enabled network device MUST listen to for link-local multicasts when UDP is used for Bormann, et al. Expires January 8, 2018 [Page 23] Internet-Draft GRASP July 2017 M_DISCOVERY or M_FLOOD messages in the GRASP instance This user port MAY also be used to listen for TCP or UDP unicast messages in a simple implementation of GRASP (Section 2.5.3). o GRASP_DEF_TIMEOUT (60000 milliseconds) The default timeout used to determine that an operation has failed to complete. o GRASP_DEF_LOOPCT (6) The default loop count used to determine that a negotiation has failed to complete, and to avoid looping messages. o GRASP_DEF_MAX_SIZE (2048) The default maximum message size in bytes. 2.7. Session Identifier (Session ID) This is an up to 32-bit opaque value used to distinguish multiple sessions between the same two devices. A new Session ID MUST be generated by the initiator for every new Discovery, Flood Synchronization or Request message. All responses and follow-up messages in the same discovery, synchronization or negotiation procedure MUST carry the same Session ID. The Session ID SHOULD have a very low collision rate locally. It MUST be generated by a pseudo-random number generator (PRNG) using a locally generated seed which is unlikely to be used by any other device in the same network. The PRNG SHOULD be cryptographically strong [RFC4086]. When allocating a new Session ID, GRASP MUST check that the value is not already in use and SHOULD check that it has not been used recently, by consulting a cache of current and recent sessions. In the unlikely event of a clash, GRASP MUST generate a new value. However, there is a finite probability that two nodes might generate the same Session ID value. For that reason, when a Session ID is communicated via GRASP, the receiving node MUST tag it with the initiator's IP address to allow disambiguation. In the highly unlikely event of two peers opening sessions with the same Session ID value, this tag will allow the two sessions to be distinguished. Multicast GRASP messages and their responses, which may be relayed between links, therefore include a field that carries the initiator's global IP address. Bormann, et al. Expires January 8, 2018 [Page 24] Internet-Draft GRASP July 2017 There is a highly unlikely race condition in which two peers start simultaneous negotiation sessions with each other using the same Session ID value. Depending on various implementation choices, this might lead to the two sessions being confused. See Section 2.8.6 for details of how to avoid this. 2.8. GRASP Messages 2.8.1. Message Overview This section defines the GRASP message format and message types. Message types not listed here are reserved for future use. The messages currently defined are: Discovery and Discovery Response (M_DISCOVERY, M_RESPONSE). Request Negotiation, Negotiation, Confirm Waiting and Negotiation End (M_REQ_NEG, M_NEGOTIATE, M_WAIT, M_END). Request Synchronization, Synchronization, and Flood Synchronization (M_REQ_SYN, M_SYNCH, M_FLOOD. No Operation and Invalid (M_NOOP, M_INVALID). 2.8.2. GRASP Message Format GRASP messages share an identical header format and a variable format area for options. GRASP message headers and options are transmitted in Concise Binary Object Representation (CBOR) [RFC7049]. In this specification, they are described using CBOR data definition language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is used to describe each item in this section. A complete and normative CDDL specification of GRASP is given in Section 5, including constants such as message types. Every GRASP message, except the No Operation message, carries a Session ID (Section 2.7). Options are then presented serially in the options field. In fragmentary CDDL, every GRASP message follows the pattern: Bormann, et al. Expires January 8, 2018 [Page 25] Internet-Draft GRASP July 2017 grasp-message = (message .within message-structure) / noop-message message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option] MESSAGE_TYPE = 1..255 session-id = 0..4294967295 ;up to 32 bits grasp-option = any The MESSAGE_TYPE indicates the type of the message and thus defines the expected options. Any options received that are not consistent with the MESSAGE_TYPE SHOULD be silently discarded. The No Operation (noop) message is described in Section 2.8.13. The various MESSAGE_TYPE values are defined in Section 5. All other message elements are described below and formally defined in Section 5. If an unrecognized MESSAGE_TYPE is received in a unicast message, an Invalid message (Section 2.8.12) MAY be returned. Otherwise the message MAY be logged and MUST be discarded. If an unrecognized MESSAGE_TYPE is received in a multicast message, it MAY be logged and MUST be silently discarded. 2.8.3. Message Size GRASP nodes MUST be able to receive unicast messages of at least GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send unicast messages longer than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly allowed for the objective concerned. For example, GRASP negotiation itself could be used to agree on a longer message size. The message parser used by GRASP should be configured to know about the GRASP_DEF_MAX_SIZE, or any larger negotiated message size, so that it may defend against overly long messages. The maximum size of multicast messages (M_DISCOVERY and M_FLOOD) depends on the link layer technology or link adaptation layer in use. 2.8.4. Discovery Message In fragmentary CDDL, a Discovery message follows the pattern: discovery-message = [M_DISCOVERY, session-id, initiator, objective] Bormann, et al. Expires January 8, 2018 [Page 26] Internet-Draft GRASP July 2017 A discovery initiator sends a Discovery message to initiate a discovery process for a particular objective option. The discovery initiator sends all Discovery messages via UDP to port GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBORS multicast address on each link-layer interface in use by GRASP. It then listens for unicast TCP responses on a given port, and stores the discovery results (including responding discovery objectives and corresponding unicast locators). The listening port used for TCP MUST be the same port as used for sending the Discovery UDP multicast, on a given interface. In an implementation with a single GRASP instance in a node this MAY be GRASP_LISTEN_PORT. To support multiple instances in the same node, the GRASP discovery mechanism in each instance needs to find, for each interface, a dynamic port that it can bind to for both sending UDP link-local multicast and listening for TCP, before initiating any discovery. The 'initiator' field in the message is a globally unique IP address of the initiator, for the sole purpose of disambiguating the Session ID in other nodes. If for some reason the initiator does not have a globally unique IP address, it MUST use a link-local address for this purpose that is highly likely to be unique, for example using [RFC7217]. Determination of a node's globally unique IP address is implementation-dependent. A Discovery message MUST include exactly one of the following: o a discovery objective option (Section 2.10.1). Its loop count MUST be set to a suitable value to prevent discovery loops (default value is GRASP_DEF_LOOPCT). If the discovery initiator requires only on-link responses, the loop count MUST be set to 1. o a negotiation objective option (Section 2.10.1). This is used both for the purpose of discovery and to indicate to the discovery target that it MAY directly reply to the discovery initiatior with a Negotiation message for rapid processing, if it could act as the corresponding negotiation counterpart. The sender of such a Discovery message MUST initialize a negotiation timer and loop count in the same way as a Request Negotiation message (Section 2.8.6). o a synchronization objective option (Section 2.10.1). This is used both for the purpose of discovery and to indicate to the discovery target that it MAY directly reply to the discovery initiator with a Synchronization message for rapid processing, if it could act as the corresponding synchronization counterpart. Its loop count Bormann, et al. Expires January 8, 2018 [Page 27] Internet-Draft GRASP July 2017 MUST be set to a suitable value to prevent discovery loops (default value is GRASP_DEF_LOOPCT). As mentioned in Section 2.5.4.2, a Discovery message MAY be sent unicast to a peer node, which SHOULD then proceed exactly as if the message had been multicast. 2.8.5. Discovery Response Message In fragmentary CDDL, a Discovery Response message follows the pattern: response-message = [M_RESPONSE, session-id, initiator, ttl, (+locator-option // divert-option), ?objective)] ttl = 0..4294967295 ; in milliseconds A node which receives a Discovery message SHOULD send a Discovery Response message if and only if it can respond to the discovery. It MUST contain the same Session ID and initiator as the Discovery message. It MUST contain a time-to-live (ttl) for the validity of the response, given as a positive integer value in milliseconds. Zero implies a value significantly greater than GRASP_DEF_TIMEOUT milliseconds (Section 2.6). A suggested value is ten times that amount. It MAY include a copy of the discovery objective from the Discovery message. It is sent to the sender of the Discovery message via TCP at the port used to send the Discovery message (as explained in Section 2.8.4). In the case of a relayed Discovery message, the Discovery Response is thus sent to the relay, not the original initiator. In all cases, the transport session SHOULD be closed after sending the Discovery Response. A transport session failure is treated as no response. If the responding node supports the discovery objective of the discovery, it MUST include at least one kind of locator option (Section 2.9.5) to indicate its own location. A sequence of multiple kinds of locator options (e.g. IP address option and FQDN option) is also valid. Bormann, et al. Expires January 8, 2018 [Page 28] Internet-Draft GRASP July 2017 If the responding node itself does not support the discovery objective, but it knows the locator of the discovery objective, then it SHOULD respond to the discovery message with a divert option (Section 2.9.2) embedding a locator option or a combination of multiple kinds of locator options which indicate the locator(s) of the discovery objective. More details on the processing of Discovery Responses are given in Section 2.5.4. 2.8.6. Request Messages In fragmentary CDDL, Request Negotiation and Request Synchronization messages follow the patterns: request-negotiation-message = [M_REQ_NEG, session-id, objective] request-synchronization-message = [M_REQ_SYN, session-id, objective] A negotiation or synchronization requesting node sends the appropriate Request message to the unicast address of the negotiation or synchronization counterpart, using the appropriate protocol and port numbers (selected from the discovery result). If the discovery result is an FQDN, it will be resolved first. A Request message MUST include the relevant objective option. In the case of Request Negotiation, the objective option MUST include the requested value. When an initiator sends a Request Negotiation message, it MUST initialize a negotiation timer for the new negotiation thread. The default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a Confirm Waiting message (Section 2.8.9), the initiator will consider that the negotiation has failed when the timer expires. Similarly, when an initiator sends a Request Synchronization, it SHOULD initialize a synchronization timer. The default is GRASP_DEF_TIMEOUT milliseconds. The initiator will consider that synchronization has failed if there is no response before the timer expires. When an initiator sends a Request message, it MUST initialize the loop count of the objective option with a value defined in the specification of the option or, if no such value is specified, with GRASP_DEF_LOOPCT. Bormann, et al. Expires January 8, 2018 [Page 29] Internet-Draft GRASP July 2017 If a node receives a Request message for an objective for which no ASA is currently listening, it MUST immediately close the relevant socket to indicate this to the initiator. This is to avoid unnecessary timeouts if, for example, an ASA exits prematurely but the GRASP core is listening on its behalf. To avoid the highly unlikely race condition in which two nodes simultaneously request sessions with each other using the same Session ID (Section 2.7), when a node receives a Request message, it MUST verify that the received Session ID is not already locally active. In case of a clash, it MUST discard the Request message, in which case the initiator will detect a timeout. 2.8.7. Negotiation Message In fragmentary CDDL, a Negotiation message follows the pattern: negotiate-message = [M_NEGOTIATE, session-id, objective] A negotiation counterpart sends a Negotiation message in response to a Request Negotiation message, a Negotiation message, or a Discovery message in Rapid Mode. A negotiation process MAY include multiple steps. The Negotiation message MUST include the relevant Negotiation Objective option, with its value updated according to progress in the negotiation. The sender MUST decrement the loop count by 1. If the loop count becomes zero the message MUST NOT be sent. In this case the negotiation session has failed and will time out. 2.8.8. Negotiation End Message In fragmentary CDDL, a Negotiation End message follows the pattern: end-message = [M_END, session-id, accept-option / decline-option] A negotiation counterpart sends an Negotiation End message to close the negotiation. It MUST contain either an accept or a decline option, defined in Section 2.9.3 and Section 2.9.4. It could be sent either by the requesting node or the responding node. 2.8.9. Confirm Waiting Message In fragmentary CDDL, a Confirm Waiting message follows the pattern: wait-message = [M_WAIT, session-id, waiting-time] waiting-time = 0..4294967295 ; in milliseconds Bormann, et al. Expires January 8, 2018 [Page 30] Internet-Draft GRASP July 2017 A responding node sends a Confirm Waiting message to ask the requesting node to wait for a further negotiation response. It might be that the local process needs more time or that the negotiation depends on another triggered negotiation. This message MUST NOT include any other options. When received, the waiting time value overwrites and restarts the current negotiation timer (Section 2.8.6). The responding node SHOULD send a Negotiation, Negotiation End or another Confirm Waiting message before the negotiation timer expires. If not, when the initiator's timer expires, the initiator MUST treat the negotiation procedure as failed. 2.8.10. Synchronization Message In fragmentary CDDL, a Synchronization message follows the pattern: synch-message = [M_SYNCH, session-id, objective] A node which receives a Request Synchronization, or a Discovery message in Rapid Mode, sends back a unicast Synchronization message with the synchronization data, in the form of a GRASP Option for the specific synchronization objective present in the Request Synchronization. 2.8.11. Flood Synchronization Message In fragmentary CDDL, a Flood Synchronization message follows the pattern: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] ttl = 0..4294967295 ; in milliseconds A node MAY initiate flooding by sending an unsolicited Flood Synchronization Message with synchronization data. This MAY be sent to port GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBORS multicast address, in accordance with the rules in Section 2.5.6. The initiator address is provided, as described for Discovery messages (Section 2.8.4), only to disambiguate the Session ID. The message MUST contain a time-to-live (ttl) for the validity of the contents, given as a positive integer value in milliseconds. There is no default; zero indicates an indefinite lifetime. Bormann, et al. Expires January 8, 2018 [Page 31] Internet-Draft GRASP July 2017 The synchronization data are in the form of GRASP Option(s) for specific synchronization objective(s). The loop count(s) MUST be set to a suitable value to prevent flood loops (default value is GRASP_DEF_LOOPCT). Each objective option MAY be followed by a locator option associated with the flooded objective. In its absence, an empty option MUST be included to indicate a null locator. A node that receives a Flood Synchronization message MUST cache the received objectives for use by local ASAs. Each cached objective MUST be tagged with the locator option sent with it, or with a null tag if an empty locator option was sent. If a subsequent Flood Synchronization message carrying an objective with same name and the same tag, the corresponding cached copy of the objective MUST be overwritten. If a subsequent Flood Synchronization message carrying an objective with same name arrives with a different tag, a new cached entry MUST be created. Note: the purpose of this mechanism is to allow the recipient of flooded values to distinguish between different senders of the same objective, and if necessary communicate with them using the locator, protocol and port included in the locator option. Many objectives will not need this mechanism, so they will be flooded with a null locator. Cached entries MUST be ignored or deleted after their lifetime expires. 2.8.12. Invalid Message In fragmentary CDDL, an Invalid message follows the pattern: invalid-message = [M_INVALID, session-id, ?any] This message MAY be sent by an implementation in response to an incoming unicast message that it considers invalid. The session-id MUST be copied from the incoming message. The content SHOULD be diagnostic information such as a partial copy of the invalid message up to the maximum message size. An M_INVALID message MAY be silently ignored by a recipient. However, it could be used in support of extensibility, since it indicates that the remote node does not support a new or obsolete message or option. An M_INVALID message MUST NOT be sent in response to an M_INVALID message. Bormann, et al. Expires January 8, 2018 [Page 32] Internet-Draft GRASP July 2017 2.8.13. No Operation Message In fragmentary CDDL, a No Operation message follows the pattern: noop-message = [M_NOOP] This message MAY be sent by an implementation that for practical reasons needs to initialize a socket. It MUST be silently ignored by a recipient. 2.9. GRASP Options This section defines the GRASP options for the negotiation and synchronization protocol signaling. Additional options may be defined in the future. 2.9.1. Format of GRASP Options GRASP options are CBOR objects that MUST start with an unsigned integer identifying the specific option type carried in this option. These option types are formally defined in Section 5. Apart from that the only format requirement is that each option MUST be a well- formed CBOR object. In general a CBOR array format is RECOMMENDED to limit overhead. GRASP options may be defined to include encapsulated GRASP options. 2.9.2. Divert Option The Divert option is used to redirect a GRASP request to another node, which may be more appropriate for the intended negotiation or synchronization. It may redirect to an entity that is known as a specific negotiation or synchronization counterpart (on-link or off- link) or a default gateway. The divert option MUST only be encapsulated in Discovery Response messages. If found elsewhere, it SHOULD be silently ignored. A discovery initiator MAY ignore a Divert option if it only requires direct discovery responses. In fragmentary CDDL, the Divert option follows the pattern: divert-option = [O_DIVERT, +locator-option] The embedded Locator Option(s) (Section 2.9.5) point to diverted destination target(s) in response to a Discovery message. Bormann, et al. Expires January 8, 2018 [Page 33] Internet-Draft GRASP July 2017 2.9.3. Accept Option The accept option is used to indicate to the negotiation counterpart that the proposed negotiation content is accepted. The accept option MUST only be encapsulated in Negotiation End messages. If found elsewhere, it SHOULD be silently ignored. In fragmentary CDDL, the Accept option follows the pattern: accept-option = [O_ACCEPT] 2.9.4. Decline Option The decline option is used to indicate to the negotiation counterpart the proposed negotiation content is declined and end the negotiation process. The decline option MUST only be encapsulated in Negotiation End messages. If found elsewhere, it SHOULD be silently ignored. In fragmentary CDDL, the Decline option follows the pattern: decline-option = [O_DECLINE, ?reason] reason = text ;optional UTF-8 error message Note: there might be scenarios where an ASA wants to decline the proposed value and restart the negotiation process. In this case it is an implementation choice whether to send a Decline option or to continue with a Negotiate message, with an objective option that contains a null value, or one that contains a new value that might achieve convergence. 2.9.5. Locator Options These locator options are used to present reachability information for an ASA, a device or an interface. They are Locator IPv6 Address Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified Domain Name) Option and URI (Uniform Resource Identifier) Option. Since ASAs will normally run as independent user programs, locator options need to indicate the network layer locator plus the transport protocol and port number for reaching the target. For this reason, the Locator Options for IP addresses and FQDNs include this information explicitly. In the case of the URI Option, this information can be encoded in the URI itself. Bormann, et al. Expires January 8, 2018 [Page 34] Internet-Draft GRASP July 2017 Note: It is assumed that all locators used in locator options are in scope throughout the GRASP domain. As stated in Section 2.2, GRASP is not intended to work across disjoint addressing or naming realms. 2.9.5.1. Locator IPv6 address option In fragmentary CDDL, the IPv6 address option follows the pattern: ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number] ipv6-address = bytes .size 16 transport-proto = IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 port-number = 0..65535 The content of this option is a binary IPv6 address followed by the protocol number and port number to be used. Note 1: The IPv6 address MUST normally have global scope. However, during initialization, a link-local address MAY be used for specific objectives only (Section 2.5.2). In this case the corresponding Discovery Response message MUST be sent via the interface to which the link-local address applies. Note 2: A link-local IPv6 address MUST NOT be used when this option is included in a Divert option. Note 3: The IPPROTO values are taken from the existing IANA Protocol Numbers registry in order to specify TCP or UDP. If GRASP requires future values that are not in that registry, a new registry for values outside the range 0..255 will be needed. 2.9.5.2. Locator IPv4 address option In fragmentary CDDL, the IPv4 address option follows the pattern: ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, transport-proto, port-number] ipv4-address = bytes .size 4 The content of this option is a binary IPv4 address followed by the protocol number and port number to be used. Note: If an operator has internal network address translation for IPv4, this option MUST NOT be used within the Divert option. Bormann, et al. Expires January 8, 2018 [Page 35] Internet-Draft GRASP July 2017 2.9.5.3. Locator FQDN option In fragmentary CDDL, the FQDN option follows the pattern: fqdn-locator-option = [O_FQDN_LOCATOR, text, transport-proto, port-number] The content of this option is the Fully Qualified Domain Name of the target followed by the protocol number and port number to be used. Note 1: Any FQDN which might not be valid throughout the network in question, such as a Multicast DNS name [RFC6762], MUST NOT be used when this option is used within the Divert option. Note 2: Normal GRASP operations are not expected to use this option. It is intended for special purposes such as discovering external services. 2.9.5.4. Locator URI option In fragmentary CDDL, the URI option follows the pattern: uri-locator = [O_URI_LOCATOR, text, transport-proto / null, port-number / null] The content of this option is the Uniform Resource Identifier of the target followed by the protocol number and port number to be used (or by null values if not required) [RFC3986]. Note 1: Any URI which might not be valid throughout the network in question, such as one based on a Multicast DNS name [RFC6762], MUST NOT be used when this option is used within the Divert option. Note 2: Normal GRASP operations are not expected to use this option. It is intended for special purposes such as discovering external services. Therefore its use is not further described in this specification. 2.10. Objective Options 2.10.1. Format of Objective Options An objective option is used to identify objectives for the purposes of discovery, negotiation or synchronization. All objectives MUST be in the following format, described in fragmentary CDDL: Bormann, et al. Expires January 8, 2018 [Page 36] Internet-Draft GRASP July 2017 objective = [objective-name, objective-flags, loop-count, ?objective-value] objective-name = text objective-value = any loop-count = 0..255 All objectives are identified by a unique name which is a UTF-8 string [RFC3629], to be compared byte by byte. The names of generic objectives MUST NOT include a colon (":") and MUST be registered with IANA (Section 6). The names of privately defined objectives MUST include at least one colon (":"). The string preceding the last colon in the name MUST be globally unique and in some way identify the entity or person defining the objective. The following three methods MAY be used to create such a globally unique string: 1. The unique string is a decimal number representing a registered 32 bit Private Enterprise Number (PEN) [RFC5612] that uniquely identifies the enterprise defining the objective. 2. The unique string is a fully qualified domain name that uniquely identifies the entity or person defining the objective. 3. The unique string is an email address that uniquely identifies the entity or person defining the objective. The GRASP protocol treats the objective name as an opaque string. For example, "EX1", "32473:EX1", "example.com:EX1", "example.org:EX1 and "user@example.org:EX1" would be five different objectives. The 'objective-flags' field is described below. The 'loop-count' field is used for terminating negotiation as described in Section 2.8.7. It is also used for terminating discovery as described in Section 2.5.4, and for terminating flooding as described in Section 2.5.6.2. It is placed in the objective rather than in the GRASP message format because, as far as the ASA is concerned, it is a property of the objective itself. The 'objective-value' field is to express the actual value of a negotiation or synchronization objective. Its format is defined in the specification of the objective and may be a simple value or a data structure of any kind, as long as it can be represented in CBOR. It is optional because it is optional in a Discovery or Discovery Response message. Bormann, et al. Expires January 8, 2018 [Page 37] Internet-Draft GRASP July 2017 2.10.2. Objective flags An objective may be relevant for discovery only, for discovery and negotiation, or for discovery and synchronization. This is expressed in the objective by logical flag bits: objective-flags = uint .bits objective-flag objective-flag = &( F_DISC: 0 ; valid for discovery F_NEG: 1 ; valid for negotiation F_SYNCH: 2 ; valid for synchronization F_NEG_DRY: 3 ; negotiation is dry-run ) These bits are independent and may be combined appropriately, e.g. (F_DISC and F_SYNCH) or (F_DISC and F_NEG) or (F_DISC and F_NEG and F_NEG_DRY). Note that for a given negotiation session, an objective must be either used for negotiation, or for dry-run negotiation. Mixing the two modes in a single negotiation is not possible. 2.10.3. General Considerations for Objective Options As mentioned above, Objective Options MUST be assigned a unique name. As long as privately defined Objective Options obey the rules above, this document does not restrict their choice of name, but the entity or person concerned SHOULD publish the names in use. Names are expressed as UTF-8 strings for convenience in designing Objective Options for localized use. For generic usage, names expressed in the ASCII subset of UTF-8 are RECOMMENDED. Designers planning to use non-ASCII names are strongly advised to consult [RFC7564] or its successor to understand the complexities involved. Since the GRASP protocol compares names byte by byte, all issues of Unicode profiling and canonicalization MUST be specified in the design of the Objective Option. All Objective Options MUST respect the CBOR patterns defined above as "objective" and MUST replace the "any" field with a valid CBOR data definition for the relevant use case and application. An Objective Option that contains no additional fields beyond its "loop-count" can only be a discovery objective and MUST only be used in Discovery and Discovery Response messages. The Negotiation Objective Options contain negotiation objectives, which vary according to different functions/services. They MUST be Bormann, et al. Expires January 8, 2018 [Page 38] Internet-Draft GRASP July 2017 carried by Discovery, Request Negotiation or Negotiation messages only. The negotiation initiator MUST set the initial "loop-count" to a value specified in the specification of the objective or, if no such value is specified, to GRASP_DEF_LOOPCT. For most scenarios, there should be initial values in the negotiation requests. Consequently, the Negotiation Objective options MUST always be completely presented in a Request Negotiation message, or in a Discovery message in rapid mode. If there is no initial value, the value field SHOULD be set to the 'null' value defined by CBOR. Synchronization Objective Options are similar, but MUST be carried by Discovery, Discovery Response, Request Synchronization, or Flood Synchronization messages only. They include value fields only in Synchronization or Flood Synchronization messages. The design of an objective interacts in various ways with the design of the ASAs that will use it. ASA design considerations are discussed in [I-D.carpenter-anima-asa-guidelines]. 2.10.4. Organizing of Objective Options Generic objective options MUST be specified in documents available to the public and SHOULD be designed to use either the negotiation or the synchronization mechanism described above. As noted earlier, one negotiation objective is handled by each GRASP negotiation thread. Therefore, a negotiation objective, which is based on a specific function or action, SHOULD be organized as a single GRASP option. It is NOT RECOMMENDED to organize multiple negotiation objectives into a single option, nor to split a single function or action into multiple negotiation objectives. It is important to understand that GRASP negotiation does not support transactional integrity. If transactional integrity is needed for a specific objective, this must be ensured by the ASA. For example, an ASA might need to ensure that it only participates in one negotiation thread at the same time. Such an ASA would need to stop listening for incoming negotiation requests before generating an outgoing negotiation request. A synchronization objective SHOULD be organized as a single GRASP option. Some objectives will support more than one operational mode. An example is a negotiation objective with both a "dry run" mode (where the negotiation is to find out whether the other end can in fact make the requested change without problems) and a "live" mode, as Bormann, et al. Expires January 8, 2018 [Page 39] Internet-Draft GRASP July 2017 explained in Section 2.5.5. The semantics of such modes will be defined in the specification of the objectives. These objectives SHOULD include flags indicating the applicable mode(s). An issue requiring particular attention is that GRASP itself is not a transactionally safe protocol. Any state associated with a dry run operation, such as temporarily reserving a resource for subsequent use in a live run, is entirely a matter for the designer of the ASA concerned. As indicated in Section 2.1, an objective's value may include multiple parameters. Parameters might be categorized into two classes: the obligatory ones presented as fixed fields; and the optional ones presented in some other form of data structure embedded in CBOR. The format might be inherited from an existing management or configuration protocol, with the objective option acting as a carrier for that format. The data structure might be defined in a formal language, but that is a matter for the specifications of individual objectives. There are many candidates, according to the context, such as ABNF, RBNF, XML Schema, YANG, etc. The GRASP protocol itself is agnostic on these questions. The only restriction is that the format can be mapped into CBOR. It is NOT RECOMMENDED to mix parameters that have significantly different response time characteristics in a single objective. Separate objectives are more suitable for such a scenario. All objectives MUST support GRASP discovery. However, as mentioned in Section 2.3, it is acceptable for an ASA to use an alternative method of discovery. Normally, a GRASP objective will refer to specific technical parameters as explained in Section 2.1. However, it is acceptable to define an abstract objective for the purpose of managing or coordinating ASAs. It is also acceptable to define a special-purpose objective for purposes such as trust bootstrapping or formation of the ACP. To guarantee convergence, a limited number of rounds or a timeout is needed for each negotiation objective. Therefore, the definition of each negotiation objective SHOULD clearly specify this, for example a default loop count and timeout, so that the negotiation can always be terminated properly. If not, the GRASP defaults will apply. There must be a well-defined procedure for concluding that a negotiation cannot succeed, and if so deciding what happens next (e.g., deadlock resolution, tie-breaking, or revert to best-effort Bormann, et al. Expires January 8, 2018 [Page 40] Internet-Draft GRASP July 2017 service). This MUST be specified for individual negotiation objectives. 2.10.5. Experimental and Example Objective Options The names "EX0" through "EX9" have been reserved for experimental options. Multiple names have been assigned because a single experiment may use multiple options simultaneously. These experimental options are highly likely to have different meanings when used for different experiments. Therefore, they SHOULD NOT be used without an explicit human decision and MUST NOT be used in unmanaged networks such as home networks. These names are also RECOMMENDED for use in documentation examples. 3. Implementation Status [RFC Editor: please remove] Two prototype implementations of GRASP have been made. 3.1. BUPT C++ Implementation o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp o Description: C++ implementation of GRASP core and API o Maturity: Prototype code, interoperable between Ubuntu. o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03. Since it was implemented based on the old version draft, the most significant limitations comparing to current protocol design include: * Not support CBOR * Not support Flooding * Not support loop avoidance * only coded for IPv6, any IPv4 is accidental o Licensing: Huawei License. o Experience: https://github.com/liubingpang/IETF-Anima-Signaling- Protocol/blob/master/README.md o Contact: https://github.com/liubingpang/IETF-Anima-Signaling- Protocol Bormann, et al. Expires January 8, 2018 [Page 41] Internet-Draft GRASP July 2017 3.2. Python Implementation o Name: graspy o Description: Python 3 implementation of GRASP core and API. o Maturity: Prototype code, interoperable between Windows 7 and Linux. o Coverage: Corresponds to draft-ietf-anima-grasp-13. Limitations include: * insecure: uses a dummy ACP module * only coded for IPv6, any IPv4 is accidental * FQDN and URI locators incompletely supported * no code for rapid mode * relay code is lazy (no rate control) * all unicast transactions use TCP (no unicast UDP). Experimental code for unicast UDP proved to be complex and brittle. * optional Objective option in Response messages not implemented * workarounds for defects in Python socket module and Windows socket peculiarities o Licensing: Simplified BSD o Experience: Tested on Windows, Linux and MacOS. https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ 4. Security Considerations A successful attack on negotiation-enabled nodes would be extremely harmful, as such nodes might end up with a completely undesirable configuration that would also adversely affect their peers. GRASP nodes and messages therefore require full protection. As explained in Section 2.5.1, GRASP MUST run within a secure environment such as the Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], except for the constrained instances described in Section 2.5.2. Bormann, et al. Expires January 8, 2018 [Page 42] Internet-Draft GRASP July 2017 - Authentication A cryptographically authenticated identity for each device is needed in an autonomic network. It is not safe to assume that a large network is physically secured against interference or that all personnel are trustworthy. Each autonomic node MUST be capable of proving its identity and authenticating its messages. GRASP relies on a separate external certificate-based security mechanism to support authentication, data integrity protection, and anti-replay protection. Since GRASP must be deployed in an existing secure environment, the protocol itself specifies nothing concerning the trust anchor and certification authority. For example, in the Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], all nodes can trust each other and the ASAs installed in them. If GRASP is used temporarily without an external security mechanism, for example during system bootstrap (Section 2.5.1), the Session ID (Section 2.7) will act as a nonce to provide limited protection against third parties injecting responses. A full analysis of the secure bootstrap process is in [I-D.ietf-anima-bootstrapping-keyinfra]. - Authorization and Roles The GRASP protocol is agnostic about the roles and capabilities of individual ASAs and about which objectives a particular ASA is authorized to support. An implementation might support precautions such as allowing only one ASA in a given node to modify a given objective, but this may not be appropriate in all cases. For example, it might be operationally useful to allow an old and a new version of the same ASA to run simultaneously during an overlap period. These questions are out of scope for the present specification. - Privacy and confidentiality GRASP is intended for network management purposes involving network elements, not end hosts. Therefore, no personal information is expected to be involved in the signaling protocol, so there should be no direct impact on personal privacy. Nevertheless, applications that do convey personal information cannot be excluded. Also, traffic flow paths, VPNs, etc. could be negotiated, which could be of interest for traffic analysis. Operators generally want to conceal details of their network topology and traffic density from outsiders. Therefore, since insider attacks cannot be excluded in a large network, the Bormann, et al. Expires January 8, 2018 [Page 43] Internet-Draft GRASP July 2017 security mechanism for the protocol MUST provide message confidentiality. This is why Section 2.5.1 requires either an ACP or an alternative security mechanism. - Link-local multicast security GRASP has no reasonable alternative to using link-local multicast for Discovery or Flood Synchronization messages and these messages are sent in clear and with no authentication. They are only sent on interfaces within the autonomic network (see Section 2.1 and Section 2.5.1). They are however available to on-link eavesdroppers, and could be forged by on-link attackers. In the case of Discovery, the Discovery Responses are unicast and will therefore be protected (Section 2.5.1), and an untrusted forger will not be able to receive responses. In the case of Flood Synchronization, an on-link eavesdropper will be able to receive the flooded objectives but there is no response message to consider. Some precautions for Flood Synchronization messages are suggested in Section 2.5.6.2. - DoS Attack Protection GRASP discovery partly relies on insecure link-local multicast. Since routers participating in GRASP sometimes relay discovery messages from one link to another, this could be a vector for denial of service attacks. Some mitigations are specified in Section 2.5.4. However, malicious code installed inside the Autonomic Control Plane could always launch DoS attacks consisting of spurious discovery messages, or of spurious discovery responses. It is important that firewalls prevent any GRASP messages from entering the domain from an unknown source. - Security during bootstrap and discovery A node cannot trust GRASP traffic from other nodes until the security environment (such as the ACP) has identified the trust anchor and can authenticate traffic by validating certificates for other nodes. Also, until it has succesfully enrolled [I-D.ietf-anima-bootstrapping-keyinfra] a node cannot assume that other nodes are able to authenticate its own traffic. Therefore, GRASP discovery during the bootstrap phase for a new device will inevitably be insecure. Secure synchronization and negotiation will be impossible until enrollment is complete. Further details are given in Section 2.5.2. - Security of discovered locators Bormann, et al. Expires January 8, 2018 [Page 44] Internet-Draft GRASP July 2017 When GRASP discovery returns an IP address, it MUST be that of a node within the secure environment (Section 2.5.1). If it returns an FQDN or a URI, the ASA that receives it MUST NOT assume that the target of the locator is within the secure environment. 5. CDDL Specification of GRASP grasp-message = (message .within message-structure) / noop-message message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option] MESSAGE_TYPE = 0..255 session-id = 0..4294967295 ;up to 32 bits grasp-option = any message /= discovery-message discovery-message = [M_DISCOVERY, session-id, initiator, objective] message /= response-message ;response to Discovery response-message = [M_RESPONSE, session-id, initiator, ttl, (+locator-option // divert-option), ?objective] message /= synch-message ;response to Synchronization request synch-message = [M_SYNCH, session-id, objective] message /= flood-message flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] message /= request-negotiation-message request-negotiation-message = [M_REQ_NEG, session-id, objective] message /= request-synchronization-message request-synchronization-message = [M_REQ_SYN, session-id, objective] message /= negotiation-message negotiation-message = [M_NEGOTIATE, session-id, objective] message /= end-message end-message = [M_END, session-id, accept-option / decline-option ] message /= wait-message wait-message = [M_WAIT, session-id, waiting-time] message /= invalid-message invalid-message = [M_INVALID, session-id, ?any] Bormann, et al. Expires January 8, 2018 [Page 45] Internet-Draft GRASP July 2017 noop-message = [M_NOOP] divert-option = [O_DIVERT, +locator-option] accept-option = [O_ACCEPT] decline-option = [O_DECLINE, ?reason] reason = text ;optional UTF-8 error message waiting-time = 0..4294967295 ; in milliseconds ttl = 0..4294967295 ; in milliseconds locator-option /= [O_IPv4_LOCATOR, ipv4-address, transport-proto, port-number] ipv4-address = bytes .size 4 locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number] ipv6-address = bytes .size 16 locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number] locator-option /= [O_URI_LOCATOR, text, transport-proto / null, port-number / null] transport-proto = IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 port-number = 0..65535 initiator = ipv4-address / ipv6-address objective-flags = uint .bits objective-flag objective-flag = &( F_DISC: 0 ; valid for discovery F_NEG: 1 ; valid for negotiation F_SYNCH: 2 ; valid for synchronization F_NEG_DRY: 3 ; negotiation is dry-run ) objective = [objective-name, objective-flags, loop-count, ?objective-value] objective-name = text ;see section "Format of Objective Options" objective-value = any loop-count = 0..255 Bormann, et al. Expires January 8, 2018 [Page 46] Internet-Draft GRASP July 2017 ; Constants for message types and option types M_NOOP = 0 M_DISCOVERY = 1 M_RESPONSE = 2 M_REQ_NEG = 3 M_REQ_SYN = 4 M_NEGOTIATE = 5 M_END = 6 M_WAIT = 7 M_SYNCH = 8 M_FLOOD = 9 M_INVALID = 99 O_DIVERT = 100 O_ACCEPT = 101 O_DECLINE = 102 O_IPv6_LOCATOR = 103 O_IPv4_LOCATOR = 104 O_FQDN_LOCATOR = 105 O_URI_LOCATOR = 106 6. IANA Considerations This document defines the GeneRic Autonomic Signaling Protocol (GRASP). Section 2.6 explains the following link-local multicast addresses, which IANA is requested to assign for use by GRASP: ALL_GRASP_NEIGHBORS multicast address (IPv6): (TBD1). Assigned in the IPv6 Link-Local Scope Multicast Addresses registry. ALL_GRASP_NEIGHBORS multicast address (IPv4): (TBD2). Assigned in the IPv4 Multicast Local Network Control Block. Section 2.6 explains the following User Port, which IANA is requested to assign for use by GRASP for both UDP and TCP: GRASP_LISTEN_PORT: (TBD3) Service Name: Generic Autonomic Signaling Protocol (GRASP) Transport Protocols: UDP, TCP Assignee: iesg@ietf.org Contact: chair@ietf.org Description: See Section 2.6 Reference: RFC XXXX (this document) Bormann, et al. Expires January 8, 2018 [Page 47] Internet-Draft GRASP July 2017 The IANA is requested to create a GRASP Parameter Registry including two registry tables. These are the GRASP Messages and Options Table and the GRASP Objective Names Table. GRASP Messages and Options Table. The values in this table are names paired with decimal integers. Future values MUST be assigned using the Standards Action policy defined by [RFC8126]. The following initial values are assigned by this document: M_NOOP = 0 M_DISCOVERY = 1 M_RESPONSE = 2 M_REQ_NEG = 3 M_REQ_SYN = 4 M_NEGOTIATE = 5 M_END = 6 M_WAIT = 7 M_SYNCH = 8 M_FLOOD = 9 M_INVALID = 99 O_DIVERT = 100 O_ACCEPT = 101 O_DECLINE = 102 O_IPv6_LOCATOR = 103 O_IPv4_LOCATOR = 104 O_FQDN_LOCATOR = 105 O_URI_LOCATOR = 106 GRASP Objective Names Table. The values in this table are UTF-8 strings which MUST NOT include a colon (":"), according to Section 2.10.1. Future values MUST be assigned using the Specification Required policy defined by [RFC8126]. To assist expert review of a new objective, the specification should include a precise description of the format of the new objective, with sufficient explanation of its semantics to allow independent implementations. See Section 2.10.3 for more details. If the new objective is similar in name or purpose to a previously registered objective, the specification should explain why a new objective is justified. The following initial values are assigned by this document: Bormann, et al. Expires January 8, 2018 [Page 48] Internet-Draft GRASP July 2017 EX0 EX1 EX2 EX3 EX4 EX5 EX6 EX7 EX8 EX9 7. Acknowledgements A major contribution to the original version of this document was made by Sheng Jiang and significant contributions were made by Toerless Eckert. Significant early review inputs were received from Joel Halpern, Barry Leiba, Charles E. Perkins, and Michael Richardson. William Atwood provided important assistance in debugging a prototype implementation. Valuable comments were received from Michael Behringer, Jeferson Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Jaeggli, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg, Martin Stiemerling, Rene Struik, Martin Thomson, Dacheng Zhang, and participants in the NMRG research group, the ANIMA working group, and the IESG. 8. References 8.1. Normative References [I-D.greevenbosch-appsawg-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR data structures", draft-greevenbosch-appsawg- cbor-cddl-11 (work in progress), July 2017. [I-D.ietf-anima-autonomic-control-plane] Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Control Plane", draft-ietf-anima-autonomic-control- plane-07 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Bormann, et al. Expires January 8, 2018 [Page 49] Internet-Draft GRASP July 2017 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [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, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 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, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . 8.2. Informative References [I-D.carpenter-anima-asa-guidelines] Carpenter, B. and S. Jiang, "Guidelines for Autonomic Service Agents", draft-carpenter-anima-asa-guidelines-02 (work in progress), July 2017. [I-D.chaparadza-intarea-igcp] Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. Mahkonen, "IP based Generic Control Protocol (IGCP)", draft-chaparadza-intarea-igcp-00 (work in progress), July 2011. [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-07 (work in progress), July 2017. Bormann, et al. Expires January 8, 2018 [Page 50] Internet-Draft GRASP July 2017 [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Reference Model for Autonomic Networking", draft-ietf- anima-reference-model-04 (work in progress), July 2017. [I-D.ietf-anima-stable-connectivity] Eckert, T. and M. Behringer, "Using Autonomic Control Plane for Stable Connectivity of Network OAM", draft-ietf- anima-stable-connectivity-03 (work in progress), July 2017. [I-D.liu-anima-grasp-api] Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", draft-liu-anima-grasp-api-04 (work in progress), June 2017. [I-D.stenberg-anima-adncp] Stenberg, M., "Autonomic Distributed Node Consensus Protocol", draft-stenberg-anima-adncp-00 (work in progress), March 2015. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, DOI 10.17487/RFC2334, April 1998, . [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, DOI 10.17487/RFC2608, June 1999, . [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, . [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, . Bormann, et al. Expires January 8, 2018 [Page 51] Internet-Draft GRASP July 2017 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, DOI 10.17487/RFC3416, December 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, . [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, . [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, . [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, . [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 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, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . Bormann, et al. Expires January 8, 2018 [Page 52] Internet-Draft GRASP July 2017 [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, . [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 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, . [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, . [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, . [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Bormann, et al. Expires January 8, 2018 [Page 53] Internet-Draft GRASP July 2017 Appendix A. Open Issues [RFC Editor: This section should be empty. Please remove] o 68. (Placeholder) Appendix B. Closed Issues [RFC Editor: Please remove] o 1. UDP vs TCP: For now, this specification suggests UDP and TCP as message transport mechanisms. This is not clarified yet. UDP is good for short conversations, is necessary for multicast discovery, and generally fits the discovery and divert scenarios well. However, it will cause problems with large messages. TCP is good for stable and long sessions, with a little bit of time consumption during the session establishment stage. If messages exceed a reasonable MTU, a TCP mode will be required in any case. This question may be affected by the security discussion. RESOLVED by specifying UDP for short message and TCP for longer one. o 2. DTLS or TLS vs built-in security mechanism. For now, this specification has chosen a PKI based built-in security mechanism based on asymmetric cryptography. However, (D)TLS might be chosen as security solution to avoid duplication of effort. It also allows essentially similar security for short messages over UDP and longer ones over TCP. The implementation trade-offs are different. The current approach requires expensive asymmetric cryptographic calculations for every message. (D)TLS has startup overheads but cheaper crypto per message. DTLS is less mature than TLS. RESOLVED by specifying external security (ACP or (D)TLS). o The following open issues applied only if the original security model was retained: * 2.1. For replay protection, GRASP currently requires every participant to have an NTP-synchronized clock. Is this OK for low-end devices, and how does it work during device bootstrapping? We could take the Timestamp out of signature option, to become an independent and OPTIONAL (or RECOMMENDED) option. * 2.2. The Signature Option states that this option could be any place in a message. Wouldn't it be better to specify a position (such as the end)? That would be much simpler to implement. Bormann, et al. Expires January 8, 2018 [Page 54] Internet-Draft GRASP July 2017 RESOLVED by changing security model. o 3. DoS Attack Protection needs work. RESOLVED by adding text. o 4. Should we consider preferring a text-based approach to discovery (after the initial discovery needed for bootstrapping)? This could be a complementary mechanism for multicast based discovery, especially for a very large autonomic network. Centralized registration could be automatically deployed incrementally. At the very first stage, the repository could be empty; then it could be filled in by the objectives discovered by different devices (for example using Dynamic DNS Update). The more records are stored in the repository, the less the multicast- based discovery is needed. However, if we adopt such a mechanism, there would be challenges: stateful solution, and security. RESOLVED for now by adding optional use of DNS-SD by ASAs. Subsequently removed by editors as irrelevant to GRASP istelf. o 5. Need to expand description of the minimum requirements for the specification of an individual discovery, synchronization or negotiation objective. RESOLVED for now by extra wording. o 6. Use case and protocol walkthrough. A description of how a node starts up, performs discovery, and conducts negotiation and synchronisation for a sample use case would help readers to understand the applicability of this specification. Maybe it should be an artificial use case or maybe a simple real one, based on a conceptual API. However, the authors have not yet decided whether to have a separate document or have it in the protocol document. RESOLVED: recommend a separate document. o 7. Cross-check against other ANIMA WG documents for consistency and gaps. RESOLVED: Satisfied by WGLC. o 8. Consideration of ADNCP proposal. RESOLVED by adding optional use of DNCP for flooding-type synchronization. Bormann, et al. Expires January 8, 2018 [Page 55] Internet-Draft GRASP July 2017 o 9. Clarify how a GDNP instance knows whether it is running inside the ACP. (Sheng) RESOLVED by improved text. o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. (Sheng) RESOLVED by improved text and declaring DTLS out of scope for this draft. o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - Brian] RESOLVED by improved text. o 12. Justify that IP address within ACP or (D)TLS environment is sufficient to prove AN identity; or explain how Device Identity Option is used. (Sheng) RESOLVED for now: we assume that all ASAs in a device are trusted as soon as the device is trusted, so they share credentials. In that case the Device Identity Option is useless. This needs to be reviewed later. o 13. Emphasise that negotiation/synchronization are independent from discovery, although the rapid discovery mode includes the first step of a negotiation/synchronization. (Sheng) RESOLVED by improved text. o 14. Do we need an unsolicited flooding mechanism for discovery (for discovery results that everyone needs), to reduce scaling impact of flooding discovery messages? (Toerless) RESOLVED: Yes, added to requirements and solution. o 15. Do we need flag bits in Objective Options to distinguish distinguish Synchronization and Negotiation "Request" or rapid mode "Discovery" messages? (Bing) RESOLVED: yes, work on the API showed that these flags are essential. o 16. (Related to issue 14). Should we revive the "unsolicited Response" for flooding synchronisation data? This has to be done carefully due to the well-known issues with flooding, but it could Bormann, et al. Expires January 8, 2018 [Page 56] Internet-Draft GRASP July 2017 be useful, e.g. for Intent distribution, where DNCP doesn't seem applicable. RESOLVED: Yes, see #14. o 17. Ensure that the discovery mechanism is completely proof against loops and protected against duplicate responses. RESOLVED: Added loop count mechanism. o 18. Discuss the handling of multiple valid discovery responses. RESOLVED: Stated that the choice must be available to the ASA but GRASP implementation should pick a default. o 19. Should we use a text-oriented format such as JSON/CBOR instead of native binary TLV format? RESOLVED: Yes, changed to CBOR. o 20. Is the Divert option needed? If a discovery response provides a valid IP address or FQDN, the recipient doesn't gain any extra knowledge from the Divert. On the other hand, the presence of Divert informs the receiver that the target is off- link, which might be useful sometimes. RESOLVED: Decided to keep Divert option. o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling Protocol)? RESOLVED: Yes, name changed. o 22. Does discovery mechanism scale robustly as needed? Need hop limit on relaying? RESOLVED: Added hop limit. o 23. Need more details on TTL for caching discovery responses. RESOLVED: Done. o 24. Do we need "fast withdrawal" of discovery responses? RESOLVED: This doesn't seem necessary. If an ASA exits or stops supporting a given objective, peers will fail to start future sessions and will simply repeat discovery. Bormann, et al. Expires January 8, 2018 [Page 57] Internet-Draft GRASP July 2017 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? RESOLVED: Decided not to consider this further as a GRASP protocol issue. GRASP objectives could embed DNS-SD formats if needed. o 26. Add a URL type to the locator options (for security bootstrap etc.) RESOLVED: Done, later renamed as URI. o 27. Security of Flood multicasts (Section 2.5.6.2). RESOLVED: added text. o 28. Does ACP support secure link-local multicast? RESOLVED by new text in the Security Considerations. o 29. PEN is used to distinguish vendor options. Would it be better to use a domain name? Anything unique will do. RESOLVED: Simplified this by removing PEN field and changing naming rules for objectives. o 30. Does response to discovery require randomized delays to mitigate amplification attacks? RESOLVED: WG feedback is that it's unnecessary. o 31. We have specified repeats for failed discovery etc. Is that sufficient to deal with sleeping nodes? RESOLVED: WG feedback is that it's unnecessary to say more. o 32. We have one-to-one synchronization and flooding synchronization. Do we also need selective flooding to a subset of nodes? RESOLVED: This will be discussed as a protocol extension in a separate draft (draft-liu-anima-grasp-distribution). o 33. Clarify if/when discovery needs to be repeated. RESOLVED: Done. o 34. Clarify what is mandatory for running in ACP, expand discussion of security boundary when running with no ACP - might rely on the local PKI infrastructure. Bormann, et al. Expires January 8, 2018 [Page 58] Internet-Draft GRASP July 2017 RESOLVED: Done. o 35. State that role-based authorization of ASAs is out of scope for GRASP. GRASP doesn't recognize/handle any "roles". RESOLVED: Done. o 36. Reconsider CBOR definition for PEN syntax. ( objective-name = text / [pen, text] ; pen = uint ) RESOLVED: See issue 29. o 37. Are URI locators really needed? RESOLVED: Yes, e.g. for security bootstrap discovery, but added note that addresses are the normal case (same for FQDN locators). o 38. Is Session ID sufficient to identify relayed responses? Isn't the originator's address needed too? RESOLVED: Yes, this is needed for multicast messages and their responses. o 39. Clarify that a node will contain one GRASP instance supporting multiple ASAs. RESOLVED: Done. o 40. Add a "reason" code to the DECLINE option? RESOLVED: Done. o 41. What happens if an ASA cannot conveniently use one of the GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) simply pass the discovery results to the ASA so that it can open its own socket? RESOLVED: Both would be possible, but (b) is preferred. o 42. Do we need a feature whereby an ASA can bypass the ACP and use the data plane for efficiency/throughput? This would require discovery to return non-ACP addresses and would evade ACP security. RESOLVED: This is considered out of scope for GRASP, but a comment has been added in security considerations. Bormann, et al. Expires January 8, 2018 [Page 59] Internet-Draft GRASP July 2017 o 43. Rapid mode synchronization and negotiation is currently limited to a single objective for simplicity of design and implementation. A future consideration is to allow multiple objectives in rapid mode for greater efficiency. RESOLVED: This is considered out of scope for this version. o 44. In requirement T9, the words that encryption "may not be required in all deployments" were removed. Is that OK?. RESOLVED: No objections. o 45. Device Identity Option is unused. Can we remove it completely?. RESOLVED: No objections. Done. o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD messages is intended to assist in loop prevention. However, we also have the loop count for that. Also, if we create a new Session ID each time a DISCOVER or FLOOD is relayed, that ID can be disambiguated by recipients. It would be simpler to remove the initiator from the messages, making parsing more uniform. Is that OK? RESOLVED: Yes. Done. o 47. REQUEST is a dual purpose message (request negotiation or request synchronization). Would it be better to split this into two different messages (and adjust various message names accordingly)? RESOLVED: Yes. Done. o 48. Should the Appendix "Capability Analysis of Current Protocols" be deleted before RFC publication? RESOLVED: No (per WG meeting at IETF 96). o 49. Section 2.5.1 Should say more about signaling between two autonomic networks/domains. RESOLVED: Description of separate GRASP instance added. o 50. Is Rapid mode limited to on-link only? What happens if first discovery responder does not support Rapid Mode? Section 2.5.5, Section 2.5.6) Bormann, et al. Expires January 8, 2018 [Page 60] Internet-Draft GRASP July 2017 RESOLVED: Not limited to on-link. First responder wins. o 51. Should flooded objectives have a time-to-live before they are deleted from the flood cache? And should they be tagged in the cache with their source locator? RESOLVED: TTL added to Flood (and Discovery Response) messages. Cached flooded objectives must be tagged with their originating ASA locator, and multiple copies must be kept if necessary. o 52. Describe in detail what is allowed and disallowed in an insecure instance of GRASP. RESOLVED: Done. o 53. Tune IANA Considerations to support early assignment request. o 54. Is there a highly unlikely race condition if two peers simultaneously choose the same Session ID and send each other simultaneous M_REQ_NEG messages? RESOLVED: Yes. Enhanced text on Session ID generation, and added precaution when receiving a Request message. o 55. Could discovery be performed over TCP? RESOLVED: Unicast discovery added as an option. o 56. Change Session-ID to 32 bits? RESOLVED: Done. o 57. Add M_INVALID message? RESOLVED: Done. o 58. Maximum message size? RESOLVED by specifying default maximum message size (2048 bytes). o 59. Add F_NEG_DRY flag to specify a "dry run" objective?. RESOLVED: Done. o 60. Change M_FLOOD syntax to associate a locator with each objective? Bormann, et al. Expires January 8, 2018 [Page 61] Internet-Draft GRASP July 2017 RESOLVED: Done. o 61. Is the SONN constrained instance really needed? RESOLVED: Retained but only as an option. o 62. Is it helpful to tag descriptive text with message names (M_DISCOVER etc.)? RESOLVED: Yes, done in various parts of the text. o 63. Should encryption be MUST instead of SHOULD in Section 2.5.1 and Section 2.5.1? RESOLVED: Yes, MUST implement in both cases. o 64. Should more security text be moved from the main text into the Security Considerations? RESOLVED: No, on AD advice. o 65. Do we need to formally restrict Unicode characters allowed in objective names? RESOLVED: No, but need to point to guidance from PRECIS WG. o 66. Split requirements into separate document? RESOLVED: No, on AD advice. o 67. Remove normative dependency on draft-greevenbosch-appsawg- cbor-cddl? RESOLVED: No, on AD advice. In worst case, fix at AUTH48. Appendix C. Change log [RFC Editor: Please remove] draft-ietf-anima-grasp-15, 2017-07-07: Updates following additional IESG comments: Security (Eric Rescorla): missing brittleness of group security concept, attack via compromised member. TSV (Mirja Kuehlewind): clarification on the use of UDP, TCP, mandate use of TCP (or other reliable transport). Clarified that in ACP, UDP is not used at all. Bormann, et al. Expires January 8, 2018 [Page 62] Internet-Draft GRASP July 2017 Clarified that GRASP itself needs TCP listen port (was previously written as if this was optional). draft-ietf-anima-grasp-14, 2017-07-02: Updates following additional IESG comments: Updated 2.5.1 and 2.5.2 based on IESG security feedback (specify dependency against security substrate). Strengthened requirement for reliable transport protocol. draft-ietf-anima-grasp-13, 2017-06-06: Updates following additional IESG comments: Removed all mention of TLS, including SONN, since it was under- specified. Clarified other text about trust and security model. Banned Rapid Mode when multicast is insecure. Explained use of M_INVALID to support extensibility Corrected details on discovery cache TTL and discovery timeout. Improved description of multicast UDP w.r.t. RFC8085. Clarified when transport connections are opened or closed. Noted that IPPROTO values come from the Protocol Numbers registry Protocol change: Added protocol and port numbers to URI locator. Removed inaccurate text about routing protocols Moved Requirements section to an Appendix. Other editorial and technical clarifications. draft-ietf-anima-grasp-12, 2017-05-19: Updates following IESG comments: Clarified that GRASP runs in a single addressing realm Bormann, et al. Expires January 8, 2018 [Page 63] Internet-Draft GRASP July 2017 Improved wording about FQDN resolution, clarified that URI usage is out of scope. Clarified description of negotiation timeout. Noted that 'dry run' semantics are ASA-dependent Made the ACP a normative reference Clarified that LL multicasts are limited to GRASP interfaces Unicast UDP moved out of scope Editorial clarifications draft-ietf-anima-grasp-11, 2017-03-30: Updates following IETF 98 discussion: Encryption changed to a MUST implement. Pointed to guidance on UTF-8 names. draft-ietf-anima-grasp-10, 2017-03-10: Updates following IETF Last call: Protocol change: Specify that an objective with no initial value should have its value field set to CBOR 'null'. Protocol change: Specify behavior on receiving unrecognized message type. Noted that UTF-8 names are matched byte-for-byte. Added brief guidance for Expert Reviewer of new generic objectives. Numerous editorial improvements and clarifications and minor text rearrangements, none intended to change the meaning. draft-ietf-anima-grasp-09, 2016-12-15: Protocol change: Add F_NEG_DRY flag to specify a "dry run" objective. Protocol change: Change M_FLOOD syntax to associate a locator with each objective. Bormann, et al. Expires January 8, 2018 [Page 64] Internet-Draft GRASP July 2017 Concentrated mentions of TLS in one section, with all details out of scope. Clarified text around constrained instances of GRASP. Strengthened text restricting LL addresses in locator options. Clarified description of rapid mode processsing. Specified that cached discovery results should not be returned on the same interface where they were learned. Shortened text in "High Level Design Choices" Dropped the word 'kernel' to avoid confusion with o/s kernel mode. Editorial improvements and clarifications. draft-ietf-anima-grasp-08, 2016-10-30: Protocol change: Added M_INVALID message. Protocol change: Increased Session ID space to 32 bits. Enhanced rules to avoid Session ID clashes. Corrected and completed description of timeouts for Request messages. Improved wording about exponential backoff and DoS. Clarified that discovery relaying is not done by limited security instances. Corrected and expanded explanation of port used for Discovery Response. Noted that Discovery message could be sent unicast in special cases. Added paragraph on extensibility. Specified default maximum message size. Added Appendix for sample messages. Added short protocol overview. Editorial fixes, including minor re-ordering for readability. Bormann, et al. Expires January 8, 2018 [Page 65] Internet-Draft GRASP July 2017 draft-ietf-anima-grasp-07, 2016-09-13: Protocol change: Added TTL field to Flood message (issue 51). Protocol change: Added Locator option to Flood message (issue 51). Protocol change: Added TTL field to Discovery Response message (corrollary to issue 51). Clarified details of rapid mode (issues 43 and 50). Description of inter-domain GRASP instance added (issue 49). Description of limited security GRASP instances added (issue 52). Strengthened advice to use TCP rather than UDP. Updated IANA considerations and text about well-known port usage (issue 53). Amended text about ASA authorization and roles to allow for overlapping ASAs. Added text recommending that Flood should be repeated periodically. Editorial fixes. draft-ietf-anima-grasp-06, 2016-06-27: Added text on discovery cache timeouts. Noted that ASAs that are only initiators do not need to respond to discovery message. Added text on unexpected address changes. Added text on robust implementation. Clarifications and editorial fixes for numerous review comments Added open issues for some review comments. draft-ietf-anima-grasp-05, 2016-05-13: Noted in requirement T1 that it should be possible to implement ASAs independently as user space programs. Bormann, et al. Expires January 8, 2018 [Page 66] Internet-Draft GRASP July 2017 Protocol change: Added protocol number and port to discovery response. Updated protocol description, CDDL and IANA considerations accordingly. Clarified that discovery and flood multicasts are handled by the GRASP core, not directly by ASAs. Clarified that a node may discover an objective without supporting it for synchronization or negotiation. Added Implementation Status section. Added reference to SCSP. Editorial fixes. draft-ietf-anima-grasp-04, 2016-03-11: Protocol change: Restored initiator field in certain messages and adjusted relaying rules to provide complete loop detection. Updated IANA Considerations. draft-ietf-anima-grasp-03, 2016-02-24: Protocol change: Removed initiator field from certain messages and adjusted relaying requirement to simplify loop detection. Also clarified narrative explanation of discovery relaying. Protocol change: Split Request message into two (Request Negotiation and Request Synchronization) and updated other message names for clarity. Protocol change: Dropped unused Device ID option. Further clarified text on transport layer usage. New text about multicast insecurity in Security Considerations. Various other clarifications and editorial fixes, including moving some material to Appendix. draft-ietf-anima-grasp-02, 2016-01-13: Resolved numerous issues according to WG discussions. Renumbered requirements, added D9. Bormann, et al. Expires January 8, 2018 [Page 67] Internet-Draft GRASP July 2017 Protocol change: only allow one objective in rapid mode. Protocol change: added optional error string to DECLINE option. Protocol change: removed statement that seemed to say that a Request not preceded by a Discovery should cause a Discovery response. That made no sense, because there is no way the initiator would know where to send the Request. Protocol change: Removed PEN option from vendor objectives, changed naming rule accordingly. Protocol change: Added FLOOD message to simplify coding. Protocol change: Added SYNCH message to simplify coding. Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD messages. But also allowed the relay process for DISCOVER and FLOOD to regenerate a Session ID. Protocol change: Require that discovered addresses must be global (except during bootstrap). Protocol change: Receiver of REQUEST message must close socket if no ASA is listening for the objective. Protocol change: Simplified Waiting message. Protocol change: Added No Operation message. Renamed URL locator type as URI locator type. Updated CDDL definition. Various other clarifications and editorial fixes. draft-ietf-anima-grasp-01, 2015-10-09: Updated requirements after list discussion. Changed from TLV to CBOR format - many detailed changes, added co- author. Tightened up loop count and timeouts for various cases. Noted that GRASP does not provide transactional integrity. Various other clarifications and editorial fixes. Bormann, et al. Expires January 8, 2018 [Page 68] Internet-Draft GRASP July 2017 draft-ietf-anima-grasp-00, 2015-08-14: File name and protocol name changed following WG adoption. Added URL locator type. draft-carpenter-anima-gdn-protocol-04, 2015-06-21: Tuned wording around hierarchical structure. Changed "device" to "ASA" in many places. Reformulated requirements to be clear that the ASA is the main customer for signaling. Added requirement for flooding unsolicited synch, and added it to protocol spec. Recognized DNCP as alternative for flooding synch data. Requirements clarified, expanded and rearranged following design team discussion. Clarified that GDNP discovery must not be a prerequisite for GDNP negotiation or synchronization (resolved issue 13). Specified flag bits for objective options (resolved issue 15). Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 9,10,11). Updated DNCP description from latest DNCP draft. Editorial improvements. draft-carpenter-anima-gdn-protocol-03, 2015-04-20: Removed intrinsic security, required external security Format changes to allow DNCP co-existence Recognized DNS-SD as alternative discovery method. Editorial improvements draft-carpenter-anima-gdn-protocol-02, 2015-02-19: Tuned requirements to clarify scope, Bormann, et al. Expires January 8, 2018 [Page 69] Internet-Draft GRASP July 2017 Clarified relationship between types of objective, Clarified that objectives may be simple values or complex data structures, Improved description of objective options, Added loop-avoidance mechanisms (loop count and default timeout, limitations on discovery relaying and on unsolicited responses), Allow multiple discovery objectives in one response, Provided for missing or multiple discovery responses, Indicated how modes such as "dry run" should be supported, Minor editorial and technical corrections and clarifications, Reorganized future work list. draft-carpenter-anima-gdn-protocol-01, restructured the logical flow of the document, updated to describe synchronization completely, add unsolicited responses, numerous corrections and clarifications, expanded future work list, 2015-01-06. draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 02, 2014-10-08. Appendix D. Example Message Formats For readers unfamiliar with CBOR, this appendix shows a number of example GRASP messages conforming to the CDDL syntax given in Section 5. Each message is shown three times in the following formats: 1. CBOR diagnostic notation. 2. Similar, but showing the names of the constants. (Details of the flag bit encoding are omitted.) 3. Hexadecimal version of the CBOR wire format. Long lines are split for display purposes only. Bormann, et al. Expires January 8, 2018 [Page 70] Internet-Draft GRASP July 2017 D.1. Discovery Example The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a discovery message looking for objective EX1: [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 5, 2, 0]] [M_DISCOVERY, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", F_SYNCH_bits, 2, 0]] h'84011a00d4d7485020010db8f000baaa28ccdc4c970367818463455831050200' A peer (2001:0db8:f000:baaa:f000:baaa:f000:baaa) responds with a locator: [2, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, [103, h'20010db8f000baaaf000baaaf000baaa', 6, 49443]] [M_RESPONSE, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, [O_IPv6_LOCATOR, h'20010db8f000baaaf000baaaf000baaa', IPPROTO_TCP, 49443]] h'85021a00d4d7485020010db8f000baaa28ccdc4c9703678119ea6084186750 20010db8f000baaaf000baaaf000baaa0619c123' D.2. Flood Example The initiator multicasts a flood message. The single objective has a null locator. There is no response: [9, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, [["EX1", 5, 2, ["Example 1 value=", 100]],[] ] ] [M_FLOOD, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, [["EX1", F_SYNCH_bits, 2, ["Example 1 value=", 100]],[] ] ] h'86091a00357b4e5020010db8f000baaa28ccdc4c97036781192710 828463455831050282704578616d706c6520312076616c75653d186480' D.3. Synchronization Example Following successful discovery of objective EX2, the initiator unicasts a request: [4, 4038926, ["EX2", 5, 5, 0]] [M_REQ_SYN, 4038926, ["EX2", F_SYNCH_bits, 5, 0]] h'83041a003da10e8463455832050500' The peer responds with a value: [8, 4038926, ["EX2", 5, 5, ["Example 2 value=", 200]]] [M_SYNCH, 4038926, ["EX2", F_SYNCH_bits, 5, ["Example 2 value=", 200]]] h'83081a003da10e8463455832050582704578616d706c6520322076616c75653d18c8' Bormann, et al. Expires January 8, 2018 [Page 71] Internet-Draft GRASP July 2017 D.4. Simple Negotiation Example Following successful discovery of objective EX3, the initiator unicasts a request: [3, 802813, ["EX3", 3, 6, ["NZD", 47]]] [M_REQ_NEG, 802813, ["EX3", F_NEG_bits, 6, ["NZD", 47]]] h'83031a000c3ffd8463455833030682634e5a44182f' The peer responds with immediate acceptance. Note that no objective is needed, because the initiator's request was accepted without change: [6, 802813, [101]] [M_END , 802813, [O_ACCEPT]] h'83061a000c3ffd811865' D.5. Complete Negotiation Example Again the initiator unicasts a request: [3, 13767778, ["EX3", 3, 6, ["NZD", 410]]] [M_REQ_NEG, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 410]]] h'83031a00d214628463455833030682634e5a4419019a' The responder starts to negotiate (making an offer): [5, 13767778, ["EX3", 3, 6, ["NZD", 80]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 80]]] h'83051a00d214628463455833030682634e5a441850' The initiator continues to negotiate (reducing its request, and note that the loop count is decremented): [5, 13767778, ["EX3", 3, 5, ["NZD", 307]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 5, ["NZD", 307]]] h'83051a00d214628463455833030582634e5a44190133' The responder asks for more time: [7, 13767778, 34965] [M_WAIT, 13767778, 34965] h'83071a00d21462198895' The responder continues to negotiate (increasing its offer): Bormann, et al. Expires January 8, 2018 [Page 72] Internet-Draft GRASP July 2017 [5, 13767778, ["EX3", 3, 4, ["NZD", 120]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 4, ["NZD", 120]]] h'83051a00d214628463455833030482634e5a441878' The initiator continues to negotiate (reducing its request): [5, 13767778, ["EX3", 3, 3, ["NZD", 246]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 3, ["NZD", 246]]] h'83051a00d214628463455833030382634e5a4418f6' The responder refuses to negotiate further: [6, 13767778, [102, "Insufficient funds"]] [M_END , 13767778, [O_DECLINE, "Insufficient funds"]] h'83061a00d2146282186672496e73756666696369656e742066756e6473' This negotiation has failed. If either side had sent [M_END, 13767778, [O_ACCEPT]] it would have succeeded, converging on the objective value in the preceding M_NEGOTIATE. Note that apart from the initial M_REQ_NEG, the process is symmetrical. Appendix E. Requirement Analysis of Discovery, Synchronization and Negotiation This section discusses the requirements for discovery, negotiation and synchronization capabilities. The primary user of the protocol is an autonomic service agent (ASA), so the requirements are mainly expressed as the features needed by an ASA. A single physical device might contain several ASAs, and a single ASA might manage several technical objectives. If a technical objective is managed by several ASAs, any necessary coordination is outside the scope of the GRASP signaling protocol. Furthermore, requirements for ASAs themselves, such as the processing of Intent [RFC7575], are out of scope for the present document. E.1. Requirements for Discovery D1. ASAs may be designed to manage any type of configurable device or software, as required in Appendix E.2. A basic requirement is therefore that the protocol can represent and discover any kind of technical objective (as defined in Section 2.1) among arbitrary subsets of participating nodes. In an autonomic network we must assume that when a device starts up it has no information about any peer devices, the network structure, or what specific role it must play. The ASA(s) inside the device are in the same situation. In some cases, when a new application session starts up within a device, the device or ASA may again lack Bormann, et al. Expires January 8, 2018 [Page 73] Internet-Draft GRASP July 2017 information about relevant peers. For example, it might be necessary to set up resources on multiple other devices, coordinated and matched to each other so that there is no wasted resource. Security settings might also need updating to allow for the new device or user. The relevant peers may be different for different technical objectives. Therefore discovery needs to be repeated as often as necessary to find peers capable of acting as counterparts for each objective that a discovery initiator needs to handle. From this background we derive the next three requirements: D2. When an ASA first starts up, it may have no knowledge of the specific network to which it is attached. Therefore the discovery process must be able to support any network scenario, assuming only that the device concerned is bootstrapped from factory condition. D3. When an ASA starts up, it must require no configured location information about any peers in order to discover them. D4. If an ASA supports multiple technical objectives, relevant peers may be different for different discovery objectives, so discovery needs to be performed separately to find counterparts for each objective. Thus, there must be a mechanism by which an ASA can separately discover peer ASAs for each of the technical objectives that it needs to manage, whenever necessary. D5. Following discovery, an ASA will normally perform negotiation or synchronization for the corresponding objectives. The design should allow for this by conveniently linking discovery to negotiation and synchronization. It may provide an optional mechanism to combine discovery and negotiation/synchronization in a single protocol exchange. D6. Some objectives may only be significant on the local link, but others may be significant across the routed network and require off- link operations. Thus, the relevant peers might be immediate neighbors on the same layer 2 link, or they might be more distant and only accessible via layer 3. The mechanism must therefore provide both on-link and off-link discovery of ASAs supporting specific technical objectives. D7. The discovery process should be flexible enough to allow for special cases, such as the following: o During initialization, a device must be able to establish mutual trust with autonomic nodes elsewhere in the network and participate in an authentication mechanism. Although this will inevitably start with a discovery action, it is a special case precisely because trust is not yet established. This topic is the Bormann, et al. Expires January 8, 2018 [Page 74] Internet-Draft GRASP July 2017 subject of [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once trust has been established for a device, all ASAs within the device inherit the device's credentials and are also trusted. This does not preclude the device having multiple credentials. o Depending on the type of network involved, discovery of other central functions might be needed, such as the Network Operations Center (NOC) [I-D.ietf-anima-stable-connectivity]. The protocol must be capable of supporting such discovery during initialization, as well as discovery during ongoing operation. D8. The discovery process must not generate excessive traffic and must take account of sleeping nodes. D9. There must be a mechanism for handling stale discovery results. E.2. Requirements for Synchronization and Negotiation Capability Autonomic networks need to be able to manage many different types of parameter and consider many dimensions, such as latency, load, unused or limited resources, conflicting resource requests, security settings, power saving, load balancing, etc. Status information and resource metrics need to be shared between nodes for dynamic adjustment of resources and for monitoring purposes. While this might be achieved by existing protocols when they are available, the new protocol needs to be able to support parameter exchange, including mutual synchronization, even when no negotiation as such is required. In general, these parameters do not apply to all participating nodes, but only to a subset. SN1. A basic requirement for the protocol is therefore the ability to represent, discover, synchronize and negotiate almost any kind of network parameter among selected subsets of participating nodes. SN2. Negotiation is an iterative request/response process that must be guaranteed to terminate (with success or failure). While tie- breaking rules must be defined specifically for each use case, the protocol should have some general mechanisms in support of loop and deadlock prevention, such as hop count limits or timeouts. SN3. Synchronization must be possible for groups of nodes ranging from small to very large. SN4. To avoid "reinventing the wheel", the protocol should be able to encapsulate the data formats used by existing configuration protocols (such as NETCONF/YANG) in cases where that is convenient. Bormann, et al. Expires January 8, 2018 [Page 75] Internet-Draft GRASP July 2017 SN5. Human intervention in complex situations is costly and error- prone. Therefore, synchronization or negotiation of parameters without human intervention is desirable whenever the coordination of multiple devices can improve overall network performance. It follows that the protocol's resource requirements must be small enough to fit in any device that would otherwise need human intervention. The issue of running in constrained nodes is discussed in [I-D.ietf-anima-reference-model]. SN6. Human intervention in large networks is often replaced by use of a top-down network management system (NMS). It therefore follows that the protocol, as part of the Autonomic Networking Infrastructure, should be capable of running in any device that would otherwise be managed by an NMS, and that it can co-exist with an NMS, and with protocols such as SNMP and NETCONF. SN7. Specific autonomic features are expected to be implemented by individual ASAs, but the protocol must be general enough to allow them. Some examples follow: o Dependencies and conflicts: In order to decide upon a configuration for a given device, the device may need information from neighbors. This can be established through the negotiation procedure, or through synchronization if that is sufficient. However, a given item in a neighbor may depend on other information from its own neighbors, which may need another negotiation or synchronization procedure to obtain or decide. Therefore, there are potential dependencies and conflicts among negotiation or synchronization procedures. Resolving dependencies and conflicts is a matter for the individual ASAs involved. To allow this, there need to be clear boundaries and convergence mechanisms for negotiations. Also some mechanisms are needed to avoid loop dependencies or uncontrolled growth in a tree of dependencies. It is the ASA designer's responsibility to avoid or detect looping dependencies or excessive growth of dependency trees. The protocol's role is limited to bilateral signaling between ASAs, and the avoidance of loops during bilateral signaling. o Recovery from faults and identification of faulty devices should be as automatic as possible. The protocol's role is limited to discovery, synchronization and negotiation. These processes can occur at any time, and an ASA may need to repeat any of these steps when the ASA detects an event such as a negotiation counterpart failing. o Since a major goal is to minimize human intervention, it is necessary that the network can in effect "think ahead" before Bormann, et al. Expires January 8, 2018 [Page 76] Internet-Draft GRASP July 2017 changing its parameters. One aspect of this is an ASA that relies on a knowledge base to predict network behavior. This is out of scope for the signaling protocol. However, another aspect is forecasting the effect of a change by a "dry run" negotiation before actually installing the change. Signaling a dry run is therefore a desirable feature of the protocol. Note that management logging, monitoring, alerts and tools for intervention are required. However, these can only be features of individual ASAs, not of the protocol itself. Another document [I-D.ietf-anima-stable-connectivity] discusses how such agents may be linked into conventional OAM systems via an Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane]. SN8. The protocol will be able to deal with a wide variety of technical objectives, covering any type of network parameter. Therefore the protocol will need a flexible and easily extensible format for describing objectives. At a later stage it may be desirable to adopt an explicit information model. One consideration is whether to adopt an existing information model or to design a new one. E.3. Specific Technical Requirements T1. It should be convenient for ASA designers to define new technical objectives and for programmers to express them, without excessive impact on run-time efficiency and footprint. In particular, it should be convenient for ASAs to be implemented independently of each other as user space programs rather than as kernel code, where such a programming model is possible. The classes of device in which the protocol might run is discussed in [I-D.ietf-anima-reference-model]. T2. The protocol should be easily extensible in case the initially defined discovery, synchronization and negotiation mechanisms prove to be insufficient. T3. To be a generic platform, the protocol payload format should be independent of the transport protocol or IP version. In particular, it should be able to run over IPv6 or IPv4. However, some functions, such as multicasting on a link, might need to be IP version dependent. By default, IPv6 should be preferred. T4. The protocol must be able to access off-link counterparts via routable addresses, i.e., must not be restricted to link-local operation. Bormann, et al. Expires January 8, 2018 [Page 77] Internet-Draft GRASP July 2017 T5. It must also be possible for an external discovery mechanism to be used, if appropriate for a given technical objective. In other words, GRASP discovery must not be a prerequisite for GRASP negotiation or synchronization. T6. The protocol must be capable of distinguishing multiple simultaneous operations with one or more peers, especially when wait states occur. T7. Intent: Although the distribution of Intent is out of scope for this document, the protocol must not by design exclude its use for Intent distribution. T8. Management monitoring, alerts and intervention: Devices should be able to report to a monitoring system. Some events must be able to generate operator alerts and some provision for emergency intervention must be possible (e.g. to freeze synchronization or negotiation in a mis-behaving device). These features might not use the signaling protocol itself, but its design should not exclude such use. T9. Because this protocol may directly cause changes to device configurations and have significant impacts on a running network, all protocol exchanges need to be fully secured against forged messages and man-in-the middle attacks, and secured as much as reasonably possible against denial of service attacks. There must also be an encryption mechanism to resist unwanted monitoring. However, it is not required that the protocol itself provides these security features; it may depend on an existing secure environment. Appendix F. Capability Analysis of Current Protocols This appendix discusses various existing protocols with properties related to the requirements described in Appendix E. The purpose is to evaluate whether any existing protocol, or a simple combination of existing protocols, can meet those requirements. Numerous protocols include some form of discovery, but these all appear to be very specific in their applicability. Service Location Protocol (SLP) [RFC2608] provides service discovery for managed networks, but requires configuration of its own servers. DNS-SD [RFC6763] combined with mDNS [RFC6762] provides service discovery for small networks with a single link layer. [RFC7558] aims to extend this to larger autonomous networks but this is not yet standardized. However, both SLP and DNS-SD appear to target primarily application layer services, not the layer 2 and 3 objectives relevant to basic network configuration. Both SLP and DNS-SD are text-based protocols. Bormann, et al. Expires January 8, 2018 [Page 78] Internet-Draft GRASP July 2017 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ response model not well suited for peer negotiation. Network Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that does allow positive or negative responses from the target system, but this is still not adequate for negotiation. There are various existing protocols that have elementary negotiation abilities, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are configuration or management protocols. However, they either provide only a simple request/response model in a master/slave context or very limited negotiation abilities. There are some signaling protocols with an element of negotiation. For example Resource ReSerVation Protocol (RSVP) [RFC2205] was designed for negotiating quality of service parameters along the path of a unicast or multicast flow. RSVP is a very specialised protocol aimed at end-to-end flows. A more generic design is General Internet Signalling Transport (GIST) [RFC5971], but it is complex, tries to solve many problems, and is also aimed at per-flow signaling across many hops rather than at device-to-device signaling. However, we cannot completely exclude extended RSVP or GIST as a synchronization and negotiation protocol. They do not appear to be directly useable for peer discovery. RESTCONF [RFC8040] is a protocol intended to convey NETCONF information expressed in the YANG language via HTTP, including the ability to transit HTML intermediaries. While this is a powerful approach in the context of centralised configuration of a complex network, it is not well adapted to efficient interactive negotiation between peer devices, especially simple ones that might not include YANG processing already. The Distributed Node Consensus Protocol (DNCP) [RFC7787] is defined as a generic form of state synchronization protocol, with a proposed usage profile being the Home Networking Control Protocol (HNCP) [RFC7788] for configuring Homenet routers. A specific application of DNCP for autonomic networking was proposed in [I-D.stenberg-anima-adncp]. DNCP "is designed to provide a way for each participating node to publish a set of TLV (Type-Length-Value) tuples, and to provide a shared and common view about the data published... DNCP is most suitable for data that changes only infrequently... If constant rapid state changes are needed, the preferable choice is to use an additional point-to-point channel..." Bormann, et al. Expires January 8, 2018 [Page 79] Internet-Draft GRASP July 2017 Specific features of DNCP include: o Every participating node has a unique node identifier. o DNCP messages are encoded as a sequence of TLV objects, sent over unicast UDP or TCP, with or without (D)TLS security. o Multicast is used only for discovery of DNCP neighbors when lower security is acceptable. o Synchronization of state is maintained by a flooding process using the Trickle algorithm. There is no bilateral synchronization or negotiation capability. o The HNCP profile of DNCP is designed to operate between directly connected neighbors on a shared link using UDP and link-local IPv6 addresses. DNCP does not meet the needs of a general negotiation protocol, because it is designed specifically for flooding synchronization. Also, in its HNCP profile it is limited to link-local messages and to IPv6. However, at the minimum it is a very interesting test case for this style of interaction between devices without needing a central authority, and it is a proven method of network-wide state synchronization by flooding. The Server Cache Synchronization Protocol (SCSP) [RFC2334] also describes a method for cache synchronization and cache replication among a group of nodes. A proposal was made some years ago for an IP based Generic Control Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at information exchange and negotiation but not directly at peer discovery. However, it has many points in common with the present work. None of the above solutions appears to completely meet the needs of generic discovery, state synchronization and negotiation in a single solution. Many of the protocols assume that they are working in a traditional top-down or north-south scenario, rather than a fluid peer-to-peer scenario. Most of them are specialized in one way or another. As a result, we have not identified a combination of existing protocols that meets the requirements in Appendix E. Also, we have not identified a path by which one of the existing protocols could be extended to meet the requirements. Bormann, et al. Expires January 8, 2018 [Page 80] Internet-Draft GRASP July 2017 Authors' Addresses Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28359 Bremen Germany Email: cabo@tzi.org Brian Carpenter (editor) Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Bing Liu (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China Email: leo.liubing@huawei.com Bormann, et al. Expires January 8, 2018 [Page 81] ./draft-ietf-grow-bmp-adj-rib-out-07.txt0000644000764400076440000005004213522063612017225 0ustar iustyiusty Global Routing Operations T. Evens Internet-Draft S. Bayraktar Updates: 7854 (if approved) Cisco Systems Intended status: Standards Track P. Lucente Expires: February 6, 2020 NTT Communications P. Mi Tencent S. Zhuang Huawei August 5, 2019 Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) draft-ietf-grow-bmp-adj-rib-out-07 Abstract The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB- In Routing Information Bases (RIBs). This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB- Out RIBs. It adds a new flag to the peer header to distinguish Adj- RIB-In and Adj-RIB-Out. 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 https://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 6, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Evens, et al. Expires February 6, 2020 [Page 1] Internet-Draft BMP Adj-RIB-Out August 2019 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . . . 4 5. Adj-RIB-Out . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Post-Policy . . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Pre-Policy . . . . . . . . . . . . . . . . . . . . . . . 5 6. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 5 6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 5 6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 6 6.3.1. Peer Up Information . . . . . . . . . . . . . . . . . 6 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 7.1. Peer and Update Groups . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 8 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 8 9.3. Peer Up Information TLV . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction BGP Monitoring Protocol (BMP) defines monitoring of the received (e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer. The Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before any policy has been applied. The Adj-RIB-In post-policy conveys to a BMP receiver all RIB data after policy filters and/or modifications have been applied. An example of pre-policy versus post-policy is when an inbound policy applies attribute modification or filters. Pre-policy would contain information prior to the inbound policy changes or filters of data. Post policy would convey the changed data or would not contain the filtered data. Evens, et al. Expires February 6, 2020 [Page 2] Internet-Draft BMP Adj-RIB-Out August 2019 Monitoring the received updates that the router received before any policy has been applied is the primary level of monitoring for most use-cases. Inbound policy validation and auditing is the primary use-case for enabling post-policy monitoring. In order for a BMP receiver to receive any BGP data, the BMP sender (e.g., router) needs to have an established BGP peering session and actively be receiving updates for an Adj-RIB-In. Being able to only monitor the Adj-RIB-In puts a restriction on what data is available to BMP receivers via BMP senders (e.g., routers). This is an issue when the receiving end of the BGP peer is not enabled for BMP or when it is not accessible for administrative reasons. For example, a service provider advertises prefixes to a customer, but the service provider cannot see what it advertises via BMP. Asking the customer to enable BMP and monitoring of the Adj- RIB-In is not feasible. BGP Monitoring Protocol (BMP) RFC 7854 [RFC7854] only defines Adj- RIB-In being sent to BMP receivers. This document updates the per- peer header in section 4.2 of [RFC7854] by adding a new flag to distinguish Adj-RIB-In versus Adj-RIB-Out. BMP senders use the new flag to send either Adj-RIB-In or Adj-RIB-Out. Adding Adj-RIB-Out provides the ability for a BMP sender to send to BMP receivers what it advertises to BGP peers, which can be used for outbound policy validation and to monitor routes that were advertised. 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 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Definitions o Adj-RIB-Out: As defined in [RFC4271], "The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker's UPDATE messages." o Pre-Policy Adj-RIB-Out: The result before applying the outbound policy to an Adj-RIB-Out. This normally would match what is in the local RIB. Evens, et al. Expires February 6, 2020 [Page 3] Internet-Draft BMP Adj-RIB-Out August 2019 o Post-Policy Adj-RIB-Out: The result of applying outbound policy to an Adj-RIB-Out. This MUST convey to the BMP receiver what is actually transmitted to the peer. 4. Per-Peer Header The per-peer header has the same structure and flags as defined in section 4.2 of [RFC7854] with the following O flag addition: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L|A|O| Resv | +-+-+-+-+-+-+-+-+ o The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set to 1. The existing flags are defined in section 4.2 of [RFC7854] and the remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt. When the O flag is set to 1, the following fields in the Per-Peer Header are redefined: o Peer Address: The remote IP address associated with the TCP session over which the encapsulated PDU is sent. o Peer AS: The Autonomous System number of the peer to which the encapsulated PDU is sent. o Peer BGP ID: The BGP Identifier of the peer to which the encapsulated PDU is sent. o Timestamp: The time when the encapsulated routes were advertised (one may also think of this as the time when they were installed in the Adj-RIB-Out), expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). If zero, the time is unavailable. Precision of the timestamp is implementation- dependent. 5. Adj-RIB-Out 5.1. Post-Policy The primary use-case in monitoring Adj-RIB-Out is to monitor the updates transmitted to a BGP peer after outbound policy has been applied. These updates reflect the result after modifications and filters have been applied (e.g., Adj-RIB-Out Post-Policy). Some Evens, et al. Expires February 6, 2020 [Page 4] Internet-Draft BMP Adj-RIB-Out August 2019 attributes are set when the BGP message is transmitted, such as next- hop. Adj-RIB-Out Post-Policy MUST convey to the BMP receiver what is actually transmitted to the peer. The L flag MUST be set to 1 to indicate post-policy. 5.2. Pre-Policy Similarly to Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can be used to validate and audit outbound policies. For example, a comparison between pre-policy and post-policy can be used to validate the outbound policy. Depending on BGP peering session type (IBGP, IBGP route reflector client, EBGP, BGP confederations, Route Server Client) the candidate routes that make up the Pre-Policy Adj-RIB-Out do not contain all local-rib routes. Pre-Policy Adj-RIB-Out conveys only routes that are available based on the peering type. Post-Policy represents the filtered/changed routes from the available routes. Some attributes are set only during transmission of the BGP message, i.e., Post-Policy. It is common that next-hop may be null, loopback, or similar during pre-policy phase. All mandatory attributes, such as next-hop, MUST be either ZERO or have an empty length if they are unknown at the Pre-Policy phase completion. The BMP receiver will treat zero or empty mandatory attributes as self-originated. The L flag MUST be set to 0 to indicate pre-policy. 6. BMP Messages Many BMP messages have a per-peer header but some are not applicable to Adj-RIB-In or Adj-RIB-Out monitoring, such as peer up and down notifications. Unless otherwise defined, the O flag should be set to 0 in the per-peer header in BMP messages. 6.1. Route Monitoring and Route Mirroring The O flag MUST be set accordingly to indicate if the route monitor or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out. 6.2. Statistics Report The Statistics report message has a Stat Type field to indicate the statistic carried in the Stat Data field. Statistics report messages are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O flag set to zero. The O flag SHOULD be ignored by the BMP receiver. Evens, et al. Expires February 6, 2020 [Page 5] Internet-Draft BMP Adj-RIB-Out August 2019 The following new statistic types are added: o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out Pre-Policy. o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out Post-Policy. o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- Policy. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- Policy. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. 6.3. Peer Down and Up Notifications Peer Up and Down notifications convey BGP peering session state to BMP receivers. The state is independent of whether or not route monitoring or route mirroring messages will be sent for Adj-RIB-In, Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the O flag in Peer Up and Down notifications. 6.3.1. Peer Up Information The following Peer Up message Information TLV type is added: o Type = 4: Admin Label. The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with null or any other character. Multiple admin labels can be included in the Peer Up notification. When multiple admin labels are included the BMP receiver MUST preserve their order. The TLV is optional. 7. Other Considerations Evens, et al. Expires February 6, 2020 [Page 6] Internet-Draft BMP Adj-RIB-Out August 2019 7.1. Peer and Update Groups Peer and update groups are used to group updates shared by many peers. This is a level of efficiency in implementations, not a true representation of what is conveyed to a peer in either Pre-Policy or Post-Policy. One of the use-cases to monitor Adj-RIB-Out Post-Policy is to validate and continually ensure the egress updates match what is expected. For example, wholesale peers should never have routes with community X:Y sent to them. In this use-case, there may be hundreds of wholesale peers but a single peer could have represented the group. From a BMP perspective, this should be simple to include a group name in the Peer Up, but it is more complex than that. BGP implementations have evolved to provide comprehensive and structured policy grouping, such as session, AFI/SAFI, and template-based based group policy inheritances. This level of structure and inheritance of polices does not provide a simple peer group name or ID, such as wholesale peer. Instead of requiring a group name to be used, a new administrative label informational TLV (Section 6.3.1) is added to the Peer Up message. These labels have administrative scope relevance. For example, labels "type=wholesale" and "region=west" could be used to monitor expected policies. Configuration and assignment of labels to peers is BGP implementation specific. 8. Security Considerations The same considerations as in section 11 of [RFC7854] apply to this document. Implementations of this protocol SHOULD require to establish sessions with authorized and trusted monitoring devices. It is also believed that this document does not add any additional security considerations. 9. IANA Considerations This document requests that IANA assign the following new parameters to the BMP parameters name space [1]. Evens, et al. Expires February 6, 2020 [Page 7] Internet-Draft BMP Adj-RIB-Out August 2019 9.1. BMP Peer Flags This document defines the following per-peer header flags (Section 4): o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set to 1. 9.2. BMP Statistics Types This document defines four statistic types for statistics reporting (Section 6.2): o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out Pre-Policy. o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out Post-Policy. o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- Policy. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- Policy. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. 9.3. Peer Up Information TLV This document defines the following BMP Peer Up Information TLV types (Section 6.3.1): o Type = 4: Admin Label. The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with null or any other character. Multiple admin labels can be included in the Peer Up notification. When multiple admin labels are included the BMP receiver MUST preserve their order. The TLV is optional. Evens, et al. Expires February 6, 2020 [Page 8] Internet-Draft BMP Adj-RIB-Out August 2019 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, . [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, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. URIs [1] https://www.iana.org/assignments/bmp-parameters/bmp- parameters.xhtml Acknowledgements The authors would like to thank John Scudder and Mukul Srivastava for their valuable input. Contributors Manish Bhardwaj Cisco Systems 3700 Cisco Way San Jose, CA 95134 USA Email: manbhard@cisco.com Xianyuzheng Tencent Tencent Building, Kejizhongyi Avenue, Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China Evens, et al. Expires February 6, 2020 [Page 9] Internet-Draft BMP Adj-RIB-Out August 2019 Weiguo Tencent Tencent Building, Kejizhongyi Avenue, Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China Shugang cheng H3C Authors' Addresses Tim Evens Cisco Systems 2901 Third Avenue, Suite 600 Seattle, WA 98121 USA Email: tievens@cisco.com Serpil Bayraktar Cisco Systems 3700 Cisco Way San Jose, CA 95134 USA Email: serpil@cisco.com Paolo Lucente NTT Communications Siriusdreef 70-72 Hoofddorp, WT 2132 NL Email: paolo@ntt.net Penghui Mi Tencent Tengyun Building,Tower A ,No. 397 Tianlin Road Shanghai 200233 China Email: kevinmi@tencent.com Evens, et al. Expires February 6, 2020 [Page 10] Internet-Draft BMP Adj-RIB-Out August 2019 Shunwan Zhuang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Evens, et al. Expires February 6, 2020 [Page 11] ./draft-ietf-anima-prefix-management-07.txt0000644000764400076440000014651413216066203020063 0ustar iustyiusty ANIMA WG S. Jiang, Ed. Internet-Draft Z. Du Intended status: Informational Huawei Technologies Co., Ltd Expires: June 18, 2018 B. Carpenter Univ. of Auckland Q. Sun China Telecom December 15, 2017 Autonomic IPv6 Edge Prefix Management in Large-scale Networks draft-ietf-anima-prefix-management-07 Abstract This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. 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 https://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, 2018. 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 (https://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 Jiang, et al. Expires June 18, 2018 [Page 1] Internet-Draft Auto IPv6 Prefix Management December 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Intended User and Administrator Experience . . . . . . . 4 3.2. Analysis of Parameters and Information Involved . . . . . 5 3.2.1. Parameters each device can define for itself . . . . 5 3.2.2. Information needed from network operations . . . . . 6 3.2.3. Comparison with current solutions . . . . . . . . . . 6 3.3. Interaction with other devices . . . . . . . . . . . . . 7 3.3.1. Information needed from other devices . . . . . . . . 7 3.3.2. Monitoring, diagnostics and reporting . . . . . . . . 7 4. Autonomic Edge Prefix Management Solution . . . . . . . . . . 8 4.1. Behaviors on prefix requesting device . . . . . . . . . . 8 4.2. Behaviors on prefix providing device . . . . . . . . . . 9 4.3. Behavior after Successful Negotiation . . . . . . . . . . 10 4.4. Prefix logging . . . . . . . . . . . . . . . . . . . . . 10 5. Autonomic Prefix Management Objectives . . . . . . . . . . . 10 5.1. Edge Prefix Objective Option . . . . . . . . . . . . . . 10 5.2. IPv4 extension . . . . . . . . . . . . . . . . . . . . . 11 6. Prefix Management Parameters . . . . . . . . . . . . . . . . 11 6.1. Example of Prefix Management Parameters . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Deployment Overview . . . . . . . . . . . . . . . . 17 A.1. Address & Prefix management with DHCP . . . . . . . . . . 17 A.2. Prefix management with ANI/GRASP . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The original purpose of this document was to validate the design of the Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows how the ANI can be applied to IP prefix delegation and it outlines approaches to build a system to do this. A fully standardized solution would require more details, so this document is informational in nature. Jiang, et al. Expires June 18, 2018 [Page 2] Internet-Draft Auto IPv6 Prefix Management December 2017 This document defines two autonomic technical objectives for IPv6 prefix management in large-scale networks, with an extension to support IPv4 prefixes. The background to Autonomic Networking (AN) is described in [RFC7575] and [RFC7576]. The GeneRic Autonomic Signaling Protocol (GRASP) is specified by [I-D.ietf-anima-grasp] and can make use of the proposed technical objectives to provide a solution for autonomic prefix management. An important purpose of the present document is to use it for validation of the design of GRASP and other components of the autonomic networking infrastructure described in [I-D.ietf-anima-reference-model]. This document is not a complete functional specification of an autonomic prefix management system and it does not describe all detailed aspects of the GRASP objective parameters and Autonomic Service Agent (ASA) procedures necessary to build a complete system. Instead, it describes the architectural framework utilizing the components of the ANI, outlines the different deployment options and aspects, and defines GRASP objectives for use in building the system. It also provides some basic parameter examples. This document is not intended to solve all cases of IPv6 prefix management. In fact, it assumes that the network's main infrastructure elements already have addresses and prefixes. The document is dedicated to how to make IPv6 prefix management at the edges of large-scale networks as autonomic as possible. It is specifically written for service provider (ISP) networks. Although there are similarities between ISPs and large enterprise networks, the requirements for the two use cases differ. In any case, the scope of the solution is expected to be limited, like any autonomic network, to a single management domain. However, the solution is designed in a general way. Its use for a broader scope than edge prefixes, including some or all infrastructure prefixes, is left for future discussion. A complete solution has many aspects that are not discussed here. Once prefixes have been assigned to routers, they need to be communicated to the routing system as they are brought into use. Similarly, when prefixes are released, they need to be removed from the routing system. Different operators may have different policies about prefix lifetimes, and they may prefer to have centralized or distributed pools of spare prefixes. In an autonomic network, these are properties decided by the design of the relevant ASAs. The GRASP objectives are simply building blocks. A particular risk of distributed prefix allocation in large networks is that over time, it might lead to fragmentation of the address space and an undesirable increase in the interior routing protocol Jiang, et al. Expires June 18, 2018 [Page 3] Internet-Draft Auto IPv6 Prefix Management December 2017 tables. The extent of this risk depends on the algorithms and policies used by the ASAs. Mitigating this risk might even become an autonomic function in itself. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terminology defined in [RFC7575]. 3. Problem Statement The autonomic networking use case considered here is autonomic IPv6 prefix management at the edge of large-scale ISP networks. Although DHCPv6 Prefix Delegation [RFC3633] supports automated delegation of IPv6 prefixes from one router to another, prefix management still largely depends on human planning. In other words, there is no basic information or policy to support autonomic decisions on the prefix length that each router should request or be delegated, according to its role in the network. Roles could be defined separately for individual devices or could be generic (edge router, interior router, etc.). Furthermore, IPv6 prefix management by humans tends to be rigid and static after initial planning. The problem to be solved by autonomic networking is how to dynamically manage IPv6 address space in large-scale networks, so that IPv6 addresses can be used efficiently. Here, we limit the problem to assignment of prefixes at the edge of the network, close to access routers that support individual fixed-line subscribers, mobile customers, and corporate customers. We assume that the core infrastructure of the network has already been established with appropriately assigned prefixes. The AN approach discussed in this document is based on the assumption that there is a generic discovery and negotiation protocol that enables direct negotiation between intelligent IP routers. GRASP [I-D.ietf-anima-grasp] is intended to be such a protocol. 3.1. Intended User and Administrator Experience The intended experience is, for the administrators of a large-scale network, that the management of IPv6 address space at the edge of the network can be run with minimum effort, as devices at the edge are added and removed and as customers of all kinds join and leave the Jiang, et al. Expires June 18, 2018 [Page 4] Internet-Draft Auto IPv6 Prefix Management December 2017 network. In the ideal scenario, the administrators only have to specify a single IPv6 prefix for the whole network and the initial prefix length for each device role. As far as users are concerned, IPv6 prefix assignment would occur exactly as it does in any other network. The actual prefix usage needs to be logged for potential offline management operations including audit and security incident tracing. 3.2. Analysis of Parameters and Information Involved For specific purposes of address management, a few parameters are involved on each edge device (some of them can be pre-configured before they are connected). They include: o Identity, authentication and authorization of this device. This is expected to use the autonomic networking secure bootstrap process [I-D.ietf-anima-bootstrapping-keyinfra], following which the device could safely take part in autonomic operations. o Role of this device. Some example roles are discussed in Section 6.1. o An IPv6 prefix length for this device. o An IPv6 prefix that is assigned to this device and its downstream devices. A few parameters are involved in the network as a whole. They are: o Identity of a trust anchor, which is a certification authority (CA) maintained by the network administrators, used during the secure bootstrap process. o Total IPv6 address space available for edge devices. It is a pool of one or several IPv6 prefixes. o The initial prefix length for each device role. 3.2.1. Parameters each device can define for itself This section identifies those of the above parameters that do not need external information in order for the devices concerned to set them to a reasonable default value after bootstrap or after a network disruption. There are few of these: o Default role of this device. Jiang, et al. Expires June 18, 2018 [Page 5] Internet-Draft Auto IPv6 Prefix Management December 2017 o Default IPv6 prefix length for this device. o Cryptographic identity of this device, as needed for secure bootstrapping [I-D.ietf-anima-bootstrapping-keyinfra]. The device may be shipped from the manufacturer with pre-configured role and default prefix length, which could be modified by an autonomic mechanism. Its cryptographic identity will be installed by its manufacturer. 3.2.2. Information needed from network operations This section identifies those parameters that might need operational input in order for the devices concerned to set them to a non-default value. o Non-default value for the IPv6 prefix length for this device. This needs to be decided based on the role of this device. o The initial prefix length for each device role. o Whether to allow the device to request more address space. o The policy when to request more address space, for example, if the address usage reaches a certain limit or percentage. 3.2.3. Comparison with current solutions This section briefly compares the above use case with current solutions. Currently, the address management is still largely dependent on human planning. It is rigid and static after initial planning. Address requests will fail if the configured address space is used up. Some autonomic and dynamic address management functions may be achievable by extending the existing protocols, for example, extending DHCPv6-PD (DHCPv6 Prefix Delegation, [RFC3633]) to request IPv6 prefixes according to the device role. However, defining uniform device roles may not be a practical task. Some functions are not suitable to be achieved by any existing protocols. Using a generic autonomic discovery and negotiation protocol instead of specific solutions has the advantage that additional parameters can be included in the autonomic solution without creating new mechanisms. This is the principal argument for a generic approach. Jiang, et al. Expires June 18, 2018 [Page 6] Internet-Draft Auto IPv6 Prefix Management December 2017 3.3. Interaction with other devices 3.3.1. Information needed from other devices This section identifies those of the above parameters that need external information from neighbor devices (including the upstream devices). In many cases, two-way dialogue with neighbor devices is needed to set or optimize them. o Identity of a trust anchor. o The device will need to discover a device, from which it can acquire IPv6 address space. o The initial prefix length for each device role, particularly for its own downstream devices. o The default value of the IPv6 prefix length may be overridden by a non-default value. o The device will need to request and acquire one or more IPv6 prefixes that can be assigned to this device and its downstream devices. o The device may respond to prefix delegation requests from its downstream devices. o The device may require to be assigned more IPv6 address space, if it used up its assigned IPv6 address space. 3.3.2. Monitoring, diagnostics and reporting This section discusses what role devices should play in monitoring, fault diagnosis, and reporting. o The actual address assignments need to be logged for potential offline management operations. o In general, the usage situation of address space should be reported to the network administrators, in an abstract way, for example, statistics or visualized report. o A forecast of address exhaustion should be reported. Jiang, et al. Expires June 18, 2018 [Page 7] Internet-Draft Auto IPv6 Prefix Management December 2017 4. Autonomic Edge Prefix Management Solution This section introduces the building blocks for an autonomic edge prefix management solution. As noted in Section 1, this is not a complete description of a solution, which will depend on the detailed design of the relevant Autonomic Service Agents. It uses the generic discovery and negotiation protocol defined by [I-D.ietf-anima-grasp]. The relevant GRASP objectives are defined in Section 5. The procedures described below are carried out by an Autonomic Service Agent (ASA) in each device that participates in the solution. We will refer to this as the PrefixManager ASA. 4.1. Behaviors on prefix requesting device If the device containing a PrefixManager ASA has used up its address pool, it can request more space according to its requirements. It should decide the length of the requested prefix and request it by the mechanism described in Section 6. Note that although the device's role may define certain default allocation lengths, those defaults might be changed dynamically, and the device might request more, or less, address space due to some local operational heuristic. A PrefixManager ASA that needs additional address space should firstly discover peers that may be able to provide extra address space. The ASA should send out a GRASP Discovery message that contains a PrefixManager Objective option (see Section 5.1) in order to discover peers also supporting that option. Then it should choose one such peer, most likely the first to respond. If the GRASP discovery Response message carries a divert option pointing to an off-link PrefixManager ASA, the requesting ASA may initiate negotiation with that ASA diverted device to find out whether it can provide the requested length prefix. In any case, the requesting ASA will act as a GRASP negotiation initiator by sending a GRASP Request message with a PrefixManager Objective option. The ASA indicates in this option the length of the requested prefix. This starts a GRASP negotiation process. During the subsequent negotiation, the ASA will decide at each step whether to accept the offered prefix. That decision, and the decision to end negotiation, is an implementation choice. The ASA could alternatively initiate rapid mode GRASP discovery with an embedded negotiation request, if it is implemented. Jiang, et al. Expires June 18, 2018 [Page 8] Internet-Draft Auto IPv6 Prefix Management December 2017 4.2. Behaviors on prefix providing device At least one device on the network must be configured with the initial pool of available prefixes mentioned in Section 3.2. Apart from that requirement, any device may act as a prefix providing device. A device that receives a Discovery message with a PrefixManager Objective option should respond with a GRASP Response message if it contains a PrefixManager ASA. Further details of the discovery process are described in [I-D.ietf-anima-grasp]. When this ASA receives a subsequent Request message, it should conduct a GRASP negotiation sequence, using Negotiate, Confirm-waiting, and Negotiation-ending messages as appropriate. The Negotiate messages carry a PrefixManager Objective option, which will indicate the prefix and its length offered to the requesting ASA. As described in [I-D.ietf-anima-grasp], negotiation will continue until either end stops it with a Negotiation-ending message. If the negotiation succeeds, the prefix providing ASA will remove the negotiated prefix from its pool, and the requesting ASA will add it. If the negotiation fails, the party sending the Negotiation-ending message may include an error code string. During the negotiation, the ASA will decide at each step how large a prefix to offer. That decision, and the decision to end negotiation, is an implementation choice. The ASA could alternatively negotiate in response to rapid mode GRASP discovery, if it is implemented. This specification is independent of whether the PrefixManager ASAs are all embedded in routers, but that would be a rather natural scenario. In a hierarchical network topology, a given router typically provide prefixes for routers below it in the hierarchy, and it is also likely to contain the first PrefixManager ASA discovered by those downstream routers. However, the GRASP discovery model, including its Redirect feature, means that this is not an exclusive scenario, and a downstream PrefixManager ASA could negotiate a new prefix with a device other than its upstream router. A resource shortage may cause the gateway router to request more resource in turn from its own upstream device. This would be another independent GRASP discovery and negotiation process. During the processing time, the gateway router should send a Confirm-waiting Message to the initial requesting router, to extend its timeout. When the new resource becomes available, the gateway router responds with a GRASP Negotiate message with a prefix length matching the request. Jiang, et al. Expires June 18, 2018 [Page 9] Internet-Draft Auto IPv6 Prefix Management December 2017 The algorithm to choose which prefixes to assign on the prefix providing devices is an implementation choice. 4.3. Behavior after Successful Negotiation Upon receiving a GRASP Negotiation-ending message that indicates that an acceptable prefix length is available, the requesting device may use the negotiated prefix without further messages. There are use cases where the ANI/GRASP based prefix management approach can work together with DHCPv6-PD [RFC3633] as a complement. For example, the ANI/GRASP based method can be used intra-domain, while the DHCPv6-PD method works inter-domain (i.e., across an administrative boundary). Also, ANI/GRASP can be used inside the domain, and DHCP/DHCPv6-PD be used on the edge of the domain to client (non-ANI devices). Another similar use case would be ANI/ GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to client devices. 4.4. Prefix logging Within the autonomic prefix management, all the prefix assignment is done by devices without human intervention. It may be required to record all the prefix assignment history, for example to detect or trace lost prefixes after outages, or to meet legal requirements. However, the logging and reporting process is out of scope for this document. 5. Autonomic Prefix Management Objectives This section defines the GRASP technical objective options that are used to support autonomic prefix management. 5.1. Edge Prefix Objective Option The PrefixManager Objective option is a GRASP objective option conforming to [I-D.ietf-anima-grasp]. Its name is "PrefixManager" (see Section 8) and it carries the following data items as its value: the prefix length, and the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Object Representation [RFC7049]), the format of the PrefixManager Objective option is described as follows in CBOR data definition language (CDDL) [I-D.ietf-cbor-cddl]: Jiang, et al. Expires June 18, 2018 [Page 10] Internet-Draft Auto IPv6 Prefix Management December 2017 objective = ["PrefixManager", objective-flags, loop-count, [length, ?prefix]] loop-count = 0..255 ; as in the GRASP specification objective-flags /= ; as in the GRASP specification length = 0..128 ; requested or offered prefix length prefix = bytes .size 16 ; offered prefix in binary format The use of the 'dry run' mode of GRASP is NOT RECOMMENDED for this objective, because it would require both ASAs to store state about the corresponding negotiation, to no real benefit - the requesting ASA cannot base any decisions on the result of a successful dry run negotiation. 5.2. IPv4 extension This section presents an extended version of the PrefixManager Objective that supports IPv4 by adding an extra flag: objective = ["PrefixManager", objective-flags, loop-count, prefval] loop-count = 0..255 ; as in the GRASP specification objective-flags /= ; as in the GRASP specification prefval /= pref6val pref6val = [version6, length, ?prefix] version6 = 6 length = 0..128 ; requested or offered prefix length prefix = bytes .size 16 ; offered prefix in binary format prefval /= pref4val pref4val = [version4, length4, ?prefix4] version4 = 4 length4 = 0..32 ; requested or offered prefix length prefix4 = bytes .size 4 ; offered prefix in binary format Prefix and address management for IPv4 is considerably more difficult than for IPv6, due to the prevalence of NAT, ambiguous addresses [RFC1918], and address sharing [RFC6346]. These complexities might require further extending the objective with additional fields which are not defined by this document. 6. Prefix Management Parameters An implementation of a prefix manager MUST include default settings of all necessary parameters. However, within a single administrative domain, the network operator MAY change default parameters for all devices with a certain role. Thus it would be possible to apply an Jiang, et al. Expires June 18, 2018 [Page 11] Internet-Draft Auto IPv6 Prefix Management December 2017 intended policy for every device in a simple way, without traditional configuration files. As noted in Section 4.1, individual autonomic devices may also change their own behavior dynamically. For example, the network operator could change the default prefix length for each type of role. A prefix management parameters objective, which contains mapping information of device roles and their default prefix lengths, MAY be flooded in the network, through the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The objective is defined in CDDL as follows: objective = ["PrefixManager.Params", objective-flags, any] loop-count = 0..255 ; as in the GRASP specification objective-flags /= ; as in the GRASP specification The 'any' object would be the relevant parameter definitions (such as the example below) transmitted as a CBOR object in an appropriate format. This could be flooded to all nodes, and any PrefixManager ASA that did not receive it for some reason could obtain a copy using GRASP unicast synchronization. Upon receiving the prefix management parameters, every device can decide its default prefix length by matching its own role. 6.1. Example of Prefix Management Parameters The parameters comprise mapping information of device roles and their default prefix lengths in an autonomic domain. For example, suppose an IPRAN (IP Radio Access Network) operator wants to configure the prefix length of Radio Network Controller Site Gateway (RSG) as 34, the prefix length of Aggregation Site Gateway (ASG) as 44, and the prefix length of Cell Site Gateway (CSG) as 56. This could be described in the value of the PrefixManager.Params objective as: [ [["role", "RSG"],["prefix_length", 34]], [["role", "ASG"],["prefix_length", 44]], [["role", "CSG"],["prefix_length", 56]] ] This example is expressed in JSON notation [RFC7159], which is easy to represent in CBOR. Jiang, et al. Expires June 18, 2018 [Page 12] Internet-Draft Auto IPv6 Prefix Management December 2017 An alternative would be to express the parameters in YANG [RFC7950] using the YANG-to-CBOR mapping [I-D.ietf-core-yang-cbor]. For clarity, the background of the example is introduced below, which can also be regarded as a use case of the mechanism proposed in this document. An IPRAN network is used for mobile backhaul, including radio stations, RNC (in 3G) or the packet core (in LTE), and the IP network between them as shown in Figure 1. The eNB (Evolved Node B), RNC (Radio Network Controller), SGW (Service Gateway), and MME (Mobility Management Entity) are mobile network entities defined in 3GPP. The CSG, ASG, and RSG are entities defined in the IPRAN solution. The IPRAN topology shown in Figure 1 includes Ring1 which is the circle following ASG1->RSG1->RSG2->ASG2->ASG1, Ring2 following CSG1->ASG1->ASG2->CSG2->CSG1, and Ring3 following CSG3->ASG1->ASG2->CSG3. In a real deployment of IPRAN, there may be more stations, rings, and routers in the topology, and normally the network is highly dependent on human design and configuration, which is neither flexible nor cost-effective. +------+ +------+ | eNB1 |---| CSG1 |\ +------+ +------+ \ +-------+ +------+ +-------+ | \ | ASG1 |-------| RSG1 |-----------|SGW/MME| | Ring2 +-------+ +------+ \ /+-------+ +------+ +------+ / | | \ / | eNB2 |---| CSG2 | \ / | Ring1 | \/ +------+ +------+ \ Ring3| | /\ / \ | | / \ +------+ +------+ / \ +-------+ +------+/ \+-------+ | eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC | +------+ +------+ +-------+ +------+ +-------+ Figure 1: IPRAN Topology Example If ANI/GRASP is supported in the IPRAN network, the network nodes should be able to negotiate with each other, and make some autonomic decisions according to their own status and the information collected from the network. The Prefix Management Parameters should be part of the information they communicate. The routers should know the role of their neighbors, the default prefix length for each type of role, etc. An ASG should be able to request prefixes from an RSG, and an CSG should be able to request prefixes from an ASG. In each request, the ASG/CSG should indicate Jiang, et al. Expires June 18, 2018 [Page 13] Internet-Draft Auto IPv6 Prefix Management December 2017 the required prefix length, or its role, which implies what length it needs by default. 7. Security Considerations Relevant security issues are discussed in [I-D.ietf-anima-grasp]. The preferred security model is that devices are trusted following the secure bootstrap procedure [I-D.ietf-anima-bootstrapping-keyinfra] and that a secure Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane] is in place. It is RECOMMENDED that DHCPv6-PD, if used, should be operated using DHCPv6 authentication or Secure DHCPv6. 8. IANA Considerations This document defines two new GRASP Objective Option names, "PrefixManager" and "PrefixManager.Params". The IANA is requested to add these to the GRASP Objective Names Table registry defined by [I-D.ietf-anima-grasp] (if approved). 9. Acknowledgements Valuable comments were received from William Atwood, Fred Baker, Michael Behringer, Ben Campbell, Laurent Ciavaglia, Toerless Eckert, Joel Halpern, Russ Housley, Geoff Huston, Warren Kumari, Dan Romascanu, and Chongfeng Xie. 10. Change log [RFC Editor: Please remove] draft-jiang-anima-prefix-management-00: original version, 2014-10-25. draft-jiang-anima-prefix-management-01: add intent example and coauthor Zongpeng Du, 2015-05-04. draft-jiang-anima-prefix-management-02: update references and the format of the prefix management intent, 2015-10-14. draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and purpose, update text to match latest GRASP spec, 2016-01-11. draft-ietf-anima-prefix-management-01: minor update, 2016-07-08. draft-ietf-anima-prefix-management-02: replaced intent discussion by parameter setting, 2017-01-10. Jiang, et al. Expires June 18, 2018 [Page 14] Internet-Draft Auto IPv6 Prefix Management December 2017 draft-ietf-anima-prefix-management-03: corrected object format, improved parameter setting example, 2017-03-10. draft-ietf-anima-prefix-management-04: add more explanations about the solution, add IPv4 options, removed PD flag, 2017-06-23. draft-ietf-anima-prefix-management-05: selected one IPv4 option, updated references, 2017-08-14. draft-ietf-anima-prefix-management-06: handled IETF Last Call comments, 2017-10-18. draft-ietf-anima-prefix-management-07: handled IESG comments, 2017-12-18. 11. References 11.1. Normative References [I-D.ietf-anima-autonomic-control-plane] Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Control Plane (ACP)", draft-ietf-anima-autonomic-control- plane-12 (work in progress), October 2017. [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-09 (work in progress), October 2017. [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- grasp-15 (work in progress), July 2017. [I-D.ietf-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR data structures", draft-ietf-cbor-cddl-00 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Jiang, et al. Expires June 18, 2018 [Page 15] Internet-Draft Auto IPv6 Prefix Management December 2017 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Reference Model for Autonomic Networking", draft-ietf- anima-reference-model-05 (work in progress), October 2017. [I-D.ietf-core-yang-cbor] Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Minaburo, "CBOR Encoding of Data Modeled with YANG", draft-ietf-core-yang-cbor-05 (work in progress), August 2017. [I-D.liu-dhc-dhcp-yang-model] Liu, B., Lou, K., and C. Chen, "Yang Data Model for DHCP Protocol", draft-liu-dhc-dhcp-yang-model-06 (work in progress), March 2017. [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, . [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, . Jiang, et al. Expires June 18, 2018 [Page 16] Internet-Draft Auto IPv6 Prefix Management December 2017 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, . [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, . [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, . Appendix A. Deployment Overview This Appendix includes logical deployment models, and explanations of the target deployment models. The purpose is to help in understanding the mechanism of the document. This Appendix includes two sub-sections: A.1 for the two most common DHCP deployment models, and A.2 for the proposed PD deployment model. It should be noted that these are just examples, and there are many more deployment models. A.1. Address & Prefix management with DHCP Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD for IPv6 capable CPE that are router and have LANs behind them. Jiang, et al. Expires June 18, 2018 [Page 17] Internet-Draft Auto IPv6 Prefix Management December 2017 edge dynamic, "netconf/YANG" interfaces <---------------> +-------------+ +------+ <- telemetry | edge router/|-+ ----- +-----+ |config| .... Domain ... | DHCP server | | ... | CPE |+ LANs |server| +-------------+ | ----- +-----+| (---| ) +------+ +--------------+ DHCP/ +-----+ DHCPv6 / PD Figure 2: DHCP Deployment Model without a Central DHCP Server This requires various coordination functions via some backend system depicted as "config server": The address prefixes on the edge interfaces should be slightly larger than required for the number of CPEs connected so that the overall address space is best used. The config server needs to provision edge interface address prefixes and DHCP parameters for every edge router. If too fine grained prefixes are used, this will result in large routing tables across the "Domain". If too coarse grained prefixes are used, address space is wasted. (This is less of a concern for IPv6, but if the model includes IPv4, it is a very serious concern.) There is no standard describing algorithms for how configuration servers would best perform this ongoing dynamic provisioning to optimize routing table size and address space utilization. There are currently no complete YANG models that a config server could use to perform these actions (including telemetry of assigned addresses from such distributed DHCP servers). For example, a YANG model for controlling DHCP server operations is still in draft [I-D.liu-dhc-dhcp-yang-model]. Due to these and other problems of the above model, the more common DHCP deployment model is as follows: +------+ edge |config| initial, "CLI" interfaces |server| ----------------> +-------------+ +------+ | edge router/|-+ ----- +-----+ | .... Domain ... | DHCP relay | | ... | CPE |+ LANs +------+ +-------------+ | ----- +-----+| (---| ) |DHCP | +--------------+ DHCP/ +-----+ |server| DHCPv6 / PD +------+ Figure 3: DHCP Deployment Model with a Central DHCP Server Jiang, et al. Expires June 18, 2018 [Page 18] Internet-Draft Auto IPv6 Prefix Management December 2017 Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber identifying options into DHCP requests from CPE (e.g., [RFC3046], [RFC6221]), the DHCP server has complete policies for address assignments and prefixes useable on every edge-router/interface/ subscriber-group. When the DHCP relay sees the DHCP reply, it inserts static routes for the assigned address/address-prefix into the routing table of the edge router which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable across the Domain. There is no comprehensive standardization of these solutions. [RFC3633] section 14, for example, simply refers to "a [non-defined] protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router". A.2. Prefix management with ANI/GRASP With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model is intended to look as follows: |<............ ANI Domain / ACP............>| (...) ........-> Roles | v "Edge routers" GRASP parameter +----------+ Network wide | PM-ASA | downstream parameters/policies | (DHCP- | interfaces | |functions)| ------ v "central device" +----------+ +------+ ^ +--------+ |PM-ASA| <............GRASP .... .... | CPE |-+ (LANs) +------+ . v |(PM-ASA)| | ---| . +........+ +----------+ +--------+ | +...........+ . PM-ASA . | PM-ASA | ------ +---------+ .DHCP server. +........+ | (DHCP- | SLAAC/ +...........+ "intermediate |functions)| DHCP/DHCP-PD router" +----------+ Figure 4: Proposed Deployment Model using ANI/GRASP The network runs an ANI domain with ACP [I-D.ietf-anima-autonomic-control-plane] between some central device (e.g., router or ANI enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch communication channel between Jiang, et al. Expires June 18, 2018 [Page 19] Internet-Draft Auto IPv6 Prefix Management December 2017 the devices and enables the use of GRASP[I-D.ietf-anima-grasp] not only for p2p communication, but also for distribution/flooding. The central devices and edge routers run software in the form of "Autonomic Service Agents" (ASA) to support this document's autonomic IPv6 edge prefix management (PM). The ASAs for prefix management are called PM-ASAs below, and together comprise the Autonomic Prefix Management Function. Edge routers can have different roles based on the type and number of CPE attaching to them. Each edge router could be an RSG, ASG, or CSG in mobile aggregation networks (see Section 6.1). Mechanisms outside the scope of this document make routers aware of their roles. Some considerations about the proposed deployment model are listed as follows. 1. In a minimum Prefix Management solution, the central device uses the "PrefixManager.Params" GRASP Objective introduced in this document to disseminate network wide, per-role parameters to edge routers. The PM-ASA uses the parameters applying to its role to locally configure pre-existing addressing functions. Because PM-ASA does not manage the dynamic assignment of actual IPv6 address prefixes in this case, the following options can be considered: 1.a The edge router connects via downstream interfaces to (host) CPE that each requires an address. The PM-ASA sets up for each such interface a DHCP requesting router (according to [RFC3633]) to request an IPv6 prefix for the interface. The router's address on the downstream interface can be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs. A central DHCP server acting as the DHCP delegating router (according to [RFC3633]) is required. Its address can be another parameter from the GRASP Objective. 1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are routers and act as DHCPv6 requesting routers. The need to support this could be derived from role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests to the central DHCP server as in 1.a. 2. In a solution without a central DHCP server, the PM-ASA on the edge routers not only learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below. In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA in the central device. This Jiang, et al. Expires June 18, 2018 [Page 20] Internet-Draft Auto IPv6 Prefix Management December 2017 device must be provisioned initially with a large pool of prefixes. The delegated prefixes are then used by the PM-ASA on the edge routers to edge routers to configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the local DHCP servers it starts. It needs to monitor the address utilization and accordingly request more address prefixes if its existing prefixes are exhausted, or return address prefixes when they are unneeded. This solution is quite similar to the initial described IPv6 DHCP deployment model without central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provide the automation to make this approach work more easily than it is possible today. 3. The address pool(s) from which prefixes are allocated does not need to be taken all from one central location. Edge router PM-ASA that received a big (short) prefix from a central PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used in such a way that the PM-ASA would find and select the objective from the closest neighboring PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further (smaller/ shorter) prefixes when it exhausts its own poll (from the central location) and can not get further large prefixes from that central location anymore. Because the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited and the topological proximity increases the chances that aggregation of prefixes in the IGP can most likely limit the geography in which the longer prefixes need to be routed. 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built (indicated in the picture via a dotted intermediate router). This would require additional parameters to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the prefixes can be delegated. This is not detailed further below. 5. In cases where CPEs are also part of the ANI Domain (e.g., "Managed CPE"), then GRASP will extend into the actual customer sites and can equally run a PM-ASA. All the options described in points 1 to 4 above would then apply to the CPE as the edge router with the mayor changes being that a) a CPE router will most likley not need to run DHCPv6-PD itself, but only DHCP address assignment, b) The edge Jiang, et al. Expires June 18, 2018 [Page 21] Internet-Draft Auto IPv6 Prefix Management December 2017 routers to which the CPE connect would most likely become ideal places to run a hierarchical instance of PD-ASAs on as outlined in point 1. Authors' Addresses Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Zongpeng Du Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: duzongpeng@huawei.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Qiong Sun China Telecom No.118, Xizhimennei Street Beijing 100035 P. R. China Email: sunqiong@ctbri.com.cn Jiang, et al. Expires June 18, 2018 [Page 22] ./draft-ietf-hip-rfc4423-bis-20.txt0000644000764400076440000040425213431243406016001 0ustar iustyiusty Network Working Group R. Moskowitz, Ed. Internet-Draft HTT Consulting Obsoletes: 4423 (if approved) M. Komu Intended status: Informational Ericsson Expires: August 18, 2019 February 14, 2019 Host Identity Protocol Architecture draft-ietf-hip-rfc4423-bis-20 Abstract This memo describes the Host Identity (HI) namespace, that provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The section on security considerations describe also measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers and trust on first use. This document incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. 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 18, 2019. Moskowitz & Komu Expires August 18, 2019 [Page 1] Internet-Draft Host Identity Protocol Architecture February 2019 Copyright Notice Copyright (c) 2019 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terms common to other documents . . . . . . . . . . . . . . 4 2.2. Terms specific to this and other HIP documents . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. A desire for a namespace for computing platforms . . . . . 8 4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 9 4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 10 4.2. Host Identity Hash (HIH) . . . . . . . . . . . . . . . . . 11 4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 11 4.4. Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 12 4.5. Storing Host Identifiers in directories . . . . . . . . . . 13 5. New stack architecture . . . . . . . . . . . . . . . . . . . 14 5.1. On the multiplicity of identities . . . . . . . . . . . . . 15 6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. End-host mobility and multi-homing . . . . . . . . . . . . 17 6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 18 6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 18 Moskowitz & Komu Expires August 18, 2019 [Page 2] Internet-Draft Host Identity Protocol Architecture February 2019 6.5. Termination of the control plane . . . . . . . . . . . . . 18 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 20 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Security considerations . . . . . . . . . . . . . . . . . . . 21 11.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Protection against flooding attacks . . . . . . . . . . . 23 11.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 24 11.4. Alternative HI considerations . . . . . . . . . . . . . . 25 11.5. Trust On First Use . . . . . . . . . . . . . . . . . . . . 25 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 14. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 29 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 15.2. Informative references . . . . . . . . . . . . . . . . . . 31 Appendix A. Design considerations . . . . . . . . . . . . . . . 38 A.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . . 38 A.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 41 A.3. Deployment and adoption considerations . . . . . . . . . . 43 A.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . . 43 A.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 44 A.3.3. HIP and Internet of Things . . . . . . . . . . . . . . . 44 A.3.4. Infrastructure Applications . . . . . . . . . . . . . . . 46 A.3.5. Management of Identities in a Commercial Product . . . . 47 A.4. Answers to NSRG questions . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction The Internet has two important global namespaces: Internet Protocol (IP) addresses and Domain Name Service (DNS) names. These two namespaces have a set of features and abstractions that have powered the Internet to what it is today. They also have a number of weaknesses. Basically, since they are all we have, we try to do too much with them. Semantic overloading and functionality extensions have greatly complicated these namespaces. The proposed Host Identity namespace is also a global namespace, and it fills an important gap between the IP and DNS namespaces. A Host Identity conceptually refers to a computing platform, and there may be multiple such Host Identities per computing platform (because the platform may wish to present a different identity to different communicating peers). The Host Identity namespace consists of Host Identifiers (HI). There is exactly one Host Identifier for each Host Identity (although there may be transient periods of time such as key Moskowitz & Komu Expires August 18, 2019 [Page 3] Internet-Draft Host Identity Protocol Architecture February 2019 replacement when more than one identifier may be active). While this text later talks about non-cryptographic Host Identifiers, the architecture focuses on the case in which Host Identifiers are cryptographic in nature. Specifically, the Host Identifier is the public key of an asymmetric key-pair. Each Host Identity uniquely identifies a single host, i.e., no two hosts have the same Host Identity. If two or more computing platforms have the same Host Identifier, then they are instantiating a distributed host. The Host Identifier can either be public (e.g., published in the DNS), or unpublished. Client systems will tend to have both public and unpublished Host Identifiers. There is a subtle but important difference between Host Identities and Host Identifiers. An Identity refers to the abstract entity that is identified. An Identifier, on the other hand, refers to the concrete bit pattern that is used in the identification process. Although the Host Identifiers could be used in many authentication systems, such as IKEv2 [RFC4306], the presented architecture introduces a new protocol, called the Host Identity Protocol (HIP), and a cryptographic exchange, called the HIP base exchange; see also Section 6. HIP provides for limited forms of trust between systems, enhances mobility, multi-homing and dynamic IP renumbering, aids in protocol translation / transition, and reduces certain types of denial-of-service (DoS) attacks. When HIP is used, the actual payload traffic between two HIP hosts is typically, but not necessarily, protected with ESP [RFC7402]. The Host Identities are used to create the needed ESP Security Associations (SAs) and to authenticate the hosts. When ESP is used, the actual payload IP packets do not differ in any way from standard ESP protected IP packets. Much has been learned about HIP [RFC6538] since [RFC4423] was published. This document expands Host Identities beyond use to enable IP connectivity and security to general interhost secure signalling at any protocol layer. The signal may establish a security association between the hosts, or simply pass information within the channel. 2. Terminology 2.1. Terms common to other documents Moskowitz & Komu Expires August 18, 2019 [Page 4] Internet-Draft Host Identity Protocol Architecture February 2019 +---------------+---------------------------------------------------+ | Term | Explanation | +---------------+---------------------------------------------------+ | Public key | The public key of an asymmetric cryptographic key | | | pair. Used as a publicly known identifier for | | | cryptographic identity authentication. Public is | | | a relative term here, ranging from "known to | | | peers only" to "known to the world." | | Private key | The private or secret key of an asymmetric | | | cryptographic key pair. Assumed to be known only | | | to the party identified by the corresponding | | | public key. Used by the identified party to | | | authenticate its identity to other parties. | | Public key | An asymmetric cryptographic key pair consisting | | pair | of public and private keys. For example, Rivest- | | | Shamir-Adleman (RSA), Digital Signature Algorithm | | | (DSA) and Elliptic Curve DSA (ECDSA) key pairs | | | are such key pairs. | | End-point | A communicating entity. For historical reasons, | | | the term 'computing platform' is used in this | | | document as a (rough) synonym for end-point. | +---------------+---------------------------------------------------+ 2.2. Terms specific to this and other HIP documents It should be noted that many of the terms defined herein are tautologous, self-referential or defined through circular reference to other terms. This is due to the succinct nature of the definitions. See the text elsewhere in this document and the base specification [RFC7401] for more elaborate explanations. Moskowitz & Komu Expires August 18, 2019 [Page 5] Internet-Draft Host Identity Protocol Architecture February 2019 +---------------+---------------------------------------------------+ | Term | Explanation | +---------------+---------------------------------------------------+ | Computing | An entity capable of communicating and computing, | | platform | for example, a computer. See the definition of | | | 'End-point', above. | | | | | HIP base | A cryptographic protocol; see also Section 6 | | exchange | | | | | | HIP packet | An IP packet that carries a 'Host Identity | | | Protocol' message. | | | | | Host Identity | An abstract concept assigned to a 'computing | | | platform'. See 'Host Identifier', below. | | | | | Host | A public key used as a name for a Host Identity. | | Identifier | | | | | | Host Identity | A name space formed by all possible Host | | namespace | Identifiers. | | | | | Host Identity | A protocol used to carry and authenticate Host | | Protocol | Identifiers and other information. | | | | | Host Identity | The cryptographic hash used in creating the Host | | Hash | Identity Tag from the Host Identifier. | | | | | Host Identity | A 128-bit datum created by taking a cryptographic | | Tag | hash over a Host Identifier plus bits to identify | | | which hash used. | | | | | Local Scope | A 32-bit datum denoting a Host Identity. | | Identifier | | | | | | Public Host | A published or publicly known Host Identifier | | Identifier | used as a public name for a Host Identity, and | | and Identity | the corresponding Identity. | | | | | Unpublished | A Host Identifier that is not placed in any | | Host | public directory, and the corresponding Host | | Identifier | Identity. Unpublished Host Identities are | | and Identity | typically short lived in nature, being often | | | replaced and possibly used just once. | | | | | Rendezvous | A mechanism used to locate mobile hosts based on | | Mechanism | their HIT. | +---------------+---------------------------------------------------+ Moskowitz & Komu Expires August 18, 2019 [Page 6] Internet-Draft Host Identity Protocol Architecture February 2019 3. Background The Internet is built from three principal components: computing platforms (end-points), packet transport (i.e., internetworking) infrastructure, and services (applications). The Internet exists to service two principal components: people and robotic services (silicon-based people, if you will). All these components need to be named in order to interact in a scalable manner. Here we concentrate on naming computing platforms and packet transport elements. There are two principal namespaces in use in the Internet for these components: IP addresses, and Domain Names. Domain Names provide hierarchically assigned names for some computing platforms and some services. Each hierarchy is delegated from the level above; there is no anonymity in Domain Names. Email, HTTP, and SIP addresses all reference Domain Names. The IP addressing namespace has been overloaded to name both interfaces (at layer-3) and endpoints (for the endpoint-specific part of layer-3, and for layer-4). In their role as interface names, IP addresses are sometimes called "locators" and serve as an endpoint within a routing topology. IP addresses are numbers that name networking interfaces, and typically only when the interface is connected to the network. Originally, IP addresses had long-term significance. Today, the vast number of interfaces use ephemeral and/or non-unique IP addresses. That is, every time an interface is connected to the network, it is assigned an IP address. In the current Internet, the transport layers are coupled to the IP addresses. Neither can evolve separately from the other. IPng deliberations were strongly shaped by the decision that a corresponding TCPng would not be created. There are three critical deficiencies with the current namespaces. Firstly, establishing initial contact and sustaining of data flows between two hosts can be challenging due to private address realms and ephemeral nature of addresses. Secondly, confidentiality is not provided in a consistent, trustable manner. Finally, authentication for systems and datagrams is not provided. All of these deficiencies arise because computing platforms are not well named with the current namespaces. Moskowitz & Komu Expires August 18, 2019 [Page 7] Internet-Draft Host Identity Protocol Architecture February 2019 3.1. A desire for a namespace for computing platforms An independent namespace for computing platforms could be used in end-to-end operations independent of the evolution of the internetworking layer and across the many internetworking layers. This could support rapid readdressing of the internetworking layer because of mobility, rehoming, or renumbering. If the namespace for computing platforms is based on public-key cryptography, it can also provide authentication services. If this namespace is locally created without requiring registration, it can provide anonymity. Such a namespace (for computing platforms) and the names in it should have the following characteristics: o The namespace should be applied to the IP 'kernel' or stack. The IP stack is the 'component' between applications and the packet transport infrastructure. o The namespace should fully decouple the internetworking layer from the higher layers. The names should replace all occurrences of IP addresses within applications (like in the Transport Control Block, TCB). This replacement can be handled transparently for legacy applications as the LSIs and HITs are compatible with IPv4 and IPv6 addresses [RFC5338]. However, HIP-aware applications require some modifications from the developers, who may employ networking API extensions for HIP [RFC6317]. o The introduction of the namespace should not mandate any administrative infrastructure. Deployment must come from the bottom up, in a pairwise deployment. o The names should have a fixed-length representation, for easy inclusion in datagram headers and existing programming interfaces (e.g the TCB). o Using the namespace should be affordable when used in protocols. This is primarily a packet size issue. There is also a computational concern in affordability. o Name collisions should be avoided as much as possible. The mathematics of the birthday paradox can be used to estimate the chance of a collision in a given population and hash space. In general, for a random hash space of size n bits, we would expect to obtain a collision after approximately 1.2*sqrt(2**n) hashes were obtained. For 64 bits, this number is roughly 4 billion. A hash size of 64 bits may be too small to avoid collisions in a Moskowitz & Komu Expires August 18, 2019 [Page 8] Internet-Draft Host Identity Protocol Architecture February 2019 large population; for example, there is a 1% chance of collision in a population of 640M. For 100 bits (or more), we would not expect a collision until approximately 2**50 (1 quadrillion) hashes were generated. With the currently used hash size of 96 bits [RFC7343], the figure is 2**48 (281 trillions). o The names should have a localized abstraction so that they can be used in existing protocols and APIs. o It must be possible to create names locally. When such names are not published, this can provide anonymity at the cost of making resolvability very difficult. o The namespace should provide authentication services. o The names should be long-lived, but replaceable at any time. This impacts access control lists; short lifetimes will tend to result in tedious list maintenance or require a namespace infrastructure for central control of access lists. In this document, the namespace approaching these ideas is called the Host Identity namespace. Using Host Identities requires its own protocol layer, the Host Identity Protocol, between the internetworking and transport layers. The names are based on public- key cryptography to supply authentication services. Properly designed, it can deliver all of the above-stated requirements. 4. Host Identity namespace A name in the Host Identity namespace, a Host Identifier (HI), represents a statistically globally unique name for naming any system with an IP stack. This identity is normally associated with, but not limited to, an IP stack. A system can have multiple identities, some 'well known', some unpublished or 'anonymous'. A system may self- assert its own identity, or may use a third-party authenticator like DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion to another namespace. In theory, any name that can claim to be 'statistically globally unique' may serve as a Host Identifier. In the HIP architecture, the public key of a private-public key pair has been chosen as the Host Identifier because it can be self-managed and it is computationally difficult to forge. As specified in the Host Identity Protocol [RFC7401] specification, a public-key-based HI can authenticate the HIP packets and protect them from man-in-the-middle attacks. Since authenticated datagrams are mandatory to provide much of HIP's denial-of-service protection, the Diffie-Hellman exchange in HIP base Moskowitz & Komu Expires August 18, 2019 [Page 9] Internet-Draft Host Identity Protocol Architecture February 2019 exchange has to be authenticated. Thus, only public-key HI and authenticated HIP messages are supported in practice. In this document, some non-cryptographic forms of HI and HIP are referenced, but cryptographic forms SHOULD be preferred because they are more secure than their non-cryptographic counterparts. There has been past research in challenge puzzles to use non-cryptographic HI, for Radio Frequency IDentification (RFID), in an HIP exchange tailored to the workings of such challenges (as described further in [urien-rfid] and [urien-rfid-draft]). 4.1. Host Identifiers Host Identity adds two main features to Internet protocols. The first is a decoupling of the internetworking and transport layers; see Section 5. This decoupling will allow for independent evolution of the two layers. Additionally, it can provide end-to-end services over multiple internetworking realms. The second feature is host authentication. Because the Host Identifier is a public key, this key can be used for authentication in security protocols like ESP. An identity is based on public-private key cryptography in HIP. The Host Identity is referred to by its public component, the public key. Thus, the name representing a Host Identity in the Host Identity namespace, i.e., the Host Identifier, is the public key. In a way, the possession of the private key defines the Identity itself. If the private key is possessed by more than one node, the Identity can be considered to be a distributed one. Architecturally, any other Internet naming convention might form a usable base for Host Identifiers. However, non-cryptographic names should only be used in situations of high trust - low risk. That is any place where host authentication is not needed (no risk of host spoofing) and no use of ESP. However, at least for interconnected networks spanning several operational domains, the set of environments where the risk of host spoofing allowed by non- cryptographic Host Identifiers is acceptable is the null set. Hence, the current HIP documents do not specify how to use any other types of Host Identifiers but public keys. For instance, Back-to-My-Mac [RFC6281] from Apple comes pretty close to the functionality of HIP, but unlike HIP, it is based on non-cryptographic identifiers. The actual Host Identifiers are never directly used at the transport or network layers. The corresponding Host Identifiers (public keys) may be stored in various DNS or other directories as identified elsewhere in this document, and they are passed in the HIP base exchange. A Host Identity Tag (HIT) is used in other protocols to represent the Host Identity. Another representation of the Host Moskowitz & Komu Expires August 18, 2019 [Page 10] Internet-Draft Host Identity Protocol Architecture February 2019 Identities, the Local Scope Identifier (LSI), can also be used in protocols and APIs. 4.2. Host Identity Hash (HIH) The Host Identity Hash (HIH) is the cryptographic hash algorithm used in producing the HIT from the HI. It is also the hash used throughout the HIP protocol for consistency and simplicity. It is possible for the two hosts in the HIP exchange to use different hash algorithms. Multiple HIHs within HIP are needed to address the moving target of creation and eventual compromise of cryptographic hashes. This significantly complicates HIP and offers an attacker an additional downgrade attack that is mitigated in the HIP protocol [RFC7401]. 4.3. Host Identity Tag (HIT) A Host Identity Tag (HIT) is a 128-bit representation for a Host Identity. Due to its size, it is suitable to be used in the existing sockets API in the place of IPv6 addresses (e.g., in sockaddr_in6 structure, sin6_addr member) without modifying applications. It is created from an HIH, an IPv6 prefix [RFC7343] and a hash identifier. There are two advantages of using the HIT over using the Host Identifier in protocols. Firstly, its fixed length makes for easier protocol coding and also better manages the packet size cost of this technology. Secondly, it presents the identity in a consistent format to the protocol independent of the cryptographic algorithms used. In essence, the HIT is a hash over the public key. As such, two algorithms affect the generation of a HIT: the public-key algorithm of the HI and the used HIH. The two algorithms are encoded in the bit presentation of the HIT. As the two communicating parties may support different algorithms, [RFC7401] defines the minimum set for interoperability. For further interoperability, the responder may store its keys in DNS records, and thus the initiator may have to couple destination HITs with appropriate source HITs according to matching HIH. In the HIP packets, the HITs identify the sender and recipient of a packet. Consequently, a HIT should be unique in the whole IP universe as long as it is being used. In the extremely rare case of a single HIT mapping to more than one Host Identity, the Host Identifiers (public keys) will make the final difference. If there is more than one public key for a given node, the HIT acts as a hint for the correct public key to use. Moskowitz & Komu Expires August 18, 2019 [Page 11] Internet-Draft Host Identity Protocol Architecture February 2019 Although it may be rare for an accidental collision to cause a single HIT mapping to more than one Host Identity, it may be the case that an attacker succeeds to find, by brute force or algorithmic weakness, a second Host Identity hashing to the same HIT. This type of attack is known as a preimage attack, and the resistance to finding a second Host Identifier (public key) that hashes to the same HIT is called second preimage resistance. Second preimage resistance in HIP is based on the hash algorithm strength and the length of the hash output used. Through HIPv2 [RFC7401], this resistance is 96 bits (less than the 128 bit width of an IPv6 address field due to the presence of the ORCHID prefix [RFC7343]). 96 bits of resistance was considered acceptable strength during the design of HIP, but may eventually be considered insufficient for the threat model of an envisioned deployment. One possible mitigation would be to augment the use of HITs in the deployment with the HIs themselves (and mechanisms to securely bind the HIs to the HITs), so that the HI becomes the final authority. It also may be possible to increase the difficulty of brute force attack by making the generation of the HI more computationally difficult, such as the hash extension approach of SEND CGAs [RFC3972], although the HIP specifications through HIPv2 do not provide such a mechanism. Finally, deployments that do not use ORCHIDs (such as certain types of overlay networks) might also use the full 128-bit width of an IPv6 address field for the HIT. 4.4. Local Scope Identifier (LSI) An LSI is a 32-bit localized representation for a Host Identity. Due to its size, it is suitable to be used in the existing sockets API in the place of IPv4 addresses (e.g., in sockaddr_in structure, sin_addr member) without modifying applications. The purpose of an LSI is to facilitate using Host Identities in existing APIs for IPv4-based applications. LSIs are never transmitted on the wire; when an application sends data using a pair of LSIs, the HIP layer (or sockets handler) translates the LSIs to the corresponding HITs, and vice versa for receiving of data. Besides facilitating HIP-based connectivity for legacy IPv4 applications, the LSIs are beneficial in two other scenarios [RFC6538]. In the first scenario, two IPv4-only applications are residing on two separate hosts connected by IPv6-only network. With HIP-based connectivity, the two applications are able to communicate despite of the mismatch in the protocol families of the applications and the underlying network. The reason is that the HIP layer translates the LSIs originating from the upper layers into routable IPv6 locators before delivering the packets on the wire. The second scenario is the same as the first one, but with the difference that one of the applications supports only IPv6. Now two Moskowitz & Komu Expires August 18, 2019 [Page 12] Internet-Draft Host Identity Protocol Architecture February 2019 obstacles hinder the communication between the application: the addressing families of the two applications differ, and the application residing at the IPv4-only side is again unable to communicate because of the mismatch between addressing families of the application (IPv4) and network (IPv6). With HIP-based connectivity for applications, this scenario works; the HIP layer can choose whether to translate the locator of an incoming packet into an LSI or HIT. Effectively, LSIs improve IPv6 interoperability at the network layer as described in the first scenario and at the application layer as depicted in the second example. The interoperability mechanism should not be used to avoid transition to IPv6; the authors firmly believe in IPv6 adoption and encourage developers to port existing IPv4-only applications to use IPv6. However, some proprietary, closed-source, IPv4-only applications may never see the daylight of IPv6, and the LSI mechanism is suitable for extending the lifetime of such applications even in IPv6-only networks. The main disadvantage of an LSI is its local scope. Applications may violate layering principles and pass LSIs to each other in application-layer protocols. As the LSIs are valid only in the context of the local host, they may represent an entirely different host when passed to another host. However, it should be emphasized here that the LSI concept is effectively a host-based NAT and does not introduce any more issues than the prevalent middlebox based NATs for IPv4. In other words, the applications violating layering principles are already broken by the NAT boxes that are ubiquitously deployed. 4.5. Storing Host Identifiers in directories The public Host Identifiers should be stored in DNS; the unpublished Host Identifiers should not be stored anywhere (besides the communicating hosts themselves). The (public) HI along with the supported HIHs are stored in a new RR type. This RR type is defined in HIP DNS Extension [RFC8005]. Alternatively, or in addition to storing Host Identifiers in the DNS, they may be stored in various other directories. For instance, a directory based on the Lightweight Directory Access Protocol (LDAP) or a Public Key Infrastructure (PKI) [RFC8002] may be used. Alternatively, Distributed Hash Tables (DHTs) [RFC6537] have successfully been utilized [RFC6538]. Such a practice may allow them to be used for purposes other than pure host identification. Some types of applications may cache and use Host Identifiers directly, while others may indirectly discover them through symbolic Moskowitz & Komu Expires August 18, 2019 [Page 13] Internet-Draft Host Identity Protocol Architecture February 2019 host name (such as FQDN) look up from a directory. Even though Host Identities can have a substantially longer lifetime associated with them than routable IP addresses, directories may be a better approach to manage the lifespan of Host Identities. For example, an LDAP- based directory or DHT can be used for locally published identities whereas DNS can be more suitable for public advertisement. 5. New stack architecture One way to characterize Host Identity is to compare the proposed HI- based architecture with the current one. Using the terminology from the IRTF Name Space Research Group Report [nsrg-report] and, e.g., the unpublished Internet-Draft Endpoints and Endpoint Names [chiappa-endpoints], the IP addresses currently embody the dual role of locators and end-point identifiers. That is, each IP address names a topological location in the Internet, thereby acting as a routing direction vector, or locator. At the same time, the IP address names the physical network interface currently located at the point-of-attachment, thereby acting as a end-point name. In the HIP architecture, the end-point names and locators are separated from each other. IP addresses continue to act as locators. The Host Identifiers take the role of end-point identifiers. It is important to understand that the end-point names based on Host Identities are slightly different from interface names; a Host Identity can be simultaneously reachable through several interfaces. The difference between the bindings of the logical entities are illustrated in Figure 1. The left side illustrates the current TCP/ IP architecture and the right side the HIP-based architecture. Transport ---- Socket Transport ------ Socket association | association | | | | | | | End-point | End-point --- Host Identity \ | | \ | | \ | | \ | | Location --- IP address Location --- IP address Figure 1 Moskowitz & Komu Expires August 18, 2019 [Page 14] Internet-Draft Host Identity Protocol Architecture February 2019 Architecturally, HIP provides for a different binding of transport- layer protocols. That is, the transport-layer associations, i.e., TCP connections and UDP associations, are no longer bound to IP addresses but rather to Host Identities. In practice, the Host Identities are exposed as LSIs and HITs for legacy applications and the transport layer to facilitate backward compatibility with existing networking APIs and stacks. The HIP layer is logically located at layer 3.5, between the transport and network layers, in the networking stack. It acts as shim layer for transport data utilizing LSIs or HITs, but leaves other data intact. The HIP layer translates between the two forms of HIP identifiers originating from the transport layer into routable IPv4/IPv6 addresses for the network layer, and vice versa for the reverse direction. 5.1. On the multiplicity of identities A host may have multiple identities both at the client and server side. This raises some additional concerns that are addressed in this section. For security reasons, it may be a bad idea to duplicate the same Host Identity on multiple hosts because the compromise of a single host taints the identities of the other hosts. Management of machines with identical Host Identities may also present other challenges and, therefore, it is advisable to have a unique identity for each host. At the server side, utilizing DNS is a better alternative than a shared Host Identity to implement load balancing. A single FQDN entry can be configured to refer to multiple Host Identities. Each of the FQDN entries can be associated with the related locators, or a single shared locator in the case the servers are using the same HIP rendezvous server Section 6.3 or HIP relay server Section 6.4. Instead of duplicating identities, HIP opportunistic mode can be employed, where the initiator leaves out the identifier of the responder when initiating the key exchange and learns it upon the completion of the exchange. The tradeoffs are related to lowered security guarantees, but a benefit of the approach is to avoid publishing of Host Identifiers in any directories [komu-leap]. Since many public servers already employ DNS as their directory, opportunistic mode may be more suitable for, e.g, peer-to-peer connectivity. It is also worth noting that opportunistic mode is also required in practice when anycast IP addresses would be utilized as locators. Moskowitz & Komu Expires August 18, 2019 [Page 15] Internet-Draft Host Identity Protocol Architecture February 2019 HIP opportunistic mode could be utilized in association with HIP rendezvous servers or HIP relay servers [komu-diss]. In such a scenario, the Initiator sends an I1 message with a wildcard destination HIT to the locator of a HIP rendezvous/relay server. When the receiving rendezvous/relay server is serving multiple registered Responders, the server can choose the ultimate destination HIT, thus acting as a HIP based load balancer. However, this approach is still experimental and requires further investigation. At the client side, a host may have multiple Host Identities, for instance, for privacy purposes. Another reason can be that the person utilizing the host employs different identities for different administrative domains as an extra security measure. If a HIP-aware middlebox, such as a HIP-based firewall, is on the path between the client and server, the user or the underlying system should carefully choose the correct identity to avoid the firewall to unnecessarily drop HIP-based connectivity [komu-diss]. Similarly, a server may have multiple Host Identities. For instance, a single web server may serve multiple different administrative domains. Typically, the distinction is accomplished based on the DNS name, but also the Host Identity could be used for this purpose. However, a more compelling reason to employ multiple identities are HIP-aware firewalls that are unable see the HTTP traffic inside the encrypted IPsec tunnel. In such a case, each service could be configured with a separate identity, thus allowing the firewall to segregate the different services of the single web server from each other [lindqvist-enterprise]. 6. Control plane HIP decouples control and data plane from each other. Two end-hosts initialize the control plane using a key exchange procedure called the base exchange. The procedure can be assisted by HIP specific infrastructural intermediaries called rendezvous or relay servers. In the event of IP address changes, the end-hosts sustain control plane connectivity with mobility and multihoming extensions. Eventually, the end-hosts terminate the control plane and remove the associated state. 6.1. Base exchange The base exchange is a key exchange procedure that authenticates the initiator and responder to each other using their public keys. Typically, the initiator is the client-side host and the responder is the server-side host. The roles are used by the state machine of a HIP implementation, but discarded upon successful completion. Moskowitz & Komu Expires August 18, 2019 [Page 16] Internet-Draft Host Identity Protocol Architecture February 2019 The exchange consists of four messages during which the hosts also create symmetric keys to protect the control plane with Hash-based message authentication codes (HMACs). The keys can be also used to protect the data plane, and IPsec ESP [RFC7402] is typically used as the data-plane protocol, albeit HIP can also accommodate others. Both the control and data plane are terminated using a closing procedure consisting of two messages. In addition, the base exchange also includes a computational puzzle [RFC7401] that the initiator must solve. The responder chooses the difficulty of the puzzle which permits the responder to delay new incoming initiators according to local policies, for instance, when the responder is under heavy load. The puzzle can offer some resiliency against DoS attacks because the design of the puzzle mechanism allows the responder to remain stateless until the very end of the base exchange [aura-dos]. HIP puzzles have also been studied under steady-state DDoS attacks [beal-dos], on multiple adversary models with varying puzzle difficulties [tritilanunt-dos] and with ephemeral Host Identities [komu-mitigation]. 6.2. End-host mobility and multi-homing HIP decouples the transport from the internetworking layer, and binds the transport associations to the Host Identities (actually through either the HIT or LSI). After the initial key exchange, the HIP layer maintains transport-layer connectivity and data flows using its mobility [RFC8046] and multihoming [RFC8047] extensions. Consequently, HIP can provide for a degree of internetworking mobility and multi-homing at a low infrastructure cost. HIP mobility includes IP address changes (via any method) to either party. Thus, a system is considered mobile if its IP address can change dynamically for any reason like PPP, DHCP, IPv6 prefix reassignments, or a NAT device remapping its translation. Likewise, a system is considered multi-homed if it has more than one globally routable IP address at the same time. HIP links IP addresses together, when multiple IP addresses correspond to the same Host Identity. If one address becomes unusable, or a more preferred address becomes available, existing transport associations can easily be moved to another address. When a mobile node moves while communication is already on-going, address changes are rather straightforward. The mobile node sends a HIP UPDATE packet to inform the peer of the new address(es), and the peer then verifies that the mobile node is reachable through these addresses. This way, the peer can avoid flooding attacks as further discussed in Section 11.2. Moskowitz & Komu Expires August 18, 2019 [Page 17] Internet-Draft Host Identity Protocol Architecture February 2019 6.3. Rendezvous mechanism Establishing a contact to a mobile, moving node is slightly more involved. In order to start the HIP exchange, the initiator node has to know how to reach the mobile node. For instance, the mobile node can employ Dynamic DNS [RFC2136] to update its reachability information in the DNS. To avoid the dependency to DNS, HIP provides its own HIP-specific alternative: the HIP rendezvous mechanism as defined in HIP Rendezvous specifications [RFC8004]. Using the HIP rendezvous extensions, the mobile node keeps the rendezvous infrastructure continuously updated with its current IP address(es). The mobile nodes trusts the rendezvous mechanism in order to properly maintain their HIT and IP address mappings. The rendezvous mechanism is especially useful in scenarios where both of the nodes are expected to change their address at the same time. In such a case, the HIP UPDATE packets will cross each other in the network and never reach the peer node. 6.4. Relay mechanism The HIP relay mechanism [I-D.ietf-hip-native-nat-traversal] is an alternative to the HIP rendezvous mechanism. The HIP relay mechanism is more suitable for IPv4 networks with NATs because a HIP relay can forward all control and data plane communications in order to guarantee successful NAT traversal. 6.5. Termination of the control plane The control plane between two hosts is terminated using a secure two- message exchange as specified in base exchange specification [RFC7401]. The related state (i.e. host associations) should be removed upon successful termination. 7. Data plane The encapsulation format for the data plane used for carrying the application-layer traffic can be dynamically negotiated during the key exchange. For instance, HICCUPS extensions [RFC6078] define one way to transport application-layer datagrams directly over the HIP control plane, protected by asymmetric key cryptography. Also, SRTP has been considered as the data encapsulation protocol [hip-srtp]. However, the most widely implemented method is the Encapsulated Security Payload (ESP) [RFC7402] that is protected by symmetric keys derived during the key exchange. ESP Security Associations (SAs) offer both confidentiality and integrity protection, of which the Moskowitz & Komu Expires August 18, 2019 [Page 18] Internet-Draft Host Identity Protocol Architecture February 2019 former can be disabled during the key exchange. In the future, other ways of transporting application-layer data may be defined. The ESP SAs are established and terminated between the initiator and the responder hosts. Usually, the hosts create at least two SAs, one in each direction (initiator-to-responder SA and responder-to- initiator SA). If the IP addresses of either host changes, the HIP mobility extensions can be used to re-negotiate the corresponding SAs. On the wire, the difference in the use of identifiers between the HIP control and data plane is that the HITs are included in all control packets, but not in the data plane when ESP is employed. Instead, the ESP employs SPI numbers that act as compressed HITs. Any HIP- aware middlebox (for instance, a HIP-aware firewall) interested in the ESP based data plane should keep track between the control and data plane identifiers in order to associate them with each other. Since HIP does not negotiate any SA lifetimes, all lifetimes are subject to local policy. The only lifetimes a HIP implementation must support are sequence number rollover (for replay protection), and SA timeout. An SA times out if no packets are received using that SA. Implementations may support lifetimes for the various ESP transforms and other data-plane protocols. 8. HIP and NATs Passing packets between different IP addressing realms requires changing IP addresses in the packet header. This may occur, for example, when a packet is passed between the public Internet and a private address space, or between IPv4 and IPv6 networks. The address translation is usually implemented as Network Address Translation (NAT) [RFC3022] or NAT Protocol translation (NAT-PT) [RFC2766]. In a network environment where identification is based on the IP addresses, identifying the communicating nodes is difficult when NATs are employed because private address spaces are overlapping. In other words, two hosts cannot be distinguished from each other solely based on their IP address. With HIP, the transport-layer end-points (i.e. applications) are bound to unique Host Identities rather than overlapping private addresses. This allows two end-points to distinguish one other even when they are located in different private address realms. Thus, the IP addresses are used only for routing purposes and can be changed freely by NATs when a packet between two HIP capable hosts traverses through multiple private address realms. Moskowitz & Komu Expires August 18, 2019 [Page 19] Internet-Draft Host Identity Protocol Architecture February 2019 NAT traversal extensions for HIP [I-D.ietf-hip-native-nat-traversal] can be used to realize the actual end-to-end connectivity through NAT devices. To support basic backward compatibility with legacy NATs, the extensions encapsulate both HIP control and data plane in UDP. The extensions define mechanisms for forwarding the two planes through an intermediary host called HIP relay and procedures to establish direct end-to-end connectivity by penetrating NATs. Besides this "native" NAT traversal mode for HIP, other NAT traversal mechanisms have been successfully utilized, such as Teredo [RFC4380] (as described in further detail in [varjonen-split]). Besides legacy NATs, a HIP-aware NAT has been designed and implemented [ylitalo-spinat]. For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the mapping of HITs, and the corresponding ESP SPIs, to an IP address. The NAT system has to learn mappings both from HITs and from SPIs to IP addresses. Many HITs (and SPIs) can map to a single IP address on a NAT, simplifying connections on address-poor NAT interfaces. The NAT can gain much of its knowledge from the HIP packets themselves; however, some NAT configuration may be necessary. 8.1. HIP and Upper-layer checksums There is no way for a host to know if any of the IP addresses in an IP header are the addresses used to calculate the TCP checksum. That is, it is not feasible to calculate the TCP checksum using the actual IP addresses in the pseudo header; the addresses received in the incoming packet are not necessarily the same as they were on the sending host. Furthermore, it is not possible to recompute the upper-layer checksums in the NAT/NAT-PT system, since the traffic is ESP protected. Consequently, the TCP and UDP checksums are calculated using the HITs in the place of the IP addresses in the pseudo header. Furthermore, only the IPv6 pseudo header format is used. This provides for IPv4 / IPv6 protocol translation. 9. Multicast A number of studies investigating HIP-based multicast have been published (including [shields-hip], [xueyong-hip], [xueyong-hip], [amir-hip], [kovacshazi-host] and [xueyong-secure]). In particular, so-called Bloom filters, that allow compressing of multiple labels into small data structures, may be a promising way forward [sarela-bloom]. However, the different schemes have not been adopted by the HIP working group (nor the HIP research group in IRTF), so the details are not further elaborated here. Moskowitz & Komu Expires August 18, 2019 [Page 20] Internet-Draft Host Identity Protocol Architecture February 2019 10. HIP policies There are a number of variables that influence the HIP exchange that each host must support. All HIP implementations should support at least 2 HIs, one to publish in DNS or similar directory service and an unpublished one for anonymous usage (that should expect to be rotated frequently in order to disrupt linkability/trackability). Although unpublished HIs will be rarely used as responder HIs, they are likely to be common for initiators. As stated in [RFC7401], "all HIP implementations MUST support more than one simultaneous HI, at least one of which SHOULD be reserved for anonymous usage", and "support for more than two HIs is RECOMMENDED". This provides new challenges for systems or users to decide which type of HI to expose when they start a new session. Opportunistic mode (where the initiator starts a HIP exchange without prior knowledge of the responder's HI) presents a security tradeoff. At the expense of being subject to MITM attacks, the opportunistic mode allows the initiator to learn the identity of the responder during communication rather than from an external directory. Opportunistic mode can be used for registration to HIP-based services [RFC8003] (i.e. utilized by HIP for its own internal purposes) or by the application layer [komu-leap]. For security reasons, especially the latter requires some involvement from the user to accept the identity of the responder similar to how SSH prompts the user when connecting to a server for the first time [pham-leap]. In practice, this can be realized in end-host based firewalls in the case of legacy applications [karvonen-usable] or with native APIs for HIP APIs [RFC6317] in the case of HIP-aware applications. As stated in [RFC7401], "Initiators MAY use a different HI for different Responders to provide basic privacy. Whether such private HIs are used repeatedly with the same Responder, and how long these HIs are used, are decided by local policy and depend on the privacy requirements of the Initiator". According to [RFC7401], "Responders that only respond to selected Initiators require an Access Control List (ACL), representing for which hosts they accept HIP base exchanges, and the preferred transport format and local lifetimes. Wildcarding SHOULD be supported for such ACLs, and also for Responders that offer public or anonymous services". 11. Security considerations This section includes discussion on some issues and solutions related to security in the HIP architecture. Moskowitz & Komu Expires August 18, 2019 [Page 21] Internet-Draft Host Identity Protocol Architecture February 2019 11.1. MiTM Attacks HIP takes advantage of the Host Identity paradigm to provide secure authentication of hosts and to provide a fast key exchange for ESP. HIP also attempts to limit the exposure of the host to various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. In so doing, HIP itself is subject to its own DoS and MitM attacks that potentially could be more damaging to a host's ability to conduct business as usual. Resource exhausting denial-of-service attacks take advantage of the cost of setting up a state for a protocol on the responder compared to the 'cheapness' on the initiator. HIP allows a responder to increase the cost of the start of state on the initiator and makes an effort to reduce the cost to the responder. This is done by having the responder start the authenticated Diffie-Hellman exchange instead of the initiator, making the HIP base exchange 4 packets long. The first packet sent by the responder can be prebuilt to further mitigate the costs. This packet also includes a computational puzzle that can optionally be used to further delay the initiator, for instance, when the responder is overloaded. The details are explained in the base exchange specification [RFC7401]. Man-in-the-middle (MitM) attacks are difficult to defend against, without third-party authentication. A skillful MitM could easily handle all parts of the HIP base exchange, but HIP indirectly provides the following protection from a MitM attack. If the responder's HI is retrieved from a signed DNS zone or securely obtained by some other means, the initiator can use this to authenticate the signed HIP packets. Likewise, if the initiator's HI is in a secure DNS zone, the responder can retrieve it and validate the signed HIP packets. However, since an initiator may choose to use an unpublished HI, it knowingly risks a MitM attack. The responder may choose not to accept a HIP exchange with an initiator using an unknown HI. Other types of MitM attacks against HIP can be mounted using ICMP messages that can be used to signal about problems. As an overall guideline, the ICMP messages should be considered as unreliable "hints" and should be acted upon only after timeouts. The exact attack scenarios and countermeasures are described in full detail the base exchange specification [RFC7401]. A MitM attacker could try to replay older I1 or R1 messages using weaker cryptographic algorithms as described in section 4.1.4 in [RFC7401]. The base exchange has been augmented to deal with such an attack by restarting on detecting the attack. At worst this would only lead to a situation in which the base exchange would never Moskowitz & Komu Expires August 18, 2019 [Page 22] Internet-Draft Host Identity Protocol Architecture February 2019 finish (or would be aborted after some retries). As a drawback, this leads to a 6-way base exchange which may seem bad at first. However, since this only occurs in an attack scenario and since the attack can be handled (so it is not interesting to mount anymore), we assume the subsequent messages do not represent a security threat. Since the MitM cannot be successful with a downgrade attack, these sorts of attacks will only occur as 'nuisance' attacks. So, the base exchange would still be usually just four packets even though implementations must be prepared to protect themselves against the downgrade attack. In HIP, the Security Association for ESP is indexed by the SPI; the source address is always ignored, and the destination address may be ignored as well. Therefore, HIP-enabled Encapsulated Security Payload (ESP) is IP address independent. This might seem to make attacking easier, but ESP with replay protection is already as well protected as possible, and the removal of the IP address as a check should not increase the exposure of ESP to DoS attacks. 11.2. Protection against flooding attacks Although the idea of informing about address changes by simply sending packets with a new source address appears appealing, it is not secure enough. That is, even if HIP does not rely on the source address for anything (once the base exchange has been completed), it appears to be necessary to check a mobile node's reachability at the new address before actually sending any larger amounts of traffic to the new address. Blindly accepting new addresses would potentially lead to flooding Denial-of-Service attacks against third parties [RFC4225]. In a distributed flooding attack an attacker opens high volume HIP connections with a large number of hosts (using unpublished HIs), and then claims to all of these hosts that it has moved to a target node's IP address. If the peer hosts were to simply accept the move, the result would be a packet flood to the target node's address. To prevent this type of attack, HIP mobility extensions include a return routability check procedure where the reachability of a node is separately checked at each address before using the address for larger amounts of traffic. A credit-based authorization approach for host mobility with the Host Identity Protocol [RFC8046] can be used between hosts for sending data prior to completing the address tests. Otherwise, if HIP is used between two hosts that fully trust each other, the hosts may optionally decide to skip the address tests. However, such performance optimization must be restricted to peers that are known to be trustworthy and capable of protecting themselves from malicious software. Moskowitz & Komu Expires August 18, 2019 [Page 23] Internet-Draft Host Identity Protocol Architecture February 2019 11.3. HITs used in ACLs At end-hosts, HITs can be used in IP-based access control lists at the application and network layers. At middleboxes, HIP-aware firewalls [lindqvist-enterprise] can use HITs or public keys to control both ingress and egress access to networks or individual hosts, even in the presence of mobile devices because the HITs and public keys are topology independent. As discussed earlier in Section 7, once a HIP session has been established, the SPI value in an ESP packet may be used as an index, indicating the HITs. In practice, firewalls can inspect HIP packets to learn of the bindings between HITs, SPI values, and IP addresses. They can even explicitly control ESP usage, dynamically opening ESP only for specific SPI values and IP addresses. The signatures in HIP packets allow a capable firewall to ensure that the HIP exchange is indeed occurring between two known hosts. This may increase firewall security. A potential drawback of HITs in ACLs is their 'flatness' means they cannot be aggregated, and this could potentially result in larger table searches in HIP-aware firewalls. A way to optimize this could be to utilize Bloom filters for grouping of HITs [sarela-bloom]. However, it should be noted that it is also easier to exclude individual, misbehaving hosts out when the firewall rules concern individual HITs rather than groups. There has been considerable bad experience with distributed ACLs that contain public key related material, for example, with SSH. If the owner of a key needs to revoke it for any reason, the task of finding all locations where the key is held in an ACL may be impossible. If the reason for the revocation is due to private key theft, this could be a serious issue. A host can keep track of all of its partners that might use its HIT in an ACL by logging all remote HITs. It should only be necessary to log responder hosts. With this information, the host can notify the various hosts about the change to the HIT. There have been attempts to develop a secure method to issue the HIT revocation notice [zhang-revocation]. Some of the HIP-aware middleboxes, such as firewalls [lindqvist-enterprise] or NATs [ylitalo-spinat], may observe the on- path traffic passively. Such middleboxes are transparent by their nature and may not get a notification when a host moves to a different network. Thus, such middleboxes should maintain soft state and timeout when the control and data plane between two HIP end-hosts has been idle too long. Correspondingly, the two end-hosts may send periodically keepalives, such as UPDATE packets or ICMP messages inside the ESP tunnel, to sustain state at the on-path middleboxes. Moskowitz & Komu Expires August 18, 2019 [Page 24] Internet-Draft Host Identity Protocol Architecture February 2019 One general limitation related to end-to-end encryption is that middleboxes may not be able to participate to the protection of data flows. While the issue may affect also other protocols, Heer at al [heer-end-host] have analyzed the problem in the context of HIP. More specifically, when ESP is used as the data-plane protocol for HIP, the association between the control and data plane is weak and can be exploited under certain assumptions. In the scenario, the attacker has already gained access to the target network protected by a HIP-aware firewall, but wants to circumvent the HIP-based firewall. To achieve this, the attacker passively observes a base exchange between two HIP hosts and later replays it. This way, the attacker manages to penetrate the firewall and can use a fake ESP tunnel to transport its own data. This is possible because the firewall cannot distinguish when the ESP tunnel is valid. As a solution, HIP-aware middleboxes may participate to the control plane interaction by adding random nonce parameters to the control traffic, which the end- hosts have to sign to guarantee the freshness of the control traffic [heer-midauth]. As an alternative, extensions for transporting data plane directly over the control plane can be used [RFC6078]. 11.4. Alternative HI considerations The definition of the Host Identifier states that the HI need not be a public key. It implies that the HI could be any value; for example a FQDN. This document does not describe how to support such a non- cryptographic HI, but examples of such protocol variants do exist ([urien-rfid], [urien-rfid-draft]). A non-cryptographic HI would still offer the services of the HIT or LSI for NAT traversal. It would be possible to carry HITs in HIP packets that had neither privacy nor authentication. Such schemes may be employed for resource constrained devices, such as small sensors operating on battery power, but are not further analyzed here. If it is desirable to use HIP in a low security situation where public key computations are considered expensive, HIP can be used with very short Diffie-Hellman and Host Identity keys. Such use makes the participating hosts vulnerable to MitM and connection hijacking attacks. However, it does not cause flooding dangers, since the address check mechanism relies on the routing system and not on cryptographic strength. 11.5. Trust On First Use [RFC7435] highlights four design principles for Leap of Faith, or Trust On First Use (TOFU), protocols that apply also to opportunistic HIP: 1. Coexist with explicit policy Moskowitz & Komu Expires August 18, 2019 [Page 25] Internet-Draft Host Identity Protocol Architecture February 2019 2. Prioritize communication 3. Maximize security peer by peer 4. No misrepresentation of security According to the first TOFU design principle, "opportunistic security never displaces or preempts explicit policy". Some application data may be too sensitive, so the related policy could require authentication (i.e, the public key or certificate) in such a case instead of the unauthenticated opportunistic mode. In practice, this has been realized in HIP implementations as follows [RFC6538]. The OpenHIP implementation allowed an Initiator to use opportunistic mode only with an explicitly configured Responder IP address, when the Responder's HIT is unknown. At the Responder, OpenHIP had an option to allow opportunistic mode with any Initiator -- trust any Initiator. HIP for Linux (HIPL) developers experimented with more fine-grained policies operating at the application level. HIPL implementation utilized so called "LD_PRELOAD" hooking at the application layer that allowed a dynamically linked library to intercept socket-related calls without rebuilding the related application binaries. The library acted as a shim layer between the application and transport layers. The shim layer translated the non-HIP based socket calls from the application into HIP-based socket calls. While the shim library involved some level of complexity as described in more detail in [komu-leap], it achieved the goal of applying opportunistic mode at the granularity of individual applications. The second TOFU principle essentially states that communication should be first class citizen instead of security. So opportunistic mode should be, in general, allowed even if no authentication is present, and even possibly a fallback to non-encrypted communications could be allowed (if policy permits) instead of blocking communications. In practice, this can be realized in three steps. In the first step, a HIP Initiator can look up the HI of a Responder from a directory such as DNS. When the Initiator discovers a HI, it can use the HI for authentication and skip the rest of the following steps. In the second step, the Initiator can, upon failing to find a HI, try opportunistic mode with the Responder. In the third step, the Initiator can fall back to non-HIP based communications upon failing with opportunistic mode if the policy allows it. This three step model has been implemented successfully and described in more detail in [komu-leap]. Moskowitz & Komu Expires August 18, 2019 [Page 26] Internet-Draft Host Identity Protocol Architecture February 2019 The third TOFU principle suggests that security should be maximized, so that at least opportunistic security would be employed. The three step model described earlier prefers authentication when it is available, e.g., via DNS records (and possibly even via DNSSEC when available) and falls back to opportunistic mode when no out-of-band credentials are available. As the last resort, fallback to non-HIP based communications can be used if the policy allows it. Also, since perfect forward security (PFS) is explicitly mentioned in the third design principle, it is worth mentioning that HIP supports it. The fourth TOFU principle states that users and non-interactive applications should be properly informed about the level of security being applied. In practice, non-HIP aware applications would assume no extra security being applied, so misleading at least a non- interactive application should not be possible. In the case of interactive desktop applications, system-level prompts have been utilized in earlier HIP experiments [karvonen-usable], [RFC6538] to guide the user about the underlying HIP-based security. In general, users in those experiments perceived when HIP-based security was being used versus not used. However, the users failed to notice the difference between opportunistic and non-opportunistic HIP. The reason for this was that the opportunistic HIP (i.e. lowered level of security) was not clearly indicated in the prompt. This provided a valuable lesson to further improve the user interface. In the case of HIP-aware applications, native sockets APIs for HIP as specified in [RFC6317] can be used to develop application-specific logic instead of using generic system-level prompting. In such case, the application itself can directly prompt the user or otherwise manage the situation in other ways. In this case, also non- interactive applications can properly log the level of security being employed because the developer can now explicitly program the use of authenticated HIP, opportunistic HIP and plain-text communication. It is worth mentioning a few additional items discussed in [RFC7435]. Related to active attacks, HIP has built-in protection against cipher-suite down-grade attacks as described in detail in [RFC7401]. In addition, pre-deployed certificates could be used to mitigate against active attacks in the case of opportunistic mode as mentioned in [RFC6538]. Detection of peer capabilities is also mentioned in the TOFU context. As discussed in this section, the three-step model can be used to detect peer capabilities. A host can achieve the first step of authentication, i.e., discovery of a public key, via DNS, for instance. If the host found no keys, the host can then try opportunistic mode as the second step. Upon a timeout, the host can then proceed to the third step by falling back to non-HIP based Moskowitz & Komu Expires August 18, 2019 [Page 27] Internet-Draft Host Identity Protocol Architecture February 2019 communications if the policy permits. This last step is based on an implicit timeout rather an explicit (negative) acknowledgment like in the case of DNS, so the user may conclude prematurely that the connectivity has failed. To speed up the detection phase by explicitly detecting if the peer supports opportunistic HIP, researchers have proposed TCP specific extensions [RFC6538], [komu-leap]. In a nutshell, an Initiator sends simultaneously both an opportunistic I1 packet and the related TCP SYN datagram equipped with a special TCP option to a peer. If the peer supports HIP, it drops the SYN packet and responds with an R1. If the peer is HIP incapable, it drops the HIP packet (and the unknown TCP option) and responds with a TCP SYN-ACK. The benefit of the proposed scheme is faster, one round-trip fallback to non-HIP based communications. The drawback is that the approach is tied to TCP (IP-options were also considered, but do not work well with firewalls and NATs). Naturally, the approach does not work against active attacker, but opportunistic mode is not anyway supposed to protect against such an adversary. It is worth noting that while the use of opportunistic mode has some benefits related to incremental deployment, it does not achieve all the benefits of authenticated HIP [komu-diss]. Namely, authenticated HIP supports persistent identifiers in the sense that hosts are identified with the same HI independently of their movement. Opportunistic HIP meets this goal only partially: after the first contact between two hosts, HIP can successfully sustain connectivity with its mobility management extensions, but problems emerge when the hosts close the HIP association and try to re-establish connectivity. As hosts can change their location, it is no longer guaranteed that the same IP address belongs to the same host. The same address can be temporally assigned to different hosts, e.g., due to the reuse of IP addresses (e.g., by a DHCP service), overlapping private address realms (see also the discussion on Internet transparency in Appendix A.1) or due to an attempted attack. 12. IANA considerations This document has no actions for IANA. 13. Acknowledgments For the people historically involved in the early stages of HIP, see the Acknowledgments section in the Host Identity Protocol specification. During the later stages of this document, when the editing baton was transferred to Pekka Nikander, the comments from the early implementers and others, including Jari Arkko, Jeff AhrenHolz, Tom Moskowitz & Komu Expires August 18, 2019 [Page 28] Internet-Draft Host Identity Protocol Architecture February 2019 Henderson, Petri Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim Shepard, Jukka Ylitalo, Sasu Tarkoma, and Jorma Wall, were invaluable. Also, the comments from Lars Eggert, Spencer Dawkins, Dave Crocker and Erik Giesa were also useful. The authors want to express their special thanks to Tom Henderson, who took the burden of editing the document in response to IESG comments at the time when both of the authors were busy doing other things. Without his perseverance original document might have never made it as RFC4423. This main effort to update and move HIP forward within the IETF process owes its impetuous to a number of HIP development teams. The authors are grateful for Boeing, Helsinki Institute for Information Technology (HIIT), NomadicLab of Ericsson, and the three universities: RWTH Aachen, Aalto and University of Helsinki, for their efforts. Without their collective efforts HIP would have withered as on the IETF vine as a nice concept. Thanks also for Suvi Koskinen for her help with proofreading and with the reference jungle. 14. Changes from RFC 4423 In a nutshell, the changes from RFC 4423 [RFC4423] are mostly editorial, including clarifications on topics described in a difficult way and omitting some of the non-architectural (implementation) details that are already described in other documents. A number of missing references to the literature were also added. New topics include the drawbacks of HIP, discussion on 802.15.4 and MAC security, HIP for IoT scenarios, deployment considerations and description of the base exchange. 15. References 15.1. Normative References [I-D.ietf-hip-dex] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", draft-ietf-hip-dex-06 (work in progress), December 2017. [I-D.ietf-hip-native-nat-traversal] Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal Mode for the Host Identity Protocol", draft-ietf-hip- native-nat-traversal-28 (work in progress), March 2018. Moskowitz & Komu Expires August 18, 2019 [Page 29] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, . [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)", RFC 6079, DOI 10.17487/RFC6079, January 2011, . [RFC7086] Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", RFC 7086, DOI 10.17487/RFC7086, January 2014, . [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014, . [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, . [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 8002, DOI 10.17487/RFC8002, October 2016, . [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, . [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, . [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, . Moskowitz & Komu Expires August 18, 2019 [Page 30] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, . [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Multihoming with the Host Identity Protocol", RFC 8047, DOI 10.17487/RFC8047, February 2017, . 15.2. Informative references [amir-hip] Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G. Pulkkis, "Security and Trust of Public Key Cryptography for HIP and HIP Multicast", International Journal of Dependable and Trustworthy Information Systems (IJDTIS), 2(3), 17-35, DOI: 10.4018/jdtis.2011070102, 2013. [aura-dos] Aura, T., Nikander, P., and J. Leiwo, "DOS-resistant Authentication with Client Puzzles", 8th International Workshop on Security Protocols, pages 170-177. Springer, , April 2001. [beal-dos] Beal, J. and T. Shephard, "Deamplification of DoS Attacks via Puzzles", , October 2004. [camarillo-p2psip] Camarillo, G., Maeenpaeae, J., Keraenen, A., and V. Anderson, "Reducing delays related to NAT traversal in P2PSIP session establishments", IEEE Consumer Communications and Networking Conference (CCNC), pp. 549-553 DOI: 10.1109/CCNC.2011.5766540, 2011. [chiappa-endpoints] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [heer-end-host] Heer, T., Hummen, R., Komu, M., Goetz, S., and K. Wehre, "End-host Authentication and Authorization for Middleboxes based on a Cryptographic Namespace", ICC2009 Communication and Information Systems Security Symposium, , 2009. Moskowitz & Komu Expires August 18, 2019 [Page 31] Internet-Draft Host Identity Protocol Architecture February 2019 [heer-midauth] Heer, T. and M. Komu, "End-Host Authentication for HIP Middleboxes", Working draft draft-heer-hip-middle-auth-02, September 2009. [henderson-vpls] Henderson, T. and D. Mattes, "HIP-based Virtual Private LAN Service (HIPLS)", Working draft draft-henderson-hip- vpls-07, Dec 2013. [hip-lte] Liyanage, M., Kumar, P., Ylianttila, M., and A. Gurtov, "Novel secure VPN architectures for LTE backhaul networks", Security and Communication Networks DOI 10.1002/sec.1411, November 2015. [hip-srtp] Tschofenig, H., Muenz, F., and M. Shanmugam, "Using SRTP transport format with HIP", Working draft draft- tschofenig-hiprg-hip-srtp-01, October 2005. [hummen] Hummen, R., Hiller, J., Henze, M., and K. Wehrle, "Slimfit - A HIP DEX Compression Layer for the IP-based Internet of Things", Wireless and Mobile Computing, Networking and Communications (WiMob), 2013 IEEE 9th International Conference on , page 259-266. DOI: 10.1109/WiMOB.2013.6673370, October 2013. [IEEE.802-15-4.2011] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.4, September 2011, . [IEEE.802-15-9] "IEEE Draft Recommended Practice for Transort of Key Management Protocol (KMP) Datagrams", IEEE P802.15.9/D04, May 2015. [karvonen-usable] Karvonen, K., Komu, M., and A. Gurtov, "Usable Security Management with Host Identity Protocol", 7th ACS/IEEE International Conference on Computer Systems and Applications, (AICCSA-2009), 2009. Moskowitz & Komu Expires August 18, 2019 [Page 32] Internet-Draft Host Identity Protocol Architecture February 2019 [komu-cloud] Komu, M., Sethi, M., Mallavarapu, R., Oirola, H., Khan, R., and S. Tarkoma, "Secure Networking for Virtual Machines in the Cloud", International Workshop on Power and QoS Aware Computing (PQoSCom2012), IEEE, ISBN: 978-1-4244-8567-3, September 2012. [komu-diss] Komu, M., "A Consolidated Namespace for Network Applications, Developers, Administrators and Users", Dissertation, Aalto University, Espoo, Finland ISBN: 978-952-60-4904-5 (printed), ISBN: 978-952-60-4905-2 (electronic). , December 2012. [komu-leap] Komu, M. and J. Lindqvist, "Leap-of-Faith Security is Enough for IP Mobility", 6th Annual IEEE Consumer Communications and Networking Conference IEEE CCNC 2009, Las Vegas, Nevada, , January 2009. [komu-mitigation] Komu, M., Tarkoma, S., and A. Lukyanenko, "Mitigation of Unsolicited Traffic Across Domains with Host Identities and Puzzles", 15th Nordic Conference on Secure IT Systems (NordSec 2010), Springer Lecture Notes in Computer Science, Volume 7127, pp. 33-48, ISBN: 978-3-642-27936-2, October 2010. [kovacshazi-host] Kovacshazi, Z. and R. Vida, "Host Identity Specific Multicast", International conference on Networking and Services (ICNS'06), IEEE Computer Society, Los Alamitos, CA, USA, http://doi.ieeecomputersociety.org/10.1109/ ICNS.2007.66, 2007. [leva-barriers] Levae, A., Komu, M., and S. Luukkainen, "Adoption Barriers of Network-layer Protocols: the Case of Host Identity Protocol", The International Journal of Computer and Telecommunications Networking, ISSN: 1389-1286, March 2013. [lindqvist-enterprise] Lindqvist, J., Vehmersalo, E., Manner, J., and M. Komu, "Enterprise Network Packet Filtering for Mobile Cryptographic Identities", International Journal of Handheld Computing Research, 1 (1), 79-94, , January-March 2010. Moskowitz & Komu Expires August 18, 2019 [Page 33] Internet-Draft Host Identity Protocol Architecture February 2019 [Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", in Proceesings of Security Protocols, 9th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pp. 12-26, Springer, 2002. [nsrg-report] Lear, E. and R. Droms, "What's In A Name:Thoughts from the NSRG", draft-irtf-nsrg-report-10 (work in progress), September 2003. [paine-hip] Paine, R., "Beyond HIP: The End to Hacking As We Know It", BookSurge Publishing, ISBN: 1439256047, 9781439256046, 2009. [pham-leap] Pham, V. and T. Aura, "Security Analysis of Leap-of-Faith Protocols", Seventh ICST International Conference on Security and Privacy for Communication Networks, , September 2011. [ranjbar-synaptic] Ranjbar, A., Komu, M., Salmela, P., and T. Aura, "SynAPTIC: Secure and Persistent Connectivity for Containers", 2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), Madrid, 2017, pp. 262-267 doi: 10.1109/CCGRID.2017.62, 2017. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, . [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, DOI 10.17487/RFC2766, February 2000, . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . Moskowitz & Komu Expires August 18, 2019 [Page 34] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, DOI 10.17487/RFC3102, October 2001, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [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, . [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, . [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, . [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 2006, . [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, . [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, DOI 10.17487/RFC5338, September 2008, . [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May 2010, . Moskowitz & Komu Expires August 18, 2019 [Page 35] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, January 2011, . [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 10.17487/RFC6250, May 2011, . [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, DOI 10.17487/RFC6281, June 2011, . [RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, DOI 10.17487/RFC6317, July 2011, . [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 2012, . [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, March 2012, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . [sarela-bloom] Saerelae, M., Esteve Rothenberg, C., Zahemszky, A., Nikander, P., and J. Ott, "BloomCasting: Security in Bloom filter based multicast", , Lecture Notes in Computer Science 2012, , pages 1-16, Springer Berlin Heidelberg, 2012. [schuetz-intermittent] Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol enhancements for intermittently connected hosts", SIGCOMM Comput. Commun. Rev., 35(3):5-18, , July 2005. Moskowitz & Komu Expires August 18, 2019 [Page 36] Internet-Draft Host Identity Protocol Architecture February 2019 [shields-hip] Shields, C. and J. Garcia-Luna-Aceves, "The HIP protocol for hierarchical multicast routing", Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing, pages 257-266. ACM, New York, NY, USA, ISBN: 0-89791-977-7, DOI: 10.1145/277697.277744, 1998. [tempered-networks] "Identity-Defined Network (IDN) Architecture: Unified, Secure Networking Made Simple", White Paper , 2016. [tritilanunt-dos] Tritilanunt, S., Boyd, C., Foo, E., and J. Nieto, "Examining the DoS Resistance of HIP", OTM Workshops (1), volume 4277 of Lecture Notes in Computer Science, pages 616-625,Springer , 2006. [urien-rfid] Urien, P., Chabanne, H., Bouet, M., de Cunha, D., Guyot, V., Pujolle, G., Paradinas, P., Gressier, E., and J. Susini, "HIP-based RFID Networking Architecture", IFIP International Conference on Wireless and Optical Communications Networks, DOI: 10.1109/WOCN.2007.4284140, July 2007. [urien-rfid-draft] Urien, P., Lee, G., and G. Pujolle, "HIP support for RFIDs", IRTF Working draft draft-irtf-hiprg-rfid-07, April 2013. [varjonen-split] Varjonen, S., Komu, M., and A. Gurtov, "Secure and Efficient IPv4/IPv6 Handovers Using Host-Based Identifier- Location Split", Journal of Communications Software and Systems, 6(1), 2010, ISSN: 18456421, 2010. [xin-hip-lib] Xin, G., "Host Identity Protocol Version 2.5", Master's Thesis, Aalto University, Espoo, Finland, , June 2012. [xueyong-hip] Xueyong, Z., Zhiguo, D., and W. Xinling, "A Multicast Routing Algorithm Applied to HIP-Multicast Model", Proceedings of the 2011 International Conference on Network Computing and Information Security - Volume 01 (NCIS '11), Vol. 1. IEEE Computer Society, Washington, DC, USA, pages 169-174, DOI: 10.1109/NCIS.2011.42, 2011. Moskowitz & Komu Expires August 18, 2019 [Page 37] Internet-Draft Host Identity Protocol Architecture February 2019 [xueyong-secure] Xueyong, Z. and J. Atwood, "A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol", Consumer Communications and Networking Conference. CCNC 2007. 4th IEEE, pages 1098,1102, DOI: 10.1109/CCNC.2007.221, January 2007. [ylitalo-diss] Ylitalo, J., "Secure Mobility at Multiple Granularity Levels over Heterogeneous Datacom Networks", Dissertation, Helsinki University of Technology, Espoo, Finland ISBN 978-951-22-9531-9, 2008. [ylitalo-spinat] Ylitalo, J., Salmela, P., and H. Tschofenig, "SPINAT: Integrating IPsec into overlay routing", Proceedings of the First International Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2005). Athens, Greece. IEEE Computer Society, pages 315-326, ISBN: 0-7695-2369-2, September 2005. [zhang-revocation] Zhang, D., Kuptsov, D., and S. Shen, "Host Identifier Revocation in HIP", IRTF Working draft draft-irtf-hiprg- revocation-05, Mar 2012. Appendix A. Design considerations A.1. Benefits of HIP In the beginning, the network layer protocol (i.e., IP) had the following four "classic" invariants: 1. Non-mutable: The address sent is the address received. 2. Non-mobile: The address doesn't change during the course of an "association". 3. Reversible: A return header can always be formed by reversing the source and destination addresses. 4. Omniscient: Each host knows what address a partner host can use to send packets to it. Actually, the fourth can be inferred from 1 and 3, but it is worth mentioning explicitly for reasons that will be obvious soon if not already. Moskowitz & Komu Expires August 18, 2019 [Page 38] Internet-Draft Host Identity Protocol Architecture February 2019 In the current "post-classic" world, we are intentionally trying to get rid of the second invariant (both for mobility and for multi- homing), and we have been forced to give up the first and the fourth. Realm Specific IP [RFC3102] is an attempt to reinstate the fourth invariant without the first invariant. IPv6 is attempts to reinstate the first invariant. Few client-side systems on the Internet have DNS names that are meaningful. That is, if they have a Fully Qualified Domain Name (FQDN), that name typically belongs to a NAT device or a dial-up server, and does not really identify the system itself but its current connectivity. FQDNs (and their extensions as email names) are application-layer names; more frequently naming services than particular systems. This is why many systems on the Internet are not registered in the DNS; they do not have services of interest to other Internet hosts. DNS names are references to IP addresses. This only demonstrates the interrelationship of the networking and application layers. DNS, as the Internet's only deployed and distributed database, is also the repository of other namespaces, due in part to DNSSEC and application specific key records. Although each namespace can be stretched (IP with v6, DNS with KEY records), neither can adequately provide for host authentication or act as a separation between internetworking and transport layers. The Host Identity (HI) namespace fills an important gap between the IP and DNS namespaces. An interesting thing about the HI is that it actually allows a host to give up all but the 3rd network-layer invariant. That is to say, as long as the source and destination addresses in the network-layer protocol are reversible, HIP takes care of host identification, and reversibility allows a local host to receive a packet back from a remote host. The address changes occurring during NAT transit (non-mutable) or host movement (non- omniscient or non-mobile) can be managed by the HIP layer. With the exception of High-Performance Computing applications, the Sockets API is the most common way to develop network applications. Applications use the Sockets API either directly or indirectly through some libraries or frameworks. However, the Sockets API is based on the assumption of static IP addresses, and DNS with its lifetime values was invented at later stages during the evolution of the Internet. Hence, the Sockets API does not deal with the lifetime of addresses [RFC6250]. As the majority of the end-user equipment is mobile today, their addresses are effectively ephemeral, but the Sockets API still gives a fallacious illusion of persistent IP addresses to the unwary developer. HIP can be used to solidify this Moskowitz & Komu Expires August 18, 2019 [Page 39] Internet-Draft Host Identity Protocol Architecture February 2019 illusion because HIP provides persistent surrogate addresses to the application layer in the form of LSIs and HITs. The persistent identifiers as provided by HIP are useful in multiple scenarios (see, e.g., [ylitalo-diss] or [komu-diss], for a more elaborate discussion): o When a mobile host moves physically between two different WLAN networks and obtains a new address, an application using the identifiers remains isolated regardless of the topology changes while the underlying HIP layer re-establishes connectivity (i.e. a horizontal handoff). o Similarly, the application utilizing the identifiers remains again unaware of the topological changes when the underlying host equipped with WLAN and cellular network interfaces switches between the two different access technologies (i.e. a vertical handoff). o Even when hosts are located in private address realms, applications can uniquely distinguish different hosts from each other based on their identifiers. In other words, it can be stated that HIP improves Internet transparency for the application layer [komu-diss]. o Site renumbering events for services can occur due to corporate mergers or acquisitions, or by changes in Internet Service Provider. They can involve changing the entire network prefix of an organization, which is problematic due to hard-coded addresses in service configuration files or cached IP addresses at the client side [RFC5887]. Considering such human errors, a site employing location-independent identifiers as promoted by HIP may experience fewer problems while renumbering their network. o More agile IPv6 interoperability can be achieved, as discussed in Section 4.4. IPv6-based applications can communicate using HITs with IPv4-based applications that are using LSIs. Additionally, the underlying network type (IPv4 or IPv6) becomes independent of the addressing family of the application. o HITs (or LSIs) can be used in IP-based access control lists as a more secure replacement for IPv6 addresses. Besides security, HIT based access control has two other benefits. First, the use of HITs can potentially halve the size of access control lists because separate rules for IPv4 are not needed [komu-diss]. Second, HIT-based configuration rules in HIP-aware middleboxes remain static and independent of topology changes, thus simplifying administrative efforts particularly for mobile Moskowitz & Komu Expires August 18, 2019 [Page 40] Internet-Draft Host Identity Protocol Architecture February 2019 environments. For instance, the benefits of HIT-based access control have been harnessed in the case of HIP-aware firewalls, but can be utilized directly at the end-hosts as well [RFC6538]. While some of these benefits could be and have been redundantly implemented by individual applications, providing such generic functionality at the lower layers is useful because it reduces software development effort and networking software bugs (as the layer is tested with multiple applications). It also allows the developer to focus on building the application itself rather than delving into the intricacies of mobile networking, thus facilitating separation of concerns. HIP could also be realized by combining a number of different protocols, but the complexity of the resulting software may become substantially larger, and the interaction between multiple possibly layered protocols may have adverse effects on latency and throughput. It is also worth noting that virtually nothing prevents realizing the HIP architecture, for instance, as an application-layer library, which has been actually implemented in the past [xin-hip-lib]. However, the tradeoff in moving the HIP layer to the application layer is that legacy applications may not be supported. A.2. Drawbacks of HIP In computer science, many problems can be solved with an extra layer of indirection. However, the indirection always involves some costs as there is no such a thing as "free lunch". In the case of HIP, the main costs could be stated as follows: o In general, an additional layer and a namespace always involve some initial effort in terms of implementation, deployment and maintenance. Some education of developers and administrators may also be needed. However, the HIP community at the IETF has spent years in experimenting, exploring, testing, documenting and implementing HIP to ease the adoption costs. o HIP introduces a need to manage HIs and requires a centralized approach to manage HIP-aware endpoints at scale. What were formerly IP address-based ACLs are now trusted HITs, and the HIT to IP address mappings as well as access policies must be managed. HIP-aware endpoints must also be able to operate autonomously to ensure mobility and availability (an endpoint must be able to run without having to have a persistent management connection). The users who want this better security and mobility of HIs instead of IP address based ACLs have to then manage this additional 'identity layer' in a non-persistent fashion. As exemplified in Appendix A.3.5, these challenges have been already solved in an Moskowitz & Komu Expires August 18, 2019 [Page 41] Internet-Draft Host Identity Protocol Architecture February 2019 infrastructure setting to distribute policy and manage the mappings and trust relationships between HIP-aware endpoints. o HIP decouples identifier and locator roles of IP addresses. Consequently, a mapping mechanism is needed to associate them together. A failure to map a HIT to its corresponding locator may result in failed connectivity because a HIT is "flat" by its nature and cannot be looked up from the hierarchically organized DNS. HITs are flat by design due to a security tradeoff. The more bits are allocated for the hash in the HIT, the less likely there will be (malicious) collisions. o From performance viewpoint, HIP control and data plane processing introduces some overhead in terms of throughput and latency as elaborated below. Related to deployment drawbacks, firewalls are commonly used to control access to various services and devices in the current Internet. Since HIP introduces an additional namespace, it is expected that also the HIP namespace would be filtered for unwanted connectivity. While this can be achieved with existing tools directly in the end-hosts, filtering at the middleboxes requires modifications to existing firewall software or additional middleboxes [RFC6538]. The key exchange introduces some extra latency (two round trips) in the initial transport-layer connection establishment between two hosts. With TCP, additional delay occurs if the underlying network stack implementation drops the triggering SYN packet during the key exchange. The same cost may also occur during HIP handoff procedures. However, subsequent TCP sessions using the same HIP association will not bear this cost (within the key lifetime). Both the key exchange and handoff penalties can be minimized by caching TCP packets. The latter case can further be optimized with TCP user timeout extensions [RFC5482] as described in further detail by Schuetz et al [schuetz-intermittent]. The most CPU-intensive operations involve the use of the asymmetric keys and Diffie-Hellman key derivation at the control plane, but this occurs only during the key exchange, its maintenance (handoffs, refreshing of key material) and tear-down procedures of HIP associations. The data plane is typically implemented with ESP because it has a smaller overhead due to symmetric key encryption. Naturally, even ESP involves some overhead in terms of latency (processing costs) and throughput (tunneling) (see, e.g., [ylitalo-diss] for a performance evaluation). Moskowitz & Komu Expires August 18, 2019 [Page 42] Internet-Draft Host Identity Protocol Architecture February 2019 A.3. Deployment and adoption considerations This section describes some deployment and adoption considerations related to HIP from a technical perspective. A.3.1. Deployment analysis HIP has been adapted and deployed in an industrial control network in a production factory, in which HIP's strong network layer identity supports the secure coexistence of the control network with many untrusted network devices operated by third-party vendors [paine-hip]. Similarly, HIP has also been included in a security product to support layer-two Virtual Private Networks [henderson-vpls] to enable security zones in a supervisory control and data acquisition (SCADA) network. However, HIP has not been a "wild success" [RFC5218] in the Internet as argued by Levae et al [leva-barriers]. Here, we briefly highlight some of their findings based on interviews with 19 experts from the industry and academia. From a marketing perspective, the demand for HIP has been low and substitute technologies have been favored. Another identified reason has been that some technical misconceptions related to the early stages of HIP specifications still persist. Two identified misconceptions are that HIP does not support NAT traversal, and that HIP must be implemented in the OS kernel. Both of these claims are untrue; HIP does have NAT traversal extensions [I-D.ietf-hip-native-nat-traversal], and kernel modifications can be avoided with modern operating systems by diverting packets for userspace processing. The analysis by Levae et al clarifies infrastructural requirements for HIP. In a minimal set up, a client and server machine have to run HIP software. However, to avoid manual configurations, usually DNS records for HIP are set up. For instance, the popular DNS server software Bind9 does not require any changes to accommodate DNS records for HIP because they can be supported in binary format in its configuration files [RFC6538]. HIP rendezvous servers and firewalls are optional. No changes are required to network address points, NATs, edge routers or core networks. HIP may require holes in legacy firewalls. The analysis also clarifies the requirements for the host components that consist of three parts. First, a HIP control plane component is required, typically implemented as a userspace daemon. Second, a data plane component is needed. Most HIP implementations utilize the so called BEET mode of ESP that has been available since Linux kernel 2.6.27, but the BEET mode is also included as a userspace component in a few of the implementations. Third, HIP systems usually provide Moskowitz & Komu Expires August 18, 2019 [Page 43] Internet-Draft Host Identity Protocol Architecture February 2019 a DNS proxy for the local host that translates HIP DNS records to LSIs and HITs, and communicates the corresponding locators to HIP userspace daemon. While the third component is not mandatory, it is very useful for avoiding manual configurations. The three components are further described in the HIP experiment report [RFC6538]. Based on the interviews, Levae et al suggest further directions to facilitate HIP deployment. Transitioning a number of HIP specifications to the standards track in IETF has already taken place, but the authors suggest other additional measures based on the interviews. As a more radical measure, the authors suggest to implement HIP as a purely application-layer library [xin-hip-lib] or other kind of middleware. On the other hand, more conservative measures include focusing on private deployments controlled by a single stakeholder. As a more concrete example of such a scenario, HIP could be used by a single service provider to facilitate secure connectivity between its servers [komu-cloud]. A.3.2. HIP in 802.15.4 networks The IEEE 802 standards have been defining MAC layered security. Many of these standards use EAP [RFC3748] as a Key Management System (KMS) transport, but some like IEEE 802.15.4 [IEEE.802-15-4.2011] leave the KMS and its transport as "Out of Scope". HIP is well suited as a KMS in these environments: o HIP is independent of IP addressing and can be directly transported over any network protocol. o Master Keys in 802 protocols are commonly pair-based with group keys transported from the group controller using pair-wise keys. o AdHoc 802 networks can be better served by a peer-to-peer KMS than the EAP client/server model. o Some devices are very memory constrained and a common KMS for both MAC and IP security represents a considerable code savings. A.3.3. HIP and Internet of Things HIP requires certain amount computational resources from a device due to cryptographic processing. HIP scales down to phones and small system-on-chip devices (such as Raspberry Pis, Intel Edison), but small sensors operating with small batteries have remained problematic. Different extensions to the HIP have been developed to scale HIP down to smaller devices, typically with different security tradeoffs. For example, the non-cryptographic identifiers have been Moskowitz & Komu Expires August 18, 2019 [Page 44] Internet-Draft Host Identity Protocol Architecture February 2019 proposed in RFID scenarios. The slimfit approach [hummen] proposes a compression layer for HIP to make it more suitable for constrained networks. The approach is applied to a light-weight version of HIP (i.e. "Diet HIP") in order to scale down to small sensors. The HIP Diet Exchange [I-D.ietf-hip-dex] design aims at reducing the overhead of the employed cryptographic primitives by omitting public- key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to the Base Exchange (BEX). DEX is primarily designed for computation or memory- constrained sensor/actuator devices. Like BEX, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.9 networks ([IEEE.802-15-9]. The main differences between HIP BEX and DEX are: 1. Minimum collection of cryptographic primitives to reduce the protocol overhead. * Static Elliptic Curve Diffie-Hellman key pairs for peer authentication and encryption of the session key. * AES-CTR for symmetric encryption and AES-CMAC for MACing function. * A simple fold function for HIT generation. 2. Forfeit of Perfect Forward Secrecy with the dropping of an ephemeral Diffie-Hellman key agreement. 3. Forfeit of digital signatures with the removal of a hash function. Reliance on ECDH derived key used in HIP_MAC to prove ownership of the private key. 4. Diffie-Hellman derived key ONLY used to protect the HIP packets. A separate secret exchange within the HIP packets creates the session key(s). 5. Optional retransmission strategy tailored to handle the potentially extensive processing time of the employed cryptographic operations on computationally constrained devices. Moskowitz & Komu Expires August 18, 2019 [Page 45] Internet-Draft Host Identity Protocol Architecture February 2019 A.3.4. Infrastructure Applications HIP experimentation report [RFC6538] enumerates a number of client and server applications that have been trialed with HIP. Based on the report, this section highlights and complements some potential ways how HIP could be exploited in existing infrastructure such as routers, gateways and proxies. HIP has been successfully used with forward web proxies (i.e., client-side proxies). HIP was used between a client host (web browser) and a forward proxy (Apache server) that terminated the HIP/ ESP-tunnel. The forward web proxy translated HIP-based traffic originating from the client into non-HIP traffic towards any web server in the Internet. Consequently, the HIP-capable client could communicate with HIP-incapable web servers. This way, the client could utilize mobility support as provided by HIP while using the fixed IP address of the web proxy, for instance, to access services that were allowed only from the IP address range of the proxy. HIP has also been experimented with reverse web proxies (i.e. server- side proxies) as described in more detail in [komu-cloud]. In this scenario, a HIP-incapable client accessed a HIP-capable web service via an intermediary load balancer (that was a web based load balancer implementation called HAProxy). The load balancer translated non-HIP traffic originating from the client into HIP-based traffic for the web service (consisting of front-end and back-end servers). Both the load balancer and the web service were located in a datacenter. One of the key benefits for encrypting the web traffic with HIP in this scenario was to support a private-public cloud scenario (i.e. hybrid cloud) where the load balancer, front-end servers and back-end servers can be located in different datacenters and, thus, the traffic needs to protected when it passes through potentially insecure networks between the borders of the private and public clouds. While HIP could be used to secure access to intermediary devices (e.g., access to switches with legacy telnet), it has also been used to secure intermittent connectivity between middlebox infrastructure. For instance, earlier research [komu-mitigation] utilized HIP between Secure Mail Transport Protocol (SMTP) servers in order to exploit the computational puzzles of HIP as a spam mitigation mechanism. A rather obvious practical challenge in this approach was the lack of HIP adoption on existing SMTP servers. To avoid deployment hurdles with existing infrastructure, HIP could be applied in the context of new protocols with little deployment. Namely, HIP has been experimented in the context of a new protocol, peer-to-peer SIP [camarillo-p2psip]. The work has resulted in a Moskowitz & Komu Expires August 18, 2019 [Page 46] Internet-Draft Host Identity Protocol Architecture February 2019 number of related RFCs [RFC6078], [RFC6079], [RFC7086]. The key idea in the research work was to avoid redundant, time consuming ICE procedures by grouping different connections (i.e. SIP and media streams) together using the low-layer HIP which executes NAT traversal procedures only once per host. An interesting aspect in the approach was the use of P2P-SIP infrastructure as rendezvous servers for HIP control plane instead of utilizing the traditional HIP rendezvous services [RFC8004]. Researchers have proposed to use HIP in cellular networks as a mobility, multihoming and security solution. [hip-lte] provides a security analysis and simulation measurements of using HIP in Long Term Evolution (LTE) backhaul networks. HIP has been experimented with securing cloud internal connectivity. First with virtual machines [komu-cloud] and then later also between Linux containers [ranjbar-synaptic]. In both cases, HIP was suggested as a solution NAT traversal that could be utilized both internally by a cloud network and between multi-cloud deployments. Specifically in the former case, HIP was beneficial sustaining connectivity with a virtual machine while it migrates to a new location. In the latter case, Software-Defined Networking (SDN) controller acted as rendezvous server for HIP-capable containers. The controller enforced strong replay protection by adding middlebox nonces [heer-end-host] to the passing HIP base exchange and UPDATE messages. A.3.5. Management of Identities in a Commercial Product Tempered Networks provides HIP-based products. They refer to their platform as Identity-Defined Networking (IDN) [tempered-networks] because of HIP's identity-first networking architecture. Their objective has been to make it simple and non-disruptive to deploy HIP enabled services widely in production environments with the purpose of enabling transparent device authentication and authorization, cloaking, segmentation, and end-to-end networking. The goal is to eliminate much of the circular dependencies, exploits, and layered complexity of traditional "address-defined networking" that prevents mobility and verifiable device access control. The products in the portfolio of Tempered Networks utilize HIP as follows: o HIP Switches / Gateways - these are physical or virtual appliances that serve as the HIP gateway and policy enforcement point for non HIP-aware applications and devices located behind it. No IP or infrastructure changes are required in order to connect, cloak, and protect the non-HIP aware devices. Currently known supported platforms for HIP gateways are: x86 and ARM chipsets, ESXi, Hyper- V, KVM, AWS, Azure, and Google clouds. Moskowitz & Komu Expires August 18, 2019 [Page 47] Internet-Draft Host Identity Protocol Architecture February 2019 o HIP Relays / Rendezvous - are physical or virtual appliances that serve as identity based routers authorizing and bridging HIP endpoints without decrypting the HIP session. A HIP Relay can be deployed as a standalone appliance or in a cluster for horizontal scaling. All HIP aware endpoints and the devices they're connecting and protecting can remain privately addressed, The appliances eliminate IP conflicts, tunnel through NAT and CGNAT, and require no changes to the underlay infrastructure. The only requirement is that a HIP endpoint should have outbound access to the Internet and that a HIP Relay should have a public address. o HIP-Aware Clients and Servers - software that installs in the host's network stack and enforces policy for that host. HIP clients support split tunneling. Both HIP client and HIP server can interface with the local host firewall and HIP Server can be locked down to listen only on the port used for HIP, making the server invisible from unauthorized devices. Currently known supported platforms are Windows, OSX, iOS, Android, Ubuntu, CentOS and other Linux derivatives. o Policy Orchestration Managers - a physical or virtual appliance that serves as the engine to define and distribute network and security policy (HI and IP mappings, overlay networks and whitelist policies etc.) to HIP-aware endpoints. Orchestration does not need to persist to the HIP endpoints and vice versa allowing for autonomous host networking and security. A.4. Answers to NSRG questions The IRTF Name Space Research Group has posed a number of evaluating questions in their report [nsrg-report]. In this section, we provide answers to these questions. 1. How would a stack name improve the overall functionality of the Internet? HIP decouples the internetworking layer from the transport layer, allowing each to evolve separately. The decoupling makes end-host mobility and multi-homing easier, also across IPv4 and IPv6 networks. HIs make network renumbering easier, and they also make process migration and clustered servers easier to implement. Furthermore, being cryptographic in nature, they provide the basis for solving the security problems related to end-host mobility and multi-homing. 2. What does a stack name look like? Moskowitz & Komu Expires August 18, 2019 [Page 48] Internet-Draft Host Identity Protocol Architecture February 2019 A HI is a cryptographic public key. However, instead of using the keys directly, most protocols use a fixed-size hash of the public key. 3. What is its lifetime? HIP provides both stable and temporary Host Identifiers. Stable HIs are typically long-lived, with a lifetime of years or more. The lifetime of temporary HIs depends on how long the upper-layer connections and applications need them, and can range from a few seconds to years. 4. Where does it live in the stack? The HIs live between the transport and internetworking layers. 5. How is it used on the end points? The Host Identifiers may be used directly or indirectly (in the form of HITs or LSIs) by applications when they access network services. Additionally, the Host Identifiers, as public keys, are used in the built-in key agreement protocol, called the HIP base exchange, to authenticate the hosts to each other. 6. What administrative infrastructure is needed to support it? In some environments, it is possible to use HIP opportunistically, without any infrastructure. However, to gain full benefit from HIP, the HIs must be stored in the DNS or a PKI, and the rendezvous mechanism is needed [RFC8005]. 7. If we add an additional layer would it make the address list in SCTP unnecessary? Yes 8. What additional security benefits would a new naming scheme offer? HIP reduces dependency on IP addresses, making the so-called address ownership [Nik2001] problems easier to solve. In practice, HIP provides security for end-host mobility and multi-homing. Furthermore, since HIP Host Identifiers are public keys, standard public key certificate infrastructures can be applied on the top of HIP. Moskowitz & Komu Expires August 18, 2019 [Page 49] Internet-Draft Host Identity Protocol Architecture February 2019 9. What would the resolution mechanisms be, or what characteristics of a resolution mechanisms would be required? For most purposes, an approach where DNS names are resolved simultaneously to HIs and IP addresses is sufficient. However, if it becomes necessary to resolve HIs into IP addresses or back to DNS names, a flat resolution infrastructure is needed. Such an infrastructure could be based on the ideas of Distributed Hash Tables, but would require significant new development and deployment. Authors' Addresses Robert Moskowitz (editor) HTT Consulting Oak Park Michigan USA Email: rgm@labs.htt-consult.com Miika Komu Ericsson Hirsalantie 11 02420 Jorvas Finland Email: miika.komu@ericsson.com Moskowitz & Komu Expires August 18, 2019 [Page 50] ./draft-ietf-anima-reference-model-10.txt0000644000764400076440000021503613375730226017507 0ustar iustyiusty ANIMA M. Behringer, Ed. Internet-Draft Intended status: Informational B. Carpenter Expires: May 27, 2019 Univ. of Auckland T. Eckert Futurewei Technologies Inc. L. Ciavaglia Nokia J. Nobre University of Vale do Rio dos Sinos November 23, 2018 A Reference Model for Autonomic Networking draft-ietf-anima-reference-model-10 Abstract This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. 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, 2019. Copyright Notice Copyright (c) 2018 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 Behringer, et al. Expires May 27, 2019 [Page 1] Internet-Draft AN Reference Model November 2018 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. The Network View . . . . . . . . . . . . . . . . . . . . . . 4 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 5 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The Adjacency Table . . . . . . . . . . . . . . . . . . . 6 3.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. State 1: Factory Default . . . . . . . . . . . . . . 8 3.3.2. State 2: Enrolled . . . . . . . . . . . . . . . . . . 9 3.3.3. State 3: In ACP . . . . . . . . . . . . . . . . . . . 9 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 10 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 12 4.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. The Autonomic Control Plane . . . . . . . . . . . . . . . 13 4.7. Information Distribution (*) . . . . . . . . . . . . . . 13 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 14 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 14 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 14 5.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 15 5.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 15 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 15 6.1. General Description of an ASA . . . . . . . . . . . . . . 15 6.2. ASA Life-Cycle Management . . . . . . . . . . . . . . . . 17 6.3. Specific ASAs for the Autonomic Network Infrastructure . 18 6.3.1. The enrollment ASAs . . . . . . . . . . . . . . . . . 18 6.3.2. The ACP ASA . . . . . . . . . . . . . . . . . . . . . 19 6.3.3. The Information Distribution ASA (*) . . . . . . . . 19 7. Management and Programmability . . . . . . . . . . . . . . . 19 7.1. Managing a (Partially) Autonomic Network . . . . . . . . 19 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 21 7.4. Feedback Loops to NOC (*) . . . . . . . . . . . . . . . . 21 7.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 22 7.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 22 7.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 23 8. Coordination Between Autonomic Functions (*) . . . . . . . . 24 Behringer, et al. Expires May 27, 2019 [Page 2] Internet-Draft AN Reference Model November 2018 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 24 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9.1. Protection Against Outsider Attacks . . . . . . . . . . . 26 9.2. Risk of Insider Attacks . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction The document "Autonomic Networking - Definitions and Design Goals" [RFC7575] explains the fundamental concepts behind Autonomic Networking, and defines the relevant terms in this space, as well as a high level reference model. [RFC7576] provides a gap analysis between traditional and autonomic approaches. This document defines this reference model with more detail, to allow for functional and protocol specifications to be developed in an architecturally consistent, non-overlapping manner. As discussed in [RFC7575], the goal of this work is not to focus exclusively on fully autonomic nodes or networks. In reality, most networks will run with some autonomic functions, while the rest of the network is traditionally managed. This reference model allows for this hybrid approach. For example, it is possible in an existing, non-autonomic network to enrol devices in a traditional way, to bring up a trust infrastructure with certificates. This trust infrastructure could then be used to automatically bring up an Autonomic Control Plane (ACP), and run traditional network operations over the secure and self-healing ACP. See [I-D.ietf-anima-stable-connectivity] for a description of this use case. The scope of this model is therefore limited to networks that are to some extent managed by skilled human operators, loosely referred to as "professionally managed" networks. Unmanaged networks raise additional security and trust issues that this model does not cover. This document describes a first, simple, implementable phase of an Autonomic Networking solution. It is expected that the experience from this phase will be used in defining updated and extended specifications over time. Some topics are considered architecturally Behringer, et al. Expires May 27, 2019 [Page 3] Internet-Draft AN Reference Model November 2018 in this document, but are not yet reflected in the implementation specifications. They are marked with an (*). 2. The Network View This section describes the various elements in a network with autonomic functions, and how these entities work together, on a high level. Subsequent sections explain the detailed inside view for each of the autonomic network elements, as well as the network functions (or interfaces) between those elements. Figure 1 shows the high level view of an Autonomic Network. It consists of a number of autonomic nodes, which interact directly with each other. Those autonomic nodes provide a common set of capabilities across the network, called the "Autonomic Networking Infrastructure" (ANI). The ANI provides functions like naming, addressing, negotiation, synchronization, discovery and messaging. Autonomic functions typically span several, possibly all nodes in the network. The atomic entities of an autonomic function are called the "Autonomic Service Agents" (ASA), which are instantiated on nodes. +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + : : Autonomic Function 1 : : : ASA 1 : ASA 1 : ASA 1 : ASA 1 : +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + : : : : +- - - - - - - - - - - - - - + : : : Autonomic Function 2 : : : : ASA 2 : ASA 2 : : : +- - - - - - - - - - - - - - + : : : : +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + : Autonomic Networking Infrastructure : +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +--------+ : +--------+ : +--------+ : +--------+ | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | +--------+ : +--------+ : +--------+ : +--------+ Figure 1: High level view of an Autonomic Network In a horizontal view, autonomic functions span across the network, as well as the Autonomic Networking Infrastructure. In a vertical view, a node always implements the ANI, plus it may have one or several Autonomic Service Agents. ASAs may be standalone, or use other ASAs in a hierarchical way. Behringer, et al. Expires May 27, 2019 [Page 4] Internet-Draft AN Reference Model November 2018 The Autonomic Networking Infrastructure (ANI) therefore is the foundation for autonomic functions. 3. The Autonomic Network Element This section explains the general architecture of an Autonomic Network Element (Section 3.1), how it tracks its surrounding environment in an Adjacency Table (Section 3.2), and the state machine which defines the behaviour of the network element (Section 3.3), based on that adjacency table. 3.1. Architecture This section describes an autonomic network element and its internal architecture. The reference model explained in the document "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows the sources of information that an autonomic service agent can leverage: Self-knowledge, network knowledge (through discovery), Intent (see Section 7.2), and feedback loops. There are two levels inside an autonomic node: the level of Autonomic Service Agents, and the level of the Autonomic Networking Infrastructure, with the former using the services of the latter. Figure 2 illustrates this concept. +------------------------------------------------------------+ | | | +-----------+ +------------+ +------------+ | | | Autonomic | | Autonomic | | Autonomic | | | | Service | | Service | | Service | | | | Agent 1 | | Agent 2 | | Agent 3 | | | +-----------+ +------------+ +------------+ | | ^ ^ ^ | | - - | - - API level - -| - - - - - - - |- - - | | V V V | |------------------------------------------------------------| | Autonomic Networking Infrastructure | | - Data structures (ex: certificates, peer information) | | - Generalized Autonomic Control Plane (GACP) | | - Autonomic Node Addressing and naming | | - Discovery, negotiation and synchronisation functions | | - Distribution of Intent and other information | | - Aggregated reporting and feedback loops | | - Routing | |------------------------------------------------------------| | Basic Operating System Functions | +------------------------------------------------------------+ Figure 2: Model of an autonomic node Behringer, et al. Expires May 27, 2019 [Page 5] Internet-Draft AN Reference Model November 2018 The Autonomic Networking Infrastructure (lower part of Figure 2) contains node specific data structures, for example trust information about itself and its peers, as well as a generic set of functions, independent of a particular usage. This infrastructure should be generic, and support a variety of Autonomic Service Agents (upper part of Figure 2). It contains addressing and naming of autonomic nodes, discovery, negotiation and synchronisation functions, distribution of information, reporting and feedback loops, as well as routing inside the Autonomic Control Plane. The Generalized Autonomic Control Plane (GACP) is the summary of all interactions of the Autonomic Networking Infrastructure with other nodes and services. A specific implementation of the GACP is referred to here as the Autonomic Control Plane (ACP), and described in [I-D.ietf-anima-autonomic-control-plane]. The use cases of "Autonomics" such as self-management, self- optimisation, etc, are implemented as Autonomic Service Agents. They use the services and data structures of the underlying Autonomic Networking Infrastructure, which should be self-managing. The "Basic Operating System Functions" include the "normal OS", including the network stack, security functions, etc. Full AN nodes have the full Autonomic Networking Infrastructure, with the full functionality described in this document. At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI and well-defined minimal functionality. They are currently out of scope. 3.2. The Adjacency Table Autonomic Networking is based on direct interactions between devices of a domain. The Autonomic Control Plane (ACP) is normally constructed on a hop-by-hop basis. Therefore, many interactions in the ANI are based on the ANI adjacency table. There are interactions that provide input into the adjacency table, and other interactions that leverage the information contained in it. The ANI adjacency table contains information about adjacent autonomic nodes, at a minimum: node-ID, IP address in data plane, IP address in ACP, domain, certificate. An autonomic node maintains this adjacency table up to date. The adjacency table only contains information about other nodes that are capable of Autonomic Networking; non- autonomic nodes are normally not tracked here. However, the information is tracked independently of the status of the peer nodes; specifically, it contains information about non-enrolled nodes, nodes of the same and other domains. The adjacency table may contain Behringer, et al. Expires May 27, 2019 [Page 6] Internet-Draft AN Reference Model November 2018 information about the validity and trust level of the adjacent autonomic nodes. The adjacency table is fed by the following inputs: o Link local discovery: This interaction happens in the data plane, using IPv6 link local addressing only, because this addressing type is itself autonomic. This way the nodes learns about all autonomic nodes around itself. The related standards track documents ([I-D.ietf-anima-grasp], [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-autonomic-control-plane]) describe in detail how link local discovery is used. o Vendor re-direct: A new device may receive information on where its home network is through a vendor based Manufacturer Authorized Signing Authority (MASA, see Section 5.3) re-direct; this is typically a routable address. o Non-autonomic input: A node may be configured manually with an autonomic peer; it could learn about autonomic nodes through DHCP options, DNS, and other non-autonomic mechanisms. Generally such non-autonomic mechansims require some administrator intervention. The key purpose is to by-pass a non-autonomic device or network. As this pertains to new devices, it is covered in appendix A and B of [I-D.ietf-anima-bootstrapping-keyinfra]. The adjacency table is defining the behaviour of an autonomic node: o If the node has not bootstrapped into a domain (i.e., doesn't have a domain certificate), it rotates through all nodes in the adjacency table that claim to have a domain, and will attempt bootstrapping through them, one by one. One possible response is a re-direct via a vendor MASA, which will be entered into the adjacency table (see second bullet above). See [I-D.ietf-anima-bootstrapping-keyinfra] for details. o If the adjacent node has the same domain, it will authenticate that adjacent node and, if successful, establish the Autonomic Control Plane (ACP). See [I-D.ietf-anima-autonomic-control-plane]. o Once the node is part of the ACP of a domain, it will use GRASP [I-D.ietf-anima-grasp] to find Registrar(s) of its domain and potentially other services. o If the node is part of an ACP and has discovered at least one Registrar in its domain via GRASP, it will start the "join Behringer, et al. Expires May 27, 2019 [Page 7] Internet-Draft AN Reference Model November 2018 assistant" ASA, and act as a join assistant for neighboring nodes that need to be bootstrapped. See Section 6.3.1.2 for details. o Other behaviours are possible, for example establishing the ACP also with devices of a sub-domain, to other domains, etc. Those will likely be controlled by Intent. They are outside scope for the moment. Note that Intent is distributed through the ACP; therefore, a node can only adapt Intent driven behaviour once it has joined the ACP. At the moment, ANIMA does not consider providing Intent outside the ACP; this can be considered later. Once a node has joined the ACP, it will also learn the ACP addresses of its adjacent nodes, and add them to the adjacency table, to allow for communication inside the ACP. Further autonomic domain interactions will now happen inside the ACP. At this moment, only negotiation / synchronization via GRASP [I-D.ietf-anima-grasp] is being defined. (Note that GRASP runs in the data plane, as an input in building the adjacency table, as well as inside the ACP.) Autonomic Functions consist of Autonomic Service Agents (ASAs). They run logically above the AN Infrastructure, and may use the adjacency table, the ACP, negotiation and synchronization through GRASP in the ACP, Intent and other functions of the ANI. Since the ANI only provides autonomic interactions within a domain, autonomic functions can also use any other context on a node, specifically the global data plane. 3.3. State Machine Autonomic Networking applies during the full life-cycle of a node. This section describes a state machine of an autonomic node, throughout its life. A device is normally expected to store its domain specific identity, the LDevID (see Section 5.2), in persistent storage, to be available after a powercycle event. For device types that cannot store the LDevID in persistent storage, a powercycle event is effectively equivalent to a factory reset. 3.3.1. State 1: Factory Default An autonomic node leaves the factory in this state. In this state, the node has no domain specific configuration, specifically no LDevID, and could be used in any particular target network. It does however have a vendor/manufacturer specific ID, the IDevID [IDevID]. Nodes without IDevID cannot be autonomically and securely enrolled into a domain; they require manual pre-staging, in which case the pre-staging takes them directly to state 2. Behringer, et al. Expires May 27, 2019 [Page 8] Internet-Draft AN Reference Model November 2018 Transitions: o Bootstrap event: The device enrols into a domain; as part of this process it receives a domain identity (LDevID). If enrollment is successful, the next state is state 2. See [I-D.ietf-anima-bootstrapping-keyinfra] Section 3 for details on enrollment. o Powercycle event: The device loses all state tables. It remains in state: 1. 3.3.2. State 2: Enrolled An autonomic node is in the state "enrolled" if it has a domain identity (LDevID), and has currently no ACP channel up. It may have further configuration or state, for example if it had been in state 3 before, but lost all its ACP channels. The LDevID can only be removed from a device through a factory reset, which also removes all other state from the device. This ensures that a device has no stale domain specific state when entering the "enrolled" state from state 1. Transitions: o Joining ACP: The device establishes an ACP channel to an adjacent device. See [I-D.ietf-anima-autonomic-control-plane] for details. Next state: 3. o Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1. o Powercycle event: The device loses all state tables, but not its domain identity (LDevID). it remains in state: 2. 3.3.3. State 3: In ACP In this state, the autonomic node has at least one ACP channel to another device. The node can now participate in further autonomic transactions, such as starting autonomic service agents (e.g., it must now enable the join assistant ASA, to help other devices to join the domain. Other conditions may apply to such interactions, for example to serve as a join assistant, the device must first discover a bootstrap Registrar. Transitions: o Leaving ACP: The device drops the last (or only) ACP channel to an adjacent device. Next state: 2. Behringer, et al. Expires May 27, 2019 [Page 9] Internet-Draft AN Reference Model November 2018 o Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1. o Powercycle event: The device loses all state tables, but not its domain identity (LDevID). Next state: 2. 4. The Autonomic Networking Infrastructure The Autonomic Networking Infrastructure provides a layer of common functionality across an Autonomic Network. It provides the elementary functions and services, as well as extensions. An Autonomic Function, comprising of Autonomic Service Agents on nodes, uses the functions described in this section. 4.1. Naming Inside a domain, each autonomic device should be assigned a unique name. The naming scheme should be consistent within a domain. Names are typically assigned by a Registrar at bootstrap time and persistent over the lifetime of the device. All Registrars in a domain must follow the same naming scheme. In the absence of a domain specific naming scheme, a default naming scheme should use the same logic as the addressing scheme discussed in [I-D.ietf-anima-autonomic-control-plane]. The device name is then composed of a Registrar ID (for example taking a MAC address of the Registrar) and a device number. An example name would then look like this: 0123-4567-89ab-0001 The first three fields are the MAC address, the fourth field is the sequential number for the device. 4.2. Addressing Autonomic Service Agents (ASAs) need to communicate with each other, using the autonomic addressing of the Autonomic Networking Infrastructure of the node they reside on. This section describes the addressing approach of the Autonomic Networking Infrastructure, used by ASAs. Addressing approaches for the data plane of the network are outside the scope of this document. These addressing approaches may be configured and managed in the traditional way, or negotiated as a service of an ASA. One use case for such an autonomic function is described in [I-D.ietf-anima-prefix-management]. Behringer, et al. Expires May 27, 2019 [Page 10] Internet-Draft AN Reference Model November 2018 Autonomic addressing is a function of the Autonomic Networking Infrastructure (lower part of Figure 2), specifically the Autonomic Control Plane. ASAs do not have their own addresses. They may use either API calls, or the autonomic addressing scheme of the Autonomic Networking Infrastructure. An autonomic addressing scheme has the following requirements: o Zero-touch for simple networks: Simple networks should have complete self-management of addressing, and not require any central address management, tools, or address planning. o Low-touch for complex networks: If complex networks require operator input for autonomic address management, it should be limited to high level guidance only, expressed in Intent. o Flexibility: The addressing scheme must be flexible enough for nodes to be able to move around, for the network to grow, split and merge. o Robustness: It should be as hard as possible for an administrator to negatively affect addressing (and thus connectivity) in the autonomic context. o Stability: The addressing scheme should be as stable as possible. However, implementations need to be able to recover from unexpected address changes. o Support for virtualization: Autonomic functions can exist either at the level of the physical network and physical devices, or at the level of virtual machines, containers and networks. In particular, Autonomic Nodes may support Autonomic Service Agents in virtual entities. The infrastructure, including the addressing scheme, should be able to support this architecture. o Simplicity: To make engineering simpler, and to give the human administrator an easy way to trouble-shoot autonomic functions. o Scale: The proposed scheme should work in any network of any size. o Upgradability: The scheme must be able to support different addressing concepts in the future. The proposed addressing scheme is described in the document "An Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). Behringer, et al. Expires May 27, 2019 [Page 11] Internet-Draft AN Reference Model November 2018 4.3. Discovery Traditionally, most of the information a node requires is provided through configuration or northbound interfaces. An autonomic function should rely on such northbound interfaces minimally or not at all, and therefore it needs to discover peers and other resources in the network. This section describes various discovery functions in an autonomic network. Discovering nodes and their properties and capabilities: A core function to establish an autonomic domain is the mutual discovery of autonomic nodes, primarily adjacent nodes and secondarily off-link peers. This may in principle either leverage existing discovery mechanisms, or use new mechanisms tailored to the autonomic context. An important point is that discovery must work in a network with no predefined topology, ideally no manual configuration of any kind, and with nodes starting up from factory condition or after any form of failure or sudden topology change. Discovering services: Network services such as AAA should also be discovered and not configured. Service discovery is required for such tasks. An autonomic network can either leverage existing service discovery functions, or use a new approach, or a mixture. Thus the discovery mechanism could either be fully integrated with autonomic signaling (next section) or could use an independent discovery mechanism such as DNS Service Discovery or Service Location Protocol. This choice could be made independently for each Autonomic Service Agent, although the infrastructure might require some minimal lowest common denominator (e.g., for discovering the security bootstrap mechanism, or the source of information distribution, Section 4.7). Phase 1 of Autonomic Networking uses GRASP for discovery, described in [I-D.ietf-anima-grasp]. 4.4. Signaling Between Autonomic Nodes Autonomic nodes must communicate with each other, for example to negotiate and/or synchronize technical objectives (i.e., network parameters) of any kind and complexity. This requires some form of signaling between autonomic nodes. Autonomic nodes implementing a specific use case might choose their own signaling protocol, as long as it fits the overall security model. However, in the general case, any pair of autonomic nodes might need to communicate, so there needs to be a generic protocol for this. A prerequisite for this is that autonomic nodes can discover each other without any preconfiguration, as mentioned above. To be generic, discovery and signaling must be Behringer, et al. Expires May 27, 2019 [Page 12] Internet-Draft AN Reference Model November 2018 able to handle any sort of technical objective, including ones that require complex data structures. The document "A Generic Autonomic Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] describes more detailed requirements for discovery, negotiation and synchronization in an autonomic network. It also defines a protocol, GRASP, for this purpose, including an integrated but optional discovery protocol. GRASP is normally expected to run inside the Autonomic Control Plane (ACP; see Section 4.6) and to depend on the ACP for security. It may run insecurely for a short time during bootstrapping. An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are not excluded. 4.5. Routing All autonomic nodes in a domain must be able to communicate with each other, and later phases also with autonomic nodes outside their own domain. Therefore, an Autonomic Control Plane relies on a routing function. For Autonomic Networks to be interoperable, they must all support one common routing protocol. The routing protocol is defined in the ACP document [I-D.ietf-anima-autonomic-control-plane]. 4.6. The Autonomic Control Plane The "Autonomic Control Plane" carries the control protocols in an autonomic network. In the architecture described here, it is implemented as an overlay network. The document "An Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes the implementation details suggested here. This document uses the term "overlay" to mean a set of point-to-point adjacencies congruent with the underlying interconnection topology. The terminology may not be aligned with a common usage of the "overlay" term in routing context. See [I-D.ietf-anima-stable-connectivity] for uses cases for the ACP. 4.7. Information Distribution (*) Certain forms of information require distribution across an autonomic domain. The distribution of information runs inside the Autonomic Control Plane. For example, Intent is distributed across an autonomic domain, as explained in [RFC7575]. Behringer, et al. Expires May 27, 2019 [Page 13] Internet-Draft AN Reference Model November 2018 Intent is the policy language of an Autonomic Network, see also Section 7.2. It is a high level policy, and should change only infrequently (order of days). Therefore, information such as Intent should be simply flooded to all nodes in an autonomic domain, and there is currently no perceived need to have more targeted distribution methods. Intent is also expected to be monolithic, and flooded as a whole. One possible method for distributing Intent, as well as other forms of data, is discussed in [I-D.liu-anima-grasp-distribution]. Intent and information distribution are not part of phase 1 of ANIMA. 5. Security and Trust Infrastructure An Autonomic Network is self-protecting. All protocols are secure by default, without the requirement for the administrator to explicitly configure security, with the exception of setting up a PKI infrastructure. Autonomic nodes have direct interactions between themselves, which must be secured. Since an autonomic network does not rely on configuration, it is not an option to configure, for example, pre- shared keys. A trust infrastructure such as a PKI infrastructure must be in place. This section describes the principles of this trust infrastructure. In this first phase of autonomic networking, a device is either within the trust domain and fully trusted, or outside the trust domain and fully untrusted. The default method to automatically bring up a trust infrastructure is defined in the document "Bootstrapping Key Infrastructures" [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this enrollment process are described in Section 6.3. An autonomic node must implement the enrollment and join assistant ASAs. The registrar ASA may be implemented only on a sub-set of nodes. 5.1. Public Key Infrastructure An autonomic domain uses a PKI model. The root of trust is a certification authority (CA). A registrar acts as a registration authority (RA). A minimum implementation of an autonomic domain contains one CA, one Registrar, and network elements. 5.2. Domain Certificate Each device in an autonomic domain uses a domain certificate (LDevID) to prove its identity. A new device uses its manufacturer provided certificate (IDevID) during bootstrap, to obtain a domain Behringer, et al. Expires May 27, 2019 [Page 14] Internet-Draft AN Reference Model November 2018 certificate. [I-D.ietf-anima-bootstrapping-keyinfra] describes how a new device receives a domain certificate, and the certificate format. 5.3. The MASA The Manufacturer Authorized Signing Authority (MASA) is a trusted service for bootstrapping devices. The purpose of the MASA is to provide ownership tracking of devices in a domain. The MASA provides audit, authorization, and ownership tokens to the registrar during the bootstrap process to assist in the authentication of devices attempting to join an Autonomic Domain, and to allow a joining device to validate whether it is joining the correct domain. The details for MASA service, security, and usage are defined in [I-D.ietf-anima-bootstrapping-keyinfra]. 5.4. Sub-Domains (*) By default, sub-domains are treated as different domains. This implies no trust between a domain and its sub-domains, and no trust between sub-domains of the same domain. Specifically, no ACP is built, and Intent is valid only for the domain it is defined for explicitly. In phase 2 of ANIMA, alternative trust models should be defined, for example to allow full or limited trust between domain and sub-domain. 5.5. Cross-Domain Functionality (*) By default, different domains do not interoperate, no ACP is built and no trust is implied between them. In the future, models can be established where other domains can be trusted in full or for limited operations between the domains. 6. Autonomic Service Agents (ASA) This section describes how autonomic services run on top of the Autonomic Networking Infrastructure. 6.1. General Description of an ASA An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole." Thus it is a process that makes use of the features provided by the ANI to achieve its own goals, usually including interaction with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or otherwise. Of course it also interacts with the specific targets of Behringer, et al. Expires May 27, 2019 [Page 15] Internet-Draft AN Reference Model November 2018 its function, using any suitable mechanism. Unless its function is very simple, the ASA will need to handle overlapping asynchronous operations. It may therefore be a quite complex piece of software in its own right, forming part of the application layer above the ANI. ASA design guidelines are available in [I-D.carpenter-anima-asa-guidelines]. Thus we can distinguish at least three classes of ASAs: o Simple ASAs with a small footprint that could run anywhere. o Complex, possibly multi-threaded ASAs that have a significant resource requirement and will only run on selected nodes. o A few 'infrastructure ASAs' that use basic ANI features in support of the ANI itself, which must run in all autonomic nodes. These are outlined in the following sections. Autonomic nodes, and therefore their ASAs, know their own capabilities and restrictions, derived from hardware, firmware or pre-installed software: They are "self-aware". The role of an autonomic node depends on Intent and on the surrounding network behaviors, which may include forwarding behaviors, aggregation properties, topology location, bandwidth, tunnel or translation properties, etc. For example, a node may decide to act as a backup node for a neighbor, if its capabilities allow it to do so. Following an initial discovery phase, the node properties and those of its neighbors are the foundation of the behavior of a specific node. A node and its ASAs have no pre-configuration for the particular network in which they are installed. Since all ASAs will interact with the ANI, they will depend on appropriate application programming interfaces (APIs). It is desirable that ASAs are portable between operating systems, so these APIs need to be universal. An API for GRASP is described in [I-D.ietf-anima-grasp-api]. ASAs will in general be designed and coded by experts in a particular technology and use case, not by experts in the ANI and its components. Also, they may be coded in a variety of programming languages, in particular including languages that support object constructs as well as traditional variables and structures. The APIs should be designed with these factors in mind. Behringer, et al. Expires May 27, 2019 [Page 16] Internet-Draft AN Reference Model November 2018 It must be possible to run ASAs as non-privileged (user space) processes except for those (such as the infrastructure ASAs) that necessarily require kernel privilege. Also, it is highly desirable that ASAs can be dynamically loaded on a running node. Since autonomic systems must be self-repairing, it is of great importance that ASAs are coded using robust programming techniques. All run-time error conditions must be caught, leading to suitable minimally disruptive recovery actions, also considering a complete restart of the ASA. Conditions such as discovery failures or negotiation failures must be treated as routine, with the ASA retrying the failed operation, preferably with an exponential back- off in the case of persistent errors. When multiple threads are started within an ASA, these threads must be monitored for failures and hangups, and appropriate action taken. Attention must be given to garbage collection, so that ASAs never run out of resources. There is assumed to be no human operator - again, in the worst case, every ASA must be capable of restarting itself. ASAs will automatically benefit from the security provided by the ANI, and specifically by the ACP and by GRASP. However, beyond that, they are responsible for their own security, especially when communicating with the specific targets of their function. Therefore, the design of an ASA must include a security analysis beyond 'use ANI security.' 6.2. ASA Life-Cycle Management ASAs operating on a given ANI may come from different providers and pursue different objectives. Management of ASAs and its interactions with the ANI should follow the same operating principles, hence comply to a generic life-cycle management model. The ASA life-cycle provides standard processes to: o install ASA: copy the ASA code onto the node and start it, o deploy ASA: associate the ASA instance with a (some) managed network device(s) (or network function), o control ASA execution: when and how an ASA executes its control loop. The life-cyle will cover the sequential states below: Installation, Deployment, Operation and the transitional states in-between. This Life-Cycle will also define which interactions ASAs have with the ANI in between the different states. The noticeable interactions are: Behringer, et al. Expires May 27, 2019 [Page 17] Internet-Draft AN Reference Model November 2018 o Self-description of ASA instances at the end of deployment: its format needs to define the information required for the management of ASAs by ANI entities o Control of ASA control-loop during the operation: a signaling has to carry formatted messages to control ASA execution (at least starting and stopping the control loop) 6.3. Specific ASAs for the Autonomic Network Infrastructure The following functions provide essential, required functionality in an autonomic network, and are therefore mandatory to implement on unconstrained autonomic nodes. They are described here as ASAs that include the underlying infrastructure components, but implementation details might vary. The first three together support the trust enrollment process described in Section 5. For details see [I-D.ietf-anima-bootstrapping-keyinfra]. 6.3.1. The enrollment ASAs 6.3.1.1. The Pledge ASA This ASA includes the function of an autonomic node that bootstraps into the domain with the help of an join assitant ASA (see below). Such a node is known as a Pledge during the enrollment process. This ASA must be installed by default on all nodes that require an autonomic zero-touch bootstrap. 6.3.1.2. The Join Assistant ASA This ASA includes the function of an autonomic node that helps a non- enrolled, adjacent devices to enroll into the domain. This ASA must be installed on all nodes, although only one join assistant needs to be active on a given LAN. See also [I-D.ietf-anima-bootstrapping-keyinfra]. 6.3.1.3. The Join Registrar ASA This ASA includes the join registrar function in an autonomic network. This ASA does not need to be installed on all nodes, but only on nodes that implement the Join Registrar function. Behringer, et al. Expires May 27, 2019 [Page 18] Internet-Draft AN Reference Model November 2018 6.3.2. The ACP ASA This ASA includes the ACP function in an autonomic network. In particular it acts to discover other potential ACP nodes, and to support the establishment and teardown of ACP channels. This ASA must be installed on all nodes. For details see Section 4.6 and [I-D.ietf-anima-autonomic-control-plane]. 6.3.3. The Information Distribution ASA (*) This ASA is currently out of scope in ANIMA, and provided here only as background information. This ASA includes the information distribution function in an autonomic network. In particular it acts to announce the availability of Intent and other information to all other autonomic nodes. This ASA does not need to be installed on all nodes, but only on nodes that implement the information distribution function. For details see Section 4.7. Note that information distribution can be implemented as a function in any ASA. See [I-D.liu-anima-grasp-distribution] for more details on how information is suggested to be distributed. 7. Management and Programmability This section describes how an Autonomic Network is managed, and programmed. 7.1. Managing a (Partially) Autonomic Network Autonomic management usually co-exists with traditional management methods in most networks. Thus, autonomic behavior will be defined for individual functions in most environments. Examples for overlap are: o Autonomic functions can use traditional methods and protocols (e.g., SNMP and NETCONF) to perform management tasks, inside and outside the ACP; o Autonomic functions can conflict with behavior enforced by the same traditional methods and protocols; o Traditional functions can use the ACP, for example if reachability on the data plane is not (yet) established. The autonomic Intent is defined at a high level of abstraction. However, since it is necessary to address individual managed Behringer, et al. Expires May 27, 2019 [Page 19] Internet-Draft AN Reference Model November 2018 elements, autonomic management needs to communicate in lower-level interactions (e.g., commands and requests). For example, it is expected that the configuration of such elements be performed using NETCONF and YANG modules as well as the monitoring be executed through SNMP and MIBs. Conflict can occur between autonomic default behavior, autonomic Intent, traditional management methods. Conflict resolution is achieved in autonomic management through prioritization [RFC7575]. The rationale is that manual and node-based management have a higher priority over autonomic management. Thus, the autonomic default behavior has the lowest priority, then comes the autonomic Intent (medium priority), and, finally, the highest priority is taken by node-specific network management methods, such as the use of command line interfaces. 7.2. Intent (*) Intent is not covered in the current implementation specifications. This section discusses a topic for further research. This section gives an overview of Intent, and how it is managed. Intent and Policy-Based Network Management (PBNM) is already described inside the IETF (e.g., PCIM) and in other SDOs (e.g., DMTF and TMF ZOOM). Intent can be described as an abstract, declarative, high-level policy used to operate an autonomic domain, such as an enterprise network [RFC7575]. Intent should be limited to high level guidance only, thus it does not directly define a policy for every network element separately. Intent can be refined to lower level policies using different approaches. This is expected in order to adapt the Intent to the capabilities of managed devices. Intent may contain role or function information, which can be translated to specific nodes [RFC7575]. One of the possible refinements of the Intent is using Event- Condition-Action (ECA) rules. Different parameters may be configured for Intent. These parameters are usually provided by the human operator. Some of these parameters can influence the behavior of specific autonomic functions as well as the way the Intent is used to manage the autonomic domain. Intent is discussed in more detail in [I-D.du-anima-an-intent]. Intent as well as other types of information are distributed via GRASP, see [I-D.liu-anima-grasp-distribution]. Behringer, et al. Expires May 27, 2019 [Page 20] Internet-Draft AN Reference Model November 2018 7.3. Aggregated Reporting (*) Aggregated reporting is not covered in the current implementation specifications. This section discusses a topic for further research. An Autonomic Network should minimize the need for human intervention. In terms of how the network should behave, this is done through an autonomic Intent provided by the human administrator. In an analogous manner, the reports which describe the operational status of the network should aggregate the information produced in different network elements in order to present the effectiveness of autonomic Intent enforcement. Therefore, reporting in an autonomic network should happen on a network-wide basis [RFC7575]. Multiple simultaneous events can occur in an autonomic network in the same way they can happen in a traditional network. However, when reporting to a human administrator, such events should be aggregated to avoid notifications about individual managed elements. In this context, algorithms may be used to determine what should be reported (e.g., filtering) and in which way and how different events are related to each other. Besides that, an event in an individual element can be compensated by changes in other elements to maintain a network-wide target which is described in the autonomic Intent. Reporting in an autonomic network may be at the same abstraction level as Intent. In this context, the aggregated view of current operational status of an autonomic network can be used to switch to different management modes. Despite the fact that autonomic management should minimize the need for user intervention, possibly there are some events that need to be addressed by human administrator actions. 7.4. Feedback Loops to NOC (*) Feedback loops are required in an autonomic network to allow the intervention of a human administrator or central control systems, while maintaining a default behaviour. Through a feedback loop an administrator must be prompted with a default action, and has the possibility to acknowledge or override the proposed default action. Uni-directional notifications to the NOC, that do not propose any default action, and do not allow an override as part of the transaction are considered like traditional notification services, such as syslog. They are expected to co-exist with autonomic methods, but are not covered in this draft. Behringer, et al. Expires May 27, 2019 [Page 21] Internet-Draft AN Reference Model November 2018 7.5. Control Loops (*) Control loops are not covered in the current implementation specifications. This section discusses a topic for further research. Control loops are used in autonomic networking to provide a generic mechanism to enable the Autonomic System to adapt (on its own) to various factors that can change the goals that the autonomic network is trying to achieve, or how those goals are achieved. For example, as user needs, business goals, and the ANI itself changes, self- adaptation enables the ANI to change the services and resources it makes available to adapt to these changes. Control loops operate to continuously observe and collect data that enables the autonomic management system to understand changes to the behavior of the system being managed, and then provide actions to move the state of the system being managed toward a common goal. Self-adaptive systems move decision-making from static, pre-defined commands to dynamic processes computed at runtime. Most autonomic systems use a closed control loop with feedback. Such control loops should be able to be dynamically changed at runtime to adapt to changing user needs, business goals, and changes in the ANI. 7.6. APIs (*) APIs are not covered in the current implementation specifications. This section discusses a topic for further research. Most APIs are static, meaning that they are pre-defined and represent an invariant mechanism for operating with data. An Autonomic Network should be able to use dynamic APIs in addition to static APIs. A dynamic API is one that retrieves data using a generic mechanism, and then enables the client to navigate the retrieved data and operate on it. Such APIs typically use introspection and/or reflection. Introspection enables software to examine the type and properties of an object at runtime, while reflection enables a program to manipulate the attributes, methods, and/or metadata of an object. APIs must be able to express and preserve the semantics of data models. For example, software contracts [Meyer97] are based on the principle that a software-intensive system, such as an Autonomic Network, is a set of communicating components whose interaction is based on precisely-defined specifications of the mutual obligations that interacting components must respect. This typically includes specifying: Behringer, et al. Expires May 27, 2019 [Page 22] Internet-Draft AN Reference Model November 2018 o pre-conditions that must be satisfied before the method can start execution o post-conditions that must be satisfied when the method has finished execution o invariant attributes that must not change during the execution of the method 7.7. Data Model (*) Data models are not covered in the current implementation specifications. This section discusses a topic for further research. The following definitions are adapted from [I-D.ietf-supa-generic-policy-data-model]: An information model is a representation of concepts of interest to an environment in a form that is independent of data repository, data definition language, query language, implementation language, and protocol. In contrast, a data model is a representation of concepts of interest to an environment in a form that is dependent on data repository, data definition language, query language, implementation language, and protocol (typically, but not necessarily, all three). The utility of an information model is to define objects and their relationships in a technology-neutral manner. This forms a consensual vocabulary that the ANI and ASAs can use. A data model is then a technology-specific mapping of all or part of the information model to be used by all or part of the system. A system may have multiple data models. Operational Support Systems, for example, typically have multiple types of repositories, such as SQL and NoSQL, to take advantage of the different properties of each. If multiple data models are required by an Autonomic System, then an information model should be used to ensure that the concepts of each data model can be related to each other without technological bias. A data model is essential for certain types of functions, such as a Model-Reference Adaptive Control Loop (MRACL). More generally, a data model can be used to define the objects, attributes, methods, and relationships of a software system (e.g., the ANI, an autonomic node, or an ASA). A data model can be used to help design an API, as well as any language used to interface to the Autonomic Network. Behringer, et al. Expires May 27, 2019 [Page 23] Internet-Draft AN Reference Model November 2018 8. Coordination Between Autonomic Functions (*) Coordination between autonomic functions is not covered in the current implementation specifications. This section discusses a topic for further research. 8.1. The Coordination Problem (*) Different autonomic functions may conflict in setting certain parameters. For example, an energy efficiency function may want to shut down a redundant link, while a load balancing function would not want that to happen. The administrator must be able to understand and resolve such interactions, to steer autonomic network performance to a given (intended) operational point. Several interaction types may exist among autonomic functions, for example: o Cooperation: An autonomic function can improve the behavior or performance of another autonomic function, such as a traffic forecasting function used by a traffic allocation function. o Dependency: An autonomic function cannot work without another one being present or accessible in the autonomic network. o Conflict: A metric value conflict is a conflict where one metric is influenced by parameters of different autonomic functions. A parameter value conflict is a conflict where one parameter is modified by different autonomic functions. Solving the coordination problem beyond one-by-one cases can rapidly become intractable for large networks. Specifying a common functional block on coordination is a first step to address the problem in a systemic way. The coordination life-cycle consists in three states: o At build-time, a "static interaction map" can be constructed on the relationship of functions and attributes. This map can be used to (pre-)define policies and priorities on identified conflicts. o At deploy-time, autonomic functions are not yet active/acting on the network. A "dynamic interaction map" is created for each instance of each autonomic functions and on a per resource basis, including the actions performed and their relationships. This map provides the basis to identify conflicts that will happen at run- time, categorize them and plan for the appropriate coordination strategies/mechanisms. Behringer, et al. Expires May 27, 2019 [Page 24] Internet-Draft AN Reference Model November 2018 o At run-time, when conflicts happen, arbitration is driven by the coordination strategies. Also new dependencies can be observed and inferred, resulting in an update of the dynamic interaction map and adaptation of the coordination strategies and mechanisms. Multiple coordination strategies and mechanisms exist and can be devised. The set ranges from basic approaches such as random process or token-based process, to approaches based on time separation and hierarchical optimization, to more complex approaches such as multi- objective optimization, and other control theory approaches and algorithms family. 8.2. A Coordination Functional Block (*) A common coordination functional block is a desirable component of the ANIMA reference model. It provides a means to ensure network properties and predictable performance or behavior such as stability, and convergence, in the presence of several interacting autonomic functions. A common coordination function requires: o A common description of autonomic functions, their attributes and life-cycle. o A common representation of information and knowledge (e.g., interaction maps). o A common "control/command" interface between the coordination "agent" and the autonomic functions. Guidelines, recommendations or BCPs can also be provided for aspects pertaining to the coordination strategies and mechanisms. 9. Security Considerations In this section we distinguish outsider and insider attacks. In an outsider attack all network elements and protocols are securely managed and operating, and an outside attacker can sniff packets in transit, inject and replay packets. In an insider attack, the attacker has access to an autonomic node or other means (e.g. remote code execution in the node by exploiting ACP-independent vulnerabilities in the node platform) to produce arbitrary payloads on the protected ACP channels. If a system has vulnerabilities in the implementation or operation (configuration), an outside attacker can exploit such vulnerabilies to become an insider attacker. Behringer, et al. Expires May 27, 2019 [Page 25] Internet-Draft AN Reference Model November 2018 9.1. Protection Against Outsider Attacks Here, we assume that all systems involved in an autonomic network are secured and operated according to best current practices. These protection methods comprise traditional security implementation and operation methods (such as code security, strong randomization algorithms, strong passwords, etc.) as well as mechanisms specific to an autonomic network (such as a secured MASA service). Traditional security methods for both implementation and operation are outside scope for this document. AN specific protocols and methods must also follow traditional security methods, in that all packets that can be sniffed or injected by an outside attacker are: o protected against modification. o authenticated. o protected against replay attacks. o confidentiality protected (encrypted). o and that the AN protocols are robust against packet drops and man- in-the-middle attacks. How these requirements are met is covered in the AN standards track documents that define the methods used, specifically [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-grasp], and [I-D.ietf-anima-autonomic-control-plane]. Most AN messages run inside the cryptographically protected ACP. The unprotected AN messages outside the ACP are limited to a simple discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]: The "Discovery Unsolicited Link-Local (DULL)" message, with detailed rules on its usage. If AN messages can be observed by a third party, they might reveal valuable information about network configuration, security precautions in use, individual users, and their traffic patterns. If encrypted, AN messages might still reveal some information via traffic analysis. Behringer, et al. Expires May 27, 2019 [Page 26] Internet-Draft AN Reference Model November 2018 9.2. Risk of Insider Attacks An autonomic network consists of autonomic devices that form a distributed self-managing system. Devices within a domain have credentials issued from a common trust anchor and can use them to create mutual trust. This means that any device inside a trust domain can by default use all distributed functions in the entire autonomic domain in a malicious way. If an autonomic node or protocol has vulnerabilities or is not securely operated, an outside attacker has the following generic ways to take control of an autonomic network: o Introducing a fake device into the trust domain, by subverting the authentication methods. This depends on the correct specification, implementation and operation of the AN protocols. o Subverting a device which is already part of a trust domain, and modifying its behavior. This threat is not specific to the solution discussed in this document, and applies to all network solutions. o Exploiting potentially yet unknown protocol vulnerabilities in the AN or other protocols. Also this is a generic threat that applies to all network solutions. The above threats are in principle comparable to other solutions: In the presence of design, implementation or operational errors, security is no longer guaranteed. However, the distributed nature of AN, specifically the Autonomic Control Plane, increases the threat surface significantly. For example, a compromised device may have full IP reachability to all other devices inside the ACP, and can use all AN methods and protocols. For the next phase of the ANIMA work it is therefore recommended to introduce a sub-domain security model, to reduce the attack surface and not expose a full domain to a potential intruder. Furthermore, additional security mechanisms on the ASA level should be considered for high-risk autonomic functions. 10. IANA Considerations This document requests no action by IANA. Behringer, et al. Expires May 27, 2019 [Page 27] Internet-Draft AN Reference Model November 2018 11. Acknowledgements Many people have provided feedback and input to this document: Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur Hecker. Useful reviews were made by Joel Halpern, Radia Perlman, Tianran Zhou and Christian Hopps. 12. Contributors Significant contributions to this document have been made by John Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia. 13. References 13.1. Normative References [I-D.ietf-anima-autonomic-control-plane] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", draft-ietf-anima-autonomic-control- plane-18 (work in progress), August 2018. [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-17 (work in progress), November 2018. [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- grasp-15 (work in progress), July 2017. [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", December 2009, . 13.2. Informative References [I-D.carpenter-anima-asa-guidelines] Carpenter, B., Ciavaglia, L., Jiang, S., and P. Pierre, "Guidelines for Autonomic Service Agents", draft- carpenter-anima-asa-guidelines-05 (work in progress), June 2018. [I-D.du-anima-an-intent] Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. Behringer, "ANIMA Intent Policy and Format", draft-du- anima-an-intent-05 (work in progress), February 2017. Behringer, et al. Expires May 27, 2019 [Page 28] Internet-Draft AN Reference Model November 2018 [I-D.ietf-anima-grasp-api] Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", draft-ietf-anima-grasp-api-02 (work in progress), June 2018. [I-D.ietf-anima-prefix-management] Jiang, S., Du, Z., and B. Carpenter, "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", draft-ietf- anima-prefix-management-07 (work in progress), December 2017. [I-D.ietf-anima-stable-connectivity] Eckert, T. and M. Behringer, "Using Autonomic Control Plane for Stable Connectivity of Network OAM", draft-ietf- anima-stable-connectivity-10 (work in progress), February 2018. [I-D.ietf-supa-generic-policy-data-model] Halpern, J. and J. Strassner, "Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)", draft- ietf-supa-generic-policy-data-model-04 (work in progress), June 2017. [I-D.liu-anima-grasp-distribution] Liu, B., Jiang, S., Xiao, X., Hecker, A., and Z. Despotovic, "Information Distribution in Autonomic Networking", draft-liu-anima-grasp-distribution-09 (work in progress), October 2018. [Meyer97] Meyer, B., "Object-Oriented Software Construction (2nd edition)", Prentice-Hall, ISBN 978-0136291558, 1997. [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, . Behringer, et al. Expires May 27, 2019 [Page 29] Internet-Draft AN Reference Model November 2018 Authors' Addresses Michael H. Behringer (editor) Email: Michael.H.Behringer@gmail.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Toerless Eckert Futurewei Technologies Inc. 2330 Central Expy Santa Clara 95050 USA Email: tte@cs.fau.de Laurent Ciavaglia Nokia Villarceaux Nozay 91460 FR Email: laurent.ciavaglia@nokia.com Jeferson Campos Nobre University of Vale do Rio dos Sinos Av. Unisinos, 950 Sao Leopoldo 91501-970 Brazil Email: jcnobre@unisinos.br Behringer, et al. Expires May 27, 2019 [Page 30] ./draft-ietf-dmm-ondemand-mobility-18.txt0000644000764400076440000006722113520367615017567 0ustar iustyiusty DMM Working Group A. Yegin Internet-Draft Actility Intended status: Informational D. Moses Expires: January 31, 2020 Intel S. Jeon Sungkyunkwan University July 30, 2019 On Demand Mobility Management draft-ietf-dmm-ondemand-mobility-18 Abstract Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in [RFC7333]. This document defines a new concep of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-Socket basis, and suggests extensions to the networking stack's API to accomodate this concept. 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 https://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 31, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Yegin, et al. Expires January 31, 2020 [Page 1] Internet-Draft On Demand Mobility July 2019 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. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. High-level Description . . . . . . . . . . . . . . . . . 4 3.2. Types of IP Addresses . . . . . . . . . . . . . . . . . . 5 3.3. Granularity of Selection . . . . . . . . . . . . . . . . 6 3.4. On Demand Nature . . . . . . . . . . . . . . . . . . . . 6 4. Backwards Compatibility Considerations . . . . . . . . . . . 7 4.1. Applications . . . . . . . . . . . . . . . . . . . . . . 8 4.2. IP Stack in the Mobile Host . . . . . . . . . . . . . . . 8 4.3. Network Infrastructure . . . . . . . . . . . . . . . . . 8 4.4. Merging this work with RFC5014 . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Conveying the Desired Address Type . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], the following two attributes are defined for IP service provided to mobile hosts: - Session Continuity The ability to maintain an ongoing transport interaction by keeping the same local end-point IP address throughout the life-time of the IP socket despite the mobile host changing its point of attachment within the IP network topology. The IP address of the host may change after closing the IP socket and before opening a new one, but that does not jeopardize the ability of applications using these IP sockets to work flawlessly. Session continuity is essential for mobile hosts to maintain ongoing flows without any interruption. Yegin, et al. Expires January 31, 2020 [Page 2] Internet-Draft On Demand Mobility July 2019 - IP Address Reachability The ability to maintain the same IP address for an extended period of time. The IP address stays the same across independent sessions, and even in the absence of any session. The IP address may be published in a long-term registry (e.g., DNS), and is made available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/published IP addresses. Mobile IP is designed to provide both session continuity and IP address reachability to mobile hosts. Architectures utilizing these protocols (e.g., 3GPP, 3GPP2, WIMAX) ensure that any mobile host attached to the compliant networks can enjoy these benefits. Any application running on these mobile hosts is subjected to the same treatment with respect to session continuity and IP address reachability. Achieving session continuity and IP address reachability with Mobile IP incurs some cost. Mobile IP protocol forces the mobile host's IP traffic to traverse a centrally-located router (Home Agent, HA), which incurs additional transmission latency and use of additional network resources, adds to the network CAPEX and OPEX, and decreases the reliability of the network due to the introduction of a single point of failure [RFC7333]. Therefore, session continuity and IP address reachability SHOULD be provided only when necessary. In reality not every application may need these benefits. IP address reachability is required for applications running as servers (e.g., a web server running on the mobile host). But, a typical client application (e.g., web browser) does not necessarily require IP address reachability. Similarly, session continuity is not required for all types of applications either. Applications performing brief communication (e.g., text messaging) can survive without having session continuity support. Furthermore, when an application needs session continuity, it may be able to satisfy that need by using a solution above the IP layer, such as MPTCP [RFC6824], SIP mobility [RFC3261], or an application- layer mobility solution. These higher-layer solutions are not subject to the same issues that arise with the use of Mobile IP since they can utilize the most direct data path between the end-points. But, if Mobile IP is being applied to the mobile host, the higher- layer protocols are rendered useless because their operation is inhibited by Mobile IP. Since Mobile IP ensures that the IP address of the mobile host remains fixed (despite the location and movement of the mobile host), the higher-layer protocols never detect the IP- layer change and never engage in mobility management. Yegin, et al. Expires January 31, 2020 [Page 3] Internet-Draft On Demand Mobility July 2019 This document proposes a solution for applications running on mobile hosts to indicate when establishing the network connection ('on demand') whether they need session continuity or IP address reachability. The network protocol stack on the mobile host, in conjunction with the network infrastructure, provides the required type of service. It is for the benefit of both the users and the network operators not to engage an extra level of service unless it is absolutely necessary. It is expected that applications and networks compliant with this specification will utilize this solution to use network resources more efficiently. 2. Notational Conventions 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 , [RFC2119] [RFC8174] when, they appear in all capitals, as shown here. 3. Solution 3.1. High-level Description Enabling applications to indicate their mobility service requirements e.g. session continuity and/or IP address reachability, comprises the following steps: - The application indicates to the network stack (local to the mobile host) the desired mobility service. - The network stack assigns a source IP address based on an IP prefix with the desired services that was previously provided by the network. If such an IP prefix is not available, the network stack performs the additional steps below. - The network stack sends a request to the network for a new source IP prefix that is associated with the desired mobility service. - The network responds with the suitable allocated source IP prefix (or responds with a failure indication). - If the suitable source IP prefix was allocates, the network stack constructs a source IP address and provides it to the application. This document specifies the new address types associated with mobility services and details the interaction between the applications and the network stack steps. It uses the Socket Yegin, et al. Expires January 31, 2020 [Page 4] Internet-Draft On Demand Mobility July 2019 interface as an example for an API between applications and the network stack. Other steps are outside the scope of this document. 3.2. Types of IP Addresses Four types of IP addresses are defined with respect to mobility management. - Fixed IP Address A Fixed IP address is an address with a guarantee to be valid for a very long time, regardless of whether it is being used in any packet to/from the mobile host, or whether or not the mobile host is connected to the network, or whether it moves from one point-of- attachment to another (with a different IP prefix) while it is connected. Fixed IP addresses are required by applications that need both session continuity and IP address reachability. - Session-lasting IP Address A session-lasting IP address is an address with a guarantee to be valid throughout the life-time of the socket(s) for which it was requested. It is guaranteed to be valid even after the mobile host had moved from one point-of-attachment to another (with a different IP prefix). Session-lasting IP addresses are required by applications that need session continuity but do not need IP address reachability. - Non-persistent IP Address This type of IP address has no guarantee to exist after a mobile host moves from one point-of-attachment to another, and therefore, no session continuity nor IP address reachability are provided. The IP address is created from an IP prefix that is obtained from the serving IP gateway and is not maintained across gateway changes. In other words, the IP prefix may be released and replaced by a new one when the IP gateway changes due to the movement of the mobile host forcing the creation of a new source IP address with the updated allocated IP prefix. - Graceful Replacement IP Address In some cases, the network cannot guarantee the validity of the provided IP prefix throughout the duration of the opened socket, but can provide a limited graceful period of time in which both the Yegin, et al. Expires January 31, 2020 [Page 5] Internet-Draft On Demand Mobility July 2019 original IP prefix and a new one are valid. This enables the application some flexibility in the transition from the existing source IP address to the new one. This gracefulness is still better than the non-persistence type of address for applications that can handle a change in their source IP address but require that extra flexibility. Applications running as servers at a published IP address require a Fixed IP Address. Long-standing applications (e.g., an SSH session) may also require this type of address. Enterprise applications that connect to an enterprise network via virtual LAN require a Fixed IP Address. Applications with short-lived transient sessions can use Session- lasting IP Addresses. For example: Web browsers. Applications with very short sessions, such as DNS clients and instant messengers, can utilize Non-persistent IP Addresses. Even though they could very well use Fixed or Session-lasting IP Addresses, the transmission latency would be minimized when a Non- persistent IP Addresses are used. Applications that can tolerate a short interruption in connectivity can use the Graceful-replacement IP addresses. For example, a streaming client that has buffering capabilities. 3.3. Granularity of Selection IP address type selection is made on a per-socket granularity. Different parts of the same application may have different needs. For example, the control-plane of an application may require a Fixed IP Address in order to stay reachable, whereas the data-plane of the same application may be satisfied with a Session-lasting IP Address. 3.4. On Demand Nature At any point in time, a mobile host may have a combination of IP addresses configured. Zero or more Fixed, zero or more Session- lasting, zero or more Non-persistent and zero or more Graceful- Replacement IP addresses may be configured by the IP stack of the host. The combination may be as a result of the host policy, application demand, or a mix of the two. When an application requires a specific type of IP address and such an address is not already configured on the host, the IP stack SHALL attempt to configure one. For example, a host may not always have a Session-lasting IP address available. When an application requests Yegin, et al. Expires January 31, 2020 [Page 6] Internet-Draft On Demand Mobility July 2019 one, the IP stack SHALL make an attempt to configure one by issuing a request to the network. If the operation fails, the IP stack SHALL fail the associated socket request and return an error. If successful, a Session-lasting IP Address gets configured on the mobile host. If another socket requests a Session-lasting IP address at a later time, the same IP address may be served to that socket as well. When the last socket using the same configured IP address is closed, the IP address may be released or kept for future applications that may be launched and require a Session-lasting IP address. In some cases it might be preferable for the mobile host to request a new Session-lasting IP address for a new opening of an IP socket (even though one was already assigned to the mobile host by the network and might be in use in a different, already active IP sockets). It is outside the scope of this specification to define criteria for choosing to use available addresses or choosing to request new ones. It supports both alternatives (and any combination). It is outside the scope of this specification to define how the host requests a specific type of prefix and how the network indicates the type of prefix in its advertisement or in its reply to a request. The following are matters of policy, which may be dictated by the host itself, the network operator, or the system architecture standard: - The initial set of IP addresses configured on the host at boot time. - Permission to grant various types of IP addresses to a requesting application. - Determination of a default address type when an application does not make any explicit indication, whether it already supports the required API or it is just a legacy application. 4. Backwards Compatibility Considerations Backwards compatibility support is REQUIRED by the following 3 types of entities: - The Applications on the mobile host - The IP stack in the mobile host - The network infrastructure Yegin, et al. Expires January 31, 2020 [Page 7] Internet-Draft On Demand Mobility July 2019 4.1. Applications Legacy applications that do not support the On-Demand functionality will use the legacy API and will not be able to take advantage of the On-Demand Mobility feature. Applications using the new On-Demand functionality should be aware that they may be executed in legacy environments that do not support it. Such environments may include a legacy IP stack on the mobile host, legacy network infrastructure, or both. In either case, the API will return an error code and the invoking applications may just give up and use legacy calls. 4.2. IP Stack in the Mobile Host New IP stacks (that implement On Demand functionality) MUST continue to support all legacy operations. If an application does not use On- Demand functionality, the IP stack MUST respond in a legacy manner. If the network infrastructure supports On-Demand functionality, the IP stack SHOULD follow the application request: If the application requests a specific address type, the stack SHOULD forward this request to the network. If the application does not request an address type, the IP stack MUST NOT request an address type and leave it to the network's default behavior to choose the type of the allocated IP prefix. If an IP prefix was already allocated to the host, the IP stack uses it and may not request a new one from the network. 4.3. Network Infrastructure The network infrastructure may or may not support the On-Demand functionality. How the IP stack on the host and the network infrastructure behave in case of a compatibility issue is outside the scope of this API specification. 4.4. Merging this work with RFC5014 [RFC5014] defines new flags that may be used with setsockopt() to influence source IP address selection for a socket. The list of flags include: source home address, care-of address, temporary address, public address CGA (Cryptographically Created Address) and non-CGA. When applications require session continuity service, they SHOULD NOT set the flags specified in [RFC5014]. However, if an application erroneously performs a combination of (1) Use setsockopt() to set a specific option (using one of the flags specified in [RFC5014]) and (2) Selects a source IP address type, the Yegin, et al. Expires January 31, 2020 [Page 8] Internet-Draft On Demand Mobility July 2019 IP stack will fulfill the request specified by (2) and ignore the flags set by (1). 5. Security Considerations The different service types (session continuity types and address reachability) associated with the allocated IP address types, may be associated with different costs. The cost to the operator for enabling a type of service, and the cost to applications using a selected service. A malicious application may use these to generate extra billing of a mobile subscriber, and/or impose costly services on the mobile operator. When costly services are limited, malicious applications may exhaust them, preventing other applications on the same mobile host from being able to use them. Mobile hosts that enables such service options, should provide capabilities for ensuring that only authorized applications can use the costly (or limited) service types. The ability to select service types requires the exchange of the association of source IP prefixes and their corresponding service types, between the mobile host and mobile network. Exposing these associations may provide information to passive attackers even if the traffic that is used with these addressed is encrypted. To avoid profiling an application according to the type of IP addresses, it is expected that prefixes provided by the mobile operator are associated to various type of addresses over time. As a result, the type of address could not be associated to the prefix, making application profiling based on the type of address harder. The application or the OS should ensure that IP addresses regularly change to limit IP tracking by a passive observer. The application should regularly set the On Demand flag. The application should be able to ensure that session lasting IP addresses are regularly changed by setting a lifetime for example handled by the application. In addition, the application should consider the use of graceful replacement IP addresses. Similarly, the OS may also associated IP addresses with a lifetime. Upon receiving a request for a given type of IP address, after some time, the OS should request a new address to the network even if it already has one IP address available with the requested type. This includes any type of IP address. IP addresses of type graceful replacement or non persistent should be regularly renewed by the OS. The lifetime of an IP address may be expressed in number of seconds or in number of bytes sent through this IP address. Yegin, et al. Expires January 31, 2020 [Page 9] Internet-Draft On Demand Mobility July 2019 6. IANA Considerations This document has no IANA considerations. 7. Contributors This document was merged with [I-D.sijeon-dmm-use-cases-api-source]. We would like to acknowledge the contribution of the following people to that document as well: Sergio Figueiredo Altran Research, France Email: sergio.figueiredo@altran.com Younghan Kim Soongsil University, Korea Email: younghak@ssu.ac.kr John Kaippallimalil Huawei, USA Email: john.kaippallimalil@huawei.com 8. Acknowledgements We would like to thank Wu-chi Feng, Alexandru Petrescu, Jouni Korhonen, Sri Gundavelli, Dave Dolson Lorenzo Colitti and Daniel Migault for their valuable comments and suggestions on this work. 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, . [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Yegin, et al. Expires January 31, 2020 [Page 10] Internet-Draft On Demand Mobility July 2019 9.2. Informative References [I-D.sijeon-dmm-use-cases-api-source] Jeon, S., Figueiredo, S., Kim, Y., and J. Kaippallimalil, "Use Cases and API Extension for Source IP Address Selection", draft-sijeon-dmm-use-cases-api-source-07 (work in progress), September 2017. [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, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5563] Leung, K., Dommety, G., Yegani, P., and K. Chowdhury, "WiMAX Forum / 3GPP2 Proxy Mobile IPv4", RFC 5563, DOI 10.17487/RFC5563, February 2010, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [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, . [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . Appendix A. Conveying the Desired Address Type Following are some suggestions of possible extensions to the Socket API for enabling applications to convey their session continuity and address reachability requirements. Yegin, et al. Expires January 31, 2020 [Page 11] Internet-Draft On Demand Mobility July 2019 [RFC5014] introduced the ability of applications to influence the source address selection with the IPV6_ADDR_PREFERENCE option at the IPPROTO_IPV6 level. This option is used with setsockopt() and getsockopt() calls to set/get address selection preferences. One alternative is to extend the defintion of the IPV6_ADDR_REFERENCE opion with flags that express the invoker's desire. An "OnDeman" field could contains one of the values: FIXED_IP_ADDRESS, SESSION_LASTING_IP_ADDRESS, NON_PERSISTENT_IP_ADDRESS or GRACEFUL_REPLACEMENT_IP_ADDRESS. Another alternative is to define a new Socket function used by the invoker to convey its desire. This enables the implementation of two behaviors of Socket functions: The existing "setsockotp()" is a function that returns after executing, and the new "setsc()" (Set Service Contionuity) function that may initaite a request for the desired service, and wait until the network responds with the allocated resources, before returning to the invoker. After obtaining an IP address with the desired behavior the application can call the bind() Socket function to associate that received IP address with the socket. Authors' Addresses Alper Yegin Actility Istanbul Turkey Email: alper.yegin@actility.com Danny Moses Intel Corporation Petah Tikva Israel Email: danny.moses@intel.com Seil Jeon Sungkyunkwan University Suwon South Korea Email: seiljeon@skku.edu Yegin, et al. Expires January 31, 2020 [Page 12] ./draft-ietf-avtcore-multi-media-rtp-session-13.txt0000644000764400076440000011400712635025637021524 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-curdle-ssh-curves-12.txt0000644000764400076440000003356513534220231016740 0ustar iustyiusty Internet Engineering Task Force A. Adamantiadis Internet-Draft libssh Intended status: Standards Track S. Josefsson Expires: March 7, 2020 SJD AB M. Baushke Juniper Networks, Inc. September 4, 2019 Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 draft-ietf-curdle-ssh-curves-12 Abstract This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) 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 https://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 7, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Adamantiadis, et al. Expires March 7, 2020 [Page 1] Internet-Draft Curve25519/448 for SSH September 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 2 3.1. Shared Secret Encoding . . . . . . . . . . . . . . . . . 3 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Secure Shell (SSH) [RFC4251] is a secure remote login protocol. The key exchange protocol described in [RFC4253] supports an extensible set of methods. [RFC5656] defines how elliptic curves are integrated into this extensible SSH framework, and this document reuses the Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol messages defined in section 7.1 "ECDH Message Numbers" [RFC5656]. Other parts of [RFC5656], such as Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) are not considered in this document. This document describes how to implement key exchange based on Curve25519 and Curve448 [RFC7748] in SSH. For Curve25519 with SHA-256 [RFC6234] and [SHS], the algorithm described is equivalent to the privately defined algorithm "curve25519-sha256@libssh.org", which at the time of publication was implemented and widely deployed in libssh [libssh] and OpenSSH [OpenSSH]. The Curve448 key exchange method is similar but uses SHA-512 [RFC6234] and [SHS]. 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Key Exchange Methods The key exchange procedure is similar to the ECDH method described in chapter 4 of [RFC5656], though with a different wire encoding used for public values and the final shared secret. Public ephemeral keys are encoded for transmission as standard SSH strings. Adamantiadis, et al. Expires March 7, 2020 [Page 2] Internet-Draft Curve25519/448 for SSH September 2019 The protocol flow, the SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange hash are identical to chapter 4 of [RFC5656]. The method names registered by this document are "curve25519-sha256" and "curve448-sha512". The methods are based on Curve25519 and Curve448 scalar multiplication, as described in [RFC7748]. Private and public keys are generated as described therein. Public keys are defined as strings of 32 bytes for Curve25519 and 56 bytes for Curve448. Key-agreement schemes "curve25519-sha256" and "curve448-sha512" perform the Diffie-Hellman protocol using the functions X25519 and X448, respectively. Implementations SHOULD compute these functions using the algorithms described in [RFC7748]. When they do so, implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. Alternative implementations of these functions SHOULD abort when either input forces the shared secret to one of a small set of values, as described in Section 7 of [RFC7748]. Clients and servers MUST also abort if the length of the received public keys are not the expected lengths. An abort for these purposes is defined as a disconnect (SSH_MSG_DISCONNECT) of the session and SHOULD use the SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message [IANA-REASON]. No further validation is required beyond what is described in [RFC7748]. The derived shared secret is 32 bytes when "curve25519-sha256" is used and 56 bytes when "curve448-sha512" is used. The encodings of all values are defined in [RFC7748]. The hash used is SHA-256 for "curve25519-sha256" and SHA-512 for "curve448-sha512". 3.1. Shared Secret Encoding The following step differs from [RFC5656], which uses a different conversion. This is not intended to modify that text generally, but only to be applicable to the scope of the mechanism described in this document. The shared secret, K, is defined in [RFC4253] and [RFC5656] as an integer encoded as a multiple precision integer (mpint). Curve25519/448 outputs a binary string X, which is the 32 or 56 byte point obtained by scalar multiplication of the other side's public key and the local private key scalar. The 32 or 56 bytes of X are converted into K by interpreting the octets as an unsigned fixed- length integer encoded in network byte order. Adamantiadis, et al. Expires March 7, 2020 [Page 3] Internet-Draft Curve25519/448 for SSH September 2019 The integer K is then encoded as an mpint using the process described in section 5 of [RFC4251] and the resulting bytes are fed as described in [RFC4253] to the key exchange method's hash function to generate encryption keys. When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fixed-length unsigned little-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH function in SSH that the bytes are re-interpreted as a fixed-length unsigned big- endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. The mpint K is then fed along with other data to the key exchange method's hash function to generate encryption keys. 4. Acknowledgements The "curve25519-sha256" key exchange method is identical to the "curve25519-sha256@libssh.org" key exchange method created by Aris Adamantiadis and implemented in libssh and OpenSSH. Thanks to the following people for review and comments: Denis Bider, Damien Miller, Niels Moeller, Matt Johnston, Eric Rescorla, Ron Frederick, Stefan Buehler. 5. Security Considerations The security considerations of [RFC4251], [RFC5656], and [RFC7748] are inherited. Curve25519 with SHA-256 provides strong (~128 bits) security and is efficient on a wide range of architectures, and has properties that allows better implementation properties compared to traditional elliptic curves. Curve448 with SHA-512 provides stronger (~224 bits) security with similar implementation properties, but has not received the same cryptographic review as Curve25519, and is slower (larger key material and larger secure hash algorithm), but it is provided as a hedge to combat unforeseen analytical advances against Curve25519 and SHA-256 due to the larger number of security bits. The way the derived binary secret string is encoded into a mpint before it is hashed (i.e., adding or removing zero-bytes for encoding) raises the potential for a side-channel attack which could determine the length of what is hashed. This would leak the most significant bit of the derived secret, and/or allow detection of when the most significant bytes are zero. For backwards compatibility reasons it was decided not to address this potential problem. Adamantiadis, et al. Expires March 7, 2020 [Page 4] Internet-Draft Curve25519/448 for SSH September 2019 This document provides "curve25519-sha256" as the preferred choice, but suggests that the "curve448-sha512" is implemented to provide more than 128 bits of security strength should that become a requirement. 6. IANA Considerations IANA is requested to add "curve25519-sha256" and "curve448-sha512" to the "Key Exchange Method Names" registry for SSH [IANA-KEX] that was created in RFC 4250 section 4.10 [RFC4250]. 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, . [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SHS] Information Technology Laboratory National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, . Adamantiadis, et al. Expires March 7, 2020 [Page 5] Internet-Draft Curve25519/448 for SSH September 2019 7.2. Informative References [IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell (SSH) Protocol Parameters: Key Exchange Method Names", August 2019, . [IANA-REASON] Internet Assigned Numbers Authority (IANA), "Secure Shell (SSH) Protocol Parameters: Disconnection Messages Reason Codes and Descriptions", August 2019, . [libssh] libssh, "The SSH Library", September 2019, . [OpenSSH] OpenSSH group of OpenBSD, "The OpenSSH Project", September 2019, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . Authors' Addresses Aris Adamantiadis libssh Email: aris@badcode.be Simon Josefsson SJD AB Email: simon@josefsson.org Mark D. Baushke Juniper Networks, Inc. Email: mdb@juniper.net Adamantiadis, et al. Expires March 7, 2020 [Page 6] ./index.html0000644000764400076440000016561513555642745012402 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


./draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt0000644000764400076440000013226012665667627023012 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-mmusic-dtls-sdp-32.txt0000644000764400076440000016124613175541414016421 0ustar iustyiusty Network Working Group C. Holmberg Internet-Draft Ericsson Updates: 5763,7345 (if approved) R. Shpount Intended status: Standards Track TurboBridge Expires: May 2, 2018 October 29, 2017 Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) draft-ietf-mmusic-dtls-sdp-32.txt Abstract This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFC 4145 and RFC 8122. 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 https://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 2, 2018. Holmberg & Shpount Expires May 2, 2018 [Page 1] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 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 (https://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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Establishing a new DTLS Association . . . . . . . . . . . . . 4 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Change of Local Transport Parameters . . . . . . . . . . 5 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 5 4. SDP tls-id Attribute . . . . . . . . . . . . . . . . . . . . 5 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 10 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14 9.2.1. Update to section 1 . . . . . . . . . . . . . . . . . 14 9.2.2. Update to section 5 . . . . . . . . . . . . . . . . . 15 9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16 9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17 9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17 9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17 9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 Holmberg & Shpount Expires May 2, 2018 [Page 2] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction [RFC5763] defines Session Description Protocol (SDP) offer/answer procedures for Secure Realtime Transport Protocol Using Datagram Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/ answer procedures for UDP Transport Layer over Datagram Transport Layer Security (UDPTL-DTLS). This specification defines general offer/answer procedures for DTLS, based on the procedures in [RFC5763]. Other specifications, defining specific DTLS usages, can then reference this specification, in order to ensure that the DTLS aspects are common among all usages. Having common procedures is essential when multiple usages share the same DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. The document updates [RFC5763] and [RFC7345], by replacing common SDP offer/answer procedures with a reference to this specification. NOTE: Since the publication of [RFC5763], [RFC4474] has been obsoleted by [I-D.ietf-stir-rfc4474bis]. The updating of the references (and the associated procedures) within [RFC5763] is outside the scope of this document. However, implementers of [RFC5763] applications are encouraged to implement [I-D.ietf-stir-rfc4474bis] instead of [RFC4474]. As defined in [RFC5763], a new DTLS association MUST be established when transport parameters are changed. Transport parameter change is not well defined when Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a transport change is based on ufrag [I-D.ietf-ice-rfc5245bis] change, but the ufrag value is changed both when ICE is negotiated and when ICE restart [I-D.ietf-ice-rfc5245bis] occurs. These events do not always require a new DTLS association to be established, but previously there was no way to explicitly indicate in an SDP offer or answer whether a new DTLS association is required. To solve that problem, this document defines a new SDP attribute, 'tls-id'. The pair of SDP 'tls-id' attribute values (the attribute values of the offerer and the answerer) uniquely identifies the DTLS association. Providing a new value of the 'tls-id' attribute in an SDP offer or answers can be used to indicate whether a new DTLS association is to be established. The SDP 'tls-id' attribute can be specified when negotiating a Transport Layer Security (TLS) connection, using the procedures in this document in conjunction with the procedures in [RFC5763] and Holmberg & Shpount Expires May 2, 2018 [Page 3] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 [RFC8122]. The unique combination of SDP 'tls-id' attribute values can be used to identity the negotiated TLS connection. The unique value can be used, for example, within TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/answer exchanges. The TLS specific considerations are described in Section 7. 2. Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Establishing a new DTLS Association 3.1. General A new DTLS association must be established between two endpoints after a successful SDP offer/answer exchange in the following cases: o The negotiated DTLS setup roles change; or o One or more fingerprint values are modified, added or removed in either an SDP offer or answer; or o The intent to establish a new DTLS association is explicitly signaled using SDP, by changing the value of the SDP 'tls-id' attribute defined in this document; NOTE: The first two items above are based on the procedures in [RFC5763]. This specification adds the support for explicit signaling using the SDP 'tls-id' attribute. A new DTLS association can only be established as a result of the successful SDP offer/answer exchange. Whenever an entity determines that a new DTLS association is required, the entity MUST initiate an SDP offer/answer exchange, following the procedures in Section 5. The sections below describe typical cases where a new DTLS association needs to be established. In this document, a "new DTLS association" between two endpoints refers to either an initial DTLS association (when no DTLS association is currently established between the endpoints) or an DTLS association replacing a previously established DTLS association. Holmberg & Shpount Expires May 2, 2018 [Page 4] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 3.2. Change of Local Transport Parameters If an endpoint modifies its local transport parameters (address and/ or port), and if the modification requires a new DTLS association, the endpoint MUST change its local SDP 'tls-id' attribute value (see Section 4). If the underlying transport protocol prohibits a DTLS association from spanning multiple 5-tuples (transport/source address/source port/destination address/destination port), and if the 5-tuple is changed, the endpoint MUST change its local SDP 'tls-id' attribute value (see Section 4). An example of such a case is when DTLS is carried over the Stream Control Transmission Protocol (SCTP), as described in [RFC6083]. 3.3. Change of ICE ufrag value If an endpoint uses ICE, and modifies a local ufrag value, and if the modification requires a new DTLS association, the endpoint MUST change its local SDP 'tls-id' attribute value (see Section 4). 4. SDP tls-id Attribute The pair of SDP 'tls-id' attribute values (the attribute values of the offerer and the answerer) uniquely identifies the DTLS association or TLS connection. Holmberg & Shpount Expires May 2, 2018 [Page 5] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Name: tls-id Value: tls-id-value Usage Level: media Charset Dependent: no Default Value: N/A Syntax: tls-id-value = 20*255(tls-id-char) tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" Example: a=tls-id:abc3de65cddef001be82 Every time an endpoint requests to establish a new DTLS association, the endpoint MUST generate a new local 'tls-id' attribute value. A non-changed local 'tls-id' attribute value, in combination with non- changed fingerprints, indicates that the endpoint intends to reuse the existing DTLS association. The 'tls-id' attribute value MUST be generated using a strong random function and include at least 120 bits of randomness. No default value is defined for the SDP 'tls-id' attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain a 'tls-id' attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the 'tls-id' attribute), unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, a modification of one or more of the following characteristics MUST be treated as an indication that an endpoint wants to establish a new DTLS association: o DTLS setup role; or o fingerprint set; or o local transport parameters Holmberg & Shpount Expires May 2, 2018 [Page 6] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 NOTE: A modification of the ufrag value is not treated as an indication that an endpoint wants to establish a new DTLS assocation. In order to indicate that a new DTLS association is to be established, one or more of the characteristics listed above have to be modified. The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- id' attribute is 'IDENTICAL', which means that the attribute value applies to all media descriptions being multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], in order to avoid duplication the attribute is only associated with the "m=" line representing the offerer/answerer BUNDLE-tag. For RTP-based media, the 'tls-id' 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 5. 5. SDP Offer/Answer Procedures 5.1. General This section defines the generic SDP offer/answer procedures for negotiating a DTLS association. Additional procedures (e.g., regarding usage of specific SDP attributes etc.) for individual DTLS usages (e.g., DTLS-SRTP) are outside the scope of this specification, and need to be specified in a usage specific specification. NOTE: The procedures in this section are generalizations of procedures first specified in DTLS-SRTP [RFC5763], with the addition of usage of the SDP 'tls-id' attribute. That document is herein updated to make use of these new procedures. The procedures in this section apply to an SDP media description ("m=" line) associated with DTLS-protected media/data. When an offerer or answerer indicates that it wants to establish a new DTLS association, it needs to make sure that media packets associated with any previously established DTLS association and the new DTLS association can be de-multiplexed. In case of an ordered transport (e.g., SCTP) this can be done simply by sending packets for the new DTLS association after all packets associated with a previously established DTLS association has been sent. In case of an unordered transport, such as UDP, packets associated with a previously established DTLS association can arrive after the answer Holmberg & Shpount Expires May 2, 2018 [Page 7] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 SDP was received and after the first packets associated with the new DTLS association were received. The only way to de-multiplex packets associated with with a previously established DTLS association and the new DTLS association is on the basis of the 5-tuple. Because of this, if an unordered transport is used for the DTLS association, a new 3-tuple (transport/source address/source port) MUST be allocated by at least one of the endpoints so that DTLS packets can be de- multiplexed. When an offerer needs to establish a new DTLS association, and if an unordered transport (e.g., UDP) is used, the offerer MUST allocate a new 3-tuple for the offer in such a way that the offerer can disambiguate any packets associated with the new DTLS association from any packets associated with any other DTLS association. This typically means using a local address and/or port, or a set of ICE candidates (see Section 6), which were not recently used for any other DTLS association. When an answerer needs to establish a new DTLS association, if an unordered transport is used, and if the offerer did not allocate a new 3-tuple, the answerer MUST allocate a new 3-tuple for the answer in such a way that it can disambiguate any packets associated with the new DTLS association from any packets associated with any other DTLS association. This typically means using a local address and/or port, or a set of ICE candidates (see Section 6), which were not recently used for any other DTLS association. In order to negotiate a DTLS association, the following SDP attributes are used: o The SDP 'setup' attribute, defined in [RFC4145], is used to negotiate the DTLS roles; o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to provide one or more fingerprint values; and o The SDP 'tls-id' attribute, defined in this specification, is used to identity the DTLS association. This specification does not define the usage of the SDP 'connection' attribute [RFC4145] for negotiating a DTLS association. However, the attribute MAY be used if the DTLS association is used together with another protocol (e.g., SCTP or TCP) for which the usage of the attribute has been defined. Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 'setup' attribute 'holdconn' value when negotiating a DTLS association. Holmberg & Shpount Expires May 2, 2018 [Page 8] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Endpoints MUST support the hash functions as defined in [RFC8122]. The certificate received during the DTLS handshake [RFC6347] MUST match a certificate fingerprint received in SDP 'fingerprint' attributes according to the procedures defined in [RFC8122]. If fingerprints do not match the hashed certificate, then an endpoint MUST tear down the media session immediately (see [RFC8122]). SDP offerers and answerers might reuse certificates across multiple DTLS associations, and provide identical fingerprint values for each DTLS association. The combination of the SDP 'tls-id' attribute values of the SDP offerer and answerer identifies each individual DTLS association. NOTE: There are cases where the SDP 'tls-id' attribute value generated by the offerer will end up being used for multiple DTLS associations. For that reason the combination of the attribute values of the offerer and answerer is needed in order to identity a DTLS association. An example of such case is where the offerer sends an updated offer (Section 5.5), without modifying its attribute value, but the answerer determines that a new DTLS association is to be created. The answerer will generate a new local attribute value for the new DTLS association (Section 5.3), while the offerer will use the same attribute value that it used for the current association. Another example is when the Session Initiation Protocol (SIP) [RFC3261] is used for signalling, and an offer is forked to multiple answerers. The attribute value generated by the offerer will be used for DTLS associations established by each answerer. 5.2. Generating the Initial SDP Offer When an offerer sends the initial offer, the offerer MUST insert an SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique attribute value. As the offerer inserts the SDP 'setup' attribute with an 'actpass' attribute value, the offerer MUST be prepared to receive a DTLS ClientHello message [RFC6347] (if a new DTLS association is established by the answerer) from the answerer before the offerer receives the SDP answer. If the offerer receives a DTLS ClientHello message, and a DTLS association is established, before the offerer receives the SDP Answer carrying the fingerprint associated with the DTLS association, any data received on the DTLS association before the fingerprint MUST be considered coming from an unverified source. The processing of Holmberg & Shpount Expires May 2, 2018 [Page 9] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 such data, and sending of data by the offerer to the unverified source, is outside the scope of this document. 5.3. Generating the Answer When an answerer sends an answer, the answerer MUST insert in the answer an SDP 'setup' attribute according to the procedures in [RFC4145], and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. If the answerer determines, based on the criteria specified in Section 3.1, that a new DTLS association is to be established, the answerer MUST insert in the associated answer an SDP 'tls-id' attribute with a new unique attribute value. Note that the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association. If the answerer receives an offer that requires establishment of a new DTLS association, and if the answerer does not accept the establishment of a new DTLS association, the answerer MUST reject the "m=" lines associated with the suggested DTLS association [RFC3264]. If an answerer receives an offer that does not require the establishment of a new DTLS association, and if the answerer determines that a new DTLS association is not to be established, the answerer MUST insert an SDP 'tls-id' attribute with the previously assigned attribute value in the associated answer. In addition, the answerer MUST insert an SDP 'setup' attribute with an attribute value that does not change the previously negotiated DTLS roles, and one or more SDP 'fingerprint' attributes values that do not change the previously sent fingerprint set, in the associated answer. If the answerer receives an offer that does not contain an SDP 'tls- id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in the answer. If a new DTLS association is to be established, and if the answerer inserts an SDP 'setup' attribute with an 'active' attribute value in the answer, the answerer MUST initiate a DTLS handshake [RFC6347]) by sending a DTLS ClientHello message towards the offerer. Even though an offerer is required to insert an 'SDP' setup attribute with an 'actpass' attribute value in initial offers (Section 5.2) and subsequent offers (Section 5.5), the answerer MUST be able to receive initial and subsequent offers with other attribute values, in order to be backward compatible with older implementations that might insert other attribute values in initial and subsequent offers. Holmberg & Shpount Expires May 2, 2018 [Page 10] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 5.4. Offerer Processing of the SDP Answer When an offerer receives an answer that establishes a new DTLS association based on criteria defined in Section 3.1, and if the offerer becomes DTLS client (based on the value of the SDP 'setup' attribute value [RFC4145]), the offerer MUST establish a DTLS association. If the offerer becomes DTLS server, it MUST wait for the answerer to establish the DTLS association. If the offerer indicated a desire to reuse an existing DTLS association and the answerer does not request the establishment of a new DTLS association, the offerer will continue to use the previously established DTLS association. A new DTLS association can be established based on changes in either an SDP offer or answer. When communicating with legacy endpoints, an offerer can receive an answer that includes the same fingerprint set and setup role. A new DTLS association will still be established if such an answer was received as a response to an offer which requested the establishment of a new DTLS association, as the transport parameters would have been changed in the offer. 5.5. Modifying the Session When an offerer sends a subsequent offer, and if the offerer wants to establish a new DTLS association, the offerer MUST insert an SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a new unique attribute value. When an offerer sends a subsequent offer, and the offerer does not want to establish a new DTLS association, and if a previously established DTLS association exists, the offerer MUST insert an SDP 'setup' attribute with an 'actpass' attribute value, and one or more SDP 'fingerprint' attributes with attribute values that do not change the previously sent fingerprint set, in the offer. In addition, the offerer MUST insert an SDP 'tls-id' attribute with the previously assigned attribute value in the offer. NOTE: When a new DTLS association is being established, each endpoint needs to be prepared to receive data on both the new and old DTLS associations as long as both are alive. Holmberg & Shpount Expires May 2, 2018 [Page 11] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 6. ICE Considerations When the Interactive Connectivity Establishment (ICE) mechanism [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. NOTE: Aggressive nomination has been deprecated from ICE, but must still be supported for backwards compatibility reasons [I-D.ietf-ice-rfc5245bis]. When a new DTLS association is established over an unordered transport, in order to disambiguate any packets associated with the newly established DTLS association, at least one of the endpoints MUST allocate a completely new set of ICE candidates which were not recently used for any other DTLS association. This means the answerer cannot initiate a new DTLS association unless the offerer initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer wants to initiate a new DTLS association, it needs to initiate an ICE restart and a new offer/answer exchange on its own. However, an ICE restart does not by default require a new DTLS association to be established. NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets are sent directly over UDP, not over DTLS. [RFC7983] describes how to demultiplex STUN packets from DTLS packets and SRTP packets. Each ICE candidate associated with a component is treated as being part of the same DTLS association. Therefore, from a DTLS perspective it is not considered a change of local transport parameters when an endpoint switches between those ICE candidates. 7. TLS Considerations The procedures in this document can also be used for negotiating and establishing a TLS connection, with the restriction described below. As specified in [RFC4145], the SDP 'connection' attribute is used to indicate whether to establish a new TLS connection. An offerer and answerer MUST ensure that the 'connection' attribute value and the 'tls-id' attribute value does not cause a conflict regarding whether a new TLS connection is to be established or not. NOTE: Even though the SDP 'connection' attribute can be used to indicate whether a new TLS connection is to be established, the unique combination of SDP 'tls-id' attribute values can be used to identity a TLS connection. The unique value can be used e.g., within Holmberg & Shpount Expires May 2, 2018 [Page 12] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/ answer exchanges. One such extension is defined in [I-D.ietf-mmusic-sdp-uks]. If an offerer or answerer inserts an SDP 'connection' attribute with a 'new' value in the offer/answer and also inserts an SDP 'tls-id' attribute, the value of tls-id' attribute MUST be new and unique. If an offerer or answerer inserts an SDP 'connection' attribute with a 'existing' value in the offer/answer, if a previously established TLS connection exists, and if the offerer/answerer previously inserted an SDP 'tls-id' attribute associated with the same TLS connection in an offer/answer, the offerer/answerer MUST also insert an SDP 'tls-id' attribute with the previously assigned value in the offer/answer. If an offerer or answerer receives an offer/answer with conflicting attribute values, the offerer/answerer MUST process the offer/answer as misformed. An endpoint MUST NOT make assumptions regarding the support of the SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, both offerers and answerers MUST always use the 'connection' attribute in conjunction with the 'tls-id' attribute. NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is not explicitly present, the implicit default value is 'new'. The SDP example below is based on the example in section 3.4 of [RFC8122], with the addition of the SDP 'tls-id' attribute. m=image 54111 TCP/TLS t38 c=IN IP4 192.0.2.2 a=tls-id:abc3de65cddef001be82 a=setup:passive a=connection:new a=fingerprint:SHA-256 \ 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 3E:5D:49:6B:19:E5:7C:AB:4A:AD a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB Holmberg & Shpount Expires May 2, 2018 [Page 13] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 8. SIP Considerations When the Session Initiation Protocol (SIP) [RFC3261] is used as the signal protocol for establishing a multimedia session, dialogs [RFC3261] might be established between the caller and multiple callees. This is referred to as forking. If forking occurs, separate DTLS associations will be established between the caller and each callee. When forking occurs, an SDP offerer can receive DTLS ClientHello messages and SDP answerers from multiple remote locations. Because of this, the offerer might have to wait for multiple SDP answers (from different remote locations) until it receives a certificate fingerprint that matches the certificate associated with a specific DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch until it determines that it will not receive SDP answers from any additional remote locations. It is possible to send an INVITE request which does not contain an SDP offer. Such an INVITE request is often referred to as an 'empty INVITE', or an 'offer-less INVITE'. The receiving endpoint will include the SDP offer in a response to the request. When the endpoint generates such SDP offer, if a previously established DTLS association exists, the offerer MUST insert an SDP 'tls-id' attribute, and one or more SDP 'fingerprint' attributes, with previously assigned attribute values. If a previously established DTLS association did not exist, the offer MUST be generated based on the same rules as a new offer (see Section 5.2). Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145]. Furthermore, if ICE is used, according to the third party call control considerations described in [I-D.ietf-mmusic-ice-sip-sdp], ICE restart MUST be initiated. 9. RFC Updates 9.1. General This section updates specifications that use DTLS-protected media, in order to reflect the procedures defined in this specification. 9.2. Update to RFC 5763 9.2.1. Update to section 1 The reference to [RFC4572] is replaced with a reference to [RFC8122]. Holmberg & Shpount Expires May 2, 2018 [Page 14] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 9.2.2. Update to section 5 The text in section 5 (Establishing a Secure Channel) is modified by replacing generic SDP offer/answer procedures for DTLS with a reference to this specification: NEW TEXT: The two endpoints in the exchange present their identities as part of the DTLS handshake procedure using certificates. This document uses certificates in the same style as described in "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC8122]. If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the uniform resource identifier (URI) of the user. This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. The integrity of the certificate is ensured through the fingerprint attribute in the SDP. The generation of public/private key pairs is relatively expensive. Endpoints are not required to generate certificates for each session. The offer/answer model, defined in [RFC3264], is used by protocols like the Session Initiation Protocol (SIP) [RFC3261] to set up multimedia sessions. When an endpoint wishes to set up a secure media session with another endpoint, it sends an offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, a fingerprint of a certificate that the endpoint wants to use. The endpoint SHOULD send the SIP message containing the offer to the offerer's SIP proxy over an integrity protected channel. The proxy SHOULD add an Identity header field according to the procedures outlined in [RFC4474]. When the far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header field. Since the Identity header field is a digital signature across several SIP header fields, in addition to the body of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was applied and added to the SIP message. The far endpoint (answerer) may now establish a DTLS association with the offerer. Alternately, it can indicate in its answer that the offerer is to initiate the DTLS association. In either case, mutual DTLS certificate-based authentication will be used. After completing Holmberg & Shpount Expires May 2, 2018 [Page 15] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 the DTLS handshake, information about the authenticated identities, including the certificates, are made available to the endpoint application. The answerer is then able to verify that the offerer's certificate used for authentication in the DTLS handshake can be associated to a certificate fingerprint contained in the offer in the SDP. At this point, the answerer may indicate to the end user that the media is secured. The offerer may only tentatively accept the answerer's certificate since it may not yet have the answerer's certificate fingerprint. When the answerer accepts the offer, it provides an answer back to the offerer containing the answerer's certificate fingerprint. At this point, the offerer can accept or reject the peer's certificate and the offerer can indicate to the end user that the media is secured. Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. The signaling path is only used to verify the peers' certificate fingerprints. The offerer and answerer MUST follow the SDP offer/answer procedures defined in [RFCXXXX]. 9.2.3. Update to section 6.6 The text in section 6.6 (Session Modification) is modified by replacing generic SDP offer/answer procedures for DTLS with a reference to this specification: NEW TEXT: Once an answer is provided to the offerer, either endpoint MAY request a session modification that MAY include an updated offer. This session modification can be carried in either an INVITE or UPDATE request. The peers can reuse an existing DTLS association, or establish a new one, following the procedures in [RFCXXXX]. 9.2.4. Update to section 6.7.1 The text in section 6.7.1 (ICE Interaction) is modified by replacing the ICE procedures with a reference to this specification: Holmberg & Shpount Expires May 2, 2018 [Page 16] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 NEW TEXT: The Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media are described in [RFCXXXX]. 9.3. Update to RFC 7345 9.3.1. Update to section 4 The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer Procedures) are removed, and replaced with the new text below: NEW TEXT: An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each UDPTL-over-DTLS media stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the "proto" field of the "m=" line. The offerer and answerer MUST follow the SDP offer/answer procedures defined in [RFCXXXX] in order to negotiate the DTLS association associated with the UDPTL-over-DTLS media stream. In addition, the offerer and answerer MUST use the SDP attributes defined for UDPTL over UDP, as defined in [ITU.T38.2010]. 9.3.2. Update to section 5.2.1 The text in section 5.2.1 (ICE Usage) is modified by replacing the ICE procedures with a reference to this specification: NEW TEXT: The Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media are described in [RFCXXXX]. [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX with the RFC number of this document.] Holmberg & Shpount Expires May 2, 2018 [Page 17] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 9.3.3. Update to section 10.1 A reference to [RFC8122] is added to section 10.1 (Normative References): NEW TEXT: [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . 10. Security Considerations This specification does not modify the security considerations associated with DTLS, or the SDP offer/answer mechanism. In addition to the introduction of the SDP 'tls-id' attribute, the specification simply clarifies the procedures for negotiating and establishing a DTLS association. This specification does not modify the actual TLS connection setup procedures. The SDP 'tls-is' attribute as such cannot be used to correlate an SDP Offer/Answer exchange with a TLS connection setup. Thus, this draft does not introduce new security considerations related to correlating an SDP Offer/Answer exchange with a TLS connection setup. 11. 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 'tls-id' attribute to the table for SDP media level attributes. Attribute name: tls-id Type of attribute: media-level Subject to charset: no Purpose: Indicates whether a new DTLS association or TLS connection is to be established/re-established. Appropriate Values: see Section 4 Contact name: Christer Holmberg Mux Category: IDENTICAL Holmberg & Shpount Expires May 2, 2018 [Page 18] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 12. Acknowledgements Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing comments and suggestions on the document. Ben Campbell performed an AD review. Paul Kyzivat performed a gen-art review. 13. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-sdp-dtls-31 o Changes based on IESG comments from Eric R Changes from draft-ietf-mmusic-sdp-dtls-30 o Changes based on IESG comments from Mirja K Changes from draft-ietf-mmusic-sdp-dtls-29 o Removal of ufrag value change as a trigger for a new DTLS association Changes from draft-ietf-mmusic-sdp-dtls-28 o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey Melnikov and Mirja Kuhlewind: o - Document title changed o - Transport Protocol Considerations section removed o - Additional text to Security Considerations section o - Editorial changes Changes from draft-ietf-mmusic-sdp-dtls-27 o Reference fixes based on Gen-ART review by Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-26 o Editorial fixes based on Gen-ART review by Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-25 o Minor editorial nits. Holmberg & Shpount Expires May 2, 2018 [Page 19] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Changes from draft-ietf-mmusic-sdp-dtls-24 o Changes based on 2nd WGLC comments from Roman S and Martin T: o - RFC update structure shortened (old text removed). o - Guidance regarding receiving ClientHello before SDP answer added. o - Additional SIP considerations regarding forking. o - SDP setup attribute value restriction in initial and subsequent offers based on comment from Ekr. Changes from draft-ietf-mmusic-sdp-dtls-23 o Editorial change to make it clear that the document does not modify the procedures in RFC 8122. Changes from draft-ietf-mmusic-sdp-dtls-22 o Support for TLS added. o Editorial changes based on sec-dir review by Rich Salz. o Editorial changes based on gen-art review by Paul Kyzivat. o Editorial changes based on ops-dir review by Carlos Pignataro. Changes from draft-ietf-mmusic-sdp-dtls-21 o Changes based on AD review by Ben Campbell. o (https://www.ietf.org/mail-archive/web/mmusic/current/ msg17707.html) Changes from draft-ietf-mmusic-sdp-dtls-20 o Change to length and randomness of tls-id attribute value. Changes from draft-ietf-mmusic-sdp-dtls-19 o Change based on comment from Roman. Changes from draft-ietf-mmusic-sdp-dtls-18 o Changes based on comments from Flemming. Holmberg & Shpount Expires May 2, 2018 [Page 20] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 o - Change in tls-id value definition. o - Editorial fixes. Changes from draft-ietf-mmusic-sdp-dtls-17 o Reference fix. Changes from draft-ietf-mmusic-sdp-dtls-16 o Editorial changes based on 2nd WGLC comments from Christian Groves and Nevenka Biondic. Changes from draft-ietf-mmusic-sdp-dtls-15 o tls-id attribute value made globally unique Changes from draft-ietf-mmusic-sdp-dtls-14 o Changes based on comments from Flemming: o - Additional dtls-is clarifications o - Editorial fixes Changes from draft-ietf-mmusic-sdp-dtls-13 o Text about the updated RFCs added to Abstract and Introduction o Reference to RFC 5763 removed from section 6 (ICE Considerations) o Reference to RFC 5763 removed from section 8 (SIP Considerations) Changes from draft-ietf-mmusic-sdp-dtls-12 o "unreliable" changed to "unordered" Changes from draft-ietf-mmusic-sdp-dtls-11 o Attribute name changed to tls-id o Additional text based on comments from Roman Shpount. Changes from draft-ietf-mmusic-sdp-dtls-10 o Modified document to use tls-id instead of dtls-connection Holmberg & Shpount Expires May 2, 2018 [Page 21] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 o Changes are based on comments from Eric Rescorla, Justin Uberti, and Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-08 o Offer/Answer section modified in order to allow sending of multiple SDP 'fingerprint' attributes. o Terminology made consistent: 'DTLS connection' replaced with 'DTLS association'. o Editorial changes based on comments from Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-07 o Reference to RFC 7315 replaced with reference to RFC 7345. Changes from draft-ietf-mmusic-sdp-dtls-06 o Text on restrictions regarding spanning a DTLS association over multiple transports added. o Mux category added to IANA Considerations. o Normative text regarding mux category and source-specific applicability added. o Reference to RFC 7315 added. o Clarified that offerer/answerer that has not been updated to support this specification will not include the tls-id attribute in offers and answers. o Editorial corrections based on WGLC comments from Charles Eckel. Changes from draft-ietf-mmusic-sdp-dtls-05 o Text on handling offer/answer error conditions added. Changes from draft-ietf-mmusic-sdp-dtls-04 o Editorial nits fixed based on comments from Paul Kyzivat: Changes from draft-ietf-mmusic-sdp-dtls-03 o Changes based on comments from Paul Kyzivat: o - Modification of tls-id attribute section. Holmberg & Shpount Expires May 2, 2018 [Page 22] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 o - Removal of IANA considerations subsection. o - Making note into normative text in o/a section. o Changes based on comments from Martin Thompson: o - Abbreviations section removed. o - Clarify that a new DTLS association requires a new o/a transaction. Changes from draft-ietf-mmusic-sdp-dtls-02 o - Updated RFCs added to boilerplate. Changes from draft-ietf-mmusic-sdp-dtls-01 o - Annex regarding 'tls-id-id' attribute removed. o - Additional SDP offer/answer procedures, related to certificates, added. o - Updates to RFC 5763 and RFC 7345 added. o - Transport protocol considerations added. Changes from draft-ietf-mmusic-sdp-dtls-00 o - SDP 'connection' attribute replaced with new 'tls-id' attribute. o - IANA Considerations added. o - E-mail regarding 'tls-id-id' attribute added as Annex. Changes from draft-holmberg-mmusic-sdp-dtls-01 o - draft-ietf-mmusic version of draft submitted. o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision with another expired draft. o - Clarify that if ufrag in offer is unchanged, it must be unchanged in associated answer. o - SIP Considerations section added. o - Section about multiple SDP fingerprint attributes added. Holmberg & Shpount Expires May 2, 2018 [Page 23] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Changes from draft-holmberg-mmusic-sdp-dtls-00 o - Editorial changes and clarifications. 14. References 14.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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [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, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 2014, . Holmberg & Shpount Expires May 2, 2018 [Page 24] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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-13 (work in progress), October 2017. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 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-39 (work in progress), August 2017. 14.2. Informative References [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 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, . [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, . Holmberg & Shpount Expires May 2, 2018 [Page 25] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 [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, . [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, . [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 (work in progress), February 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in progress), October 2017. [I-D.ietf-mmusic-sdp-uks] Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00 (work in progress), August 2017. [ITU.T38.2010] International Telecommunications Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, September 2010. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg & Shpount Expires May 2, 2018 [Page 26] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Roman Shpount TurboBridge 4905 Del Ray Avenue, Suite 300 Bethesda, MD 20814 USA Phone: +1 (240) 292-6632 Email: rshpount@turbobridge.com Holmberg & Shpount Expires May 2, 2018 [Page 27] ./draft-ietf-avtext-lrr-07.txt0000644000764400076440000007633613126302536015507 0ustar iustyiusty Payload Working Group J. Lennox Internet-Draft D. Hong Intended status: Standards Track Vidyo Expires: December 31, 2017 J. Uberti S. Holmer M. Flodman Google June 29, 2017 The Layer Refresh Request (LRR) RTCP Feedback Message draft-ietf-avtext-lrr-07 Abstract This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. 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 31, 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 Lennox, et al. Expires December 31, 2017 [Page 1] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 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, Definitions and Acronyms . . . . . . . . . . . . 2 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 8 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Usage with different scalability transmission mechanisms . . 11 6. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This memo describes an RTCP [RFC3550] Payload-Specific Feedback Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to allow a receiver of a layered media stream to request that one or more of its substreams be refreshed, such that it can then be decoded by an endpoint which previously was not receiving those layers, without requiring that the entire stream be refreshed (as it would be if the receiver sent a Full Intra Request (FIR); [RFC5104] see also [RFC8082]). The feedback message is applicable both to temporally and spatially scaled streams, and to both single-stream and multi-stream scalability modes. 2. Conventions, Definitions and Acronyms 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]. Lennox, et al. Expires December 31, 2017 [Page 2] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 2.1. Terminology A "Layer Refresh Point" is a point in a scalable stream after which a decoder, which previously had been able to decode only some (possibly none) of the available layers of stream, is able to decode a greater number of the layers. For spatial (or quality) layers, in normal encoding, a subpicture can depend both on earlier pictures of that spatial layer and also on lower-layer pictures of the current picture. A layer refresh, however, typically requires that a spatial layer picture be encoded in a way that references only the lower-layer subpictures of the current picture, not any earlier pictures of that spatial layer. Additionally, the encoder must promise that no earlier pictures of that spatial layer will be used as reference in the future. However, even in a layer refresh, layers other than the ones being refreshed may still maintain dependency on earlier content of the stream. This is the difference between a layer refresh and a Full Intra Request [RFC5104]. This minimizes the coding overhead of refresh to only those parts of the stream that actually need to be refreshed at any given time. An illustration of spatial layer refresh of an enhancement layer is shown below. <-- indicates a coding dependency. ... <-- S1 <-- S1 S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... 1 2 3 4 Figure 1 In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a decoder which had previously only been decoding spatial layer S0 would be able to decode layer S1 starting at frame 3. Lennox, et al. Expires December 31, 2017 [Page 3] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 An illustration of spatial layer refresh of a base layer is shown below. <-- indicates a coding dependency. ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 S0 <-- S0 <-- ... 1 2 3 4 Figure 2 In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a decoder which had previously not been decoding the stream at all could decode layer S0 starting at frame 3. For temporal layers, while normal encoding allows frames to depend on earlier frames of the same temporal layer, layer refresh requires that the layer be "temporally nested", i.e. use as reference only earlier frames of a lower temporal layer, not any earlier frames of this temporal layer, and also promise that no future frames of this temporal layer will reference frames of this temporal layer before the refresh point. In many cases, the temporal structure of the stream will mean that all frames are temporally nested, in which case decoders will have no need to send LRR messages for the stream. An illustration of temporal layer refresh is shown below. <-- indicates a coding dependency. ... <----- T1 <------ T1 T1 <------ ... / / / |_ |_ |_ ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 1 2 3 4 5 6 7 Figure 3 In Figure 3, frame 6 is a layer refresh point for temporal layer T1; a decoder which had previously only been decoding temporal layer T0 would be able to decode layer T1 starting at frame 6. Lennox, et al. Expires December 31, 2017 [Page 4] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 An illustration of an inherently temporally nested stream is shown below. <-- indicates a coding dependency. T1 T1 T1 / / / |_ |_ |_ ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 1 2 3 4 5 6 7 Figure 4 In Figure 4, the stream is temporally nested in its ordinary structure; a decoder receiving layer T0 can begin decoding layer T1 at any point. A "Layer Index" is a numeric label for a specific spatial and temporal layer of a scalable stream. It consists of the pair of a "temporal ID" identifying the temporal layer, and a "layer ID" identifying the spatial or quality layer. The details of how layers of a scalable stream are labeled are codec-specific. Details for several codecs are defined in Section 4. 3. Layer Refresh Request A layer refresh frame can be requested by sending a Layer Refresh Request (LRR), which is an RTP Control Protocol (RTCP) [RFC3550] payload-specific feedback message [RFC4585] asking the encoder to encode a frame which makes it possible to upgrade to a higher layer. The LRR contains one or two tuples, indicating the temporal and spatial layer the decoder wants to upgrade to, and (optionally) the currently highest temporal and spatial layer the decoder can decode. The specific format of the tuples, and the mechanism by which a receiver recognizes a refresh frame, is codec-dependent. Usage for several codecs is discussed in Section 4. LRR follows the model of the Full Intra Request (FIR) [RFC5104] (Section 3.5.1) for its retransmission, reliability, and use in multipoint conferences. The LRR message is identified by RTCP packet type value PT=PSFB and FMT=TBD. The FCI field MUST contain one or more LRR entries. Each entry applies to a different media sender, identified by its SSRC. [NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned payload-specific feedback number.] Lennox, et al. Expires December 31, 2017 [Page 5] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 3.1. Message Format The Feedback Control Information (FCI) for the Layer Refresh Request consists of one or more FCI entries, the content of which is depicted in Figure 5. The length of the LRR feedback message MUST be set to 2+3*N 32-bit words, where N is the number of FCI entries. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr. |C| Payload Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TTID| TLID | RES | CTID| CLID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 SSRC (32 bits) The SSRC value of the media sender that is requested to send a layer refresh point. Seq nr. (8 bits) Command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence number SHALL be increased by 1 for each new command (modulo 256, so the value after 255 is 0). A repetition SHALL NOT increase the sequence number. The initial value is arbitrary. C (1 bit) A flag bit indicating whether the "Current Temporal Layer ID (CTID)" and "Current Layer ID (CLID)" fields are present in the FCI. If this bit is 0, the sender of the LRR message is requesting refresh of all layers up to and including the target layer. Payload Type (7 bits) The RTP payload type for which the LRR is being requested. This gives the context in which the target layer index is to be interpreted. Reserved (RES) (three separate fields, 16 bits / 5 bits / 5 bits) All bits SHALL be set to 0 by the sender and SHALL be ignored on reception. Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the target layer for which the receiver wishes a refresh point. Lennox, et al. Expires December 31, 2017 [Page 6] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Target Layer ID (TLID) (8 bits) The layer ID of the target spatial or quality layer for which the receiver wishes a refresh point. Its format is dependent on the payload type field. Current Temporal Layer ID (CTID) (3 bits) If C is 1, the ID of the current temporal layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to 0 by the sender and SHALL be ignored on reception. Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the current spatial or quality layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to 0 by the sender and SHALL be ignored on reception. When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be less than CLID; at least one of TTID or TLID MUST be greater than CTID or CLID respectively. That is to say, the target layer index MUST be a layer upgrade from the current layer index . A sender MAY request an upgrade in both temporal and spatial/quality layers simultaneously. A receiver receiving an LRR feedback packet which does not satisfy the requirements of the previous paragraph, i.e. one where the C bit is present but TTID is less than CTID or TLID is less than CLID, MUST discard the request. Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. 3.2. Semantics Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the LRR command applies are in the corresponding FCI entries. A LRR message MAY contain requests to multiple media senders, using one FCI entry per target media sender. Upon reception of LRR, the encoder MUST send a decoder refresh point (see Section 2.1) as soon as possible. The sender MUST respect bandwidth limits provided by the application of congestion control, as described in Section 5 of [RFC5104]. As layer refresh points will often be larger than non-refreshing frames, Lennox, et al. Expires December 31, 2017 [Page 7] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 this may restrict a sender's ability to send a layer refresh point quickly. LRR MUST NOT be sent as a reaction to picture losses due to packet loss or corruption -- it is RECOMMENDED to use PLI [RFC4585] instead. LRR SHOULD be used only in situations where there is an explicit change in decoders' behavior, for example when a receiver will start decoding a layer which it previously had been discarding. 4. Usage with specific codecs In order for LRR to be used with a scalable codec, the format of the temporal and layer ID fields (for both the target and current layer indices) needs to be specified for that codec's RTP packetization. New RTP packetization specifications for scalable codecs SHOULD define how this is done. (The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.) If the payload also specifies how it is used with the Frame Marking RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax MUST be defined in the same manner as the TID and LID fields in that header. 4.1. H264 SVC H.264 SVC [RFC6190] defines temporal, dependency (spatial), and quality scalability modes. +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |R| DID | QID | +---------------+---------------+ Figure 6 Figure 6 shows the format of the layer index fields for H.264 SVC streams. The "R" and "RES" fields MUST be set to 0 on transmission and ignored on reception. See [RFC6190] Section 1.1.3 for details on the DID, QID, and TID fields. A dependency or quality layer refresh of a given layer in H.264 SVC can be identified by the "I" bit (idr_flag) in the extended NAL unit header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded scalable slice). Layer refresh of the base layer can also be identified by its NAL unit type of its coded slices, which is "5" rather than "1". A dependency or quality layer refresh is complete once this bit has been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index. Lennox, et al. Expires December 31, 2017 [Page 8] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Note that as the "I" bit in a PACSI header is set if the corresponding bit is set in any of the aggregated NAL units it describes; thus, it is not sufficient to identify layer refresh when NAL units of multiple dependency or quality layers are aggregated. In H.264 SVC, temporal layer refresh information can be determined from various Supplemental Encoding Information (SEI) messages in the bitstream. Whether an H.264 SVC stream is scalably nested can be determined from the Scalability Information SEI message's temporal_id_nesting flag. If this flag is set in a stream's currently applicable Scalability Information SEI, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. (The Scalability Information SEI message may also be available in the signaling negotiation of H.264 SVC, as the sprop- scalability-info parameter.) If a stream's temporal_id_nesting flag is not set, the Temporal Level Switching Point SEI message identifies temporal layer switching points. A temporal layer refresh is satisfied when this SEI message is present in a frame with the target layer index, if the message's delta_frame_num refers to a frame with the requested current layer index. (Alternately, temporal layer refresh can also be satisfied by a complete state refresh, such as an IDR.) Senders which support receiving LRR for non-temporally-nested streams MUST insert Temporal Level Switching Point SEI messages as appropriate. 4.2. VP8 The VP8 RTP payload format [RFC7741] defines temporal scalability modes. It does not support spatial scalability. +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID | RES | +---------------+---------------+ Figure 7 Figure 7 shows the format of the layer index field for VP8 streams. The "RES" fields MUST be set to 0 on transmission and be ignored on reception. See [RFC7741] Section 4.2 for details on the TID field. A VP8 layer refresh point can be identified by the presence of the "Y" bit in the VP8 payload header. When this bit is set, this and all subsequent frames depend only on the current base temporal layer. Lennox, et al. Expires December 31, 2017 [Page 9] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 On receipt of an LRR for a VP8 stream, A sender which supports LRR MUST encode the stream so it can set the Y bit in a packet whose temporal layer is at or below the target layer index. Note that in VP8, not every layer switch point can be identified by the Y bit, since the Y bit implies layer switch of all layers, not just the layer in which it is sent. Thus the use of LRR with VP8 can result in some inefficiency in transmision. However, this is not expected to be a major issue for temporal structures in normal use. 4.3. H265 The initial version of the H.265 payload format [RFC7798] defines temporal scalability, with protocol elements reserved for spatial or other scalability modes (which are expected to be defined in a future version of the specification). +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |RES| LayerId | +---------------+---------------+ Figure 8 Figure 8 shows the format of the layer index field for H.265 streams. The "RES" fields MUST be set to 0 on transmission and ignored on reception. See [RFC7798] Section 1.1.4 for details on the LayerId and TID fields. H.265 streams signal whether they are temporally nested, using the vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). If this flag is set in a stream's currently applicable VPS or SPS, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit types 2 to 5 inclusively identify temporal layer switching points. A layer refresh to any higher target temporal layer is satisfied when a NAL unit type of 4 or 5 with TID equal to 1 more than current TID is seen. Alternatively, layer refresh to a target temporal layer can be incrementally satisfied with NAL unit type of 2 or 3. In this case, given current TID = TO and target TID = TN, layer refresh to TN is satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up to TID = TN. During this incremental process, layer refresh to TN can be completely satisfied as soon as a NAL unit type of 2 or 3 is seen. Lennox, et al. Expires December 31, 2017 [Page 10] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Of course, temporal layer refresh can also be satisfied whenever any Intra Random Access Point (IRAP) NAL unit type (with values 16-23, inclusively) is seen. An IRAP picture is similar to an IDR picture in H.264 (NAL unit type of 5 in H.264) where decoding of the picture can start without any older pictures. In the (future) H.265 payloads that support spatial scalability, a spatial layer refresh of a specific layer can be identified by NAL units with the requested layer ID and NAL unit types between 16 and 21 inclusive. A dependency or quality layer refresh is complete once NAL units of this type have been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index. 5. Usage with different scalability transmission mechanisms Several different mechanisms are defined for how scalable streams can be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7 defines three mechanisms: Single RTP Stream on a Single Media Transport (SRST), Multiple RTP Streams on a Single Media Transport (MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT). The LRR message is applicable to all these mechanisms. For MRST and MRMT mechanisms, the "media source" field of the LRR FCI is set to the SSRC of the RTP stream containing the layer indicated by the Current Layer Index (if "C" is 1), or the stream containing the base encoded stream (if "C" is 0). For MRMT, it is sent on the RTP session on which this stream is sent. On receipt, the sender MUST refresh all the layers requested in the stream, simultaneously in decode order. 6. SDP Definitions Section 7 of [RFC5104] defines SDP procedures for indicating and negotiating support for codec control messages (CCM) in SDP. This document extends this with a new codec control command, "lrr", which indicates support of the Layer Refresh Request (LRR). Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this grammar extension, extending the grammar defined in [RFC5104]. rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request Figure 9: Syntax of the "lrr" ccm The Offer-Answer considerations defined in [RFC5104] Section 7.2 apply. Lennox, et al. Expires December 31, 2017 [Page 11] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 7. Security Considerations All the security considerations of FIR feedback packets [RFC5104] apply to LRR feedback packets as well. Additionally, media senders receiving LRR feedback packets MUST validate that the payload types and layer indices they are receiving are valid for the stream they are currently sending, and discard the requests if not. 8. IANA Considerations This document defines a new entry to the "Codec Control Messages" subregistry of the "Session Description Protocol (SDP) Parameters" registry, according to the following data: Value name: lrr Long name: Layer Refresh Request Command Usable with: ccm Mux: IDENTICAL-PER-PT Reference: RFC XXXX This document also defines a new entry to the "FMT Values for PSFB Payload Types" subregistry of the "Real-Time Transport Protocol (RTP) Parameters" registry, according to the following data: Name: LRR Long Name: Layer Refresh Request Command Value: TBD Reference: RFC XXXX 9. References 9.1. Normative References [I-D.ietf-avtext-framemarking] Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking RTP Header Extension", draft-ietf-avtext-framemarking-04 (work in progress), March 2017. Lennox, et al. Expires December 31, 2017 [Page 12] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 [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, . [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, . [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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [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, . [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 2016, . 9.2. Informative References [I-D.ietf-payload-vp9] Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. Hong, "RTP Payload Format for VP9 Video", draft-ietf- payload-vp9-03 (work in progress), March 2017. Lennox, et al. Expires December 31, 2017 [Page 13] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 [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, . [RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund, "Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs", RFC 8082, DOI 10.17487/RFC8082, March 2017, . Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Danny Hong Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: danny@vidyo.com Justin Uberti Google, Inc. 747 6th Street South Kirkland, WA 98033 USA Email: justin@uberti.name Lennox, et al. Expires December 31, 2017 [Page 14] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Stefan Holmer Google, Inc. Kungsbron 2 Stockholm 111 22 Sweden Email: holmer@google.com Magnus Flodman Google, Inc. Kungsbron 2 Stockholm 111 22 Sweden Email: mflodman@google.com Lennox, et al. Expires December 31, 2017 [Page 15] ./draft-ietf-mmusic-ice-sip-sdp-39.txt0000644000764400076440000027105613524656112017014 0ustar iustyiusty MMUSIC M. Petit-Huguenin Internet-Draft Impedance Mismatch Obsoletes: 5245 (if approved) S. Nandakumar Intended status: Standards Track Cisco Systems Expires: February 14, 2020 C. Holmberg A. Keranen Ericsson R. Shpount TurboBridge August 13, 2019 Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) draft-ietf-mmusic-ice-sip-sdp-39 Abstract This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. This document obsoletes RFC 5245. 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 https://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, 2020. Copyright Notice Copyright (c) 2019 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 Petit-Huguenin, et al. Expires February 14, 2020 [Page 1] Internet-Draft ICE SDP Usage August 2019 (https://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 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 5 4.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6 4.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6 4.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 4.2.5. Verifying ICE Support Procedures . . . . . . . . . . 7 4.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 8 4.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 4.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 4.3.2. Sending the Initial Answer . . . . . . . . . . . . . 9 4.3.3. Receiving the Initial Answer . . . . . . . . . . . . 10 4.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 10 4.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 11 4.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 11 4.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 14 4.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 16 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 18 5.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 20 5.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 21 5.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 21 Petit-Huguenin, et al. Expires February 14, 2020 [Page 2] Internet-Draft ICE SDP Usage August 2019 5.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 22 5.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 22 6. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23 7.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 24 7.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 25 7.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25 7.3. Interactions with Forking . . . . . . . . . . . . . . . . 25 7.4. Interactions with Preconditions . . . . . . . . . . . . . 25 7.5. Interactions with Third Party Call Control . . . . . . . 26 8. Interactions with Application Layer Gateways and SIP . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9.1. IP Address Privacy . . . . . . . . . . . . . . . . . . . 28 9.2. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 28 9.3. The Voice Hammer Attack . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 29 10.1.1. candidate Attribute . . . . . . . . . . . . . . . . 29 10.1.2. remote-candidates Attribute . . . . . . . . . . . . 29 10.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 30 10.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 30 10.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 31 10.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 31 10.1.7. ice-options Attribute . . . . . . . . . . . . . . . 32 10.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 32 10.2. Interactive Connectivity Establishment (ICE) Options Registry . . . . . . . . . . . . . . . . . . . . . . . . 33 10.3. Candidate Attribute Extension Subregistry Establishment 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 12. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. The remote-candidates Attribute . . . . . . . . . . 39 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 40 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 41 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer [RFC3264]. The ICE specification [RFC8445] describes procedures that are common to all usages of ICE and this document gives the additional details needed to use ICE with SDP offer/answer. Petit-Huguenin, et al. Expires February 14, 2020 [Page 3] Internet-Draft ICE SDP Usage August 2019 This document obsoletes RFC 5245. NOTE: Previously both the common ICE procedures, and the SDP offer/ answer specific details, were described in[RFC5245]. [RFC8445] obsoleted [RFC5245], and the SDP offer/answer specific details were removed from the document. Section 12 describes the changes to the SDP offer/answer specific details specified in this document. 2. Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology Readers should be familiar with the terminology defined in [RFC3264], in [RFC8445] and the following: Default Destination/Candidate: The default destination for a component of a data stream is the transport address that would be used by an agent that is not ICE aware. A default candidate for a component is one whose transport address matches the default destination for that component. For the RTP component, the default connection address is in the "c=" line of the SDP, and the port and transport protocol are in the "m=" line. For the RTCP component, the address and port are indicated using the "a=rtcp" attribute defined in [RFC3605], if present; otherwise, the RTCP component address is the same as the address of the RTP component, and its port is one greater than the port of the RTP component. 4. SDP Offer/Answer Procedures 4.1. Introduction [RFC8445] defines ICE candidate exchange as the process for ICE agents (Initiator and Responder) to exchange their candidate information required for ICE processing at the agents. For the purposes of this specification, the candidate exchange process corresponds to the [RFC3264] Offer/Answer protocol and the terms "offerer" and "answerer" correspond to the initiator and responder roles from [RFC8445] respectively. Once the initiating agent has gathered, pruned, and prioritized its set of candidates [RFC8445], the candidate exchange with the peer agent begins. Petit-Huguenin, et al. Expires February 14, 2020 [Page 4] Internet-Draft ICE SDP Usage August 2019 4.2. Generic Procedures 4.2.1. Encoding Section 5 provides detailed rules for constructing various SDP attributes defined in this specification. 4.2.1.1. Data Streams Each data stream [RFC8445] is represented by an SDP media description ("m=" section). 4.2.1.2. Candidates Within an "m=" section, each candidate (including the default candidate) associated with the data stream is represented by an SDP candidate attribute. Prior to nomination, the "c=" line associated with an "m=" section contains the connection address of the default candidate, while the "m=" line contains the port and transport protocol of the default candidate for that "m=" section. After nomination, the "c=" line for a given "m=" section contains the connection address of the nominated candidate (the local candidate of the nominated candidate pair) and the "m=" line contains the port and transport protocol corresponding to the nominated candidate for that "m=" section. 4.2.1.3. Username and Password The ICE username is represented by an SDP ice-ufrag attribute and the ICE password is represented by an SDP ice-pwd attribute. 4.2.1.4. Lite Implementations An ICE lite implementation [RFC8445] MUST include an SDP ice-lite attribute. A full implementation MUST NOT include that attribute. 4.2.1.5. ICE Extensions An agent uses the SDP ice-options attribute to indicate support of ICE extensions. An agent compliant to this specification MUST include an SDP ice- options attribute with an "ice2" attribute value [RFC8445]. If an agent receives an SDP offer or answer that indicates ICE support, but that does not contain an SDP ice-options attribute with an "ice2" Petit-Huguenin, et al. Expires February 14, 2020 [Page 5] Internet-Draft ICE SDP Usage August 2019 attribute value, the agent can assume that the peer is compliant to [RFC5245]. 4.2.1.6. Inactive and Disabled Data Streams If an "m=" section is marked as inactive [RFC4566], or has a bandwidth value of zero [RFC4566], the agent MUST still include ICE- related SDP attributes. If the port value associated with an "m=" section is set to zero (implying a disabled stream) as defined in section 8.2 of [RFC3264], the agent SHOULD NOT include ICE-related SDP candidate attributes in that "m=" section, unless an SDP extension specifying otherwise is used. 4.2.2. RTP/RTCP Considerations If an agent utilizes both RTP and RTCP, and separate ports are used for RTP and RTCP, the agent MUST include SDP candidate attributes for both the RTP and RTCP components. The agent includes an SDP rtcp attribute following the procedures in [RFC3605]. Hence, in the cases where the RTCP port value is one higher than the RTP port value and the RTCP component address the same as the address of the RTP component, the SDP rtcp attribute might be omitted. NOTE: [RFC5245] required that an agent always includes the SDP rtcp attribute, even if the RTCP port value was one higher than the RTP port value. This specification aligns the rtcp attribute procedures with [RFC3605]. If the agent does not utilize RTCP, it indicates that by including b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556]. 4.2.3. Determining Role The offerer acts as the Initiating agent. The answerer acts as the Responding agent. The ICE roles (controlling and controlled) are determined using the procedures in [RFC8445]. 4.2.4. STUN Considerations Once an agent has provided its local candidates to its peer in an SDP offer or answer, the agent MUST be prepared to receive STUN connectivity check Binding requests on those candidates. Petit-Huguenin, et al. Expires February 14, 2020 [Page 6] Internet-Draft ICE SDP Usage August 2019 4.2.5. Verifying ICE Support Procedures An ICE agent is considered to indicate support of ICE by including at least the SDP ice-pwd and ice-ufrag attributes in an offer or answer. An ICE agent compliant with this specification MUST also include an SDP ice-options attribute with an "ice2" attribute value. The agents will proceed with the ICE procedures defined in [RFC8445] and this specification if, for each data stream in the SDP it received, the default destination for each component of that data stream appears in a candidate attribute. For example, in the case of RTP, the connection address, port, and transport protocol in the "c=" and "m=" lines, respectively, appear in a candidate attribute and the value in the rtcp attribute appears in a candidate attribute. This specification provides no guidance on how an agent should proceed in the cases where the above condition is not met with the few exceptions noted below: 1. The presence of certain application layer gateways might modify the transport address information as described in Section 8. The behavior of the responding agent in such a situation is implementation dependent. Informally, the responding agent might consider the mismatched transport address information as a plausible new candidate learnt from the peer and continue its ICE processing with that transport address included. Alternatively, the responding agent MAY include an "a=ice-mismatch" attribute in its answer for such data streams. If an agent chooses to include an "a=ice-mismatch" attribute in its answer for a data stream, then it MUST also omit "a=candidate" attributes, MUST terminate the usage of ICE procedures and [RFC3264] procedures MUST be used instead for this data stream. 2. The transport address from the peer for the default destination is set to IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9". This MUST NOT be considered as a ICE failure by the peer agent and the ICE processing MUST continue as usual. 3. In some cases, the controlling/initiator agent may receive the SDP answer that may omit "a=candidate" attributes for the data stream, and instead include a media level "a=ice-mismatch" attribute. This signals to the offerer that the answerer supports ICE, but that ICE processing was not used for this data stream. In this case, ICE processing MUST be terminated for this data stream and [RFC3264] procedures MUST be followed instead. 4. The transport address from the peer for the default destination is an FQDN. Regardless of the procedures used to resolve FQDN or Petit-Huguenin, et al. Expires February 14, 2020 [Page 7] Internet-Draft ICE SDP Usage August 2019 the resolution result, this MUST NOT be considered as a ICE failure by the peer agent and the ICE processing MUST continue as usual. 4.2.6. SDP Example The following is an example SDP message that includes ICE attributes (lines folded for readability): v=0 o=jdoe 2890844526 2890842807 IN IP4 203.0.113.141 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 203.0.113.141 rport 8998 4.3. Initial Offer/Answer Exchange 4.3.1. Sending the Initial Offer When an offerer generates the initial offer, in each "m=" section it MUST include SDP candidate attributes for each available candidate associated with the "m=" section. In addition, the offerer MUST include an SDP ice-ufrag attribute, an SDP ice-pwd attribute and an SDP ice-options attribute with an "ice2" attribute value in the offer. If the offerer is a full ICE implementation, it SHOULD include an ice-pacing attribute in the offer (if not included, the default value will apply). A lite ICE implementation MUST NOT included the ice-pacing attribute in the offer (as it will not perform connectivity checks). It is valid for an offer "m=" line to include no SDP candidate attributes and with default destination set to the IP address values "0.0.0.0"/"::" and port value of "9". This implies that the offering agent is only going to use peer reflexive candidates or that additional candidates would be provided in subsequent signaling messages. Petit-Huguenin, et al. Expires February 14, 2020 [Page 8] Internet-Draft ICE SDP Usage August 2019 Note: Within the scope of this document, "Initial Offer" refers to the first SDP offer that is sent in order to negotiate usage of ICE. It might, or might not, be the initial SDP offer of the SDP session. Note: The procedures in this document only consider "m=" sections associated with data streams where ICE is used. 4.3.2. Sending the Initial Answer When an answerer receives an initial offer that indicates that the offerer supports ICE, and if the answerer accepts the offer and the usage of ICE, in each "m=" section within the answer, it MUST include SDP candidate attributes for each available candidate associated with the "m=" section. In addition, the answerer MUST include an SDP ice- ufrag attribute, an SDP ice-pwd attribute and an SDP ice-options attribute with an "ice2" attribute value in the answer. If the answerer is a full ICE implementation, it SHOULD include an ice- pacing attribute in the answerer (if not included, the default value will apply). A lite ICE implementation MUST NOT included the ice- pacing attribute in the answer (as it will not perform connectivity chekcks). In each "m=" line, the answerer MUST use the same transport protocol as was used in the offer "m=" line. If none of the candidates in the "m=" line in the answer use the same transport protocol as indicated in the offer "m=" line, then, in order to avoid ICE mismatch, the default destination MUST be set to IP address values "0.0.0.0"/"::" and port value of "9". It is also valid for an answer "m=" line to include no SDP candidate attributes and with default destination set to the IP address values "0.0.0.0"/"::" and port value of "9". This implies that the answering agent is only going to use peer reflexive candidates or that additional candidates would be provided in subsequent signaling messages. Once the answerer has sent the answer, it can start performing connectivity checks towards the peer candidates that were provided in the offer. If the offer does not indicate support of ICE Section 4.2.5, the answerer MUST NOT accept the usage of ICE. If the answerer still accepts the offer, the answerer MUST NOT include any ICE-related SDP attributes in the answer. Instead the answerer will generate the answer according to normal offer/answer procedures [RFC3264]. Petit-Huguenin, et al. Expires February 14, 2020 [Page 9] Internet-Draft ICE SDP Usage August 2019 If the answerer detects a possibility of an ICE mismatch, procedures described in Section 4.2.5 are followed. 4.3.3. Receiving the Initial Answer When an offerer receives an initial answer that indicates that the answerer supports ICE, it can start performing connectivity checks towards the peer candidates that were provided in the answer. If the answer does not indicate that the answerer supports ICE, or if the answerer included "a=ice-mismatch" attributes for all the active data streams in the answer, the offerer MUST terminate the usage of ICE for the entire session and [RFC3264] procedures MUST be followed instead. On the other hand, if the answer indicates support for ICE but includes "a=ice-mismatch" in certain active data streams, then the offerer MUST terminate the usage of ICE procedures and [RFC3264] procedures MUST be used instead for only these data streams. Also, ICE procedures MUST be used for data streams where an "a=ice- mismatch" attribute was not included. If the offerer detects an ICE mismatch for one or more data streams in the answer, as described in Section 4.2.5, the offerer MUST terminate the usage of ICE for the entire session. The subsequent actions taken by the offerer are implementation dependent and are out of the scope of this specification. 4.3.4. Concluding ICE Once the agent has successfully nominated a pair [RFC8445], the state of the checklist associated with the pair is set to Completed. Once the state of each checklist is set to either Completed or Failed, for each Completed checklist the agent checks whether the nominated pair matches the default candidate pair. If there are one or more pairs that do not match, and the peer did not indicate support for the 'ice2' ice-option, the controlling agent MUST generate a subsequent offer, in which the connection address, port and transport protocol in the "c=" and "m=" lines associated with each data stream match the corresponding local information of the nominated pair for that data stream (Section 4.4.1.2.2). If the peer did indicate support for the 'ice2' ice-option, the controlling agent does not immediately need to generate an updated offer in order to align a connection address, port and protocol with a nominated pair. However, later in the session, whenever the controlling agent does sent a subsequent offer, it MUST do the alignment as described above. Petit-Huguenin, et al. Expires February 14, 2020 [Page 10] Internet-Draft ICE SDP Usage August 2019 If there are one or more checklists with the state set to Failed, the controlling agent MUST generate a subsequent offer in order to remove the associated data streams by setting the port value of the data streams to zero (Section 4.4.1.1.2), even if the peer did indicate support for the 'ice2' ice-option. If needed, such offer is used to align the connection address, port and transport protocol, as described above. As described in [RFC8445], once the controlling agent has nominated a candidate pair for a checklist, the agent MUST NOT nominate another pair for that checklist during the lifetime of the ICE session (i.e. until ICE is restarted). [draft-ietf-ice-pac] provides a mechanism for allowing the ICE process to run long enough in order to find working candidate pairs, by waiting for potential peer-reflexive candidates, even though no candidate pairs were received from the peer or all current candidate pairs associated with a checklist have either failed or been discarded. It is OPTIONAL for an ICE agent to support the mechanism. 4.4. Subsequent Offer/Answer Exchanges Either agent MAY generate a subsequent offer at any time allowed by [RFC3264]. This section defines rules for construction of subsequent offers and answers. Should a subsequent offer fail, ICE processing continues as if the subsequent offer had never been made. 4.4.1. Sending Subsequent Offer 4.4.1.1. Procedures for All Implementations 4.4.1.1.1. ICE Restart An agent MAY restart ICE processing for an existing data stream [RFC8445]. The rules governing the ICE restart imply that setting the connection address in the "c=" line to "0.0.0.0" (for IPv4)/ "::" (for IPv6) will cause an ICE restart. Consequently, ICE implementations MUST NOT utilize this mechanism for call hold, and instead MUST use "a=inactive" and "a=sendonly" as described in [RFC3264]. To restart ICE, an agent MUST change both the ice-pwd and the ice- ufrag for the data stream in an offer. However, it is permissible to use a session-level attribute in one offer, but to provide the same Petit-Huguenin, et al. Expires February 14, 2020 [Page 11] Internet-Draft ICE SDP Usage August 2019 ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. This MUST NOT be considered as ICE restart. An agent sets the rest of the ICE-related fields in the SDP for this data stream as it would in an initial offer of this data stream (Section 4.2.1). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that data stream and MAY include a totally new set of candidates. The agent MAY modify the attribute values of the SDP ice-options and SDP ice-pacing attributes, and it MAY change its role using the SDP ice-lite attribute. The agent MUST NOT modify the SDP ice-options, ice-pacing and ice-lite attributes in a subsequent offer unless the offer is sent in order to request an ICE restart. 4.4.1.1.2. Removing a Data Stream If an agent removes a data stream by setting its port to zero, it MUST NOT include any candidate attributes for that data stream and SHOULD NOT include any other ICE-related attributes defined in Section 5 for that data stream. 4.4.1.1.3. Adding a Data Stream If an agent wishes to add a new data stream, it sets the fields in the SDP for this data stream as if this were an initial offer for that data stream (Section 4.2.1). This will cause ICE processing to begin for this data stream. 4.4.1.2. Procedures for Full Implementations This section describes additional procedures for full implementations, covering existing data streams. 4.4.1.2.1. Before Nomination When an offerer sends a subsequent offer; in each "m=" section for which a candidate pair has not yet been nominated, the offer MUST include the same set of ICE-related information that the offerer included in the previous offer or answer. The agent MAY include additional candidates it did not offer previously, but which it has gathered since the last offer/answer exchange, including peer reflexive candidates. The agent MAY change the default destination for media. As with initial offers, there MUST be a set of candidate attributes in the offer matching this default destination. Petit-Huguenin, et al. Expires February 14, 2020 [Page 12] Internet-Draft ICE SDP Usage August 2019 4.4.1.2.2. After Nomination Once a candidate pair has been nominated for a data stream, the connection address, port and transport protocol in each "c=" and "m=" line associated with that data stream MUST match the data associated with the nominated pair for that data stream. In addition, the offerer only includes SDP candidates (one per component) representing the local candidates of the nominated candidate pair. The offerer MUST NOT include any other SDP candidate attributes in the subsequent offer. In addition, if the agent is controlling, it MUST include the "a=remote-candidates" attribute for each data stream whose checklist is in the Completed state. The attribute contains the remote candidates corresponding to the nominated pair in the valid list for each component of that data stream. It is needed to avoid a race condition whereby the controlling agent chooses its pairs, but the updated offer beats the connectivity checks to the controlled agent, which doesn't even know these pairs are valid, let alone selected. See Appendix B for elaboration on this race condition. 4.4.1.3. Procedures for Lite Implementations If the ICE state is Running, a lite implementation MUST include all of its candidates for each component of each data stream in "a=candidate" attributes in any subsequent offer. The candidates are formed identically to the procedures for initial offers. A lite implementation MUST NOT add additional host candidates in a subsequent offer, and MUST NOT modify the username fragments and passwords. If an agent needs to offer additional candidates, or modify the username fragments and passwords, it MUST request an ICE restart (Section 4.4.1.1.1) for that data stream. If ICE has completed for a data stream and if the agent is controlled, the default destination for that data stream MUST be set to the remote candidate of the candidate pair for that component in the valid list. For a lite implementation, there is always just a single candidate pair in the valid list for each component of a data stream. Additionally, the agent MUST include a candidate attribute for each default destination. If the ICE state is Completed and if the agent is controlling (which only happens when both agents are lite), the agent MUST include the "a=remote-candidates" attribute for each data stream. The attribute contains the remote candidates from the candidate pairs in the valid list (one pair for each component of each data stream). Petit-Huguenin, et al. Expires February 14, 2020 [Page 13] Internet-Draft ICE SDP Usage August 2019 4.4.2. Sending Subsequent Answer If ICE is Completed for a data stream, and the offer for that data stream lacked the "a=remote-candidates" attribute, the rules for construction of the answer are identical to those for the offerer, except that the answerer MUST NOT include the "a=remote-candidates" attribute in the answer. A controlled agent will receive an offer with the "a=remote- candidates" attribute for a data stream when its peer has concluded ICE processing for that data stream. This attribute is present in the offer to deal with a race condition between the receipt of the offer, and the receipt of the Binding Response that tells the answerer the candidate that will be selected by ICE. See Appendix B for an explanation of this race condition. Consequently, processing of an offer with this attribute depends on the winner of the race. The agent forms a candidate pair for each component of the data stream by: o Setting the remote candidate equal to the offerer's default destination for that component (i.e. the contents of the "m=" and "c=" lines for RTP, and the "a=rtcp" attribute for RTCP) o Setting the local candidate equal to the transport address for that same component in the "a=remote-candidates" attribute in the offer. The agent then sees if each of these candidate pairs is present in the valid list. If a particular pair is not in the valid list, the check has "lost" the race. Call such a pair a "losing pair". The agent finds all the pairs in the checklist whose remote candidates equal the remote candidate in the losing pair: o If none of the pairs are In-Progress, and at least one is Failed, it is most likely that a network failure, such as a network partition or serious packet loss, has occurred. The agent SHOULD generate an answer for this data stream as if the remote- candidates attribute had not been present, and then restart ICE for this stream. o If at least one of the pairs is In-Progress, the agent SHOULD wait for those checks to complete, and as each completes, redo the processing in this section until there are no losing pairs. Once there are no losing pairs, the agent can generate the answer. It MUST set the default destination for media to the candidates in Petit-Huguenin, et al. Expires February 14, 2020 [Page 14] Internet-Draft ICE SDP Usage August 2019 the remote-candidates attribute from the offer (each of which will now be the local candidate of a candidate pair in the valid list). It MUST include a candidate attribute in the answer for each candidate in the remote-candidates attribute in the offer. 4.4.2.1. ICE Restart If the offerer in a subsequent offer requested an ICE restart (Section 4.4.1.1.1) for a data stream, and if the answerer accepts the offer, the answerer follows the procedures for generating an initial answer. For a given data stream, the answerer MAY include the same candidates that were used in the previous ICE session, but it MUST change the SDP ice-pwd and ice-ufrag attribute values. The answerer MAY modify the attribute values of the SDP ice-options and SDP ice-pacing attributes, and it MAY change its role using the SDP ice-lite attribute. The answerer MUST NOT modify the SDP ice- options, ice-pacing and ice-lite attributes in a subsequent answer unless the answer is sent for an offer that was used to request an ICE restart (Section 4.4.1.1.1). If any of the SDP attributes have been modified in a subsequent offer that is not used to request an ICE restart, the answerer MUST reject the offer. 4.4.2.2. Lite Implementation specific procedures If the received offer contains the remote-candidates attribute for a data stream, the agent forms a candidate pair for each component of the data stream by: o Setting the remote candidate equal to the offerer's default destination for that component (i.e., the contents of the "m=" and "c=" lines for RTP, and the "a=rtcp" attribute for RTCP). o Setting the local candidate equal to the transport address for that same component in the "a=remote-candidates" attribute in the offer. The state of the checklist associated with that data stream is set to Completed. Furthermore, if the agent believed it was controlling, but the offer contained the "a=remote-candidates" attribute, both agents believe they are controlling. In this case, both would have sent updated offers around the same time. Petit-Huguenin, et al. Expires February 14, 2020 [Page 15] Internet-Draft ICE SDP Usage August 2019 However, the signaling protocol carrying the offer/answer exchanges will have resolved this glare condition, so that one agent is always the 'winner' by having its offer received before its peer has sent an offer. The winner takes the role of controlling, so that the loser (the answerer under consideration in this section) MUST change its role to controlled. Consequently, if the agent was going to send an updated offer since, based on the rules in section 8.2 of [RFC8445], it was controlling, it no longer needs to. Besides the potential role change, change in the Valid list, and state changes, the construction of the answer is performed identically to the construction of an offer. 4.4.3. Receiving Answer for a Subsequent Offer 4.4.3.1. Procedures for Full Implementations There may be certain situations where the offerer receives an SDP answer that lacks ICE candidates although the initial answer included them. One example of such an "unexpected" answer might be happen when an ICE-unaware Back-to-Back User Agent (B2BUA) introduces a media server during call hold using 3rd party call-control procedures [RFC3725]. Omitting further details how this is done, this could result in an answer being received at the holding UA that was constructed by the B2BUA. With the B2BUA being ICE-unaware, that answer would not include ICE candidates. Receiving an answer without ICE attributes in this situation might be unexpected, but would not necessarily impair the user experience. When the offerer receives an answer indicating support for ICE, the offer performs one of the following actions: o If the offer was a restart, the agent MUST perform ICE restart procedures as specified in Section 4.4.3.1.1 o If the offer/answer exchange removed a data stream, or an answer rejected an offered data stream, an agent MUST flush the Valid list for that data stream. It MUST also terminate any STUN transactions in progress for that data stream. o If the offer/answer exchange added a new data stream, the agent MUST create a new checklist for it (and an empty Valid list to start of course) which in turn triggers the candidate processing procedures [RFC8445]. Petit-Huguenin, et al. Expires February 14, 2020 [Page 16] Internet-Draft ICE SDP Usage August 2019 o If the checklist state associated with a data stream is Running, the agent recomputes the checklist. If a pair on the new checklist was also on the previous checklist, its candidate pair state is copied over. Otherwise, its candidate pair state is set to Frozen. If none of the checklists are active (meaning that the candidate pair states in each checklist are Frozen), appropriate procedures in [RFC8445] are performed to move candidate pair(s) to the Waiting state to further continue ICE processing. o If the ICE state is Completed and the SDP answer conforms to Section 4.4.2, the agent MUST remain in the Completed ICE state. However, if the ICE support is no longer indicated in the SDP answer, the agent MUST fall-back to [RFC3264] procedures and SHOULD NOT drop the dialog because of the missing ICE support or unexpected answer. Once the agent sends a new offer later on, it MUST perform an ICE restart. 4.4.3.1.1. ICE Restarts The agent MUST remember the nominated pair in the Valid list for each component of the data stream, called the "previous selected pair", prior to the restart. The agent will continue to send media using this pair, as described in section 12 of [RFC8445]. Once these destinations are noted, the agent MUST flush the Valid lists and checklists, and then recompute the checklist and its states, thus triggering the candidate processing procedures [RFC8445] 4.4.3.2. Procedures for Lite Implementations If ICE is restarting for a data stream, the agent MUST create a new Valid list for that data stream. It MUST remember the nominated pair in the previous Valid list for each component of the data stream, called the "previous selected pairs", and continue to send media there as described in section 12 of [RFC8445]. The state of each checklist for each data stream MUST change to Running, and the ICE state MUST be set to Running. 5. Grammar This specification defines eight new SDP attributes -- the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- ufrag", "ice-pwd", "ice-pacing", and "ice-options" attributes. This section also provides non-normative examples of the attributes defined. Petit-Huguenin, et al. Expires February 14, 2020 [Page 17] Internet-Draft ICE SDP Usage August 2019 The syntax for the attributes follow Augmented BNF as defined in [RFC5234]. 5.1. "candidate" Attribute The candidate attribute is a media-level attribute only. It contains a transport address for a candidate that can be used for connectivity checks. candidate-attribute = "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP ;from RFC 4566 port ;port from RFC 4566 SP cand-type [SP rel-addr] [SP rel-port] *(SP cand-extension) foundation = 1*32ice-char component-id = 1*3DIGIT transport = "UDP" / transport-extension transport-extension = token ; from RFC 3261 priority = 1*10DIGIT cand-type = "typ" SP candidate-types candidate-types = "host" / "srflx" / "prflx" / "relay" / token rel-addr = "raddr" SP connection-address rel-port = "rport" SP port cand-extension = extension-att-name SP extension-att-value extension-att-name = token extension-att-value = *VCHAR ice-char = ALPHA / DIGIT / "+" / "/" This grammar encodes the primary information about a candidate: its IP address, port and transport protocol, and its properties: the foundation, component ID, priority, type, and related transport address: : is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent generating local candidates MUST NOT use FQDN addresses. An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN or IP address versions that are not supported or recognized. The procedures for generation and handling of FQDN candidates, as well Petit-Huguenin, et al. Expires February 14, 2020 [Page 18] Internet-Draft ICE SDP Usage August 2019 as, how agents indicate support for such procedures, need to be specified in an extension specification. : is also taken from RFC 4566 [RFC4566]. It is the port of the candidate. : indicates the transport protocol for the candidate. This specification only defines UDP. However, extensibility is provided to allow for future transport protocols to be used with ICE by extending the sub-registry "ICE Transport Protocols" under "Interactive Connectivity Establishment (ICE)" registry. : is composed of 1 to 32 s. It is an identifier that is equivalent for two candidates that are of the same type, share the same base, and come from the same STUN server. The foundation is used to optimize ICE performance in the Frozen algorithm as described in [RFC8445] : is a positive integer between 1 and 256 (inclusive) that identifies the specific component of the data stream for which this is a candidate. It MUST start at 1 and MUST increment by 1 for each component of a particular candidate. For data streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2. See section 13 in [RFC8445] for additional discussion on extending ICE to new data streams. : is a positive integer between 1 and (2**31 - 1) inclusive. The procedures for computing candidate's priority is described in section 5.1.2 of [RFC8445]. : encodes the type of candidate. This specification defines the values "host", "srflx", "prflx", and "relay" for host, server reflexive, peer reflexive, and relayed candidates, respectively. Specifications for new candidate types MUST define how, if at all, various steps in the ICE processing differ from the ones defined by this specification. and : convey transport addresses related to the candidate, useful for diagnostics and other purposes. and MUST be present for server reflexive, peer reflexive, and relayed candidates. If a candidate is server or peer reflexive, and are equal to the base for that server or peer reflexive candidate. If the candidate is relayed, and are equal to the mapped address in the Allocate response that provided the client with that relayed candidate (see Appendix B.3 of [RFC8445] for a discussion Petit-Huguenin, et al. Expires February 14, 2020 [Page 19] Internet-Draft ICE SDP Usage August 2019 of its purpose). If the candidate is a host candidate, and MUST be omitted. In some cases, e.g., for privacy reasons, an agent may not want to reveal the related address and port. In this case the address MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 candidates) and the port to '9'. The candidate attribute can itself be extended. The grammar allows for new name/value pairs to be added at the end of the attribute. Such extensions MUST be made through IETF Review or IESG Approval [RFC8126] and the assignments MUST contain the specific extension and a reference to the document defining the usage of the extension. An implementation MUST ignore any name/value pairs it doesn't understand. Example: SDP line for UDP server reflexive candidate attribute for the RTP component a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 203.0.113.141 rport 8998 5.2. "remote-candidates" Attribute The syntax of the "remote-candidates" attribute is defined using Augmented BNF as defined in [RFC5234]. The remote-candidates attribute is a media-level attribute only. remote-candidate-att = "remote-candidates:" remote-candidate 0*(SP remote-candidate) remote-candidate = component-ID SP connection-address SP port The attribute contains a connection-address and port for each component. The ordering of components is irrelevant. However, a value MUST be present for each component of a data stream. This attribute MUST be included in an offer by a controlling agent for a data stream that is Completed, and MUST NOT be included in any other case. Example: Remote candidates SDP lines for the RTP and RTCP components: a=remote-candidates:1 192.0.2.3 45664 a=remote-candidates:2 192.0.2.3 45665 Petit-Huguenin, et al. Expires February 14, 2020 [Page 20] Internet-Draft ICE SDP Usage August 2019 5.3. "ice-lite" and "ice-mismatch" Attributes The syntax of the "ice-lite" and "ice-mismatch" attributes, both of which are flags, is: ice-lite = "ice-lite" ice-mismatch = "ice-mismatch" "ice-lite" is a session-level attribute only, and indicates that an agent is a lite implementation. "ice-mismatch" is a media-level attribute and only reported in the answer. It indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. Inclusion of "a=ice-mismatch" attribute for a given data stream implies that even though both agents support ICE, ICE procedures MUST NOT be used for this data stream and [RFC3264] procedures MUST be used instead. 5.4. "ice-ufrag" and "ice-pwd" Attributes The "ice-ufrag" and "ice-pwd" attributes convey the username fragment and password used by ICE for message integrity. Their syntax is: ice-pwd-att = "ice-pwd:" password ice-ufrag-att = "ice-ufrag:" ufrag password = 22*256ice-char ufrag = 4*256ice-char The "ice-pwd" and "ice-ufrag" attributes can appear at either the session-level or media-level. When present in both, the value in the media-level takes precedence. Thus, the value at the session-level is effectively a default that applies to all data streams, unless overridden by a media-level value. Whether present at the session or media-level, there MUST be an ice-pwd and ice-ufrag attribute for each data stream. If two data streams have identical ice-ufrag's, they MUST have identical ice-pwd's. The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the beginning of a session (the same applies when ICE is restarting for an agent). [RFC8445] requires the ice-ufrag attribute to contain at least 24 bits of randomness, and the ice-pwd attribute to contain at least 128 bits of randomness. This means that the ice-ufrag attribute will be at least 4 characters long, and the ice-pwd at least 22 characters long, since the grammar for these attributes allows for 6 bits of information per character. The attributes MAY be longer than 4 and 22 characters, respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large Petit-Huguenin, et al. Expires February 14, 2020 [Page 21] Internet-Draft ICE SDP Usage August 2019 upper limit allows for increased amounts of randomness to be added over time. For compatibility with the 512 character limitation for the STUN username attribute value and for bandwidth conservation considerations, the ice-ufrag attribute MUST NOT be longer than 32 characters when sending, but an implementation MUST accept up to 256 characters when receiving. Example shows sample ice-ufrag and ice-pwd SDP lines: a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY 5.5. "ice-pacing" Attribute The "ice-pacing" is a session level attribute that indicates the desired connectivity check pacing (Ta interval), in milliseconds, that the sender wishes to use. See section 14.2 of [RFC8445] for more information regarding selecting a pacing value. The syntax is: ice-pacing-att = "ice-pacing:" pacing-value pacing-value = 1*10DIGIT If absent in an offer or answer the default value of the attribute is 50 ms, which is the recommended value specified in [RFC8445]. Once both agents have indicated the pacing value they with to use, both agents MUST use the larger of the indicated values. Example shows an ice-pacing SDP line with value '50': a=ice-pacing:50 5.6. "ice-options" Attribute The "ice-options" attribute is a session- and media-level attribute. It contains a series of tokens that identify the options supported by the agent. Its grammar is: ice-options = "ice-options:" ice-option-tag *(SP ice-option-tag) ice-option-tag = 1*ice-char The existence of an ice-option in an offer indicates that a certain extension is supported by the agent and it is willing to use it, if the peer agent also includes the same extension in the answer. There might be further extension specific negotiation needed between the agents that determine how the extension gets used in a given session. The details of the negotiation procedures, if present, MUST be defined by the specification defining the extension (Section 10.2). Petit-Huguenin, et al. Expires February 14, 2020 [Page 22] Internet-Draft ICE SDP Usage August 2019 Example shows an ice-options SDP line with 'ice2' and 'rtp+ecn' [RFC6679] values: a=ice-options:ice2 rtp+ecn 6. Keepalives All the ICE agents MUST follow the procedures defined in section 11 of [RFC8445] for sending keepalives. The keepalives MUST be sent regardless of whether the data stream is currently inactive, sendonly, recvonly, or sendrecv, and regardless of the presence or value of the bandwidth attribute. An agent can determine that its peer supports ICE by the presence of "a=candidate" attributes for each media session. 7. SIP Considerations Note that ICE is not intended for NAT traversal for SIP signaling, which is assumed to be provided via another mechanism [RFC5626]. When ICE is used with SIP, forking may result in a single offer generating a multiplicity of answers. In that case, ICE proceeds completely in parallel and independently for each answer, treating the combination of its offer and each answer as an independent offer/ answer exchange, with its own set of local candidates, pairs, checklists, states, and so on. 7.1. Latency Guidelines ICE requires a series of STUN-based connectivity checks to take place between endpoints. These checks start from the answerer on generation of its answer, and start from the offerer when it receives the answer. These checks can take time to complete, and as such, the selection of messages to use with offers and answers can affect perceived user latency. Two latency figures are of particular interest. These are the post-pickup delay and the post-dial delay. The post-pickup delay refers to the time between when a user "answers the phone" and when any speech they utter can be delivered to the caller. The post-dial delay refers to the time between when a user enters the destination address for the user and ringback begins as a consequence of having successfully started alerting the called user agent. Two cases can be considered -- one where the offer is present in the initial INVITE and one where it is in a response. Petit-Huguenin, et al. Expires February 14, 2020 [Page 23] Internet-Draft ICE SDP Usage August 2019 7.1.1. Offer in INVITE To reduce post-dial delays, it is RECOMMENDED that the caller begin gathering candidates prior to actually sending its initial INVITE, so that the candidates can be provided in the INVITE. This can be started upon user interface cues that a call is pending, such as activity on a keypad or the phone going off-hook. On the receipt of the offer, the answerer SHOULD generate an answer in a provisional response as soon as it has completed gathering the candidates. ICE requires that a provisional response with an SDP be transmitted reliably. This can be done through the existing Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or through an ICE specific optimization, wherein, the agent retransmits the provisional response with the exponential backoff timers described in [RFC3262]. Such retransmissions MUST cease on receipt of a STUN Binding request with the transport address matching the candidate address for one of the data streams signaled in that SDP or on transmission of the answer in a 2xx response. If no Binding request is received prior to the last retransmit, the agent does not consider the session terminated. For the ICE lite peers, the agent MUST cease retransmitting the 18x after sending it four times since there will be no Binding request sent and the number four is arbitrarily chosen to limit the number of 18x retransmits. Once the answer has been sent, the agent SHOULD begin its connectivity checks. Once candidate pairs for each component of a data stream enter the valid list, the answerer can begin sending media on that data stream. However, prior to this point, any media that needs to be sent towards the caller (such as SIP early media [RFC3960]) MUST NOT be transmitted. For this reason, implementations SHOULD delay alerting the called party until candidates for each component of each data stream have entered the valid list. In the case of a PSTN gateway, this would mean that the setup message into the PSTN is delayed until this point. Doing this increases the post-dial delay, but has the effect of eliminating 'ghost rings'. Ghost rings are cases where the called party hears the phone ring, picks up, but hears nothing and cannot be heard. This technique works without requiring support for, or usage of, preconditions [RFC3312]. It also has the benefit of guaranteeing that not a single packet of media will get clipped, so that post-pickup delay is zero. If an agent chooses to delay local alerting in this way, it SHOULD generate a 180 response once alerting begins. Petit-Huguenin, et al. Expires February 14, 2020 [Page 24] Internet-Draft ICE SDP Usage August 2019 7.1.2. Offer in Response In addition to uses where the offer is in an INVITE, and the answer is in the provisional and/or 200 OK response, ICE works with cases where the offer appears in the response. In such cases, which are common in third party call control [RFC3725], ICE agents SHOULD generate their offers in a reliable provisional response (which MUST utilize [RFC3262]), and not alert the user on receipt of the INVITE. The answer will arrive in a PRACK. This allows for ICE processing to take place prior to alerting, so that there is no post-pickup delay, at the expense of increased call setup delays. Once ICE completes, the callee can alert the user and then generate a 200 OK when they answer. The 200 OK would contain no SDP, since the offer/answer exchange has completed. Alternatively, agents MAY place the offer in a 2xx instead (in which case the answer comes in the ACK). When this happens, the callee will alert the user on receipt of the INVITE, and the ICE exchanges will take place only after the user answers. This has the effect of reducing call setup delay, but can cause substantial post-pickup delays and media clipping. 7.2. SIP Option Tags and Media Feature Tags [RFC5768] specifies a SIP option tag and media feature tag for usage with ICE. ICE implementations using SIP SHOULD support this specification, which uses a feature tag in registrations to facilitate interoperability through signaling intermediaries. 7.3. Interactions with Forking ICE interacts very well with forking. Indeed, ICE fixes some of the problems associated with forking. Without ICE, when a call forks and the caller receives multiple incoming data streams, it cannot determine which data stream corresponds to which callee. With ICE, this problem is resolved. The connectivity checks which occur prior to transmission of media carry username fragments, which in turn are correlated to a specific callee. Subsequent media packets that arrive on the same candidate pair as the connectivity check will be associated with that same callee. Thus, the caller can perform this correlation as long as it has received an answer. 7.4. Interactions with Preconditions Quality of Service (QoS) preconditions, which are defined in [RFC3312] and [RFC4032], apply only to the transport addresses listed as the default targets for media in an offer/answer. If ICE changes Petit-Huguenin, et al. Expires February 14, 2020 [Page 25] Internet-Draft ICE SDP Usage August 2019 the transport address where media is received, this change is reflected in an updated offer that changes the default destination for media to match ICE's selection. As such, it appears like any other re-INVITE would, and is fully treated in RFCs 3312 and 4032, which apply without regard to the fact that the destination for media is changing due to ICE negotiations occurring "in the background". Indeed, an agent SHOULD NOT indicate that QoS preconditions have been met until the checks have completed and selected the candidate pairs to be used for media. ICE also has (purposeful) interactions with connectivity preconditions [RFC5898]. Those interactions are described there. Note that the procedures described in Section 7.1 describe their own type of "preconditions", albeit with less functionality than those provided by the explicit preconditions in [RFC5898]. 7.5. Interactions with Third Party Call Control ICE works with Flows I, III, and IV as described in [RFC3725]. Flow I works without the controller supporting or being aware of ICE. Flow IV will work as long as the controller passes along the ICE attributes without alteration. Flow II is fundamentally incompatible with ICE; each agent will believe itself to be the answerer and thus never generate a re-INVITE. The flows for continued operation, as described in Section 7 of [RFC3725], require additional behavior of ICE implementations to support. In particular, if an agent receives a mid-dialog re-INVITE that contains no offer, it MUST restart ICE for each data stream and go through the process of gathering new candidates. Furthermore, that list of candidates SHOULD include the ones currently being used for media. 8. Interactions with Application Layer Gateways and SIP Application Layer Gateways (ALGs) are functions present in a Network Address Translation (NAT) device that inspect the contents of packets and modify them, in order to facilitate NAT traversal for application protocols. Session Border Controllers (SBCs) are close cousins of ALGs, but are less transparent since they actually exist as application-layer SIP intermediaries. ICE has interactions with SBCs and ALGs. If an ALG is SIP aware but not ICE aware, ICE will work through it as long as the ALG correctly modifies the SDP. A correct ALG implementation behaves as follows: Petit-Huguenin, et al. Expires February 14, 2020 [Page 26] Internet-Draft ICE SDP Usage August 2019 o The ALG does not modify the "m=" and "c=" lines or the rtcp attribute if they contain external addresses. o If the "m=" and "c=" lines contain internal addresses, the modification depends on the state of the ALG: * If the ALG already has a binding established that maps an external port to an internal connection address and port matching the values in the "m=" and "c=" lines or rtcp attribute, the ALG uses that binding instead of creating a new one. * If the ALG does not already have a binding, it creates a new one and modifies the SDP, rewriting the "m=" and "c=" lines and rtcp attribute. Unfortunately, many ALGs are known to work poorly in these corner cases. ICE does not try to work around broken ALGs, as this is outside the scope of its functionality. ICE can help diagnose these conditions, which often show up as a mismatch between the set of candidates and the "m=" and "c=" lines and rtcp attributes. The ice- mismatch attribute is used for this purpose. ICE works best through ALGs when the signaling is run over TLS. This prevents the ALG from manipulating the SDP messages and interfering with ICE operation. Implementations that are expected to be deployed behind ALGs SHOULD provide for TLS transport of the SDP. If an SBC is SIP aware but not ICE aware, the result depends on the behavior of the SBC. If it is acting as a proper Back-to-Back User Agent (B2BUA), the SBC will remove any SDP attributes it doesn't understand, including the ICE attributes. Consequently, the call will appear to both endpoints as if the other side doesn't support ICE. This will result in ICE being disabled, and media flowing through the SBC, if the SBC has requested it. If, however, the SBC passes the ICE attributes without modification, yet modifies the default destination for media (contained in the "m=" and "c=" lines and rtcp attribute), this will be detected as an ICE mismatch, and ICE processing is aborted for the call. It is outside of the scope of ICE for it to act as a tool for "working around" SBCs. If one is present, ICE will not be used and the SBC techniques take precedence. 9. Security Considerations The generic ICE security considerations are defined in [RFC8445], and the generic SDP offer/answer security considerations are defined in [RFC3264]. These security considerations also apply to implementations of this document. Petit-Huguenin, et al. Expires February 14, 2020 [Page 27] Internet-Draft ICE SDP Usage August 2019 9.1. IP Address Privacy In some cases, e.g., for privacy reasons, an agent may not want to reveal the related address and port. In this case the address MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 candidates) and the port to '9'. 9.2. Attacks on the Offer/Answer Exchanges An attacker that can modify or disrupt the offer/answer exchanges themselves can readily launch a variety of attacks with ICE. They could direct media to a target of a DoS attack, they could insert themselves into the data stream, and so on. These are similar to the general security considerations for offer/answer exchanges, and the security considerations in [RFC3264] apply. These require techniques for message integrity and encryption for offers and answers, which are satisfied by the TLS mechanism [RFC3261] when SIP is used. As such, the usage of TLS with ICE is RECOMMENDED. 9.3. The Voice Hammer Attack The voice hammer attack is an amplification attack, and can be triggered even if the attacker is an authenticated and valid participant in a session. In this attack, the attacker initiates sessions to other agents, and maliciously includes the connection address and port of a DoS target as the destination for media traffic signaled in the SDP. This causes substantial amplification; a single offer/answer exchange can create a continuing flood of media packets, possibly at high rates (consider video sources). The use of ICE can help to prevent against this attack. Specifically, if ICE is used, the agent receiving the malicious SDP will first perform connectivity checks to the target of media before sending media there. If this target is a third-party host, the checks will not succeed, and media is never sent. Unfortunately, ICE doesn't help if it's not used, in which case an attacker could simply send the offer without the ICE parameters. However, in environments where the set of clients is known, and is limited to ones that support ICE, the server can reject any offers or answers that don't indicate ICE support. SIP User Agents (UA) [RFC3261] that are not willing to receive non- ICE answers MUST include an "ice" Option Tag [RFC5768] in the SIP Require Header Field in their offer. UAs that reject non-ICE offers will generally use a 421 response code, together with an Option Tag "ice" in the Require Header Field in the response. Petit-Huguenin, et al. Expires February 14, 2020 [Page 28] Internet-Draft ICE SDP Usage August 2019 10. IANA Considerations 10.1. SDP Attributes The original ICE specification defined seven new SDP attributes per the procedures of Section 8.2.4 of [RFC4566]. The registration information from the original specification is included here with modifications to include Mux Category and also defines a new SDP attribute 'ice-pacing'. 10.1.1. candidate Attribute Attribute Name: candidate Type of Attribute: media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides one of many possible candidate addresses for communication. These addresses are validated with an end-to-end connectivity check using Session Traversal Utilities for NAT (STUN). Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact Email: iesg@ietf.org Reference: RFCXXXX Mux Category: TRANSPORT 10.1.2. remote-candidates Attribute Attribute Name: remote-candidates Type of Attribute: media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the identity of the remote candidates that the offerer wishes the answerer to use in its answer. Appropriate Values: See Section 5 of RFC XXXX. Petit-Huguenin, et al. Expires February 14, 2020 [Page 29] Internet-Draft ICE SDP Usage August 2019 Contact Name: IESG Contact Email: iesg@ietf.org Reference: RFCXXXX Mux Category: TRANSPORT 10.1.3. ice-lite Attribute Attribute Name: ice-lite Type of Attribute: session-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates that an agent has the minimum functionality required to support ICE inter-operation with a peer that has a full implementation. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact Email: iesg@ietf.org Reference: RFCXXXX Mux Category: NORMAL 10.1.4. ice-mismatch Attribute Attribute Name: ice-mismatch Type of Attribute: media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates that an agent is ICE capable, but did not proceed with ICE due to a mismatch of candidates with the default destination for media signaled in the SDP. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Petit-Huguenin, et al. Expires February 14, 2020 [Page 30] Internet-Draft ICE SDP Usage August 2019 Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux Category: NORMAL 10.1.5. ice-pwd Attribute Attribute Name: ice-pwd Type of Attribute: session- or media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the password used to protect STUN connectivity checks. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux Category: TRANSPORT 10.1.6. ice-ufrag Attribute Attribute Name: ice-ufrag Type of Attribute: session- or media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the fragments used to construct the username in STUN connectivity checks. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Petit-Huguenin, et al. Expires February 14, 2020 [Page 31] Internet-Draft ICE SDP Usage August 2019 Mux Category: TRANSPORT 10.1.7. ice-options Attribute Attribute Name: ice-options Long Form: ice-options Type of Attribute: session-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates the ICE options or extensions used by the agent. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux Category: NORMAL 10.1.8. ice-pacing Attribute This specification also defines a new SDP attribute, "ice-pacing" according to the following data: Attribute Name: ice-pacing Type of Attribute: session-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE) to indicate desired connectivity check pacing values. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Petit-Huguenin, et al. Expires February 14, 2020 [Page 32] Internet-Draft ICE SDP Usage August 2019 Mux Category: NORMAL 10.2. Interactive Connectivity Establishment (ICE) Options Registry IANA maintains a registry for ice-options identifiers under the Specification Required policy as defined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC8126]. ICE options are of unlimited length according to the syntax in Section 5.6; however, they are RECOMMENDED to be no longer than 20 characters. This is to reduce message sizes and allow for efficient parsing. ICE options are defined at the session level. A registration request MUST include the following information: o The ICE option identifier to be registered o Short description of the ICE extension to which the option relates o Reference(s) to the specification defining the ICE option and the related extensions 10.3. Candidate Attribute Extension Subregistry Establishment This section creates a new sub-registry, "Candidate Attribute Extensions", under the sdp-parameters registry: http://www.iana.org/assignments/sdp-parameters. The purpose of the sub-registry is to register SDP candidate attribute extensions. When a candidate extension is registered in the sub-registry, it needs to meet the "Specification Required" policies defined in [RFC8126]. Candidate attribute extensions MUST follow the 'cand-extension' syntax. The attribute extension name MUST follow the 'extension-att- name' syntax, and the attribute extension value MUST follow the 'extension-att-value' syntax. A registration request MUST include the following information: o The name of the attribute extension. o A short description of the attribute extension. o A reference to a specification that describes the semantics, usage and possible values of the attribute extension. Petit-Huguenin, et al. Expires February 14, 2020 [Page 33] Internet-Draft ICE SDP Usage August 2019 11. Acknowledgments A large part of the text in this document was taken from [RFC5245], authored by Jonathan Rosenberg. Some of the text in this document was taken from [RFC6336], authored by Magnus Westerlund and Colin Perkins. Many thanks to Flemming Andreasen for shepherd review feedback. Thanks to following experts for their reviews and constructive feedback: Thomas Stach, Adam Roach, Peter Saint-Andre, Roman Danyliw, Alissa Cooper, Benjamin Kaduk, Mirja Kuhlewind, Alexey Melnikov, Eric Vyncke for their detailed reviews. 12. Changes from RFC 5245 [RFC8445] describes the changes that were done to the common SIP procedures, including removal of aggressive nomination, modifying the procedures for calculating candidate pair states and scheduling connectivity checks and the calculation of timer values. This document defines the following SDP offer/answer specific changes: o SDP offer/answer realization and usage of of 'ice2' option. o Definition and usage of SDP 'ice-pacing' attribute. o Explicit text that an ICE agent must not generate candidates with FQDNs, and must discard such candidates if received from the peer agent. o Relax requirement to include SDP 'rtcp' attribute. o Generic clarifications of SDP offer/answer procedures. 13. References 13.1. Normative References [draft-ietf-ice-pac] Holmberg, C. and J. Uberti, "Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)", draft-ietf-ice-pac-02 (work in progress), July 2019, . Petit-Huguenin, et al. Expires February 14, 2020 [Page 34] Internet-Draft ICE SDP Usage August 2019 [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, . [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, . [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, . [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, . [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, DOI 10.17487/RFC4032, March 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . Petit-Huguenin, et al. Expires February 14, 2020 [Page 35] Internet-Draft ICE SDP Usage August 2019 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5768] Rosenberg, J., "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April 2010, . [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, DOI 10.17487/RFC6336, July 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 13.2. Informative References [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, . [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, DOI 10.17487/RFC3960, December 2004, . [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, . Petit-Huguenin, et al. Expires February 14, 2020 [Page 36] Internet-Draft ICE SDP Usage August 2019 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, . [RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, "Connectivity Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5898, DOI 10.17487/RFC5898, July 2010, . [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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Appendix A. Examples For the example shown in section 15 of [RFC8445] the resulting offer (message 5) encoded in SDP looks like: v=0 o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP s= c=IN IP6 $NAT-PUB-1.IP t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio $NAT-PUB-1.PORT RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ host a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT The offer, with the variables replaced with their values, will look like (lines folded for clarity): Petit-Huguenin, et al. Expires February 14, 2020 [Page 37] Internet-Draft ICE SDP Usage August 2019 v=0 o=jdoe 2890844526 2890842807 IN IP6 fe80::6676:baff:fe9c:ee4a s= c=IN IP6 2001:db8:8101:3a55:4858:a2a9:22ff:99b9 t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 fe80::6676:baff:fe9c:ee4a 8998 typ host a=candidate:2 1 UDP 1694498815 2001:db8:8101:3a55:4858:a2a9:22ff:99b9 45664 typ srflx raddr fe80::6676:baff:fe9c:ee4a rport 8998 The resulting answer looks like: v=0 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP s= c=IN IP4 $R-PUB-1.IP t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-ufrag:9uB6 m=audio $R-PUB-1.PORT RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host With the variables filled in: Petit-Huguenin, et al. Expires February 14, 2020 [Page 38] Internet-Draft ICE SDP Usage August 2019 v=0 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-ufrag:9uB6 m=audio 3478 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host Appendix B. The remote-candidates Attribute The "a=remote-candidates" attribute exists to eliminate a race condition between the updated offer and the response to the STUN Binding request that moved a candidate into the Valid list. This race condition is shown in Figure 1. On receipt of message 4, agent L adds a candidate pair to the valid list. If there was only a single data stream with a single component, agent L could now send an updated offer. However, the check from agent R has not yet generated a response, and agent R receives the updated offer (message 7) before getting the response (message 9). Thus, it does not yet know that this particular pair is valid. To eliminate this condition, the actual candidates at R that were selected by the offerer (the remote candidates) are included in the offer itself, and the answerer delays its answer until those pairs validate. Petit-Huguenin, et al. Expires February 14, 2020 [Page 39] Internet-Draft ICE SDP Usage August 2019 Agent L Network Agent R |(1) Offer | | |------------------------------------------>| |(2) Answer | | |<------------------------------------------| |(3) STUN Req. | | |------------------------------------------>| |(4) STUN Res. | | |<------------------------------------------| |(5) STUN Req. | | |<------------------------------------------| |(6) STUN Res. | | |-------------------->| | | |Lost | |(7) Offer | | |------------------------------------------>| |(8) STUN Req. | | |<------------------------------------------| |(9) STUN Res. | | |------------------------------------------>| |(10) Answer | | |<------------------------------------------| Figure 1: Race Condition Flow Appendix C. Why Is the Conflict Resolution Mechanism Needed? When ICE runs between two peers, one agent acts as controlled, and the other as controlling. Rules are defined as a function of implementation type and offerer/answerer to determine who is controlling and who is controlled. However, the specification mentions that, in some cases, both sides might believe they are controlling, or both sides might believe they are controlled. How can this happen? The condition when both agents believe they are controlled shows up in third party call control cases. Consider the following flow: Petit-Huguenin, et al. Expires February 14, 2020 [Page 40] Internet-Draft ICE SDP Usage August 2019 A Controller B |(1) INV() | | |<-------------| | |(2) 200(SDP1) | | |------------->| | | |(3) INV() | | |------------->| | |(4) 200(SDP2) | | |<-------------| |(5) ACK(SDP2) | | |<-------------| | | |(6) ACK(SDP1) | | |------------->| Figure 2: Role Conflict Flow This flow is a variation on flow III of RFC 3725 [RFC3725]. In fact, it works better than flow III since it produces fewer messages. In this flow, the controller sends an offerless INVITE to agent A, which responds with its offer, SDP1. The agent then sends an offerless INVITE to agent B, which it responds to with its offer, SDP2. The controller then uses the offer from each agent to generate the answers. When this flow is used, ICE will run between agents A and B, but both will believe they are in the controlling role. With the role conflict resolution procedures, this flow will function properly when ICE is used. At this time, there are no documented flows that can result in the case where both agents believe they are controlled. However, the conflict resolution procedures allow for this case, should a flow arise that would fit into this category. Appendix D. Why Send an Updated Offer? Section 11.1 describes rules for sending media. Both agents can send media once ICE checks complete, without waiting for an updated offer. Indeed, the only purpose of the updated offer is to "correct" the SDP so that the default destination for media matches where media is being sent based on ICE procedures (which will be the highest- priority nominated candidate pair). This raises the question -- why is the updated offer/answer exchange needed at all? Indeed, in a pure offer/answer environment, it would not be. The offerer and answerer will agree on the candidates to use through ICE, and then can begin using them. As far as the agents themselves are concerned, the updated offer/answer provides no new information. However, in practice, numerous components along the signaling path look at the SDP information. These include entities Petit-Huguenin, et al. Expires February 14, 2020 [Page 41] Internet-Draft ICE SDP Usage August 2019 performing off-path QoS reservations, NAT traversal components such as ALGs and Session Border Controllers (SBCs), and diagnostic tools that passively monitor the network. For these tools to continue to function without change, the core property of SDP -- that the existing, pre-ICE definitions of the addresses used for media -- the "m=" and "c=" lines and the rtcp attribute -- must be retained. For this reason, an updated offer must be sent. Appendix E. Contributors Following experts have contributed textual and structural improvements for this work 1. Thomas Stach * thomass.stach@gmail.com Authors' Addresses Marc Petit-Huguenin Impedance Mismatch Email: marc@petit-huguenin.org Suhas Nandakumar Cisco Systems 707 Tasman Dr Milpitas, CA 95035 USA Email: snandaku@cisco.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Petit-Huguenin, et al. Expires February 14, 2020 [Page 42] Internet-Draft ICE SDP Usage August 2019 Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Roman Shpount TurboBridge 4905 Del Ray Avenue, Suite 300 Bethesda, MD 20814 USA Phone: +1 (240) 292-6632 Email: rshpount@turbobridge.com Petit-Huguenin, et al. Expires February 14, 2020 [Page 43] ./draft-ietf-avtext-rid-09.txt0000644000764400076440000004622412775522766015503 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-homenet-babel-profile-07.txt0000644000764400076440000004664213323647633017545 0ustar iustyiusty Network Working Group J. Chroboczek Internet-Draft IRIF, University of Paris-Diderot Intended status: Standards Track July 18, 2018 Expires: January 19, 2019 Homenet profile of the Babel routing protocol draft-ietf-homenet-babel-profile-07 Abstract This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of the Homenet protocol suite, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel. 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 https://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 19, 2019. Copyright Notice Copyright (c) 2018 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 (https://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. Chroboczek Expires January 19, 2019 [Page 1] Internet-Draft Homenet Babel profile July 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Homenet profile of Babel . . . . . . . . . . . . . . . . 3 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Optional features . . . . . . . . . . . . . . . . . . . . 5 3. Interactions between HNCP and Babel . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Optional features . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The core of the Homenet protocol suite consists of the Home Networking Control Protocol (HNCP) [RFC7788], a protocol used for flooding configuration information and assigning prefixes to links, combined with the Babel routing protocol [RFC6126bis]. Babel is an extensible, flexible and modular protocol: minimal implementations of Babel have been demonstrated that consist of a few hundred lines of code, while the "large" implementation includes support for a number of extensions and consists of over ten thousand lines of C code. This document consists of two parts. The first specifies the exact subset of the Babel protocol and its extensions that is required by an implementation of the Homenet protocol suite. The second specifies how HNCP interacts with Babel. 1.1. Requirement Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Background The Babel routing protocol and its extensions are defined in a number of documents: Chroboczek Expires January 19, 2019 [Page 2] Internet-Draft Homenet Babel profile July 2018 o RFC 6126bis [RFC6126bis] defines the Babel routing protocol. It allows Babel's control data to be carried either over link-local IPv6 or over IPv4, and in either case allows announcing both IPv4 and IPv6 routes. It leaves link cost estimation, metric computation and route selection to the implementation. Distinct implementations of RFC 6126bis Babel will interoperate, in the sense that they will maintain a set of loop-free forwarding paths. However, if they implement conflicting options, they might not be able to exchange a full set of routes; in the worst case, an implementation that only implements the IPv6 subset of the protocol and an implementation that only implements the IPv4 subset of the protocol will not exchange any routes. In addition, if implementations use conflicting route selection policies, persistent oscillations might occur. o The informative Appendix A of RFC 6126bis suggests a simple and easy to implement algorithm for cost and metric computation that has been found to work satisfactorily in a wide range of topologies. o While RFC 6126bis does not provide an algorithm for route selection, its Section 3.6 suggests selecting the route with smallest metric with some hysteresis applied. An algorithm that has been found to work well in practice is described in Section III.E of [DELAY-BASED]. o Five RFCs and Internet-Drafts define optional extensions to Babel: HMAC-based authentication [RFC7298], source-specific routing [BABEL-SS], delay-based routing [BABEL-RTT] and ToS-specific routing [ToS-SPECIFIC]. All of these extensions interoperate with the core protocol as well as with each other. 2. The Homenet profile of Babel 2.1. Requirements REQ1: a Homenet implementation of Babel MUST encapsulate Babel control traffic in IPv6 packets sent to the IANA-assigned port 6696 and either the IANA-assigned multicast group ff02::1:6 or to a link- local unicast address. Rationale: since Babel is able to carry both IPv4 and IPv6 routes over either IPv4 or IPv6, choosing the protocol used for carrying control traffic is a matter of preference. Since IPv6 has some features that make implementations somewhat simpler and more reliable (notably properly scoped and reasonably stable link-local addresses), we require carrying control data over IPv6. Chroboczek Expires January 19, 2019 [Page 3] Internet-Draft Homenet Babel profile July 2018 REQ2: a Homenet implementation of Babel MUST implement the IPv6 subset of the protocol defined in the body of RFC 6126bis. Rationale: support for IPv6 routing is an essential component of the Homenet architecture. REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 subset of the protocol defined in the body of RFC 6126bis. Use of other techniques for acquiring IPv4 connectivity (such as multiple layers of NAT) is strongly discouraged. Rationale: support for IPv4 will likely remain necessary for years to come, and even in pure IPv6 deployments, including code for supporting IPv4 has very little cost. Since HNCP makes it easy to assign distinct IPv4 prefixes to the links in a network, it is not necessary to resort to multiple layers of NAT, with all of its problems. REQ4: a Homenet implementation of Babel MUST implement source- specific routing for IPv6, as defined in draft-ietf-babel-source- specific [BABEL-SS]. Rationale: source-specific routing is an essential component of the Homenet architecture. Source-specific routing for IPv4 is not required, since HNCP arranges things so that a single non-specific IPv4 default route is announced (Section 6.5 of [RFC7788]). REQ5: a Homenet implementation of Babel must use metrics that are of a similar magnitude to the values suggested in Appendix A of RFC 6126bis. In particular, it SHOULD assign costs that are no less than 256 to wireless links, and SHOULD assign costs between 32 and 196 to lossless wired links. Rationale: if two implementations of Babel choose very different values for link costs, combining routers from different vendors will cause sub-optimal routing. REQ6: a Homenet implementation of Babel SHOULD distinguish between wired and wireless links; if it is unable to determine whether a link is wired or wireless, it SHOULD make the worst-case hypothesis that the link is wireless. It SHOULD dynamically probe the quality of wireless links and derive a suitable metric from its quality estimation. Appendix A of RFC 6126bis gives an example of a suitable algorithm. Rationale: support for wireless transit links is a distinguishing feature of Homenet, and one that is requested by our users. In the absence of dynamically computed metrics, the routing protocol Chroboczek Expires January 19, 2019 [Page 4] Internet-Draft Homenet Babel profile July 2018 attempts to minimise the number of links crossed by a route, and therefore prefers long, lossy links to shorter, lossless ones. In wireless networks, "hop-count routing is worst-path routing". While it would be desirable to perform link-quality probing on some wired link technologies, notably power-line networks, these kinds of links tend to be difficult or impossible to detect automatically, and we are not aware of any published link-quality algorithms for them. Hence, we do not require link-quality estimation for wired links of any kind. 2.2. Optional features OPT1: a Homenet implementation of Babel MAY perform route selection by applying hysteresis to route metrics, as suggested in Section 3.6 of RFC 6126bis and described in detail in Section III.E of [BABEL-RTT]. However, hysteresis is not required, and the implementation may simply pick the route with the smallest metric. Rationale: hysteresis is only useful in congested and highly dynamic networks. In a typical home network, stable and uncongested, the feedback loop that hysteresis compensates for does not occur. OPT2: a Homenet implementation of Babel may include support for other extensions to the protocol, as long as they are known to interoperate with both the core protocol and source-specific routing. Rationale: a number of extensions to the Babel routing protocol have been defined over the years; however, they are useful in fairly specific situations, such as routing over global-scale overlay networks [BABEL-RTT] or multi-hop wireless networks with multiple radio frequencies [BABEL-Z]. Hence, with the exception of source-specific routing, no extensions are required for Homenet. 3. Interactions between HNCP and Babel The Homenet architecture cleanly separates configuration, which is done by HNCP, from routing, which is done by Babel. While the coupling between the two protocols is deliberately kept to a minimum, some interactions are unavoidable. All the interactions between HNCP and Babel consist of HNCP causing Babel to perform an announcement on its behalf (under no circumstances does Babel cause HNCP to perform an action). How this is realised is an implementation detail that is outside the scope of this document; while it could conceivably be done using a private Chroboczek Expires January 19, 2019 [Page 5] Internet-Draft Homenet Babel profile July 2018 communication channel between HNCP and Babel, in existing implementations HNCP installs a route in the operating system's kernel which is later picked up by Babel using the existing redistribution mechanisms. 3.1. Requirements REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix P and publishes an External-Connection TLV containing a Delegated- Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST announce a source-specific default route with source prefix P over Babel. Rationale: source-specific routes are the main tool that Homenet uses to enable optimal routing in the presence of multiple IPv6 prefixes. External connections with non-trivial prefix policies are explicitly excluded from this requirement, since their exact behaviour is application-specific. REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address and wins the election for NAT gateway, then it MUST act as a NAT gateway and MUST announce a (non-specific) IPv4 default route over Babel. Rationale: the Homenet stack does not use source-specific routing for IPv4; instead, HNCP elects a single NAT gateway and publishes a single default route towards that gateway ([RFC7788] Section 6.5). REQ9: if an HNCP node assigns a prefix P to an attached link and announces P in an Assigned-Prefix TLV, then it MUST announce a route towards P over Babel. Rationale: prefixes assigned to links must be routable within the Homenet. 3.2. Optional features OPT3: an HNCP node that receives a DHCPv6 prefix delegation MAY announce a non-specific IPv6 default route over Babel in addition to the source-specific default route mandated by requirement REQ7. Rationale: since the source-specific default route is more specific than the non-specific default route, the former will override the latter if all nodes implement source-specific routing. Announcing an additional non-specific route is allowed, since doing that causes no harm and might simplify operations in Chroboczek Expires January 19, 2019 [Page 6] Internet-Draft Homenet Babel profile July 2018 some circumstances, e.g. when interoperating with a routing protocol that does not support source-specific routing. OPT4: an HNCP node that receives a DHCPv4 lease with an IPv4 address and wins the election for NAT gateway SHOULD NOT announce a source- specific IPv4 default route. Homenet does not require support for IPv4 source-specific routing. Announcing IPv4 source-specific routes will not cause routing pathologies (blackholes or routing loops), but it might cause packets sourced in different parts of the Homenet to follow different paths, with all the confusion that this entails. 4. Security Considerations Both HNCP and Babel carry their control data in IPv6 packets with a link-local source address, and implementations are required to drop packets sent from a global address. Hence, they are only susceptible to attacks from a directly connected link on which the HNCP and Babel implementations are listening. The security of a Homenet network relies on having a set of "Internal", "Ad Hoc" and "Hybrid" interfaces (Section 5.1 of [RFC7788]) that are assumed to be connected to links that are secured at a lower layer. HNCP and Babel packets are only accepted when they originate on these trusted links. "External" and "Guest" interfaces are connected to links that are not trusted, and any HNCP or Babel packets that are received on such interfaces are ignored. ("Leaf" interfaces are a special case, since they are connected to trusted links but HNCP and Babel traffic received on such interfaces is ignored.) This implies that the security of a Homenet network depends on the reliability of the border discovery procedure described in Section 5.3 of [RFC7788]. If untrusted links are used for transit, which is NOT RECOMMENDED, then any HNCP and Babel traffic that is carried over such links MUST be secured using an upper-layer security protocol. While both HNCP and Babel support cryptographic authentication, at the time of writing no protocol for autonomous configuration of HNCP and Babel security has been defined. 5. IANA Considerations This document requires no actions from IANA. Chroboczek Expires January 19, 2019 [Page 7] Internet-Draft Homenet Babel profile July 2018 6. Acknowledgments A number of people have helped with defining the requirements listed in this document. I am especially indebted to Barbara Stark and Markus Stenberg. 7. References 7.1. Normative References [BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", draft-ietf-babel-source-specific-03 (work in progress), August 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC6126bis] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04, October 2017. [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 7.2. Informative References [BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", draft-jonglez- babel-rtt-extension-01 (work in progress), May 2015. [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", draft-chroboczek-babel-diversity-routing-01 (work in progress), February 2016. [DELAY-BASED] Jonglez, B. and J. Chroboczek, "A delay-based routing metric", March 2014. Available online from http://arxiv.org/abs/1403.3488 Chroboczek Expires January 19, 2019 [Page 8] Internet-Draft Homenet Babel profile July 2018 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, July 2014. [ToS-SPECIFIC] Chouasne, G., "https://tools.ietf.org/id/ draft-chouasne-babel-tos-specific-00.xml", draft-chouasne- babel-tos-specific-00 (work in progress), July 2017. Author's Address Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@irif.fr Chroboczek Expires January 19, 2019 [Page 9] ./draft-ietf-bess-dci-evpn-overlay-10.txt0000644000764400076440000020354313246335700017501 0ustar iustyiusty BESS Workgroup J. Rabadan (Ed.) Internet Draft S. Sathappan Intended status: Standards Track W. Henderickx Nokia A. Sajassi Cisco J. Drake Juniper Expires: September 3, 2018 March 2, 2018 Interconnect Solution for EVPN Overlay networks draft-ietf-bess-dci-evpn-overlay-10 Abstract This document describes how Network Virtualization Overlays (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPN) and other L2VPN technologies used in the WAN, such as Virtual Private LAN Services (VPLS), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how the existing technical specifications apply to the Interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, and the use of the Unknown MAC route to avoid MAC scale issues on Data Center Network Virtualization Edge (NVE) 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Rabadan et al. Expires September 3, 2018 [Page 1] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 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 September 3, 2018. Copyright Notice Copyright (c) 2018 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. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Decoupled Interconnect solution for EVPN overlay networks . . . 6 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 7 3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 8 3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 8 3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 9 3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 9 3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 9 3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 10 3.5.3. Handling failures between GW and WAN Edge routers . . . 11 4. Integrated Interconnect solution for EVPN overlay networks . . 11 4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 12 4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 13 4.2.1. Control/Data Plane setup procedures on the GWs . . . . 13 4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 14 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 14 Rabadan et al. Expires September 3, 2018 [Page 2] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 4.3.1. Control/Data Plane setup procedures on the GWs . . . . 14 4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 15 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 15 4.4.1. Control Plane setup procedures on the GWs . . . . . . . 15 4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 17 4.4.3. Multi-homing procedure extensions on the GWs . . . . . 18 4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 20 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 20 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 21 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 22 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 22 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 22 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 23 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 23 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 23 4.6.1. Globally unique VNIs in the Interconnect network . . . 24 4.6.2. Downstream assigned VNIs in the Interconnect network . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . . 27 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. AC: Attachment Circuit. ARP: Address Resolution Protocol. BUM: refers to Broadcast, Unknown unicast and Multicast traffic. CE: Customer Equipment. CFM: Connectivity Fault Management. DC and DCI: Data Center and Data Center Interconnect. Rabadan et al. Expires September 3, 2018 [Page 3] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 DC RR(s) and WAN RR(s): refers to the Data Center and Wide Area Network Route Reflectors, respectively. DF and NDF: Designated Forwarder and Non-Designated Forwarder. EVPN: Ethernet Virtual Private Network, as in [RFC7432]. EVI: EVPN Instance. EVPN Tunnel binding: refers to a tunnel to a remote PE/NVE for a given EVI. Ethernet packets in these bindings are encapsulated with the Overlay or MPLS encapsulation and the EVPN label at the bottom of the stack. ES and vES: Ethernet Segment and virtual Ethernet Segment. ESI: Ethernet Segment Identifier. GW: Gateway or Data Center Gateway. I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect Ethernet Segment Identifier. An I-ES is defined on the GWs for multi- homing to/from the WAN. MAC-VRF: refers to an EVI instance in a particular node. MP2P and LSM tunnels: refer to Multi-Point to Point and Label Switched Multicast tunnels. ND: Neighbor Discovery protocol. NVE: Network Virtualization Edge. NVGRE: Network Virtualization using Generic Routing Encapsulation. NVO: refers to Network Virtualization Overlays. OAM: Operations and Maintenance. PBB: Provider Backbone Bridging. PE: Provider Edge. PW: Pseudowire. RD: Route-Distinguisher. RT: Route-Target. Rabadan et al. Expires September 3, 2018 [Page 4] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 S/C-TAG: refers to a combination of Service Tag and Customer Tag in a 802.1Q frame. TOR: Top-Of-Rack switch. UMR: Unknown MAC Route. VNI/VSID: refers to VXLAN/NVGRE virtual identifiers. VPLS: Virtual Private LAN Service. VSI: Virtual Switch Instance or VPLS instance in a particular PE. VXLAN: Virtual eXtensible LAN. 2. Introduction [EVPN-Overlays] discusses the use of Ethernet Virtual Private Networks (EVPN) [RFC7432] as the control plane for Network Virtualization Overlays (NVO), where VXLAN [RFC7348], NVGRE [RFC7637] or MPLS over GRE [RFC4023] can be used as possible data plane encapsulation options. While this model provides a scalable and efficient multi-tenant solution within the Data Center, it might not be easily extended to the Wide Area Network (WAN) in some cases due to the requirements and existing deployed technologies. For instance, a Service Provider might have an already deployed Virtual Private LAN Service (VPLS) [RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging (PBB-VPLS) [RFC7041], EVPN [RFC7432] or PBB-EVPN [RFC7623] network that has to be used to interconnect Data Centers and WAN VPN users. A Gateway (GW) function is required in these cases. In fact, [EVPN- Overlays] discusses two main Data Center Interconnect solution groups: "DCI using GWs" and "DCI using ASBRs". This document specifies the solutions that correspond to the "DCI using GWs" group. It is assumed that the NVO Gateway (GW) and the WAN Edge functions can be decoupled in two separate systems or integrated into the same system. The former option will be referred as "Decoupled Interconnect solution" throughout the document, whereas the latter one will be referred as "Integrated Interconnect solution". The specified procedures are local to the redundant GWs connecting a DC to the WAN. The document does not preclude any combination across different DCs for the same tenant. For instance, a "Decoupled" solution can be used in GW1 and GW2 (for DC1) and an "Integrated" solution can be used in GW3 and GW4 (for DC2). Rabadan et al. Expires September 3, 2018 [Page 5] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 While the Gateways and WAN PEs use existing specifications in some cases, the document also defines extensions that are specific to DCI. In particular, those extensions are: o The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that can be associated to a set of PWs or other tunnels. I-ES defined in this document is not associated with a set of Ethernet links, as per [RFC7432], but rather with a set of virtual tunnels (e.g., a set of PWs). This set of virtual tunnels is referred to as vES [VIRTUAL-ES]. o The use of the Unknown MAC route in a DCI scenario. o The processing of EVPN routes on Gateways with MAC-VRFs connecting EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN- Overlay networks. 3. Decoupled Interconnect solution for EVPN overlay networks This section describes the interconnect solution when the GW and WAN Edge functions are implemented in different systems. Figure 1 depicts the reference model described in this section. Note that, although not shown in Figure 1, GWs may have local ACs (Attachment Circuits). Rabadan et al. Expires September 3, 2018 [Page 6] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 +--+ |CE| +--+ | +----+ +----| PE |----+ +---------+ | +----+ | +---------+ +----+ | +---+ +----+ +----+ +---+ | +----+ |NVE1|--| | | |WAN | |WAN | | | |--|NVE3| +----+ | |GW1|--|Edge| |Edge|--|GW3| | +----+ | +---+ +----+ +----+ +---+ | | NVO-1 | | WAN | | NVO-2 | | +---+ +----+ +----+ +---+ | | | | |WAN | |WAN | | | | +----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+ |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| +----+ +---------+ | | +---------+ +----+ +--------------+ |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| hand-off hand-off Figure 1 Decoupled Interconnect model The following section describes the interconnect requirements for this model. 3.1. Interconnect requirements The Decoupled Interconnect architecture is intended to be deployed in networks where the EVPN-Overlay and WAN providers are different entities and a clear demarcation is needed. This solution solves the following requirements: o A simple connectivity hand-off between the EVPN-Overlay network provider and the WAN provider so that QoS and security enforcement is easily accomplished. o Independence of the Layer Two VPN (L2VPN) technology deployed in the WAN. o Multi-homing between GW and WAN Edge routers, including per-service load balancing. Per-flow load balancing is not a strong requirement since a deterministic path per service is usually required for an easy QoS and security enforcement. o Support of Ethernet OAM and Connectivity Fault Management (CFM) [802.1AG][Y.1731] functions between the GW and the WAN Edge router Rabadan et al. Expires September 3, 2018 [Page 7] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 to detect individual AC failures. o Support for the following optimizations at the GW: + Flooding reduction of unknown unicast traffic sourced from the DC Network Virtualization Edge devices (NVEs). + Control of the WAN MAC addresses advertised to the DC. + Address Resolution Protocol (ARP) and Neighbor Discovery (ND) flooding control for the requests coming from the WAN. 3.2. VLAN-based hand-off In this option, the hand-off between the GWs and the WAN Edge routers is based on VLANs [802.1Q-2014]. This is illustrated in Figure 1 (between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in the GW is connected to a different VSI/MAC-VRF instance in the WAN Edge router by using a different C-TAG VLAN ID or a different combination of S/C-TAG VLAN IDs that matches at both sides. This option provides the best possible demarcation between the DC and WAN providers and it does not require control plane interaction between both providers. The disadvantage of this model is the provisioning overhead since the service has to be mapped to a C-TAG or S/C-TAG VLAN ID combination at both GW and WAN Edge routers. In this model, the GW acts as a regular Network Virtualization Edge (NVE) towards the DC. Its control plane, data plane procedures and interactions are described in [EVPN-Overlays]. The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with attachment circuits (ACs) to the GWs. Its functions are described in [RFC4761], [RFC4762], [RFC6074] or [RFC7432], [RFC7623]. 3.3. PW-based (Pseudowire-based) hand-off If MPLS between the GW and the WAN Edge router is an option, a PW- based Interconnect solution can be deployed. In this option the hand-off between both routers is based on FEC128-based PWs [RFC4762] or FEC129-based PWs (for a greater level of network automation) [RFC6074]. Note that this model still provides a clear demarcation boundary between DC and WAN (since there is a single PW between each MAC-VRF and peer VSI), and security/QoS policies may be applied on a per PW basis. This model provides better scalability than a C-TAG based hand-off and less provisioning overhead than a combined C/S-TAG hand-off. The PW-based hand-off interconnect is illustrated in Figure 1 (between the NVO-2 GWs and the WAN Edge routers). In this model, besides the usual MPLS procedures between GW and WAN Rabadan et al. Expires September 3, 2018 [Page 8] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 Edge router [RFC3031], the GW MUST support an interworking function in each MAC-VRF that requires extension to the WAN: o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI (WAN Edge), the corresponding VCID MUST be provisioned on the MAC- VRF and match the VCID used in the peer VSI at the WAN Edge router. o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used between the GW MAC-VRF and the WAN Edge VSI, the provisioning of the VPLS-ID MUST be supported on the MAC-VRF and MUST match the VPLS-ID used in the WAN Edge VSI. If a PW-based handoff is used, the GW's AC (or point of attachment to the EVPN Instance) uses a combination of a PW label and VLAN IDs. PWs are treated as service interfaces defined in [RFC7432]. 3.4. Multi-homing solution on the GWs EVPN single-active multi-homing, i.e. per-service load-balancing multi-homing is required in this type of interconnect. The GWs will be provisioned with a unique ES per WAN interconnect, and the hand-off attachment circuits or PWs between the GW and the WAN Edge router will be assigned an ESI for such ES. The ESI will be administratively configured on the GWs according to the procedures in [RFC7432]. This Interconnect ES will be referred as "I-ES" hereafter, and its identifier will be referred as "I-ESI". [RFC7432] describes different ESI Types. The use of Type 0 for the I-ESI is RECOMMENDED in this document. The solution (on the GWs) MUST follow the single-active multi-homing procedures as described in [EVPN-Overlays] for the provisioned I-ESI, i.e. Ethernet A-D routes per ES and per EVI will be advertised to the DC NVEs for the multi-homing functions, ES routes will be advertised so that ES discovery and Designated Forwarder (DF) procedures can be followed. The MAC addresses learned (in the data plane) on the hand- off links will be advertised with the I-ESI encoded in the ESI field. 3.5. Gateway Optimizations The following GW features are optional and optimize the control plane and data plane in the DC. 3.5.1. MAC Address Advertisement Control The use of EVPN in NVO networks brings a significant number of benefits as described in [EVPN-Overlays]. However, if multiple DCs Rabadan et al. Expires September 3, 2018 [Page 9] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 are interconnected into a single EVI, each DC will have to import all of the MAC addresses from each of the other DCs. Even if optimized BGP techniques like RT-constraint [RFC4684] are used, the number of MAC addresses to advertise or withdraw (in case of failure) by the GWs of a given DC could overwhelm the NVEs within that DC, particularly when the NVEs reside in the hypervisors. The solution specified in this document uses the 'Unknown MAC Route' (UMR) which is advertised into a given DC by each of the DC's GWs. This route is defined in [RFC7543] and is a regular EVPN MAC/IP Advertisement route in which the MAC Address Length is set to 48, the MAC address is set to 0, and the ESI field is set to the DC GW's I- ESI. An NVE within that DC that understands and process the UMR will send unknown unicast frames to one of the DCs GWs, which will then forward that packet to the correct egress PE. Note that, because the ESI is set to the DC GW's I-ESI, all-active multi-homing can be applied to unknown unicast MAC addresses. An NVE that does not understand the Unknown MAC route will handle unknown unicast as described in [RFC7432]. This document proposes that local policy determines whether MAC addresses and/or the UMR are advertised into a given DC. As an example, when all the DC MAC addresses are learned in the control/management plane, it may be appropriate to advertise only the UMR. Advertising all the DC MAC addresses in the control/management plane is usually the case when the NVEs reside in hypervisors. Refer to [EVPN-Overlays] section 7. It is worth noting that the UMR usage in [RFC7543] and the UMR usage in this document are different. In the former, a Virtual Spoke (V- spoke) does not necessarily learn all the MAC addresses pertaining to hosts in other V-spokes of the same network. The communication between two V-spokes is done through the DMG, until the V-spokes learn each other's MAC addresses. In this document, two leaf switches in the same DC are recommended to learn each other's MAC addresses for the same EVI. The leaf to leaf communication is always direct and does not go through the GW. 3.5.2. ARP/ND flooding control Another optimization mechanism, naturally provided by EVPN in the GWs, is the Proxy ARP/ND function. The GWs should build a Proxy ARP/ND cache table as per [RFC7432]. When the active GW receives an ARP/ND request/solicitation coming from the WAN, the GW does a Proxy Rabadan et al. Expires September 3, 2018 [Page 10] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 ARP/ND table lookup and replies as long as the information is available in its table. This mechanism is especially recommended on the GWs, since it protects the DC network from external ARP/ND-flooding storms. 3.5.3. Handling failures between GW and WAN Edge routers Link/PE failures are handled on the GWs as specified in [RFC7432]. The GW detecting the failure will withdraw the EVPN routes as per [RFC7432]. Individual AC/PW failures may be detected by OAM mechanisms. For instance: o If the Interconnect solution is based on a VLAN hand-off, Ethernet- CFM [802.1AG][Y.1731] may be used to detect individual AC failures on both, the GW and WAN Edge router. An individual AC failure will trigger the withdrawal of the corresponding A-D per EVI route as well as the MACs learned on that AC. o If the Interconnect solution is based on a PW hand-off, the Label Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be used to detect individual PW failures on both, the GW and WAN Edge router. 4. Integrated Interconnect solution for EVPN overlay networks When the DC and the WAN are operated by the same administrative entity, the Service Provider can decide to integrate the GW and WAN Edge PE functions in the same router for obvious CAPEX and OPEX saving reasons. This is illustrated in Figure 2. Note that this model does not provide an explicit demarcation link between DC and WAN anymore. Although not shown in Figure 2, note that the GWs may have local ACs. Rabadan et al. Expires September 3, 2018 [Page 11] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 +--+ |CE| +--+ | +----+ +----| PE |----+ +---------+ | +----+ | +---------+ +----+ | +---+ +---+ | +----+ |NVE1|--| | | | | |--|NVE3| +----+ | |GW1| |GW3| | +----+ | +---+ +---+ | | NVO-1 | WAN | NVO-2 | | +---+ +---+ | | | | | | | +----+ | |GW2| |GW4| | +----+ |NVE2|--| +---+ +---+ |--|NVE4| +----+ +---------+ | | +---------+ +----+ +--------------+ |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->| |<--PBB-VPLS-->| Interconnect -> |<-EVPN-MPLS-->| options |<--EVPN-Ovl-->|* |<--PBB-EVPN-->| Figure 2 Integrated Interconnect model * EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option). 4.1. Interconnect requirements The Integrated Interconnect solution meets the following requirements: o Control plane and data plane interworking between the EVPN-overlay network and the L2VPN technology supported in the WAN, irrespective of the technology choice, i.e. (PBB-)VPLS or (PBB-)EVPN, as depicted in Figure 2. o Multi-homing, including single-active multi-homing with per-service load balancing or all-active multi-homing, i.e. per-flow load- balancing, as long as the technology deployed in the WAN supports it. o Support for end-to-end MAC Mobility, Static MAC protection and other procedures (e.g. proxy-arp) described in [RFC7432] as long as EVPN-MPLS is the technology of choice in the WAN. Rabadan et al. Expires September 3, 2018 [Page 12] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o Independent inclusive multicast trees in the WAN and in the DC. That is, the inclusive multicast tree type defined in the WAN does not need to be the same as in the DC. 4.2. VPLS Interconnect for EVPN-Overlay networks 4.2.1. Control/Data Plane setup procedures on the GWs Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that different route-targets for the DC and for the WAN are normally required (unless [RFC4762] is used in the WAN, in which case no WAN route-target is needed). A single type-1 RD per service may be used. In order to support multi-homing, the GWs will be provisioned with an I-ESI (see section 3.4), that will be unique per interconnection. The I-ES in this case will represent the group of PWs to the WAN PEs and GWs. All the [RFC7432] procedures are still followed for the I-ES, e.g. any MAC address learned from the WAN will be advertised to the DC with the I-ESI in the ESI field. A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have two different types of tunnel bindings instantiated in two different split-horizon-groups: o VPLS PWs will be instantiated in the "WAN split-horizon-group". o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated in the "DC split-horizon-group". Attachment circuits are also supported on the same MAC-VRF (although not shown in Figure 2), but they will not be part of any of the above split-horizon-groups. Traffic received in a given split-horizon-group will never be forwarded to a member of the same split-horizon-group. As far as BUM flooding is concerned, a flooding list will be composed of the sub-list created by the inclusive multicast routes and the sub-list created for VPLS in the WAN. BUM frames received from a local Attachment Circuit (AC) will be forwarded to the flooding list. BUM frames received from the DC or the WAN will be forwarded to the flooding list observing the split-horizon-group rule described above. Note that the GWs are not allowed to have an EVPN binding and a PW to the same far-end within the same MAC-VRF, so that loops and packet duplication are avoided. In case a GW can successfully establish Rabadan et al. Expires September 3, 2018 [Page 13] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 both, an EVPN binding and a PW to the same far-end PE, the EVPN binding will prevail and the PW will be brought operationally down. The optimizations procedures described in section 3.5 can also be applied to this model. 4.2.2. Multi-homing procedures on the GWs This model supports single-active multi-homing on the GWs. All-active multi-homing is not supported by VPLS, therefore it cannot be used on the GWs. In this case, for a given EVI, all the PWs in the WAN split-horizon- group are assigned to I-ES. All the single-active multi-homing procedures as described by [EVPN-Overlays] will be followed for the I-ES. The non-DF GW for the I-ES will block the transmission and reception of all the PWs in the "WAN split-horizon-group" for BUM and unicast traffic. 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks 4.3.1. Control/Data Plane setup procedures on the GWs In this case, there is no impact on the procedures described in [RFC7041] for the B-component. However the I-component instances become EVI instances with EVPN-Overlay bindings and potentially local attachment circuits. A number of MAC-VRF instances can be multiplexed into the same B-component instance. This option provides significant savings in terms of PWs to be maintained in the WAN. The I-ESI concept described in section 4.2.1 will also be used for the PBB-VPLS-based Interconnect. B-component PWs and I-component EVPN-overlay bindings established to the same far-end will be compared. The following rules will be observed: o Attempts to setup a PW between the two GWs within the B- component context will never be blocked. o If a PW exists between two GWs for the B-component and an attempt is made to setup an EVPN binding on an I-component linked to that B-component, the EVPN binding will be kept operationally down. Note that the BGP EVPN routes will still be valid but not used. Rabadan et al. Expires September 3, 2018 [Page 14] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o The EVPN binding will only be up and used as long as there is no PW to the same far-end in the corresponding B-component. The EVPN bindings in the I-components will be brought down before the PW in the B-component is brought up. The optimizations procedures described in section 3.5 can also be applied to this Interconnect option. 4.3.2. Multi-homing procedures on the GWs This model supports single-active multi-homing on the GWs. All-active multi-homing is not supported by this scenario. The single-active multi-homing procedures as described by [EVPN- Overlays] will be followed for the I-ES for each EVI instance connected to the B-component. Note that in this case, for a given EVI, all the EVPN bindings in the I-component are assigned to the I- ES. The non-DF GW for the I-ES will block the transmission and reception of all the I-component EVPN bindings for BUM and unicast traffic. When learning MACs from the WAN, the non-DF MUST NOT advertise EVPN MAC/IP routes for those MACs. 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the WAN, an end-to-end EVPN solution can be deployed. The following sections describe the proposed solution as well as the impact required on the [RFC7432] procedures. 4.4.1. Control Plane setup procedures on the GWs The GWs MUST establish separate BGP sessions for sending/receiving EVPN routes to/from the DC and to/from the WAN. Normally each GW will setup one BGP EVPN session to the DC RR (or two BGP EVPN sessions if there are redundant DC RRs) and one session to the WAN RR (or two sessions if there are redundant WAN RRs). In order to facilitate separate BGP processes for DC and WAN, EVPN routes sent to the WAN SHOULD carry a different route-distinguisher (RD) than the EVPN routes sent to the DC. In addition, although reusing the same value is possible, different route-targets are expected to be handled for the same EVI in the WAN and the DC. Note that the EVPN service routes sent to the DC RRs will normally include a [TUNNEL-ENCAP] BGP encapsulation extended community with a different tunnel type than the one sent to the WAN RRs. As in the other discussed options, an I-ES and its assigned I-ESI Rabadan et al. Expires September 3, 2018 [Page 15] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 will be configured on the GWs for multi-homing. This I-ES represents the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to the WAN. Optionally, different I-ESI values are configured for representing the WAN and the DC. If different EVPN-Overlay networks are connected to the same group of GWs, each EVPN-Overlay network MUST get assigned a different I-ESI. Received EVPN routes will never be reflected on the GWs but consumed and re-advertised (if needed): o Ethernet A-D routes, ES routes and Inclusive Multicast routes are consumed by the GWs and processed locally for the corresponding [RFC7432] procedures. o MAC/IP advertisement routes will be received, imported and if they become active in the MAC-VRF, the information will be re- advertised as new routes with the following fields: + The RD will be the GW's RD for the MAC-VRF. + The ESI will be set to the I-ESI. + The Ethernet-tag value will be kept from the received NLRI. + The MAC length, MAC address, IP Length and IP address values will be kept from the received NLRI. + The MPLS label will be a local 20-bit value (when sent to the WAN) or a DC-global 24-bit value (when sent to the DC for encapsulations using a VNI). + The appropriate Route-Targets (RTs) and [TUNNEL-ENCAP] BGP Encapsulation extended community will be used according to [EVPN-Overlays]. The GWs will also generate the following local EVPN routes that will be sent to the DC and WAN, with their corresponding RTs and [TUNNEL- ENCAP] BGP Encapsulation extended community values: o ES route(s) for the I-ESI(s). o Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D per-EVI routes sent to the WAN and the DC will have consistent Ethernet-Tag values. o Inclusive Multicast routes with independent tunnel type value for the WAN and DC. E.g. a P2MP LSP may be used in the WAN whereas ingress replication may be used in the DC. The routes Rabadan et al. Expires September 3, 2018 [Page 16] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 sent to the WAN and the DC will have a consistent Ethernet-Tag. o MAC/IP advertisement routes for MAC addresses learned in local attachment circuits. Note that these routes will not include the I-ESI, but ESI=0 or different from 0 for local multi-homed Ethernet Segments (ES). The routes sent to the WAN and the DC will have a consistent Ethernet-Tag. Assuming GW1 and GW2 are peer GWs of the same DC, each GW will generate two sets of the above local service routes: Set-DC will be sent to the DC RRs and will include A-D per EVI, Inclusive Multicast and MAC/IP routes for the DC encapsulation and RT. Set-WAN will be sent to the WAN RRs and will include the same routes but using the WAN RT and encapsulation. GW1 and GW2 will receive each other's set- DC and set-WAN. This is the expected behavior on GW1 and GW2 for locally generated routes: o Inclusive multicast routes: when setting up the flooding lists for a given MAC-VRF, each GW will include its DC peer GW only in the EVPN-MPLS flooding list (by default) and not the EVPN- Overlay flooding list. That is, GW2 will import two Inclusive Multicast routes from GW1 (from set-DC and set-WAN) but will only consider one of the two, having the set-WAN route higher priority. An administrative option MAY change this preference so that the set-DC route is selected first. o MAC/IP advertisement routes for local attachment circuits: as above, the GW will select only one, having the route from the set-WAN a higher priority. As with the Inclusive multicast routes, an administrative option MAY change this priority. 4.4.2. Data Plane setup procedures on the GWs The procedure explained at the end of the previous section will make sure there are no loops or packet duplication between the GWs of the same EVPN-Overlay network (for frames generated from local ACs) since only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN- aware bundle services) will be setup in the data plane between the two nodes. That binding will by default be added to the EVPN-MPLS flooding list. As for the rest of the EVPN tunnel bindings, they will be added to one of the two flooding lists that each GW sets up for the same MAC- VRF: o EVPN-overlay flooding list (composed of bindings to the remote NVEs or multicast tunnel to the NVEs). Rabadan et al. Expires September 3, 2018 [Page 17] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the remote PEs) Each flooding list will be part of a separate split-horizon-group: the WAN split-horizon-group or the DC split-horizon-group. Traffic generated from a local AC can be flooded to both split-horizon-groups. Traffic from a binding of a split-horizon-group can be flooded to the other split-horizon-group and local ACs, but never to a member of its own split-horizon-group. When either GW1 or GW2 receive a BUM frame on an MPLS tunnel including an ESI label at the bottom of the stack, they will perform an ESI label lookup and split-horizon filtering as per [RFC7432] in case the ESI label identifies a local ESI (I-ESI or any other non- zero ESI). 4.4.3. Multi-homing procedure extensions on the GWs This model supports single-active as well as all-active multi-homing. All the [RFC7432] multi-homing procedures for the DF election on I- ES(s) as well as the backup-path (single-active) and aliasing (all- active) procedures will be followed on the GWs. Remote PEs in the EVPN-MPLS network will follow regular [RFC7432] aliasing or backup- path procedures for MAC/IP routes received from the GWs for the same I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes received with the same I-ESI. As far as the forwarding plane is concerned, by default, the EVPN- Overlay network will have an analogous behavior to the access ACs in [RFC7432] multi-homed Ethernet Segments. The forwarding behavior on the GWs is described below: o Single-active multi-homing; assuming a WAN split-horizon-group (comprised of EVPN-MPLS bindings), a DC split-horizon-group (comprised of EVPN-Overlay bindings) and local ACs on the GWs: + Forwarding behavior on the non-DF: the non-DF MUST block ingress and egress forwarding on the EVPN-Overlay bindings associated to the I-ES. The EVPN-MPLS network is considered to be the core network and the EVPN-MPLS bindings to the remote PEs and GWs will be active. + Forwarding behavior on the DF: the DF MUST NOT forward BUM or unicast traffic received from a given split-horizon-group to a member of his own split-horizon group. Forwarding to other Rabadan et al. Expires September 3, 2018 [Page 18] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 split-horizon-groups and local ACs is allowed (as long as the ACs are not part of an ES for which the node is non-DF). As per [RFC7432] and for split-horizon purposes, when receiving BUM traffic on the EVPN-Overlay bindings associated to an I- ES, the DF GW SHOULD add the I-ESI label when forwarding to the peer GW over EVPN-MPLS. + When receiving EVPN MAC/IP routes from the WAN, the non-DF MUST NOT re-originate the EVPN routes and advertise them to the DC peers. In the same way, EVPN MAC/IP routes received from the DC MUST NOT be advertised to the WAN peers. This is consistent with [RFC7432] and allows the remote PE/NVEs know who the primary GW is, based on the reception of the MAC/IP routes. o All-active multi-homing; assuming a WAN split-horizon-group (comprised of EVPN-MPLS bindings), a DC split-horizon-group (comprised of EVPN-Overlay bindings) and local ACs on the GWs: + Forwarding behavior on the non-DF: the non-DF follows the same behavior as the non-DF in the single-active case but only for BUM traffic. Unicast traffic received from a split-horizon- group MUST NOT be forwarded to a member of its own split- horizon-group but can be forwarded normally to the other split-horizon-groups and local ACs. If a known unicast packet is identified as a "flooded" packet, the procedures for BUM traffic MUST be followed. + Forwarding behavior on the DF: the DF follows the same behavior as the DF in the single-active case but only for BUM traffic. Unicast traffic received from a split-horizon-group MUST NOT be forwarded to a member of its own split-horizon- group but can be forwarded normally to the other split- horizon-group and local ACs. If a known unicast packet is identified as a "flooded" packet, the procedures for BUM traffic MUST be followed. As per [RFC7432] and for split- horizon purposes, when receiving BUM traffic on the EVPN- Overlay bindings associated to an I-ES, the DF GW MUST add the I-ESI label when forwarding to the peer GW over EVPN-MPLS. + Contrary to the single-active multi-homing case, both DF and non-DF re-originate and advertise MAC/IP routes received from the WAN/DC peers, adding the corresponding I-ESI so that the remote PE/NVEs can perform regular aliasing as per [RFC7432]. The example in Figure 3 illustrates the forwarding of BUM traffic originated from an NVE on a pair of all-active multi-homing GWs. Rabadan et al. Expires September 3, 2018 [Page 19] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 |<--EVPN-Overlay--->|<--EVPN-MPLS-->| +---------+ +--------------+ +----+ BUM +---+ | |NVE1+----+----> | +-+-----+ | +----+ | | DF |GW1| | | | | | +-+-+ | | ++--+ | | | | +--> |PE1| | +--->X +-+-+ | ++--+ | NDF| | | | +----+ | |GW2<-+ | |NVE2+--+ +-+-+ | +----+ +--------+ | +------------+ v +--+ |CE| +--+ Figure 3 Multi-homing BUM forwarding GW2 is the non-DF for the I-ES and blocks the BUM forwarding. GW1 is the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2 will include the ESI-label for the I-ES. Based on the ESI-label, GW2 identifies the packets as I-ES-generated packets and will only forward them to local ACs (CE in the example) and not back to the EVPN-Overlay network. 4.4.4. Impact on MAC Mobility procedures MAC Mobility procedures described in [RFC7432] are not modified by this document. Note that an intra-DC MAC move still leaves the MAC attached to the same I-ES, so under the rules of [RFC7432] this is not considered a MAC mobility event. Only when the MAC moves from the WAN domain to the DC domain (or from one DC to another) the MAC will be learned from a different ES and the MAC Mobility procedures will kick in. The sticky bit indication in the MAC Mobility extended community MUST be propagated between domains. 4.4.5. Gateway optimizations All the Gateway optimizations described in section 3.5 MAY be applied to the GWs when the Interconnect is based on EVPN-MPLS. In particular, the use of the Unknown MAC Route, as described in Rabadan et al. Expires September 3, 2018 [Page 20] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 section 3.5.1, solves some transient packet duplication issues in cases of all-active multi-homing, as explained below. Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all- active multi-homing, and the following sequence: a) MAC Address M1 is advertised from NVE3 in EVI-1. b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN with I-ESI-2 in the ESI field. c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following the EVPN aliasing procedures. d) Before NVE1 learns M1, a packet arrives at NVE1 with destination M1. If the Unknown MAC Route had not been advertised into the DC, NVE1 would have flooded the packet throughout the DC, in particular to both GW1 and GW2. If the same VNI/VSID is used for both known unicast and BUM traffic, as is typically the case, there is no indication in the packet that it is a BUM packet and both GW1 and GW2 would have forwarded it, creating packet duplication. However, because the Unknown MAC Route had been advertised into the DC, NVE1 will unicast the packet to either GW1 or GW2. e) Since both GW1 and GW2 know M1, the GW receiving the packet will forward it to either GW3 or GW4. 4.4.6. Benefits of the EVPN-MPLS Interconnect solution The [EVPN-Overlays] "DCI using ASBRs" solution and the GW solution with EVPN-MPLS Interconnect may be seen similar since they both retain the EVPN attributes between Data Centers and throughout the WAN. However the EVPN-MPLS Interconnect solution on the GWs has significant benefits compared to the "DCI using ASBRs" solution: o As in any of the described GW models, this solution supports the connectivity of local attachment circuits on the GWs. This is not possible in a "DCI using ASBRs" solution. o Different data plane encapsulations can be supported in the DC and the WAN, while a uniform encapsulation is needed in the "DCI using ASBRs" solution. o Optimized multicast solution, with independent inclusive multicast trees in DC and WAN. Rabadan et al. Expires September 3, 2018 [Page 21] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o MPLS Label aggregation: for the case where MPLS labels are signaled from the NVEs for MAC/IP Advertisement routes, this solution provides label aggregation. A remote PE MAY receive a single label per GW MAC-VRF as opposed to a label per NVE/MAC- VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE would receive only one label for all the routes advertised for a given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF. o The GW will not propagate MAC mobility for the MACs moving within a DC. Mobility intra-DC is solved by all the NVEs in the DC. The MAC Mobility procedures on the GWs are only required in case of mobility across DCs. o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce ARP/ND flooding in the DC or/and in the WAN. 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks PBB-EVPN [RFC7623] is yet another Interconnect option. It requires the use of GWs where I-components and associated B-components are part of EVI instances. 4.5.1. Control/Data Plane setup procedures on the GWs EVPN will run independently in both components, the I-component MAC- VRF and B-component MAC-VRF. Compared to [RFC7623], the DC C-MACs are no longer learned in the data plane on the GW but in the control plane through EVPN running on the I-component. Remote C-MACs coming from remote PEs are still learned in the data plane. B-MACs in the B- component will be assigned and advertised following the procedures described in [RFC7623]. An I-ES will be configured on the GWs for multi-homing, but its I-ESI will only be used in the EVPN control plane for the I-component EVI. No non-reserved ESIs will be used in the control plane of the B- component EVI as per [RFC7623], that is, the I-ES will be represented to the WAN PBB-EVPN PEs using shared or dedicated B-MACs. The rest of the control plane procedures will follow [RFC7432] for the I-component EVI and [RFC7623] for the B-component EVI. From the data plane perspective, the I-component and B-component EVPN bindings established to the same far-end will be compared and the I- component EVPN-overlay binding will be kept down following the rules described in section 4.3.1. 4.5.2. Multi-homing procedures on the GWs Rabadan et al. Expires September 3, 2018 [Page 22] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 This model supports single-active as well as all-active multi-homing. The forwarding behavior of the DF and non-DF will be changed based on the description outlined in section 4.4.3, only replacing the "WAN split-horizon-group" for the B-component, and using [RFC7623] procedures for the traffic sent or received on the B-component. 4.5.3. Impact on MAC Mobility procedures C-MACs learned from the B-component will be advertised in EVPN within the I-component EVI scope. If the C-MAC was previously known in the I-component database, EVPN would advertise the C-MAC with a higher sequence number, as per [RFC7432]. From a Mobility perspective and the related procedures described in [RFC7432], the C-MACs learned from the B-component are considered local. 4.5.4. Gateway optimizations All the considerations explained in section 4.4.5 are applicable to the PBB-EVPN Interconnect option. 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks If EVPN for Overlay tunnels is supported in the WAN and a GW function is required, an end-to-end EVPN solution can be deployed. While multiple Overlay tunnel combinations at the WAN and the DC are possible (MPLSoGRE, nvGRE, etc.), VXLAN is described here, given its popularity in the industry. This section focuses on the specific case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the [RFC7432] procedures. The procedures described in section 4.4 apply to this section too, only replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and using [EVPN-Overlays] "Local Bias" procedures instead of section 4.4.3. Since there are no ESI-labels in VXLAN, GWs need to rely on "Local Bias" to apply split-horizon on packets generated from the I- ES and sent to the peer GW. This use-case assumes that NVEs need to use the VNIs or VSIDs as a globally unique identifiers within a data center, and a Gateway needs to be employed at the edge of the data center network to translate the VNI or VSID when crossing the network boundaries. This GW function provides VNI and tunnel IP address translation. The use-case in which local downstream assigned VNIs or VSIDs can be used (like MPLS labels) is described by [EVPN-Overlays]. While VNIs are globally significant within each DC, there are two possibilities in the Interconnect network: Rabadan et al. Expires September 3, 2018 [Page 23] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 a) Globally unique VNIs in the Interconnect network: In this case, the GWs and PEs in the Interconnect network will agree on a common VNI for a given EVI. The RT to be used in the Interconnect network can be auto-derived from the agreed Interconnect VNI. The VNI used inside each DC MAY be the same as the Interconnect VNI. b) Downstream assigned VNIs in the Interconnect network. In this case, the GWs and PEs MUST use the proper RTs to import/export the EVPN routes. Note that even if the VNI is downstream assigned in the Interconnect network, and unlike option (a), it only identifies the pair and not the pair. The VNI used inside each DC MAY be the same as the Interconnect VNI. GWs SHOULD support multiple VNI spaces per EVI (one per Interconnect network they are connected to). In both options, NVEs inside a DC only have to be aware of a single VNI space, and only GWs will handle the complexity of managing multiple VNI spaces. In addition to VNI translation above, the GWs will provide translation of the tunnel source IP for the packets generated from the NVEs, using their own IP address. GWs will use that IP address as the BGP next-hop in all the EVPN updates to the Interconnect network. The following sections provide more details about these two options. 4.6.1. Globally unique VNIs in the Interconnect network Considering Figure 2, if a host H1 in NVO-1 needs to communicate with a host H2 in NVO-2, and assuming that different VNIs are used in each DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs MUST be translated to a common Interconnect VNI (e.g. VNI- 100) on the GWs. Each GW is provisioned with a VNI translation mapping so that it can translate the VNI in the control plane when sending BGP EVPN route updates to the Interconnect network. In other words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the BGP update messages for H1's MAC route. This mapping is also used to translate the VNI in the data plane in both directions, that is, VNI- 10 to VNI-100 when the packet is received from NVO-1 and the reverse mapping from VNI-100 to VNI-10 when the packet is received from the remote NVO-2 network and needs to be forwarded to NVO-1. The procedures described in section 4.4 will be followed, considering that the VNIs advertised/received by the GWs will be translated accordingly. 4.6.2. Downstream assigned VNIs in the Interconnect network Rabadan et al. Expires September 3, 2018 [Page 24] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 In this case, if a host H1 in NVO-1 needs to communicate with a host H2 in NVO-2, and assuming that different VNIs are used in each DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs MUST be translated as in section 4.6.1. However, in this case, there is no need to translate to a common Interconnect VNI on the GWs. Each GW can translate the VNI received in an EVPN update to a locally assigned VNI advertised to the Interconnect network. Each GW can use a different Interconnect VNI, hence this VNI does not need to be agreed on all the GWs and PEs of the Interconnect network. The procedures described in section 4.4 will be followed, taking the considerations above for the VNI translation. 5. Security Considerations This document applies existing specifications to a number of Interconnect models. The Security Considerations included in those documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761] and [RFC4762] apply to this document whenever those technologies are used. As discussed, [EVPN-Overlays] discusses two main DCI solution groups: "DCI using GWs" and "DCI using ASBRs". This document specifies the solutions that correspond to the "DCI using GWs" group. It is important to note that the use of GWs provide a superior level of security on a per tenant basis, compared to the use of ASBRs. This is due to the fact that GWs need to perform a MAC lookup on the frames being received from the WAN, and they apply security procedures, such as filtering of undesired frames, filtering of frames with a source MAC that matches a protected MAC in the DC or application of MAC duplication procedures defined in [RFC7432]. On ASBRs though, traffic is forwarded based on a label or VNI swap and there is usually no visibility of the encapsulated frames, which can carry malicious traffic. In addition, the GW optimizations specified in this document, provide additional protection of the DC Tenant Systems. For instance, the MAC address advertisement control and Unknown MAC Route defined in section 3.5.1 protect the DC NVEs from being overwhelmed with an excessive number MAC/IP routes being learned on the GWs from the WAN. The ARP/ND flooding control described in 3.5.2 can reduce/suppress broadcast storms being injected from the WAN. Finally, the reader should be aware of the potential security implications of designing a DCI with the Decoupled Interconnect solution (section 3) or the Integrated Interconnect solution (section 4). In the Decoupled Interconnect solution the DC is typically easier Rabadan et al. Expires September 3, 2018 [Page 25] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 to protect from the WAN, since each GW has a single logical link to one WAN PE, whereas in the Integrated solution, the GW has logical links to all the WAN PEs that are attached to the tenant. In either model, proper control plane and data plane policies should be put in place in the GWs in order to protect the DC from potential attacks coming from the WAN. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [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, . [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, . [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, . [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 10.17487/RFC7041, November 2013, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC Rabadan et al. Expires September 3, 2018 [Page 26] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress, January 11, 2018. [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, . [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt, work in progress, January 2018. [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, "Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI 10.17487/RFC7543, May 2015, . 7.2. Informative References [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, . [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., et al., "NVGRE: Network Virtualization using Generic Routing Encapsulation", RFC 7637, September, 2015 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, . [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms for Ethernet based networks", July 2011. Rabadan et al. Expires September 3, 2018 [Page 27] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 [802.1AG] IEEE 802.1AG_2007, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", January 2008. [802.1Q-2014] IEEE 802.1Q-2014, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", December 2014. [RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, February 2013, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [VIRTUAL-ES] Sajassi et al., "EVPN Virtual Ethernet Segment", draft- sajassi-bess-evpn-virtual-eth-segment-03, work in progress, February 2018. 8. Acknowledgments The authors would like to thank Neil Hart, Vinod Prabhu and Kiran Nagaraj for their valuable comments and feedback. We would also like to thank Martin Vigoureux and Alvaro Retana for his detailed review and comments. 9. Contributors In addition to the authors listed on the front page, the following co-authors have also contributed to this document: Ravi Shekhar Anil Lohiya Wen Lin Juniper Networks Florin Balus Patrice Brissette Cisco Senad Palislamovic Nokia Dennis Cai Alibaba Rabadan et al. Expires September 3, 2018 [Page 28] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 10. Authors' Addresses Jorge Rabadan Nokia 777 E. Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com Senthil Sathappan Nokia Email: senthil.sathappan@nokia.com Wim Henderickx Nokia Email: wim.henderickx@nokia.com Ali Sajassi Cisco Email: sajassi@cisco.com John Drake Juniper Email: jdrake@juniper.net Rabadan et al. Expires September 3, 2018 [Page 29] ./draft-ietf-dnssd-hybrid-10.txt0000644000764400076440000026033413445701201015750 0ustar iustyiusty Internet Engineering Task Force S. Cheshire Internet-Draft Apple Inc. Intended status: Standards Track March 24, 2019 Expires: September 25, 2019 Discovery Proxy for Multicast DNS-Based Service Discovery draft-ietf-dnssd-hybrid-10 Abstract This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. 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 25, 2019. Copyright Notice Copyright (c) 2019 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. Cheshire Expires September 25, 2019 [Page 1] Internet-Draft Multicast Service Discovery Proxy March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Operational Analogy . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions and Terminology Used in this Document . . . . . . 7 4. Compatibility Considerations . . . . . . . . . . . . . . . . 7 5. Discovery Proxy Operation . . . . . . . . . . . . . . . . . . 8 5.1. Delegated Subdomain for Service Discovery Records . . . . 9 5.2. Domain Enumeration . . . . . . . . . . . . . . . . . . . 11 5.2.1. Domain Enumeration via Unicast Queries . . . . . . . 11 5.2.2. Domain Enumeration via Multicast Queries . . . . . . 13 5.3. Delegated Subdomain for LDH Host Names . . . . . . . . . 14 5.4. Delegated Subdomain for Reverse Mapping . . . . . . . . . 16 5.5. Data Translation . . . . . . . . . . . . . . . . . . . . 18 5.5.1. DNS TTL limiting . . . . . . . . . . . . . . . . . . 18 5.5.2. Suppressing Unusable Records . . . . . . . . . . . . 19 5.5.3. NSEC and NSEC3 queries . . . . . . . . . . . . . . . 20 5.5.4. No Text Encoding Translation . . . . . . . . . . . . 20 5.5.5. Application-Specific Data Translation . . . . . . . . 21 5.6. Answer Aggregation . . . . . . . . . . . . . . . . . . . 23 6. Administrative DNS Records . . . . . . . . . . . . . . . . . 27 6.1. DNS SOA (Start of Authority) Record . . . . . . . . . . . 27 6.2. DNS NS Records . . . . . . . . . . . . . . . . . . . . . 28 6.3. DNS Delegation Records . . . . . . . . . . . . . . . . . 28 6.4. DNS SRV Records . . . . . . . . . . . . . . . . . . . . . 29 7. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 30 7.1. On-line signing only . . . . . . . . . . . . . . . . . . 30 7.2. NSEC and NSEC3 Records . . . . . . . . . . . . . . . . . 30 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9.1. Authenticity . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Implementation Status . . . . . . . . . . . . . . . 38 A.1. Already Implemented and Deployed . . . . . . . . . . . . 38 A.2. Already Implemented . . . . . . . . . . . . . . . . . . . 38 A.3. Partially Implemented . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 Cheshire Expires September 25, 2019 [Page 2] Internet-Draft Multicast Service Discovery Proxy March 2019 1. Introduction Multicast DNS [RFC6762] and its companion technology DNS-based Service Discovery [RFC6763] were created to provide IP networking with the ease-of-use and autoconfiguration for which AppleTalk was well known [RFC6760] [ZC] [Roadmap]. For a small home network consisting of just a single link (or a few physical links bridged together to appear as a single logical link from the point of view of IP) Multicast DNS [RFC6762] is sufficient for client devices to look up the ".local" host names of peers on the same home network, and to use Multicast DNS-Based Service Discovery (DNS-SD) [RFC6763] to discover services offered on that home network. For a larger network consisting of multiple links that are interconnected using IP-layer routing instead of link-layer bridging, link-local Multicast DNS alone is insufficient because link-local Multicast DNS packets, by design, are not propagated onto other links. Using link-local multicast packets for Multicast DNS was a conscious design choice [RFC6762]. Even when limited to a single link, multicast traffic is still generally considered to be more expensive than unicast, because multicast traffic impacts many devices, instead of just a single recipient. In addition, with some technologies like Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and less reliable than unicast, because Wi-Fi multicast traffic is sent at lower data rates, and is not acknowledged [Mcast]. Increasing the amount of expensive multicast traffic by flooding it across multiple links would make the traffic load even worse. Partitioning the network into many small links curtails the spread of expensive multicast traffic, but limits the discoverability of services. At the opposite end of the spectrum, using a very large local link with thousands of hosts enables better service discovery, but at the cost of larger amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient and doesn't require large multicast domains, but does require that the relevant data be available in the Unicast DNS namespace. The Unicast DNS namespace in question could fall within a traditionally assigned globally unique domain name, or could use a private local unicast domain name such as ".home.arpa" [RFC8375]. In the DNS-SD specification [RFC6763], Section 10 ("Populating the DNS with Information") discusses various possible ways that a service's PTR, SRV, TXT and address records can make their way into the Unicast DNS namespace, including manual zone file configuration Cheshire Expires September 25, 2019 [Page 3] Internet-Draft Multicast Service Discovery Proxy March 2019 [RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies of various kinds. Making the relevant data available in the Unicast DNS namespace by manual DNS configuration is one option. This option has been used for many years at IETF meetings to advertise the IETF Terminal Room printer. Details of this example are given in Appendix A of the Roadmap document [Roadmap]. However, this manual DNS configuration is labor intensive, error prone, and requires a reasonable degree of DNS expertise. Populating the Unicast DNS namespace via DNS Update by the devices offering the services themselves is another option [RegProt] [DNS-UL]. However, this requires configuration of DNS Update keys on those devices, which has proven onerous and impractical for simple devices like printers and network cameras. Hence, to facilitate efficient and reliable DNS-Based Service Discovery, a compromise is needed that combines the ease-of-use of Multicast DNS with the efficiency and scalability of Unicast DNS. This document specifies a type of proxy called a "Discovery Proxy" that uses Multicast DNS [RFC6762] to discover Multicast DNS records on its local link, and makes corresponding DNS records visible in the Unicast DNS namespace. In principle, similar mechanisms could be defined using other local service discovery protocols, to discover local information and then make corresponding DNS records visible in the Unicast DNS namespace. Such mechanisms for other local service discovery protocols could be addressed in future documents. The design of the Discovery Proxy is guided by the previously published requirements document [RFC7558]. In simple terms, a descriptive DNS name is chosen for each link in an organization. Using a DNS NS record, responsibility for that DNS name is delegated to a Discovery Proxy physically attached to that link. Now, when a remote client issues a unicast query for a name falling within the delegated subdomain, the normal DNS delegation mechanism results in the unicast query arriving at the Discovery Proxy, since it has been declared authoritative for those names. Now, instead of consulting a textual zone file on disk to discover the answer to the query, as a traditional DNS server would, a Discovery Proxy consults its local link, using Multicast DNS, to find the answer to the question. Cheshire Expires September 25, 2019 [Page 4] Internet-Draft Multicast Service Discovery Proxy March 2019 For fault tolerance reasons there may be more than one Discovery Proxy serving a given link. Note that the Discovery Proxy uses a "pull" model. The local link is not queried using Multicast DNS until some remote client has requested that data. In the idle state, in the absence of client requests, the Discovery Proxy sends no packets and imposes no burden on the network. It operates purely "on demand". An alternative proposal that has been discussed is a proxy that performs DNS updates to a remote DNS server on behalf of the Multicast DNS devices on the local network. The difficulty with this is is that Multicast DNS devices do not routinely announce their records on the network. Generally they remain silent until queried. This means that the complete set of Multicast DNS records in use on a link can only be discovered by active querying, not by passive listening. Because of this, a proxy can only know what names exist on a link by issuing queries for them, and since it would be impractical to issue queries for every possible name just to find out which names exist and which do not, there is no reasonable way for a proxy to programmatically learn all the answers it would need to push up to the remote DNS server using DNS Update. Even if such a mechanism were possible, it would risk generating high load on the network continuously, even when there are no clients with any interest in that data. Hence, having a model where the query comes to the Discovery Proxy is much more efficient than a model where the Discovery Proxy pushes the answers out to some other remote DNS server. A client seeking to discover services and other information achieves this by sending traditional DNS queries to the Discovery Proxy, or by sending DNS Push Notification subscription requests [Push]. How a client discovers what domain name(s) to use for its service discovery queries, (and consequently what Discovery Proxy or Proxies to use) is described in Section 5.2. The diagram below illustrates a network topology using a Discovery Proxy to provide discovery service to a remote client. +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communcation | Discovery | | Network | | Network | | Client |---- . . . -----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) Cheshire Expires September 25, 2019 [Page 5] Internet-Draft Multicast Service Discovery Proxy March 2019 2. Operational Analogy A Discovery Proxy does not operate as a multicast relay, or multicast forwarder. There is no danger of multicast forwarding loops that result in traffic storms, because no multicast packets are forwarded. A Discovery Proxy operates as a *proxy* for a remote client, performing queries on its behalf and reporting the results back. A reasonable analogy is making a telephone call to a colleague at your workplace and saying, "I'm out of the office right now. Would you mind bringing up a printer browser window and telling me the names of the printers you see?" That entails no risk of a forwarding loop causing a traffic storm, because no multicast packets are sent over the telephone call. A similar analogy, instead of enlisting another human being to initiate the service discovery operation on your behalf, is to log into your own desktop work computer using screen sharing, and then run the printer browser yourself to see the list of printers. Or log in using ssh and type "dns-sd -B _ipp._tcp" and observe the list of discovered printer names. In neither case is there any risk of a forwarding loop causing a traffic storm, because no multicast packets are being sent over the screen sharing or ssh connection. The Discovery Proxy provides another way of performing remote queries, except using a different protocol instead of screen sharing or ssh. When the Discovery Proxy software performs Multicast DNS operations, the exact same Multicast DNS caching mechanisms are applied as when any other client software on that Discovery Proxy device performs Multicast DNS operations, whether that be running a printer browser client locally, or a remote user running the printer browser client via a screen sharing connection, or a remote user logged in via ssh running a command-line tool like "dns-sd", or a remote user sending DNS requests that cause a Discovery Proxy to perform discovery operations on its behalf. Cheshire Expires September 25, 2019 [Page 6] Internet-Draft Multicast Service Discovery Proxy March 2019 3. Conventions and Terminology Used in this Document 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 "Key words for use in RFCs to Indicate Requirement Levels", when, and only when, they appear in all capitals, as shown here [RFC2119] [RFC8174]. The Discovery Proxy builds on Multicast DNS, which works between hosts on the same link. For the purposes of this document a set of hosts is considered to be "on the same link" if: o when any host from that set sends a packet to any other host in that set, using unicast, multicast, or broadcast, the entire link- layer packet payload arrives unmodified, and o a broadcast sent over that link, by any host from that set of hosts, can be received by every other host in that set. The link-layer *header* may be modified, such as in Token Ring Source Routing [IEEE-5], but not the link-layer *payload*. In particular, if any device forwarding a packet modifies any part of the IP header or IP payload then the packet is no longer considered to be on the same link. This means that the packet may pass through devices such as repeaters, bridges, hubs or switches and still be considered to be on the same link for the purpose of this document, but not through a device such as an IP router that decrements the IP TTL or otherwise modifies the IP header. 4. Compatibility Considerations No changes to existing devices are required to work with a Discovery Proxy. Existing devices that advertise services using Multicast DNS work with Discovery Proxy. Existing clients that support DNS-Based Service Discovery over Unicast DNS work with Discovery Proxy. Service Discovery over Unicast DNS was introduced in Mac OS X 10.4 in April 2005, as is included in Apple products introduced since then, including iPhone and iPad, as well as products from other vendors, such as Microsoft Windows 10. An overview of the larger collection of related Service Discovery technologies, and how Discovery Proxy relates to those, is given in the Service Discovery Road Map document [Roadmap]. Cheshire Expires September 25, 2019 [Page 7] Internet-Draft Multicast Service Discovery Proxy March 2019 5. Discovery Proxy Operation In a typical configuration, a Discovery Proxy is configured to be authoritative [RFC1034] [RFC1035] for four or more DNS subdomains, and authority for these subdomains is delegated to it via NS records: A DNS subdomain for service discovery records. This subdomain name may contain rich text, including spaces and other punctuation. This is because this subdomain name is used only in graphical user interfaces, where rich text is appropriate. A DNS subdomain for host name records. This subdomain name SHOULD be limited to letters, digits and hyphens, to facilitate convenient use of host names in command- line interfaces. One or more DNS subdomains for IPv4 Reverse Mapping records. These subdomains will have names that ends in "in-addr.arpa." One or more DNS subdomains for IPv6 Reverse Mapping records. These subdomains will have names that ends in "ip6.arpa." In an enterprise network the naming and delegation of these subdomains is typically performed by conscious action of the network administrator. In a home network naming and delegation would typically be performed using some automatic configuration mechanism such as HNCP [RFC7788]. These three varieties of delegated subdomains (service discovery, host names, and reverse mapping) are described below in Section 5.1, Section 5.3 and Section 5.4. How a client discovers where to issue its service discovery queries is described below in Section 5.2. Cheshire Expires September 25, 2019 [Page 8] Internet-Draft Multicast Service Discovery Proxy March 2019 5.1. Delegated Subdomain for Service Discovery Records In its simplest form, each link in an organization is assigned a unique Unicast DNS domain name, such as "Building 1.example.com" or "2nd Floor.Building 3.example.com". Grouping multiple links under a single Unicast DNS domain name is to be specified in a future companion document, but for the purposes of this document, assume that each link has its own unique Unicast DNS domain name. In a graphical user interface these names are not displayed as strings with dots as shown above, but something more akin to a typical file browser graphical user interface (which is harder to illustrate in a text-only document) showing folders, subfolders and files in a file system. +---------------+--------------+-------------+-------------------+ | *example.com* | Building 1 | 1st Floor | Alice's printer | | | Building 2 | *2nd Floor* | Bob's printer | | | *Building 3* | 3rd Floor | Charlie's printer | | | Building 4 | 4th Floor | | | | Building 5 | | | | | Building 6 | | | +---------------+--------------+-------------+-------------------+ Figure 1: Illustrative GUI Each named link in an organization has one or more Discovery Proxies which serve it. This Discovery Proxy function for each link could be performed by a device like a router or switch that is physically attached to that link. In the parent domain, NS records are used to delegate ownership of each defined link name (e.g., "Building 1.example.com") to the one or more Discovery Proxies that serve the named link. In other words, the Discovery Proxies are the authoritative name servers for that subdomain. As in the rest of DNS-Based Service Discovery, all names are represented as-is using plain UTF-8 encoding, and, as described in Section 5.5.4, no text encoding translations are performed. With appropriate VLAN configuration [IEEE-1Q] a single Discovery Proxy device could have a logical presence on many links, and serve as the Discovery Proxy for all those links. In such a configuration the Discovery Proxy device would have a single physical Ethernet [IEEE-3] port, configured as a VLAN trunk port, which would appear to software on that device as multiple virtual Ethernet interfaces, one connected to each of the VLAN links. As an alternative to using VLAN technology, using a Multicast DNS Discovery Relay [Relay] is another way that a Discovery Proxy can have a 'virtual' presence on a remote link. Cheshire Expires September 25, 2019 [Page 9] Internet-Draft Multicast Service Discovery Proxy March 2019 When a DNS-SD client issues a Unicast DNS query to discover services in a particular Unicast DNS subdomain (e.g., "_printer._tcp.Building 1.example.com. PTR ?") the normal DNS delegation mechanism results in that query being forwarded until it reaches the delegated authoritative name server for that subdomain, namely the Discovery Proxy on the link in question. Like a conventional Unicast DNS server, a Discovery Proxy implements the usual Unicast DNS protocol [RFC1034] [RFC1035] over UDP and TCP. However, unlike a conventional Unicast DNS server that generates answers from the data in its manually-configured zone file, a Discovery Proxy generates answers using Multicast DNS. A Discovery Proxy does this by consulting its Multicast DNS cache and/or issuing Multicast DNS queries, as appropriate, according to the usual protocol rules of Multicast DNS [RFC6762], for the corresponding Multicast DNS name, type and class, with the delegated zone part of the name replaced with ".local" (e.g., in this case, "_printer._tcp.local. PTR ?"). Then, from the received Multicast DNS data, the Discovery Proxy synthesizes the appropriate Unicast DNS response, with the ".local" top-level label replaced with with the name of the delegated zone. How long the Discovery Proxy should wait to accumulate Multicast DNS responses before sending its unicast reply is described below in Section 5.6. The existing Multicast DNS caching mechanism is used to minimize unnecessary Multicast DNS queries on the wire. The Discovery Proxy is acting as a client of the underlying Multicast DNS subsystem, and benefits from the same caching and efficiency measures as any other client using that subsystem. Note that the contents of the delegated zone, generated as it is by performing ".local" Multicast DNS queries, mirrors the records available on the local link via Multicast DNS very closely, but not precisely. There is not a full bidirectional equivalence between the two. Certain records that are available via Multicast DNS may not have equivalents in the delegated zone, possibly because they are invalid or not relevant in the delegated zone, or because they are being supressed because they are unusable outside the local link (see Section 5.5.2). Conversely, certain records that appear in the delegated zone may not have corresponding records available on the local link via Multicast DNS. In particular there are certain administrative SRV records (see Section 6) that logically fall within the delegated zone, but semantically represent metadata *about* the zone rather than records *within* the zone, and consequently these administrative records in the delegated zone do not have any corresponding counterparts in the Multicast DNS namespace of the local link. Cheshire Expires September 25, 2019 [Page 10] Internet-Draft Multicast Service Discovery Proxy March 2019 5.2. Domain Enumeration A DNS-SD client performs Domain Enumeration [RFC6763] via certain PTR queries, using both unicast and multicast. If it receives a Domain Name configuration via DHCP option 15 [RFC2132], then it issues unicast queries using this domain. It issues unicast queries using names derived from its IPv4 subnet address(es) and IPv6 prefix(es). These are described below in Section 5.2.1. It also issues multicast Domain Enumeration queries in the "local" domain [RFC6762]. These are described below in Section 5.2.2. The results of all the Domain Enumeration queries are combined for Service Discovery purposes. 5.2.1. Domain Enumeration via Unicast Queries The administrator creates Domain Enumeration PTR records [RFC6763] to inform clients of available service discovery domains. Two varieties of such Domain Enumeration PTR records exist; those with names derived from the domain name communicated to the clients via DHCP, and those with names derived from IPv4 subnet address(es) and IPv6 prefix(es) in use by the clients. Below is an example showing the name-based variety: b._dns-sd._udp.example.com. PTR Building 1.example.com. PTR Building 2.example.com. PTR Building 3.example.com. PTR Building 4.example.com. db._dns-sd._udp.example.com. PTR Building 1.example.com. lb._dns-sd._udp.example.com. PTR Building 1.example.com. The meaning of these records is defined in the DNS Service Discovery specification [RFC6763] but for convenience is repeated here. The "b" ("browse") records tell the client device the list of browsing domains to display for the user to select from. The "db" ("default browse") record tells the client device which domain in that list should be selected by default. The "db" domain MUST be one of the domains in the "b" list; if not then no domain is selected by default. The "lb" ("legacy browse") record tells the client device which domain to automatically browse on behalf of applications that don't implement UI for multi-domain browsing (which is most of them, at the time of writing). The "lb" domain is often the same as the "db" domain, or sometimes the "db" domain plus one or more others that should be included in the list of automatic browsing domains for legacy clients. Note that in the example above, for clarity, space characters in names are shown as actual spaces. If this data is manually entered Cheshire Expires September 25, 2019 [Page 11] Internet-Draft Multicast Service Discovery Proxy March 2019 into a textual zone file for authoritative server software such as BIND, care must be taken because the space character is used as a field separator, and other characters like dot ('.'), semicolon (';'), dollar ('$'), backslash ('\'), etc., also have special meaning. These characters have to be escaped when entered into a textual zone file, following the rules in Section 5.1 of the DNS specification [RFC1035]. For example, a literal space in a name is represented in the textual zone file using '\032', so "Building 1.example.com." is entered as "Building\0321.example.com." DNS responses are limited to a maximum size of 65535 bytes. This limits the maximum number of domains that can be returned for a Domain Enumeration query, as follows: A DNS response header is 12 bytes. That's typically followed by a single qname (up to 256 bytes) plus qtype (2 bytes) and qclass (2 bytes), leaving 65275 for the Answer Section. An Answer Section Resource Record consists of: o Owner name, encoded as a two-byte compression pointer o Two-byte rrtype (type PTR) o Two-byte rrclass (class IN) o Four-byte ttl o Two-byte rdlength o rdata (domain name, up to 256 bytes) This means that each Resource Record in the Answer Section can take up to 268 bytes total, which means that the Answer Section can contain, in the worst case, no more than 243 domains. In a more typical scenario, where the domain names are not all maximum-sized names, and there is some similarity between names so that reasonable name compression is possible, each Answer Section Resource Record may average 140 bytes, which means that the Answer Section can contain up to 466 domains. It is anticipated that this should be sufficient for even a large corporate network or university campus. Cheshire Expires September 25, 2019 [Page 12] Internet-Draft Multicast Service Discovery Proxy March 2019 5.2.2. Domain Enumeration via Multicast Queries In the case where Discovery Proxy functionality is widely deployed within an enterprise (either by having a Discovery Proxy on each link, or by having a Discovery Proxy with a remote 'virtual' presence on each link using VLANs or Multicast DNS Discovery Relays [Relay]) this offers an additional way to provide Domain Enumeration data for clients. A Discovery Proxy can be configured to generate Multicast DNS responses for the following Multicast DNS Domain Enumeration queries issued by clients: b._dns-sd._udp.local. PTR ? db._dns-sd._udp.local. PTR ? lb._dns-sd._udp.local. PTR ? This provides the ability for Discovery Proxies to indicate recommended browsing domains to DNS-SD clients on a per-link granularity. In some enterprises it may be preferable to provide this per-link configuration data in the form of Discovery Proxy configuration, rather than populating the Unicast DNS servers with the same data (in the "ip6.arpa" or "in-addr.arpa" domains). Regardless of how the network operator chooses to provide this configuration data, clients will perform Domain Enumeration via both unicast and multicast queries, and then combine the results of these queries. Cheshire Expires September 25, 2019 [Page 13] Internet-Draft Multicast Service Discovery Proxy March 2019 5.3. Delegated Subdomain for LDH Host Names DNS-SD service instance names and domains are allowed to contain arbitrary Net-Unicode text [RFC5198], encoded as precomposed UTF-8 [RFC3629]. Users typically interact with service discovery software by viewing a list of discovered service instance names on a display, and selecting one of them by pointing, touching, or clicking. Similarly, in software that provides a multi-domain DNS-SD user interface, users view a list of offered domains on the display and select one of them by pointing, touching, or clicking. To use a service, users don't have to remember domain or instance names, or type them; users just have to be able to recognize what they see on the display and touch or click on the thing they want. In contrast, host names are often remembered and typed. Also, host names have historically been used in command-line interfaces where spaces can be inconvenient. For this reason, host names have traditionally been restricted to letters, digits and hyphens (LDH), with no spaces or other punctuation. While we do want to allow rich text for DNS-SD service instance names and domains, it is advisable, for maximum compatibility with existing usage, to restrict host names to the traditional letter-digit-hyphen rules. This means that while a service name "My Printer._ipp._tcp.Building 1.example.com" is acceptable and desirable (it is displayed in a graphical user interface as an instance called "My Printer" in the domain "Building 1" at "example.com"), a host name "My-Printer.Building 1.example.com" is less desirable (because of the space in "Building 1"). To accomodate this difference in allowable characters, a Discovery Proxy SHOULD support having two separate subdomains delegated to it for each link it serves, one whose name is allowed to contain arbitrary Net-Unicode text [RFC5198], and a second more constrained subdomain whose name is restricted to contain only letters, digits, and hyphens, to be used for host name records (names of 'A' and 'AAAA' address records). The restricted names may be any valid name consisting of only letters, digits, and hyphens, including Punycode- encoded names [RFC3492]. Cheshire Expires September 25, 2019 [Page 14] Internet-Draft Multicast Service Discovery Proxy March 2019 For example, a Discovery Proxy could have the two subdomains "Building 1.example.com" and "bldg1.example.com" delegated to it. The Discovery Proxy would then translate these two Multicast DNS records: My Printer._ipp._tcp.local. SRV 0 0 631 prnt.local. prnt.local. A 203.0.113.2 into Unicast DNS records as follows: My Printer._ipp._tcp.Building 1.example.com. SRV 0 0 631 prnt.bldg1.example.com. prnt.bldg1.example.com. A 203.0.113.2 Note that the SRV record name is translated using the rich-text domain name ("Building 1.example.com") and the address record name is translated using the LDH domain ("bldg1.example.com"). A Discovery Proxy MAY support only a single rich text Net-Unicode domain, and use that domain for all records, including 'A' and 'AAAA' address records, but implementers choosing this option should be aware that this choice may produce host names that are awkward to use in command-line environments. Whether this is an issue depends on whether users in the target environment are expected to be using command-line interfaces. A Discovery Proxy MUST NOT be restricted to support only a letter- digit-hyphen subdomain, because that results in an unnecessarily poor user experience. As described above in Section 5.2.1, for clarity, space characters in names are shown as actual spaces. If this data were to be manually entered into a textual zone file (which it isn't) then spaces would need to be represented using '\032', so "My Printer._ipp._tcp.Building 1.example.com." would become "My\032Printer._ipp._tcp.Building\0321.example.com." Note that the '\032' representation does not appear in the network packets sent over the air. In the wire format of DNS messages, spaces are sent as spaces, not as '\032', and likewise, in a graphical user interface at the client device, spaces are shown as spaces, not as '\032'. Cheshire Expires September 25, 2019 [Page 15] Internet-Draft Multicast Service Discovery Proxy March 2019 5.4. Delegated Subdomain for Reverse Mapping A Discovery Proxy can facilitate easier management of reverse mapping domains, particularly for IPv6 addresses where manual management may be more onerous than it is for IPv4 addresses. To achieve this, in the parent domain, NS records are used to delegate ownership of the appropriate reverse mapping domain to the Discovery Proxy. In other words, the Discovery Proxy becomes the authoritative name server for the reverse mapping domain. For fault tolerance reasons there may be more than one Discovery Proxy serving a given link. If a given link is using the IPv4 subnet 203.0.113/24, then the domain "113.0.203.in-addr.arpa" is delegated to the Discovery Proxy for that link. For example, if a given link is using the IPv6 prefix 2001:0DB8:1234:5678/64, then the domain "8.7.6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa" is delegated to the Discovery Proxy for that link. When a reverse mapping query arrives at the Discovery Proxy, it issues the identical query on its local link as a Multicast DNS query. The mechanism to force an apparently unicast name to be resolved using link-local Multicast DNS varies depending on the API set being used. For example, in the "dns_sd.h" APIs (available on macOS, iOS, Bonjour for Windows, Linux and Android), using kDNSServiceFlagsForceMulticast indicates that the DNSServiceQueryRecord() call should perform the query using Multicast DNS. Other APIs sets have different ways of forcing multicast queries. When the host owning that IPv4 or IPv6 address responds with a name of the form "something.local", the Discovery Proxy rewrites that to use its configured LDH host name domain instead of "local", and returns the response to the caller. Cheshire Expires September 25, 2019 [Page 16] Internet-Draft Multicast Service Discovery Proxy March 2019 For example, a Discovery Proxy with the two subdomains "113.0.203.in-addr.arpa" and "bldg1.example.com" delegated to it would translate this Multicast DNS record: 2.113.0.203.in-addr.arpa. PTR prnt.local. into this Unicast DNS response: 2.113.0.203.in-addr.arpa. PTR prnt.bldg1.example.com. Subsequent queries for the prnt.bldg1.example.com address record, falling as it does within the bldg1.example.com domain, which is delegated to the Discovery Proxy, will arrive at the Discovery Proxy, where they are answered by issuing Multicast DNS queries and using the received Multicast DNS answers to synthesize Unicast DNS responses, as described above. Note that this design assumes that all addresses on a given IPv4 subnet or IPv6 prefix are mapped to hostnames using the Discovery Proxy mechanism. It would be possible to implement a Discovery Proxy that can be configured so that some address-to-name mappings are performed using Multicast DNS on the local link, while other address- to-name mappings within the same IPv4 subnet or IPv6 prefix are configured manually. Cheshire Expires September 25, 2019 [Page 17] Internet-Draft Multicast Service Discovery Proxy March 2019 5.5. Data Translation Generating the appropriate Multicast DNS queries involves, at the very least, translating from the configured DNS domain (e.g., "Building 1.example.com") on the Unicast DNS side to "local" on the Multicast DNS side. Generating the appropriate Unicast DNS responses involves translating back from "local" to the appropriate configured DNS Unicast domain. Other beneficial translation and filtering operations are described below. 5.5.1. DNS TTL limiting For efficiency, Multicast DNS typically uses moderately high DNS TTL values. For example, the typical TTL on DNS-SD PTR records is 75 minutes. What makes these moderately high TTLs acceptable is the cache coherency mechanisms built in to the Multicast DNS protocol which protect against stale data persisting for too long. When a service shuts down gracefully, it sends goodbye packets to remove its PTR records immediately from neighboring caches. If a service shuts down abruptly without sending goodbye packets, the Passive Observation Of Failures (POOF) mechanism described in Section 10.5 of the Multicast DNS specification [RFC6762] comes into play to purge the cache of stale data. A traditional Unicast DNS client on a distant remote link does not get to participate in these Multicast DNS cache coherency mechanisms on the local link. For traditional Unicast DNS queries (those received without using Long-Lived Query [LLQ] or DNS Push Notification subscriptions [Push]) the DNS TTLs reported in the resulting Unicast DNS response MUST be capped to be no more than ten seconds. Similarly, for negative responses, the negative caching TTL indicated in the SOA record [RFC2308] should also be ten seconds (Section 6.1). This value of ten seconds is chosen based on user-experience considerations. For negative caching, suppose a user is attempting to access a remote device (e.g., a printer), and they are unsuccessful because that device is powered off. Suppose they then place a telephone call and ask for the device to be powered on. We want the device to become available to the user within a reasonable time period. It is reasonable to expect it to take on the order of ten seconds for a simple device with a simple embedded operating system to power on. Cheshire Expires September 25, 2019 [Page 18] Internet-Draft Multicast Service Discovery Proxy March 2019 Once the device is powered on and has announced its presence on the network via Multicast DNS, we would like it to take no more than a further ten seconds for stale negative cache entries to expire from Unicast DNS caches, making the device available to the user desiring to access it. Similar reasoning applies to capping positive TTLs at ten seconds. In the event of a device moving location, getting a new DHCP address, or other renumbering events, we would like the updated information to be available to remote clients in a relatively timely fashion. However, network administrators should be aware that many recursive (caching) DNS servers by default are configured to impose a minimum TTL of 30 seconds. If stale data appears to be persisting in the network to the extent that it adversely impacts user experience, network administrators are advised to check the configuration of their recursive DNS servers. For received Unicast DNS queries that use LLQ [LLQ] or DNS Push Notifications [Push], the Multicast DNS record's TTL SHOULD be returned unmodified, because the Push Notification channel exists to inform the remote client as records come and go. For further details about Long-Lived Queries, and its newer replacement, DNS Push Notifications, see Section 5.6. 5.5.2. Suppressing Unusable Records A Discovery Proxy SHOULD offer a configurable option, enabled by default, to suppress Unicast DNS answers for records that are not useful outside the local link. When the option to suppress unusable records is enabled: o DNS A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 link-local addresses [RFC4862] SHOULD be suppressed. o Similarly, for sites that have multiple private address realms [RFC1918], in cases where the Discovery Proxy can determine that the querying client is in a different address realm, private addresses SHOULD NOT be communicated to that client. o IPv6 Unique Local Addresses [RFC4193] SHOULD be suppressed in cases where the Discovery Proxy can determine that the querying client is in a different IPv6 address realm. o By the same logic, DNS SRV records that reference target host names that have no addresses usable by the requester should be suppressed, and likewise, DNS PTR records that point to unusable SRV records should be similarly be suppressed. Cheshire Expires September 25, 2019 [Page 19] Internet-Draft Multicast Service Discovery Proxy March 2019 5.5.3. NSEC and NSEC3 queries Multicast DNS devices do not routinely announce their records on the network. Generally they remain silent until queried. This means that the complete set of Multicast DNS records in use on a link can only be discovered by active querying, not by passive listening. Because of this, a Discovery Proxy can only know what names exist on a link by issuing queries for them, and since it would be impractical to issue queries for every possible name just to find out which names exist and which do not, a Discovery Proxy cannot programmatically generate the traditional NSEC [RFC4034] and NSEC3 [RFC5155] records which assert the nonexistence of a large range of names. When queried for an NSEC or NSEC3 record type, the Discovery Proxy issues a qtype "ANY" query using Multicast DNS on the local link, and then generates an NSEC or NSEC3 response with a Type Bit Map signifying which record types do and do not exist for just the specific name queried, and no other names. Multicast DNS NSEC records received on the local link MUST NOT be forwarded unmodified to a unicast querier, because there are slight differences in the NSEC record data. In particular, Multicast DNS NSEC records do not have the NSEC bit set in the Type Bit Map, whereas conventional Unicast DNS NSEC records do have the NSEC bit set. 5.5.4. No Text Encoding Translation A Discovery Proxy does no translation between text encodings. Specifically, a Discovery Proxy does no translation between Punycode encoding [RFC3492] and UTF-8 encoding [RFC3629], either in the owner name of DNS records, or anywhere in the RDATA of DNS records (such as the RDATA of PTR records, SRV records, NS records, or other record types like TXT, where it is ambiguous whether the RDATA may contain DNS names). All bytes are treated as-is, with no attempt at text encoding translation. A client implementing DNS-based Service Discovery [RFC6763] will use UTF-8 encoding for its service discovery queries, which the Discovery Proxy passes through without any text encoding translation to the Multicast DNS subsystem. Responses from the Multicast DNS subsystem are similarly returned, without any text encoding translation, back to the requesting client. Cheshire Expires September 25, 2019 [Page 20] Internet-Draft Multicast Service Discovery Proxy March 2019 5.5.5. Application-Specific Data Translation There may be cases where Application-Specific Data Translation is appropriate. For example, AirPrint printers tend to advertise fairly verbose information about their capabilities in their DNS-SD TXT record. TXT record sizes in the range 500-1000 bytes are not uncommon. This information is a legacy from LPR printing, because LPR does not have in-band capability negotiation, so all of this information is conveyed using the DNS-SD TXT record instead. IPP printing does have in-band capability negotiation, but for convenience printers tend to include the same capability information in their IPP DNS-SD TXT records as well. For local mDNS use this extra TXT record information is inefficient, but not fatal. However, when a Discovery Proxy aggregates data from multiple printers on a link, and sends it via unicast (via UDP or TCP) this amount of unnecessary TXT record information can result in large responses. A DNS reply over TCP carrying information about 70 printers with an average of 700 bytes per printer adds up to about 50 kilobytes of data. Therefore, a Discovery Proxy that is aware of the specifics of an application- layer protocol such as AirPrint (which uses IPP) can elide unnecessary key/value pairs from the DNS-SD TXT record for better network efficiency. Also, the DNS-SD TXT record for many printers contains an "adminurl" key something like "adminurl=http://printername.local/status.html". For this URL to be useful outside the local link, the embedded ".local" hostname needs to be translated to an appropriate name with larger scope. It is easy to translate ".local" names when they appear in well-defined places, either as a record's name, or in the rdata of record types like PTR and SRV. In the printing case, some application-specific knowledge about the semantics of the "adminurl" key is needed for the Discovery Proxy to know that it contains a name that needs to be translated. This is somewhat analogous to the need for NAT gateways to contain ALGs (Application-Specific Gateways) to facilitate the correct translation of protocols that embed addresses in unexpected places. To avoid the need for application-specific knowledge about the semantics of particular TXT record keys, protocol designers are advised to avoid placing link-local names or link-local IP addresses in TXT record keys, if translation of those names or addresses would be required for off-link operation. In the printing case, the operational failure of failing to translate the "adminurl" key correctly is that, when accessed from a different link, printing will still work, but clicking the "Admin" UI button will fail to open the printer's administration page. Rather than duplicating the host name Cheshire Expires September 25, 2019 [Page 21] Internet-Draft Multicast Service Discovery Proxy March 2019 from the service's SRV record in its "adminurl" key, thereby having the same host name appear in two places, a better design might have been to omit the host name from the "adminurl" key, and instead have the client implicitly substitute the target host name from the service's SRV record in place of a missing host name in the "adminurl" key. That way the desired host name only appears once, and it is in a well-defined place where software like the Discovery Proxy is expecting to find it. Note that this kind of Application-Specific Data Translation is expected to be very rare. It is the exception, rather than the rule. This is an example of a common theme in computing. It is frequently the case that it is wise to start with a clean, layered design, with clear boundaries. Then, in certain special cases, those layer boundaries may be violated, where the performance and efficiency benefits outweigh the inelegance of the layer violation. These layer violations are optional. They are done primarily for efficiency reasons, and generally should not be required for correct operation. A Discovery Proxy MAY operate solely at the mDNS layer, without any knowledge of semantics at the DNS-SD layer or above. Cheshire Expires September 25, 2019 [Page 22] Internet-Draft Multicast Service Discovery Proxy March 2019 5.6. Answer Aggregation In a simple analysis, simply gathering multicast answers and forwarding them in a unicast response seems adequate, but it raises the question of how long the Discovery Proxy should wait to be sure that it has received all the Multicast DNS answers it needs to form a complete Unicast DNS response. If it waits too little time, then it risks its Unicast DNS response being incomplete. If it waits too long, then it creates a poor user experience at the client end. In fact, there may be no time which is both short enough to produce a good user experience and at the same time long enough to reliably produce complete results. Similarly, the Discovery Proxy -- the authoritative name server for the subdomain in question -- needs to decide what DNS TTL to report for these records. If the TTL is too long then the recursive (caching) name servers issuing queries on behalf of their clients risk caching stale data for too long. If the TTL is too short then the amount of network traffic will be more than necessary. In fact, there may be no TTL which is both short enough to avoid undesirable stale data and at the same time long enough to be efficient on the network. Both these dilemmas are solved by use of DNS Long-Lived Queries (DNS LLQ) [LLQ] or its newer replacement, DNS Push Notifications [Push]. Clients supporting unicast DNS Service Discovery SHOULD implement DNS Push Notifications [Push] for improved user experience. Clients and Discovery Proxies MAY support both DNS LLQ and DNS Push, and when talking to a Discovery Proxy that supports both, the client may use either protocol, as it chooses, though it is expected that only DNS Push will continue to be supported in the long run. When a Discovery Proxy receives a query using DNS LLQ or DNS Push Notifications, it responds immediately using the Multicast DNS records it already has in its cache (if any). This provides a good client user experience by providing a near-instantaneous response. Simultaneously, the Discovery Proxy issues a Multicast DNS query on the local link to discover if there are any additional Multicast DNS records it did not already know about. Should additional Multicast DNS responses be received, these are then delivered to the client using additional DNS LLQ or DNS Push Notification update messages. The timeliness of such update messages is limited only by the timeliness of the device responding to the Multicast DNS query. If the Multicast DNS device responds quickly, then the update message is delivered quickly. If the Multicast DNS device responds slowly, then Cheshire Expires September 25, 2019 [Page 23] Internet-Draft Multicast Service Discovery Proxy March 2019 the update message is delivered slowly. The benefit of using update messages is that the Discovery Proxy can respond promptly because it doesn't have to delay its unicast response to allow for the expected worst-case delay for receiving all the Multicast DNS responses. Even if a proxy were to try to provide reliability by assuming an excessively pessimistic worst-case time (thereby giving a very poor user experience) there would still be the risk of a slow Multicast DNS device taking even longer than that (e.g., a device that is not even powered on until ten seconds after the initial query is received) resulting in incomplete responses. Using update message solves this dilemma: even very late responses are not lost; they are delivered in subsequent update messages. There are two factors that determine specifically how responses are generated: The first factor is whether the query from the client used LLQ or DNS Push Notifications (used for long-lived service browsing PTR queries) or not (used for one-shot operations like SRV or address record queries). Note that queries using LLQ or DNS Push Notifications are received directly from the client. Queries not using LLQ or DNS Push Notifications are generally received via the client's configured recursive (caching) name server. The second factor is whether the Discovery Proxy already has at least one record in its cache that positively answers the question. o Not using LLQ or Push Notifications; no answer in cache: Issue an mDNS query, exactly as a local client would issue an mDNS query on the local link for the desired record name, type and class, including retransmissions, as appropriate, according to the established mDNS retransmission schedule [RFC6762]. As soon as any Multicast DNS response packet is received that contains one or more positive answers to that question (with or without the Cache Flush bit [RFC6762] set), or a negative answer (signified via a Multicast DNS NSEC record [RFC6762]), the Discovery Proxy generates a Unicast DNS response packet containing the corresponding (filtered and translated) answers and sends it to the remote client. If after six seconds no Multicast DNS answers have been received, cancel the mDNS query and return a negative response to the remote client. Six seconds is enough time to transmit three mDNS queries, and allow some time for responses to arrive. DNS TTLs in responses MUST be capped to at most ten seconds. (Reasoning: Queries not using LLQ or Push Notifications are generally queries that that expect an answer from only one device, so the first response is also the only response.) Cheshire Expires September 25, 2019 [Page 24] Internet-Draft Multicast Service Discovery Proxy March 2019 o Not using LLQ or Push Notifications; at least one answer in cache: Send response right away to minimise delay. DNS TTLs in responses MUST be capped to at most ten seconds. No local mDNS queries are performed. (Reasoning: Queries not using LLQ or Push Notifications are generally queries that that expect an answer from only one device. Given RRSet TTL harmonisation, if the proxy has one Multicast DNS answer in its cache, it can reasonably assume that it has all of them.) o Using LLQ or Push Notifications; no answer in cache: As in the case above with no answer in the cache, perform mDNS querying for six seconds, and send a response to the remote client as soon as any relevant mDNS response is received. If after six seconds no relevant mDNS response has been received, return negative response to the remote client (for LLQ; not applicable for Push Notifications). (Reasoning: We don't need to rush to send an empty answer.) Whether or not a relevant mDNS response is received within six seconds, the query remains active for as long as the client maintains the LLQ or Push Notification state, and if mDNS answers are received later, LLQ or Push Notification messages are sent. DNS TTLs in responses are returned unmodified. o Using LLQ or Push Notifications; at least one answer in cache: As in the case above with at least one answer in cache, send response right away to minimise delay. The query remains active for as long as the client maintains the LLQ or Push Notification state, and results in transmission of mDNS queries, with appropriate Known Answer lists, to determine if further answers are available. If additional mDNS answers are received later, LLQ or Push Notification messages are sent. (Reasoning: We want UI that is displayed very rapidly, yet continues to remain accurate even as the network environment changes.) DNS TTLs in responses are returned unmodified. The "negative responses" referred to above are "no error no answer" negative responses, not NXDOMAIN. This is because the Discovery Proxy cannot know all the Multicast DNS domain names that may exist on a link at any given time, so any name with no answers may have child names that do exist, making it an "empty nonterminal" name. Cheshire Expires September 25, 2019 [Page 25] Internet-Draft Multicast Service Discovery Proxy March 2019 Note that certain aspects of the behavior described here do not have to be implemented overtly by the Discovery Proxy; they occur naturally as a result of using existing Multicast DNS APIs. For example, in the first case above (no LLQ or Push Notifications, and no answers in the cache) if a new Multicast DNS query is requested (either by a local client, or by the Discovery Proxy on behalf of a remote client), and there is not already an identical Multicast DNS query active, and there are no matching answers already in the Multicast DNS cache on the Discovery Proxy device, then this will cause a series of Multicast DNS query packets to be issued with exponential backoff. The exponential backoff sequence in some implementations starts at one second and then doubles for each retransmission (0, 1, 3, 7 seconds, etc.) and in others starts at one second and then triples for each retransmission (0, 1, 4, 13 seconds, etc.). In either case, if no response has been received after six seconds, that is long enough that the underlying Multicast DNS implementation will have sent three query packets without receiving any response. At that point the Discovery Proxy cancels its Multicast DNS query (so no further Multicast DNS query packets will be sent for this query) and returns a negative response to the remote client via unicast. The six-second delay is chosen to be long enough to give enough time for devices to respond, yet short enough not to be too onerous for a human user waiting for a response. For example, using the "dig" DNS debugging tool, the current default settings result in it waiting a total of 15 seconds for a reply (three transmissions of the query packet, with a wait of 5 seconds after each packet) which is ample time for it to have received a negative reply from a Discovery Proxy after six seconds. The statement that for a one-shot query (i.e., no LLQ or Push Notifications requested), if at least one answer is already available in the cache then a Discovery Proxy should not issue additional mDNS query packets, also occurs naturally as a result of using existing Multicast DNS APIs. If a new Multicast DNS query is requested (either locally, or by the Discovery Proxy on behalf of a remote client), for which there are relevant answers already in the Multicast DNS cache on the Discovery Proxy device, and after the answers are delivered the Multicast DNS query is then cancelled immediately, then no Multicast DNS query packets will be generated for this query. Cheshire Expires September 25, 2019 [Page 26] Internet-Draft Multicast Service Discovery Proxy March 2019 6. Administrative DNS Records 6.1. DNS SOA (Start of Authority) Record The MNAME field SHOULD contain the host name of the Discovery Proxy device (i.e., the same domain name as the rdata of the NS record delegating the relevant zone(s) to this Discovery Proxy device). The RNAME field SHOULD contain the mailbox of the person responsible for administering this Discovery Proxy device. The SERIAL field MUST be zero. Zone transfers are undefined for Discovery Proxy zones, and consequently the REFRESH, RETRY and EXPIRE fields have no useful meaning for Discovery Proxy zones. These fields SHOULD contain reasonable default values. The RECOMMENDED values are: REFRESH 7200, RETRY 3600, EXPIRE 86400. The MINIMUM field (used to control the lifetime of negative cache entries) SHOULD contain the value 10. The value of ten seconds is chosen based on user-experience considerations (see Section 5.5.1). In the event that there are multiple Discovery Proxy devices on a link for fault tolerance reasons, this will result in clients receiving inconsistent SOA records (different MNAME, and possibly RNAME) depending on which Discovery Proxy answers their SOA query. However, since clients generally have no reason to use the MNAME or RNAME data, this is unlikely to cause any problems. Cheshire Expires September 25, 2019 [Page 27] Internet-Draft Multicast Service Discovery Proxy March 2019 6.2. DNS NS Records In the event that there are multiple Discovery Proxy devices on a link for fault tolerance reasons, the parent zone MUST be configured with NS records giving the names of all the Discovery Proxy devices on the link. Each Discovery Proxy device MUST be configured to answer NS queries for the zone apex name by giving its own NS record, and the NS records of its fellow Discovery Proxy devices on the same link, so that it can return the correct answers for NS queries. The target host name in the RDATA of an NS record MUST NOT reference a name that falls within any zone delegated to a Discovery Proxy. Apart from the zone apex name, all other host names that fall within a zone delegated to a Discovery Proxy correspond to local Multicast DNS host names, which logically belong to the respective Multicast DNS hosts defending those names, not the Discovery Proxy. Generally speaking, the Discovery Proxy does not own or control the delegated zone; it is merely a conduit to the corresponding ".local" namespace, which is controlled by the Multicast DNS hosts on that link. If an NS record were to reference a manually-determined host name that falls within a delegated zone, that manually-determined host name may inadvertently conflict with a corresponding ".local" host name that is owned and controlled by some device on that link. 6.3. DNS Delegation Records Since the Multicast DNS specification [RFC6762] states that there can be no delegation (subdomains) within a ".local" namespace, this implies that any name within a zone delegated to a Discovery Proxy (except for the zone apex name itself) cannot have any answers for any DNS queries for RRTYPEs SOA, NS, or DS. Consequently: o for any query for the zone apex name of a zone delegated to a Discovery Proxy, the Discovery Proxy MUST generate the appropriate immediate answers as described above, and o for any query for RRTYPEs SOA, NS, or DS, for any name within a zone delegated to a Discovery Proxy, other than the zone apex name, instead of translating the query to its corresponding Multicast DNS ".local" equivalent, a Discovery Proxy MUST generate an immediate negative answer. Cheshire Expires September 25, 2019 [Page 28] Internet-Draft Multicast Service Discovery Proxy March 2019 6.4. DNS SRV Records There are certain special DNS records that logically fall within the delegated unicast DNS subdomain, but rather than mapping to their corresponding ".local" namesakes, they actually contain metadata pertaining to the operation of the delegated unicast DNS subdomain itself. They do not exist in the corresponding ".local" namespace of the local link. For these queries a Discovery Proxy MUST generate immediate answers, whether positive or negative, to avoid delays while clients wait for their query to be answered. For example, if a Discovery Proxy does not implement Long-Lived Queries [LLQ] then it MUST return an immediate negative answer to tell the client this without delay, instead of passing the query through to the local network as a query for "_dns-llq._udp.local.", and then waiting unsuccessfully for answers that will not be forthcoming. If a Discovery Proxy implements Long-Lived Queries [LLQ] then it MUST positively respond to "_dns-llq._udp. SRV" queries, "_dns-llq._tcp. SRV" queries, and "_dns-llq-tls._tcp. SRV" queries as appropriate, else it MUST return an immediate negative answer for those queries. If a Discovery Proxy implements DNS Push Notifications [Push] then it MUST positively respond to "_dns-push-tls._tcp." queries, else it MUST return an immediate negative answer for those queries. A Discovery Proxy MUST return an immediate negative answer for "_dns-update._udp. SRV" queries, "_dns-update._tcp. SRV" queries, and "_dns-update-tls._tcp. SRV" queries, since using DNS Update [RFC2136] to change zones generated dynamically from local Multicast DNS data is not possible. Cheshire Expires September 25, 2019 [Page 29] Internet-Draft Multicast Service Discovery Proxy March 2019 7. DNSSEC Considerations 7.1. On-line signing only The Discovery Proxy acts as the authoritative name server for designated subdomains, and if DNSSEC is to be used, the Discovery Proxy needs to possess a copy of the signing keys, in order to generate authoritative signed data from the local Multicast DNS responses it receives. Off-line signing is not applicable to Discovery Proxy. 7.2. NSEC and NSEC3 Records In DNSSEC NSEC [RFC4034] and NSEC3 [RFC5155] records are used to assert the nonexistence of certain names, also described as "authenticated denial of existence". Since a Discovery Proxy only knows what names exist on the local link by issuing queries for them, and since it would be impractical to issue queries for every possible name just to find out which names exist and which do not, a Discovery Proxy cannot programmatically synthesize the traditional NSEC and NSEC3 records which assert the nonexistence of a large range of names. Instead, when generating a negative response, a Discovery Proxy programmatically synthesizes a single NSEC record assert the nonexistence of just the specific name queried, and no others. Since the Discovery Proxy has the zone signing key, it can do this on demand. Since the NSEC record asserts the nonexistence of only a single name, zone walking is not a concern, so NSEC3 is not necessary. Note that this applies only to traditional immediate DNS queries, which may return immediate negative answers when no immediate positive answer is available. When used with a DNS Push Notification subscription [Push] there are no negative answers, merely the absence of answers so far, which may change in the future if answers become available. Cheshire Expires September 25, 2019 [Page 30] Internet-Draft Multicast Service Discovery Proxy March 2019 8. IPv6 Considerations An IPv4-only host and an IPv6-only host behave as "ships that pass in the night". Even if they are on the same Ethernet [IEEE-3], neither is aware of the other's traffic. For this reason, each link may have *two* unrelated ".local." zones, one for IPv4 and one for IPv6. Since for practical purposes, a group of IPv4-only hosts and a group of IPv6-only hosts on the same Ethernet act as if they were on two entirely separate Ethernet segments, it is unsurprising that their use of the ".local." zone should occur exactly as it would if they really were on two entirely separate Ethernet segments. It will be desirable to have a mechanism to 'stitch' together these two unrelated ".local." zones so that they appear as one. Such mechanism will need to be able to differentiate between a dual-stack (v4/v6) host participating in both ".local." zones, and two different hosts, one IPv4-only and the other IPv6-only, which are both trying to use the same name(s). Such a mechanism will be specified in a future companion document. At present, it is RECOMMENDED that a Discovery Proxy be configured with a single domain name for both the IPv4 and IPv6 ".local." zones on the local link, and when a unicast query is received, it should issue Multicast DNS queries using both IPv4 and IPv6 on the local link, and then combine the results. Cheshire Expires September 25, 2019 [Page 31] Internet-Draft Multicast Service Discovery Proxy March 2019 9. Security Considerations 9.1. Authenticity A service proves its presence on a link by its ability to answer link-local multicast queries on that link. If greater security is desired, then the Discovery Proxy mechanism should not be used, and something with stronger security should be used instead, such as authenticated secure DNS Update [RFC2136] [RFC3007]. 9.2. Privacy The Domain Name System is, generally speaking, a global public database. Records that exist in the Domain Name System name hierarchy can be queried by name from, in principle, anywhere in the world. If services on a mobile device (like a laptop computer) are made visible via the Discovery Proxy mechanism, then when those services become visible in a domain such as "My House.example.com" that might indicate to (potentially hostile) observers that the mobile device is in my house. When those services disappear from "My House.example.com" that change could be used by observers to infer when the mobile device (and possibly its owner) may have left the house. The privacy of this information may be protected using techniques like firewalls, split-view DNS, and Virtual Private Networks (VPNs), as are customarily used today to protect the privacy of corporate DNS information. The privacy issue is particularly serious for the IPv4 and IPv6 reverse zones. If the public delegation of the reverse zones points to the Discovery Proxy, and the Discovery Proxy is reachable globally, then it could leak a significant amount of information. Attackers could discover hosts that otherwise might not be easy to identify, and learn their hostnames. Attackers could also discover the existence of links where hosts frequently come and go. The Discovery Proxy could also provide sensitive records only to authenticated users. This is a general DNS problem, not specific to the Discovery Proxy. Work is underway in the IETF to tackle this problem [RFC7626]. 9.3. Denial of Service A remote attacker could use a rapid series of unique Unicast DNS queries to induce a Discovery Proxy to generate a rapid series of corresponding Multicast DNS queries on one or more of its local links. Multicast traffic is generally more expensive than unicast traffic -- especially on Wi-Fi links -- which makes this attack particularly serious. To limit the damage that can be caused by such Cheshire Expires September 25, 2019 [Page 32] Internet-Draft Multicast Service Discovery Proxy March 2019 attacks, a Discovery Proxy (or the underlying Multicast DNS subsystem which it utilizes) MUST implement Multicast DNS query rate limiting appropriate to the link technology in question. For today's 802.11b/g/n/ac Wi-Fi links (for which approximately 200 multicast packets per second is sufficient to consume approximately 100% of the wireless spectrum) a limit of 20 Multicast DNS query packets per second is RECOMMENDED. On other link technologies like Gigabit Ethernet higher limits may be appropriate. A consequence of this rate limiting is that a rogue remote client could issue an excessive number of queries, resulting in denial of service to other legitimate remote clients attempting to use that Discovery Proxy. However, this is preferable to a rogue remote client being able to inflict even greater harm on the local network, which could impact the correct operation of all local clients on that network. 10. IANA Considerations This document has no IANA Considerations. 11. Acknowledgments Thanks to Markus Stenberg for helping develop the policy regarding the four styles of unicast response according to what data is immediately available in the cache. Thanks to Anders Brandt, Ben Campbell, Tim Chown, Alissa Cooper, Spencer Dawkins, Ralph Droms, Joel Halpern, Ray Hunter, Joel Jaeggli, Warren Kumari, Ted Lemon, Alexey Melnikov, Kathleen Moriarty, Tom Pusateri, Eric Rescorla, Adam Roach, David Schinazi, Markus Stenberg, Dave Thaler, and Andrew Yourtchenko for their comments. Cheshire Expires September 25, 2019 [Page 33] Internet-Draft Multicast Service Discovery Proxy March 2019 12. References 12.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, . [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, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 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, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . Cheshire Expires September 25, 2019 [Page 34] Internet-Draft Multicast Service Discovery Proxy March 2019 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, March 2019, . [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", draft-ietf-dnssd-push-19 (work in progress), March 2019. 12.2. Informative References [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- cheshire-dnssd-roadmap-03 (work in progress), October 2018. [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- ul-01 (work in progress), August 2006. [LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries", draft-sekar-dns-llq-03 (work in progress), March 2019. [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol for DNS-Based Service Discovery", draft-sctl-service- registration-00 (work in progress), July 2017. [Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress), March 2018. Cheshire Expires September 25, 2019 [Page 35] Internet-Draft Multicast Service Discovery Proxy March 2019 [Mcast] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work in progress), November 2018. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, DOI 10.17487/RFC6760, February 2013, . [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 2015, . [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, . [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, . Cheshire Expires September 25, 2019 [Page 36] Internet-Draft Multicast Service Discovery Proxy March 2019 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, . [ohp] "Discovery Proxy (Hybrid Proxy) implementation for OpenWrt", . [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc. , ISBN 0-596-10100-7, December 2005. [IEEE-1Q] "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q-2014, November 2014, . [IEEE-3] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CMSA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2008, December 2008, . [IEEE-5] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 5: Token ring access method and physical layer specification", IEEE Std 802.5-1998, 1995. [IEEE-11] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2007, June 2007, . Cheshire Expires September 25, 2019 [Page 37] Internet-Draft Multicast Service Discovery Proxy March 2019 Appendix A. Implementation Status Some aspects of the mechanism specified in this document already exist in deployed software. Some aspects are new. This section outlines which aspects already exist and which are new. A.1. Already Implemented and Deployed Domain enumeration by the client (the "b._dns-sd._udp" queries) is already implemented and deployed. Unicast queries to the indicated discovery domain is already implemented and deployed. These are implemented and deployed in Mac OS X 10.4 and later (including all versions of Apple iOS, on all iPhone and iPads), in Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) and later. Domain enumeration and unicast querying have been used for several years at IETF meetings to make Terminal Room printers discoverable from outside the Terminal room. When an IETF attendee presses Cmd-P on a Mac, or selects AirPrint on an iPad or iPhone, and the Terminal room printers appear, that is because the client is sending unicast DNS queries to the IETF DNS servers. A walk-through giving the details of this particular specific example is given in Appendix A of the Roadmap document [Roadmap]. A.2. Already Implemented A minimal portable Discovery Proxy implementation has been produced by Markus Stenberg and Steven Barth, which runs on OS X and several Linux variants including OpenWrt [ohp]. It was demonstrated at the Berlin IETF in July 2013. Tom Pusateri has an implementation that runs on any Unix/Linux. It has a RESTful interface for management and an experimental demo CLI and web interface. Ted Lemon also has produced a portable implementation of Discovery Proxy, which is available in the mDNSResponder open source code. The Long-Lived Query mechanism [LLQ] referred to in this specification exists and is deployed, but was not standardized by the IETF. The IETF has developed a superior Long-Lived Query mechanism called DNS Push Notifications [Push], which is built on DNS Stateful Operations [RFC8490]. The pragmatic short-term deployment approach is for vendors to produce Discovery Proxies that implement both the Cheshire Expires September 25, 2019 [Page 38] Internet-Draft Multicast Service Discovery Proxy March 2019 deployed Long-Lived Query mechanism [LLQ] (for today's clients) and the new DNS Push Notifications mechanism [Push] as the preferred long-term direction. A.3. Partially Implemented The current APIs make multiple domains visible to client software, but most client UI today lumps all discovered services into a single flat list. This is largely a chicken-and-egg problem. Application writers were naturally reluctant to spend time writing domain-aware UI code when few customers today would benefit from it. If Discovery Proxy deployment becomes common, then application writers will have a reason to provide better UI. Existing applications will work with the Discovery Proxy, but will show all services in a single flat list. Applications with improved UI will group services by domain. Author's Address Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, California 95014 USA Phone: +1 (408) 996-1010 Email: cheshire@apple.com Cheshire Expires September 25, 2019 [Page 39] ./queue.html0000644000764400076440000025314513555642745012413 0ustar iustyiusty Current Queue » RFC Editor

Publication Queue

[About this page]  [Summary statistics]  [List of all active clusters]

Found 166 records

Current stateWeeks in stateWeeks in queueDraft name (Authors) ClusterPagesSubmitted
EDIT*R		10.4254.4draft-ietf-rmcat-cc-requirements-09
R. Jesup, Z. Sarker, Ed.		C238122014-12-12
EDIT*R		10.4205.0draft-ietf-bfcpbis-rfc4582bis-16
G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel		C238902015-11-23
EDIT*R		10.4200.0draft-ietf-avtcore-multi-media-rtp-session-13
M. Westerlund, C. Perkins, J. Lennox		C238162015-12-28
EDIT*R		10.6189.7draft-ietf-avtcore-rtp-multi-stream-optimisation-12
J. Lennox, M. Westerlund, Q. Wu, C. Perkins		C238182016-03-09
EDIT*R		10.4141.0draft-ietf-bfcpbis-bfcp-websocket-15
V. Pascual, A. Roman, S. Cazeaux, G. Salgueiro, R. Ravindranath		C238142017-02-13
EDIT*R		10.6136.0draft-ietf-mmusic-sctp-sdp-26
C. Holmberg, R. Shpount, S. Loreto, G. Camarillo		C238262017-03-20
EDIT*R		7.0110.0draft-ietf-rmcat-coupled-cc-09
S. Islam, M. Welzl, S. Gjessing		C331262017-09-18
EDIT*R		10.4103.6draft-ietf-mmusic-dtls-sdp-32
C. Holmberg, R. Shpount		C238272017-11-02
EDIT		8.693.0draft-ietf-rtgwg-yang-rip-11
X. Liu, P. Sarda, V. Choudhary		442018-01-15
EDIT*R		10.486.6draft-ietf-rtcweb-jsep-26
J. Uberti, C. Jennings, E. Rescorla, Ed.		C2381152018-03-01
EDIT*R		10.471.0draft-ietf-mmusic-sdp-bundle-negotiation-54
C. Holmberg, H. Alvestrand, C. Jennings		C238692018-06-18
EDIT*R		10.469.0draft-ietf-mmusic-trickle-ice-sip-18
E. Ivov, T. Stach, E. Marocco, C. Holmberg		C238472018-07-02
EDIT*R		10.444.4draft-ietf-bfcpbis-rfc4583bis-27
G. Camarillo, T. Kristensen, C. Holmberg		C238252018-12-21
EDIT*R		9.028.0draft-ietf-iasa2-consolidated-upd-07
J. Klensin, Ed.		C388102019-04-15
EDIT*R		9.027.9draft-ietf-iasa2-rfc4071bis-11
B. Haberman, J. Hall, J. Livingood		C388242019-04-16
EDIT*R		9.927.7draft-ietf-clue-datachannel-18
C. Holmberg		C238142019-04-17
EDIT*R		10.423.9draft-ietf-sipbrandy-rtpsec-08
J. Peterson, R. Barnes, R. Housley		C238142019-05-14
EDIT*R		9.922.9draft-ietf-mmusic-data-channel-sdpneg-28
K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed.		C238402019-05-21
EDIT		0.921.4draft-kanugovi-intarea-mams-framework-04
S. Kanugovi, F. Baboescu, J. Zhu, J. Mueller, S. Seo		1412019-05-31
EDIT*R		10.415.4draft-ietf-rtcweb-ip-handling-12
J. Uberti		C238122019-07-12
EDIT*R		10.615.4draft-ietf-rtcweb-security-12
E. Rescorla		C238262019-07-12
EDIT*R		9.015.0draft-ietf-iasa2-rfc7437bis-09
M. Kucherawy, Ed., B. Hinden, Ed., J. Livingood, Ed.		C388422019-07-15
EDIT*R		10.414.0draft-ietf-rtcweb-security-arch-20
E. Rescorla		C238432019-07-22
EDIT*R		7.011.7draft-ietf-curdle-gss-keyex-sha2-10
S. Sorce, H. Kario		C397132019-08-07
EDIT		11.011.4draft-ietf-ipwave-ipv6-over-80211ocb-52
N. Benamar, J. Haerri, J. Lee, T. Ernst		312019-08-09
EDIT		10.610.7draft-ietf-pce-inter-area-as-applicability-08
D. King, H. Zheng		252019-08-14
EDIT		10.010.0draft-ietf-rtgwg-enterprise-pa-multihoming-12
F. Baker, C. Bowers, J. Linkova		522019-08-19
EDIT*R		7.99.9draft-ietf-mmusic-rfc4566bis-37
A. Begen, P. Kyzivat, C. Perkins, M. Handley		C238632019-08-20
EDIT		9.69.7draft-iab-rfc7500-bis-00
R. Housley, Ed., O. Kolkman, Ed.		82019-08-21
EDIT		9.09.0draft-ietf-alto-xdom-disc-06
S. Kiesel, M. Stiemerling		442019-08-26
EDIT*R		9.09.0draft-ietf-iasa2-rfc2031bis-08
G. Camarillo, J. Livingood		C38892019-08-26
EDIT		7.99.0draft-ietf-lamps-cms-mix-with-psk-07
R. Housley		312019-08-26
EDIT		6.79.0draft-ietf-tls-grease-04
D. Benjamin		122019-08-26
EDIT		7.68.6draft-ietf-perc-double-12
C. Jennings, P. Jones, R. Barnes, A. Roach		C391182019-08-29
EDIT		7.77.7draft-iab-fiftyyears-01
H. Flanagan, Ed.		252019-09-04
EDIT		6.97.0draft-ietf-lamps-cms-shakes-18
P. Kampanakis, Q. Dang		182019-09-09
EDIT		7.07.0draft-ietf-iasa2-rfc5377bis-03
J. Halpern, Ed.		82019-09-09
EDIT		7.07.0draft-ietf-rmcat-nada-13
X. Zhu, R. Pan, M. Ramalho, S. de la Cruz		C331292019-09-09
EDIT		6.47.0draft-ietf-curdle-ssh-curves-12
A. Adamantiadis, S. Josefsson, M. Baushke		C39762019-09-09
EDIT		6.06.7draft-ietf-oauth-mtls-17
B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt		322019-09-11
EDIT*R		6.06.0draft-ietf-iasa2-rfc7776bis-03
P. Resnick, A. Farrel		C38862019-09-16
EDIT		5.46.0draft-ietf-curdle-ssh-ed25519-ed448-11
B. Harris, L. Velvindron		72019-09-16
EDIT		4.75.6draft-ietf-manet-dlep-lid-extension-06
R. Taylor, S. Ratliff		82019-09-19
EDIT		4.65.4draft-ietf-lsr-isis-rfc5306bis-09
L. Ginsberg, P. Wells		262019-09-20
EDIT		4.95.0draft-ise-iana-policy-03
A. Farrel		52019-09-23
EDIT		4.05.0draft-ietf-lamps-cms-hash-sig-10
R. Housley		142019-09-23
EDIT		4.45.0draft-ietf-core-multipart-ct-04
T. Fossati, K. Hartke, C. Bormann		102019-09-23
EDIT		0.95.0draft-ietf-curdle-rc4-die-die-die-17
L. Velvindron		52019-09-23
EDIT		2.94.6draft-bruckert-brainpool-for-tls13-07
L. Bruckert, J. Merkle, M. Lochter		112019-09-26
EDIT		2.64.6draft-ietf-pim-reserved-bits-04
S. Venaas, A. Retana		82019-09-26
EDIT		2.64.4draft-ietf-pce-stateful-pce-auto-bandwidth-12
D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang		342019-09-27
EDIT		2.02.9draft-ietf-cbor-sequence-02
C. Bormann		102019-10-08
EDIT*R		1.62.4draft-ietf-acme-ip-08
R. Shoemaker		C40152019-10-11
EDIT		0.61.6draft-ietf-acme-tls-alpn-07
R. Shoemaker		C401102019-10-17
EDIT		1.01.0draft-ietf-httpbis-http2-tls13-03
D. Benjamin		52019-10-21
EDIT		1.01.0draft-ietf-oauth-jwt-bcp-07
Y. Sheffer, D. Hardt, M. Jones		162019-10-21
EDIT		0.01.0draft-ietf-cbor-array-tags-08
C. Bormann		152019-10-21
EDIT*A		1.01.0draft-ietf-pce-lsp-control-request-11
A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi		122019-10-21
EDIT		0.90.9draft-ietf-pce-stateful-hpce-15
D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King		242019-10-22
EDIT*A*R		0.90.9draft-ietf-pce-stateful-path-protection-11
H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi		C402172019-10-22
EDIT*A		0.60.6draft-ietf-6man-segment-routing-header-26
C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer		322019-10-24
EDIT*A		0.60.6draft-ietf-acme-star-11
Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati		302019-10-24
RFC-EDITOR*R		11.937.6draft-ietf-softwire-yang-16
I. Farrer, Ed., M. Boucadair, Ed.		C383522019-02-07
RFC-EDITOR		7.921.0draft-ietf-pce-hierarchy-extensions-11
F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King		312019-06-03
RFC-EDITOR		5.418.9draft-ietf-tsvwg-tinymt32-06
M. Saito, M. Matsumoto, V. Roca, E. Baccelli		C393122019-06-18
RFC-EDITOR*R		5.418.6draft-ietf-tsvwg-rlc-fec-scheme-16
V. Roca, B. Teibi		C393392019-06-20
RFC-EDITOR		5.418.6draft-ietf-tsvwg-fecframe-ext-08
V. Roca, A. Begen		C393212019-06-20
RFC-EDITOR		8.616.4draft-trossen-sfc-name-based-sff-07
D. Trossen, D. Purkayastha, A. Rahman		292019-07-05
RFC-EDITOR		7.015.0draft-ietf-v6ops-nat64-deployment-08
J. Palet Martinez		452019-07-15
RFC-EDITOR		7.414.9draft-ietf-sipcore-rejected-09
E. Burger, B. Nagda		252019-07-16
RFC-EDITOR		6.714.1draft-ietf-oauth-token-exchange-19
M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. Mortimore		362019-07-21
RFC-EDITOR		1.614.0draft-ietf-mptcp-rfc6824bis-18
A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch		822019-07-22
RFC-EDITOR		5.714.0draft-ietf-lamps-pkix-shake-15
P. Kampanakis, Q. Dang		172019-07-22
RFC-EDITOR*R		1.613.0draft-ietf-tram-turnbis-29
T. Reddy, Ed., A. Johnston, Ed., P. Matthews, J. Rosenberg		C396932019-07-29
RFC-EDITOR*R		0.912.6draft-ietf-mpls-egress-protection-framework-07
Y. Shen, M. Jeganathan, B. Decraene, H. Gredler, C. Michel, H. Chen		C340302019-08-01
RFC-EDITOR		7.412.6draft-ietf-pce-association-group-10
I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka		C402302019-08-01
RFC-EDITOR		3.712.0draft-ietf-uta-smtp-require-tls-09
J. Fenton		212019-08-05
RFC-EDITOR		4.69.0draft-ietf-httpbis-rand-access-live-04
C. Pratt, D. Thakore, B. Stark		122019-08-26
RFC-EDITOR		3.98.9draft-ietf-ospf-xaf-te-07
A. Smirnov, A. Retana, M. Barnes		82019-08-27
RFC-EDITOR		3.48.6draft-nottingham-safe-hint-11
M. Nottingham		92019-08-29
RFC-EDITOR		3.48.4draft-ietf-mpls-rfc8287-len-clarification-04
N. Nainar, C. Pignataro, F. Iqbal, A. Vainshtein		62019-08-30
RFC-EDITOR		1.97.9draft-ietf-opsec-urpf-improvements-04
K. Sriram, D. Montgomery, J. Haas		202019-09-03
RFC-EDITOR		1.06.7draft-ietf-oauth-resource-indicators-08
B. Campbell, J. Bradley, H. Tschofenig		142019-09-11
AUTH		67.979.6draft-ribose-asciirfc-08
R. Tse, N. Nicholas, J. Lau, P. Brasolin		1712018-04-19
AUTH48*R		8.7126.4draft-ietf-isis-l2bundles-07
L. Ginsberg, A. Bashandy, C. Filsfils, M. Nanduri, E. Aries		C340182017-05-26
AUTH48*R		0.797.0draft-ietf-ospf-segment-routing-extensions-27
P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura		C340292017-12-18
AUTH48*R		1.967.0draft-ietf-mpls-spring-entropy-label-12
S. Kini, K. Kompella, S. Sivabalan, S. Litkowski, R. Shakir, J. Tantsura		C340262018-07-16
AUTH48*R		0.764.0draft-ietf-idr-bgp-prefix-sid-27
S. Previdi, C. Filsfils, A. Lindem, Ed., A. Sreekantiah, H. Gredler		C340172018-08-06
AUTH48*R		0.747.4draft-ietf-spring-segment-routing-msdc-11
C. Filsfils, Ed., S. Previdi, G. Dawra, E. Aries, P. Lapukhov		C340212018-11-30
AUTH48*R		0.741.4draft-ietf-ospf-ospfv3-segment-routing-extensions-23
P. Psenak, Ed., S. Previdi, Ed.		C340212019-01-11
AUTH48*R		0.732.9draft-ietf-pce-segment-routing-16
S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick		C340332019-03-12
AUTH48		13.031.3draft-ietf-tram-stunbis-21
M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, P. Matthews		C396742019-03-23
AUTH48		8.921.9draft-ietf-spring-segment-routing-mpls-22
A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski, R. Shakir		C340382019-05-28
AUTH48*R		8.920.7draft-ietf-isis-segment-routing-extensions-25
S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene		C340322019-06-05
AUTH48		1.019.0draft-ietf-softwire-iftunnel-07
M. Boucadair, I. Farrer, R. Asati		C383162019-06-17
AUTH48*R		1.918.4draft-ietf-mpls-sr-over-ip-07
X. Xu, S. Bryant, A. Farrel, S. Hassan, W. Henderickx, Z. Li		C340182019-06-21
AUTH48		1.611.6draft-ietf-netconf-restconf-notif-15
E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman		C390282019-08-08
AUTH48		2.09.0draft-ietf-grow-bmp-adj-rib-out-07
T. Evens, S. Bayraktar, P. Lucente, P. Mi, S. Zhuang		112019-08-26
AUTH48-DONE*R		0.659.6draft-ietf-spring-segment-routing-ldp-interop-15
A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski		C340232018-09-06
AUTH48-DONE		5.419.6draft-ietf-lamps-rfc6844bis-07
P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews		C394182019-06-13
AUTH48-DONE		0.019.0draft-ietf-pim-igmp-mld-yang-15
X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter		492019-06-17
AUTH48-DONE		0.419.0draft-ietf-softwire-map-radius-26
S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair		402019-06-17
AUTH48-DONE*R		3.918.6draft-ietf-acme-caa-10
H. Landau		C394112019-06-20
AUTH48-DONE		0.011.9draft-ietf-dmm-ondemand-mobility-18
A. Yegin, D. Moses, S. Jeon		122019-08-06
AUTH48-DONE		0.411.0draft-sheffer-tls-pinning-ticket-12
Y. Sheffer, D. Migault		292019-08-12
MISSREF*R(1G)		235.4235.6draft-ietf-lisp-introduction-13
A. Cabellos-Aparicio, D. Saucez, Ed.		C251272015-04-23
MISSREF*R(1G)		198.9199.0draft-ietf-lwig-cellular-06
J. Arkko, A. Eriksson, A. Keranen		C280162016-01-04
MISSREF*R(1G)		197.6197.6draft-ietf-clue-framework-25
M. Duckworth, Ed., A. Pepperell, S. Wenger		C238842016-01-14
MISSREF*R(1G)		163.7167.0draft-ietf-clue-data-model-schema-17
R. Presta, S. Pietro Romano		C238772016-08-15
MISSREF*R(1G)		119.9120.4draft-ietf-avtext-lrr-07
J. Lennox, D. Hong, J. Uberti, S. Holmer, M. Flodman		C324152017-07-07
MISSREF*R(1G)		118.4118.7draft-ietf-anima-grasp-15
C. Bormann, B. Carpenter, Ed., B. Liu, Ed.		C325812017-07-19
MISSREF*R(1G)		104.6104.9draft-ietf-ospf-encapsulation-cap-09
X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil		C349112017-10-24
MISSREF*R(1G)		94.696.9draft-ietf-anima-prefix-management-07
S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun		C325222017-12-19
MISSREF*R(1G)		86.086.0draft-ietf-bess-dci-evpn-overlay-10
J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake		C349292018-03-05
MISSREF*R(1G)		84.785.0draft-ietf-trill-ecn-support-07
D. Eastlake 3rd, B. Briscoe		C350202018-03-12
MISSREF*R(1G)		83.984.4draft-ietf-netmod-syslog-model-26
C. Wildes, Ed., K. Koushik, Ed.		C336312018-03-16
MISSREF*R(1G)		73.974.6draft-ietf-bess-evpn-prefix-advertisement-11
J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi		C355362018-05-24
MISSREF*R(1G)		67.467.7draft-ietf-ippm-twamp-yang-13
R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed.		C365682018-07-11
MISSREF*R(1G)		66.666.6draft-ietf-dnssd-hybrid-10
S. Cheshire		C367372018-07-19
MISSREF*R(1G)		63.464.0draft-ietf-bfd-yang-17
R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky		C336792018-08-06
MISSREF*R(1G)		58.959.0draft-ietf-homenet-babel-profile-07
J. Chroboczek		C36892018-09-10
MISSREF*R(1G)		55.956.0draft-ietf-taps-minset-11
M. Welzl, S. Gjessing		C370502018-10-01
MISSREF*R(1G)		48.048.3draft-ietf-anima-reference-model-10
M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre		C325302018-11-24
MISSREF*R(1G)		43.044.4draft-ietf-httpbis-expect-ct-08
E. Stark		C377232018-12-21
MISSREF*R(1G)		39.039.0draft-ietf-lisp-rfc8113bis-03
M. Boucadair, C. Jacquenet		C38162019-01-28
MISSREF*R(1G)		30.931.7draft-ietf-pce-wson-rwa-ext-17
Y. Lee, Ed., R. Casellas, Ed.		C385332019-03-20
MISSREF*R(1G)		31.031.3draft-ietf-hip-rfc4423-bis-20
R. Moskowitz, Ed., M. Komu		C386502019-03-23
MISSREF*R(1G)		21.621.6draft-ietf-rmcat-eval-test-10
Z. Sarker, V. Singh, X. Zhu, M. Ramalho		C238332019-05-30
MISSREF*R(1G)		19.919.9draft-ietf-perc-private-media-framework-12
P. Jones, D. Benham, C. Groves		C391282019-06-11
MISSREF*R(1G)		19.419.7draft-jenkins-cnsa-cmc-profile-05
M. Jenkins, L. Zieglar		C392192019-06-12
MISSREF*R(1G)		15.716.6draft-ietf-idr-bgp-ls-segment-routing-ext-16
S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen		C340312019-07-04
MISSREF*R(1G)		14.7draft-aranda-dispatch-q4s-10
J. Aranda, M. Cortes, J. Salvachua, M. Narganes, I. Sarriegui		C399832019-07-17
MISSREF*R(1G)		13.914.4draft-ietf-teas-yang-te-topo-22
X. Liu, I. Bryskin, V. Beeram, T. Saad, H. Shah, O. Dios		C3952112019-07-19
MISSREF*R(1G)		10.010.9draft-ietf-dots-data-channel-31
M. Boucadair, Ed., K. Reddy, Ed.		C398752019-08-13
MISSREF*R(1G)		1.99.4draft-sekar-dns-llq-06
S. Cheshire, M. Krochmal		C367262019-08-23
MISSREF*R(1G)		2.62.6draft-ietf-intarea-frag-fragile-17
R. Bonica, F. Baker, G. Huston, B. Hinden, O. Trøan, F. Gont		C400282019-10-10
MISSREF*R(1G)		1.92.6draft-ietf-6lo-deadline-time-05
L. Thomas, S. Anamalamudi, S. Anand, M. Hegde, C. Perkins		C310212019-10-10
MISSREF*R(2G)		71.0139.0draft-ietf-clue-rtp-mapping-14
R. Even, J. Lennox		C238142017-02-27
MISSREF*R(2G)		63.675.7draft-ietf-pim-yang-17
X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, f. Hu		C3361072018-05-16
MISSREF*R(2G)		16.623.0draft-ietf-idr-bgpls-segment-routing-epe-19
S. Previdi, K. Talaulikar, C. Filsfils, K. Patel, S. Ray, J. Dong		C340182019-05-20
MISSREF*R(2G)		8.49.0draft-ietf-ospf-yang-29
D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem		C3361322019-08-26
MISSREF*R(2G)		0.91.6draft-ietf-isis-yang-isis-cfg-42
S. Litkowski, D. Yeung, A. Lindem, Z. Zhang, L. Lhotka		C3361182019-10-17
MISSREF*R(3G)		16.696.6draft-ietf-spring-segment-routing-central-epe-10
C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev		C340192017-12-21
REF*R		10.0250.6draft-ietf-rtcweb-data-channel-13
R. Jesup, S. Loreto, M. Tuexen		C238162015-01-08
REF*R		8.9250.6draft-ietf-rtcweb-data-protocol-09
R. Jesup, S. Loreto, M. Tuexen		C238132015-01-08
REF*R		5.4225.7draft-ietf-rtcweb-rtp-usage-26
C. Perkins, M. Westerlund, J. Ott		C238452015-07-01
REF*R		10.0180.6draft-ietf-rtcweb-alpn-04
M. Thomson		C23872016-05-12
REF*R		0.9171.9draft-ietf-mmusic-msid-17
H. Alvestrand		C238182016-07-12
REF*R		10.4167.9draft-ietf-mmusic-mux-exclusive-12
C. Holmberg		C238122016-08-09
REF*R		10.0166.0draft-ietf-tsvwg-rtcweb-qos-18
P. Jones, S. Dhesikan, C. Jennings, D. Druta		C238112016-08-22
REF*R		10.4157.7draft-ietf-avtext-rid-09
A. Roach, S. Nandakumar, P. Thatcher		C23892016-10-19
REF*R		9.1156.6draft-ietf-rtcweb-transports-17
H. Alvestrand		C238202016-10-27
REF*R		10.4148.9draft-ietf-mmusic-sdp-mux-attributes-17
S. Nandakumar		C238962016-12-20
REF*R		1.6102.1draft-ietf-rtcweb-overview-19
H. Alvestrand		C238242017-11-12
REF*R		10.475.7draft-ietf-mmusic-rid-15
A.B. Roach, Ed.		C238282018-05-16
REF		36.774.9draft-ietf-ice-trickle-21
E. Ivov, J. Uberti, P. Saint-Andre		C238332018-05-22
REF*R		1.071.4draft-ietf-mtgvenue-iaoc-venue-selection-process-16
E. Lear, Ed.		C388132018-06-15
REF*R		10.467.9draft-ietf-mmusic-sdp-simulcast-14
B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty		C238412018-07-10
REF		1.063.7draft-ietf-mtgvenue-meeting-policy-07
S. Krishnan		C38852018-08-08
REF*R		8.951.0draft-ietf-iasa2-trust-rationale-03
J. Arkko		C38862018-11-05
REF*R		8.951.0draft-ietf-iasa2-trust-update-03
J. Arkko, T. Hardie		C38852018-11-05
REF		6.414.9draft-ietf-rtcweb-fec-10
J. Uberti		C238132019-07-16
REF*R		4.910.9draft-ietf-mmusic-sdp-uks-07
M. Thomson, E. Rescorla		C238192019-08-13
REF		3.710.7draft-ietf-mmusic-ice-sip-sdp-39
M. Petit-Huguenin, S. Nandakumar, C. Holmberg, A. Keränen, R. Shpount		C238432019-08-14
IESG		7.915.6draft-ietf-roll-useofrplinfo-31
M. Robles, M. Richardson, P. Thubert		542019-07-11
IESG		8.415.6draft-ietf-roll-efficient-npdao-16
R. Jadhav, Ed., P. Thubert, R. Sahoo, Z. Cao		232019-07-11


./draft-ietf-bess-evpn-prefix-advertisement-11.txt0000644000764400076440000024223513277623635021445 0ustar iustyiusty BESS Workgroup J. Rabadan, Ed. Internet Draft W. Henderickx Intended status: Standards Track Nokia J. Drake W. Lin Juniper A. Sajassi Cisco Expires: November 19, 2018 May 18, 2018 IP Prefix Advertisement in EVPN draft-ietf-bess-evpn-prefix-advertisement-11 Abstract The BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO (Network Virtualization Overlay) [RFC7365] network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. 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), 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 Rabadan et al. Expires November 19, 2018 [Page 1] Internet-Draft EVPN Prefix Advertisement May 18, 2018 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 November 19, 2018. Copyright Notice Copyright (c) 2018 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Inter-Subnet Connectivity Requirements in Data Centers . . . 5 2.2 The Need for the EVPN IP Prefix Route . . . . . . . . . . . 8 3. The BGP EVPN IP Prefix Route . . . . . . . . . . . . . . . . . 10 3.1 IP Prefix Route Encoding . . . . . . . . . . . . . . . . . . 11 3.2 Overlay Indexes and Recursive Lookup Resolution . . . . . . 13 4. Overlay Index Use-Cases . . . . . . . . . . . . . . . . . . . . 15 4.1 TS IP Address Overlay Index Use-Case . . . . . . . . . . . . 16 4.2 Floating IP Overlay Index Use-Case . . . . . . . . . . . . . 18 4.3 Bump-in-the-Wire Use-Case . . . . . . . . . . . . . . . . . 20 4.4 IP-VRF-to-IP-VRF Model . . . . . . . . . . . . . . . . . . . 23 4.4.1 Interface-less IP-VRF-to-IP-VRF Model . . . . . . . . . 24 4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD IRB . . . . . . 27 4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 33 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 34 7.2 Informative References . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 35 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 Rabadan et al. Expires November 19, 2018 [Page 2] Internet-Draft EVPN Prefix Advertisement May 18, 2018 1. Introduction [RFC7365] provides a framework for Data Center (DC) Network Virtualization over Layer 3 and specifies that the Network Virtualization Edge devices (NVEs) must provide layer 2 and layer 3 virtualized network services in multi-tenant DCs. [RFC8365] discusses the use of EVPN as the technology of choice to provide layer 2 or intra-subnet services in these DCs. This document, along with [EVPN- INTERSUBNET], specifies the use of EVPN for layer 3 or inter-subnet connectivity services. [EVPN-INTERSUBNET] defines some fairly common inter-subnet forwarding scenarios where TSes can exchange packets with TSes located in remote subnets. In order to achieve this, [EVPN-INTERSUBNET] describes how MAC/IPs encoded in TS RT-2 routes are not only used to populate MAC- VRF and overlay ARP tables, but also IP-VRF tables with the encoded TS host routes (/32 or /128). In some cases, EVPN may advertise IP Prefixes and therefore provide aggregation in the IP-VRF tables, as opposed to propagate individual host routes. This document complements the scenarios described in [EVPN-INTERSUBNET] and defines how EVPN may be used to advertise IP Prefixes. Interoperability between EVPN and L3VPN [RFC4364] IP Prefix routes is out of the scope of this document. Section 2.1 describes the inter-subnet connectivity requirements in Data Centers. Section 2.2 explains why a new EVPN route type is required for IP Prefix advertisements. Sections 3, 4 and 5 will describe this route type and how it is used in some specific use cases. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. AC: Attachment Circuit. ARP: Address Resolution Protocol. BD: Broadcast Domain. As per [RFC7432], an EVI consists of a single or multiple BDs. In case of VLAN-bundle and VLAN-based service models (see [RFC7432]), a BD is equivalent to an EVI. In case of VLAN-aware bundle service model, an EVI contains multiple BDs. Also, in this document, BD and subnet are equivalent terms. Rabadan et al. Expires November 19, 2018 [Page 3] Internet-Draft EVPN Prefix Advertisement May 18, 2018 BD Route Target: refers to the Broadcast Domain assigned Route Target [RFC4364]. In case of VLAN-aware bundle service model, all the BD instances in the MAC-VRF share the same Route Target. BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as per [RFC7432]. DGW: Data Center Gateway. Ethernet A-D route: Ethernet Auto-Discovery (A-D) route, as per [RFC7432]. Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels with Ethernet payload. Examples of this type of tunnels are VXLAN or GENEVE. EVI: EVPN Instance spanning the NVE/PE devices that are participating on that EVPN, as per [RFC7432]. EVPN: Ethernet Virtual Private Networks, as per [RFC7432]. GRE: Generic Routing Encapsulation. GW IP: Gateway IP Address. IPL: IP Prefix Length. IP NVO tunnel: it refers to Network Virtualization Overlay tunnels with IP payload (no MAC header in the payload). IP-VRF: A VPN Routing and Forwarding table for IP routes on an NVE/PE. The IP routes could be populated by EVPN and IP-VPN address families. An IP-VRF is also an instantiation of a layer 3 VPN in an NVE/PE. IRB: Integrated Routing and Bridging interface. It connects an IP-VRF to a BD (or subnet). MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF is also an instantiation of an EVI in an NVE/PE. ML: MAC address length. ND: Neighbor Discovery Protocol. NVE: Network Virtualization Edge. Rabadan et al. Expires November 19, 2018 [Page 4] Internet-Draft EVPN Prefix Advertisement May 18, 2018 GENEVE: Generic Network Virtualization Encapsulation, [GENEVE]. NVO: Network Virtualization Overlays. RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as defined in [RFC7432]. RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in Section 3. SBD: Supplementary Broadcast Domain. A BD that does not have any ACs, only IRB interfaces, and it is used to provide connectivity among all the IP-VRFs of the tenant. The SBD is only required in IP-VRF- to-IP-VRF use-cases (see Section 4.4.). SN: Subnet. TS: Tenant System. VA: Virtual Appliance. VNI: Virtual Network Identifier. As in [RFC8365], the term is used as a representation of a 24-bit NVO instance identifier, with the understanding that VNI will refer to a VXLAN Network Identifier in VXLAN, or Virtual Network Identifier in GENEVE, etc. unless it is stated otherwise. VTEP: VXLAN Termination End Point, as in [RFC7348]. VXLAN: Virtual Extensible LAN, as in [RFC7348]. This document also assumes familiarity with the terminology of [RFC7432], [RFC8365] and [RFC7365]. 2. Problem Statement This Section describes the inter-subnet connectivity requirements in Data Centers and why a specific route type to advertise IP Prefixes is needed. 2.1 Inter-Subnet Connectivity Requirements in Data Centers [RFC7432] is used as the control plane for a Network Virtualization Overlay (NVO) solution in Data Centers (DC), where Network Virtualization Edge (NVE) devices can be located in Hypervisors or Rabadan et al. Expires November 19, 2018 [Page 5] Internet-Draft EVPN Prefix Advertisement May 18, 2018 Top of Rack switches (ToRs), as described in [RFC8365]. The following considerations apply to Tenant Systems (TS) that are physical or virtual systems identified by MAC and maybe IP addresses and connected to BDs by Attachment Circuits: o The Tenant Systems may be Virtual Machines (VMs) that generate traffic from their own MAC and IP. o The Tenant Systems may be Virtual Appliance entities (VAs) that forward traffic to/from IP addresses of different End Devices sitting behind them. o These VAs can be firewalls, load balancers, NAT devices, other appliances or virtual gateways with virtual routing instances. o These VAs do not necessarily participate in dynamic routing protocols and hence rely on the EVPN NVEs to advertise the routes on their behalf. o In all these cases, the VA will forward traffic to other TSes using its own source MAC but the source IP will be the one associated to the End Device sitting behind or a translated IP address (part of a public NAT pool) if the VA is performing NAT. o Note that the same IP address and endpoint could exist behind two of these TSes. One example of this would be certain appliance resiliency mechanisms, where a virtual IP or floating IP can be owned by one of the two VAs running the resiliency protocol (the master VA). Virtual Router Redundancy Protocol (VRRP), RFC5798, is one particular example of this. Another example is multi-homed subnets, i.e., the same subnet is connected to two VAs. o Although these VAs provide IP connectivity to VMs and subnets behind them, they do not always have their own IP interface connected to the EVPN NVE, e.g., layer 2 firewalls are examples of VAs not supporting IP interfaces. Figure 1 illustrates some of the examples described above. Rabadan et al. Expires November 19, 2018 [Page 6] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1 +-----------+ TS1(VM)--| (BD-10) |-----+ IP1/M1 +-----------+ | DGW1 +---------+ +-------------+ | |----| (BD-10) | SN1---+ NVE2 | | | IRB1\ | | +-----------+ | | | (IP-VRF)|---+ SN2---TS2(VA)--| (BD-10) |-| | +-------------+ _|_ | IP2/M2 +-----------+ | VXLAN/ | ( ) IP4---+ <-+ | GENEVE | DGW2 ( WAN ) | | | +-------------+ (___) vIP23 (floating) | |----| (BD-10) | | | +---------+ | IRB2\ | | SN1---+ <-+ NVE3 | | | | (IP-VRF)|---+ | IP3/M3 +-----------+ | | | +-------------+ SN3---TS3(VA)--| (BD-10) |---+ | | | +-----------+ | | IP5---+ | | | | NVE4 | | NVE5 +--SN5 +---------------------+ | | +-----------+ | IP6------| (BD-1) | | +-| (BD-10) |--TS4(VA)--SN6 | \ | | +-----------+ | | (IP-VRF) |--+ ESI4 +--SN7 | / \IRB3 | |---| (BD-2) (BD-10) | SN4| +---------------------+ Figure 1 DC inter-subnet use-cases Where: NVE1, NVE2, NVE3, NVE4, NVE5, DGW1 and DGW2 share the same BD for a particular tenant. BD-10 is comprised of the collection of BD instances defined in all the NVEs. All the hosts connected to BD-10 belong to the same IP subnet. The hosts connected to BD-10 are listed below: o TS1 is a VM that generates/receives traffic from/to IP1, where IP1 belongs to the BD-10 subnet. o TS2 and TS3 are Virtual Appliances (VA) that send/receive traffic from/to the subnets and hosts sitting behind them (SN1, SN2, SN3, IP4 and IP5). Their IP addresses (IP2 and IP3) belong to the BD-10 subnet and they can also generate/receive traffic. When these VAs receive packets destined to their own MAC addresses (M2 and M3) they will route the packets to the proper subnet or host. These VAs Rabadan et al. Expires November 19, 2018 [Page 7] Internet-Draft EVPN Prefix Advertisement May 18, 2018 do not support routing protocols to advertise the subnets connected to them and can move to a different server and NVE when the Cloud Management System decides to do so. These VAs may also support redundancy mechanisms for some subnets, similar to VRRP, where a floating IP is owned by the master VA and only the master VA forwards traffic to a given subnet. E.g.,: vIP23 in Figure 1 is a floating IP that can be owned by TS2 or TS3 depending on which system is the master. Only the master will forward traffic to SN1. o Integrated Routing and Bridging interfaces IRB1, IRB2 and IRB3 have their own IP addresses that belong to the BD-10 subnet too. These IRB interfaces connect the BD-10 subnet to Virtual Routing and Forwarding (IP-VRF) instances that can route the traffic to other subnets for the same tenant (within the DC or at the other end of the WAN). o TS4 is a layer 2 VA that provides connectivity to subnets SN5, SN6 and SN7, but does not have an IP address itself in the BD-10. TS4 is connected to a port on NVE5 assigned to Ethernet Segment Identifier 4. For a BD that an ingress NVE is attached to, "Overlay Index" is defined as an identifier that the ingress EVPN NVE requires in order to forward packets to a subnet or host in a remote subnet. As an example, vIP23 (Figure 1) is an Overlay Index that any NVE attached to BD-10 needs to know in order to forward packets to SN1. IRB3 IP address is an Overlay Index required to get to SN4, and ESI4 (Ethernet Segment Identifier 4) is an Overlay Index needed to forward traffic to SN5. In other words, the Overlay Index is a next-hop in the overlay address space that can be an IP address, a MAC address or an ESI. When advertised along with an IP Prefix, the Overlay Index requires a recursive resolution to find out to what egress NVE the EVPN packets need to be sent. All the DC use cases in Figure 1 require inter-subnet forwarding and therefore, the individual host routes and subnets: a) must be advertised from the NVEs (since VAs and VMs do not participate in dynamic routing protocols) and b) may be associated to an Overlay Index that can be a VA IP address, a floating IP address, a MAC address or an ESI. The Overlay Index is further discussed in Section 3.2. 2.2 The Need for the EVPN IP Prefix Route [RFC7432] defines a MAC/IP route (also referred as RT-2) where a MAC Rabadan et al. Expires November 19, 2018 [Page 8] Internet-Draft EVPN Prefix Advertisement May 18, 2018 address can be advertised together with an IP address length and IP address (IP). While a variable IP address length might have been used to indicate the presence of an IP prefix in a route type 2, there are several specific use cases in which using this route type to deliver IP Prefixes is not suitable. One example of such use cases is the "floating IP" example described in Section 2.1. In this example it is needed to decouple the advertisement of the prefixes from the advertisement of MAC address of either M2 or M3, otherwise the solution gets highly inefficient and does not scale. For example, if 1,000 prefixes are advertised from M2 (using RT-2) and the floating IP owner changes from M2 to M3, 1,000 routes would be withdrawn from M2 and readvertise 1k routes from M3. However if a separate route type is used, 1,000 routes can be advertised as associated to the floating IP address (vIP23) and only one RT-2 for advertising the ownership of the floating IP, i.e., vIP23 and M2 in the route type 2. When the floating IP owner changes from M2 to M3, a single RT-2 withdraw/update is required to indicate the change. The remote DGW will not change any of the 1,000 prefixes associated to vIP23, but will only update the ARP resolution entry for vIP23 (now pointing at M3). An EVPN route (type 5) for the advertisement of IP Prefixes is described in this document. This new route type has a differentiated role from the RT-2 route and addresses the Data Center (or NVO-based networks in general) inter-subnet connectivity scenarios described in this document. Using this new RT-5, an IP Prefix may be advertised along with an Overlay Index that can be a GW IP address, a MAC or an ESI, or without an Overlay Index, in which case the BGP next-hop will point at the egress NVE/ASBR/ABR and the MAC in the Router's MAC Extended Community will provide the inner MAC destination address to be used. As discussed throughout the document, the EVPN RT-2 does not meet the requirements for all the DC use cases, therefore this EVPN route type 5 is required. The EVPN route type 5 decouples the IP Prefix advertisements from the MAC/IP route advertisements in EVPN, hence: a) Allows the clean and clear advertisements of IPv4 or IPv6 prefixes in an NLRI (Network Layer Reachability Information message) with no MAC addresses. b) Since the route type is different from the MAC/IP Advertisement route, the current [RFC7432] procedures do not need to be modified. Rabadan et al. Expires November 19, 2018 [Page 9] Internet-Draft EVPN Prefix Advertisement May 18, 2018 c) Allows a flexible implementation where the prefix can be linked to different types of Overlay/Underlay Indexes: overlay IP address, overlay MAC addresses, overlay ESI, underlay BGP next-hops, etc. d) An EVPN implementation not requiring IP Prefixes can simply discard them by looking at the route type value. The following Sections describe how EVPN is extended with a route type for the advertisement of IP prefixes and how this route is used to address the inter-subnet connectivity requirements existing in the Data Center. 3. The BGP EVPN IP Prefix Route The BGP EVPN NLRI as defined in [RFC7432] is shown below: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ Figure 2 BGP EVPN NLRI This document defines an additional route type (RT-5) in the IANA EVPN Route Types registry [EVPNRouteTypes], to be used for the advertisement of EVPN routes using IP Prefixes: Value: 5 Description: IP Prefix Route According to Section 5.4 in [RFC7606], a node that doesn't recognize the Route Type 5 (RT-5) will ignore it. Therefore an NVE following this document can still be attached to a BD where an NVE ignoring RT- 5s is attached to. Regular [RFC7432] procedures would apply in that case for both NVEs. In case two or more NVEs are attached to different BDs of the same tenant, they MUST support RT-5 for the proper Inter-Subnet Forwarding operation of the tenant. The detailed encoding of this route and associated procedures are described in the following Sections. Rabadan et al. Expires November 19, 2018 [Page 10] Internet-Draft EVPN Prefix Advertisement May 18, 2018 3.1 IP Prefix Route Encoding An IP Prefix Route Type for IPv4 has the Length field set to 34 and consists of the following fields: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | IP Prefix Length (1 octet, 0 to 32) | +---------------------------------------+ | IP Prefix (4 octets) | +---------------------------------------+ | GW IP Address (4 octets) | +---------------------------------------+ | MPLS Label (3 octets) | +---------------------------------------+ Figure 3 EVPN IP Prefix route NLRI for IPv4 An IP Prefix Route Type for IPv6 has the Length field set to 58 and consists of the following fields: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | IP Prefix Length (1 octet, 0 to 128) | +---------------------------------------+ | IP Prefix (16 octets) | +---------------------------------------+ | GW IP Address (16 octets) | +---------------------------------------+ | MPLS Label (3 octets) | +---------------------------------------+ Figure 4 EVPN IP Prefix route NLRI for IPv6 Where: Rabadan et al. Expires November 19, 2018 [Page 11] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o The Length field of the BGP EVPN NLRI for an EVPN IP Prefix route MUST be either 34 (if IPv4 addresses are carried) or 58 (if IPv6 addresses are carried). The IP Prefix and Gateway IP Address MUST be from the same IP address family. o Route Distinguisher (RD) and Ethernet Tag ID MUST be used as defined in [RFC7432] and [RFC8365]. In particular, the RD is unique per MAC-VRF (or IP-VRF). The MPLS Label field is set to either an MPLS label or a VNI, as described in [RFC8365] for other EVPN route types. o The Ethernet Segment Identifier MUST be a non-zero 10-octet identifier if the ESI is used as an Overlay Index (see the definition of Overlay Index in Section 3.2). It MUST be all bytes zero otherwise. The ESI format is described in [RFC7432]. o The IP Prefix Length can be set to a value between 0 and 32 (bits) for IPv4 and between 0 and 128 for IPv6, and specifies the number of bits in the Prefix. The value MUST NOT be greater than 128. o The IP Prefix is a 4 or 16-octet field (IPv4 or IPv6). o The GW (Gateway) IP Address field is a 4 or 16-octet field (IPv4 or IPv6), and will encode a valid IP address as an Overlay Index for the IP Prefixes. The GW IP field MUST be all bytes zero if it is not used as an Overlay Index. Refer to Section 3.2 for the definition and use of the Overlay Index. o The MPLS Label field is encoded as 3 octets, where the high-order 20 bits contain the label value, as per [RFC7432]. When sending, the label value SHOULD be zero if recursive resolution based on overlay index is used. If the received MPLS Label value is zero, the route MUST contain an Overlay Index and the ingress NVE/PE MUST do recursive resolution to find the egress NVE/PE. If the received Label is zero and the route does not contain an Overlay Index, it MUST be treat-as-withdraw [RFC7606]. The RD, Ethernet Tag ID, IP Prefix Length and IP Prefix are part of the route key used by BGP to compare routes. The rest of the fields are not part of the route key. An IP Prefix Route MAY be sent along with a Router's MAC Extended Community (defined in [EVPN-INTERSUBNET]) to carry the MAC address that is used as the overlay index. Note that the MAC address may be that of an TS. As described in Section 3.2, certain data combinations in a received routes would imply a "treat-as-withdraw" handling of the route Rabadan et al. Expires November 19, 2018 [Page 12] Internet-Draft EVPN Prefix Advertisement May 18, 2018 [RFC7606]. 3.2 Overlay Indexes and Recursive Lookup Resolution RT-5 routes support recursive lookup resolution through the use of Overlay Indexes as follows: o An Overlay Index can be an ESI, IP address in the address space of the tenant or MAC address and it is used by an NVE as the next-hop for a given IP Prefix. An Overlay Index always needs a recursive route resolution on the NVE/PE that installs the RT-5 into one of its IP-VRFs, so that the NVE knows to which egress NVE/PE it needs to forward the packets. It is important to note that recursive resolution of the Overlay Index applies upon installation into an IP-VRF, and not upon BGP propagation (for instance, on an ASBR). Also, as a result of the recursive resolution, the egress NVE/PE is not necessarily the same NVE that originated the RT-5. o The Overlay Index is indicated along with the RT-5 in the ESI field, GW IP field or Router's MAC Extended Community, depending on whether the IP Prefix next-hop is an ESI, IP address or MAC address in the tenant space. The Overlay Index for a given IP Prefix is set by local policy at the NVE that originates an RT-5 for that IP Prefix (typically managed by the Cloud Management System). o In order to enable the recursive lookup resolution at the ingress NVE, an NVE that is a possible egress NVE for a given Overlay Index must originate a route advertising itself as the BGP next hop on the path to the system denoted by the Overlay Index. For instance: . If an NVE receives an RT-5 that specifies an Overlay Index, the NVE cannot use the RT-5 in its IP-VRF unless (or until) it can recursively resolve the Overlay Index. . If the RT-5 specifies an ESI as the Overlay Index, recursive resolution can only be done if the NVE has received and installed an RT-1 (Auto-Discovery per-EVI) route specifying that ESI. . If the RT-5 specifies a GW IP address as the Overlay Index, recursive resolution can only be done if the NVE has received and installed an RT-2 (MAC/IP route) specifying that IP address in the IP address field of its NLRI. . If the RT-5 specifies a MAC address as the Overlay Index, recursive resolution can only be done if the NVE has received and installed an RT-2 (MAC/IP route) specifying that MAC address in the MAC address field of its NLRI. Note that the RT-1 or RT-2 routes needed for the recursive resolution may arrive before or after the given RT-5 route. Rabadan et al. Expires November 19, 2018 [Page 13] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Irrespective of the recursive resolution, if there is no IGP or BGP route to the BGP next-hop of an RT-5, BGP MUST NOT install the RT-5 even if the Overlay Index can be resolved. o The ESI and GW IP fields may both be zero at the same time. However, they MUST NOT both be non-zero at the same time. A route containing a non-zero GW IP and a non-zero ESI (at the same time) SHOULD be treat-as-withdraw [RFC7606]. o If either the ESI or GW IP are non-zero, then the non-zero one is the Overlay Index, regardless of whether the Router's MAC Extended Community is present or the value of the Label. In case the GW IP is the Overlay Index (hence ESI is zero), the Router's MAC Extended Community is ignored if present. o A route where ESI, GW IP, MAC and Label are all zero at the same time SHOULD be treat-as-withdraw. The indirection provided by the Overlay Index and its recursive lookup resolution is required to achieve fast convergence in case of a failure of the object represented by the Overlay Index (see the example described in Section 2.2). Table 1 shows the different RT-5 field combinations allowed by this specification and what Overlay Index must be used by the receiving NVE/PE in each case. Those cases where there is no Overlay Index, are indicated as "None" in Table 1. If there is no Overlay Index the receiving NVE/PE will not perform any recursive resolution, and the actual next-hop is given by the RT-5's BGP next-hop. +----------+----------+----------+------------+----------------+ | ESI | GW IP | MAC* | Label | Overlay Index | |--------------------------------------------------------------| | Non-Zero | Zero | Zero | Don't Care | ESI | | Non-Zero | Zero | Non-Zero | Don't Care | ESI | | Zero | Non-Zero | Zero | Don't Care | GW IP | | Zero | Zero | Non-Zero | Zero | MAC | | Zero | Zero | Non-Zero | Non-Zero | MAC or None** | | Zero | Zero | Zero | Non-Zero | None*** | +----------+----------+----------+------------+----------------+ Table 1 - RT-5 fields and Indicated Overlay Index Table NOTES: * MAC with Zero value means no Router's MAC extended community is present along with the RT-5. Non-Zero indicates that the extended community is present and carries a valid MAC address. The Rabadan et al. Expires November 19, 2018 [Page 14] Internet-Draft EVPN Prefix Advertisement May 18, 2018 encoding of a MAC address MUST be the 6-octet MAC address specified by [802.1Q] and [802.1D-REV]. Examples of invalid MAC addresses are broadcast or multicast MAC addresses. The route MUST be treat-as-withdraw in case of an invalid MAC address. The presence of the Router's MAC extended community alone is not enough to indicate the use of the MAC address as the Overlay Index, since the extended community can be used for other purposes. ** In this case, the Overlay Index may be the RT-5's MAC address or None, depending on the local policy of the receiving NVE/PE. Note that the advertising NVE/PE that sets the Overlay Index SHOULD advertise an RT-2 for the MAC Overlay Index if there are receiving NVE/PEs configured to use the MAC as the Overlay Index. This case in Table 1 is used in the IP-VRF-to-IP-VRF implementations described in 4.4.1 and 4.4.3. The support of a MAC Overlay Index in this model is OPTIONAL. *** The Overlay Index is None. This is a special case used for IP- VRF-to-IP-VRF where the NVE/PEs are connected by IP NVO tunnels as opposed to Ethernet NVO tunnels. If the combination of ESI, GW IP, MAC and Label in the receiving RT-5 is different than the combinations shown in Table 1, the router will process the route as per the rules described at the beginning of this Section (3.2). Table 2 shows the different inter-subnet use-cases described in this document and the corresponding coding of the Overlay Index in the route type 5 (RT-5). +---------+---------------------+----------------------------+ | Section | Use-case | Overlay Index in the RT-5 | +-------------------------------+----------------------------+ | 4.1 | TS IP address | GW IP | | 4.2 | Floating IP address | GW IP | | 4.3 | "Bump in the wire" | ESI or MAC | | 4.4 | IP-VRF-to-IP-VRF | GW IP, MAC or None | +---------+---------------------+----------------------------+ Table 2 - Use-cases and Overlay Indexes for Recursive Resolution The above use-cases are representative of the different Overlay Indexes supported by RT-5 (GW IP, ESI, MAC or None). 4. Overlay Index Use-Cases Rabadan et al. Expires November 19, 2018 [Page 15] Internet-Draft EVPN Prefix Advertisement May 18, 2018 This Section describes some use-cases for the Overlay Index types used with the IP Prefix route. Although the examples use IPv4 Prefixes and subnets, the descriptions of the RT-5 are valid for the same cases with IPv6, only replacing the IP Prefixes, IPL and GW IP by the corresponding IPv6 values. 4.1 TS IP Address Overlay Index Use-Case Figure 5 illustrates an example of inter-subnet forwarding for subnets sitting behind Virtual Appliances (on TS2 and TS3). IP4---+ NVE2 DGW1 | +-----------+ +---------+ +-------------+ SN2---TS2(VA)--| (BD-10) |-| |----| (BD-10) | | IP2/M2 +-----------+ | | | IRB1\ | -+---+ | | | (IP-VRF)|---+ | | | +-------------+ _|_ SN1 | VXLAN/ | ( ) | | GENEVE | DGW2 ( WAN ) -+---+ NVE3 | | +-------------+ (___) | IP3/M3 +-----------+ | |----| (BD-10) | | SN3---TS3(VA)--| (BD-10) |-| | | IRB2\ | | | +-----------+ +---------+ | (IP-VRF)|---+ IP5---+ +-------------+ Figure 5 TS IP address use-case An example of inter-subnet forwarding between subnet SN1, which uses a 24 bit IP prefix (written as SN1/24 in future), and a subnet sitting in the WAN is described below. NVE2, NVE3, DGW1 and DGW2 are running BGP EVPN. TS2 and TS3 do not participate in dynamic routing protocols, and they only have a static route to forward the traffic to the WAN. SN1/24 is dual-homed to NVE2 and NVE3. In this case, a GW IP is used as an Overlay Index. Although a different Overlay Index type could have been used, this use-case assumes that the operator knows the VA's IP addresses beforehand, whereas the VA's MAC address is unknown and the VA's ESI is zero. Because of this, the GW IP is the suitable Overlay Index to be used with the RT-5s. The NVEs know the GW IP to be used for a given Prefix by policy. (1) NVE2 advertises the following BGP routes on behalf of TS2: o Route type 2 (MAC/IP route) containing: ML=48 (MAC Address Length), M=M2 (MAC Address), IPL=32 (IP Prefix Length), IP=IP2 and [RFC5512] BGP Encapsulation Extended Community with the corresponding Tunnel type. The MAC and IP addresses may be Rabadan et al. Expires November 19, 2018 [Page 16] Internet-Draft EVPN Prefix Advertisement May 18, 2018 learned via ARP snooping. o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=IP2. The prefix and GW IP are learned by policy. (2) Similarly, NVE3 advertises the following BGP routes on behalf of TS3: o Route type 2 (MAC/IP route) containing: ML=48, M=M3, IPL=32, IP=IP3 (and BGP Encapsulation Extended Community). o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=IP3. (3) DGW1 and DGW2 import both received routes based on the Route Targets: o Based on the BD-10 Route Target in DGW1 and DGW2, the MAC/IP route is imported and M2 is added to the BD-10 along with its corresponding tunnel information. For instance, if VXLAN is used, the VTEP will be derived from the MAC/IP route BGP next- hop and VNI from the MPLS Label1 field. IP2 - M2 is added to the ARP table. Similarly, M3 is added to BD-10 and IP3 - M3 to the ARP table. o Based on the BD-10 Route Target in DGW1 and DGW2, the IP Prefix route is also imported and SN1/24 is added to the IP- VRF with Overlay Index IP2 pointing at the local BD-10. In this example, it is assumed that the RT-5 from NVE2 is preferred over the RT-5 from NVE3. If both routes were equally preferable and ECMP enabled, SN1/24 would also be added to the routing table with Overlay Index IP3. (4) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table and Overlay Index=IP2 is found. Since IP2 is an Overlay Index a recursive route resolution is required for IP2. o IP2 is resolved to M2 in the ARP table, and M2 is resolved to the tunnel information given by the BD FIB (e.g., remote VTEP and VNI for the VXLAN case). o The IP packet destined to IPx is encapsulated with: Rabadan et al. Expires November 19, 2018 [Page 17] Internet-Draft EVPN Prefix Advertisement May 18, 2018 . Source inner MAC = IRB1 MAC. . Destination inner MAC = M2. . Tunnel information provided by the BD (VNI, VTEP IPs and MACs for the VXLAN case). (5) When the packet arrives at NVE2: o Based on the tunnel information (VNI for the VXLAN case), the BD-10 context is identified for a MAC lookup. o Encapsulation is stripped off and based on a MAC lookup (assuming MAC forwarding on the egress NVE), the packet is forwarded to TS2, where it will be properly routed. (6) Should TS2 move from NVE2 to NVE3, MAC Mobility procedures will be applied to the MAC route IP2/M2, as defined in [RFC7432]. Route type 5 prefixes are not subject to MAC mobility procedures, hence no changes in the DGW IP-VRF routing table will occur for TS2 mobility, i.e., all the prefixes will still be pointing at IP2 as Overlay Index. There is an indirection for e.g., SN1/24, which still points at Overlay Index IP2 in the routing table, but IP2 will be simply resolved to a different tunnel, based on the outcome of the MAC mobility procedures for the MAC/IP route IP2/M2. Note that in the opposite direction, TS2 will send traffic based on its static-route next-hop information (IRB1 and/or IRB2), and regular EVPN procedures will be applied. 4.2 Floating IP Overlay Index Use-Case Sometimes Tenant Systems (TS) work in active/standby mode where an upstream floating IP - owned by the active TS - is used as the Overlay Index to get to some subnets behind. This redundancy mode, already introduced in Section 2.1 and 2.2, is illustrated in Figure 6. Rabadan et al. Expires November 19, 2018 [Page 18] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE2 DGW1 +-----------+ +---------+ +-------------+ +---TS2(VA)--| (BD-10) |-| |----| (BD-10) | | IP2/M2 +-----------+ | | | IRB1\ | | <-+ | | | (IP-VRF)|---+ | | | | +-------------+ _|_ SN1 vIP23 (floating) | VXLAN/ | ( ) | | | GENEVE | DGW2 ( WAN ) | <-+ NVE3 | | +-------------+ (___) | IP3/M3 +-----------+ | |----| (BD-10) | | +---TS3(VA)--| (BD-10) |-| | | IRB2\ | | +-----------+ +---------+ | (IP-VRF)|---+ +-------------+ Figure 6 Floating IP Overlay Index for redundant TS In this use-case, a GW IP is used as an Overlay Index for the same reasons as in 4.1. However, this GW IP is a floating IP that belongs to the active TS. Assuming TS2 is the active TS and owns vIP23: (1) NVE2 advertises the following BGP routes for TS2: o Route type 2 (MAC/IP route) containing: ML=48, M=M2, IPL=32, IP=vIP23 (and BGP Encapsulation Extended Community). The MAC and IP addresses may be learned via ARP snooping. o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=vIP23. The prefix and GW IP are learned by policy. (2) NVE3 advertises the following BGP route for TS3 (it does not advertise an RT-2 for vIP23/M3): o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=vIP23. The prefix and GW IP are learned by policy. (3) DGW1 and DGW2 import both received routes based on the Route Target: o M2 is added to the BD-10 FIB along with its corresponding tunnel information. For the VXLAN use case, the VTEP will be derived from the MAC/IP route BGP next-hop and VNI from the VNI field. vIP23 - M2 is added to the ARP table. o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with Overlay index vIP23 pointing at M2 in the local BD-10. Rabadan et al. Expires November 19, 2018 [Page 19] Internet-Draft EVPN Prefix Advertisement May 18, 2018 (4) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table and Overlay Index=vIP23 is found. Since vIP23 is an Overlay Index, a recursive route resolution for vIP23 is required. o vIP23 is resolved to M2 in the ARP table, and M2 is resolved to the tunnel information given by the BD (remote VTEP and VNI for the VXLAN case). o The IP packet destined to IPx is encapsulated with: . Source inner MAC = IRB1 MAC. . Destination inner MAC = M2. . Tunnel information provided by the BD FIB (VNI, VTEP IPs and MACs for the VXLAN case). (5) When the packet arrives at NVE2: o Based on the tunnel information (VNI for the VXLAN case), the BD-10 context is identified for a MAC lookup. o Encapsulation is stripped off and based on a MAC lookup (assuming MAC forwarding on the egress NVE), the packet is forwarded to TS2, where it will be properly routed. (6) When the redundancy protocol running between TS2 and TS3 appoints TS3 as the new active TS for SN1, TS3 will now own the floating vIP23 and will signal this new ownership, using a gratuitous ARP REPLY message (explained in [RFC5227]) or similar. Upon receiving the new owner's notification, NVE3 will issue a route type 2 for M3-vIP23 and NVE2 will withdraw the RT-2 for M2-vIP23. DGW1 and DGW2 will update their ARP tables with the new MAC resolving the floating IP. No changes are made in the IP-VRF routing table. 4.3 Bump-in-the-Wire Use-Case Figure 7 illustrates an example of inter-subnet forwarding for an IP Prefix route that carries a subnet SN1. In this use-case, TS2 and TS3 are layer 2 VA devices without any IP address that can be included as an Overlay Index in the GW IP field of the IP Prefix route. Their MAC addresses are M2 and M3 respectively and are connected to BD-10. Note that IRB1 and IRB2 (in DGW1 and DGW2 respectively) have IP addresses Rabadan et al. Expires November 19, 2018 [Page 20] Internet-Draft EVPN Prefix Advertisement May 18, 2018 in a subnet different than SN1. NVE2 DGW1 M2 +-----------+ +---------+ +-------------+ +---TS2(VA)--| (BD-10) |-| |----| (BD-10) | | ESI23 +-----------+ | | | IRB1\ | | + | | | (IP-VRF)|---+ | | | | +-------------+ _|_ SN1 | | VXLAN/ | ( ) | | | GENEVE | DGW2 ( WAN ) | + NVE3 | | +-------------+ (___) | ESI23 +-----------+ | |----| (BD-10) | | +---TS3(VA)--| (BD-10) |-| | | IRB2\ | | M3 +-----------+ +---------+ | (IP-VRF)|---+ +-------------+ Figure 7 Bump-in-the-wire use-case Since neither TS2 nor TS3 can participate in any dynamic routing protocol and have no IP address assigned, there are two potential Overlay Index types that can be used when advertising SN1: a) an ESI, i.e., ESI23, that can be provisioned on the attachment ports of NVE2 and NVE3, as shown in Figure 7. b) or the VA's MAC address, that can be added to NVE2 and NVE3 by policy. The advantage of using an ESI as Overlay Index as opposed to the VA's MAC address, is that the forwarding to the egress NVE can be done purely based on the state of the AC in the ES (notified by the Ethernet A-D per-EVI route) and all the EVPN multi-homing redundancy mechanisms can be reused. For instance, the [RFC7432] mass-withdrawal mechanism for fast failure detection and propagation can be used. This Section assumes that an ESI Overlay Index is used in this use- case but it does not prevent the use of the VA's MAC address as an Overlay Index. If a MAC is used as Overlay Index, the control plane must follow the procedures described in Section 4.4.3. The model supports VA redundancy in a similar way to the one described in Section 4.2 for the floating IP Overlay Index use-case, except that it uses the EVPN Ethernet A-D per-EVI route instead of the MAC advertisement route to advertise the location of the Overlay Index. The procedure is explained below: (1) Assuming TS2 is the active TS in ESI23, NVE2 advertises the following BGP routes: Rabadan et al. Expires November 19, 2018 [Page 21] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Route type 1 (Ethernet A-D route for BD-10) containing: ESI=ESI23 and the corresponding tunnel information (VNI field), as well as the BGP Encapsulation Extended Community as per [RFC8365]. o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=ESI23, GW IP address=0. The Router's MAC Extended Community defined in [EVPN-INTERSUBNET] is added and carries the MAC address (M2) associated to the TS behind which SN1 sits. M2 may be learned by policy, however the MAC in the Extended Community is preferred if sent with the route. (2) NVE3 advertises the following BGP route for TS3 (no AD per-EVI route is advertised): o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=23, GW IP address=0. The Router's MAC Extended Community is added and carries the MAC address (M3) associated to the TS behind which SN1 sits. M3 may be learned by policy, however the MAC in the Extended Community is preferred if sent with the route. (3) DGW1 and DGW2 import the received routes based on the Route Target: o The tunnel information to get to ESI23 is installed in DGW1 and DGW2. For the VXLAN use case, the VTEP will be derived from the Ethernet A-D route BGP next-hop and VNI from the VNI/VSID field (see [RFC8365]). o The RT-5 coming from the NVE that advertised the RT-1 is selected and SN1/24 is added to the IP-VRF in DGW1 and DGW2 with Overlay Index ESI23 and MAC = M2. (4) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table and Overlay Index=ESI23 is found. Since ESI23 is an Overlay Index, a recursive route resolution is required to find the egress NVE where ESI23 resides. o The IP packet destined to IPx is encapsulated with: . Source inner MAC = IRB1 MAC. . Destination inner MAC = M2 (this MAC will be obtained from the Router's MAC Extended Community received along Rabadan et al. Expires November 19, 2018 [Page 22] Internet-Draft EVPN Prefix Advertisement May 18, 2018 with the RT-5 for SN1). Note that the Router's MAC Extended Community is used in this case to carry the TS' MAC address, as opposed to the NVE/PE's MAC address. . Tunnel information for the NVO tunnel is provided by the Ethernet A-D route per-EVI for ESI23 (VNI and VTEP IP for the VXLAN case). (5) When the packet arrives at NVE2: o Based on the tunnel demultiplexer information (VNI for the VXLAN case), the BD-10 context is identified for a MAC lookup (assuming MAC-based disposition model [RFC7432]) or the VNI may directly identify the egress interface (for a MPLS-based disposition model, which in this context is a VNI-based disposition model). o Encapsulation is stripped off and based on a MAC lookup (assuming MAC forwarding on the egress NVE) or a VNI lookup (in case of VNI forwarding), the packet is forwarded to TS2, where it will be forwarded to SN1. (6) If the redundancy protocol running between TS2 and TS3 follows an active/standby model and there is a failure, appointing TS3 as the new active TS for SN1, TS3 will now own the connectivity to SN1 and will signal this new ownership. Upon receiving the new owner's notification, NVE3's AC will become active and issue a route type 1 for ESI23, whereas NVE2 will withdraw its Ethernet A-D route for ESI23. DGW1 and DGW2 will update their tunnel information to resolve ESI23. The destination inner MAC will be changed to M3. 4.4 IP-VRF-to-IP-VRF Model This use-case is similar to the scenario described in "IRB forwarding on NVEs for Tenant Systems" in [EVPN-INTERSUBNET], however the new requirement here is the advertisement of IP Prefixes as opposed to only host routes. In the examples described in Sections 4.1, 4.2 and 4.3, the BD instance can connect IRB interfaces and any other Tenant Systems connected to it. EVPN provides connectivity for: 1. Traffic destined to the IRB or TS IP interfaces as well as 2. Traffic destined to IP subnets sitting behind the TS, e.g., SN1 or SN2. Rabadan et al. Expires November 19, 2018 [Page 23] Internet-Draft EVPN Prefix Advertisement May 18, 2018 In order to provide connectivity for (1), MAC/IP routes (RT-2) are needed so that IRB or TS MACs and IPs can be distributed. Connectivity type (2) is accomplished by the exchange of IP Prefix routes (RT-5) for IPs and subnets sitting behind certain Overlay Indexes, e.g., GW IP or ESI or TS MAC. In some cases, IP Prefix routes may be advertised for subnets and IPs sitting behind an IRB. This use-case is referred to as the "IP-VRF- to-IP-VRF" model. [EVPN-INTERSUBNET] defines an asymmetric IRB model and a symmetric IRB model, based on the required lookups at the ingress and egress NVE: the asymmetric model requires an IP lookup and a MAC lookup at the ingress NVE, whereas only a MAC lookup is needed at the egress NVE; the symmetric model requires IP and MAC lookups at both, ingress and egress NVE. From that perspective, the IP-VRF-to-IP-VRF use-case described in this Section is a symmetric IRB model. Note that, in an IP-VRF-to-IP-VRF scenario, out of the many subnets that a tenant may have, it may be the case that only a few are attached to a given NVE/PE's IP-VRF. In order to provide inter-subnet connectivity among the set of NVE/PEs where the tenant is connected, a new SBD is created on all of them if recursive resolution is needed. This SBD is instantiated as a regular BD (with no ACs) in each NVE/PE and has an IRB interface that connects the SBD to the IP- VRF. The IRB interface's IP or MAC address is used as the overlay index for recursive resolution. Depending on the existence and characteristics of the SBD and IRB interfaces for the IP-VRFs, there are three different IP-VRF-to-IP- VRF scenarios identified and described in this document: 1) Interface-less model: no SBD and no overlay indexes required. 2) Interface-ful with SBD IRB model: it requires SBD, as well as GW IP addresses as overlay indexes. 3) Interface-ful with unnumbered SBD IRB model: it requires SBD, as well as MAC addresses as overlay indexes. Inter-subnet IP multicast is outside the scope of this document. 4.4.1 Interface-less IP-VRF-to-IP-VRF Model Figure 8 will be used for the description of this model. Rabadan et al. Expires November 19, 2018 [Page 24] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1(M1) +------------+ IP1+----| (BD-1) | DGW1(M3) | \ | +---------+ +--------+ | (IP-VRF)|----| |-|(IP-VRF)|----+ | / | | | +--------+ | +---| (BD-2) | | | _+_ | +------------+ | | ( ) SN1| | VXLAN/ | ( WAN )--H1 | NVE2(M2) | GENEVE/| (___) | +------------+ | MPLS | + +---| (BD-2) | | | DGW2(M4) | | \ | | | +--------+ | | (IP-VRF)|----| |-|(IP-VRF)|----+ | / | +---------+ +--------+ SN2+----| (BD-3) | +------------+ Figure 8 Interface-less IP-VRF-to-IP-VRF model In this case: a) The NVEs and DGWs must provide connectivity between hosts in SN1, SN2, IP1 and hosts sitting at the other end of the WAN, for example, H1. It is assumed that the DGWs import/export IP and/or VPN-IP routes from/to the WAN. b) The IP-VRF instances in the NVE/DGWs are directly connected through NVO tunnels, and no IRBs and/or BD instances are instantiated to connect the IP-VRFs. c) The solution must provide layer 3 connectivity among the IP-VRFs for Ethernet NVO tunnels, for instance, VXLAN or GENEVE. d) The solution may provide layer 3 connectivity among the IP-VRFs for IP NVO tunnels, for example, GENEVE (with IP payload). In order to meet the above requirements, the EVPN route type 5 will be used to advertise the IP Prefixes, along with the Router's MAC Extended Community as defined in [EVPN-INTERSUBNET] if the advertising NVE/DGW uses Ethernet NVO tunnels. Each NVE/DGW will advertise an RT-5 for each of its prefixes with the following fields: o RD as per [RFC7432]. Rabadan et al. Expires November 19, 2018 [Page 25] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Ethernet Tag ID=0. o IP Prefix Length and IP address, as explained in the previous Sections. o GW IP address=0. o ESI=0 o MPLS label or VNI corresponding to the IP-VRF. Each RT-5 will be sent with a Route Target identifying the tenant (IP-VRF) and may be sent with two BGP extended communities: o The first one is the BGP Encapsulation Extended Community, as per [RFC5512], identifying the tunnel type. o The second one is the Router's MAC Extended Community as per [EVPN-INTERSUBNET] containing the MAC address associated to the NVE advertising the route. This MAC address identifies the NVE/DGW and MAY be reused for all the IP-VRFs in the NVE. The Router's MAC Extended Community must be sent if the route is associated to an Ethernet NVO tunnel, for instance, VXLAN. If the route is associated to an IP NVO tunnel, for instance GENEVE with IP payload, the Router's MAC Extended Community should not be sent. The following example illustrates the procedure to advertise and forward packets to SN1/24 (IPv4 prefix advertised from NVE1): (1) NVE1 advertises the following BGP route: o Route type 5 (IP Prefix route) containing: . IPL=24, IP=SN1, Label=10. . GW IP= set to 0. . [RFC5512] BGP Encapsulation Extended Community. . Router's MAC Extended Community that contains M1. . Route Target identifying the tenant (IP-VRF). (2) DGW1 imports the received routes from NVE1: o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 Route Target. Rabadan et al. Expires November 19, 2018 [Page 26] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Since GW IP=ESI=0, the Label is a non-zero value and the local policy indicates this interface-less model, DGW1 will use the Label and next-hop of the RT-5, as well as the MAC address conveyed in the Router's MAC Extended Community (as inner destination MAC address) to set up the forwarding state and later encapsulate the routed IP packets. (3) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table. The lookup yields SN1/24. o Since the RT-5 for SN1/24 had a GW IP=ESI=0, a non-zero Label and next-hop and the model is interface-less, DGW1 will not need a recursive lookup to resolve the route. o The IP packet destined to IPx is encapsulated with: Source inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer IP (tunnel source IP) = DGW1 IP, Destination outer IP (tunnel destination IP) = NVE1 IP. The Source and Destination inner MAC addresses are not needed if IP NVO tunnels are used. (4) When the packet arrives at NVE1: o NVE1 will identify the IP-VRF for an IP lookup based on the Label (the Destination inner MAC is not needed to identify the IP-VRF). o An IP lookup is performed in the routing context, where SN1 turns out to be a local subnet associated to BD-2. A subsequent lookup in the ARP table and the BD FIB will provide the forwarding information for the packet in BD-2. The model described above is called Interface-less model since the IP-VRFs are connected directly through tunnels and they don't require those tunnels to be terminated in SBDs instead, as in Sections 4.4.2 or 4.4.3. 4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD IRB Figure 9 will be used for the description of this model. Rabadan et al. Expires November 19, 2018 [Page 27] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1 +------------+ DGW1 IP10+---+(BD-1) | +---------------+ +------------+ | \ | | | | | |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ | / IRB(IP1/M1) IRB(IP3/M3) | | +---+(BD-2) | | | +------------+ _+_ | +------------+ | | ( ) SN1| | VXLAN/ | ( WAN )--H1 | NVE2 | GENEVE/ | (___) | +------------+ | MPLS | DGW2 + +---+(BD-2) | | | +------------+ | | \ | | | | | | |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ | / IRB(IP2/M2) IRB(IP4/M4) | SN2+----+(BD-3) | +---------------+ +------------+ +------------+ Figure 9 Interface-ful with SBD IRB model In this model: a) As in Section 4.4.1, the NVEs and DGWs must provide connectivity between hosts in SN1, SN2, IP10 and hosts sitting at the other end of the WAN. b) However, the NVE/DGWs are now connected through Ethernet NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB interfaces for their connectivity to the SBD. c) Each SBD IRB has an IP and a MAC address, where the IP address must be reachable from other NVEs or DGWs. d) The SBD is attached to all the NVE/DGWs in the tenant domain BDs. e) The solution must provide layer 3 connectivity for Ethernet NVO tunnels, for instance, VXLAN or GENEVE (with Ethernet payload). EVPN type 5 routes will be used to advertise the IP Prefixes, whereas EVPN RT-2 routes will advertise the MAC/IP addresses of each SBD IRB interface. Each NVE/DGW will advertise an RT-5 for each of its prefixes with the following fields: o RD as per [RFC7432]. o Ethernet Tag ID=0. Rabadan et al. Expires November 19, 2018 [Page 28] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o IP Prefix Length and IP address, as explained in the previous Sections. o GW IP address=IRB-IP of the SBD (this is the Overlay Index that will be used for the recursive route resolution). o ESI=0 o Label value should be zero since the RT-5 route requires a recursive lookup resolution to an RT-2 route. It is ignored on reception, and, when forwarding packets, the MPLS label or VNI from the RT-2's MPLS Label1 field is used. Each RT-5 will be sent with a Route Target identifying the tenant (IP-VRF). The Router's MAC Extended Community should not be sent in this case. The following example illustrates the procedure to advertise and forward packets to SN1/24 (IPv4 prefix advertised from NVE1): (1) NVE1 advertises the following BGP routes: o Route type 5 (IP Prefix route) containing: . IPL=24, IP=SN1, Label= SHOULD be set to 0. . GW IP=IP1 (SBD IRB's IP) . Route Target identifying the tenant (IP-VRF). o Route type 2 (MAC/IP route for the SBD IRB) containing: . ML=48, M=M1, IPL=32, IP=IP1, Label=10. . A [RFC5512] BGP Encapsulation Extended Community. . Route Target identifying the SBD. This Route Target may be the same as the one used with the RT-5. (2) DGW1 imports the received routes from NVE1: o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 Route Target. . Since GW IP is different from zero, the GW IP (IP1) will be used as the Overlay Index for the recursive route resolution to the RT-2 carrying IP1. Rabadan et al. Expires November 19, 2018 [Page 29] Internet-Draft EVPN Prefix Advertisement May 18, 2018 (3) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table. The lookup yields SN1/24, which is associated to the Overlay Index IP1. The forwarding information is derived from the RT-2 received for IP1. o The IP packet destined to IPx is encapsulated with: Source inner MAC = M3, Destination inner MAC = M1, Source outer IP (source VTEP) = DGW1 IP, Destination outer IP (destination VTEP) = IP1. (4) When the packet arrives at NVE1: o NVE1 will identify the IP-VRF for an IP lookup based on the Label and the inner MAC DA. o An IP lookup is performed in the routing context, where SN1 turns out to be a local subnet associated to BD-2. A subsequent lookup in the ARP table and the BD FIB will provide the forwarding information for the packet in BD-2. The model described above is called 'Interface-ful with SBD IRB model' because the tunnels connecting the DGWs and NVEs need to be terminated into the SBD. The SBD is connected to the IP-VRFs via SBD IRB interfaces, and that allows the recursive resolution of RT-5s to GW IP addresses. 4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB Figure 10 will be used for the description of this model. Note that this model is similar to the one described in Section 4.4.2, only without IP addresses on the SBD IRB interfaces. Rabadan et al. Expires November 19, 2018 [Page 30] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1 +------------+ DGW1 IP1+----+(BD-1) | +---------------+ +------------+ | \ | | | | | |(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+ | / IRB(M1)| | IRB(M3) | | +---+(BD-2) | | | +------------+ _+_ | +------------+ | | ( ) SN1| | VXLAN/ | ( WAN )--H1 | NVE2 | GENEVE/ | (___) | +------------+ | MPLS | DGW2 + +---+(BD-2) | | | +------------+ | | \ | | | | | | |(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+ | / IRB(M2)| | IRB(M4) | SN2+----+(BD-3) | +---------------+ +------------+ +------------+ Figure 10 Interface-ful with unnumbered SBD IRB model In this model: a) As in Section 4.4.1 and 4.4.2, the NVEs and DGWs must provide connectivity between hosts in SN1, SN2, IP1 and hosts sitting at the other end of the WAN. b) As in Section 4.4.2, the NVE/DGWs are connected through Ethernet NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB interfaces for their connectivity to the SBD. c) However, each SBD IRB has a MAC address only, and no IP address (that is why the model refers to an 'unnumbered' SBD IRB). In this model, there is no need to have IP reachability to the SBD IRB interfaces themselves and there is a requirement to limit the number of IP addresses used. d) As in Section 4.4.2, the SBD is composed of all the NVE/DGW BDs of the tenant that need inter-subnet-forwarding. e) As in Section 4.4.2, the solution must provide layer 3 connectivity for Ethernet NVO tunnels, for instance, VXLAN or GENEVE (with Ethernet payload). This model will also make use of the RT-5 recursive resolution. EVPN type 5 routes will advertise the IP Prefixes along with the Router's MAC Extended Community used for the recursive lookup, whereas EVPN RT-2 routes will advertise the MAC addresses of each SBD IRB Rabadan et al. Expires November 19, 2018 [Page 31] Internet-Draft EVPN Prefix Advertisement May 18, 2018 interface (this time without an IP). Each NVE/DGW will advertise an RT-5 for each of its prefixes with the same fields as described in 4.4.2 except for: o GW IP address= set to 0. Each RT-5 will be sent with a Route Target identifying the tenant (IP-VRF) and the Router's MAC Extended Community containing the MAC address associated to SBD IRB interface. This MAC address may be reused for all the IP-VRFs in the NVE. The example is similar to the one in Section 4.4.2: (1) NVE1 advertises the following BGP routes: o Route type 5 (IP Prefix route) containing the same values as in the example in Section 4.4.2, except for: . GW IP= SHOULD be set to 0. . Router's MAC Extended Community containing M1 (this will be used for the recursive lookup to a RT-2). o Route type 2 (MAC route for the SBD IRB) with the same values as in Section 4.4.2 except for: . ML=48, M=M1, IPL=0, Label=10. (2) DGW1 imports the received routes from NVE1: o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 Route Target. . The MAC contained in the Router's MAC Extended Community sent along with the RT-5 (M1) will be used as the Overlay Index for the recursive route resolution to the RT-2 carrying M1. (3) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table. The lookup yields SN1/24, which is associated to the Overlay Index M1. The forwarding information is derived from the RT-2 received for M1. o The IP packet destined to IPx is encapsulated with: Source Rabadan et al. Expires November 19, 2018 [Page 32] Internet-Draft EVPN Prefix Advertisement May 18, 2018 inner MAC = M3, Destination inner MAC = M1, Source outer IP (source VTEP) = DGW1 IP, Destination outer IP (destination VTEP) = NVE1 IP. (4) When the packet arrives at NVE1: o NVE1 will identify the IP-VRF for an IP lookup based on the Label and the inner MAC DA. o An IP lookup is performed in the routing context, where SN1 turns out to be a local subnet associated to BD-2. A subsequent lookup in the ARP table and the BD FIB will provide the forwarding information for the packet in BD-2. The model described above is called Interface-ful with unnumbered SBD IRB model (as in Section 4.4.2), only this time the SBD IRB does not have an IP address. 5. Security Considerations This document provides a set of procedures to achieve Inter-Subnet Forwarding across NVEs or PEs attached to a group of BDs that belong to the same tenant (or VPN). The security considerations discussed in [RFC7432] apply to the Intra-Subnet Forwarding or communication within each of those BDs. In addition, the security considerations in [RFC4364] should also be understood, since this document and [RFC4364] may be used in similar applications. Contrary to [RFC4364], this document does not describe PE/CE route distribution techniques, but rather considers the CEs as TSes or VAs that do not run dynamic routing protocols. This can be considered a security advantage, since dynamic routing protocols can be blocked on the NVE/PE ACs, not allowing the tenant to interact with the infrastructure's dynamic routing protocols. In this document, the RT-5 may use a regular BGP Next Hop for its resolution or an Overlay Index that requires a recursive resolution to a different EVPN route (an RT-2 or an RT-1). In the latter case, it is worth noting that any action that ends up filtering or modifying the RT-2/RT-1 routes used to convey the Overlay Indexes, will modify the resolution of the RT-5 and therefore the forwarding of packets to the remote subnet. 6. IANA Considerations This document requests value 5 in the [EVPNRouteTypes] registry Rabadan et al. Expires November 19, 2018 [Page 33] Internet-Draft EVPN Prefix Advertisement May 18, 2018 defined by [RFC7432]: Value Description Reference 5 IP Prefix route [this document] 7. References 7.1 Normative References [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8365] Sajassi-Drake et al., "A Network Virtualization Overlay Solution using EVPN", RFC 8365, DOI 10.17487/RFC8365, March, 2018. [EVPN-INTERSUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt, work in progress, February, 2017 [EVPNRouteTypes] IANA EVPN Route Type registry, https://www.iana.org/assignments/evpn 7.2 Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC7606] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, August Rabadan et al. Expires November 19, 2018 [Page 34] Internet-Draft EVPN Prefix Advertisement May 18, 2018 2015, . [802.1D-REV] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges", IEEE Std. 802.1D, June 2004. [802.1Q] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q(tm), 2014 Edition, November 2014. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, . [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, DOI 10.17487/RFC5227, July 2008, . [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, . [GENEVE] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-06, March 2018. 8. Acknowledgments The authors would like to thank Mukul Katiyar and Jeffrey Zhang for their valuable feedback and contributions. The following people also helped improving this document with their feedback: Tony Przygienda and Thomas Morin. Special THANK YOU to Eric Rosen for his detailed review, it really helped improve the readability and clarify the concepts. Thank you to Alvaro Retana for his thorough review. 9. Contributors In addition to the authors listed on the front page, the following co-authors have also contributed to this document: Senthil Sathappan Florin Balus Aldrin Isaac Senad Palislamovic Rabadan et al. Expires November 19, 2018 [Page 35] Internet-Draft EVPN Prefix Advertisement May 18, 2018 Samir Thoria 10. Authors' Addresses Jorge Rabadan (Editor) Nokia 777 E. Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com Wim Henderickx Nokia Email: wim.henderickx@nokia.com John E. Drake Juniper Email: jdrake@juniper.net Ali Sajassi Cisco Email: sajassi@cisco.com Wen Lin Juniper Email: wlin@juniper.net Rabadan et al. Expires November 19, 2018 [Page 36] ./draft-ietf-httpbis-rand-access-live-04.txt0000644000764400076440000005760313437766153020201 0ustar iustyiusty HTTP C. Pratt Internet-Draft Intended status: Experimental D. Thakore Expires: September 7, 2019 CableLabs B. Stark AT&T March 6, 2019 HTTP Random Access and Live Content draft-ietf-httpbis-rand-access-live-04 Abstract To accommodate byte range requests for content that has data appended over time, this document defines semantics that allow a HTTP client and server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and ends at an indeterminate offset. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at . 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 7, 2019. Pratt, et al. Expires September 7, 2019 [Page 1] Internet-Draft HTTP Random Access and Live Content March 2019 Copyright Notice Copyright (c) 2019 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. Performing Range requests on Random-Access Aggregating ("live") Content . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Establishing the Randomly Accessible Byte Range . . . . . 4 2.2. Byte-Range Requests Beyond the Randomly Accessible Byte Range . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Other Applications of Random-Access Aggregating Content . . . 7 3.1. Requests Starting at the Aggregation ("Live") Point . . . 7 3.2. Shift Buffer Representations . . . . . . . . . . . . . . 8 4. Recommendations for Very Large Values . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Some Hypertext Transfer Protocol (HTTP) clients use byte-range requests (Range requests using the "bytes" Range Unit) to transfer select portions of large representations ([RFC7233]). And in some cases large representations require content to be continuously or periodically appended - such as representations consisting of live audio or video sources, blockchain databases, and log files. Clients cannot access the appended/live content using a Range request with the bytes range unit using the currently defined byte-range semantics Pratt, et al. Expires September 7, 2019 [Page 2] Internet-Draft HTTP Random Access and Live Content March 2019 without accepting performance or behavior sacrifices which are not acceptable for many applications. For instance, HTTP clients have the ability to access appended content on an indeterminate-length resource by transferring the entire representation from the beginning and continuing to read the appended content as it's made available. Obviously, this is highly inefficient for cases where the representation is large and only the most recently appended content is needed by the client. Alternatively, clients can also access appended content by sending periodic open-ended bytes Range requests using the last-known end byte position as the range start. Performing low-frequency periodic bytes Range requests in this fashion (polling) introduces latency since the client will necessarily be somewhat behind the aggregated content - mimicking the behavior (and latency) of segmented content representations such as "HTTP Live Streaming" (HLS, [RFC8216]) or "Dynamic Adaptive Streaming over HTTP" (MPEG-DASH, [DASH]). And while performing these Range requests at higher frequency can reduce this latency, it also incurs more processing overhead and HTTP exchanges as many of the requests will return no content - since content is usually aggregated in groups of bytes (e.g. a video frame, audio sample, block, or log entry). This document describes a usage model for range requests which enables efficient retrieval of representations that are appended to over time by using large values and associated semantics for communicating range end positions. This model allows representations to be progressively delivered by servers as new content is added. It also ensures compatibility with servers and intermediaries that don't support this technique. 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]. 1.2. Notational Conventions This document cites productions in Augmented Backus-Naur Form (ABNF) productions from [RFC7233], using the notation defined in [RFC5234]. Pratt, et al. Expires September 7, 2019 [Page 3] Internet-Draft HTTP Random Access and Live Content March 2019 2. Performing Range requests on Random-Access Aggregating ("live") Content This document recommends a two-step process for accessing resources that have indeterminate length representations. Two steps are necessary because of limitations with the Range request header fields and the Content-Range response header fields. A server cannot know from a range request that a client wishes to receive a response that does not have a definite end. More critically, the header fields do not allow the server to signal that a resource has indeterminate length without also providing a fixed portion of the resource. A client first learns that the resource has a representation of indeterminate length by requesting a range of the resource. The server responds with the range that is available, but indicates that the length of the representation is unknown using the existing Content-Range syntax. See Section 2.1 for details and examples. Once the client knows the resource has indeterminate length, it can request a range with a very large end position from the resource. The client chooses an explicit end value larger than can be transferred in the foreseeable term. A server which supports range requests of indeterminate length signals its understanding of the client's indeterminate range request by indicating that the range it is providing has a range end that exactly matches the client's requested range end rather than a range that is bounded by what is currently available. See Section 2.2 for details. 2.1. Establishing the Randomly Accessible Byte Range Establishing if a representation is continuously aggregating ("live") and determining the randomly-accessible byte range can both be determined using the existing definition for an open-ended byte-range request. Specifically, [RFC7233] defines a byte-range request of the form: byte-range-spec = first-byte-pos "-" [ last-byte-pos ] which allows a client to send a HEAD request with a first-byte-pos and leave last-byte-pos absent. A server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) may respond with a 206 status code (Partial Content) with a Content-Range header field indicating the currently satisfiable byte range. For example: Pratt, et al. Expires September 7, 2019 [Page 4] Internet-Draft HTTP Random Access and Live Content March 2019 HEAD /resource HTTP/1.1 Host: example.com Range: bytes=0- returns a response of the form: HTTP/1.1 206 Partial Content Content-Range: bytes 0-1234567/* from the server indicating that (1) the complete representation length is unknown (via the "*" in place of the complete-length field) and (2) that only bytes 0-1234567 were accessible at the time the request was processed by the server. The client can infer from this response that bytes 0-1234567 of the representation can be requested and returned in a timely fashion (the bytes are immediately available). 2.2. Byte-Range Requests Beyond the Randomly Accessible Byte Range Once a client has determined that a representation has an indeterminate length and established the byte range that can be accessed, it may want to perform a request with a start position within the randomly-accessible content range and an end position at an indefinite "live" point - a point where the byte-range GET request is fulfilled on-demand as the content is aggregated. For example, for a large video asset, a client may wish to start a content transfer from the video "key" frame immediately before the point of aggregation and continue the content transfer indefinitely as content is aggregated - in order to support low-latency startup of a live video stream. Unlike a byte-range Range request, a byte-range Content-Range response header field cannot be "open ended", per [RFC7233]: byte-content-range = bytes-unit SP ( byte-range-resp / unsatisfied-range ) byte-range-resp = byte-range "/" ( complete-length / "*" ) byte-range = first-byte-pos "-" last-byte-pos unsatisfied-range = "*/" complete-length complete-length = 1*DIGIT Specifically, last-byte-pos is required in byte-range. So in order to preserve interoperability with existing HTTP clients, servers, proxies, and caches, this document proposes a mechanism for a client Pratt, et al. Expires September 7, 2019 [Page 5] Internet-Draft HTTP Random Access and Live Content March 2019 to indicate support for handling an indeterminate-length byte-range response, and a mechanism for a server to indicate if/when it's providing an indeterminate-length response. A client can indicate support for handling indeterminate-length byte- range responses by providing a very large value for the last-byte-pos in the byte-range request. For example, a client can perform a byte- range GET request of the form: GET /resource HTTP/1.1 Host: example.com Range: bytes=1230000-999999999999 where the last-byte-pos in the Request is much larger than the last- byte-pos returned in response to an open-ended byte-range HEAD request, as described above, and much larger than the expected maximum size of the representation. See Section 6 for range value considerations. In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client request's last-byte-pos in the Content-Range response header field. For example: GET /resource HTTP/1.1 Host: example.com Range: bytes=1230000-999999999999 returns HTTP/1.1 206 Partial Content Content-Range: bytes 1230000-999999999999/* from the server to indicate that the response will start at byte 1230000 and continues indefinitely to include all aggregated content, as it becomes available. A server that doesn't support or supply a continuously aggregating ("live") response will supply the currently satisfiable byte range, as it would with an open-ended byte request. For example: Pratt, et al. Expires September 7, 2019 [Page 6] Internet-Draft HTTP Random Access and Live Content March 2019 GET /resource HTTP/1.1 Host: example.com Range: bytes=1230000-999999999999 will return HTTP/1.1 206 Partial Content Content-Range: bytes 1230000-1234567/* from the server to indicate that the response will start at byte 1230000 and end at byte 1234567 and will not include any aggregated content. This is the response expected from a typical HTTP server - one that doesn't support byte-range requests on aggregating content. A client that doesn't receive a response indicating it is continuously aggregating must use other means to access aggregated content (e.g. periodic byte-range polling). A server that does return a continuously aggregating ("live") response should return data using chunked transfer coding and not provide a Content-Length header field. A 0-length chunk indicates the end of the transfer, per [RFC7230]. 3. Other Applications of Random-Access Aggregating Content 3.1. Requests Starting at the Aggregation ("Live") Point A client that wishes to only receive newly-aggregated portions of a resource (i.e., start at the "live" point), can use a HEAD request to learn what range the server has currently available and initiate an indeterminate-length transfer. For example: HEAD /resource HTTP/1.1 Host: example.com Range: bytes=0- With the Content-Range response header field indicating the range (or ranges) available. For example: 206 Partial Content Content-Range: bytes 0-1234567/* The client can then issue a request for a range starting at the end value (using a very large value for the end of a range) and receive only new content. Pratt, et al. Expires September 7, 2019 [Page 7] Internet-Draft HTTP Random Access and Live Content March 2019 GET /resource HTTP/1.1 Host: example.com Range: bytes=1234567-999999999999 with a server returning a Content-Range response indicating that an indeterminate-length response body will be provided 206 Partial Content Content-Range: bytes 1234567-999999999999/* 3.2. Shift Buffer Representations Some representations lend themselves to front-end content removal in addition to aggregation. While still supporting random access, representations of this type have a portion at the beginning (the "0" end) of the randomly-accessible region that become inaccessible over time. Examples of this kind of representation would be an audio- video time-shift buffer or a rolling log file. For example a Range request containing: HEAD /resource HTTP/1.1 Host: example.com Range: bytes=0- returns 206 Partial Content Content-Range: bytes 1000000-1234567/* indicating that the first 1000000 bytes were not accessible at the time the HEAD request was processed. Subsequent HEAD requests could return: Content-Range: bytes 1000000-1234567/* Content-Range: bytes 1010000-1244567/* Content-Range: bytes 1020000-1254567/* Note though that the difference between the first-byte-pos and last- byte-pos need not be constant. The client could then follow-up with a GET Range request containing Pratt, et al. Expires September 7, 2019 [Page 8] Internet-Draft HTTP Random Access and Live Content March 2019 GET /resource HTTP/1.1 Host: example.com Range: bytes=1020000-999999999999 with the server returning 206 Partial Content Content-Range: bytes 1020000-999999999999/* with the response body returning bytes 1020000-1254567 immediately and aggregated ("live") data being returned as the content is aggregated. A server that doesn't support or supply a continuously aggregating ("live") response will supply the currently satisfiable byte range, as it would with an open-ended byte request. For example: GET /resource HTTP/1.1 Host: example.com Range: bytes=0-999999999999 will return HTTP/1.1 206 Partial Content Content-Range: bytes 1020000-1254567/* from the server to indicate that the response will start at byte 1020000, end at byte 1254567, and will not include any aggregated content. This is the response expected from a typical HTTP server - one that doesn't support byte-range requests on aggregating content. Note that responses to GET requests against shift-buffer representations using Range can be cached by intermediaries, since the Content-Range response header indicates which portion of the representation is being returned in the response body. However GET requests without a Range header cannot be cached since the first byte of the response body can vary from request to request. To ensure Range-less GET requests against shift-buffer representations are not cached, servers hosting a shift-buffer representation should either not return a 200-level response (e.g. sending a 300-level redirect response with a URI that represents the current start of the shift- buffer) or indicate the response is non-cacheable. See HTTP Caching ([RFC7234]) for details on HTTP cache control. Pratt, et al. Expires September 7, 2019 [Page 9] Internet-Draft HTTP Random Access and Live Content March 2019 4. Recommendations for Very Large Values While it would be ideal to define a single numerical Very Large Value, there's no single value that would work for all applications and platforms. e.g. JavaScript numbers cannot represent all integer values above 2^^53, so a JavaScript application may want to use 2^^53-1 for a Very Large Value. This value, however, would not be sufficient for all applications, such as continuously-streaming high- bitrate streams. So the value 2^^53-1 (9007199254740991) is recommended as a Very Large Value unless an application has a good justification to use a smaller or larger value. e.g. If it's always known that the resource won't exceed a value smaller than the recommended Very Large Value for an application, a smaller value can be used. And if it's likely that an application will utilize resources larger than the recommended Very Large Value - such as a continuously aggregating high-bitrate media stream - a larger value should be used. Note that, in accordance with the semantics defined above, servers that support random-access live content will need to return the last- byte-pos provided in the Range request in some cases - even if the last-byte-pos cannot be represented as a numerical value internally by the server. As is the case with any live/continuously aggregating resource, the server should terminate the content transfer when the end of the resource is reached - whether the end is due to termination of the content source or the content length exceeds the server's maximum representation length. 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations As described above, servers need to be prepared to receive last-byte- pos values in Range requests that are numerically larger than the server implementation supports - and return these values in Content- Range response header fields. Servers should check the last-byte-pos value before converting and storing them into numeric form to ensure the value doesn't cause an overflow or index incorrect data. The simplest way to satisfy the live-range semantics defined in this document without potential overflow issues is to store the last-byte- pos as a string value and return it in the byte-range Content-Range response header's last-byte-pos field. Pratt, et al. Expires September 7, 2019 [Page 10] Internet-Draft HTTP Random Access and Live Content March 2019 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, . [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, . [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, . [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, . 7.2. Informative References [DASH] ISO, "Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2014, May 2014, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", RFC 8216, DOI 10.17487/RFC8216, August 2017, . Appendix A. Acknowledgements Mark Nottingham, Patrick McManus, Julian Reschke, Remy Lebeau, Rodger Combs, Thorsten Lohmar, Martin Thompson, Adrien de Croy, K. Morgan, Roy T. Fielding, Jeremy Poulter. Pratt, et al. Expires September 7, 2019 [Page 11] Internet-Draft HTTP Random Access and Live Content March 2019 Authors' Addresses Craig Pratt Portland, OR 97229 US Email: pratt@acm.org Darshak Thakore CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Email: d.thakore@cablelabs.com Barbara Stark AT&T Atlanta, GA US Email: barbara.stark@att.com Pratt, et al. Expires September 7, 2019 [Page 12] ./draft-ietf-bfcpbis-bfcp-websocket-15.txt0000644000764400076440000007345113046757044017706 0ustar iustyiusty BFCPBIS Working Group V. Pascual Internet-Draft Oracle Intended status: Standards Track A. Roman Expires: August 12, 2017 Quobis S. Cazeaux France Telecom Orange G. Salgueiro R. Ravindranath Cisco February 8, 2017 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) draft-ietf-bfcpbis-bfcp-websocket-15 Abstract The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new 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 August 12, 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 Pascual, et al. Expires August 12, 2017 [Page 1] Internet-Draft WebSocket as a Transport for BFCP February 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 3 4. The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . . 4 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. BFCP Encoding . . . . . . . . . . . . . . . . . . . . . . 5 5. Transport Reliability . . . . . . . . . . . . . . . . . . . . 5 6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. Transport Negotiation . . . . . . . . . . . . . . . . . . 6 6.2. SDP Media Attributes . . . . . . . . . . . . . . . . . . 6 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Example Usage of 'websocket-uri' SDP Attribute . . . . . 7 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 10 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' Values . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The WebSocket(WS) [RFC6455] protocol enables two-way message exchange between clients and servers on top of a persistent TCP connection, optionally secured with Transport Layer Security (TLS) [RFC5246]. The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure. The Binary Floor Control Protocol (BFCP) is a protocol to coordinate access to shared resources in a conference. It is defined in [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants Pascual, et al. Expires August 12, 2017 [Page 2] Internet-Draft WebSocket as a Transport for BFCP February 2017 and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. This document extends the applicability of [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis] to enable the usage of BFCP in these scenarios. The transport over which BFCP entities exchange messages depends on how the clients obtain information to contact the floor control server (e.g. using an Session Description Protocol (SDP) offer/answer exchange per [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described in RFC5018 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two transports for BFCP: TCP and UDP. This specification defines a new WebSocket sub-protocol (as defined in Section 1.9 in [RFC6455]) for transporting BFCP messages between a WebSocket client and server. This sub-protocol provides a reliable and boundary preserving transport for BFCP when run on top of TCP. Since WebSocket provides a reliable transport, the extensions defined in [I-D.ietf-bfcpbis-rfc4582bis] for sending BFCP over unreliable transports are not applicable. 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]. 2.1. Definitions BFCP WebSocket Client: Any BFCP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket BFCP sub-protocol as defined by this document. BFCP WebSocket Server: Any BFCP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket BFCP sub-protocol as defined by this document. 3. The WebSocket Protocol The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC5246]) in which both client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket sub-protocol and extensions Pascual, et al. Expires August 12, 2017 [Page 3] Internet-Draft WebSocket as a Transport for BFCP February 2017 negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes. The WebSocket connection handshake is based on HTTP [RFC7230] and utilizes the HTTP GET method with an "Upgrade" request. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, client and server agree on the application protocol to use on top of the WebSocket transport. Such an application protocol (also known as a "WebSocket sub-protocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as the WebSocket BFCP sub-protocol defined in this document). Once the HTTP 101 response is processed both client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges. The WebSocket protocol defines message units to be used by applications for the exchange of data, so it provides a message boundary-preserving transport layer. 4. The WebSocket BFCP Sub-Protocol The term WebSocket sub-protocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket BFCP sub-protocol for carrying BFCP messages over a WebSocket connection. 4.1. Handshake The BFCP WebSocket Client and BFCP WebSocket Server negotiate usage of the WebSocket BFCP sub-protocol during the WebSocket handshake procedure as defined in Section 1.3 of [RFC6455]. The Client MUST include the value "BFCP" in the Sec-WebSocket-Protocol header in its handshake request. The 101 reply from the Server MUST contain "BFCP" in its corresponding Sec-WebSocket-Protocol header. Below is an example of a WebSocket handshake in which the Client requests the WebSocket BFCP sub-protocol support from the Server: Pascual, et al. Expires August 12, 2017 [Page 4] Internet-Draft WebSocket as a Transport for BFCP February 2017 GET / HTTP/1.1 Host: bfcp-ws.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://www.example.com Sec-WebSocket-Protocol: BFCP Sec-WebSocket-Version: 13 The handshake response from the Server accepting the WebSocket BFCP sub-protocol would look as follows: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: BFCP Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of BFCP messages. 4.2. BFCP Encoding BFCP messages use a TLV (Type-Length-Value) binary encoding, therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be transported in unfragmented binary WebSocket frames (FIN:1,opcode:%x2) to exchange BFCP messages. The WebSocket frame data MUST be a valid BCFP message, so the length of the payload of the WebSocket frame MUST be lower than the maximum size allowed (2^16 +12 bytes) for a BCFP message as described in [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be followed. While this specification assumes that BFCP encoding is only TLV binary, future documents may define other mechanisms like JSON serialization. if encoding changes a new subprotocol identifier would need to be selected. Each BFCP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one BFCP message. 5. Transport Reliability WebSocket [RFC6455] provides a reliable transport and therefore the BFCP WebSocket sub-protocol defined by this document also provides reliable BFCP transport. Thus, client and server transactions using WebSocket for transport MUST follow the procedures for reliable Pascual, et al. Expires August 12, 2017 [Page 5] Internet-Draft WebSocket as a Transport for BFCP February 2017 transports as defined in [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis]. BFCP WebSocket clients cannot receive incoming WebSocket connections initiated by any other peer. This means that a BFCP WebSocket client MUST actively initiate a connection towards a BFCP WebSocket server. The BFCP server is a will have a globally routable address and thus does not require ICE as clients always initiate connections to it. 6. SDP Considerations 6.1. Transport Negotiation Rules to generate an 'm' line for a BFCP stream are described in [I-D.ietf-bfcpbis-rfc4583bis], Section 3 New values are defined for the transport field: TCP/WS/BFCP and TCP/WSS/BFCP. TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn runs on top of TCP. TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn runs on top of TLS and TCP. The port field is set following the rules in Section 3 and Section 8.1 of [I-D.ietf-bfcpbis-rfc4583bis]. Depending on the value of the SDP 'setup' attribute defined in [RFC4145], the port field contains the port to which the remote endpoint will direct BFCP messages or is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of 9, which is the discard port. Connection attribute and port MUST follow the rules of [RFC4145] While this document recommends the use of secure WebSockets (i.e.TCP/ WSS) for security reasons, TCP/WS is also permitted so as to achieve maximum compatibility among clients. 6.2. SDP Media Attributes [I-D.ietf-bfcpbis-sdp-ws-uri] defines a new SDP attribute to indicate the connection Uniform Resource Identifier (URI) for the WebSocket Client. The SDP attribute 'websocket-uri' defined in Section 3 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of WS or WSS. When the 'websocket-uri' attribute is present in the media section of the SDP, the procedures mentioned in Section 4 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be followed. Pascual, et al. Expires August 12, 2017 [Page 6] Internet-Draft WebSocket as a Transport for BFCP February 2017 7. SDP Offer/Answer Procedures 7.1. General An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each BFCP-over-WebSocket media stream and MUST assign either TCP/WSS/BFCP or TCP/WS/BFCP value to the "proto" field of the "m=" line depending on whether the endpoint wishes to use secure WebSocket or WebSocket. Furthermore, the server side, which could be either the offerer or answerer, MUST add an "a=websocket-uri" attribute in the media section depending on whether it wishes to use WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in [I-D.ietf-bfcpbis-sdp-ws-uri]. Additionally, the SDP Offer/Answer procedures defined in Section 4 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be followed for the "m=" line associated with a BFCP-over-WebSocket media stream. 7.2. Example Usage of 'websocket-uri' SDP Attribute The following is an example of an "m=" line for a BFCP connection. In this example, the offerer sends the SDP with the "proto" field having a value of TCP/WSS/BFCP * indicating that the offerer wishes to use secure WebSocket as a transport for the media stream. Offer (browser): m=application 9 TCP/WSS/BFCP * a=setup:active a=connection:new a=floorctrl:c-only m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31 Answer (server): m=application 50000 TCP/WSS/BFCP * a=setup:passive a=connection:new a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312 a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 m-stream:10 a=floorid:2 m-stream:11 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11 Pascual, et al. Expires August 12, 2017 [Page 7] Internet-Draft WebSocket as a Transport for BFCP February 2017 It is possible that an endpoint (e.g., a browser) sends an offerless INVITE to the server. In such cases the server will act as SDP offerer. The server MUST assign the SDP "setup" attribute with a value of "passive". The server MUST have an "a=websocket-uri" attribute with a "ws-URI" or "wss-URI" value depending on whether the server wishes to use WebSocket or secure WebSocket. This attribute MUST follow the syntax defined in Section 3 of [I-D.ietf-bfcpbis-sdp-ws-uri] . For BFCP application, the "proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST be TCP/WS/BFCP. 8. Authentication Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients and floor control servers SHOULD authenticate each other prior to accepting messages, and RECOMMENDS that mutual TLS/DTLS authentication be used. However, browser-based WebSocket clients have no control over the use of TLS in the WebSocket API [WS-API], so it is RECOMMENDED that standard Web-based methods for client and server authentication are used, as follows. When a BFCP WebSocket client connects to a BFCP WebSocket server, it SHOULD use TCP/WSS as its transport. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, Secure WebSocket (WSS) MUST be used, and the floor control server MUST authenticate the client.. The WebSocket client MUST follow the procedures in [RFC7525] while setting up TLS connection with the WebSocket server. The BFCP client validates the server by means of verifying the server certificate. This means the "websocket-uri" value MUST contain a hostname. The verification process does not use a=fingerprint. A floor control server that receives a message over TCP/WS can mandate the use of TCP/WSS by generating an Error message, as described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an Error code with a value of 9 (use TLS). Prior to sending BFCP requests, a BFCP WebSocket client connects to a BFCP WebSocket server and performs the connection handshake. As described in Section 3 the handshake procedure involves a HTTP GET method request from the client and a response from the server including an HTTP 101 status code. In order to authorize the WebSocket connection, the BFCP WebSocket server SHOULD inspect any cookie [RFC6265] headers present in the HTTP GET request. For many web applications the value of such a cookie is provided by the web server once the user has authenticated themselves to the web server, which could be done by many existing Pascual, et al. Expires August 12, 2017 [Page 8] Internet-Draft WebSocket as a Transport for BFCP February 2017 mechanisms. As an alternative method, the BFCP WebSocket Server could request HTTP authentication by replying to the Client's GET method request with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers this usage in Section 4.1: If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures, in particular the client might perform authentication if it receives 401 status code. If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures, in particular the client might perform authentication if it receives 401 status code. The WebSocket clients are vulnerable to the attacks of basic authentication (mentioned in Section 4 of [RFC7617]) and digest authentication (mentioned in Section 5 of [RFC7616]]). To overcome some of these weakness, the WebSocket clients for example can use HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in [RFC7486]. 9. Security Considerations Considerations from [I-D.ietf-bfcpbis-rfc4582bis], [I-D.ietf-bfcpbis-rfc4583bis] and RFC5018 [RFC5018] apply. BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. It is RECOMMENDED that the BFCP traffic transported over a WebSocket communication be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP). The security considerations in [RFC6455] apply for BFCP over WebSocket as well. The security model here is a typical webserver- client model where the client validates the server certificate and then connects to the server. Section 8 describes the authentication procedures between client and server. When using BFCP over websockets, the security mechanisms defined in [I-D.ietf-bfcpbis-rfc4582bis] are not used. Instead, the application is required to build and rely on the security mechanisms in [RFC6455]. The rest of this section analyses the threats described in Section 14 of [I-D.ietf-bfcpbis-rfc4582bis] when WebSocket is used as transport protocol for BFCP. An attacker attempting to impersonate a floor control server is avoided by having servers accept BFCP messages over WSS only. As with any other web connection, the clients will verify the servers certificate. The floor control WebSocket client MUST follow the Pascual, et al. Expires August 12, 2017 [Page 9] Internet-Draft WebSocket as a Transport for BFCP February 2017 procedures in [RFC7525] (including hostname verification as per Section 6.1 in [RFC7525]) while setting up TLS connection with floor control webSocket server. An attacker attempting to impersonate a floor control client is avoided by having servers accept BFCP messages over WSS only. As described in Section 10.5 of [RFC6455] the floor control server can use any client authentication mechanism and follow the steps in Section 8 of this document. Attackers may attempt to modify messages exchanged by a client and a floor control server. This can be prevented by having WSS between client and server. An attacker trying to replay the messages is prevented by having floor control servers check that messages arriving over a given WSS connection use an authorized user ID. Attackers may may eavesdrop on the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). In order to ensure that BFCP users are getting the level of protection that they would get using the BFCP protocol directly, applications need to have a way to control the websocket libraries to use encryption algorithms specified in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis] . Since the WebSocket API [WS-API] does not have a way to allow an application to select the encryption algorithm to be used, the protection level provided when WSS is used is limited to the underlying TLS algorithm used by WebSocket library. 10. IANA Considerations 10.1. Registration of the WebSocket BFCP Sub-Protocol This specification requests IANA to register the WebSocket BFCP sub- protocol under the "WebSocket Subprotocol Name" Registry with the following data: Subprotocol Identifier: BFCP Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor Control Protocol) Subprotocol Definition: RFCXXXX [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]] Pascual, et al. Expires August 12, 2017 [Page 10] Internet-Draft WebSocket as a Transport for BFCP February 2017 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' Values This document defines two new values for the SDP 'proto' field under the Session Description Protocol (SDP) Parameters registry. The resulting entries are shown in Figure 1 below: Value Reference ---------- ----------- TCP/WS/BFCP RFCXXXX; TCP/WSS/BFCP RFCXXXX; Figure 1: Values for the SDP 'proto' Field [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]] 11. Acknowledgements The authors want to thank Robert Welbourn, from Acme Packet and Sergio Garcia Murillo who made significant contributions to the first version of this document. This work benefited from the thorough review and constructive comments of Charles Eckel, Christer Holmberg, Paul Kyzivat, Dan Wing and Alissa Cooper. Thanks to Bert Wijnen, Robert Sparks and Mirja Kuehlewind for their reviews and comments on this document. Thanks for Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey Melnikov, Jari Arkko and Stephen Farrell for their feedback and comments during IESG reviews. 12. References 12.1. Normative References [I-D.ietf-bfcpbis-rfc4582bis] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", draft- ietf-bfcpbis-rfc4582bis-16 (work in progress), November 2015. [I-D.ietf-bfcpbis-rfc4583bis] Camarillo, G., Kristensen, T., and P. Jones, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-16 (work in progress), September 2016. Pascual, et al. Expires August 12, 2017 [Page 11] Internet-Draft WebSocket as a Transport for BFCP February 2017 [I-D.ietf-bfcpbis-sdp-ws-uri] R, R. and G. Salgueiro, "Session Description Protocol (SDP) WebSocket Connection URI Attribute", draft-ietf- bfcpbis-sdp-ws-uri-09 (work in progress), February 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/RFC5018, September 2007, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [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, . 12.2. Informative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [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, . Pascual, et al. Expires August 12, 2017 [Page 12] Internet-Draft WebSocket as a Transport for BFCP February 2017 [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 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, . [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. Authors' Addresses Victor Pascual Oracle Email: victor.pascual.avila@oracle.com Anton Roman Quobis Email: anton.roman@quobis.com Stephane Cazeaux France Telecom Orange Email: stephane.cazeaux@orange.com Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: gsalguei@cisco.com Pascual, et al. Expires August 12, 2017 [Page 13] Internet-Draft WebSocket as a Transport for BFCP February 2017 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 Pascual, et al. Expires August 12, 2017 [Page 14] ./draft-ietf-idr-bgp-prefix-sid-27.txt0000644000764400076440000011260413314510455016762 0ustar iustyiusty IDR S. Previdi Internet-Draft C. Filsfils Intended status: Standards Track A. Lindem, Ed. Expires: December 28, 2018 Cisco Systems A. Sreekantiah H. Gredler RtBrick Inc. June 26, 2018 Segment Routing Prefix SID extensions for BGP draft-ietf-idr-bgp-prefix-sid-27 Abstract Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SID). Each SID represents a topological or a service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An SR domain is defined as a single administrative domain for global SID assignment. This document defines an optional, transitive BGP attribute for announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) information and the specification for SR-MPLS SIDs. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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/. Previdi, et al. Expires December 28, 2018 [Page 1] Internet-Draft June 2018 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 28, 2018. Copyright Notice Copyright (c) 2018 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. MPLS BGP Prefix SID . . . . . . . . . . . . . . . . . . . . . 4 3. BGP Prefix-SID Attribute . . . . . . . . . . . . . . . . . . 5 3.1. Label-Index TLV . . . . . . . . . . . . . . . . . . . . . 5 3.2. Originator SRGB TLV . . . . . . . . . . . . . . . . . . . 6 4. Receiving BGP Prefix-SID Attribute . . . . . . . . . . . . . 8 4.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 8 5. Advertising BGP Prefix-SID Attribute . . . . . . . . . . . . 10 5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 10 6. Error Handling of BGP Prefix-SID Attribute . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Previdi, et al. Expires December 28, 2018 [Page 2] Internet-Draft June 2018 1. Introduction The Segment Routing (SR) architecture leverages the source routing paradigm. A segment represents either a topological instruction such as "go to prefix P following shortest path" or a service instruction. Other types of segments may be defined in the future. A segment is identified through a Segment Identifier (SID). An SR domain is defined as a single administrative domain for global SID assignment. It may be comprised of a single Autonomous System (AS) or multiple ASes under consolidated global SID administration. Typically, the ingress node of the SR domain prepends an SR header containing segments identifiers (SIDs) to an incoming packet. As described in [I-D.ietf-spring-segment-routing], when SR is applied to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the SID consists of a label. [I-D.ietf-spring-segment-routing] also describes how segment routing can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing header containing a stack of SR SIDs encoded as IPv6 addresses [I-D.ietf-6man-segment-routing-header]. The applicability and support for Segment Routing over IPv6 is beyond the scope of this document. A BGP-Prefix Segment is a BGP prefix with a Prefix-SID attached. A BGP Prefix-SID is always a global SID ([I-D.ietf-spring-segment-routing]) within the SR domain and identifies an instruction to forward the packet over the Equal-Cost Multi-Path (ECMP) best-path computed by BGP to the related prefix. The BGP Prefix-SID is the identifier of the BGP prefix segment. In this document, we always refer to the BGP-Prefix segment by the BGP Prefix-SID. This document describes the BGP extension to signal the BGP Prefix- SID. Specifically, this document defines a BGP attribute known as the BGP Prefix-SID attribute and specifies the rules to originate, receive, and handle error conditions for the attribute. The BGP Prefix-SID attribute defined in this document can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC4760], [RFC8277]). Usage of the BGP Prefix-SID attribute for other Address Family Identifier (AFI)/ Subsequent Address Family Identifier (SAFI) combinations is not defined herein but may be specified in future specifications. [I-D.ietf-spring-segment-routing-msdc] describes example use cases where the BGP Prefix-SID is used for the above AFI/SAFI combinations. Previdi, et al. Expires December 28, 2018 [Page 3] Internet-Draft June 2018 It should be noted that: o A BGP Prefix-SID will be global across ASes when the interconnected ASes are part of the same SR domain. Alternatively, when interconnecting ASes, the ASBRs of each domain will have to handle the advertisement of unique SIDs. The mechanisms for such interconnection are outside the scope of the protocol extensions defined in this document. o A BGP Prefix-SID MAY be attached to a BGP prefix. This implies that each prefix is advertised individually, reducing the ability to pack BGP advertisements (when sharing common attributes). 2. MPLS BGP Prefix SID The BGP Prefix-SID is realized on the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) in the following way: The operator assigns a globally unique label index, L_I, to a locally originated prefix of a BGP speaker N which is advertised to all other BGP speakers in the SR domain. According to [I-D.ietf-spring-segment-routing], each BGP speaker is configured with a label block called the Segment Routing Global Block (SRGB). While [I-D.ietf-spring-segment-routing] recommends using the same SRGB across all the nodes within the SR domain, the SRGB of a node is a local property and could be different on different speakers. The drawbacks of the use case where BGP speakers have different SRGBs are documented in [I-D.ietf-spring-segment-routing] and [I-D.ietf-spring-segment-routing-msdc]. If traffic-engineering within the SR domain is required, each node may also be required to advertise topological information and Peering SIDs for each of its links and peers. This information is required to perform the explicit path computation and to express an explicit path as a list of SIDs. The advertisement of topological information and peer segments (Peer SIDs) is done through [I-D.ietf-idr-bgpls-segment-routing-epe]. If a prefix segment is to be included in an MPLS label stack, e.g., for traffic engineering purposes, the knowledge of the SRGB of the originator of the prefix is required in order to compute the local label used by the originator. This document assumes that BGP-LS is the preferred method for collecting both peer segments (Peer SIDs) and SRGB information through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and Previdi, et al. Expires December 28, 2018 [Page 4] Internet-Draft June 2018 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an optional alternative for the advertisement of the local SRGB without the topology nor the peer SIDs, hence without applicability for TE, the Originator SRGB TLV of the BGP Prefix- SID attribute is specified in Section 3.2 of this document. A BGP speaker will derive its local MPLS label L from the label index L_I and its local SRGB as described in [I-D.ietf-spring-segment-routing-mpls]. The BGP speaker then programs the MPLS label L in its MPLS dataplane as its incoming/ local label for the prefix. See Section 4.1 for more details. The outgoing label for the prefix is found in the Network Layer Reachability Information (NLRI) of the Multiprotocol BGP IPv4/IPv6 Labeled Unicast prefix advertisement as defined in [RFC8277]. The label index L_I is only used as a hint to derive the local/ incoming label. Section 3.1 of this document specifies the Label-Index TLV of the BGP Prefix-SID attribute; this TLV can be used to advertise the label index for a given prefix. 3. BGP Prefix-SID Attribute The BGP Prefix-SID attribute is an optional, transitive BGP path attribute. The attribute type code 40 has been assigned by IANA (see Section 7). The BGP Prefix-SID attribute is defined here to be a set of elements encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP Prefix-SID attribute TLVs will start with a 1-octet type and a 2-octet length. The following TLVs are defined in this document: o Label-Index TLV o Originator SRGB TLV The Label-Index and Originator SRGB TLVs are used only when SR is applied to the MPLS dataplane. For future extensibility, unknown TLVs MUST be ignored and propagated unmodified. 3.1. Label-Index TLV The Label-Index TLV MUST be present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). It MUST Previdi, et al. Expires December 28, 2018 [Page 5] Internet-Draft June 2018 be ignored when received for other BGP AFI/SAFI combinations. The Label-Index 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 | Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Label Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type is 1. o Length: is 7, the total length in octets of the value portion of the TLV. o RESERVED: 8-bit field. MUST be clear on transmission and MUST be ignored on reception. o Flags: 16 bits of flags. None are defined by this document. The flag field MUST be clear on transmission and MUST be ignored on reception. o Label Index: 32-bit value representing the index value in the SRGB space. 3.2. Originator SRGB TLV The Originator SRGB TLV is an optional TLV and has the following format: Previdi, et al. Expires December 28, 2018 [Page 6] Internet-Draft June 2018 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 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRGB 1 (6 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRGB n (6 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type is 3. o Length is the total length in octets of the value portion of the TLV: 2 + (non-zero multiple of 6). o Flags: 16 bits of flags. None are defined in this document. Flags MUST be clear on transmission and MUST be ignored on reception. o SRGB: 3 octets specifying the first label in the range followed by 3 octets specifying the number of labels in the range. Note that the SRGB field MAY appear multiple times. If the SRGB field appears multiple times, the SRGB consists of multiple ranges that are concatenated. The Originator SRGB TLV contains the SRGB of the node originating the prefix to which the BGP Prefix-SID is attached. The Originator SRGB TLV MUST NOT be changed during the propagation of the BGP update. It is used to build segment routing policies when different SRGBs are used in the fabric, for example ([I-D.ietf-spring-segment-routing-msdc]). Examples of how the receiving routers concatenate the ranges and build their neighbor's Segment Routing Global Block (SRGB) are included in [I-D.ietf-spring-segment-routing-mpls]). Previdi, et al. Expires December 28, 2018 [Page 7] Internet-Draft June 2018 The Originator SRGB TLV may only appear in a BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). It MUST be ignored when received for other BGP AFI/SAFI combinations. Since the Label-Index TLV is required for IPv4/IPv6 prefix applicability, the Originator SRGB TLV will be ignored if it is not specified consistent with Section 6. If a BGP speaker receives a node's SRGB as an attribute of the BGP-LS Node NLRI and the BGP speaker also receives the same node's SRGB in a BGP Prefix-SID attribute, then the received values should be the same. If the values are different, the values advertised in the BGP- LS NLRI SHOULD be preferred and an error should be logged. 4. Receiving BGP Prefix-SID Attribute A BGP speaker receiving a BGP Prefix-SID attribute from an External BGP (EBGP) neighbor residing outside the boundaries of the SR domain MUST discard the attribute unless it is configured to accept the attribute from the EBGP neighbor. A BGP speaker SHOULD log an error for further analysis when discarding an attribute. 4.1. MPLS Dataplane: Labeled Unicast A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 Unicast ([RFC8277]) AFI/SAFI is required. When the BGP Prefix-SID attribute is attached to a BGP labeled IPv4 or IPv6 Unicast [RFC8277] AFI/SAFI, it MUST contain the Label-Index TLV and MAY contain the Originator SRGB TLV. A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered as "invalid" by the receiving speaker. The label index provides guidance to the receiving BGP speaker as to the incoming label that SHOULD be allocated to the prefix. A BGP speaker may be locally configured with an SRGB=[SRGB_Start, SRGB_End]. The preferred method for deriving the SRGB is a matter of local node configuration. The mechanisms through which a given label index value is assigned to a given prefix are outside the scope of this document. Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the derived label. A BGP Prefix-SID attribute is designated "conflicting" for a speaker M if the derived label value L lies outside the SRGB configured on M. Otherwise the Label-Index TLV is designated "acceptable" to speaker M. Previdi, et al. Expires December 28, 2018 [Page 8] Internet-Draft June 2018 If multiple different prefixes are received with the same label index, all of the different prefixes MUST have their BGP Prefix-SID attribute considered as "conflicting". If multiple valid paths for the same prefix are received from multiple BGP speakers or, in the case of [RFC7911], from the same BGP speaker, and the BGP Prefix-SID attributes do not contain the same label index, then the label index from the best path BGP Prefix-SID attribute SHOULD be chosen with a notable exception being when [RFC5004] is being used to dampen route changes. When a BGP speaker receives a path from a neighbor with an "acceptable" BGP Prefix-SID attribute and that path is selected as the best path, it SHOULD program the derived label as the label for the prefix in its local MPLS dataplane. When a BGP speaker receives a path from a neighbor with an "invalid" or "conflicting" BGP Prefix-SID attribute or when a BGP speaker receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (e.g., local policy disables the functionality), it MUST ignore the BGP Prefix-SID attribute. For the purposes of label allocation, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix as per classic Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST follow the error handling rules specified in Section 6. A BGP speaker SHOULD log an error for further analysis. In the case of a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT treat it as error and SHOULD propagate the attribute unchanged. A BGP Speaker SHOULD log a warning for further analysis, i.e., in the case the conflict is not due to a label index transition. When a BGP Prefix-SID attribute changes and transitions from "conflicting" to "acceptable", the BGP Prefix-SID attributes for other prefixes may also transition to "acceptable" as well. Implementations SHOULD assure all impacted prefixes revert to using the label indices corresponding to these newly "acceptable" BGP Prefix-SID attributes. The outgoing label is always programmed as per classic Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. Specifically, a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a label NLRI field of Implicit NULL [RFC3032] from a neighbor MUST adhere to standard behavior and program its MPLS dataplane to pop the top label when forwarding traffic to the prefix. The label NLRI defines the outbound label that MUST be used by the receiving node. Previdi, et al. Expires December 28, 2018 [Page 9] Internet-Draft June 2018 5. Advertising BGP Prefix-SID Attribute The BGP Prefix-SID attribute MAY be attached to BGP IPv4/IPv6 Label Unicast prefixes [RFC8277]. In order to prevent distribution of the BGP Prefix-SID attribute beyond its intended scope of applicability, attribute filtering SHOULD be deployed to remove the BGP Prefix-SID attribute at the administrative boundary of the segment routing domain. A BGP speaker that advertises a path received from one of its neighbors SHOULD advertise the BGP Prefix-SID received with the path without modification, as long as the BGP Prefix-SID was acceptable. If the path did not come with a BGP Prefix-SID attribute, the speaker MAY attach a BGP Prefix-SID to the path if configured to do so. The content of the TLVs present in the BGP Prefix-SID is determined by the configuration. 5.1. MPLS Dataplane: Labeled Unicast A BGP speaker that originates a prefix attaches the BGP Prefix-SID attribute when it advertises the prefix to its neighbors via Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]). The value of the label index in the Label-Index TLV is determined by configuration. A BGP speaker that originates a BGP Prefix-SID attribute MAY optionally announce the Originator SRGB TLV along with the mandatory Label-Index TLV. The content of the Originator SRGB TLV is determined by configuration. Since the label index value must be unique within an SR domain, by default an implementation SHOULD NOT advertise the BGP Prefix-SID attribute outside an Autonomous System unless it is explicitly configured to do so. In all cases, the label field of the advertised NLRI ([RFC8277], [RFC4364]) MUST be set to the local/incoming label programmed in the MPLS dataplane for the given advertised prefix. If the prefix is associated with one of the BGP speaker's interfaces, this is the usual MPLS label (such as the Implicit or Explicit NULL label [RFC3032]). 6. Error Handling of BGP Prefix-SID Attribute When a BGP Speaker receives a BGP Update message containing a malformed or invalid BGP Prefix-SID attribute attached to a IPv4/IPv6 Labeled Unicast prefix [RFC8277], it MUST ignore the received BGP Prefix-SID attributes and not advertise it to other BGP peers. In Previdi, et al. Expires December 28, 2018 [Page 10] Internet-Draft June 2018 this context, a malformed BGP Prefix-SID attribute is one that cannot be parsed due to not meeting the minimum attribute length requirement, contains a TLV length that doesn't conform to the length constraints for the TLV, or a contains TLV length that would extend beyond the end of the attribute (as defined by the attribute length). This is equivalent to the "Attribute discard" action specified in [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an error for further analysis. As per with [RFC7606], if the BGP Prefix-SID attribute appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message will continue to be processed. Similarly, if a recognized TLV appears more than once in an BGP Prefix-SID attribute while the specification only allows for a single occurrence, then all the occurrences of the TLV other than the first one SHALL be discarded and the Prefix-SID attribute will continue to be processed. For future extensibility, unknown TLVs MUST be ignored and propagated unmodified. 7. IANA Considerations This document defines a BGP path attribute known as the BGP Prefix- SID attribute. This document requests IANA to assign an attribute code type (suggested value: 40) to the BGP Prefix-SID attribute from the BGP Path Attributes registry. IANA temporarily assigned the following: 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 2018-09-30) [draft-ietf-idr-bgp-prefix-sid] This document defines two TLVs for the BGP Prefix-SID attribute. These TLVs need to be registered with IANA. We request IANA to create a registry for BGP Prefix-SID Attribute TLVs as follows: Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid Registration Procedure(s): Values 1-254 - Expert Review as defined in [RFC8126], Value 0 and 255 reserved Previdi, et al. Expires December 28, 2018 [Page 11] Internet-Draft June 2018 Value Type Reference 0 Reserved this document 1 Label-Index this document 2 Deprecated this document 3 Originator SRGB this document 4-254 Unassigned 255 Reserved this document The value 2 previously corresponded to the IPv6 SID TLV which was specified in previous versions of this document. It was removed and usage of the BGP Prefix-SID for Segment Routing over the IPv6 dataplane [I-D.ietf-spring-segment-routing] has been deferred to future specifications. This document also requests creation of the "BGP Prefix-SID Label- Index TLV Flags" registry under the "Border Gateway Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. Initially, this 16-bit flags registry will be empty. The registration policy for flag bits will Expert Review [RFC8126] consistent with the BGP Prefix-SID TLV Types registry. Finally, this document requests creation of the "BGP Prefix-SID Originator SRGB TLV Flags" registry under the "Border Gateway Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- prefix-sid. Initially, this 16-bit flags registry will be empty. The registration policy for flag bits will Expert Review [RFC8126] consistent with the BGP Prefix-SID TLV Types registry. The designated experts must be good and faithful stewards of the above registries, assuring that each request is legitimate and corresponds to a viable use case. Given the limited number of bits in the flags registries and the applicability to a single TLV, additional scrutiny should be afforded to flag bit allocation requests. In general, no single use case should require more than one flag bit and, should the use case require more, alternate encodings using new TLVs should be considered. 8. Manageability Considerations This document defines a BGP attribute to address use cases such as the one described in [I-D.ietf-spring-segment-routing-msdc]. It is assumed that advertisement of the BGP Prefix-SID attribute is controlled by the operator in order to: o Prevent undesired origination/advertisement of the BGP Prefix-SID attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be attached to a prefix and advertised. Hence, BGP Prefix-SID advertisement SHOULD require explicit enablement. Previdi, et al. Expires December 28, 2018 [Page 12] Internet-Draft June 2018 o Prevent any undesired propagation of the BGP Prefix-SID attribute. By default, the BGP Prefix-SID is not advertised outside the boundary of a single SR/administrative domain which may include one or more ASes. The propagation to other ASes MUST be explicitly configured. The deployment model described in [I-D.ietf-spring-segment-routing-msdc] assumes multiple Autonomous Systems (ASes) under a common administrative domain. For this use case, the BGP Prefix-SID advertisement is applicable to the inter-AS context, i.e., EBGP, while it is confined to a single administrative domain. 9. Security Considerations This document introduces a BGP attribute (BGP Prefix-SID) which inherits the security considerations expressed in: [RFC4271], [RFC8277], and [I-D.ietf-spring-segment-routing]. When advertised using BGPsec as described in [RFC8205], the BGP Prefix-SID attribute doesn't impose any unique security considerations. It should be noted that the BGP Prefix-SID attribute is not protected by the BGPsec signatures. It should be noted that, as described in Section 8, this document refers to a deployment model where all nodes are under the single administrative domain. In this context, we assume that the operator doesn't want to leak any information related to internal prefixes and topology outside of the administrative domain. The internal information includes the BGP Prefix-SID. In order to prevent such leaking, the common BGP mechanisms (filters) are applied at the boundary of the SR/administrative domain. Local BGP attribute filtering policies and mechanisms are not standardized and, consequently, beyond the scope of this document. To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service (DDoS) attack due to excessive BGP updates with an invalid or conflicting BGP Prefix-SID attribute, error log message rate-limiting as well as suppression of duplicate error log messages SHOULD be deployed. Since BGP-LS is the preferred method for advertising SRGB information, the BGP speaker SHOULD log an error if a BGP Prefix-SID attribute is received with SRGB information different from that received as an attribute of the same node's BGP-LS Node NLRI. Previdi, et al. Expires December 28, 2018 [Page 13] Internet-Draft June 2018 10. Contributors Keyur Patel Arrcus, Inc. US Email: Keyur@arrcus.com Saikat Ray Unaffiliated US Email: raysaikat@gmail.com 11. Acknowledgements The authors would like to thank Satya Mohanty for his contribution to this document. The authors would like to thank Alvaro Retana for substantive comments as part of the Routing AD review. The authors would like to thank Bruno Decraene for substantive comments and suggested text as part of the Routing Directorate review. The authors would like to thank Shyam Sethuram for comments and discussion of TLV processing and validation. The authors would like to thank Robert Raszuk for comments and suggestions regarding the MPLS data plane behavior. The authors would like to thank Krishna Deevi, Juan Alcaide, Howard Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID label indices and BGP add paths. The authors would like to thank Peter Yee, Tony Przygienda, Mirja Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren Kumari, Ben Campbell Sue Hares, and Martin Vigoureux for IDR Working Group last call, IETF Last Call, directorate, and IESG reviews. 12. References 12.1. Normative References Previdi, et al. Expires December 28, 2018 [Page 14] Internet-Draft June 2018 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-14 (work in progress), June 2018. [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, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [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, . [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Previdi, et al. Expires December 28, 2018 [Page 15] Internet-Draft June 2018 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . 12.2. Informative References [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-13 (work in progress), May 2018. [I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 (work in progress), May 2018. [I-D.ietf-idr-bgpls-segment-routing-epe] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", draft-ietf-idr-bgpls-segment-routing- epe-15 (work in progress), March 2018. [I-D.ietf-spring-segment-routing-msdc] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P. Lapukhov, "BGP-Prefix Segment in large-scale data centers", draft-ietf-spring-segment-routing-msdc-09 (work in progress), May 2018. [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, . [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions from One External to Another", RFC 5004, DOI 10.17487/RFC5004, September 2007, . Previdi, et al. Expires December 28, 2018 [Page 16] Internet-Draft June 2018 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . Authors' Addresses Stefano Previdi Cisco Systems IT Email: stefano@previdi.net Clarence Filsfils Cisco Systems Brussels Belgium Email: cfilsfils@cisco.com Acee Lindem (editor) Cisco Systems 301 Midenhall Way Cary, NC 27513 USA Email: acee@cisco.com Arjun Sreekantiah Email: arjunhrs@gmail.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Previdi, et al. Expires December 28, 2018 [Page 17] ./draft-ietf-bfcpbis-rfc4582bis-16.txt0000644000764400076440000067005012621510104016560 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-intarea-frag-fragile-17.txt0000644000764400076440000017165613544557607017367 0ustar iustyiusty Internet Area WG R. Bonica Internet-Draft Juniper Networks Intended status: Best Current Practice F. Baker Expires: April 2, 2020 Unaffiliated G. Huston APNIC R. Hinden Check Point Software O. Troan Cisco F. Gont SI6 Networks September 30, 2019 IP Fragmentation Considered Fragile draft-ietf-intarea-frag-fragile-17 Abstract This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. 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, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Bonica, et al. Expires April 2, 2020 [Page 1] Internet-Draft IP Fragmentation Fragile September 2019 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 . . . . . . . . . . . . . . . . . . 3 2. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Links, Paths, MTU and PMTU . . . . . . . . . . . . . . . 3 2.2. Fragmentation Procedures . . . . . . . . . . . . . . . . 6 2.3. Upper-Layer Reliance on IP Fragmentation . . . . . . . . 6 3. Increased Fragility . . . . . . . . . . . . . . . . . . . . . 7 3.1. Virtual Reassembly . . . . . . . . . . . . . . . . . . . 7 3.2. Policy-Based Routing . . . . . . . . . . . . . . . . . . 8 3.3. Network Address Translation (NAT) . . . . . . . . . . . . 9 3.4. Stateless Firewalls . . . . . . . . . . . . . . . . . . . 9 3.5. Equal Cost Multipath, Link Aggregate Groups and Stateless Load-Balancers . . . . . . . . . . . . . . . . . . . . . 10 3.6. IPv4 Reassembly Errors at High Data Rates . . . . . . . . 11 3.7. Security Vulnerabilities . . . . . . . . . . . . . . . . 11 3.8. PMTU Blackholing Due to ICMP Loss . . . . . . . . . . . . 12 3.8.1. Transient Loss . . . . . . . . . . . . . . . . . . . 13 3.8.2. Incorrect Implementation of Security Policy . . . . . 13 3.8.3. Persistent Loss Caused By Anycast . . . . . . . . . . 14 3.8.4. Persistent Loss Caused By Unidirectional Routing . . 14 3.9. Blackholing Due To Filtering or Loss . . . . . . . . . . 14 4. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 15 4.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 15 4.2. Application Layer Solutions . . . . . . . . . . . . . . . 17 5. Applications That Rely on IPv6 Fragmentation . . . . . . . . 17 5.1. Domain Name Service (DNS) . . . . . . . . . . . . . . . . 18 5.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . 18 5.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 18 5.4. UDP Applications Enhancing Performance . . . . . . . . . 19 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. For Application and Protocol Developers . . . . . . . . . 19 6.2. For System Developers . . . . . . . . . . . . . . . . . . 20 6.3. For Middle Box Developers . . . . . . . . . . . . . . . . 20 6.4. For ECMP, LAG and Load-Balancer Developers And Operators 20 6.5. For Network Operators . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 Bonica, et al. Expires April 2, 2020 [Page 2] Internet-Draft IP Fragmentation Fragile September 2019 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Contributors' Address . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Operational experience [Kent] [Huston] [RFC7872] reveals that IP fragmentation introduces fragility to Internet communication. This document describes IP fragmentation and explains the fragility it introduces. It also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. While this document identifies issues associated with IP fragmentation, it does not recommend deprecation. Legacy protocols that depend upon IP fragmentation would do well to be updated to remove that dependency. However, some applications and environments (see Section 5) require IP fragmentation. In these cases, the protocol will continue to rely on IP fragmentation, but the designer should to be aware that fragmented packets may result in blackholes; a design should include appropriate safeguards. Rather than deprecating IP Fragmentation, this document recommends that upper-layer protocols address the problem of fragmentation at their layer, reducing their reliance on IP fragmentation to the greatest degree possible. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. IP Fragmentation 2.1. Links, Paths, MTU and PMTU An Internet path connects a source node to a destination node. A path may contain links and routers. If a path contains more than one link, the links are connected in series and a router connects each link to the next. Bonica, et al. Expires April 2, 2020 [Page 3] Internet-Draft IP Fragmentation Fragile September 2019 Internet paths are dynamic. Assume that the path from one node to another contains a set of links and routers. If a link or a router fails, the path can also change so that it includes a different set of links and routers. Each link is constrained by the number of bytes that it can convey in a single IP packet. This constraint is called the link Maximum Transmission Unit (MTU). IPv4 [RFC0791] requires every link to support at 576 bytes or greater (see NOTE 1). IPv6 [RFC0791] similarly requires every link to support an MTU of 1280 bytes or greater. These are called the IPv4 and IPv6 minimum link MTU's. Some links, and some ways of using links, result in additional variable overhead. For the simple case of tunnels, this document defers to other documents. For other cases, such as MPLS, this document considers the Link MTU to include appropriate allowance for any such overhead. Likewise, each Internet path is constrained by the number of bytes that it can convey in a single IP packet. This constraint is called the Path MTU (PMTU). For any given path, the PMTU is equal to the smallest of its link MTU's. Because Internet paths are dynamic, PMTU is also dynamic. For reasons described below, source nodes estimate the PMTU between themselves and destination nodes. A source node can produce extremely conservative PMTU estimates in which: o The estimate for each IPv4 path is equal to the IPv4 minimum link MTU. o The estimate for each IPv6 path is equal to the IPv6 minimum link MTU. While these conservative estimates are guaranteed to be less than or equal to the actual PMTU, they are likely to be much less than the actual PMTU. This may adversely affect upper-layer protocol performance. By executing Path MTU Discovery (PMTUD) [RFC1191] [RFC8201] procedures, a source node can maintain a less conservative estimate of the PMTU between itself and a destination node. In PMTUD, the source node produces an initial PMTU estimate. This initial estimate is equal to the MTU of the first link along the path to the destination node. It can be greater than the actual PMTU. Having produced an initial PMTU estimate, the source node sends non- fragmentable IP packets to the destination node (see NOTE 2). If one Bonica, et al. Expires April 2, 2020 [Page 4] Internet-Draft IP Fragmentation Fragile September 2019 of these packets is larger than the actual PMTU, a downstream router will not be able to forward the packet through the next link along the path. Therefore, the downstream router drops the packet and sends an Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] Packet Too Big (PTB) message to the source node (see NOTE 3). The ICMP PTB message indicates the MTU of the link through which the packet could not be forwarded. The source node uses this information to refine its PMTU estimate. PMTUD produces a running estimate of the PMTU between a source node and a destination node. Because PMTU is dynamic, the PMTU estimate can be larger than the actual PMTU. In order to detect PMTU increases, PMTUD occasionally resets the PMTU estimate to its initial value and repeats the procedure described above. Ideally, PMTUD operates as described above. However, in some scenarios, PMTUD fails. For example: o PMTUD relies on the network's ability to deliver ICMP PTB messages to the source node. If the network cannot deliver ICMP PTB messages to the source node, PMTUD fails. o PMTUD is susceptible to attack because ICMP messages are easily forged [RFC5927] and not authenticated by the receiver. Such attacks can cause PMTUD to produce unnecessarily conservative PMTU estimates. NOTE 1: In IPv4, every host must be capable of receiving a packet whose length is equal to 576 bytes. However, the IPv4 minimum link MTU is not 576. Section 3.2 of RFC 791 explicitly states that the IPv4 minimum link MTU is 68 bytes. But for practical purposes, many network operators consider the IPv4 minimum link MTU to be 576 bytes, to minimize the requirement for fragmentation en route. So, for the purposes of this document, we assume that the IPv4 minimum link MTU is 576 bytes. NOTE 2: A non-fragmentable packet can be fragmented at its source. However, it cannot be fragmented by a downstream node. An IPv4 packet whose DF-bit is set to 0 is fragmentable. An IPv4 packet whose DF-bit is set to 1 is non-fragmentable. All IPv6 packets are also non-fragmentable. NOTE 3: The ICMP PTB message has two instantiations. In ICMPv4 [RFC0792], the ICMP PTB message is a Destination Unreachable message with Code equal to 4 fragmentation needed and DF set. This message was augmented by [RFC1191] to indicate the MTU of the link through which the packet could not be forwarded. In ICMPv6 [RFC4443], the ICMP PTB message is a Packet Too Big Message with Code equal to 0. Bonica, et al. Expires April 2, 2020 [Page 5] Internet-Draft IP Fragmentation Fragile September 2019 This message also indicates the MTU of the link through which the packet could not be forwarded. 2.2. Fragmentation Procedures When an upper-layer protocol submits data to the underlying IP module, and the resulting IP packet's length is greater than the PMTU, the packet is divided into fragments. Each fragment includes an IP header and a portion of the original packet. [RFC0791] describes IPv4 fragmentation procedures. An IPv4 packet whose DF-bit is set to 1 may be fragmented by the source node, but may not be fragmented by a downstream router. An IPv4 packet whose DF-bit is set to 0 may be fragmented by the source node or by a downstream router. When an IPv4 packet is fragmented, all IP options (which are within the IPv4 header) appear in the first fragment, but only options whose "copy" bit is set to 1 appear in subsequent fragments. [RFC8200], notably in section 4.5, describes IPv6 fragmentation procedures. An IPv6 packet may be fragmented only at the source node. When an IPv6 packet is fragmented, all extension headers appear in the first fragment, but only per-fragment headers appear in subsequent fragments. Per-fragment headers include the following: o The IPv6 header. o The Hop-by-hop Options header (if present) o The Destination Options header (if present and if it precedes a Routing header) o The Routing Header (if present) o The Fragment Header In IPv4, the upper-layer header usually appears in the first fragment, due to the sizes of the headers involved; in IPv6, it is required to. 2.3. Upper-Layer Reliance on IP Fragmentation Upper-layer protocols can operate in the following modes: o Do not rely on IP fragmentation. o Rely on IP fragmentation by the source node only. Bonica, et al. Expires April 2, 2020 [Page 6] Internet-Draft IP Fragmentation Fragile September 2019 o Rely on IP fragmentation by any node. Upper-layer protocols running over IPv4 can operate in all of the above-mentioned modes. Upper-layer protocols running over IPv6 can operate in the first and second modes only. Upper-layer protocols that operate in the first two modes (above) require access to the PMTU estimate. In order to fulfill this requirement, they can: o Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link MTU. o Access the estimate that PMTUD produced. o Execute PMTUD procedures themselves. o Execute Packetization Layer PMTUD (PLPMTUD) [RFC4821] [I-D.ietf-tsvwg-datagram-plpmtud] procedures. According to PLPMTUD procedures, the upper-layer protocol maintains a running PMTU estimate. It does so by sending probe packets of various sizes to its upper-layer peer and receiving acknowledgements. This strategy differs from PMTUD in that it relies on acknowledgement of received messages, as opposed to ICMP PTB messages concerning dropped messages. Therefore, PLPMTUD does not rely on the network's ability to deliver ICMP PTB messages to the source. 3. Increased Fragility This section explains how IP fragmentation introduces fragility to Internet communication. 3.1. Virtual Reassembly Virtual reassembly is a procedure in which a device conceptually reassembles a packet, forwards its fragments, and discards the reassembled copy. In A+P and CGN, virtual reassembly is required in order to correctly translate fragment addresses. It could be useful to address the problems in Section 3.2, Section 3.3, Section 3.4, and Section 3.5. Virtual reassembly in the network is problematic, however, because it is computationally expensive and because it holds state for indeterminate periods of time, is prone to errors and, is prone to attacks (Section 3.7). Bonica, et al. Expires April 2, 2020 [Page 7] Internet-Draft IP Fragmentation Fragile September 2019 One of the benefits of fragmenting at the source, as IPv6 does, is that there is no question of temporary state or involved processes as required in virtual fragmentation. The sender has the entire message, and is fragmenting it as needed - and can apply that knowledge consistently across the fragments it produces. It is better than virtual fragmentation in that sense. 3.2. Policy-Based Routing IP Fragmentation causes problems for routers that implement policy- based routing. When a router receives a packet, it identifies the next-hop on route to the packet's destination and forwards the packet to that next-hop. In order to identify the next-hop, the router interrogates a local data structure called the Forwarding Information Base (FIB). Normally, the FIB contains destination-based entries that map a destination prefix to a next-hop. Policy-based routing allows destination-based and policy-based entries to coexist in the same FIB. A policy-based FIB entry maps multiple fields, drawn from either the IP or transport-layer header, to a next-hop. +-------+--------------+-----------------+------------+-------------+ | Entry | Type | Dest. Prefix | Next Hdr / | Next-Hop | | | | | Dest. Port | | +-------+--------------+-----------------+------------+-------------+ | | | | | | | 1 | Destination- | 2001:db8::1/128 | Any / Any | 2001:db8::2 | | | based | | | | | | | | | | | 2 | Policy- | 2001:db8::1/128 | TCP / 80 | 2001:db8::3 | | | based | | | | +-------+--------------+-----------------+------------+-------------+ Table 1: Policy-Based Routing FIB Assume that a router maintains the FIB in Table 1. The first FIB entry is destination-based. It maps a destination prefix 2001:db8::1/128 to a next-hop 2001:db8::2. The second FIB entry is policy-based. It maps the same destination prefix 2001:db8::1/128 and a destination port ( TCP / 80 ) to a different next-hop (2001:db8::3). The second entry is more specific than the first. When the router receives the first fragment of a packet that is destined for TCP port 80 on 2001:db8::1, it interrogates the FIB. Both FIB entries satisfy the query. The router selects the second Bonica, et al. Expires April 2, 2020 [Page 8] Internet-Draft IP Fragmentation Fragile September 2019 FIB entry because it is more specific and forwards the packet to 2001:db8::3. When the router receives the second fragment of the packet, it interrogates the FIB again. This time, only the first FIB entry satisfies the query, because the second fragment contains no indication that the packet is destined for TCP port 80. Therefore, the router selects the first FIB entry and forwards the packet to 2001:db8::2. Policy-based routing is also known as filter-based-forwarding. 3.3. Network Address Translation (NAT) IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT device detects a new, outbound flow, it maps that flow's source port and IP address to another source port and IP address. Having created that mapping, the NAT device translates: o The Source IP Address and Source Port on each outbound packet. o The Destination IP Address and Destination Port on each inbound packet. A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common NAT strategies. In both approaches the NAT device must virtually reassemble fragmented packets in order to translate and forward each fragment. (See NOTE 1.) 3.4. Stateless Firewalls As discussed in more detail in Section 3.7, IP fragmentation causes problems for stateless firewalls whose rules include TCP and UDP ports. Because port information is only available in the first fragment and not available in the subsequent fragments the firewall is limited to the following options: o Accept all trailing subsequent, possibly admitting certain classes of attack. o Block all subsequent fragments, possibly blocking legitimate traffic. Neither option is attractive. Bonica, et al. Expires April 2, 2020 [Page 9] Internet-Draft IP Fragmentation Fragile September 2019 3.5. Equal Cost Multipath, Link Aggregate Groups and Stateless Load- Balancers IP fragmentation causes problems for Equal Cost Multipath (ECMP), Link Aggregate Groups (LAG) and other stateless load-distribution technologies. In order to assign a packet or packet fragment to a link, an intermediate node executes a hash (i.e., load-distributing) algorithm. The following paragraphs describe a commonly deployed hash algorithm. If the packet or packet fragment contains a transport-layer header, the algorithm accepts the following 5-tuple as input: o IP Source Address. o IP Destination Address. o IPv4 Protocol or IPv6 Next Header. o transport-layer source port. o transport-layer destination port. If the packet or packet fragment does not contain a transport-layer header, the algorithm accepts only the following 3-tuple as input: o IP Source Address. o IP Destination Address. o IPv4 Protocol or IPv6 Next Header. Therefore, non-fragmented packets belonging to a flow can be assigned to one link while fragmented packets belonging to the same flow can be divided between that link and another. This can cause suboptimal load-distribution. [RFC6438] offers a partial solution to this problem for IPv6 devices only. According to [RFC6438]: "At intermediate routers that perform load balancing, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next hop MUST minimally include the 3-tuple {dest addr, source addr, flow label} and MAY also include the remaining components of the 5-tuple." Bonica, et al. Expires April 2, 2020 [Page 10] Internet-Draft IP Fragmentation Fragile September 2019 If the algorithm includes only the 3-tuple {dest addr, source addr, flow label}, it will assign all fragments belonging to a packet to the same link. (See [RFC6437] and [RFC7098]). In order to avoid the problem described above, implementations SHOULD implement the recommendations provided in Section 6.4 of this document. 3.6. IPv4 Reassembly Errors at High Data Rates 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 duplicate IDs resulting in 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. [RFC4963] describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. These reassembly issues do not occur as frequently in IPv6 because the IPv6 identification field is 32 bits long. 3.7. Security Vulnerabilities Security researchers have documented several attacks that exploit IP fragmentation. The following are examples: o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722] o Resource exhaustion attacks o Attacks based on predictable fragment identification values [RFC7739] o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998] In the overlapping fragment attack, an attacker constructs a series of packet fragments. The first fragment contains an IP header, a transport-layer header, and some transport-layer payload. This fragment complies with local security policy and is allowed to pass through a stateless firewall. A second fragment, having a non-zero offset, overlaps with the first fragment. The second fragment also passes through the stateless firewall. When the packet is reassembled, the transport layer header from the first fragment is overwritten by data from the second fragment. The reassembled packet does not comply with local security policy. Had it traversed the firewall in one piece, the firewall would have rejected it. Bonica, et al. Expires April 2, 2020 [Page 11] Internet-Draft IP Fragmentation Fragile September 2019 A stateless firewall cannot protect against the overlapping fragment attack. However, destination nodes can protect against the overlapping fragment attack by implementing the procedures described in RFC 1858, RFC 3128 and RFC 8200. These reassembly procedures detect the overlap and discard the packet. The fragment reassembly algorithm is a stateful procedure in an otherwise stateless protocol. Therefore, it can be exploited by resource exhaustion attacks. An attacker can construct a series of fragmented packets, with one fragment missing from each packet so that the reassembly is impossible. Thus, this attack causes resource exhaustion on the destination node, possibly denying reassembly services to other flows. This type of attack can be mitigated by flushing fragment reassembly buffers when necessary, at the expense of possibly dropping legitimate fragments. Each IP fragment contains an "Identification" field that destination nodes use to reassemble fragmented packets. Some implementations set the Identification field to a predictable value, thus making it easy for an attacker to forge malicious IP fragments that would cause the reassembly procedure for legitimate packets to fail. NIDS aims at identifying malicious activity by analyzing network traffic. Ambiguity in the possible result of the fragment reassembly process may allow an attacker to evade these systems. Many of these systems try to mitigate some of these evasion techniques (e.g. By computing all possible outcomes of the fragment reassembly process, at the expense of increased processing requirements). 3.8. PMTU Blackholing Due to ICMP Loss As mentioned in Section 2.3, upper-layer protocols can be configured to rely on PMTUD. Because PMTUD relies upon the network to deliver ICMP PTB messages, those protocols also rely on the networks to deliver ICMP PTB messages. According to [RFC4890], ICMPv6 PTB messages must not be filtered. However, ICMP PTB delivery is not reliable. It is subject to both transient and persistent loss. Transient loss of ICMP PTB messages can cause transient PMTU black holes. When the conditions contributing to transient loss abate, the network regains its ability to deliver ICMP PTB messages and connectivity between the source and destination nodes is restored. Section 3.8.1 of this document describes conditions that lead to transient loss of ICMP PTB messages. Bonica, et al. Expires April 2, 2020 [Page 12] Internet-Draft IP Fragmentation Fragile September 2019 Persistent loss of ICMP PTB messages can cause persistent black holes. Section 3.8.2, Section 3.8.3, and Section 3.8.4 of this document describe conditions that lead to persistent loss of ICMP PTB messages. The problem described in this section is specific to PMTUD. It does not occur when the upper-layer protocol obtains its PMTU estimate from PLPMTUD or from any other source. 3.8.1. Transient Loss The following factors can contribute to transient loss of ICMP PTB messages: o Network congestion. o Packet corruption. o Transient routing loops. o ICMP rate limiting. The effect of rate limiting may be severe, as RFC 4443 recommends strict rate limiting of ICMPv6 traffic. 3.8.2. Incorrect Implementation of Security Policy Incorrect implementation of security policy can cause persistent loss of ICMP PTB messages. For example assume that a Customer Premise Equipment (CPE) router implements the following zone-based security policy: o Allow any traffic to flow from the inside zone to the outside zone. o Do not allow any traffic to flow from the outside zone to the inside zone unless it is part of an existing flow (i.e., it was elicited by an outbound packet). When a correct implementation of the above-mentioned security policy receives an ICMP PTB message, it examines the ICMP PTB payload in order to determine whether the original packet (i.e., the packet that elicited the ICMP PTB message) belonged to an existing flow. If the original packet belonged to an existing flow, the implementation allows the ICMP PTB to flow from the outside zone to the inside zone. If not, the implementation discards the ICMP PTB message. Bonica, et al. Expires April 2, 2020 [Page 13] Internet-Draft IP Fragmentation Fragile September 2019 When an incorrect implementation of the above-mentioned security policy receives an ICMP PTB message, it discards the packet because its source address is not associated with an existing flow. The security policy described above has been implemented incorrectly on many consumer CPE routers. 3.8.3. Persistent Loss Caused By Anycast Anycast can cause persistent loss of ICMP PTB messages. Consider the example below: A DNS client sends a request to an anycast address. The network routes that DNS request to the nearest instance of that anycast address (i.e., a DNS Server). The DNS server generates a response and sends it back to the DNS client. While the response does not exceed the DNS server's PMTU estimate, it does exceed the actual PMTU. A downstream router drops the packet and sends an ICMP PTB message the packet's source (i.e., the anycast address). The network routes the ICMP PTB message to the anycast instance closest to the downstream router. That anycast instance may not be the DNS server that originated the DNS response. It may be another DNS server with the same anycast address. The DNS server that originated the response may never receive the ICMP PTB message and may never update its PMTU estimate. 3.8.4. Persistent Loss Caused By Unidirectional Routing Unidirectional routing can cause persistent loss of ICMP PTB messages. Consider the example below: A source node sends a packet to a destination node. All intermediate nodes maintain a route to the destination node, but do not maintain a route to the source node. In this case, when an intermediate node encounters an MTU issue, it cannot send an ICMP PTB message to the source node. 3.9. Blackholing Due To Filtering or Loss In RFC 7872, researchers sampled Internet paths to determine whether they would convey packets that contain IPv6 extension headers. Sampled paths terminated at popular Internet sites (e.g., popular web, mail and DNS servers). The study revealed that at least 28% of the sampled paths did not convey packets containing the IPv6 Fragment extension header. In Bonica, et al. Expires April 2, 2020 [Page 14] Internet-Draft IP Fragmentation Fragile September 2019 most cases, fragments were dropped in the destination autonomous system. In other cases, the fragments were dropped in transit autonomous systems. Another study [Huston] confirmed this finding. It reported that 37% of sampled endpoints used IPv6-capable DNS resolvers that were incapable of receiving a fragmented IPv6 response. It is difficult to determine why network operators drop fragments. Possible causes follow: o Hardware inability to process fragmented packets. o Failure to change vendor defaults. o Unintentional misconfiguration. o Intentional configuration (e.g., network operators consciously chooses to drop IPv6 fragments in order to address the issues raised in Section 3.2 through Section 3.8, above.) 4. Alternatives to IP Fragmentation 4.1. Transport Layer Solutions The Transport Control Protocol (TCP) [RFC0793]) can be operated in a mode that does not require IP fragmentation. Applications submit a stream of data to TCP. TCP divides that stream of data into segments, with no segment exceeding the TCP Maximum Segment Size (MSS). Each segment is encapsulated in a TCP header and submitted to the underlying IP module. The underlying IP module prepends an IP header and forwards the resulting packet. If the TCP MSS is sufficiently small, the underlying IP module never produces a packet whose length is greater than the actual PMTU. Therefore, IP fragmentation is not required. TCP offers the following mechanisms for MSS management: o Manual configuration o PMTUD o PLPMTUD Manual configuration is always applicable. If the MSS is configured to a sufficiently low value, the IP layer will never produce a packet Bonica, et al. Expires April 2, 2020 [Page 15] Internet-Draft IP Fragmentation Fragile September 2019 whose length is greater than the protocol minimum link MTU. However, manual configuration prevents TCP from taking advantage of larger link MTU's. Upper-layer protocols can implement PMTUD in order to discover and take advantage of larger path MTUs. However, as mentioned in Section 2.1, PMTUD relies upon the network to deliver ICMP PTB messages. Therefore, PMTUD can only provide an estimate of the PMTU in environments where the risk of ICMP PTB loss is acceptable (e.g., known to not be filtered). By contrast, PLPMTUD does not rely upon the network's ability to deliver ICMP PTB messages. It utilises probe messages sent as TCP segments to determine whether the probed PMTU can be successfully used across the network path. In PLPMTUD, probing is separated from congestion control, so that loss of a TCP probe segment does not cause a reduction of the congestion control window. [RFC4821] defines PLPMTUD procedures for TCP. While TCP will never knowingly cause the underlying IP module to emit a packet that is larger than the PMTU estimate, it can cause the underlying IP module to emit a packet that is larger than the actual PMTU. For example, if routing changes and as a result the PMTU becomes smaller, TCP will not know until the ICMP PTB message arrives. If this occurs, the packet is dropped, the PMTU estimate is updated, the segment is divided into smaller segments and each smaller segment is submitted to the underlying IP module. The Datagram Congestion Control Protocol (DCCP) [RFC4340] and the Stream Control Transport Protocol (SCTP) [RFC4960] also can be operated in a mode that does not require IP fragmentation. They both accept data from an application and divide that data into segments, with no segment exceeding a maximum size. DCCP offers manual configuration, PMTUD, and PLPMTUD as mechanisms for managing that maximum size. Datagram protocols can also implement PLPMTUD to estimate the PMTU via[I-D.ietf-tsvwg-datagram-plpmtud]. This proposes procedures for performing PLPMTUD with UDP, UDP-Options, SCTP, QUIC and other datagram protocols. Currently, User Datagram Protocol (UDP) [RFC0768] lacks a fragmentation mechanism of its own and relies on IP fragmentation. However, [I-D.ietf-tsvwg-udp-options] proposes a fragmentation mechanism for UDP. Bonica, et al. Expires April 2, 2020 [Page 16] Internet-Draft IP Fragmentation Fragile September 2019 4.2. Application Layer Solutions [RFC8085] recognizes that IP fragmentation reduces the reliability of Internet communication. It also recognizes that UDP lacks a fragmentation mechanism of its own and relies on IP fragmentation. Therefore, [RFC8085] offers the following advice regarding applications the run over the UDP. "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 application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself to determine whether the path to a destination will support its desired message size without fragmentation." RFC 8085 continues: "Applications that do not follow the 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. For IPv6, EMTU_S is 1280 bytes [RFC8200]. 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." RFC 8085 assumes that for IPv4, an EMTU_S of 576 is sufficiently small to be supported by most current Internet paths, even though the IPv4 minimum link MTU is 68 bytes. This advice applies equally to any application that runs directly over IP. 5. Applications That Rely on IPv6 Fragmentation The following applications rely on IPv6 fragmentation: o DNS [RFC1035] o OSPFv3 [RFC2328][RFC5340] o Packet-in-packet encapsulations Bonica, et al. Expires April 2, 2020 [Page 17] Internet-Draft IP Fragmentation Fragile September 2019 Each of these applications relies on IPv6 fragmentation to a varying degree. In some cases, that reliance is essential, and cannot be broken without fundamentally changing the protocol. In other cases, that reliance is incidental, and most implementations already take appropriate steps to avoid fragmentation. This list is not comprehensive, and other protocols that rely on IP fragmentation may exist. They are not specifically considered in the context of this document. 5.1. Domain Name Service (DNS) DNS relies on UDP for efficiency, and the consequence is the use of IP fragmentation for large responses, as permitted by the DNS EDNS0 options in the query. It is possible to mitigate the issue of fragmentation-based packet loss by having queries use smaller EDNS0 UDP buffer sizes, or by having the DNS server limit the size of its UDP responses to some self-imposed maximum packet size that may be less than the preferred EDNS0 UDP Buffer Size. In both cases, large responses are truncated in the DNS, signaling to the client to re- query using TCP to obtain the complete response. However, the operational issue of the partial level of support for DNS over TCP, particularly in the case where IPv6 transport is being used, becomes a limiting factor of the efficacy of this approach [Damas]. Larger DNS responses can normally be avoided by aggressively pruning the Additional section of DNS responses. One scenario where such pruning is ineffective is in the use of DNSSEC, where large key sizes act to increase the response size to certain DNS queries. There is no effective response to this situation within the DNS other than using smaller cryptographic keys and adoption of DNSSEC administrative practices that attempt to keep DNS response as short as possible. 5.2. Open Shortest Path First (OSPF) OSPF implementations can emit messages large enough to cause fragmentation. However, in order to optimize performance, most OSPF implementations restrict their maximum message size to a value that will not cause fragmentation. 5.3. Packet-in-Packet Encapsulations This document acknowledges that in some cases, packets must be fragmented within IP-in-IP tunnels. Therefore, this document makes no additional recommendations regarding IP-in-IP tunnels. Bonica, et al. Expires April 2, 2020 [Page 18] Internet-Draft IP Fragmentation Fragile September 2019 In this document, packet-in-packet encapsulations include IP-in-IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473]. [RFC4459] describes fragmentation issues associated with all of the above- mentioned encapsulations. The fragmentation strategy described for GRE in [RFC7588] has been deployed for all of the above-mentioned encapsulations. This strategy does not rely on IP fragmentation except in one corner case. (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473). Section 3.3 of [RFC7676] further describes this corner case. See [I-D.ietf-intarea-tunnels] for further discussion. 5.4. UDP Applications Enhancing Performance Some UDP applications rely on IP fragmentation to achieve acceptable levels of performance. These applications use UDP datagram sizes that are larger than the path MTU so that more data can be conveyed between the application and the kernel in a single system call. To pick one example, the Licklider Transmission Protocol (LTP), [RFC5326]which is in current use on the International Space Station (ISS), uses UDP datagram sizes larger than the path MTU to achieve acceptable levels of performance even though this invokes IP fragmentation. More generally, SNMP and video applications may transmit an application-layer quantum of data, depending on the network layer to fragment and reassemble as needed. 6. Recommendations 6.1. For Application and Protocol Developers Developers SHOULD NOT develop new protocols or applications that rely on IP fragmentation. When a new protocol or application is deployed in an environment that does not fully support IP fragmentation, it SHOULD operate correctly, either in its default configuration or in a specified alternative configuration. While there may be controlled environments where IP fragmentation works reliably, this is a deployment issue and can not be known to someone developing a new protocol or application. It is not recommended that new protocols or applications be developed that rely on IP fragmentation. Protocols and applications that rely on IP fragmentation will work less reliably on the Internet. Legacy protocols that depend upon IP fragmentation SHOULD be updated to break that dependency. However, in some cases, there may be no Bonica, et al. Expires April 2, 2020 [Page 19] Internet-Draft IP Fragmentation Fragile September 2019 viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- in-IP encapsulation). Applications and protocols cannot necessarily know or control whether they use lower layers or network paths that rely on such fragmentation. In these cases, the protocol will continue to rely on IP fragmentation but should only be used in environments where IP fragmentation is known to be supported. Protocols may be able to avoid IP fragmentation by using a sufficiently small MTU (e.g., The protocol minimum link MTU), disabling IP fragmentation, and ensuring that the transport protocol in use adapts its segment size to the MTU. Other protocols may deploy a sufficiently reliable PMTU discovery mechanism (e.g., PLMPTUD). UDP applications SHOULD abide by the recommendations stated in Section 3.2 of [RFC8085]. 6.2. For System Developers Software libraries SHOULD include provision for PLPMTUD for each supported transport protocol. 6.3. For Middle Box Developers Middle boxes, which are systems that "transparently" perform policy functions on passing traffic but do not participate in the routing system, should process IP fragments in a manner that is consistent with [RFC0791] and [RFC8200]. In many cases, middle boxes must maintain state in order to achieve this goal. Price and performance considerations frequently motivate network operators to deploy stateless middle boxes. These stateless middle boxes may perform sub-optimally, process IP fragments in a manner that is not compliant with RFC 791 or RFC 8200, or even discard IP fragments completely. Such behaviors are NOT RECOMMENDED. If a middleboxes implements non-standard behavior with respect to IP fragmentation, then that behavior MUST be clearly documented. 6.4. For ECMP, LAG and Load-Balancer Developers And Operators In their default configuration, when the IPv6 Flow Label is not equal to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP) Routing as described in OSPF [RFC2328] and other routing protocols, Link Aggregation Grouping (LAG) [RFC7424], or other load-distribution technologies SHOULD accept only the following fields as input to their hash algorithm: o IP Source Address. Bonica, et al. Expires April 2, 2020 [Page 20] Internet-Draft IP Fragmentation Fragile September 2019 o IP Destination Address. o Flow Label. Operators SHOULD deploy these devices in their default configuration. These recommendations are similar to those presented in [RFC6438] and [RFC7098]. They differ in that they specify a default configuration. 6.5. For Network Operators Operators MUST ensure proper PMTUD operation in their network, including making sure the network generates PTB packets when dropping packets too large compared to outgoing interface MTU. However, implementations MAY rate limit the generation of ICMP messages as per [RFC1812] and [RFC4443]. As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB messages unless they are known to be forged or otherwise illegitimate. As stated in Section 3.8, filtering ICMPv6 PTB packets causes PMTUD to fail. Many upper-layer protocols rely on PMTUD. As per RFC 8200, network operators MUST NOT deploy IPv6 links whose MTU is less than 1280 bytes. Network operators SHOULD NOT filter IP fragments if they are known to have originated at a domain name server or be destined for a domain name server. This is because domain name services are critical to operation of the Internet. 7. IANA Considerations This document makes no request of IANA. 8. Security Considerations This document mitigates some of the security considerations associated with IP fragmentation by discouraging its use. It does not introduce any new security vulnerabilities, because it does not introduce any new alternatives to IP fragmentation. Instead, it recommends well-understood alternatives. 9. Acknowledgements Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan, Joel Halpern, Lorenzo Colitti, Gorry Fairhurst, Mike Heard, Tom Herbert, Tatuya Jinmei, Suresh Krishnan, Jen Linkova, Paolo Lucente, Manoj Nayak, Eric Nygren, Fred Templin and Joe Touch for their comments. Bonica, et al. Expires April 2, 2020 [Page 21] Internet-Draft IP Fragmentation Fragile September 2019 10. References 10.1. Normative References [I-D.ietf-tsvwg-datagram-plpmtud] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and T. Voelker, "Packetization Layer Path MTU Discovery for Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 (work in progress), June 2019. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [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, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . Bonica, et al. Expires April 2, 2020 [Page 22] Internet-Draft IP Fragmentation Fragile September 2019 [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, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/ RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . 10.2. Informative References [Damas] Damas, J. and G. Huston, "Measuring ATR", April 2018, . [Huston] Huston, G., "IPv6, Large UDP Packets and the DNS http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html", August 2017. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-10 (work in progress), September 2019. [I-D.ietf-tsvwg-udp-options] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- udp-options-08 (work in progress), September 2019. Bonica, et al. Expires April 2, 2020 [Page 23] Internet-Draft IP Fragmentation Fragile September 2019 [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524", August 1987, . [Ptacek1998] Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection", 1998, . [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, . [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, DOI 10.17487/RFC1858, October 1995, . [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ RFC2328, April 1998, . [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, DOI 10.17487/ RFC3128, June 2001, . Bonica, et al. Expires April 2, 2020 [Page 24] Internet-Draft IP Fragmentation Fragile September 2019 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2006, . [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, . [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, DOI 10.17487/RFC5326, September 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, . [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, . [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/ RFC6346, August 2011, . Bonica, et al. Expires April 2, 2020 [Page 25] Internet-Draft IP Fragmentation Fragile September 2019 [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, . [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 Flow Label for Load Balancing in Server Farms", RFC 7098, DOI 10.17487/RFC7098, January 2014, . [RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. Khasnabish, "Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, January 2015, . [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem", RFC 7588, DOI 10.17487/ RFC7588, July 2015, . [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, . Appendix A. Contributors' Address Bonica, et al. Expires April 2, 2020 [Page 26] Internet-Draft IP Fragmentation Fragile September 2019 Authors' Addresses Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20171 USA Email: rbonica@juniper.net Fred Baker Unaffiliated Santa Barbara, California 93117 USA Email: FredBaker.IETF@gmail.com Geoff Huston APNIC 6 Cordelia St Brisbane, 4101 QLD Australia Email: gih@apnic.net Robert M. Hinden Check Point Software 959 Skyway Road San Carlos, California 94070 USA Email: bob.hinden@gmail.com Ole Troan Cisco Philip Pedersens vei 1 N-1366 Lysaker Norway Email: ot@cisco.com Bonica, et al. Expires April 2, 2020 [Page 27] Internet-Draft IP Fragmentation Fragile September 2019 Fernando Gont SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires Argentina Email: fgont@si6networks.com Bonica, et al. Expires April 2, 2020 [Page 28] ./draft-ietf-bfcpbis-rfc4583bis-27.txt0000644000764400076440000013742613402762511016601 0ustar iustyiusty BFCPbis Working Group G. Camarillo Internet-Draft Ericsson Obsoletes: 4583 (if approved) T. Kristensen Intended status: Standards Track Cisco Expires: June 11, 2019 C. Holmberg Ericsson December 8, 2018 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams draft-ietf-bfcpbis-rfc4583bis-27 Abstract This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary Floor Control Protocol (BFCP) streams. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14. 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, 2019. Copyright Notice Copyright (c) 2018 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 Camarillo, et al. Expires June 11, 2019 [Page 1] Internet-Draft BFCP December 2018 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 4 4. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 4 5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . 5 5.2. SDP 'confid' Attribute . . . . . . . . . . . . . . . . . 7 5.3. SDP 'userid' Attribute . . . . . . . . . . . . . . . . . 8 5.4. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . 9 5.5. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . 10 6. Multiplexing Considerations . . . . . . . . . . . . . . . . . 11 7. BFCP Connection Management . . . . . . . . . . . . . . . . . 12 7.1. TCP Connection Management . . . . . . . . . . . . . . . . 12 8. TLS/DTLS Considerations . . . . . . . . . . . . . . . . . . . 13 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 14 10.1. Generating the Initial SDP Offer . . . . . . . . . . . . 15 10.2. Generating the SDP Answer . . . . . . . . . . . . . . . 15 10.3. Offerer Processing of the SDP Answer . . . . . . . . . . 16 10.4. Modifying the Session . . . . . . . . . . . . . . . . . 17 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13.1. Registration of SDP 'proto' Values . . . . . . . . . . . 20 13.2. Registration of the SDP 'floorctrl' Attribute . . . . . 20 13.3. Registration of the SDP 'confid' Attribute . . . . . . . 20 13.4. Registration of the SDP 'userid' Attribute . . . . . . . 20 13.5. Registration of the SDP 'floorid' Attribute . . . . . . 21 13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 21 14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 21 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 16.1. Normative References . . . . . . . . . . . . . . . . . . 22 16.2. Informational References . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Camarillo, et al. Expires June 11, 2019 [Page 2] Internet-Draft BFCP December 2018 1. Introduction As discussed in the BFCP (Binary Floor Control Protocol) specification [I-D.ietf-bfcpbis-rfc4582bis], a given BFCP 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 the user identifier. One way for clients to obtain this information is to use an SDP offer/answer [RFC3264] exchange. This document specifies how to encode this information in the SDP session descriptions that are part of such an offer/answer exchange. User agents typically use the offer/answer model to establish a number of media streams of different types. Following this model, a BFCP connection is described as any other media stream by using an SDP 'm' line, possibly followed by a number of SDP lines that also apply to the BFCP connection. Section 4 defines how the field values in 'm' line representing a BFCP connection are set. Section 5 defines SDP attributes that are used when negotiating a BFCP connection. Section 6 defines multiplexing considerations for a BFCP connection. Section 7 defines procedures for managing a BFCP connection. Section 8 defines TLS and DTLS considerations when negotiating a BFCP connection. Section 9 defines the Interactive Connectivity Establishment (ICE) [RFC8445] considerations when negotiating a BFCP connection. Section 10 defines the SDP offer/answer procedures for negotiating a BFCP connection. 2. Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Camarillo, et al. Expires June 11, 2019 [Page 3] Internet-Draft BFCP December 2018 3. Floor Control Roles When two endpoints establish a BFCP stream, they need to determine which of them acts as a floor control client and which acts as a floor control server. Once the roles have been determined, the roles will apply to all BFCP-controlled streams associated with the BFCP stream. 4. Fields in the 'm' Line According to the SDP specification [RFC4566], the 'm' line format is the following: m= ... This section describes how to generate an 'm' line of an SDP Media Description ('m' section) describing a BFCP stream. The media field MUST have a value of "application". The port field is set depending on the value of the proto field, as explained below. A port field value of zero has the standard SDP meaning (i.e., rejection of the media stream) regardless of the proto field. When TCP is used as the transport, the port field is set following the rules in [RFC4145]. Depending on the value of the 'setup' attribute (discussed in Section 7.1), the port field contains the port to which the remote endpoint will direct BFCP messages, or in the case where the endpoint will initiate the connection towards the remote endpoint, should be set to a value of 9. When UDP is used as the transport, the port field contains the port to which the remote endpoint will direct BFCP messages regardless of the value of the 'setup' attribute. This document defines five values for the proto field: TCP/BFCP, TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. The proto value are used as described below: 'TCP/BFCP' is used for TCP transport of BFCP without TLS encryption, and is backward compatible with RFC 4583 compliant endpoints. Camarillo, et al. Expires June 11, 2019 [Page 4] Internet-Draft BFCP December 2018 'TCP/TLS/BFCP' is used for TCP transport of BFCP with TLS encryption, and is backward compatible with RFC 4583 compliant endpoints that support TLS. 'UDP/BFCP' is used for UDP transport of BFCP without DTLS encryption [RFC6347]. 'UDP/TLS/BFCP' is used for UDP transport of BFCP with DTLS encryption. This is one of the options when ICE is used (Section 9). It can also be used without ICE when backward compatibility with RFC 4583 compliant endpoints is not required. 'TCP/DTLS/BFCP' is used for TCP transport of BFCP with DTLS encryption, running on top of TCP using the framing method defined in [RFC4571], with DTLS packets being sent and received instead of RTP/RTCP packets using the shim defined in RFC 4571 such that the length field defined in RFC 4571 precedes each DTLS message. This is one of the options when ICE is used (Section 9). It can also be used without ICE when backward compatibility with RFC 4583 compliant endpoints is not required. The fmt (format) list is not applicable to BFCP. The fmt list of 'm' lines in the case of any proto field value related to BFCP MUST contain a single "*" character. If the the fmt list contains any other value it MUST be ignored. The following is an example of an 'm' line for a BFCP connection: m=application 50000 TCP/TLS/BFCP * 5. SDP Attributes 5.1. SDP 'floorctrl' Attribute This section defines the SDP 'floorctrl' media-level attribute. The attribute is used to determine the floor control roles (client and server) for the endpoints associated with the BFCP stream. Camarillo, et al. Expires June 11, 2019 [Page 5] Internet-Draft BFCP December 2018 Attribute Name: floorctrl Attribute Value: floor-control Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: floor-control = role *(SP role) role = "c-only" / "s-only" / "c-s" An endpoint includes the attribute to indicate the role(s) it would be willing to perform for the BFCP-controlled media streams: c-only: The endpoint is willing to act as floor control client. s-only: The endpoint is willing to act as floor control server only. When inserted in an offer, the offerer MAY indicate multiple attribute values ("c-only" and "s-only"). When inserted in an answer, the answerer MUST indicate only one attribute value: "c-only" or "s-only". The answerer indicates the role taken by the answerer. The offerer will then take the opposite role. In [RFC4583], there was a third attribute specified, "c-s", which meant that an endpoint was willing to act as both floor control client and floor control server at the same time for the BFCP stream, taking different roles for different BFCP-controlled media streams. The feature was underspecified and implemented in different ways, in particular many implementations interpreted "c-s" to mean that the endpoint is willing to act as either client or server (equivalent to "c-only s-only"). An implementation compliant to this specification MUST NOT include the "c-s" floorctl attribute value in an offer or in an answer, but MUST accept the attribute value in an offer and process it as equivalent to "c-only s-only" (or "s-only c-only"). Also, as an implementation compliant to this specification is only allowed to include one role, either 'c-only' or 's-conly', in an answer, each endpoint will only take one role, and as a result the endpoint will take the same role for each BFCP-controlled media stream associated with the BFCP stream. Table 1 shows the roles that the answerer is allowed to take, based on what roles the offerer has indicated that it is willing to take. Camarillo, et al. Expires June 11, 2019 [Page 6] Internet-Draft BFCP December 2018 +---------+----------+ | Offerer | Answerer | +---------+----------+ | c-only | s-only | | s-only | c-only | | c-s | c-only | | c-s | s-only | +---------+----------+ Table 1: Roles Endpoints compliant with [RFC4583] might not include the 'floorctrl' attribute in offers and answerer. If the 'floorctrl' attribute is not present, in order to be interoperable with such endpoints, the offerer will act as floor control client and the answerer will act as floor control server. The SDP Offer/Answer procedures for the 'floorctrl' attribute are defined in Section 10. The following is an example of a 'floorctrl' attribute in an offer: a=floorctrl:c-only s-only 5.2. SDP 'confid' Attribute This section defines the SDP 'confid' media-level attribute. The attribute is used by a floor control server to convey the conference ID value to the floor control client, using decimal integer representation. Camarillo, et al. Expires June 11, 2019 [Page 7] Internet-Draft BFCP December 2018 Attribute Name: confid Attribute Value: conference-id Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: conference-id = 1*DIGIT DIGIT = The maximum value of the attribute is determined by the COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. The SDP Offer/Answer procedures for the 'confid' attribute are defined in Section 10. 5.3. SDP 'userid' Attribute This section defines the SDP userid' media-level attribute. The attribute is used by a floor control server to convey the user ID value to the floor control client, using decimal integer representation. Camarillo, et al. Expires June 11, 2019 [Page 8] Internet-Draft BFCP December 2018 Attribute Name: userid Attribute Value: user-id Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: user-id = 1*DIGIT DIGIT = The maximum value of the attribute is determined by the COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. The SDP Offer/Answer procedures for the 'userid' attribute are defined in Section 10. 5.4. SDP 'floorid' Attribute This section defines the SDP 'floorid' media-level attribute. The attribute conveys a floor identifier, using decimal integer representation, and optionally pointers to one or more BFCP- controlled media streams. Camarillo, et al. Expires June 11, 2019 [Page 9] Internet-Draft BFCP December 2018 Attribute Name: floorid Attribute Value: floor-id Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: floor-id = 1*DIGIT SP "mstrm:" token *(SP token) DIGIT = token = The maximum value of the attribute is determined by the FLOOR-ID format [I-D.ietf-bfcpbis-rfc4582bis]. The floor identifier value is the integer representation of the Floor ID to be used in BFCP. Each media stream pointer value is associated with an SDP 'label' attribute [RFC4574] of a media stream. The SDP Offer/Answer procedures for the 'floorid' attribute are defined in Section 10. Note: In [RFC4583] 'm-stream' was erroneously used in Section 11. Although the example was non-normative, it is implemented by some vendors and occurs in cases where the endpoint is willing to act as a server. Therefore, it is RECOMMENDED to support parsing and interpreting 'm-stream' the same way as 'mstrm' when receiving. 5.5. SDP 'bfcpver' Attribute This section defines the SDP 'bfcpver' media-level attribute. The attribute is used to negotiate the BFCP version, using decimal integer representation. The Augmented BNF syntax [RFC5234] for the attributes is: Camarillo, et al. Expires June 11, 2019 [Page 10] Internet-Draft BFCP December 2018 Attribute Name: bfcpver Attribute Value: bfcp-version Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: bfcp-version = version *(SP version) version = 1*DIGIT DIGIT = The maximum value of the attribute is determined by the COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. An endpoint uses the 'bfcpver' attribute to convey the version(s) of BFCP supported by the endpoint, using integer values. For a given version, the attribute value representing the version MUST match the "Version" field that would be presented in the BFCP COMMON-HEADER [I-D.ietf-bfcpbis-rfc4582bis]. The BFCP version that will eventually be used will be conveyed with a BFCP-level Hello/HelloAck. Endpoints compliant with [RFC4583] might not always include the 'bfcpver' attribute in offers and answers. The attribute value, if present, MUST be in accordance with the definition of the Version field in [I-D.ietf-bfcpbis-rfc4582bis]. If the attribute is not present, endpoints MUST assume a default value in accordance with [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport the default attribute value is "1", and when used over an unreliable transport the default attribute value is "2". The value is inferred from the transport specified in the 'm' line (Section 4) of the 'm' section associated with the stream. The SDP Offer/Answer procedures for the 'bfcpver' attribute are defined in Section 10. 6. Multiplexing Considerations [I-D.ietf-mmusic-sdp-bundle-negotiation] defines how multiplexing of multiple media streams can be negotiated. This specification does not define how BFCP streams can be multiplexed with other media streams. Therefore, a BFCP stream MUST NOT be associated with a Camarillo, et al. Expires June 11, 2019 [Page 11] Internet-Draft BFCP December 2018 BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation]. Note that BFCP-controlled media streams might be multiplexed with other media streams. [I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for the SDP attributes defined in this specification, except for the 'bfcpver' attribute. Table 2 defines the mux category for the 'bfcpver' attribute: +---------+-------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +---------+-------------------------------------+-------+-----------+ | bfcpver | Needs further analysis in a | M | TBD | | | separate specification | | | +---------+-------------------------------------+-------+-----------+ Table 2: Multiplexing Attribute Analysis 7. BFCP Connection Management BFCP streams can use TCP or UDP as the underlying transport. Endpoints exchanging BFCP messages over UDP send the BFCP messages towards the peer using the connection address and port provided in the SDP 'c' and 'm' lines. TCP connection management is more complicated and is described in the following Section. Note: When using Interactive Connectivity Establishment (ICE) [RFC8445], TCP/DTLS/BFCP, or UDP/TLS/BFCP, the straight-forward procedures for connection management as UDP/BFCP described above apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and is described below. 7.1. TCP Connection Management The management of the TCP connection used to transport BFCP messages is performed using the SDP 'setup' and 'connection' attributes [RFC4145]. The 'setup' attribute indicates which of the endpoints initiates the TCP connection. The 'connection' attribute handles TCP connection re-establishment. The BFCP specification [I-D.ietf-bfcpbis-rfc4582bis] describes a number of situations when the TCP connection between a floor control client and the floor control server needs to be re-established. However, that specification does not describe the re-establishment process because this process depends on how the connection was established in the first place. Endpoints using the offer/answer mechanism follow the following rules. Camarillo, et al. Expires June 11, 2019 [Page 12] Internet-Draft BFCP December 2018 When the existing TCP connection is closed and re-established following the rules in [I-D.ietf-bfcpbis-rfc4582bis], the floor control client MUST send an offer towards the floor control server in order to re-establish the connection. If a TCP connection cannot deliver a BFCP message and times out, the endpoint that attempted to send the message (i.e., the one that detected the TCP timeout) MUST send an offer in order to re-establish the TCP connection. Endpoints that use the offer/answer mechanism to negotiate TCP connections MUST support the 'setup' and 'connection' attributes. 8. TLS/DTLS Considerations When DTLS is used with UDP, the generic procedures defined in Section 5 of [I-D.ietf-mmusic-dtls-sdp] MUST be followed. When TLS is used with TCP, once the underlying connection is established, the answerer always acts as the TLS server. If the TCP connection is lost, the active endpoint [RFC4583] is responsible for re-establishing the TCP connection. Unless a new TLS connection is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. Note: For TLS, it was decided to keep the original procedures in [RFC4583] to determine which endpoint acts as the TLS server in order to retain backwards compatibility. 9. ICE Considerations Generic SDP offer/answer procedures for Interactive Connectivity Establishment (ICE) are defined in [I-D.ietf-mmusic-ice-sip-sdp]. When BFCP is used with UDP based ICE candidates [RFC8445] then the procedures for UDP/TLS/BFCP are used. When BFCP is used with TCP based ICE candidates [RFC6544] then the procedures for TCP/DTLS/BFCP are used. Based on the procedures defined in [I-D.ietf-mmusic-dtls-sdp], endpoints treat all ICE candidate pairs associated with a BFCP stream on top of a DTLS association as part of the same DTLS association. Thus, there will only be one BFCP handshake and one DTLS handshake even if there are multiple valid candidate pairs, and if BFCP media is shifted between candidate pairs (including switching between UDP to TCP candidate pairs) prior to nomination. If new candidates are added, they will also be part of the same DTLS association. Camarillo, et al. Expires June 11, 2019 [Page 13] Internet-Draft BFCP December 2018 In order to maximize the likelihood of interoperability between the endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement support for UDP/TLS/BFCP. When an SDP offer or answer conveys multiple ICE candidates for a BFCP stream, UDP based candidates SHOULD be included and the default candidate SHOULD be chosen from one of those UDP candidates. If UDP transport is used for the default candidate, then the 'm' line proto value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. Note: Usage of ICE with protocols other than UDP/TLS/BFCP and TCP/DTLS/BFCP is outside of scope for this specification. 10. SDP Offer/Answer Procedures This section defines the SDP offer/answer [RFC3264] procedures for negotiating and establishing a BFCP stream. Generic procedures for DTLS are defined in [I-D.ietf-mmusic-dtls-sdp]. Generic procedures for TLS are defined in [RFC8122]. This section only defines the BFCP-specific procedures. Unless explicitly stated otherwise, the procedures apply to an 'm' section describing a BFCP stream. If an offer or answer contains multiple 'm' sections describing BFCP streams, the procedures are applied independently to each stream. Within this document, 'initial offer' refers to the first offer, within an SDP session (e.g. a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to carry SDP) in which the offerer indicates that it wants to negotiate the establishment of a BFCP stream. If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 'UDP/TLS/BFCP', the offerer and answerer follow the generic procedures defined in [RFC8122]. If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' attribute according to the procedures in [RFC4145]. If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' attribute according to the procedures in [RFC4145]. Note: The use of source-specific SDP parameters [RFC5576] is not defined for BFCP streams. Camarillo, et al. Expires June 11, 2019 [Page 14] Internet-Draft BFCP December 2018 10.1. Generating the Initial SDP Offer When the offerer creates an initial offer, the offerer MUST include an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' attribute (Section 5.5) in the 'm' section. In addition, if the offerer includes an SDP 'floorctrl' attribute with 's-only' or 'c-s' attribute values in the offer, the offerer: o MUST include an SDP 'confid' attribute (Section 5.2) in the 'm' section; and o MUST include an SDP 'userid' attribute (Section 5.3) in the 'm' section; and o MUST include an SDP 'floorid' attribute (Section 5.4) in the 'm' section; and o MUST include an SDP 'label' attribute ([RFC4574]) with the 'm' section of each BFCP-controlled media stream. Note: If the offerer includes an SDP 'floorctrl' attribute with a 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute value in the offer, the attribute values above will only be used if it is determined (Section 5.1) that the offerer will act as floor control server. 10.2. Generating the SDP Answer When the answerer receives an offer that contains an 'm' section describing a BFCP stream, the answerer MUST check whether it supports one or more of the BFCP versions supported by the offerer (Section 5.5). If the answerer does not support any of the BFCP versions, it MUST NOT accept the 'm' section. Otherwise, if the answerer accepts the 'm' section, it: o MUST insert a corresponding 'm' section in the answer, with an identical 'm' line proto value [RFC3264]; and o MUST include a 'bfcpver' attribute in the 'm' section. The versions indicated by the answer MUST be the same or a subset of the versions indicated by the offerer in the corresponding offer; and o MUST, if the offer contained an SDP 'floorctrl' attribute, include a 'floorctrl' attribute in the 'm' section. Camarillo, et al. Expires June 11, 2019 [Page 15] Internet-Draft BFCP December 2018 In addition, if the answerer includes an SDP 'floorctrl' attribute with an 's-only' attribute value in the answer, the answerer: o MUST include an SDP 'confid' attribute in the 'm' section; and o MUST include an SDP 'userid' attribute in the 'm' section; and o MUST include an SDP 'floorid' attribute in the 'm' section; and o MUST include an SDP 'label' attribute in the 'm' section of each BFCP-controlled media stream. Note: An offerer compliant with [RFC4583] might not include 'floorctrl' and 'bfcpver' attributes in offers, in which cases the default values apply. Once the answerer has sent the answer, the answerer: o MUST, if the answerer is the active endpoint, and if a TCP connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TCP connection; and o MUST, if the answerer is the active endpoint, and if an TLS/DTLS connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TLS/DTLS connection (by sending a ClientHello message). If the answerer does not accept the 'm' section in the offer, it MUST assign a zero port value to the 'm' line of the corresponding 'm' section in the answer. In addition, the answerer MUST NOT establish a TCP connection or a TLS/DTLS connection associated with the 'm' section. 10.3. Offerer Processing of the SDP Answer When the offerer receives an answer that contains an 'm' section with a non-zero port value, describing a BFCP stream, the offerer: o MUST, if the offerer is the active endpoint, and if a TCP connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TCP connection; and o MUST, if the offerer is the active endpoint, and if an TLS/DTLS connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TLS/DTLS connection (by sending a ClientHello message). Camarillo, et al. Expires June 11, 2019 [Page 16] Internet-Draft BFCP December 2018 Note: An answerer compliant with [RFC4583] might not include 'floorctrl' and 'bfcpver' attributes in answers, in which cases the default values apply. If the 'm' line in the answer contains a zero port value, or if the offerer for some other reason does not accept the answer (e.g., if the answerer only indicates support of BFCP versions not supported by the offerer), the offerer MUST NOT establish a TCP connection or a TLS/DTLS connection associated with the 'm' section. 10.4. Modifying the Session When an offerer sends an updated offer, in order to modify a previously established BFCP stream, it follows the procedures in Section 10.1, with the following exceptions: o If the BFCP stream is carried on top of TCP, and if the offerer does not want to re-establish an existing TCP connection, the offerer MUST include an SDP 'connection' attribute with a value of "existing", in the 'm' section; and o If the offerer wants to disable a previously established BFCP stream, it MUST assign a zero port value to the 'm' line associated with the BFCP connection, following the procedures in [RFC3264]. 11. Examples For the purpose of brevity, the main portion of the session description is omitted in the examples, which only show 'm' sections and their 'm' lines and attributes. The following is an example of an offer sent by a conference server to a client. Camarillo, et al. Expires June 11, 2019 [Page 17] Internet-Draft BFCP December 2018 m=application 50000 TCP/TLS/BFCP * a=setup:actpass a=connection:new a=fingerprint:sha-256 \ 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=floorctrl:c-only s-only a=confid:4321 a=userid:1234 a=floorid:1 mstrm:10 a=floorid:2 mstrm:11 a=bfcpver:1 2 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11 Note that due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content. The following is the answer returned by the client. m=application 9 TCP/TLS/BFCP * a=setup:active a=connection:new a=fingerprint:sha-256 \ 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=floorctrl:c-only a=bfcpver:1 m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31 A similar example using unreliable transport and DTLS is shown below, where the offer is sent from a client. Camarillo, et al. Expires June 11, 2019 [Page 18] Internet-Draft BFCP December 2018 m=application 50000 UDP/TLS/BFCP * a=setup:actpass a=dtls-id:abc3dl a=fingerprint:sha-256 \ 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=floorctrl:c-only s-only a=confid:4321 a=userid:1234 a=floorid:1 mstrm:10 a=floorid:2 mstrm:11 a=bfcpver:1 2 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11 The following is the answer returned by the server. m=application 55000 UDP/TLS/BFCP * a=setup:active a=dtls-id:abc3dl a=fingerprint:sha-256 \ 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 mstrm:10 a=floorid:2 mstrm:11 a=bfcpver:2 m=audio 55002 RTP/AVP 0 m=video 55004 RTP/AVP 31 12. Security Considerations The BFCP [I-D.ietf-bfcpbis-rfc4582bis], SDP [RFC4566], and offer/ answer [RFC3264] specifications discuss security issues related to BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145] and [RFC8122] discuss security issues related to the establishment of TCP and TLS connections using an offer/answer model. Furthermore, when using DTLS over UDP, the generic offer/answer considerations defined in [I-D.ietf-mmusic-dtls-sdp] MUST be followed. The usage of certain proto values in the SDP offer/answer negotiation will result in a BFCP stream that is not protected by TLS or DTLS. Operators will need to provide integrity protection and confidentiality protection of the BFCP stream using other means. Camarillo, et al. Expires June 11, 2019 [Page 19] Internet-Draft BFCP December 2018 The generic security considerations associated with SDP attributes are defined in [RFC3264]. While the attributes defined in this specification do not reveal information about the content of individual BFCP controlled media streams, they do reveal which media streams will be BFCP controlled. 13. IANA Considerations [Editorial note: The changes in Section 13.1 instruct the IANA to register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ BFCP for the SDP 'proto' field. The new section Section 5.5 registers a new SDP "bfcpver" attribute. The rest is unchanged from [RFC4582].] 13.1. Registration of SDP 'proto' Values The IANA is requested to register the following values for the SDP 'proto' field under the Session Description Protocol (SDP) Parameters registry: +---------------+------------+ | Value | Reference | +---------------+------------+ | TCP/BFCP | [RFC XXXX] | | TCP/DTLS/BFCP | [RFC XXXX] | | TCP/TLS/BFCP | [RFC XXXX] | | UDP/BFCP | [RFC XXXX] | | UDP/TLS/BFCP | [RFC XXXX] | +---------------+------------+ Table 3: Values for the SDP 'proto' field 13.2. Registration of the SDP 'floorctrl' Attribute This document defines the SDP attribute,'floorctrl'. The details of the attribute are defined in Section 5.1. 13.3. Registration of the SDP 'confid' Attribute This document defines the SDP attribute,'confid'. The details of the attribute are defined in Section 5.2. 13.4. Registration of the SDP 'userid' Attribute This document defines the SDP attribute,'userid'. The details of the attribute are defined in Section 5.3. Camarillo, et al. Expires June 11, 2019 [Page 20] Internet-Draft BFCP December 2018 13.5. Registration of the SDP 'floorid' Attribute This document defines the SDP attribute,'floorid'. The details of the attribute are defined in Section 5.4. 13.6. Registration of the SDP 'bfcpver' Attribute This document defines the SDP attribute,'bfcpver'. The details of the attribute are defined in Section 5.5. 14. Changes from RFC 4583 Following is the list of technical changes and other fixes from [RFC4583]. Main purpose of this work was to add signaling support necessary to support BFCP over unreliable transport, as described in [I-D.ietf-bfcpbis-rfc4582bis], resulting in the following changes: 1. Fields in the 'm' line (Section 4): The section is re-written to remove reference to the exclusivity of TCP as a transport for BFCP streams. The proto field values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 2. Security Considerations (Section 12): For the DTLS over UDP case, mention existing considerations and requirements for the offer/answer exchange in [I-D.ietf-mmusic-dtls-sdp]. 3. Registration of SDP 'proto' Values (Section 13.1): Register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP in the SDP parameters registry. 4. BFCP Version Negotiation (Section 5.5): A new 'bfcpver' SDP media-level attribute is added in order to signal supported version number. In addition to the changes associated with support of BFCP over unreliable transport, the possibility for an endpoint to act as both floor control client and floor control server at the same time has been removed. An endpoint will now take the same role for all BFCP- controlled streams associated with the BFCP stream. Clarification and bug fixes: 1. Errata ID: 712 (Section 3 and Section 10): Camarillo, et al. Expires June 11, 2019 [Page 21] Internet-Draft BFCP December 2018 Language clarification. Don't use terms like an SDP attribute is "used in an 'm' line", instead make clear that the attribute is a media-level attribute. 2. Fix typo in example (Section 11): Do not use 'm-stream' in the SDP example, use the correct 'mstrm' as specified in Section 11. Recommend interpreting 'm-stream' if it is received, since it is present in some implementations. 3. 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. 15. Acknowledgements Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and Oscar Novo provided useful ideas for the original [RFC4583]. The authors also acknowledge contributions to the revision of BFCP for use over an unreliable transport from Geir Arne Sandbakken, Charles Eckel, Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. In the final stages, Roman Shpount made a considerable effort in adding proper ICE support and considerations. 16. References 16.1. Normative References [I-D.ietf-bfcpbis-rfc4582bis] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", draft- ietf-bfcpbis-rfc4582bis-16 (work in progress), November 2015. [I-D.ietf-mmusic-dtls-sdp] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in progress), November 2018. Camarillo, et al. Expires June 11, 2019 [Page 22] Internet-Draft BFCP December 2018 [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, . [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/RFC4574, August 2006, . [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, . [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, DOI 10.17487/RFC4583, November 2006, . Camarillo, et al. Expires June 11, 2019 [Page 23] Internet-Draft BFCP December 2018 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 16.2. Informational 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-53 (work in progress), September 2018. [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, . Authors' Addresses Camarillo, et al. Expires June 11, 2019 [Page 24] Internet-Draft BFCP December 2018 Gonzalo Camarillo Ericsson Hirsalantie 11 FI-02420 Jorvas Finland Email: Gonzalo.Camarillo@ericsson.com Tom Kristensen Cisco Philip Pedersens vei 1 NO-1366 Lysaker Norway Email: tomkrist@cisco.com, tomkri@ifi.uio.no Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Camarillo, et al. Expires June 11, 2019 [Page 25] ./draft-ietf-mmusic-msid-17.txt0000644000764400076440000011224513404421776015624 0ustar iustyiusty Network Working Group H. Alvestrand Internet-Draft Google Intended status: Standards Track December 13, 2018 Expires: June 16, 2019 WebRTC MediaStream Identification in the Session Description Protocol draft-ietf-mmusic-msid-17 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 June 16, 2019. Alvestrand Expires June 16, 2019 [Page 1] Internet-Draft MSID in SDP December 2018 Copyright Notice Copyright (c) 2018 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 . . . . . . . . . . . . 9 3.2.1. Generating the initial offer . . . . . . . . . . . . 9 3.2.2. Answerer processing of the Offer . . . . . . . . . . 9 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 10 3.2.4. Offerer processing of the answer . . . . . . . . . . 10 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 10 3.3. Example SDP description . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.1. Attribute registration in existing registries . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Design considerations, rejected alternatives . . . . 14 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 15 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16 Alvestrand Expires June 16, 2019 [Page 2] Internet-Draft MSID in SDP December 2018 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 17 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 17 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 17 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18 B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18 B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 18 B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 18 B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 18 B.21. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 18 B.22. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 19 B.23. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 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] . Alvestrand Expires June 16, 2019 [Page 3] Internet-Draft MSID in SDP December 2018 Section 1.3 gives the background on why a new mechanism is needed. 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. Alvestrand Expires June 16, 2019 [Page 4] Internet-Draft MSID in SDP December 2018 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. 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. Alvestrand Expires June 16, 2019 [Page 5] Internet-Draft MSID in SDP December 2018 The identifier (msid-id) uniquely identifies a group within the scope of an SDP description. 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 special value "-" indicates "no MediaStream". The value of the "msid-appdata" field in the msid, if present, 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. Alvestrand Expires June 16, 2019 [Page 6] Internet-Draft MSID in SDP December 2018 The following is a high level description of the rules for handling SDP updates. Detailed procedures are in Section 3.2. o When a new msid "identifier" value occurs in a session description, and it is not "-", 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 signal to its application that new MediaStreamTracks have been added, and which MediaStream it has been added to. This is done for each different msid "identifier" value, including the special value "-", which indicates that a MediaStreamTrack has been added with no corresponding MediaStream. o If an msid "identifier" value with no "appdata" value appears, it means that the sender did not inform the recipient of the desired identifier of the MediaStreamTrack, and the recipient will assign the "id" value of the created MediaStreamTrack on its own. All msid in a media section that do not have an "appdata" value are assumed to refer to the same MediaStreamTrack. 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 ended when its msid attribute disappears from the SDP, the track will also be signaled as being ended 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 end 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. Alvestrand Expires June 16, 2019 [Page 7] Internet-Draft MSID in SDP December 2018 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 [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. Alvestrand Expires June 16, 2019 [Page 8] Internet-Draft MSID in SDP December 2018 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 WebIDL "id" attribute of the MediaStream. If the sender wishes to signal identifiers for the MediaStreamTracks, the "appdata" field is set to the WebIDL "id" attribute of the MediaStreamTrack; otherwise it is omitted. 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, if present. o If the "appdata" field exists: 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 If the "appdata" field does not exist, and a MediaStreamTrack is not associated with this media section, create one and associate it with this media section for future use. 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. Alvestrand Expires June 16, 2019 [Page 9] Internet-Draft MSID in SDP December 2018 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". 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. Alvestrand Expires June 16, 2019 [Page 10] Internet-Draft MSID in SDP December 2018 # 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 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 Alvestrand Expires June 16, 2019 [Page 11] Internet-Draft MSID in SDP December 2018 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 [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. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-14 (work in progress), March 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . Alvestrand Expires June 16, 2019 [Page 12] Internet-Draft MSID in SDP December 2018 [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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, 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-29 (work in progress), April 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. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/ RFC5761, April 2010, . Alvestrand Expires June 16, 2019 [Page 13] Internet-Draft MSID in SDP December 2018 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, 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 June 16, 2019 [Page 14] Internet-Draft MSID in SDP December 2018 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 June 16, 2019 [Page 15] Internet-Draft MSID in SDP December 2018 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 June 16, 2019 [Page 16] Internet-Draft MSID in SDP December 2018 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 June 16, 2019 [Page 17] Internet-Draft MSID in SDP December 2018 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 June 16, 2019 [Page 18] Internet-Draft MSID in SDP December 2018 B.22. Changes from -15 to -16 Added the special "-" value that means "no MediaStream". Changed instances of a MediaStreamTrack being "closed" to saying it's "ended", in accordance with WebRTC terminology. B.23. Changes from -16 to -17 Added text to allow omitting track identifiers, per JSEP PR #850 Author's Address Harald Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Alvestrand Expires June 16, 2019 [Page 19] ./draft-ietf-bfd-yang-17.txt0000644000764400076440000043360113330605404015054 0ustar iustyiusty Network Working Group R. Rahman, Ed. Internet-Draft Cisco Systems Intended status: Standards Track L. Zheng, Ed. Expires: February 2, 2019 Huawei Technologies M. Jethanandani, Ed. Xoriant Corporation S. Pallagatti Rtbrick G. Mirsky ZTE Corporation August 1, 2018 YANG Data Model for Bidirectional Forwarding Detection (BFD) draft-ietf-bfd-yang-17 Abstract This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). 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 https://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 2, 2019. Copyright Notice Copyright (c) 2018 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 Rahman, et al. Expires February 2, 2019 [Page 1] Internet-Draft BFD YANG August 2018 (https://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 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 2.1. Design of Configuration Model . . . . . . . . . . . . . . 5 2.1.1. Common BFD configuration parameters . . . . . . . . . 6 2.1.2. Single-hop IP . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Multihop IP . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. MPLS Traffic Engineering Tunnels . . . . . . . . . . 8 2.1.5. MPLS Label Switched Paths . . . . . . . . . . . . . . 9 2.1.6. Link Aggregation Groups . . . . . . . . . . . . . . . 9 2.2. Design of Operational State Model . . . . . . . . . . . . 9 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 10 2.4. RPC Operations . . . . . . . . . . . . . . . . . . . . . 10 2.5. BFD top level hierarchy . . . . . . . . . . . . . . . . . 10 2.6. BFD IP single-hop hierarchy . . . . . . . . . . . . . . . 10 2.7. BFD IP multihop hierarchy . . . . . . . . . . . . . . . . 12 2.8. BFD over LAG hierarchy . . . . . . . . . . . . . . . . . 14 2.9. BFD over MPLS LSPs hierarchy . . . . . . . . . . . . . . 18 2.10. BFD over MPLS-TE hierarchy . . . . . . . . . . . . . . . 20 2.11. Interaction with other YANG modules . . . . . . . . . . . 22 2.11.1. Module ietf-interfaces . . . . . . . . . . . . . . . 22 2.11.2. Module ietf-ip . . . . . . . . . . . . . . . . . . . 22 2.11.3. Module ietf-mpls . . . . . . . . . . . . . . . . . . 23 2.11.4. Module ietf-te . . . . . . . . . . . . . . . . . . . 23 2.12. IANA BFD YANG Module . . . . . . . . . . . . . . . . . . 23 2.13. BFD types YANG Module . . . . . . . . . . . . . . . . . . 26 2.14. BFD top-level YANG Module . . . . . . . . . . . . . . . . 39 2.15. BFD IP single-hop YANG Module . . . . . . . . . . . . . . 41 2.16. BFD IP multihop YANG Module . . . . . . . . . . . . . . . 44 2.17. BFD over LAG YANG Module . . . . . . . . . . . . . . . . 47 2.18. BFD over MPLS YANG Module . . . . . . . . . . . . . . . . 51 2.19. BFD over MPLS-TE YANG Module . . . . . . . . . . . . . . 55 3. Data Model examples . . . . . . . . . . . . . . . . . . . . . 58 3.1. IP single-hop . . . . . . . . . . . . . . . . . . . . . . 58 3.2. IP multihop . . . . . . . . . . . . . . . . . . . . . . . 59 3.3. LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Rahman, et al. Expires February 2, 2019 [Page 2] Internet-Draft BFD YANG August 2018 4. Security Considerations . . . . . . . . . . . . . . . . . . . 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 5.1. IANA-Maintained iana-bfd-types module . . . . . . . . . . 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 70 7.2. Informative References . . . . . . . . . . . . . . . . . 73 Appendix A. Echo function configuration example . . . . . . . . 73 A.1. Example YANG module for BFD echo function configuration . 74 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 76 B.1. Changes between versions -16 and -17 . . . . . . . . . . 76 B.2. Changes between versions -15 and -16 . . . . . . . . . . 76 B.3. Changes between versions -14 and -15 . . . . . . . . . . 76 B.4. Changes between versions -13 and -14 . . . . . . . . . . 76 B.5. Changes between versions -12 and -13 . . . . . . . . . . 76 B.6. Changes between versions -11 and -12 . . . . . . . . . . 76 B.7. Changes between versions -10 and -11 . . . . . . . . . . 76 B.8. Changes between versions -09 and -10 . . . . . . . . . . 77 B.9. Changes between versions -08 and -09 . . . . . . . . . . 77 B.10. Changes between versions -07 and -08 . . . . . . . . . . 77 B.11. Changes between versions -06 and -07 . . . . . . . . . . 77 B.12. Changes between versions -05 and -06 . . . . . . . . . . 77 B.13. Changes between versions -04 and -05 . . . . . . . . . . 78 B.14. Changes between versions -03 and -04 . . . . . . . . . . 78 B.15. Changes between versions -02 and -03 . . . . . . . . . . 78 B.16. Changes between versions -01 and -02 . . . . . . . . . . 78 B.17. Changes between versions -00 and -01 . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 1. Introduction This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD) [RFC5880]. BFD is a network protocol which is used for liveness detection of arbitrary paths between systems. Some examples of different types of paths over which we have BFD: 1) Two systems directly connected via IP. This is known as BFD over single-hop IP, a.k.a. BFD for IPv4 and IPv6 [RFC5881] 2) Two systems connected via multiple hops as described in BFD for Multiple Hops. [RFC5883] 3) Two systems connected via MPLS Label Switched Paths (LSPs) as described in BFD for MPLS LSP [RFC5884] 4) Two systems connected via a Link Aggregation Group (LAG) interface as described in BFD on LAG Interfaces [RFC7130] Rahman, et al. Expires February 2, 2019 [Page 3] Internet-Draft BFD YANG August 2018 5) Two systems connected via pseudowires (PWs), this is known as Virtual Circuit Connectivity Verification (VCCV) as described in BFD for PW VCCV [RFC5885]. This is not addressed in this document. BFD typically does not operate on its own. Various control protocols, also known as BFD clients, use the services provided by BFD for their own operation as described in Generic Application of BFD [RFC5882]. The obvious candidates which use BFD are those which do not have "hellos" to detect failures, e.g. static routes, and routing protocols whose "hellos" do not support sub-second failure detection, e.g. OSPF and IS-IS. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) [RFC8342]. This means that the data models do not have separate top-level or sibling containers for configuration and operational state data. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Tree Diagrams This document uses the graphical representation of data models defined in [RFC8340]. 2. Design of the Data Model Since BFD is used for liveliness detection of various forwarding paths, there is no uniform key to identify a BFD session, and so the BFD data model is split in multiple YANG modules where each module corresponds to one type of forwarding path. For example, BFD for IP single-hop is in one YANG module and BFD for MPLS-TE is in another YANG module. The main difference between these modules is how a BFD session is uniquely identified, i.e the key for the list containing the BFD sessions for that forwarding path. To avoid duplication of BFD definitions, we have common types and groupings which are used by all the modules. A new control-plane protocol "bfdv1" is defined and a "bfd" container is created under control-plane-protocol as specified in "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349]. This new "bfd" container is augmented by all the YANG modules for their respective specific information: Rahman, et al. Expires February 2, 2019 [Page 4] Internet-Draft BFD YANG August 2018 1. ietf-bfd-ip-sh.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "ip-sh" container for BFD sessions over IP single-hop. 2. ietf-bfd-ip-mh.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "ip-mh" container for BFD sessions over IP multi-hop. 3. ietf-bfd-lag.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "lag" container for BFD sessions over LAG. 4. ietf-bfd-mpls.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "mpls" container for BFD over MPLS LSPs. 5. ietf-bfd-mpls-te.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "mpls-te" container for BFD over MPLS-TE. BFD can operate in the following contexts: 1. At the network device level 2. In Logical Network Elements as described in YANG Logical Network Element [I-D.ietf-rtgwg-lne-model] 3. In Network Instances as described in YANG Logical Network Element [I-D.ietf-rtgwg-ni-model] When used at the network device level, the BFD YANG model is used "as-is". When the BFD YANG model is used in a Logical Network Element or in a Network Instance, then the BFD YANG model augments the mounted routing model for the Logical Network Element or the Network Instance. 2.1. Design of Configuration Model The configuration model consists mainly of the parameters specified in BFD [RFC5880]. Some examples are desired minimum transmit interval, required minimum receive interval, detection multiplier, etc BFD clients are applications that use BFD for fast detection of failures. Some implementations have BFD session configuration under the BFD clients. For example, BFD session configuration under routing applications such as OSPF, IS-IS, BGP etc. Other Rahman, et al. Expires February 2, 2019 [Page 5] Internet-Draft BFD YANG August 2018 implementations have BFD session configuration centralized under BFD, i.e. outside the multiple BFD clients. The BFD parameters of interest to a BFD client are mainly the multiplier and interval(s) since those parameters impact the convergence time of the BFD clients when a failure occurs. Other parameters such as BFD authentication are not specific to the requirements of the BFD client. Ideally all configuration should be centralized under BFD. However, this is a problem for clients of BFD which auto-discover their peers. For example, IGPs do not have the peer address configured, instead the IGP is enabled on an interface and the IGP peers are auto-discovered. So for an operator to configure BFD to an IGP peer, the operator would first have to determine the peer addresses. And when a new peer is discovered, BFD configuration would need to be added. To avoid this issue, we define grouping client-cfg-parms in Section 2.13 for BFD clients to configure BFD: this allows BFD clients such as the IGPs to have configuration (multiplier and intervals) for the BFD sessions they need. For example, when a new IGP peer is discovered, the IGP would create a BFD session to the newly discovered peer and similarly when an IGP peer goes away, the IGP would remove the BFD session to that peer. The mechanism how the BFD sessions are created and removed by the BFD clients is outside the scope of this document, but typically this would be done by use of an API implemented by the BFD module on the system. For BFD clients which create BFD sessions via their own configuration, authentication parameters (if required) are still specified in BFD. 2.1.1. Common BFD configuration parameters The basic BFD configuration parameters are: local-multiplier This is the detection time multiplier as defined in BFD [RFC5880]. desired-min-tx-interval This is the Desired Min TX Interval as defined in BFD [RFC5880]. required-min-rx-interval This is the Required Min RX Interval as defined in BFD [RFC5880]. Although BFD [RFC5880] allows for different values for transmit and receive intervals, some implementations allow users to specify just one interval which is used for both transmit and receive intervals or separate values for transmit and receive intervals. The BFD YANG Rahman, et al. Expires February 2, 2019 [Page 6] Internet-Draft BFD YANG August 2018 model supports this: there is a choice between "min-interval", used for both transmit and receive intervals, and "desired-min-tx- interval" and "required-min-rx-interval". This is supported via a grouping which is used by the YANG modules for the various forwarding paths. For BFD authentication we have: key-chain This is a reference to key-chain defined in YANG Data Model for Key Chains [RFC8177]. The keys, cryptographic algorithms, key lifetime etc are all defined in the key-chain model. meticulous This enables meticulous mode as per BFD [RFC5880]. 2.1.2. Single-hop IP For single-hop IP, there is an augment of the "bfd" data node in Section 2. The "ip-sh" node contains a list of IP single-hop sessions where each session is uniquely identified by the interface and destination address pair. For the configuration parameters we use what is defined in Section 2.1.1. The "ip-sh" node also contains a list of interfaces, this is used to specify authentication parameters for BFD sessions which are created by BFD clients, see Section 2.1. [RFC5880] and [RFC5881] do not specify whether echo function is continuous or on demand. Therefore the mechanism used to start and stop echo function is implementation specific and should be done by augmentation: 1) Configuration. This is suitable for continuous echo function. An example is provided in Appendix A. 2) RPC. This is suitable for on-demand echo function. 2.1.3. Multihop IP For multihop IP, there is an augment of the "bfd" data node in Section 2. Because of multiple paths, there could be multiple multihop IP sessions between a source and a destination address. We identify this as a "session-group". The key for each "session-group" consists of: Rahman, et al. Expires February 2, 2019 [Page 7] Internet-Draft BFD YANG August 2018 source address Address belonging to the local system as per BFD for Multiple Hops [RFC5883] destination address Address belonging to the remote system as per BFD for Multiple Hops [RFC5883] For the configuration parameters we use what is defined in Section 2.1.1 Here are some extra parameters: tx-ttl TTL of outgoing BFD control packets. rx-ttl Minimum TTL of incoming BFD control packets. 2.1.4. MPLS Traffic Engineering Tunnels For MPLS-TE tunnels, BFD is configured under the MPLS-TE tunnel since the desired failure detection parameters are a property of the MPLS- TE tunnel. This is achieved by augmenting the MPLS-TE data model in YANG Data Model for TE Topologies [I-D.ietf-teas-yang-te]. For BFD parameters which are specific to the TE application, e.g. whether to tear down the tunnel in the event of a BFD session failure, these parameters will be defined in the YANG model of the MPLS-TE application. On top of the usual BFD parameters, we have the following per MPLS-TE tunnel: encap Encapsulation for the BFD packets: choice between IP, G-ACh and IP with G-ACh as per MPLS Generic Associated Channel [RFC5586] For general MPLS-TE data, "mpls-te" data node is added under the "bfd" node in Section 2. Since some MPLS-TE tunnels are uni- directional there is no MPLS-TE configuration for these tunnels on the egress node (note that this does not apply to bi-directional MPLS-TP tunnels). The BFD parameters for the egress node are added under "mpls-te". Rahman, et al. Expires February 2, 2019 [Page 8] Internet-Draft BFD YANG August 2018 2.1.5. MPLS Label Switched Paths Here we address MPLS LSPs whose FEC is an IP address. The "bfd" node in Section 2 is augmented with "mpls" which contains a list of sessions uniquely identified by an IP prefix. Because of multiple paths, there could be multiple MPLS sessions to an MPLS FEC. We identify this as a "session-group". Since these LSPs are uni-directional there is no LSP configuration on the egress node. The BFD parameters for the egress node are added under "mpls". 2.1.6. Link Aggregation Groups Per BFD on LAG Interfaces [RFC7130], configuring BFD on LAG consists of having micro-BFD sessions on each LAG member link. Since the BFD parameters are an attribute of the LAG, they should be under the LAG. However there is no LAG YANG model which we can augment. So a "lag" data node is added to the "bfd" node in Section 2, the configuration is per-LAG: we have a list of LAGs. The destination IP address of the micro-BFD sessions is configured per-LAG and per address-family (IPv4 and IPv6) 2.2. Design of Operational State Model The operational state model contains both the overall statistics of BFD sessions running on the device and the per session operational information. The overall statistics of BFD sessions consist of number of BFD sessions, number of BFD sessions up etc. This information is available globally (i.e. for all BFD sessions) under the "bfd" node in Section 2 and also per type of forwarding path. For each BFD session, mainly three categories of operational state data are shown. The fundamental information of a BFD session such as the local discriminator, remote discriminator and the capability of supporting demand detect mode are shown in the first category. The second category includes a BFD session running information, e.g. the remote BFD state and the diagnostic code received. Another example is the actual transmit interval between the control packets, which may be different from the desired minimum transmit interval configured, is shown in this category. Similar examples are actual received interval between the control packets and the actual transmit interval between the echo packets. The third category contains the detailed statistics of the session, e.g. when the session transitioned up/down and how long it has been in that state. Rahman, et al. Expires February 2, 2019 [Page 9] Internet-Draft BFD YANG August 2018 For some path types, there may be more than 1 session on the virtual path to the destination. For example, with IP multihop and MPLS LSPs, there could be multiple BFD sessions from the source to the same destination to test the various paths (ECMP) to the destination. This is represented by having multiple "sessions" under each "session-group". 2.3. Notifications This YANG model defines notifications to inform end-users of important events detected during the protocol operation. Pair of local and remote discriminator identifies a BFD session on local system. Notifications also give more important details about BFD sessions; e.g. new state, time in previous state, network-instance and the reason that the BFD session state changed. The notifications are defined for each type of forwarding path but use groupings for common information. 2.4. RPC Operations None. 2.5. BFD top level hierarchy At the "bfd" node under control-plane-protocol, there is no configuration data, only operational state data. The operational state data consist of overall BFD session statistics, i.e. for BFD on all types of forwarding paths. module: ietf-bfd augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw bfd +--ro summary +--ro number-of-sessions? yang:gauge32 +--ro number-of-sessions-up? yang:gauge32 +--ro number-of-sessions-down? yang:gauge32 +--ro number-of-sessions-admin-down? yang:gauge32 2.6. BFD IP single-hop hierarchy An "ip-sh" node is added under "bfd" node in control-plane-protocol. The configuration and operational state data for each BFD IP single- hop session is under this "ip-sh" node. module: ietf-bfd-ip-sh Rahman, et al. Expires February 2, 2019 [Page 10] Internet-Draft BFD YANG August 2018 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw ip-sh +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw sessions | +--rw session* [interface dest-addr] | +--rw interface if:interface-ref | +--rw dest-addr inet:ip-address | +--rw source-addr? inet:ip-address | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw demand-enabled? boolean | | {demand-mode}? | +--rw admin-down? boolean | +--rw authentication! {authentication}? | | +--rw key-chain? kc:key-chain-ref | | +--rw meticulous? boolean | +--ro path-type? identityref | +--ro ip-encapsulation? boolean | +--ro local-discriminator? discriminator | +--ro remote-discriminator? discriminator | +--ro remote-multiplier? multiplier | +--ro demand-capability? boolean | | {demand-mode}? | +--ro source-port? inet:port-number | +--ro dest-port? inet:port-number | +--ro session-running | | +--ro session-index? uint32 | | +--ro local-state? state | | +--ro remote-state? state | | +--ro local-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-authenticated? boolean | | +--ro remote-authentication-type? | | | iana-bfd-types:auth-type {authentication}? | | +--ro detection-mode? enumeration | | +--ro negotiated-tx-interval? uint32 Rahman, et al. Expires February 2, 2019 [Page 11] Internet-Draft BFD YANG August 2018 | | +--ro negotiated-rx-interval? uint32 | | +--ro detection-time? uint32 | | +--ro echo-tx-interval-in-use? uint32 | | {echo-mode}? | +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? yang:counter32 | +--ro admin-down-count? yang:counter32 | +--ro receive-packet-count? yang:counter64 | +--ro send-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? yang:counter64 | +--ro send-failed-packet-count? yang:counter64 +--rw interfaces* [interface] +--rw interface if:interface-ref +--rw authentication! {authentication}? +--rw key-chain? kc:key-chain-ref +--rw meticulous? boolean notifications: +---n singlehop-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro interface? if:interface-ref +--ro echo-enabled? boolean 2.7. BFD IP multihop hierarchy An "ip-mh" node is added under the "bfd" node in cntrol-plane- protocol. The configuration and operational state data for each BFD IP multihop session is under this "ip-mh" node. In the operational state model we support multiple BFD multihop sessions per remote address (ECMP), the local discriminator is used as key. module: ietf-bfd-ip-mh Rahman, et al. Expires February 2, 2019 [Page 12] Internet-Draft BFD YANG August 2018 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw ip-mh +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw session-groups +--rw session-group* [source-addr dest-addr] +--rw source-addr inet:ip-address +--rw dest-addr inet:ip-address +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw tx-ttl? bfd-types:hops +--rw rx-ttl bfd-types:hops +--ro sessions* [] +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type {authentication}? | +--ro detection-mode? enumeration Rahman, et al. Expires February 2, 2019 [Page 13] Internet-Draft BFD YANG August 2018 | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics +--ro create-time? | yang:date-and-time +--ro last-down-time? | yang:date-and-time +--ro last-up-time? | yang:date-and-time +--ro down-count? | yang:counter32 +--ro admin-down-count? | yang:counter32 +--ro receive-packet-count? | yang:counter64 +--ro send-packet-count? | yang:counter64 +--ro receive-invalid-packet-count? | yang:counter64 +--ro send-failed-packet-count? yang:counter64 notifications: +---n multihop-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref 2.8. BFD over LAG hierarchy A "lag" node is added under the "bfd" node in control-plane-protocol. The configuration and operational state data for each BFD LAG session is under this "lag" node. module: ietf-bfd-lag augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw lag Rahman, et al. Expires February 2, 2019 [Page 14] Internet-Draft BFD YANG August 2018 +--rw micro-bfd-ipv4-session-statistics | +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw micro-bfd-ipv6-session-statistics | +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw sessions +--rw session* [lag-name] +--rw lag-name if:interface-ref +--rw ipv4-dest-addr? | inet:ipv4-address +--rw ipv6-dest-addr? | inet:ipv6-address +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw use-ipv4? boolean +--rw use-ipv6? boolean +--ro member-links* [member-link] +--ro member-link if:interface-ref +--ro micro-bfd-ipv4 | +--ro path-type? identityref | +--ro ip-encapsulation? boolean | +--ro local-discriminator? discriminator | +--ro remote-discriminator? discriminator | +--ro remote-multiplier? multiplier | +--ro demand-capability? boolean | | {demand-mode}? | +--ro source-port? inet:port-number | +--ro dest-port? inet:port-number | +--ro session-running | | +--ro session-index? uint32 Rahman, et al. Expires February 2, 2019 [Page 15] Internet-Draft BFD YANG August 2018 | | +--ro local-state? state | | +--ro remote-state? state | | +--ro local-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-authenticated? boolean | | +--ro remote-authentication-type? | | | iana-bfd-types:auth-type | | | {authentication}? | | +--ro detection-mode? enumeration | | +--ro negotiated-tx-interval? uint32 | | +--ro negotiated-rx-interval? uint32 | | +--ro detection-time? uint32 | | +--ro echo-tx-interval-in-use? uint32 | | {echo-mode}? | +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? | | yang:counter32 | +--ro admin-down-count? | | yang:counter32 | +--ro receive-packet-count? | | yang:counter64 | +--ro send-packet-count? | | yang:counter64 | +--ro receive-invalid-packet-count? | | yang:counter64 | +--ro send-failed-packet-count? | yang:counter64 +--ro micro-bfd-ipv6 +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean | {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state Rahman, et al. Expires February 2, 2019 [Page 16] Internet-Draft BFD YANG August 2018 | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type | | {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics +--ro create-time? | yang:date-and-time +--ro last-down-time? | yang:date-and-time +--ro last-up-time? | yang:date-and-time +--ro down-count? | yang:counter32 +--ro admin-down-count? | yang:counter32 +--ro receive-packet-count? | yang:counter64 +--ro send-packet-count? | yang:counter64 +--ro receive-invalid-packet-count? | yang:counter64 +--ro send-failed-packet-count? yang:counter64 notifications: +---n lag-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro lag-name? if:interface-ref +--ro member-link? if:interface-ref Rahman, et al. Expires February 2, 2019 [Page 17] Internet-Draft BFD YANG August 2018 2.9. BFD over MPLS LSPs hierarchy An "mpls" node is added under the "bfd" node in control-plane- protocol. The configuration is per MPLS FEC under this "mpls" node. In the operational state model we support multiple BFD sessions per MPLS FEC (ECMP), the local discriminator is used as key. The "mpls" node can be used in a network device (top-level), or mounted in an LNE or in a network instance. module: ietf-bfd-mpls augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw mpls +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw egress | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw session-groups +--rw session-group* [mpls-fec] +--rw mpls-fec inet:ip-prefix +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--ro sessions* [] Rahman, et al. Expires February 2, 2019 [Page 18] Internet-Draft BFD YANG August 2018 +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? | | yang:counter32 | +--ro admin-down-count? | | yang:counter32 | +--ro receive-packet-count? | | yang:counter64 | +--ro send-packet-count? | | yang:counter64 | +--ro receive-invalid-packet-count? | | yang:counter64 | +--ro send-failed-packet-count? | yang:counter64 +--ro mpls-dest-address? inet:ip-address notifications: +---n mpls-notification Rahman, et al. Expires February 2, 2019 [Page 19] Internet-Draft BFD YANG August 2018 +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro mpls-dest-address? inet:ip-address 2.10. BFD over MPLS-TE hierarchy YANG Data Model for TE Topologies [I-D.ietf-teas-yang-te] is augmented. BFD is configured per MPLS-TE tunnel, and BFD session operational state data is provided per MPLS-TE LSP. module: ietf-bfd-mpls-te augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw mpls-te +--rw egress | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--ro summary +--ro number-of-sessions? yang:gauge32 +--ro number-of-sessions-up? yang:gauge32 +--ro number-of-sessions-down? yang:gauge32 +--ro number-of-sessions-admin-down? yang:gauge32 augment /te:te/te:tunnels/te:tunnel: +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean {demand-mode}? Rahman, et al. Expires February 2, 2019 [Page 20] Internet-Draft BFD YANG August 2018 +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw encap? identityref augment /te:te/te:lsps-state/te:lsp: +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? iana-bfd-types:diagnostic | +--ro remote-diagnostic? iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? iana-bfd-types:auth-type | | {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 {echo-mode}? +--ro session-statistics | +--ro create-time? yang:date-and-time | +--ro last-down-time? yang:date-and-time | +--ro last-up-time? yang:date-and-time | +--ro down-count? yang:counter32 | +--ro admin-down-count? yang:counter32 | +--ro receive-packet-count? yang:counter64 | +--ro send-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? yang:counter64 | +--ro send-failed-packet-count? yang:counter64 +--ro mpls-dest-address? inet:ip-address notifications: +---n mpls-te-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address Rahman, et al. Expires February 2, 2019 [Page 21] Internet-Draft BFD YANG August 2018 +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro mpls-dest-address? inet:ip-address +--ro tunnel-name? string 2.11. Interaction with other YANG modules Generic YANG Data Model for Connectionless OAM protocols [I-D.ietf-lime-yang-connectionless-oam] describes how the LIME connectionless OAM model could be extended to support BFD. Also, the operation of the BFD data model depends on configuration parameters that are defined in other YANG modules. 2.11.1. Module ietf-interfaces The following boolean configuration is defined in A YANG Data Model for Interface Management [RFC8343]: /if:interfaces/if:interface/if:enabled If this configuration is set to "false", no BFD packets can be transmitted or received on that interface. 2.11.2. Module ietf-ip The following boolean configuration is defined in A YANG Data Model for IP Management [RFC8344]: /if:interfaces/if:interface/ip:ipv4/ip:enabled If this configuration is set to "false", no BFD IPv4 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv4/ip:forwarding If this configuration is set to "false", no BFD IPv4 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv6/ip:enabled If this configuration is set to "false", no BFD IPv6 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv6/ip:forwarding If this configuration is set to "false", no BFD IPv6 packets can be transmitted or received on that interface. Rahman, et al. Expires February 2, 2019 [Page 22] Internet-Draft BFD YANG August 2018 2.11.3. Module ietf-mpls The following boolean configuration is defined in A YANG Data Model for MPLS Base [I-D.ietf-mpls-base-yang]: /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled If this configuration is set to "false", no BFD MPLS packets can be transmitted or received on that interface. 2.11.4. Module ietf-te The following configuration is defined in the "ietf-te" YANG module YANG Data Model for TE Topology [I-D.ietf-teas-yang-te]: /ietf-te:te/ietf-te:tunnels/ietf-te:tunnel/ietf-te:config/ietf- te:admin-status If this configuration is not set to "state-up", no BFD MPLS packets can be transmitted or received on that tunnel. 2.12. IANA BFD YANG Module file "iana-bfd-types@2018-08-01.yang" module iana-bfd-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types"; prefix "iana-bfd-types"; organization "IANA"; contact " Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 823 9358 "; description "This module defines YANG data types for IANA-registered BFD parameters. Rahman, et al. Expires February 2, 2019 [Page 23] Internet-Draft BFD YANG August 2018 This YANG module is maintained by IANA and reflects the 'BFD Diagnostic Codes' and 'BFD Authentication Types' registries. Copyright (c) 2018 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 reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: IANA BFD YANG Data Types."; } /* * Type Definitions */ typedef diagnostic { type enumeration { enum none { value 0; description "None"; } enum control-expiry { value 1; description "Control timer expiry"; } enum echo-failed { value 2; description "Echo failure"; } enum neighbor-down { value 3; description "Neighbor down"; } enum forwarding-reset { Rahman, et al. Expires February 2, 2019 [Page 24] Internet-Draft BFD YANG August 2018 value 4; description "Forwarding reset"; } enum path-down { value 5; description "Path down"; } enum concatenated-path-down { value 6; description "Concatenated path down"; } enum admin-down { value 7; description "Admin down"; } enum reverse-concatenated-path-down { value 8; description "Reverse concatenated path down"; } enum mis-connectivity-defect { value 9; description "Mis-connectivity defect as specified in RFC6428"; } } description "BFD diagnostic as defined in RFC 5880, values are maintained in the 'BFD Diagnostic Codes' IANA registry. Range is 0 to 31."; } typedef auth-type { type enumeration { enum reserved { value 0; description "Reserved"; } enum simple-password { value 1; description "Simple password"; } enum keyed-md5 { value 2; description "Keyed MD5"; } enum meticulous-keyed-md5 { value 3; description "Meticulous keyed MD5"; } enum keyed-sha1 { Rahman, et al. Expires February 2, 2019 [Page 25] Internet-Draft BFD YANG August 2018 value 4; description "Keyed SHA1"; } enum meticulous-keyed-sha1 { value 5; description "Meticulous keyed SHA1"; } } description "BFD authentication type as defined in RFC 5880, values are maintained in the 'BFD Authentication Types' IANA registry. Range is 0 to 255."; } } 2.13. BFD types YANG Module This YANG module imports typedefs from [RFC6991], [RFC8177] and the "control-plane-protocol" identity from [RFC8349]. file "ietf-bfd-types@2018-08-01.yang" module ietf-bfd-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types"; prefix "bfd-types"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import iana-bfd-types { prefix "iana-bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; Rahman, et al. Expires February 2, 2019 [Page 26] Internet-Draft BFD YANG August 2018 } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } import ietf-key-chain { prefix "kc"; reference "RFC 8177: YANG Data Model for Key Chains"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains a collection of BFD specific YANG data type definitions, as per RFC 5880, and also groupings which are common to other BFD YANG modules. Copyright (c) 2018 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."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for BFD"; } Rahman, et al. Expires February 2, 2019 [Page 27] Internet-Draft BFD YANG August 2018 /* * Feature definitions */ feature single-minimum-interval { description "This feature indicates that the server supports configuration of one minimum interval value which is used for both transmit and receive minimum intervals."; } feature authentication { description "This feature indicates that the server supports BFD authentication."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), section 6.7."; } feature demand-mode { description "This feature indicates that the server supports BFD demand mode."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), section 6.6."; } feature echo-mode { description "This feature indicates that the server supports BFD echo mode."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), section 6.4."; } /* * Identity definitions */ identity bfdv1 { base "rt:control-plane-protocol"; description "BFD protocol version 1."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)."; } identity path-type { Rahman, et al. Expires February 2, 2019 [Page 28] Internet-Draft BFD YANG August 2018 description "Base identity for BFD path type. The path type indicates the type of path on which BFD is running."; } identity path-ip-sh { base path-type; description "BFD on IP single hop."; reference "RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)."; } identity path-ip-mh { base path-type; description "BFD on IP multihop paths."; reference "RFC 5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths."; } identity path-mpls-te { base path-type; description "BFD on MPLS Traffic Engineering."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)."; } identity path-mpls-lsp { base path-type; description "BFD on MPLS Label Switched Path."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)."; } identity path-lag { base path-type; description "Micro-BFD on LAG member links."; reference "RFC 7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces."; } identity encap-type { description "Base identity for BFD encapsulation type."; } identity encap-ip { Rahman, et al. Expires February 2, 2019 [Page 29] Internet-Draft BFD YANG August 2018 base encap-type; description "BFD with IP encapsulation."; } /* * Type Definitions */ typedef discriminator { type uint32; description "BFD discriminator as described in RFC 5880."; } typedef state { type enumeration { enum adminDown { value 0; description "admindown"; } enum down { value 1; description "down"; } enum init { value 2; description "init"; } enum up { value 3; description "up"; } } description "BFD state as defined in RFC 5880."; } typedef multiplier { type uint8 { range 1..255; } description "BFD multiplier as described in RFC 5880."; } typedef hops { type uint8 { range 1..255; } description "This corresponds to Time To Live for IPv4 and corresponds to hop limit for IPv6."; Rahman, et al. Expires February 2, 2019 [Page 30] Internet-Draft BFD YANG August 2018 } /* * Groupings */ grouping auth-parms { description "Grouping for BFD authentication parameters (see section 6.7 of RFC 5880)."; container authentication { if-feature authentication; presence "Enables BFD authentication (see section 6.7 of RFC 5880)."; description "Parameters for BFD authentication."; leaf key-chain { type kc:key-chain-ref; description "Name of the key-chain as per RFC 8177."; } leaf meticulous { type boolean; description "Enables meticulous mode as described in section 6.7 " + "of RFC 5880."; } } } grouping base-cfg-parms { description "BFD grouping for base config parameters."; leaf local-multiplier { type multiplier; default 3; description "Multiplier transmitted by local system."; } choice interval-config-type { description "Two interval values or one value used for both transmit and receive."; case tx-rx-intervals { leaf desired-min-tx-interval { type uint32; units microseconds; default 1000000; description "Desired minimum transmit interval of control packets."; Rahman, et al. Expires February 2, 2019 [Page 31] Internet-Draft BFD YANG August 2018 } leaf required-min-rx-interval { type uint32; units microseconds; default 1000000; description "Required minimum receive interval of control packets."; } } case single-interval { if-feature single-minimum-interval; leaf min-interval { type uint32; units microseconds; default 1000000; description "Desired minimum transmit interval and required " + "minimum receive interval of control packets."; } } } } grouping client-cfg-parms { description "BFD grouping for configuration parameters used by clients of BFD, e.g. IGP or MPLS."; leaf enable { type boolean; default false; description "Indicates whether the BFD is enabled."; } uses base-cfg-parms; } grouping common-cfg-parms { description "BFD grouping for common configuration parameters."; uses base-cfg-parms; leaf demand-enabled { if-feature demand-mode; type boolean; Rahman, et al. Expires February 2, 2019 [Page 32] Internet-Draft BFD YANG August 2018 default false; description "To enable demand mode."; } leaf admin-down { type boolean; default false; description "Is the BFD session administratively down."; } uses auth-parms; } grouping all-session { description "BFD session operational information"; leaf path-type { type identityref { base path-type; } config "false"; description "BFD path type, this indicates the path type that BFD is running on."; } leaf ip-encapsulation { type boolean; config "false"; description "Whether BFD encapsulation uses IP."; } leaf local-discriminator { type discriminator; config "false"; description "Local discriminator."; } leaf remote-discriminator { type discriminator; config "false"; description "Remote discriminator."; } leaf remote-multiplier { type multiplier; config "false"; description "Remote multiplier."; } leaf demand-capability { if-feature demand-mode; type boolean; Rahman, et al. Expires February 2, 2019 [Page 33] Internet-Draft BFD YANG August 2018 config "false"; description "Local demand mode capability."; } leaf source-port { when "../ip-encapsulation = 'true'" { description "Source port valid only when IP encapsulation is used."; } type inet:port-number; config "false"; description "Source UDP port"; } leaf dest-port { when "../ip-encapsulation = 'true'" { description "Destination port valid only when IP encapsulation is used."; } type inet:port-number; config "false"; description "Destination UDP port."; } container session-running { config "false"; description "BFD session running information."; leaf session-index { type uint32; description "An index used to uniquely identify BFD sessions."; } leaf local-state { type state; description "Local state."; } leaf remote-state { type state; description "Remote state."; } leaf local-diagnostic { type iana-bfd-types:diagnostic; description "Local diagnostic."; } leaf remote-diagnostic { type iana-bfd-types:diagnostic; description "Remote diagnostic."; } leaf remote-authenticated { type boolean; Rahman, et al. Expires February 2, 2019 [Page 34] Internet-Draft BFD YANG August 2018 description "Indicates whether incoming BFD control packets are authenticated."; } leaf remote-authentication-type { when "../remote-authenticated = 'true'" { description "Only valid when incoming BFD control packets are authenticated."; } if-feature authentication; type iana-bfd-types:auth-type; description "Authentication type of incoming BFD control packets."; } leaf detection-mode { type enumeration { enum async-with-echo { value "1"; description "Async with echo."; } enum async-without-echo { value "2"; description "Async without echo."; } enum demand-with-echo { value "3"; description "Demand with echo."; } enum demand-without-echo { value "4"; description "Demand without echo."; } } description "Detection mode."; } leaf negotiated-tx-interval { type uint32; units microseconds; description "Negotiated transmit interval."; } leaf negotiated-rx-interval { type uint32; units microseconds; description "Negotiated receive interval."; } leaf detection-time { type uint32; Rahman, et al. Expires February 2, 2019 [Page 35] Internet-Draft BFD YANG August 2018 units microseconds; description "Detection time."; } leaf echo-tx-interval-in-use { when "../../path-type = 'bfd-types:path-ip-sh'" { description "Echo is supported for IP single-hop only."; } if-feature echo-mode; type uint32; units microseconds; description "Echo transmit interval in use."; } } container session-statistics { config "false"; description "BFD per-session statistics."; leaf create-time { type yang:date-and-time; description "Time and date when this session was created."; } leaf last-down-time { type yang:date-and-time; description "Time and date of last time this session went down."; } leaf last-up-time { type yang:date-and-time; description "Time and date of last time this session went up."; } leaf down-count { type yang:counter32; description "The number of times this session has transitioned in the down state."; } leaf admin-down-count { type yang:counter32; description "The number of times this session has transitioned in the admin-down state."; } leaf receive-packet-count { type yang:counter64; Rahman, et al. Expires February 2, 2019 [Page 36] Internet-Draft BFD YANG August 2018 description "Count of received packets in this session. This includes valid and invalid received packets."; } leaf send-packet-count { type yang:counter64; description "Count of sent packets in this session."; } leaf receive-invalid-packet-count { type yang:counter64; description "Count of invalid received packets in this session."; } leaf send-failed-packet-count { type yang:counter64; description "Count of packets which failed to be sent in this session."; } } } grouping session-statistics-summary { description "Grouping for session statistics summary."; container summary { config false; description "BFD session statistics summary."; leaf number-of-sessions { type yang:gauge32; description "Number of BFD sessions."; } leaf number-of-sessions-up { type yang:gauge32; description "Number of BFD sessions currently in up state (as defined in RFC 5880)."; } leaf number-of-sessions-down { type yang:gauge32; description "Number of BFD sessions currently in down or init state but not admin-down (as defined in RFC 5880)."; } leaf number-of-sessions-admin-down { type yang:gauge32; description "Number of BFD sessions currently in admin-down state (as defined in RFC 5880)."; } Rahman, et al. Expires February 2, 2019 [Page 37] Internet-Draft BFD YANG August 2018 } } grouping notification-parms { description "This group describes common parameters that will be sent " + "as part of BFD notification."; leaf local-discr { type discriminator; description "BFD local discriminator."; } leaf remote-discr { type discriminator; description "BFD remote discriminator."; } leaf new-state { type state; description "Current BFD state."; } leaf state-change-reason { type iana-bfd-types:diagnostic; description "BFD state change reason."; } leaf time-of-last-state-change { type yang:date-and-time; description "Calendar time of previous state change."; } leaf dest-addr { type inet:ip-address; description "BFD peer address."; } leaf source-addr { type inet:ip-address; description "BFD local address."; } leaf session-index { type uint32; description "An index used to uniquely identify BFD sessions."; } Rahman, et al. Expires February 2, 2019 [Page 38] Internet-Draft BFD YANG August 2018 leaf path-type { type identityref { base path-type; } description "BFD path type."; } } } 2.14. BFD top-level YANG Module This YANG module imports and augments "/routing/control-plane- protocols/control-plane-protocol" from [RFC8349]. file "ietf-bfd@2018-08-01.yang" module ietf-bfd { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd"; prefix "bfd"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Rahman, et al. Expires February 2, 2019 [Page 39] Internet-Draft BFD YANG August 2018 Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD parameters as per RFC 5880. Copyright (c) 2018 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."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for BFD"; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" { description "This augmentation is only valid for a control-plane protocol instance of BFD (type 'bfdv1')."; } description "BFD augmentation."; container bfd { description "BFD top level container."; uses bfd-types:session-statistics-summary; } } } Rahman, et al. Expires February 2, 2019 [Page 40] Internet-Draft BFD YANG August 2018 2.15. BFD IP single-hop YANG Module This YANG module imports "interface-ref" from [RFC8343], typedefs from [RFC6991] and augments "/routing/control-plane-protocols/ control-plane-protocol" from [RFC8349]. file "ietf-bfd-ip-sh@2018-08-01.yang" module ietf-bfd-ip-sh { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh"; prefix "bfd-ip-sh"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; Rahman, et al. Expires February 2, 2019 [Page 41] Internet-Draft BFD YANG August 2018 contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD IP single-hop as per RFC 5881. Copyright (c) 2018 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."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD IP single-hop"; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for IP single-hop"; container ip-sh { description "BFD IP single-hop top level container"; uses bfd-types:session-statistics-summary; container sessions { description "BFD IP single-hop sessions."; list session { key "interface dest-addr"; Rahman, et al. Expires February 2, 2019 [Page 42] Internet-Draft BFD YANG August 2018 description "List of IP single-hop sessions."; leaf interface { type if:interface-ref; description "Interface on which the BFD session is running."; } leaf dest-addr { type inet:ip-address; description "IP address of the peer."; } leaf source-addr { type inet:ip-address; description "Local IP address."; } uses bfd-types:common-cfg-parms; uses bfd-types:all-session; } } list interfaces { key "interface"; description "List of interfaces."; leaf interface { type if:interface-ref; description "BFD information for this interface."; } uses bfd-types:auth-parms; } } } /* * Notifications */ notification singlehop-notification { description "Notification for BFD single-hop session state change. An " + "implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; leaf interface { type if:interface-ref; description "Interface to which this BFD session belongs to."; Rahman, et al. Expires February 2, 2019 [Page 43] Internet-Draft BFD YANG August 2018 } leaf echo-enabled { type boolean; description "Was echo enabled for BFD."; } } } 2.16. BFD IP multihop YANG Module This YANG module imports typedefs from [RFC6991] and augments "/routing/control-plane-protocols/control-plane-protocol" from [RFC8349]. file "ietf-bfd-ip-mh@2018-08-01.yang" module ietf-bfd-ip-mh { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh"; prefix "bfd-ip-mh"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; Rahman, et al. Expires February 2, 2019 [Page 44] Internet-Draft BFD YANG August 2018 reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD IP multi-hop as per RFC 5883. Copyright (c) 2018 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."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD IP multihop."; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for IP multihop."; container ip-mh { description "BFD IP multihop top level container."; Rahman, et al. Expires February 2, 2019 [Page 45] Internet-Draft BFD YANG August 2018 uses bfd-types:session-statistics-summary; container session-groups { description "BFD IP multi-hop session groups."; list session-group { key "source-addr dest-addr"; description "Group of BFD IP multi-hop sessions (for ECMP). A " + "group of sessions is between 1 source and 1 " + "destination, each session has a different field " + "in UDP/IP hdr for ECMP."; leaf source-addr { type inet:ip-address; description "Local IP address."; } leaf dest-addr { type inet:ip-address; description "IP address of the peer."; } uses bfd-types:common-cfg-parms; leaf tx-ttl { type bfd-types:hops; default 255; description "Hop count of outgoing BFD control packets."; } leaf rx-ttl { type bfd-types:hops; mandatory true; description "Minimum allowed hop count value for incoming BFD control packets. Control packets whose hop count is lower than this value are dropped."; } list sessions { config false; description "The multiple BFD sessions between a source and a " + "destination."; uses bfd-types:all-session; } } } } Rahman, et al. Expires February 2, 2019 [Page 46] Internet-Draft BFD YANG August 2018 } /* * Notifications */ notification multihop-notification { description "Notification for BFD multi-hop session state change. An " + "implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; } } 2.17. BFD over LAG YANG Module This YANG module imports "interface-ref" from [RFC8343], typedefs from [RFC6991] and augments "/routing/control-plane-protocols/ control-plane-protocol" from [RFC8349]. file "ietf-bfd-lag@2018-08-01.yang" module ietf-bfd-lag { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-lag"; prefix "bfd-lag"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-interfaces { prefix "if"; Rahman, et al. Expires February 2, 2019 [Page 47] Internet-Draft BFD YANG August 2018 reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD over LAG interfaces as per RFC7130. Copyright (c) 2018 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."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD over LAG"; Rahman, et al. Expires February 2, 2019 [Page 48] Internet-Draft BFD YANG August 2018 } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for LAG"; container lag { description "BFD over LAG top level container"; container micro-bfd-ipv4-session-statistics { description "Micro-BFD IPv4 session counters."; uses bfd-types:session-statistics-summary; } container micro-bfd-ipv6-session-statistics { description "Micro-BFD IPv6 session counters."; uses bfd-types:session-statistics-summary; } container sessions { description "BFD over LAG sessions"; list session { key "lag-name"; description "List of BFD over LAG sessions."; leaf lag-name { type if:interface-ref ; description "Name of the LAG"; } leaf ipv4-dest-addr { type inet:ipv4-address; description "IPv4 address of the peer, for IPv4 micro-BFD."; } leaf ipv6-dest-addr { type inet:ipv6-address; description "IPv6 address of the peer, for IPv6 micro-BFD."; } uses bfd-types:common-cfg-parms; leaf use-ipv4 { type boolean; description "Using IPv4 micro-BFD."; } leaf use-ipv6 { type boolean; Rahman, et al. Expires February 2, 2019 [Page 49] Internet-Draft BFD YANG August 2018 description "Using IPv6 micro-BFD."; } list member-links { key "member-link"; config false; description "Micro-BFD over LAG. This represents one member link."; leaf member-link { type if:interface-ref; description "Member link on which micro-BFD is running."; } container micro-bfd-ipv4 { when "../../use-ipv4 = 'true'" { description "Needed only if IPv4 is used."; } description "Micro-BFD IPv4 session state on member link."; uses bfd-types:all-session; } container micro-bfd-ipv6 { when "../../use-ipv6 = 'true'" { description "Needed only if IPv6 is used."; } description "Micro-BFD IPv6 session state on member link."; uses bfd-types:all-session; } } } } } } /* * Notifications */ notification lag-notification { description "Notification for BFD over LAG session state change. " + "An implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; leaf lag-name { Rahman, et al. Expires February 2, 2019 [Page 50] Internet-Draft BFD YANG August 2018 type if:interface-ref; description "LAG interface name."; } leaf member-link { type if:interface-ref; description "Member link on which BFD is running."; } } } 2.18. BFD over MPLS YANG Module This YANG module imports typedefs from [RFC6991] and augments "/routing/control-plane-protocols/control-plane-protocol" from [RFC8349]. file "ietf-bfd-mpls@2018-08-01.yang" module ietf-bfd-mpls { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls"; prefix "bfd-mpls"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { Rahman, et al. Expires February 2, 2019 [Page 51] Internet-Draft BFD YANG August 2018 prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD parameters for MPLS LSPs as per RFC 5884. Copyright (c) 2018 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."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD over MPLS LSPs"; } /* * Identity definitions */ identity encap-gach { base bfd-types:encap-type; description "BFD with G-ACh encapsulation as per RFC 5586."; } Rahman, et al. Expires February 2, 2019 [Page 52] Internet-Draft BFD YANG August 2018 identity encap-ip-gach { base bfd-types:encap-type; description "BFD with IP and G-ACh encapsulation as per RFC 5586."; } /* * Groupings */ grouping encap-cfg { description "Configuration for BFD encapsulation"; leaf encap { type identityref { base bfd-types:encap-type; } default bfd-types:encap-ip; description "BFD encapsulation"; } } grouping mpls-dest-address { description "Destination address as per RFC 5884."; leaf mpls-dest-address { type inet:ip-address; config "false"; description "Destination address as per RFC 5884. Needed if IP encapsulation is used."; } } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for MPLS."; container mpls { description "BFD MPLS top level container."; uses bfd-types:session-statistics-summary; container egress { description "Egress configuration."; uses bfd-types:client-cfg-parms; Rahman, et al. Expires February 2, 2019 [Page 53] Internet-Draft BFD YANG August 2018 uses bfd-types:auth-parms; } container session-groups { description "BFD over MPLS session groups."; list session-group { key "mpls-fec"; description "Group of BFD MPLS sessions (for ECMP). A group of " + "sessions is for 1 FEC, each session has a different " + "field in UDP/IP hdr for ECMP."; leaf mpls-fec { type inet:ip-prefix; description "MPLS FEC."; } uses bfd-types:common-cfg-parms; list sessions { config false; description "The BFD sessions for an MPLS FEC. Local " + "discriminator is unique for each session in the " + "group."; uses bfd-types:all-session; uses bfd-mpls:mpls-dest-address; } } } } } /* * Notifications */ notification mpls-notification { description "Notification for BFD over MPLS FEC session state change. " + "An implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; leaf mpls-dest-address { type inet:ip-address; description Rahman, et al. Expires February 2, 2019 [Page 54] Internet-Draft BFD YANG August 2018 "Destination address as per RFC 5884. Needed if IP encapsulation is used."; } } } 2.19. BFD over MPLS-TE YANG Module This YANG module imports and augments "/te/tunnels/tunnel" from [I-D.ietf-teas-yang-te]. file "ietf-bfd-mpls-te@2018-08-01.yang" module ietf-bfd-mpls-te { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te"; prefix "bfd-mpls-te"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd-mpls { prefix "bfd-mpls"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-te { prefix "te"; // RFC Ed.: replace YYYY with actual RFC number of // draft-ietf-teas-yang-te and remove this note. reference "RFC YYYY: A YANG Data Model for Traffic Engineering Tunnels and Interfaces"; Rahman, et al. Expires February 2, 2019 [Page 55] Internet-Draft BFD YANG August 2018 } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD parameters for MPLS Traffic Engineering as per RFC 5884. Copyright (c) 2018 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."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD over MPLS-TE"; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { Rahman, et al. Expires February 2, 2019 [Page 56] Internet-Draft BFD YANG August 2018 description "BFD augmentation for MPLS-TE."; container mpls-te { description "BFD MPLS-TE top level container."; container egress { description "Egress configuration."; uses bfd-types:client-cfg-parms; uses bfd-types:auth-parms; } uses bfd-types:session-statistics-summary; } } augment "/te:te/te:tunnels/te:tunnel" { description "BFD configuration on MPLS-TE tunnel."; uses bfd-types:common-cfg-parms; uses bfd-mpls:encap-cfg; } augment "/te:te/te:lsps-state/te:lsp" { when "/te:te/te:lsps-state/te:lsp/te:origin-type != 'transit'" { description "BFD information not needed at transit points."; } description "BFD state information on MPLS-TE LSP."; uses bfd-types:all-session; uses bfd-mpls:mpls-dest-address; } /* * Notifications */ notification mpls-te-notification { description "Notification for BFD over MPLS-TE session state change. " + "An implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; uses bfd-mpls:mpls-dest-address; Rahman, et al. Expires February 2, 2019 [Page 57] Internet-Draft BFD YANG August 2018 leaf tunnel-name { type string; description "MPLS-TE tunnel on which BFD was running."; } } } 3. Data Model examples This section presents some simple and illustrative examples on how to configure BFD. 3.1. IP single-hop The following is an example configuration for a BFD IP single-hop session. The desired transmit interval and the required receive interval are both set to 10ms. Rahman, et al. Expires February 2, 2019 [Page 58] Internet-Draft BFD YANG August 2018 eth0 ianaift:ethernetCsmacd bfd-types:bfdv1 name:BFD eth0 2001:db8:0:113::101 10000 10000 3.2. IP multihop The following is an example configuration for a BFD IP multihop session group. The desired transmit interval and the required receive interval are both set to 150ms. Rahman, et al. Expires February 2, 2019 [Page 59] Internet-Draft BFD YANG August 2018 bfd-types:bfdv1 name:BFD 2001:db8:0:113::103 2001:db8:0:114::100 150000 150000 240 3.3. LAG The following is an example of BFD configuration for a LAG session. In this case, an interface named "Bundle-Ether1" of interface type "ieee802eadLag" has a desired transmit and required receive interval set to 10ms. Rahman, et al. Expires February 2, 2019 [Page 60] Internet-Draft BFD YANG August 2018 Bundle-Ether1 ianaift:ieee8023adLag bfd-types:bfdv1 name:BFD Bundle-Ether1 2001:db8:112::16 100000 100000 true 3.4. MPLS The following is an example of BFD configured for an MPLS LSP. In this case, the desired transmit and required receive interval set to 250ms. Rahman, et al. Expires February 2, 2019 [Page 61] Internet-Draft BFD YANG August 2018 bfd-types:bfdv1 name:BFD 2001:db8:114::/116 250000 250000 4. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the Rahman, et al. Expires February 2, 2019 [Page 62] Internet-Draft BFD YANG August 2018 default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ sessions: the list specifies the IP single-hop BFD sessions. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ sessions: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD IP single-hop session. The source-addr and dest-addr data nodes can be used to send BFD packets to unwitting recipients, [RFC5880] describes how BFD mitigates against such threats. Authentication data nodes key-chain and meticulous impact the security of the BFD IP single-hop session. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-group: the list specifies the IP multi-hop BFD session groups. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-group: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD IP multi-hop session. The source-addr and dest-addr data nodes can be used to send BFD packets to unwitting recipients, [RFC5880] describes how BFD mitigates against such threats. Authentication data nodes key-chain and meticulous impact the security of the BFD IP multi-hop session. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ sessions: the list specifies the BFD sessions over LAG. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ sessions: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD over LAG session. The ipv4-dest-addr and ipv6-dest-addr data nodes can be used to send BFD packets to unwitting recipients, [RFC5880] describes how BFD mitigates against such threats. Authentication data nodes key-chain and meticulous impact the security of the BFD over LAG session. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-group: the list specifies the session groups for BFD over MPLS. Rahman, et al. Expires February 2, 2019 [Page 63] Internet-Draft BFD YANG August 2018 /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-group: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval, and min-interval all impact the BFD over MPLS LSPs session. Authentication data nodes key-chain and meticulous impact the security of the BFD over MPLS LSPs session. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ egress: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD over MPLS LSPs sessions for which this device is an MPLS LSP egress node. Authentication data nodes key-chain and meticulous impact the security of the BFD over MPLS LSPs sessions for which this device is an MPLS LSP egress node /te/tunnels/tunnel: data nodes local-multiplier, desired-min-tx- interval, required-min-rx-interval and min-interval all impact the BFD session over the MPLS-TE tunnel. Authentication data nodes key- chain and meticulous impact the security of the BFD session over the MPLS-TE tunnel. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls-te/ egress: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD over MPLS-TE sessions for which this device is an MPLS-TE egress node. Authentication data nodes key-chain and meticulous impact the security of the BFD over MPLS-TE sessions for which this device is an MPLS-TE egress node. The YANG module has writeable data nodes which can be used for creation of BFD sessions and modification of BFD session parameters. The system should "police" creation of BFD sessions to prevent new sessions from causing existing BFD sessions to fail. For BFD session modification, the BFD protocol has mechanisms in place which allow for in service modification. When BFD clients are used to modify BFD configuration (as described in Section 2.1), the BFD clients need to be included in an analysis of the security properties of the BFD-using system (e.g., when considering the authentication and authorization of control actions). In many cases, BFD is not the most vulnerable portion of such a composite system, since BFD is limited to generating well-defined traffic at a fixed rate on a given path; in the case of an IGP as BFD client, attacking the IGP could cause more broad-scale disruption than (de)configuring a BFD session could cause. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or Rahman, et al. Expires February 2, 2019 [Page 64] Internet-Draft BFD YANG August 2018 notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ summary: access to this information discloses the number of BFD IP single-hop sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane-protocol/bfd/ip- sh/sessions/session/: access to data nodes local-discriminator and remote-discriminator (combined with the data nodes in the authentication container) provides the ability to spoof BFD IP single-hop packets. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ summary: access to this information discloses the number of BFD IP multi-hop sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-groups/session-group/sessions: access to data nodes local- discriminator and remote-discriminator (combined with the data nodes in the session-group's authentication container) provides the ability to spoof BFD IP multi-hop packets. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ micro-bfd-ipv4-session-statistics/summary: access to this information discloses the number of micro BFD IPv4 LAG sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane- protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd- ipv4: access to data nodes local-discriminator and remote- discriminator (combined with the data nodes in the session's authentication container) provides the ability to spoof BFD IPv4 LAG packets. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ micro-bfd-ipv6-session-statistics/summary: access to this information discloses the number of micro BFD IPv6 LAG sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane- protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd- ipv6: access to data nodes local-discriminator and remote- discriminator (combined with the data nodes in the session's Rahman, et al. Expires February 2, 2019 [Page 65] Internet-Draft BFD YANG August 2018 authentication container) provides the ability to spoof BFD IPv6 LAG packets. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ summary: access to this information discloses the number of BFD sessions over MPLS LSPs which are up, down and admin-down. The counters include BFD sessions for which the user does not have read- access. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-groups/session-group/sessions: access to data nodes local- discriminator and remote-discriminator (combined with the data nodes in the session-group's authentication container) provides the ability to spoof BFD over MPLS LSPs packets. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls-te/ summary: access to this information discloses the number of BFD sessions over MPLS-TE which are up, down and admin-down. The counters include BFD sessions for which the user does not have read- access. /te/lsps-state/lsp: access to data nodes local-discriminator and remote-discriminator (combined with the data nodes in the tunnel's authentication container) provides the ability to spoof BFD over MPLS-TE packets. 5. IANA Considerations This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:iana-bfd-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. Rahman, et al. Expires February 2, 2019 [Page 66] Internet-Draft BFD YANG August 2018 -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mh Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-lag Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls Registrant Contact: The IESG. Rahman, et al. Expires February 2, 2019 [Page 67] Internet-Draft BFD YANG August 2018 XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document registers the following YANG modules in the YANG Module Names registry [RFC6020]: RFC Editor: Replace RFC XXXX with actual RFC number and remove this note. -------------------------------------------------------------------- Name: iana-bfd-types Namespace: urn:ietf:params:xml:ns:yang:iana-bfd-types Prefix: iana-bfd-types Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-types Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-types Prefix: bfd-types Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd Rahman, et al. Expires February 2, 2019 [Page 68] Internet-Draft BFD YANG August 2018 Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd Prefix: bfd Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-ip-sh Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh Prefix: bfd-ip-sh Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-ip-mh Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh Prefix: bfd-ip-mh Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-lag Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-lag Prefix: bfd-lag Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-mpls Rahman, et al. Expires February 2, 2019 [Page 69] Internet-Draft BFD YANG August 2018 Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls Prefix: bfd-mpls Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-mpls-te Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te Prefix: bfd-mpls-te Reference: RFC XXXX -------------------------------------------------------------------- 5.1. IANA-Maintained iana-bfd-types module This document defines the initial version of the IANA-maintained iana-bfd-types YANG module. The iana-bfd-types YANG module mirrors the "BFD Diagnostic Codes" registry and "BFD Authentication Types" registry at https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml. Whenever that registry changes, IANA must update the iana-bfd-types YANG module. 6. Acknowledgements We would also like to thank Nobo Akiya and Jeff Haas for their encouragement on this work. We would also like to thank Rakesh Gandhi and Tarek Saad for their help on the MPLS-TE model. We would also like to thank Acee Lindem for his guidance. 7. References 7.1. Normative References [I-D.ietf-mpls-base-yang] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", draft-ietf-mpls-base- yang-06 (work in progress), February 2018. Rahman, et al. Expires February 2, 2019 [Page 70] Internet-Draft BFD YANG August 2018 [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work in progress), July 2018. [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, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, DOI 10.17487/RFC5882, June 2010, . [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, . [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, . Rahman, et al. Expires February 2, 2019 [Page 71] Internet-Draft BFD YANG August 2018 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [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, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", RFC 7130, DOI 10.17487/RFC7130, February 2014, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . Rahman, et al. Expires February 2, 2019 [Page 72] Internet-Draft BFD YANG August 2018 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . 7.2. Informative References [I-D.ietf-lime-yang-connectionless-oam] Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications", draft-ietf-lime-yang- connectionless-oam-18 (work in progress), November 2017. [I-D.ietf-rtgwg-lne-model] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", draft- ietf-rtgwg-lne-model-10 (work in progress), March 2018. [I-D.ietf-rtgwg-ni-model] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Network Instances", draft-ietf-rtgwg- ni-model-12 (work in progress), March 2018. [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Appendix A. Echo function configuration example As mentioned in Section 2.1.2, the mechanism to start and stop the echo function, as defined in [RFC5880] and [RFC5881], is implementation specific. In this section we provide an example of how the echo function can be implemented via configuration. Rahman, et al. Expires February 2, 2019 [Page 73] Internet-Draft BFD YANG August 2018 module: example-bfd-echo augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /bfd-ip-sh:sessions: +--rw echo {bfd-types:echo-mode}? +--rw desired-min-echo-tx-interval? uint32 +--rw required-min-echo-rx-interval? uint32 A.1. Example YANG module for BFD echo function configuration module example-bfd-echo { namespace "tag:example.com,2018:example-bfd-echo"; prefix "example-bfd-echo"; import ietf-bfd-types { prefix "bfd-types"; } import ietf-bfd { prefix "bfd"; } import ietf-bfd-ip-sh { prefix "bfd-ip-sh"; } import ietf-routing { prefix "rt"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains an example YANG augmentation for configuration of BFD echo function. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Rahman, et al. Expires February 2, 2019 [Page 74] Internet-Draft BFD YANG August 2018 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."; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model example augmentation for BFD echo function"; } // RFC Ed.: replace XXXX with actual RFC number and remove this // note /* * Groupings */ grouping echo-cfg-parms { description "BFD grouping for echo config parameters"; leaf desired-min-echo-tx-interval { type uint32; units microseconds; default 0; description "This is the minimum interval that the local system would like to use when transmitting BFD echo packets. If 0, the echo function as defined in BFD [RFC5880] is disabled."; } leaf required-min-echo-rx-interval { type uint32; units microseconds; default 0; description "This is the Required Min Echo RX Interval as defined in BFD [RFC5880]."; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "bfd-ip-sh:sessions" { Rahman, et al. Expires February 2, 2019 [Page 75] Internet-Draft BFD YANG August 2018 description "Augmentation for BFD echo function."; container echo { if-feature bfd-types:echo-mode; description "BFD echo function container"; uses echo-cfg-parms; } } } Appendix B. Change log RFC Editor: Remove this section upon publication as an RFC. B.1. Changes between versions -16 and -17 o Addressed IESG comments. B.2. Changes between versions -15 and -16 o Added list of modules for YANG module registry. B.3. Changes between versions -14 and -15 o Added missing ietf-bfd-types in XML registry. B.4. Changes between versions -13 and -14 o Addressed missing/incorrect references in import statements. B.5. Changes between versions -12 and -13 o Updated references for drafts which became RFCs recently. B.6. Changes between versions -11 and -12 o Addressed comments from YANG Doctor review of rev11. B.7. Changes between versions -10 and -11 o Added 2 examples. o Added a container around some lists. o Fixed some indentation nits. Rahman, et al. Expires February 2, 2019 [Page 76] Internet-Draft BFD YANG August 2018 B.8. Changes between versions -09 and -10 o Addressed comments from YANG Doctor review. o Addressed comments from WGLC. B.9. Changes between versions -08 and -09 o Mostly cosmetic changes to abide by draft-ietf-netmod-rfc6087bis. o Specified yang-version 1.1. o Added data model examples. o Some minor changes. B.10. Changes between versions -07 and -08 o Timer intervals in client-cfg-parms are not mandatory anymore. o Added list of interfaces under "ip-sh" node for authentication parameters. o Renamed replay-protection to meticulous. B.11. Changes between versions -06 and -07 o New ietf-bfd-types module. o Grouping for BFD clients to have BFD multiplier and interval values. o Change in ietf-bfd-mpls-te since MPLS-TE model changed. o Removed bfd- prefix from many names. B.12. Changes between versions -05 and -06 o Adhere to NMDA-guidelines. o Echo function config moved to appendix as example. o Added IANA YANG modules. o Addressed various comments. Rahman, et al. Expires February 2, 2019 [Page 77] Internet-Draft BFD YANG August 2018 B.13. Changes between versions -04 and -05 o "bfd" node in augment of control-plane-protocol. o Removed augment of network-instance. Replaced by schema-mount. o Added information on interaction with other YANG modules. B.14. Changes between versions -03 and -04 o Updated author information. o Fixed YANG compile error in ietf-bfd-lag.yang which was due to incorrect when statement. B.15. Changes between versions -02 and -03 o Fixed YANG compilation warning due to incorrect revision date in ietf-bfd-ip-sh module. B.16. Changes between versions -01 and -02 o Replace routing-instance with network-instance from YANG Network Instances [I-D.ietf-rtgwg-ni-model] B.17. Changes between versions -00 and -01 o Remove BFD configuration parameters from BFD clients, all BFD configuration parameters in BFD o YANG module split in multiple YANG modules (one per type of forwarding path) o For BFD over MPLS-TE we augment MPLS-TE model o For BFD authentication we now use YANG Data Model for Key Chains [RFC8177] Authors' Addresses Reshad Rahman (editor) Cisco Systems Canada Email: rrahman@cisco.com Rahman, et al. Expires February 2, 2019 [Page 78] Internet-Draft BFD YANG August 2018 Lianshu Zheng (editor) Huawei Technologies China Email: vero.zheng@huawei.com Mahesh Jethanandani (editor) Xoriant Corporation 1248 Reamwood Ave Sunnyvale, California 94089 USA Email: mjethanandani@gmail.com Santosh Pallagatti Rtbrick India Email: santosh.pallagatti@gmail.com Greg Mirsky ZTE Corporation Email: gregimirsky@gmail.com Rahman, et al. Expires February 2, 2019 [Page 79] ./draft-ietf-isis-yang-isis-cfg-42.txt0000644000764400076440000063512213551431773017005 0ustar iustyiusty IS-IS Working Group S. Litkowski Internet-Draft Cisco Systems Intended status: Standards Track D. Yeung Expires: April 17, 2020 Arrcus, Inc A. Lindem Cisco Systems J. Zhang Juniper Networks L. Lhotka CZ.NIC October 15, 2019 YANG Data Model for IS-IS Protocol draft-ietf-isis-yang-isis-cfg-42 Abstract This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 https://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, 2020. Litkowski, et al. Expires April 17, 2020 [Page 1] Internet-Draft isis-cfg October 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 2.1. IS-IS Configuration . . . . . . . . . . . . . . . . . . . 9 2.2. Multi-topology Parameters . . . . . . . . . . . . . . . . 10 2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10 2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 12 2.5. Authentication Parameters . . . . . . . . . . . . . . . . 19 2.6. IGP/LDP synchronization . . . . . . . . . . . . . . . . . 19 2.7. ISO parameters . . . . . . . . . . . . . . . . . . . . . 20 2.8. IP FRR . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.9. Operational States . . . . . . . . . . . . . . . . . . . 20 3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 21 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Interaction with Other YANG Modules . . . . . . . . . . . . . 22 6. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 108 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 110 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 110 11.2. Informative References . . . . . . . . . . . . . . . . . 115 Appendix A. Example of IS-IS configuration in XML . . . . . . . 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 1. Introduction This document defines a YANG [RFC7950] data model for IS-IS routing protocol. Litkowski, et al. Expires April 17, 2020 [Page 2] Internet-Draft isis-cfg October 2019 The data model covers configuration of an IS-IS routing protocol instance, as well as, the retrieval of IS-IS operational states. A simplified tree representation of the data model is presented in Section 2. Tree diagrams used in this document follow the notation defined in [RFC8340]. The module is designed as per the NMDA (Network Management Datastore Architecture) [RFC8342]. 2. Design of the Data Model The IS-IS YANG module augments the "control-plane-protocol" list in the ietf-routing module [RFC8349] with specific IS-IS parameters. The figure below describes the overall structure of the ietf-isis YANG module: module: ietf-isis augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: +--ro metric? uint32 +--ro tag* uint64 +--ro route-type? enumeration augment /if:interfaces/if:interface: +--rw clns-mtu? uint16 {osi-interface}? augment /rt:routing/rt:control-plane-protocols/rt: control-plane-protocol: +--rw isis +--rw enable? boolean {admin-control}? +--rw level-type? level +--rw system-id? system-id +--rw maximum-area-addresses? uint8 {maximum-area-addresses}? +--rw area-address* area-address +--rw lsp-mtu? uint16 +--rw lsp-lifetime? uint16 +--rw lsp-refresh? rt-types:timer-value-seconds16 | {lsp-refresh}? +--rw poi-tlv? boolean {poi-tlv}? +--rw graceful-restart {graceful-restart}? | +--rw enable? boolean | +--rw restart-interval? rt-types:timer-value-seconds16 | +--rw helper-enable? boolean +--rw nsr {nsr}? | +--rw enable? boolean +--rw node-tags {node-tag}? | +--rw node-tag* [tag] | ... Litkowski, et al. Expires April 17, 2020 [Page 3] Internet-Draft isis-cfg October 2019 +--rw metric-type | +--rw value? enumeration | +--rw level-1 | | ... | +--rw level-2 | ... +--rw default-metric | +--rw value? wide-metric | +--rw level-1 | | ... | +--rw level-2 | ... +--rw auto-cost {auto-cost}? | +--rw enable? boolean | +--rw reference-bandwidth? uint32 +--rw authentication | +--rw (authentication-type)? | | ... | +--rw level-1 | | ... | +--rw level-2 | ... +--rw address-families {nlpid-control}? | +--rw address-family-list* [address-family] | ... +--rw mpls | +--rw te-rid {te-rid}? | | ... | +--rw ldp | ... +--rw spf-control | +--rw paths? uint16 {max-ecmp}? | +--rw ietf-spf-delay {ietf-spf-delay}? | ... +--rw fast-reroute {fast-reroute}? | +--rw lfa {lfa}? +--rw preference | +--rw (granularity)? | ... +--rw overload | +--rw status? boolean +--rw overload-max-metric {overload-max-metric}? | +--rw timeout? rt-types:timer-value-seconds16 +--ro spf-log | +--ro event* [id] | ... +--ro lsp-log | +--ro event* [id] Litkowski, et al. Expires April 17, 2020 [Page 4] Internet-Draft isis-cfg October 2019 | ... +--ro hostnames | +--ro hostname* [system-id] | ... +--ro database | +--ro levels* [level] | ... +--ro local-rib | +--ro route* [prefix] | ... +--ro system-counters | +--ro level* [level] | ... +--ro protected-routes | +--ro address-family-stats* [address-family prefix alternate] | ... +--ro unprotected-routes | +--ro prefixes* [address-family prefix] | ... +--ro protection-statistics* [frr-protection-method] | +--ro frr-protection-method identityref | +--ro address-family-stats* [address-family] | ... +--rw discontinuity-time? yang:date-and-time +--rw topologies {multi-topology}? | +--rw topology* [name] | ... +--rw interfaces +--rw interface* [name] ... rpcs: +---x clear-adjacency | +---w input | +---w routing-protocol-instance-name -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +---w level? level | +---w interface? if:interface-ref +---x clear-database +---w input +---w routing-protocol-instance-name -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +---w level? level notifications: +---n database-overload Litkowski, et al. Expires April 17, 2020 [Page 5] Internet-Draft isis-cfg October 2019 | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro overload? enumeration +---n lsp-too-large | +--ro routing-protocol-name? -> /rt:routing/ | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-size? uint32 | +--ro lsp-id? lsp-id +---n if-state-change | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro state? if-state-type +---n corrupted-lsp-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n attempt-to-exceed-max-sequence | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n id-len-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-field-len? uint8 | +--ro raw-pdu? binary +---n max-area-addresses-mismatch | +--ro routing-protocol-name? -> /rt:routing/ Litkowski, et al. Expires April 17, 2020 [Page 6] Internet-Draft isis-cfg October 2019 | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro max-area-addresses? uint8 | +--ro raw-pdu? binary +---n own-lsp-purge | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n sequence-number-skipped | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n authentication-type-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n authentication-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n version-skew | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name Litkowski, et al. Expires April 17, 2020 [Page 7] Internet-Draft isis-cfg October 2019 | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro protocol-version? uint8 | +--ro raw-pdu? binary +---n area-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n rejected-adjacency | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro reason? string +---n protocols-supported-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro protocols* uint8 +---n lsp-error-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro raw-pdu? binary | +--ro error-offset? uint32 | +--ro tlv-type? uint8 +---n adjacency-state-change Litkowski, et al. Expires April 17, 2020 [Page 8] Internet-Draft isis-cfg October 2019 | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro neighbor? string | +--ro neighbor-system-id? system-id | +--ro state? adj-state-type | +--ro reason? string +---n lsp-received | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro sequence? uint32 | +--ro received-timestamp? yang:timestamp | +--ro neighbor-system-id? system-id +---n lsp-generation +--ro routing-protocol-name? -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +--ro isis-level? level +--ro lsp-id? lsp-id +--ro sequence? uint32 +--ro send-timestamp? yang:timestamp 2.1. IS-IS Configuration The IS-IS configuration is divided into: o Global parameters. o Per-interface configuration (see Section 2.4). Additional modules may be created to support additional parameters. These additional modules MUST augment the ietf-isis module. The model includes optional features, for which the corresponding configuration data nodes are also optional. As an example, the ability to control the administrative state of a particular IS-IS instance is optional. By advertising the feature "admin-control", a Litkowski, et al. Expires April 17, 2020 [Page 9] Internet-Draft isis-cfg October 2019 device communicates to the client that it supports the ability to shutdown a particular IS-IS instance. The global configuration contains usual IS-IS parameters, such as, lsp-mtu, lsp-lifetime, lsp-refresh, default-metric, etc. 2.2. Multi-topology Parameters The model supports multi-topology (MT) IS-IS as defined in [RFC5120]. The "topologies" container is used to enable support of the MT extensions. The "name" used in the topology list should refer to an existing Routing Information Base (RIB) defined for the device [RFC8349]. Some specific parameters can be defined on a per-topology basis, both at the global level and at the interface level: for example, an interface metric can be defined per topology. Multiple address families (such as, IPv4 or IPv6) can also be enabled within the default topology. This can be achieved using the address- families container (requiring the "nlpid-control" feature to be supported). 2.3. Per-Level Parameters Some parameters allow a per-level configuration. For such parameters, the parameter is modeled as a container with three configuration locations: o a Top-level container: Corresponds to level-1-2, so the configuration applies to both levels. o a Level-1 container: Corresponds to level-1 specific parameters. o a Level-2 container: Corresponds to level-2 specific parameters. +--rw priority | +--rw value? uint8 | +--rw level-1 | | +--rw value? uint8 | +--rw level-2 | +--rw value? uint8 Example: Litkowski, et al. Expires April 17, 2020 [Page 10] Internet-Draft isis-cfg October 2019 250 100 An implementation MUST prefer a level-specific parameter over a top- level parameter. For example, if the priority is 100 for the level-1 and 250 for the top-level configuration, the implementation must use 100 for the level-1 priority and 250 for the level-2 priority. Some parameters, such as, "overload bit" and "route preference", are not modeled to support a per-level configuration. If an implementation supports per-level configuration for such parameter, this implementation MUST augment the current model by adding both level-1 and level-2 containers and MUST reuse existing configuration groupings. Example of augmentation: augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol"+ "/isis:isis/isis:overload" { when "rt:type = 'isis:isis'" { description "This augment IS-IS routing protocol when used"; } description "This augments IS-IS overload configuration with per-level configuration."; container level-1 { uses isis:overload-global-cfg; description "Level 1 configuration."; } container level-2 { uses isis:overload-global-cfg; description "Level 2 configuration."; } } If an implementation does not support per-level configuration for a parameter modeled with per-level configuration, the implementation should advertise a deviation to announce the non-support of the level-1 and level-2 containers. Litkowski, et al. Expires April 17, 2020 [Page 11] Internet-Draft isis-cfg October 2019 Finally, if an implementation supports per-level configuration but does not support the level-1-2 configuration, it should also advertise a deviation. 2.4. Per-Interface Parameters The per-interface section of the IS-IS instance describes the interface-specific parameters. The interface is modeled as a reference to an existing interface defined in the "ietf-interfaces" YANG model ([RFC8343]. Each interface has some interface-specific parameters that may have a different per-level value as described in the previous section. An interface-specific parameter MUST be preferred over an IS-IS global parameter. Some parameters, such as, hello-padding are defined as containers to allow easy extension by vendor-specific modules. +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw enable? boolean {admin-control}? +--rw level-type? level +--rw lsp-pacing-interval? rt-types: | timer-value-milliseconds +--rw lsp-retransmit-interval? rt-types: | timer-value-seconds16 +--rw passive? boolean +--rw csnp-interval? rt-types: | timer-value-seconds16 +--rw hello-padding | +--rw enable? boolean +--rw mesh-group-enable? mesh-group-state +--rw mesh-group? uint8 +--rw interface-type? interface-type +--rw tag* uint32 {prefix-tag}? +--rw tag64* uint64 {prefix-tag64}? +--rw node-flag? boolean {node-flag}? +--rw hello-authentication | +--rw (authentication-type)? | | +--:(key-chain) {key-chain}? | | | +--rw key-chain? key-chain:key-chain-ref | | +--:(password) | | +--rw key? string | | +--rw crypto-algorithm? identityref | +--rw level-1 Litkowski, et al. Expires April 17, 2020 [Page 12] Internet-Draft isis-cfg October 2019 | | +--rw (authentication-type)? | | +--:(key-chain) {key-chain}? | | | +--rw key-chain? key-chain:key-chain-ref | | +--:(password) | | +--rw key? string | | +--rw crypto-algorithm? identityref | +--rw level-2 | +--rw (authentication-type)? | +--:(key-chain) {key-chain}? | | +--rw key-chain? key-chain:key-chain-ref | +--:(password) | +--rw key? string | +--rw crypto-algorithm? identityref +--rw hello-interval | +--rw value? rt-types:timer-value-seconds16 | +--rw level-1 | | +--rw value? rt-types:timer-value-seconds16 | +--rw level-2 | +--rw value? rt-types:timer-value-seconds16 +--rw hello-multiplier | +--rw value? uint16 | +--rw level-1 | | +--rw value? uint16 | +--rw level-2 | +--rw value? uint16 +--rw priority | +--rw value? uint8 | +--rw level-1 | | +--rw value? uint8 | +--rw level-2 | +--rw value? uint8 +--rw metric | +--rw value? wide-metric | +--rw level-1 | | +--rw value? wide-metric | +--rw level-2 | +--rw value? wide-metric +--rw bfd {bfd}? | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw address-families {nlpid-control}? | +--rw address-family-list* [address-family] Litkowski, et al. Expires April 17, 2020 [Page 13] Internet-Draft isis-cfg October 2019 | +--rw address-family iana-rt-types:address-family +--rw mpls | +--rw ldp | +--rw igp-sync? boolean {ldp-igp-sync}? +--rw fast-reroute {fast-reroute}? | +--rw lfa {lfa}? | +--rw candidate-enable? boolean | +--rw enable? boolean | +--rw remote-lfa {remote-lfa}? | | +--rw enable? boolean | +--rw level-1 | | +--rw candidate-enable? boolean | | +--rw enable? boolean | | +--rw remote-lfa {remote-lfa}? | | +--rw enable? boolean | +--rw level-2 | +--rw candidate-enable? boolean | +--rw enable? boolean | +--rw remote-lfa {remote-lfa}? | +--rw enable? boolean +--ro adjacencies | +--ro adjacency* [] | +--ro neighbor-sys-type? level | +--ro neighbor-sysid? system-id | +--ro neighbor-extended-circuit-id? extended-circuit-id | +--ro neighbor-snpa? snpa | +--ro usage? level | +--ro hold-timer? rt-types: | | timer-value-seconds16 | +--ro neighbor-priority? uint8 | +--ro lastuptime? yang:timestamp | +--ro state? adj-state-type +--ro event-counters | +--ro adjacency-changes? uint32 | +--ro adjacency-number? uint32 | +--ro init-fails? uint32 | +--ro adjacency-rejects? uint32 | +--ro id-len-mismatch? uint32 | +--ro max-area-addresses-mismatch? uint32 | +--ro authentication-type-fails? uint32 | +--ro authentication-fails? uint32 | +--ro lan-dis-changes? uint32 +--ro packet-counters | +--ro level* [level] | +--ro level level-number | +--ro iih | | +--ro in? uint32 | | +--ro out? uint32 Litkowski, et al. Expires April 17, 2020 [Page 14] Internet-Draft isis-cfg October 2019 | +--ro ish | | +--ro in? uint32 | | +--ro out? uint32 | +--ro esh | | +--ro in? uint32 | | +--ro out? uint32 | +--ro lsp | | +--ro in? uint32 | | +--ro out? uint32 | +--ro psnp | | +--ro in? uint32 | | +--ro out? uint32 | +--ro csnp | | +--ro in? uint32 | | +--ro out? uint32 | +--ro unknown | +--ro in? uint32 +--rw discontinuity-time? yang:date-and-time +--rw topologies {multi-topology}? +--rw topology* [name] +--rw name -> | ../../../../../../../../rt:ribs/rib/name +--rw metric +--rw value? wide-metric +--rw level-1 | +--rw value? wide-metric +--rw level-2 +--rw value? wide-metric rpcs: +---x clear-adjacency | +---w input | +---w routing-protocol-instance-name -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +---w level? level | +---w interface? if:interface-ref +---x clear-database +---w input +---w routing-protocol-instance-name -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +---w level? level notifications: +---n database-overload | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ Litkowski, et al. Expires April 17, 2020 [Page 15] Internet-Draft isis-cfg October 2019 | | control-plane-protocol/name | +--ro isis-level? level | +--ro overload? enumeration +---n lsp-too-large | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-size? uint32 | +--ro lsp-id? lsp-id +---n if-state-change | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro state? if-state-type +---n corrupted-lsp-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n attempt-to-exceed-max-sequence | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n id-len-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-field-len? uint8 | +--ro raw-pdu? binary +---n max-area-addresses-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name Litkowski, et al. Expires April 17, 2020 [Page 16] Internet-Draft isis-cfg October 2019 | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro max-area-addresses? uint8 | +--ro raw-pdu? binary +---n own-lsp-purge | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n sequence-number-skipped | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n authentication-type-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n authentication-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n version-skew | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref Litkowski, et al. Expires April 17, 2020 [Page 17] Internet-Draft isis-cfg October 2019 | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro protocol-version? uint8 | +--ro raw-pdu? binary +---n area-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n rejected-adjacency | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro reason? string +---n protocols-supported-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro protocols* uint8 +---n lsp-error-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro raw-pdu? binary | +--ro error-offset? uint32 | +--ro tlv-type? uint8 +---n adjacency-state-change | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ Litkowski, et al. Expires April 17, 2020 [Page 18] Internet-Draft isis-cfg October 2019 | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro neighbor? string | +--ro neighbor-system-id? system-id | +--ro state? adj-state-type | +--ro reason? string +---n lsp-received | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro sequence? uint32 | +--ro received-timestamp? yang:timestamp | +--ro neighbor-system-id? system-id +---n lsp-generation +--ro routing-protocol-name? -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +--ro isis-level? level +--ro lsp-id? lsp-id +--ro sequence? uint32 +--ro send-timestamp? yang:timestamp 2.5. Authentication Parameters The module enables authentication configuration through the IETF key- chain module [RFC8177]. The IS-IS module imports the "ietf-key- chain" module and reuses some groupings to allow global and per- interface configuration of authentication. If global authentication is configured, an implementation SHOULD authenticate PSNPs (Partial Sequence Number Packets), CSNPs (Complete Sequence Number Packets) and LSPs (Link State Packets) with the authentication parameters supplied. The authentication of HELLO PDUs (Protocol Data Units) can be activated on a per-interface basis. 2.6. IGP/LDP synchronization [RFC5443] defines a mechanism where IGP (Interior Gateway Protocol) needs to be synchronized with LDP (Label Distribution Protocol). An "ldp-igp-sync" feature has been defined in the model to support this functionality. The "mpls/ldp/igp-sync" leaf under "interface" allows Litkowski, et al. Expires April 17, 2020 [Page 19] Internet-Draft isis-cfg October 2019 activation of the functionality on a per-interface basis. The "mpls/ldp/igp-sync" container in the global configuration is intentionally empty and is not required for feature activation. The goal of this empty container is to facilitate augmentation with additional parameters, e.g., timers. 2.7. ISO parameters As the IS-IS protocol is based on the ISO protocol suite, some ISO parameters may be required. This module augments interface configuration model to support selected ISO configuration parameters. The clns-mtu can be configured for an interface. 2.8. IP FRR This YANG module supports LFA (Loop Free Alternates) [RFC5286] and remote LFA [RFC7490] as IP Fast Re-Route (FRR) techniques. The "fast-reroute" container may be augmented by other models to support other IP FRR flavors (MRT as defined in [RFC7812], TI-LFA as defined in [I-D.ietf-rtgwg-segment-routing-ti-lfa], etc.). The current version of the model supports activation of LFA and remote LFA at the interface-level only. The global "lfa" container is present but kept empty to allow augmentation with vendor-specific properties, e.g., policies. Remote LFA is considered as an extension of LFA. Remote LFA cannot be enabled if LFA is not enabled. The "candidate-enable" data leaf designates that an interface can be used as a backup. 2.9. Operational States Operational state is defined in module in various containers at various levels: o system-counters: Provides statistical information about the global system. o interface: Provides configuration state information for each interface. o adjacencies: Provides state information about current IS-IS adjacencies. Litkowski, et al. Expires April 17, 2020 [Page 20] Internet-Draft isis-cfg October 2019 o spf-log: Provides information about SPF events for an IS-IS instance. This SHOULD be implemented as a wrapping buffer. o lsp-log: Provides information about LSP events for an IS-IS instance (reception of an LSP or modification of a local LSP). This SHOULD be implemented as a wrapping buffer and the implementation MAY optionally log LSP refreshes. o local-rib: Provides the IS-IS internal routing table. o database: Provides contents of the current Link State Database. o hostnames: Provides the system-id to hostname mappings [RFC5301]. o fast-reroute: Provides IP FRR state information. 3. RPC Operations The "ietf-isis" module defines two RPC operations: o clear-database: Reset the content of a particular IS-IS database and restart database synchronization with all neighbors. o clear-adjacency: Restart a particular set of IS-IS adjacencies. 4. Notifications The "ietf-isis" module defines the following notifications: database-overload: This notification is sent when the IS-IS Node overload condition changes. lsp-too-large: This notification is sent when the system tries to propagate a PDU that is too large. if-state-change: This notification is sent when an interface's state changes. corrupted-lsp-detected: This notification is sent when the IS-IS node discovers that an LSP that was previously stored in the Link State Database, i.e., local memory, has become corrupted. attempt-to-exceed-max-sequence: This notification is sent when the system wraps the 32-bit sequence counter of an LSP. id-len-mismatch: This notification is sent when we receive a PDU with a different value for the System ID length. Litkowski, et al. Expires April 17, 2020 [Page 21] Internet-Draft isis-cfg October 2019 max-area-addresses-mismatch: This notification is sent when we receive a PDU with a different value for the Maximum Area Addresses. own-lsp-purge: This notification is sent when the system receives a PDU with its own system ID and zero age. sequence-number-skipped: This notification is sent when the system receives a PDU with its own system ID and different contents. The system has to reissue the LSP with a higher sequence number. authentication-type-failure: This notification is sent when the system receives a PDU with the wrong authentication type field. authentication-failure: This notification is sent when the system receives a PDU with the wrong authentication information. version-skew: This notification is sent when the system receives a PDU with a different protocol version number. area-mismatch: This notification is sent when the system receives a Hello PDU from an IS that does not share any area address. rejected-adjacency: This notification is sent when the system receives a Hello PDU from an IS but does not establish an adjacency for some reason. protocols-supported-mismatch: This notification is sent when the system receives a non-pseudonode LSP that has no matching protocol supported. lsp-error-detected: This notification is sent when the system receives an LSP with a parse error. adjacency-state-change: This notification is sent when an IS-IS adjacency moves to Up state or to Down state. lsp-received: This notification is sent when an LSP is received. lsp-generation: This notification is sent when an LSP is regenerated. 5. Interaction with Other YANG Modules The "isis" container augments the "/rt:routing/rt:control-plane- protocols/control-plane-protocol" container of the ietf-routing [RFC8349] module with IS-IS-specific parameters. Litkowski, et al. Expires April 17, 2020 [Page 22] Internet-Draft isis-cfg October 2019 The "isis" module augments "/if:interfaces/if:interface" defined by [RFC8343] with ISO specific parameters. The "isis" operational state container augments the "/rt:routing- state/rt:control-plane-protocols/control-plane-protocol" container of the ietf-routing module with IS-IS-specific operational states. Some IS-IS-specific route attributes are added to route objects in the ietf-routing module by augmenting "/rt:routing- state/rt:ribs/rt:rib/rt:routes/rt:route". The modules defined in this document uses some groupings from ietf- keychain [RFC8177]. The module reuses types from [RFC6991] and [RFC8294]. To support BFD for fast detection, the module relies on [I-D.ietf-bfd-yang]. 6. IS-IS YANG Module The following RFCs, drafts and external standards are not referenced in the document text but are referenced in the ietf-isis.yang module: [ISO-10589], [RFC1195], [RFC4090],[RFC5029], [RFC5130], [RFC5302], [RFC5305], [RFC5306], [RFC5307], [RFC5308], [RFC5880], [RFC5881], [RFC6119], [RFC6232], [RFC7794], [RFC7981], [RFC8570], [RFC7917], [RFC8405]. file "ietf-isis@2019-10-15.yang" module ietf-isis { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-isis"; prefix isis; import ietf-routing { prefix "rt"; reference "RFC 8349 - A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-inet-types { prefix inet; reference "RFC 6991 - Common YANG Data Types"; } import ietf-yang-types { Litkowski, et al. Expires April 17, 2020 [Page 23] Internet-Draft isis-cfg October 2019 prefix yang; reference "RFC 6991 - Common YANG Data Types"; } import ietf-interfaces { prefix "if"; reference "RFC 8343 - A YANG Data Model for Interface Management (NDMA Version)"; } import ietf-key-chain { prefix "key-chain"; reference "RFC 8177 - YANG Data Model for Key Chains"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294 - Common YANG Data Types for the Routing Area"; } import iana-routing-types { prefix "iana-rt-types"; reference "RFC 8294 - Common YANG Data Types for the Routing Area"; } import ietf-bfd-types { prefix "bfd-types"; reference "RFC YYYY - YANG Data Model for Bidirectional Forwarding Detection (BFD). -- Note to RFC Editor Please replace YYYY with published RFC number for draft-ietf-bfd-yang."; } organization "IETF LSR Working Group"; contact "WG Web: WG List: Editor: Stephane Litkowski Author: Derek Yeung Litkowski, et al. Expires April 17, 2020 [Page 24] Internet-Draft isis-cfg October 2019 Author: Acee Lindem Author: Jeffrey Zhang Author: Ladislav Lhotka "; description "This YANG module defines the generic configuration and operational state for the IS-IS protocol common to all vendor implementations. It is intended that the module will be extended by vendors to define vendor-specific IS-IS configuration parameters and policies, for example, route maps or route policies. This YANG model conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8242. Copyright (c) 2018 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 (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. 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) (RFC 8174) when, and only when, they appear in all capitals, as shown here. This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2019-10-15 { description "Initial revision."; reference "RFC XXXX"; } /* Identities */ Litkowski, et al. Expires April 17, 2020 [Page 25] Internet-Draft isis-cfg October 2019 identity isis { base rt:routing-protocol; description "Identity for the IS-IS routing protocol."; } identity lsp-log-reason { description "Base identity for an LSP change log reason."; } identity refresh { base lsp-log-reason; description "Identity used when the LSP log reason is a refresh LSP received."; } identity content-change { base lsp-log-reason; description "Identity used when the LSP log reason is a change in the content of the LSP."; } identity frr-protection-method { description "Base identity for a Fast Reroute protection method."; } identity frr-protection-method-lfa { base frr-protection-method; description "Loop Free Alternate as defined in RFC5286."; } identity frr-protection-method-rlfa { base frr-protection-method; description "Remote Loop Free Alternate as defined in RFC7490."; } identity frr-protection-method-rsvpte { base frr-protection-method; description "RSVP-TE as defined in RFC4090."; } identity frr-protection-available-type { description "Base identity for Fast Reroute protection types provided by an alternate path."; } identity frr-protection-available-node-type { base frr-protection-available-type; description "Node protection is provided by the alternate."; } Litkowski, et al. Expires April 17, 2020 [Page 26] Internet-Draft isis-cfg October 2019 identity frr-protection-available-link-type { base frr-protection-available-type; description "Link protection is provided by the alternate."; } identity frr-protection-available-srlg-type { base frr-protection-available-type; description "SRLG protection is provided by the alternate."; } identity frr-protection-available-downstream-type { base frr-protection-available-type; description "The alternate is downstream of node in the path."; } identity frr-protection-available-other-type { base frr-protection-available-type; description "The level of protection is unknown."; } identity frr-alternate-type { description "Base identity for IP Fast Reroute alternate type."; } identity frr-alternate-type-equal-cost { base frr-alternate-type; description "ECMP alternate."; } identity frr-alternate-type-lfa { base frr-alternate-type; description "LFA alternate."; } identity frr-alternate-type-remote-lfa { base frr-alternate-type; description "Remote LFA alternate."; } identity frr-alternate-type-tunnel { base frr-alternate-type; description "Tunnel based alternate (such as, RSVP-TE or GRE)."; } identity frr-alternate-mrt { base frr-alternate-type; description "MRT alternate."; } identity frr-alternate-tilfa { base frr-alternate-type; description "TILFA alternate."; } identity frr-alternate-other { base frr-alternate-type; description "Other alternate."; Litkowski, et al. Expires April 17, 2020 [Page 27] Internet-Draft isis-cfg October 2019 } identity unidirectional-link-delay-subtlv-flag { description "Base identity for unidirectional-link-delay subTLV flags. Flags are defined in RFC8570."; } identity unidirectional-link-delay-subtlv-a-flag { base unidirectional-link-delay-subtlv-flag; description "The A bit represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is clear, the value represents steady-state link performance."; } identity min-max-unidirectional-link-delay-subtlv-flag { description "Base identity for min-max-unidirectional-link-delay subTLV flags. Flags are defined in RFC8570."; } identity min-max-unidirectional-link-delay-subtlv-a-flag { base min-max-unidirectional-link-delay-subtlv-flag; description "The A bit represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is clear, the value represents steady-state link performance."; } identity unidirectional-link-loss-subtlv-flag { description "Base identity for unidirectional-link-loss subTLV flags. Flags are defined in RFC8570."; } identity unidirectional-link-loss-subtlv-a-flag { base unidirectional-link-loss-subtlv-flag; description "The A bit represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. Litkowski, et al. Expires April 17, 2020 [Page 28] Internet-Draft isis-cfg October 2019 The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is clear, the value represents steady-state link performance."; } identity tlv229-flag { description "Base identity for TLV229 flags. Flags are defined in RFC5120."; } identity tlv229-overload-flag { base tlv229-flag; description "If set, the originator is overloaded, and must be avoided in path calculation."; } identity tlv229-attached-flag { base tlv229-flag; description "If set, the originator is attached to another area using the referred metric."; } identity router-capability-flag { description "Base identity for router capability flags. Flags are defined in RFC7981."; } identity router-capability-flooding-flag { base router-capability-flag; description "Quote from RFC7981: 'If the S bit is set, the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is clear, the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking'."; } identity router-capability-down-flag { base router-capability-flag; description "Quote from RFC7981: 'When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be leaked from level-1 to level-2 in to prevent TLV looping'."; } identity lsp-flag { description "Base identity for LSP attributes. Litkowski, et al. Expires April 17, 2020 [Page 29] Internet-Draft isis-cfg October 2019 Attributes are defined in ISO 10589"; } identity lsp-partitioned-flag { base lsp-flag; description "Originator partition repair supported"; } identity lsp-attached-error-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the error metric."; } identity lsp-attached-delay-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the delay metric."; } identity lsp-attached-expense-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the expense metric."; } identity lsp-attached-default-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the default metric."; } identity lsp-overload-flag { base lsp-flag; description "If set, the originator is overloaded, and must be avoided in path calculation."; } identity lsp-l1system-flag { base lsp-flag; description "Set when the Intermediate System has an L1 type."; } identity lsp-l2system-flag { base lsp-flag; description "Set when the Intermediate System has an L2 type."; } /* Feature definitions */ feature osi-interface { description "Support of OSI specific parameters on an Litkowski, et al. Expires April 17, 2020 [Page 30] Internet-Draft isis-cfg October 2019 interface."; } feature poi-tlv { description "Support of Purge Originator Identification."; reference "RFC 6232 - Purge Originator Identification TLV for IS-IS"; } feature ietf-spf-delay { description "Support for IETF SPF delay algorithm."; reference "RFC 8405 - SPF Back-off algorithm for link state IGPs"; } feature bfd { description "Support for BFD detection of IS-IS neighbor reachability."; reference "RFC 5880 - Bidirectional Forwarding Detection (BFD) RFC 5881 - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"; } feature key-chain { description "Support of keychain for authentication."; reference "RFC8177 - YANG Data Model for Key Chains"; } feature node-flag { description "Support for node-flag for IS-IS prefixes."; reference "RFC7794 - IS-IS Prefix Attributes for Extended IP and IPv6 Reachability"; } feature node-tag { description "Support for node admin tag for IS-IS routing instances."; reference "RFC7917 - Advertising Node Administrative Tags in IS-IS"; } feature ldp-igp-sync { description "Support for LDP IGP synchronization."; reference "RFC5443 - LDP IGP Synchronization."; } feature fast-reroute { description "Support for IP Fast Reroute (IP-FRR)."; } feature nsr { description Litkowski, et al. Expires April 17, 2020 [Page 31] Internet-Draft isis-cfg October 2019 "Support for Non-Stop-Routing (NSR). The IS-IS NSR feature allows a router with redundant control-plane capability (e.g., dual Route-Processor (RP) cards) to maintain its state and adjacencies during planned and unplanned IS-IS instance restarts. It differs from graceful-restart or Non-Stop Forwarding (NSF) in that no protocol signaling or assistance from adjacent IS-IS neighbors is required to recover control-plane state."; } feature lfa { description "Support for Loop-Free Alternates (LFAs)."; reference "RFC5286 - Basic Specification of IP Fast-Reroute: Loop-free Alternates"; } feature remote-lfa { description "Support for Remote Loop-Free Alternates (R-LFAs)."; reference "RFC7490 - Remote Loop-Free Alternate Fast Reroute"; } feature overload-max-metric { description "Support of overload by setting all links to max metric. In IS-IS, the overload bit is usually used to signal that a node cannot be used as a transit. The overload-max-metric feature brings a similar behavior leveraging on setting all the link metrics to MAX_METRIC."; } feature prefix-tag { description "Support for 32-bit prefix tags"; reference "RFC5130 - A Policy Control Mechanism in IS-IS Using Administrative Tags"; } feature prefix-tag64 { description "Support for 64-bit prefix tags"; reference "RFC5130 - A Policy Control Mechanism in IS-IS Using Administrative Tags"; } feature auto-cost { description "Support for IS-IS interface metric computation according to a reference bandwidth."; } feature te-rid { Litkowski, et al. Expires April 17, 2020 [Page 32] Internet-Draft isis-cfg October 2019 description "Traffic-Engineering Router-ID."; reference "RFC5305 - IS-IS Extensions for Traffic Engineering RFC6119 - IPv6 Traffic Engineering in IS-IS"; } feature max-ecmp { description "Setting maximum number of ECMP paths."; } feature multi-topology { description "Support for Multiple-Topology Routing (MTR)."; reference "RFC5120 - M-IS-IS: Multi Topology Routing in IS-IS"; } feature nlpid-control { description "Support for the advertisement of a Network Layer Protocol Identifier within IS-IS configuration."; } feature graceful-restart { description "IS-IS Graceful restart support."; reference "RFC5306 - Restart Signaling in IS-IS"; } feature lsp-refresh { description "Configuration of LSP refresh interval."; } feature maximum-area-addresses { description "Support for maximum-area-addresses configuration."; } feature admin-control { description "Administrative control of the protocol state."; } /* Type definitions */ typedef circuit-id { type uint8; description "This type defines the circuit ID associated with an interface."; Litkowski, et al. Expires April 17, 2020 [Page 33] Internet-Draft isis-cfg October 2019 } typedef extended-circuit-id { type uint32; description "This type defines the extended circuit ID associated with an interface."; } typedef interface-type { type enumeration { enum broadcast { description "Broadcast interface type."; } enum point-to-point { description "Point-to-point interface type."; } } description "This type defines the type of adjacency to be established for the interface. The interface-type determines the type of hello message that is used."; } typedef level { type enumeration { enum "level-1" { description "This enum indicates L1-only capability."; } enum "level-2" { description "This enum indicates L2-only capability."; } enum "level-all" { description "This enum indicates capability for both levels."; } } default "level-all"; description "This type defines IS-IS level of an object."; } Litkowski, et al. Expires April 17, 2020 [Page 34] Internet-Draft isis-cfg October 2019 typedef adj-state-type { type enumeration { enum "up" { description "State indicates the adjacency is established."; } enum "down" { description "State indicates the adjacency is NOT established."; } enum "init" { description "State indicates the adjacency is establishing."; } enum "failed" { description "State indicates the adjacency is failed."; } } description "This type defines states of an adjacency"; } typedef if-state-type { type enumeration { enum "up" { description "Up state."; } enum "down" { description "Down state"; } } description "This type defines the state of an interface"; } typedef level-number { type uint8 { range "1 .. 2"; } description "This type defines the current IS-IS level."; } typedef lsp-id { type string { pattern Litkowski, et al. Expires April 17, 2020 [Page 35] Internet-Draft isis-cfg October 2019 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]' +'{4}\.[0-9][0-9]-[0-9][0-9]'; } description "This type defines the IS-IS LSP ID format using a pattern. An example LSP ID is 0143.0438.AEF0.02-01"; } typedef area-address { type string { pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; } description "This type defines the area address format."; } typedef snpa { type string { length "0 .. 20"; } description "This type defines the Subnetwork Point of Attachment (SNPA) format. The SNPA should be encoded according to the rules specified for the particular type of subnetwork being used. As an example, for an ethernet subnetwork, the SNPA is encoded as a MAC address, such as, '00aa.bbcc.ddee'."; } typedef system-id { type string { pattern '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; } description "This type defines IS-IS system-id using pattern, An example system-id is 0143.0438.AEF0"; } typedef extended-system-id { type string { pattern '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.' +'[0-9][0-9]'; } description "This type defines IS-IS system-id using pattern. The extended system-id contains the pseudonode number in addition to the Litkowski, et al. Expires April 17, 2020 [Page 36] Internet-Draft isis-cfg October 2019 system-id. An example system-id is 0143.0438.AEF0.00"; } typedef wide-metric { type uint32 { range "0 .. 16777215"; } description "This type defines wide style format of IS-IS metric."; } typedef std-metric { type uint8 { range "0 .. 63"; } description "This type defines old style format of IS-IS metric."; } typedef mesh-group-state { type enumeration { enum "mesh-inactive" { description "Interface is not part of a mesh group."; } enum "mesh-set" { description "Interface is part of a mesh group."; } enum "mesh-blocked" { description "LSPs must not be flooded over this interface."; } } description "This type describes mesh group state of an interface"; } /* Grouping for notifications */ grouping notification-instance-hdr { description "Instance specific IS-IS notification data grouping"; leaf routing-protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; Litkowski, et al. Expires April 17, 2020 [Page 37] Internet-Draft isis-cfg October 2019 } description "Name of the IS-IS instance."; } leaf isis-level { type level; description "IS-IS level of the instance."; } } grouping notification-interface-hdr { description "Interface specific IS-IS notification data grouping"; leaf interface-name { type if:interface-ref; description "IS-IS interface name"; } leaf interface-level { type level; description "IS-IS level of the interface."; } leaf extended-circuit-id { type extended-circuit-id; description "Extended circuit-id of the interface."; } } /* Groupings for IP Fast Reroute */ grouping instance-fast-reroute-config { description "This group defines global configuration of IP Fast ReRoute (FRR)."; container fast-reroute { if-feature fast-reroute; description "This container may be augmented with global parameters for IP-FRR."; container lfa { if-feature lfa; description "This container may be augmented with global parameters for Loop-Free Alternatives (LFA). Container creation has no effect on LFA activation."; } } } Litkowski, et al. Expires April 17, 2020 [Page 38] Internet-Draft isis-cfg October 2019 grouping interface-lfa-config { leaf candidate-enable { type boolean; default "true"; description "Enable the interface to be used as backup."; } leaf enable { type boolean; default false; description "Activates LFA - Per-prefix LFA computation is assumed."; } container remote-lfa { if-feature remote-lfa; leaf enable { type boolean; default false; description "Activates Remote LFA (R-LFA)."; } description "Remote LFA configuration."; } description "Grouping for LFA interface configuration"; } grouping interface-fast-reroute-config { description "This group defines interface configuration of IP-FRR."; container fast-reroute { if-feature fast-reroute; container lfa { if-feature lfa; uses interface-lfa-config; container level-1 { uses interface-lfa-config; description "LFA level 1 config"; } container level-2 { uses interface-lfa-config; description "LFA level 2 config"; } description "LFA configuration."; } Litkowski, et al. Expires April 17, 2020 [Page 39] Internet-Draft isis-cfg October 2019 description "Interface IP Fast-reroute configuration."; } } grouping instance-fast-reroute-state { description "IPFRR state data grouping"; container protected-routes { config false; list address-family-stats { key "address-family prefix alternate"; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf prefix { type inet:ip-prefix; description "Protected prefix."; } leaf alternate { type inet:ip-address; description "Alternate next hop for the prefix."; } leaf alternate-type { type identityref { base frr-alternate-type; } description "Type of alternate."; } leaf best { type boolean; description "Is set when the alternate is the preferred one, is clear otherwise."; } leaf non-best-reason { type string { length "1..255"; } description "Information field to describe why the alternate is not best. The length should be limited to 255 unicode characters. The expected format is a single line text."; Litkowski, et al. Expires April 17, 2020 [Page 40] Internet-Draft isis-cfg October 2019 } container protection-available { leaf-list protection-types { type identityref { base frr-protection-available-type; } description "This list contains a set of protection types defined as identities. An identity must be added for each type of protection provided by the alternate. As an example, if an alternate provides SRLG, node and link protection, three identities must be added in this list: one for SRLG protection, one for node protection, one for link protection."; } description "Protection types provided by the alternate."; } leaf alternate-metric1 { type uint32; description "Metric from Point of Local Repair (PLR) to destination through the alternate path."; } leaf alternate-metric2 { type uint32; description "Metric from PLR to the alternate node"; } leaf alternate-metric3 { type uint32; description "Metric from alternate node to the destination"; } description "Per-AF protected prefix statistics."; } description "List of prefixes that are protected."; } container unprotected-routes { config false; list prefixes { key "address-family prefix"; leaf address-family { type iana-rt-types:address-family; Litkowski, et al. Expires April 17, 2020 [Page 41] Internet-Draft isis-cfg October 2019 description "Address-family"; } leaf prefix { type inet:ip-prefix; description "Unprotected prefix."; } description "Per-AF unprotected prefix statistics."; } description "List of prefixes that are not protected."; } list protection-statistics { key frr-protection-method; config false; leaf frr-protection-method { type identityref { base frr-protection-method; } description "Protection method used."; } list address-family-stats { key address-family; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf total-routes { type yang:gauge32; description "Total prefixes."; } leaf unprotected-routes { type yang:gauge32; description "Total prefixes that are not protected."; } leaf protected-routes { type yang:gauge32; description "Total prefixes that are protected."; } leaf link-protected-routes { type yang:gauge32; description "Total prefixes that are link protected."; Litkowski, et al. Expires April 17, 2020 [Page 42] Internet-Draft isis-cfg October 2019 } leaf node-protected-routes { type yang:gauge32; description "Total prefixes that are node protected."; } description "Per-AF protected prefix statistics."; } description "Global protection statistics."; } } /* Route table and local RIB groupings */ grouping local-rib { description "Local-rib - RIB for Routes computed by the local IS-IS routing instance."; container local-rib { config false; description "Local-rib."; list route { key "prefix"; description "Routes"; leaf prefix { type inet:ip-prefix; description "Destination prefix."; } container next-hops { description "Next hops for the route."; list next-hop { key "next-hop"; description "List of next hops for the route"; leaf outgoing-interface { type if:interface-ref; description "Name of the outgoing interface."; } leaf next-hop { type inet:ip-address; description "Next hop address."; } } } leaf metric { type uint32; description "Metric for this route."; Litkowski, et al. Expires April 17, 2020 [Page 43] Internet-Draft isis-cfg October 2019 } leaf level { type level-number; description "Level number for this route."; } leaf route-tag { type uint32; description "Route tag for this route."; } } } } grouping route-content { description "IS-IS protocol-specific route properties grouping."; leaf metric { type uint32; description "IS-IS metric of a route."; } leaf-list tag { type uint64; description "List of tags associated with the route. This list provides a consolidated view of both 32-bit and 64-bit tags (RFC5130) available for the prefix."; } leaf route-type { type enumeration { enum l2-intra-area { description "Level 2 internal route. As per RFC5302, the prefix is directly connected to the advertising router. It cannot be distinguished from an L1->L2 inter-area route."; } enum l1-intra-area { description "Level 1 internal route. As per RFC5302, the prefix is directly connected to the advertising router."; } enum l2-external { description "Level 2 external route. As per RFC5302, such a route is learned from other IGPs. It cannot be distinguished from an L1->L2 inter-area external route."; } enum l1-external { Litkowski, et al. Expires April 17, 2020 [Page 44] Internet-Draft isis-cfg October 2019 description "Level 1 external route. As per RFC5302, such a route is learned from other IGPs."; } enum l1-inter-area { description "These prefixes are learned via L2 routing."; } enum l1-inter-area-external { description "These prefixes are learned via L2 routing towards an l2-external route."; } } description "IS-IS route type."; } } /* Grouping definitions for configuration and ops state */ grouping adjacency-state { container adjacencies { config false; list adjacency { leaf neighbor-sys-type { type level; description "Level capability of neighboring system"; } leaf neighbor-sysid { type system-id; description "The system-id of the neighbor"; } leaf neighbor-extended-circuit-id { type extended-circuit-id; description "Circuit ID of the neighbor"; } leaf neighbor-snpa { type snpa; description "SNPA of the neighbor"; } leaf usage { type level; description "Define the level(s) activated for the adjacency. On a p2p link this might be level 1 and 2, Litkowski, et al. Expires April 17, 2020 [Page 45] Internet-Draft isis-cfg October 2019 but on a LAN, the usage will be level 1 between neighbors at level 1 or level 2 between neighbors at level 2."; } leaf hold-timer { type rt-types:timer-value-seconds16; units seconds; description "The holding time in seconds for this adjacency. This value is based on received hello PDUs and the elapsed time since receipt."; } leaf neighbor-priority { type uint8 { range "0 .. 127"; } description "Priority of the neighboring IS for becoming the DIS."; } leaf lastuptime { type yang:timestamp; description "When the adjacency most recently entered state 'up', measured in hundredths of a second since the last reinitialization of the network management subsystem. The value is 0 if the adjacency has never been in state 'up'."; } leaf state { type adj-state-type; description "This leaf describes the state of the interface."; } description "List of operational adjacencies."; } description "This container lists the adjacencies of the local node."; } description "Adjacency state"; } Litkowski, et al. Expires April 17, 2020 [Page 46] Internet-Draft isis-cfg October 2019 grouping admin-control { leaf enable { if-feature admin-control; type boolean; default "true"; description "Enable/Disable the protocol."; } description "Grouping for admin control."; } grouping ietf-spf-delay { leaf initial-delay { type rt-types:timer-value-milliseconds; units msec; description "Delay used while in QUIET state (milliseconds)."; } leaf short-delay { type rt-types:timer-value-milliseconds; units msec; description "Delay used while in SHORT_WAIT state (milliseconds)."; } leaf long-delay { type rt-types:timer-value-milliseconds; units msec; description "Delay used while in LONG_WAIT state (milliseconds)."; } leaf hold-down { type rt-types:timer-value-milliseconds; units msec; description "Timer used to consider an IGP stability period (milliseconds)."; } leaf time-to-learn { type rt-types:timer-value-milliseconds; units msec; description "Duration used to learn all the IGP events related to a single component failure (milliseconds)."; } leaf current-state { type enumeration { Litkowski, et al. Expires April 17, 2020 [Page 47] Internet-Draft isis-cfg October 2019 enum "quiet" { description "QUIET state"; } enum "short-wait" { description "SHORT_WAIT state"; } enum "long-wait" { description "LONG_WAIT state"; } } config false; description "Current SPF back-off algorithm state."; } leaf remaining-time-to-learn { type rt-types:timer-value-milliseconds; units "msec"; config false; description "Remaining time until time-to-learn timer fires."; } leaf remaining-hold-down { type rt-types:timer-value-milliseconds; units "msec"; config false; description "Remaining time until hold-down timer fires."; } leaf last-event-received { type yang:timestamp; config false; description "Time of last IGP event received"; } leaf next-spf-time { type yang:timestamp; config false; description "Time when next SPF has been scheduled."; } leaf last-spf-time { type yang:timestamp; config false; description "Time of last SPF computation."; } description "Grouping for IETF SPF delay configuration and state."; Litkowski, et al. Expires April 17, 2020 [Page 48] Internet-Draft isis-cfg October 2019 } grouping node-tag-config { description "IS-IS node tag config state."; container node-tags { if-feature node-tag; list node-tag { key tag; leaf tag { type uint32; description "Node tag value."; } description "List of tags."; } description "Container for node admin tags."; } } grouping authentication-global-cfg { choice authentication-type { case key-chain { if-feature key-chain; leaf key-chain { type key-chain:key-chain-ref; description "Reference to a key-chain."; } } case password { leaf key { type string; description "This leaf specifies the authentication key. The length of the key may be dependent on the cryptographic algorithm."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; Litkowski, et al. Expires April 17, 2020 [Page 49] Internet-Draft isis-cfg October 2019 } } description "Choice of authentication."; } description "Grouping for global authentication config."; } grouping metric-type-global-cfg { leaf value { type enumeration { enum wide-only { description "Advertise new metric style only (RFC5305)"; } enum old-only { description "Advertise old metric style only (RFC1195)"; } enum both { description "Advertise both metric styles"; } } description "Type of metric to be generated: - wide-only means only new metric style is generated, - old-only means that only old-style metric is generated, - both means that both are advertised. This leaf is only affecting IPv4 metrics."; } description "Grouping for global metric style config."; } grouping metric-type-global-cfg-with-default { leaf value { type enumeration { enum wide-only { description "Advertise new metric style only (RFC5305)"; } enum old-only { description "Advertise old metric style only (RFC1195)"; } enum both { description "Advertise both metric styles"; Litkowski, et al. Expires April 17, 2020 [Page 50] Internet-Draft isis-cfg October 2019 } } default wide-only; description "Type of metric to be generated: - wide-only means only new metric style is generated, - old-only means that only old-style metric is generated, - both means that both are advertised. This leaf is only affecting IPv4 metrics."; } description "Grouping for global metric style config."; } grouping default-metric-global-cfg { leaf value { type wide-metric; description "Value of the metric"; } description "Global default metric config grouping."; } grouping default-metric-global-cfg-with-default { leaf value { type wide-metric; default "10"; description "Value of the metric"; } description "Global default metric config grouping."; } grouping overload-global-cfg { leaf status { type boolean; default false; description "This leaf specifies the overload status."; } description "Grouping for overload bit config."; } grouping overload-max-metric-global-cfg { leaf timeout { type rt-types:timer-value-seconds16; Litkowski, et al. Expires April 17, 2020 [Page 51] Internet-Draft isis-cfg October 2019 units "seconds"; description "Timeout (in seconds) of the overload condition."; } description "Overload maximum metric configuration grouping"; } grouping route-preference-global-cfg { choice granularity { case detail { leaf internal { type uint8; description "Protocol preference for internal routes."; } leaf external { type uint8; description "Protocol preference for external routes."; } } case coarse { leaf default { type uint8; description "Protocol preference for all IS-IS routes."; } } description "Choice for implementation of route preference."; } description "Global route preference grouping"; } grouping hello-authentication-cfg { choice authentication-type { case key-chain { if-feature key-chain; leaf key-chain { type key-chain:key-chain-ref; description "Reference to a key-chain."; } } case password { leaf key { type string; Litkowski, et al. Expires April 17, 2020 [Page 52] Internet-Draft isis-cfg October 2019 description "Authentication key specification - The length of the key may be dependent on the cryptographic algorithm."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } description "Choice of authentication."; } description "Grouping for hello authentication."; } grouping hello-interval-cfg { leaf value { type rt-types:timer-value-seconds16; units "seconds"; description "Interval (in seconds) between successive hello messages."; } description "Interval between hello messages."; } grouping hello-interval-cfg-with-default { leaf value { type rt-types:timer-value-seconds16; units "seconds"; default 10; description "Interval (in seconds) between successive hello messages."; } description "Interval between hello messages."; } grouping hello-multiplier-cfg { leaf value { type uint16; description "Number of missed hello messages prior to declaring the adjacency down."; } Litkowski, et al. Expires April 17, 2020 [Page 53] Internet-Draft isis-cfg October 2019 description "Number of missed hello messages prior to adjacency down grouping."; } grouping hello-multiplier-cfg-with-default { leaf value { type uint16; default 3; description "Number of missed hello messages prior to declaring the adjacency down."; } description "Number of missed hello messages prior to adjacency down grouping."; } grouping priority-cfg { leaf value { type uint8 { range "0 .. 127"; } description "Priority of interface for DIS election."; } description "Interface DIS election priority grouping"; } grouping priority-cfg-with-default { leaf value { type uint8 { range "0 .. 127"; } default 64; description "Priority of interface for DIS election."; } description "Interface DIS election priority grouping"; } grouping metric-cfg { leaf value { type wide-metric; description "Metric value."; } description "Interface metric grouping"; } Litkowski, et al. Expires April 17, 2020 [Page 54] Internet-Draft isis-cfg October 2019 grouping metric-cfg-with-default { leaf value { type wide-metric; default "10"; description "Metric value."; } description "Interface metric grouping"; } grouping metric-parameters { container metric-type { uses metric-type-global-cfg-with-default; container level-1 { uses metric-type-global-cfg; description "level-1 specific configuration"; } container level-2 { uses metric-type-global-cfg; description "level-2 specific configuration"; } description "Metric style global configuration"; } container default-metric { uses default-metric-global-cfg-with-default; container level-1 { uses default-metric-global-cfg; description "level-1 specific configuration"; } container level-2 { uses default-metric-global-cfg; description "level-2 specific configuration"; } description "Default metric global configuration"; } container auto-cost { if-feature auto-cost; description "Interface Auto-cost configuration state."; leaf enable { type boolean; description "Enable/Disable interface auto-cost."; } leaf reference-bandwidth { when "../enable = 'true'" { description "Only when auto cost is enabled"; Litkowski, et al. Expires April 17, 2020 [Page 55] Internet-Draft isis-cfg October 2019 } type uint32 { range "1..4294967"; } units Mbits; description "Configure reference bandwidth used to automatically determine interface cost (Mbits). The cost is the reference bandwidth divided by the interface speed with 1 being the minimum cost."; } } description "Grouping for global metric parameters."; } grouping high-availability-parameters { container graceful-restart { if-feature graceful-restart; leaf enable { type boolean; default false; description "Enable graceful restart."; } leaf restart-interval { type rt-types:timer-value-seconds16; units "seconds"; description "Interval (in seconds) to attempt graceful restart prior to failure."; } leaf helper-enable { type boolean; default "true"; description "Enable local IS-IS router as graceful restart helper."; } description "Graceful-Restart Configuration."; } container nsr { if-feature nsr; description "Non-Stop Routing (NSR) configuration."; leaf enable { type boolean; default false; description "Enable/Disable Non-Stop Routing (NSR)."; } } Litkowski, et al. Expires April 17, 2020 [Page 56] Internet-Draft isis-cfg October 2019 description "Grouping for High Availability parameters."; } grouping authentication-parameters { container authentication { uses authentication-global-cfg; container level-1 { uses authentication-global-cfg; description "level-1 specific configuration"; } container level-2 { uses authentication-global-cfg; description "level-2 specific configuration"; } description "Authentication global configuration for both LSPs and SNPs."; } description "Grouping for authentication parameters"; } grouping address-family-parameters { container address-families { if-feature nlpid-control; list address-family-list { key address-family; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf enable { type boolean; description "Activate the address family."; } description "List of address families and whether or not they are activated."; } description "Address Family configuration"; } description "Grouping for address family parameters."; } grouping mpls-parameters { container mpls { container te-rid { if-feature te-rid; description "Stable ISIS Router IP Address used for Traffic Litkowski, et al. Expires April 17, 2020 [Page 57] Internet-Draft isis-cfg October 2019 Engineering"; leaf ipv4-router-id { type inet:ipv4-address; description "Router ID value that would be used in TLV 134."; } leaf ipv6-router-id { type inet:ipv6-address; description "Router ID value that would be used in TLV 140."; } } container ldp { container igp-sync { if-feature ldp-igp-sync; description "This container may be augmented with global parameters for igp-ldp-sync."; } description "LDP configuration."; } description "MPLS configuration"; } description "Grouping for MPLS global parameters."; } grouping lsp-parameters { leaf lsp-mtu { type uint16; units "bytes"; default 1492; description "Maximum size of an LSP PDU in bytes."; } leaf lsp-lifetime { type uint16 { range "1..65535"; } units "seconds"; description "Lifetime of the router's LSPs in seconds."; } leaf lsp-refresh { if-feature lsp-refresh; type rt-types:timer-value-seconds16; units "seconds"; description "Refresh interval of the router's LSPs in seconds."; Litkowski, et al. Expires April 17, 2020 [Page 58] Internet-Draft isis-cfg October 2019 } leaf poi-tlv { if-feature poi-tlv; type boolean; default false; description "Enable advertisement of IS-IS Purge Originator Identification TLV."; } description "Grouping for LSP global parameters."; } grouping spf-parameters { container spf-control { leaf paths { if-feature max-ecmp; type uint16 { range "1..65535"; } description "Maximum number of Equal-Cost Multi-Path (ECMP) paths."; } container ietf-spf-delay { if-feature ietf-spf-delay; uses ietf-spf-delay; description "IETF SPF delay algorithm configuration."; } description "SPF calculation control."; } description "Grouping for SPF global parameters."; } grouping instance-config { description "IS-IS global configuration grouping"; uses admin-control; leaf level-type { type level; default "level-all"; description "Level of an IS-IS node - can be level-1, level-2 or level-all."; } leaf system-id { type system-id; description "system-id of the node."; } Litkowski, et al. Expires April 17, 2020 [Page 59] Internet-Draft isis-cfg October 2019 leaf maximum-area-addresses { if-feature maximum-area-addresses; type uint8; default 3; description "Maximum areas supported."; } leaf-list area-address { type area-address; description "List of areas supported by the protocol instance."; } uses lsp-parameters; uses high-availability-parameters; uses node-tag-config; uses metric-parameters; uses authentication-parameters; uses address-family-parameters; uses mpls-parameters; uses spf-parameters; uses instance-fast-reroute-config; container preference { uses route-preference-global-cfg; description "Router preference configuration for IS-IS protocol instance route installation"; } container overload { uses overload-global-cfg; description "Router protocol instance overload state configuration"; } container overload-max-metric { if-feature overload-max-metric; uses overload-max-metric-global-cfg; description "Router protocol instance overload maximum metric advertisement configuration."; } } grouping instance-state { description "IS-IS instance operational state."; uses spf-log; Litkowski, et al. Expires April 17, 2020 [Page 60] Internet-Draft isis-cfg October 2019 uses lsp-log; uses hostname-db; uses lsdb; uses local-rib; uses system-counters; uses instance-fast-reroute-state; leaf discontinuity-time { type yang:date-and-time; description "The time of the most recent occasion at which any one or more of this IS-IS instance's counters suffered a discontinuity. If no such discontinuities have occurred since the IS-IS instance was last re-initialized, then this node contains the time the IS-IS instance was re-initialized which normally occurs when it was created."; } } grouping multi-topology-config { description "Per-topology configuration"; container default-metric { uses default-metric-global-cfg; container level-1 { uses default-metric-global-cfg; description "level-1 specific configuration"; } container level-2 { uses default-metric-global-cfg; description "level-2 specific configuration"; } description "Default metric per-topology configuration"; } uses node-tag-config; } grouping interface-config { description "Interface configuration grouping"; uses admin-control; leaf level-type { type level; default "level-all"; description "IS-IS level of the interface."; } leaf lsp-pacing-interval { type rt-types:timer-value-milliseconds; Litkowski, et al. Expires April 17, 2020 [Page 61] Internet-Draft isis-cfg October 2019 units "milliseconds"; default 33; description "Interval (in milli-seconds) between LSP transmissions."; } leaf lsp-retransmit-interval { type rt-types:timer-value-seconds16; units "seconds"; description "Interval (in seconds) between LSP retransmissions."; } leaf passive { type boolean; default "false"; description "Indicates whether the interface is in passive mode (IS-IS not running but network is advertised)."; } leaf csnp-interval { type rt-types:timer-value-seconds16; units "seconds"; default 10; description "Interval (in seconds) between CSNP messages."; } container hello-padding { leaf enable { type boolean; default "true"; description "IS-IS Hello-padding activation - enabled by default."; } description "IS-IS hello padding configuration."; } leaf mesh-group-enable { type mesh-group-state; description "IS-IS interface mesh-group state"; } leaf mesh-group { when "../mesh-group-enable = 'mesh-set'" { description "Only valid when mesh-group-enable equals mesh-set"; } type uint8; description "IS-IS interface mesh-group ID."; } Litkowski, et al. Expires April 17, 2020 [Page 62] Internet-Draft isis-cfg October 2019 leaf interface-type { type interface-type; default "broadcast"; description "Type of adjacency to be established for the interface. This dictates the type of hello messages that are used."; } leaf-list tag { if-feature prefix-tag; type uint32; description "List of tags associated with the interface."; } leaf-list tag64 { if-feature prefix-tag64; type uint64; description "List of 64-bit tags associated with the interface."; } leaf node-flag { if-feature node-flag; type boolean; default false; description "Set prefix as a node representative prefix."; } container hello-authentication { uses hello-authentication-cfg; container level-1 { uses hello-authentication-cfg; description "level-1 specific configuration"; } container level-2 { uses hello-authentication-cfg; description "level-2 specific configuration"; } description "Authentication type to be used in hello messages."; } container hello-interval { uses hello-interval-cfg-with-default; container level-1 { uses hello-interval-cfg; description "level-1 specific configuration"; } container level-2 { uses hello-interval-cfg; Litkowski, et al. Expires April 17, 2020 [Page 63] Internet-Draft isis-cfg October 2019 description "level-2 specific configuration"; } description "Interval between hello messages."; } container hello-multiplier { uses hello-multiplier-cfg-with-default; container level-1 { uses hello-multiplier-cfg; description "level-1 specific configuration"; } container level-2 { uses hello-multiplier-cfg; description "level-2 specific configuration"; } description "Hello multiplier configuration."; } container priority { must '../interface-type = "broadcast"' { error-message "Priority only applies to broadcast interfaces."; description "Check for broadcast interface."; } uses priority-cfg-with-default; container level-1 { uses priority-cfg; description "level-1 specific configuration"; } container level-2 { uses priority-cfg; description "level-2 specific configuration"; } description "Priority for DIS election."; } container metric { uses metric-cfg-with-default; container level-1 { uses metric-cfg; description "level-1 specific configuration"; } container level-2 { uses metric-cfg; description "level-2 specific configuration"; } description "Metric configuration."; } container bfd { if-feature bfd; description "BFD Client Configuration."; Litkowski, et al. Expires April 17, 2020 [Page 64] Internet-Draft isis-cfg October 2019 uses bfd-types:client-cfg-parms; reference "RFC YYYY - YANG Data Model for Bidirectional Forwarding Detection (BFD). -- Note to RFC Editor Please replace YYYY with published FC number for draft-ietf-bfd-yang."; } container address-families { if-feature nlpid-control; list address-family-list { key address-family; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } description "List of AFs."; } description "Interface address-families"; } container mpls { container ldp { leaf igp-sync { if-feature ldp-igp-sync; type boolean; default false; description "Enables IGP/LDP synchronization"; } description "LDP protocol related configuration."; } description "MPLS configuration for IS-IS interfaces"; } uses interface-fast-reroute-config; } grouping multi-topology-interface-config { description "IS-IS interface topology configuration."; container metric { uses metric-cfg; container level-1 { uses metric-cfg; description "level-1 specific configuration"; } container level-2 { uses metric-cfg; description "level-2 specific configuration"; } Litkowski, et al. Expires April 17, 2020 [Page 65] Internet-Draft isis-cfg October 2019 description "Metric IS-IS interface configuration."; } } grouping interface-state { description "IS-IS interface operational state."; uses adjacency-state; uses event-counters; uses packet-counters; leaf discontinuity-time { type yang:date-and-time; description "The time of the most recent occasion at which any one or more of this IS-IS interface's counters suffered a discontinuity. If no such discontinuities have occurred since the IS-IS interface was last re-initialized, then this node contains the time the IS-IS interface was re-initialized which normally occurs when it was created."; } } /* Grouping for the hostname database */ grouping hostname-db { container hostnames { config false; list hostname { key system-id; leaf system-id { type system-id; description "system-id associated with the hostname."; } leaf hostname { type string { length "1..255"; } description "Hostname associated with the system-id as defined in RFC5301."; } description "List of system-id/hostname associations."; } description "Hostname to system-id mapping database."; } Litkowski, et al. Expires April 17, 2020 [Page 66] Internet-Draft isis-cfg October 2019 description "Grouping for hostname to system-id mapping database."; } /* Groupings for counters */ grouping system-counters { container system-counters { config false; list level { key level; leaf level { type level-number; description "IS-IS level."; } leaf corrupted-lsps { type uint32; description "Number of corrupted in-memory LSPs detected. LSPs received from the wire with a bad checksum are silently dropped and not counted. LSPs received from the wire with parse errors are counted by lsp-errors."; } leaf authentication-type-fails { type uint32; description "Number of authentication type mismatches."; } leaf authentication-fails { type uint32; description "Number of authentication key failures."; } leaf database-overload { type uint32; description "Number of times the database has become overloaded."; } leaf own-lsp-purge { type uint32; description "Number of times a zero-aged copy of the system's own LSP is received from some other IS-IS node."; } leaf manual-address-drop-from-area { Litkowski, et al. Expires April 17, 2020 [Page 67] Internet-Draft isis-cfg October 2019 type uint32; description "Number of times a manual address has been dropped from the area."; } leaf max-sequence { type uint32; description "Number of times the system has attempted to exceed the maximum sequence number."; } leaf sequence-number-skipped { type uint32; description "Number of times a sequence number skip has occurred."; } leaf id-len-mismatch { type uint32; description "Number of times a PDU is received with a different value for the ID field length than that of the receiving system."; } leaf partition-changes { type uint32; description "Number of partition changes detected."; } leaf lsp-errors { type uint32; description "Number of LSPs with errors we have received."; } leaf spf-runs { type uint32; description "Number of times we ran SPF at this level."; } description "List of supported levels."; } description "List counters for the IS-IS protocol instance"; } description "Grouping for IS-IS system counters"; } Litkowski, et al. Expires April 17, 2020 [Page 68] Internet-Draft isis-cfg October 2019 grouping event-counters { container event-counters { config false; leaf adjacency-changes { type uint32; description "The number of times an adjacency state change has occurred on this interface."; } leaf adjacency-number { type uint32; description "The number of adjacencies on this interface."; } leaf init-fails { type uint32; description "The number of times initialization of this interface has failed. This counts events such as PPP NCP failures. Failures to form an adjacency are counted by adjacency-rejects."; } leaf adjacency-rejects { type uint32; description "The number of times an adjacency has been rejected on this interface."; } leaf id-len-mismatch { type uint32; description "The number of times an IS-IS PDU with an ID field length different from that for this system has been received on this interface."; } leaf max-area-addresses-mismatch { type uint32; description "The number of times an IS-IS PDU has been received on this interface with the max area address field differing from that of this system."; } leaf authentication-type-fails { type uint32; description "Number of authentication type mismatches."; } Litkowski, et al. Expires April 17, 2020 [Page 69] Internet-Draft isis-cfg October 2019 leaf authentication-fails { type uint32; description "Number of authentication key failures."; } leaf lan-dis-changes { type uint32; description "The number of times the DIS has changed on this interface at this level. If the interface type is point-to-point, the count is zero."; } description "IS-IS interface event counters."; } description "Grouping for IS-IS interface event counters"; } grouping packet-counters { container packet-counters { config false; list level { key level; leaf level { type level-number; description "IS-IS level."; } container iih { leaf in { type uint32; description "Received IIH PDUs."; } leaf out { type uint32; description "Sent IIH PDUs."; } description "Number of IIH PDUs received/sent."; } container ish { leaf in { type uint32; description "Received ISH PDUs."; } leaf out { type uint32; description "Sent ISH PDUs."; } Litkowski, et al. Expires April 17, 2020 [Page 70] Internet-Draft isis-cfg October 2019 description "ISH PDUs received/sent."; } container esh { leaf in { type uint32; description "Received ESH PDUs."; } leaf out { type uint32; description "Sent ESH PDUs."; } description "Number of ESH PDUs received/sent."; } container lsp { leaf in { type uint32; description "Received LSP PDUs."; } leaf out { type uint32; description "Sent LSP PDUs."; } description "Number of LSP PDUs received/sent."; } container psnp { leaf in { type uint32; description "Received PSNP PDUs."; } leaf out { type uint32; description "Sent PSNP PDUs."; } description "Number of PSNP PDUs received/sent."; } container csnp { leaf in { type uint32; description "Received CSNP PDUs."; } leaf out { type uint32; description "Sent CSNP PDUs."; } description "Number of CSNP PDUs received/sent."; } container unknown { Litkowski, et al. Expires April 17, 2020 [Page 71] Internet-Draft isis-cfg October 2019 leaf in { type uint32; description "Received unknown PDUs."; } description "Number of unknown PDUs received/sent."; } description "List of packet counter for supported levels."; } description "Packet counters per IS-IS level."; } description "Grouping for per IS-IS Level packet counters."; } /* Groupings for various log buffers */ grouping spf-log { container spf-log { config false; list event { key id; leaf id { type yang:counter32; description "Event identifier - purely internal value. It is expected the most recent events to have the bigger id number."; } leaf spf-type { type enumeration { enum full { description "Full SPF computation."; } enum route-only { description "Route reachability only SPF computation"; } } description "Type of SPF computation performed."; } leaf level { type level-number; description "IS-IS level number for SPF computation"; } leaf schedule-timestamp { type yang:timestamp; Litkowski, et al. Expires April 17, 2020 [Page 72] Internet-Draft isis-cfg October 2019 description "Timestamp of when the SPF computation was scheduled."; } leaf start-timestamp { type yang:timestamp; description "Timestamp of when the SPF computation started."; } leaf end-timestamp { type yang:timestamp; description "Timestamp of when the SPF computation ended."; } list trigger-lsp { key "lsp"; leaf lsp { type lsp-id; description "LSP ID of the LSP triggering SPF computation."; } leaf sequence { type uint32; description "Sequence number of the LSP triggering SPF computation"; } description "This list includes the LSPs that triggered the SPF computation."; } description "List of computation events - implemented as a wrapping buffer."; } description "This container lists the SPF computation events."; } description "Grouping for spf-log events."; } grouping lsp-log { container lsp-log { config false; list event { key id; Litkowski, et al. Expires April 17, 2020 [Page 73] Internet-Draft isis-cfg October 2019 leaf id { type yang:counter32; description "Event identifier - purely internal value. It is expected the most recent events to have the bigger id number."; } leaf level { type level-number; description "IS-IS level number for LSP"; } container lsp { leaf lsp { type lsp-id; description "LSP ID of the LSP."; } leaf sequence { type uint32; description "Sequence number of the LSP."; } description "LSP identification container - either the received LSP or the locally generated LSP."; } leaf received-timestamp { type yang:timestamp; description "This is the timestamp when the LSA was received. In case of local LSA update, the timestamp refers to the LSA origination time."; } leaf reason { type identityref { base lsp-log-reason; } description "Type of LSP change."; } description "List of LSP events - implemented as a wrapping buffer."; } Litkowski, et al. Expires April 17, 2020 [Page 74] Internet-Draft isis-cfg October 2019 description "This container lists the LSP log. Local LSP modifications are also included in the list."; } description "Grouping for LSP log."; } /* Groupings for the LSDB description */ /* Unknown TLV and sub-TLV description */ grouping tlv { description "Type-Length-Value (TLV)"; leaf type { type uint16; description "TLV type."; } leaf length { type uint16; description "TLV length (octets)."; } leaf value { type yang:hex-string; description "TLV value."; } } grouping unknown-tlvs { description "Unknown TLVs grouping - Used for unknown TLVs or unknown sub-TLVs."; container unknown-tlvs { description "All unknown TLVs."; list unknown-tlv { description "Unknown TLV."; uses tlv; } } } /* TLVs and sub-TLVs for prefixes */ grouping prefix-reachability-attributes { description "Grouping for extended reachability attributes of an Litkowski, et al. Expires April 17, 2020 [Page 75] Internet-Draft isis-cfg October 2019 IPv4 or IPv6 prefix."; leaf external-prefix-flag { type boolean; description "External prefix flag."; } leaf readvertisement-flag { type boolean; description "Re-advertisement flag."; } leaf node-flag { type boolean; description "Node flag."; } } grouping prefix-ipv4-source-router-id { description "Grouping for the IPv4 source router ID of a prefix advertisement."; leaf ipv4-source-router-id { type inet:ipv4-address; description "IPv4 Source router ID address."; } } grouping prefix-ipv6-source-router-id { description "Grouping for the IPv6 source router ID of a prefix advertisement."; leaf ipv6-source-router-id { type inet:ipv6-address; description "IPv6 Source router ID address."; } } grouping prefix-attributes-extension { description "Prefix extended attributes as defined in RFC7794."; uses prefix-reachability-attributes; uses prefix-ipv4-source-router-id; uses prefix-ipv6-source-router-id; } grouping prefix-ipv4-std { Litkowski, et al. Expires April 17, 2020 [Page 76] Internet-Draft isis-cfg October 2019 description "Grouping for attributes of an IPv4 standard prefix as defined in RFC1195."; leaf ip-prefix { type inet:ipv4-address; description "IPv4 prefix address"; } leaf prefix-len { type uint8; description "IPv4 prefix length (in bits)"; } leaf i-e { type boolean; description "Internal or External (I/E) Metric bit value. Set to 'false' to indicate an internal metric."; } container default-metric { leaf metric { type std-metric; description "Default IS-IS metric for IPv4 prefix"; } description "IS-IS default metric container."; } container delay-metric { leaf metric { type std-metric; description "IS-IS delay metric for IPv4 prefix"; } leaf supported { type boolean; default "false"; description "Indicates whether IS-IS delay metric is supported."; } description "IS-IS delay metric container."; } container expense-metric { leaf metric { type std-metric; description "IS-IS expense metric for IPv4 prefix"; } leaf supported { type boolean; default "false"; description "Indicates whether IS-IS expense metric is supported."; } Litkowski, et al. Expires April 17, 2020 [Page 77] Internet-Draft isis-cfg October 2019 description "IS-IS expense metric container."; } container error-metric { leaf metric { type std-metric; description "This leaf describes the IS-IS error metric value"; } leaf supported { type boolean; default "false"; description "Indicates whether IS-IS error metric is supported."; } description "IS-IS error metric container."; } } grouping prefix-ipv4-extended { description "Grouping for attributes of an IPv4 extended prefix as defined in RFC5305."; leaf up-down { type boolean; description "Value of up/down bit. Set to true when the prefix has been advertised down the hierarchy."; } leaf ip-prefix { type inet:ipv4-address; description "IPv4 prefix address"; } leaf prefix-len { type uint8; description "IPv4 prefix length (in bits)"; } leaf metric { type wide-metric; description "IS-IS wide metric value"; } leaf-list tag { type uint32; description "List of 32-bit tags associated with the IPv4 prefix."; } leaf-list tag64 { type uint64; description Litkowski, et al. Expires April 17, 2020 [Page 78] Internet-Draft isis-cfg October 2019 "List of 64-bit tags associated with the IPv4 prefix."; } uses prefix-attributes-extension; } grouping prefix-ipv6-extended { description "Grouping for attributes of an IPv6 prefix as defined in RFC5308."; leaf up-down { type boolean; description "Value of up/down bit. Set to true when the prefix has been advertised down the hierarchy."; } leaf ip-prefix { type inet:ipv6-address; description "IPv6 prefix address"; } leaf prefix-len { type uint8; description "IPv6 prefix length (in bits)"; } leaf metric { type wide-metric; description "IS-IS wide metric value"; } leaf-list tag { type uint32; description "List of 32-bit tags associated with the IPv4 prefix."; } leaf-list tag64 { type uint64; description "List of 64-bit tags associated with the IPv4 prefix."; } uses prefix-attributes-extension; } /* TLVs and sub-TLVs for neighbors */ grouping neighbor-link-attributes { description "Grouping for link attributes as defined in RFC5029"; leaf link-attributes-flags { type uint16; description Litkowski, et al. Expires April 17, 2020 [Page 79] Internet-Draft isis-cfg October 2019 "Flags for the link attributes"; } } grouping neighbor-gmpls-extensions { description "Grouping for GMPLS attributes of a neighbor as defined in RFC5307"; leaf link-local-id { type uint32; description "Local identifier of the link."; } leaf remote-local-id { type uint32; description "Remote identifier of the link."; } leaf protection-capability { type uint8; description "Describes the protection capabilities of the link. This is the value of the first octet of the sub-TLV type 20 value."; } container interface-switching-capability { description "Interface switching capabilities of the link."; leaf switching-capability { type uint8; description "Switching capability of the link."; } leaf encoding { type uint8; description "Type of encoding of the LSP being used."; } container max-lsp-bandwidths { description "Per-priority max LSP bandwidths."; list max-lsp-bandwidth { leaf priority { type uint8 { range "0 .. 7"; } description "Priority from 0 to 7."; } leaf bandwidth { type rt-types:bandwidth-ieee-float32; Litkowski, et al. Expires April 17, 2020 [Page 80] Internet-Draft isis-cfg October 2019 description "max LSP bandwidth."; } description "List of max LSP bandwidths for different priorities."; } } container tdm-specific { when "../switching-capability = 100"; description "Switching Capability-specific information applicable when switching type is TDM."; leaf minimum-lsp-bandwidth { type rt-types:bandwidth-ieee-float32; description "minimum LSP bandwidth."; } leaf indication { type uint8; description "The indication whether the interface supports Standard or Arbitrary SONET/SDH."; } } container psc-specific { when "../switching-capability >= 1 and ../switching-capability <= 4"; description "Switching Capability-specific information applicable when switching type is PSC1,PSC2,PSC3 or PSC4."; leaf minimum-lsp-bandwidth { type rt-types:bandwidth-ieee-float32; description "minimum LSP bandwidth."; } leaf mtu { type uint16; units bytes; description "Interface MTU"; } } } } grouping neighbor-extended-te-extensions { description "Grouping for TE attributes of a neighbor as defined Litkowski, et al. Expires April 17, 2020 [Page 81] Internet-Draft isis-cfg October 2019 in RFC8570"; container unidirectional-link-delay { description "Container for the average delay from the local neighbor to the remote one."; container flags { leaf-list unidirectional-link-delay-subtlv-flags { type identityref { base unidirectional-link-delay-subtlv-flag; } description "This list contains identities for the bits which are set."; } description "unidirectional-link-delay subTLV flags."; } leaf value { type uint32; units usec; description "Delay value expressed in microseconds."; } } container min-max-unidirectional-link-delay { description "Container for the min and max delay from the local neighbor to the remote one."; container flags { leaf-list min-max-unidirectional-link-delay-subtlv-flags { type identityref { base min-max-unidirectional-link-delay-subtlv-flag; } description "This list contains identities for the bits which are set."; } description "min-max-unidirectional-link-delay subTLV flags."; } leaf min-value { type uint32; units usec; description "Minimum delay value expressed in microseconds."; } leaf max-value { Litkowski, et al. Expires April 17, 2020 [Page 82] Internet-Draft isis-cfg October 2019 type uint32; units usec; description "Maximum delay value expressed in microseconds."; } } container unidirectional-link-delay-variation { description "Container for the average delay variation from the local neighbor to the remote one."; leaf value { type uint32; units usec; description "Delay variation value expressed in microseconds."; } } container unidirectional-link-loss { description "Container for the packet loss from the local neighbor to the remote one."; container flags { leaf-list unidirectional-link-loss-subtlv-flags { type identityref { base unidirectional-link-loss-subtlv-flag; } description "This list contains identities for the bits which are set."; } description "unidirectional-link-loss subTLV flags."; } leaf value { type uint32; units percent; description "Link packet loss expressed as a percentage of the total traffic sent over a configurable interval."; } } container unidirectional-link-residual-bandwidth { description "Container for the residual bandwidth from the local neighbor to the remote one."; leaf value { type rt-types:bandwidth-ieee-float32; units Bps; Litkowski, et al. Expires April 17, 2020 [Page 83] Internet-Draft isis-cfg October 2019 description "Residual bandwidth."; } } container unidirectional-link-available-bandwidth { description "Container for the available bandwidth from the local neighbor to the remote one."; leaf value { type rt-types:bandwidth-ieee-float32; units Bps; description "Available bandwidth."; } } container unidirectional-link-utilized-bandwidth { description "Container for the utilized bandwidth from the local neighbor to the remote one."; leaf value { type rt-types:bandwidth-ieee-float32; units Bps; description "Utilized bandwidth."; } } } grouping neighbor-te-extensions { description "Grouping for TE attributes of a neighbor as defined in RFC5305"; leaf admin-group { type uint32; description "Administrative group/Resource Class/Color."; } container local-if-ipv4-addrs { description "All local interface IPv4 addresses."; leaf-list local-if-ipv4-addr { type inet:ipv4-address; description "List of local interface IPv4 addresses."; } } container remote-if-ipv4-addrs { description "All remote interface IPv4 addresses."; leaf-list remote-if-ipv4-addr { Litkowski, et al. Expires April 17, 2020 [Page 84] Internet-Draft isis-cfg October 2019 type inet:ipv4-address; description "List of remote interface IPv4 addresses."; } } leaf te-metric { type uint32; description "TE metric."; } leaf max-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum bandwidth."; } leaf max-reservable-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum reservable bandwidth."; } container unreserved-bandwidths { description "All unreserved bandwidths."; list unreserved-bandwidth { leaf priority { type uint8 { range "0 .. 7"; } description "Priority from 0 to 7."; } leaf unreserved-bandwidth { type rt-types:bandwidth-ieee-float32; description "Unreserved bandwidth."; } description "List of unreserved bandwidths for different priorities."; } } } grouping neighbor-extended { description "Grouping for attributes of an IS-IS extended neighbor."; leaf neighbor-id { type extended-system-id; description "system-id of the extended neighbor."; } container instances { description "List of all adjacencies between the local system and the neighbor system-id."; list instance { Litkowski, et al. Expires April 17, 2020 [Page 85] Internet-Draft isis-cfg October 2019 key id; leaf id { type uint32; description "Unique identifier of an instance of a particular neighbor."; } leaf metric { type wide-metric; description "IS-IS wide metric for extended neighbor"; } uses neighbor-gmpls-extensions; uses neighbor-te-extensions; uses neighbor-extended-te-extensions; uses neighbor-link-attributes; uses unknown-tlvs; description "Instance of a particular adjacency."; } } } grouping neighbor { description "IS-IS standard neighbor grouping."; leaf neighbor-id { type extended-system-id; description "IS-IS neighbor system-id"; } container instances { description "List of all adjacencies between the local system and the neighbor system-id."; list instance { key id; leaf id { type uint32; description "Unique identifier of an instance of a particular neighbor."; } leaf i-e { type boolean; description "Internal or External (I/E) Metric bit value. Set to 'false' to indicate an internal metric."; } container default-metric { leaf metric { type std-metric; description "IS-IS default metric value"; Litkowski, et al. Expires April 17, 2020 [Page 86] Internet-Draft isis-cfg October 2019 } description "IS-IS default metric container"; } container delay-metric { leaf metric { type std-metric; description "IS-IS delay metric value"; } leaf supported { type boolean; default "false"; description "IS-IS delay metric supported"; } description "IS-IS delay metric container"; } container expense-metric { leaf metric { type std-metric; description "IS-IS expense metric value"; } leaf supported { type boolean; default "false"; description "IS-IS expense metric supported"; } description "IS-IS expense metric container"; } container error-metric { leaf metric { type std-metric; description "IS-IS error metric value"; } leaf supported { type boolean; default "false"; description "IS-IS error metric supported"; } description "IS-IS error metric container"; } description "Instance of a particular adjacency as defined in ISO10589."; } } } /* Top-level TLVs */ grouping tlv132-ipv4-addresses { Litkowski, et al. Expires April 17, 2020 [Page 87] Internet-Draft isis-cfg October 2019 leaf-list ipv4-addresses { type inet:ipv4-address; description "List of IPv4 addresses of the IS-IS node - IS-IS reference is TLV 132."; } description "Grouping for TLV132."; } grouping tlv232-ipv6-addresses { leaf-list ipv6-addresses { type inet:ipv6-address; description "List of IPv6 addresses of the IS-IS node - IS-IS reference is TLV 232."; } description "Grouping for TLV232."; } grouping tlv134-ipv4-te-rid { leaf ipv4-te-routerid { type inet:ipv4-address; description "IPv4 Traffic Engineering router ID of the IS-IS node - IS-IS reference is TLV 134."; } description "Grouping for TLV134."; } grouping tlv140-ipv6-te-rid { leaf ipv6-te-routerid { type inet:ipv6-address; description "IPv6 Traffic Engineering router ID of the IS-IS node - IS-IS reference is TLV 140."; } description "Grouping for TLV140."; } grouping tlv129-protocols { leaf-list protocol-supported { type uint8; description "List of supported protocols of the IS-IS node - IS-IS reference is TLV 129."; } description "Grouping for TLV129."; } grouping tlv137-hostname { leaf dynamic-hostname { type string; description Litkowski, et al. Expires April 17, 2020 [Page 88] Internet-Draft isis-cfg October 2019 "Host Name of the IS-IS node - IS-IS reference is TLV 137."; } description "Grouping for TLV137."; } grouping tlv10-authentication { container authentication { leaf authentication-type { type identityref { base key-chain:crypto-algorithm; } description "Authentication type to be used with IS-IS node."; } leaf authentication-key { type string; description "Authentication key to be used. For security reasons, the authentication key MUST NOT be presented in a clear text format in response to any request (e.g., via get, get-config)."; } description "IS-IS node authentication information container - IS-IS reference is TLV 10."; } description "Grouping for TLV10."; } grouping tlv229-mt { container mt-entries { list topology { description "List of topologies supported"; leaf mt-id { type uint16 { range "0 .. 4095"; } description "Multi-Topology identifier of topology."; } container attributes { leaf-list flags { type identityref { base tlv229-flag; } description "This list contains identities for the bits which are Litkowski, et al. Expires April 17, 2020 [Page 89] Internet-Draft isis-cfg October 2019 set."; } description "TLV 229 flags."; } } description "IS-IS node topology information container - IS-IS reference is TLV 229."; } description "Grouping for TLV229."; } grouping tlv242-router-capabilities { container router-capabilities { list router-capability { container flags { leaf-list router-capability-flags { type identityref { base router-capability-flag; } description "This list contains identities for the bits which are set."; } description "Router capability flags."; } container node-tags { if-feature node-tag; list node-tag { leaf tag { type uint32; description "Node tag value."; } description "List of tags."; } description "Container for node admin tags"; } uses unknown-tlvs; description "IS-IS node capabilities. This list element may be extended with detailed information - IS-IS reference is TLV 242."; } description "List of router capability TLVs."; Litkowski, et al. Expires April 17, 2020 [Page 90] Internet-Draft isis-cfg October 2019 } description "Grouping for TLV242."; } grouping tlv138-srlg { description "Grouping for TLV138."; container links-srlgs { list links { leaf neighbor-id { type extended-system-id; description "system-id of the extended neighbor."; } leaf flags { type uint8; description "Flags associated with the link."; } leaf link-local-id { type union { type inet:ip-address; type uint32; } description "Local identifier of the link. It could be an IPv4 address or a local identifier."; } leaf link-remote-id { type union { type inet:ip-address; type uint32; } description "Remote identifier of the link. It could be an IPv4 address or a remotely learned identifier."; } container srlgs { description "List of SRLGs."; leaf-list srlg { type uint32; description "SRLG value of the link."; } } description "SRLG attribute of a link."; } Litkowski, et al. Expires April 17, 2020 [Page 91] Internet-Draft isis-cfg October 2019 description "List of links with SRLGs"; } } /* Grouping for LSDB description */ grouping lsp-entry { description "IS-IS LSP database entry grouping"; leaf decoded-completed { type boolean; description "IS-IS LSP body fully decoded."; } leaf raw-data { type yang:hex-string; description "The hexadecimal representation of the complete LSP in network-byte order (NBO) as received or originated."; } leaf lsp-id { type lsp-id; description "LSP ID of the LSP"; } leaf checksum { type uint16; description "LSP checksum"; } leaf remaining-lifetime { type uint16; units "seconds"; description "Remaining lifetime (in seconds) until LSP expiration."; } leaf sequence { type uint32; description "This leaf describes the sequence number of the LSP."; } container attributes { leaf-list lsp-flags { type identityref { base lsp-flag; } description "This list contains identities for the bits which are set."; } Litkowski, et al. Expires April 17, 2020 [Page 92] Internet-Draft isis-cfg October 2019 description "LSP attributes."; } uses tlv132-ipv4-addresses; uses tlv232-ipv6-addresses; uses tlv134-ipv4-te-rid; uses tlv140-ipv6-te-rid; uses tlv129-protocols; uses tlv137-hostname; uses tlv10-authentication; uses tlv229-mt; uses tlv242-router-capabilities; uses tlv138-srlg; uses unknown-tlvs; container is-neighbor { list neighbor { key neighbor-id; uses neighbor; description "List of neighbors."; } description "Standard IS neighbors container - IS-IS reference is TLV 2."; } container extended-is-neighbor { list neighbor { key neighbor-id; uses neighbor-extended; description "List of extended IS neighbors"; } description "Standard IS extended neighbors container - IS-IS reference is TLV 22"; } container ipv4-internal-reachability { list prefixes { uses prefix-ipv4-std; description "List of prefixes."; } description "IPv4 internal reachability information container - IS-IS reference is TLV 128."; Litkowski, et al. Expires April 17, 2020 [Page 93] Internet-Draft isis-cfg October 2019 } container ipv4-external-reachability { list prefixes { uses prefix-ipv4-std; description "List of prefixes."; } description "IPv4 external reachability information container - IS-IS reference is TLV 130."; } container extended-ipv4-reachability { list prefixes { uses prefix-ipv4-extended; uses unknown-tlvs; description "List of prefixes."; } description "IPv4 extended reachability information container - IS-IS reference is TLV 135."; } container mt-is-neighbor { list neighbor { leaf mt-id { type uint16 { range "0 .. 4095"; } description "Multi-topology (MT) identifier"; } uses neighbor-extended; description "List of neighbors."; } description "IS-IS multi-topology neighbor container - IS-IS reference is TLV 223."; } container mt-extended-ipv4-reachability { list prefixes { leaf mt-id { type uint16 { range "0 .. 4095"; } description "Multi-topology (MT) identifier"; } uses prefix-ipv4-extended; Litkowski, et al. Expires April 17, 2020 [Page 94] Internet-Draft isis-cfg October 2019 uses unknown-tlvs; description "List of extended prefixes."; } description "IPv4 multi-topology (MT) extended reachability information container - IS-IS reference is TLV 235."; } container mt-ipv6-reachability { list prefixes { leaf MT-ID { type uint16 { range "0 .. 4095"; } description "Multi-topology (MT) identifier"; } uses prefix-ipv6-extended; uses unknown-tlvs; description "List of IPv6 extended prefixes."; } description "IPv6 multi-topology (MT) extended reachability information container - IS-IS reference is TLV 237."; } container ipv6-reachability { list prefixes { uses prefix-ipv6-extended; uses unknown-tlvs; description "List of IPv6 prefixes."; } description "IPv6 reachability information container - IS-IS reference is TLV 236."; } } grouping lsdb { description "Link State Database (LSDB) grouping"; container database { config false; list levels { key level; leaf level { type level-number; description "LSDB level number (1 or 2)"; } Litkowski, et al. Expires April 17, 2020 [Page 95] Internet-Draft isis-cfg October 2019 list lsp { key lsp-id; uses lsp-entry; description "List of LSPs in LSDB"; } description "List of LSPs for the LSDB level container"; } description "IS-IS Link State database container"; } } /* Augmentations */ augment "/rt:routing/" +"rt:ribs/rt:rib/rt:routes/rt:route" { when "rt:source-protocol = 'isis:isis'" { description "IS-IS-specific route attributes."; } uses route-content; description "This augments route object in RIB with IS-IS-specific attributes."; } augment "/if:interfaces/if:interface" { leaf clns-mtu { if-feature osi-interface; type uint16; description "CLNS MTU of the interface"; } description "ISO specific interface parameters."; } augment "/rt:routing/rt:control-plane-protocols/" +"rt:control-plane-protocol" { when "rt:type = 'isis:isis'" { description "This augment is only valid when routing protocol instance type is 'isis'"; } description "This augments a routing protocol instance with IS-IS specific parameters."; container isis { Litkowski, et al. Expires April 17, 2020 [Page 96] Internet-Draft isis-cfg October 2019 must "count(area-address) > 0" { error-message "At least one area-address must be configured."; description "Enforce configuration of at least one area."; } uses instance-config; uses instance-state; container topologies { if-feature multi-topology; list topology { key "name"; leaf enable { type boolean; description "Topology enable configuration"; } leaf name { type leafref { path "../../../../../../rt:ribs/rt:rib/rt:name"; } description "Routing Information Base (RIB) corresponding to topology."; } uses multi-topology-config; description "List of topologies"; } description "Multi-topology container"; } container interfaces { list interface { key "name"; leaf name { type if:interface-ref; description "Reference to the interface within the routing-instance."; } uses interface-config; uses interface-state; container topologies { if-feature multi-topology; list topology { Litkowski, et al. Expires April 17, 2020 [Page 97] Internet-Draft isis-cfg October 2019 key name; leaf name { type leafref { path "../../../../../../../../"+ "rt:ribs/rt:rib/rt:name"; } description "Routing Information Base (RIB) corresponding to topology."; } uses multi-topology-interface-config; description "List of interface topologies"; } description "Multi-topology container"; } description "List of IS-IS interfaces."; } description "IS-IS interface specific configuration container"; } description "IS-IS configuration/state top-level container"; } } /* RPC methods */ rpc clear-adjacency { description "This RPC request clears a particular set of IS-IS adjacencies. If the operation fails due to an internal reason, then the error-tag and error-app-tag should be set indicating the reason for the failure."; input { leaf routing-protocol-instance-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "Name of the IS-IS protocol instance whose IS-IS adjacency is being cleared. Litkowski, et al. Expires April 17, 2020 [Page 98] Internet-Draft isis-cfg October 2019 If the corresponding IS-IS instance doesn't exist, then the operation will fail with an error-tag of 'data-missing' and an error-app-tag of 'routing-protocol-instance-not-found'."; } leaf level { type level; description "IS-IS level of the adjacency to be cleared. If the IS-IS level is level-1-2, both level 1 and level 2 adjacencies would be cleared. If the value provided is different from the one authorized in the enum type, then the operation SHALL fail with an error-tag of 'data-missing' and an error-app-tag of 'bad-isis-level'."; } leaf interface { type if:interface-ref; description "IS-IS interface name. If the corresponding IS-IS interface doesn't exist, then the operation SHALL fail with an error-tag of 'data-missing' and an error-app-tag of 'isis-interface-not-found'."; } } } rpc clear-database { description "This RPC request clears a particular IS-IS database. If the operation fails for an IS-IS internal reason, then the error-tag and error-app-tag should be set indicating the reason for the failure."; input { leaf routing-protocol-instance-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "Name of the IS-IS protocol instance whose IS-IS database(s) is/are being cleared. If the corresponding IS-IS instance doesn't exist, Litkowski, et al. Expires April 17, 2020 [Page 99] Internet-Draft isis-cfg October 2019 then the operation will fail with an error-tag of 'data-missing' and an error-app-tag of 'routing-protocol-instance-not-found'."; } leaf level { type level; description "IS-IS level of the adjacency to be cleared. If the IS-IS level is level-1-2, both level 1 and level 2 databases would be cleared. If the value provided is different from the one authorized in the enum type, then the operation SHALL fail with an error-tag of 'data-missing' and an error-app-tag of 'bad-isis-level'."; } } } /* Notifications */ notification database-overload { uses notification-instance-hdr; leaf overload { type enumeration { enum off { description "Indicates IS-IS instance has left overload state"; } enum on { description "Indicates IS-IS instance has entered overload state"; } } description "New overload state of the IS-IS instance"; } description "This notification is sent when an IS-IS instance overload state changes."; } notification lsp-too-large { uses notification-instance-hdr; uses notification-interface-hdr; Litkowski, et al. Expires April 17, 2020 [Page 100] Internet-Draft isis-cfg October 2019 leaf pdu-size { type uint32; description "Size of the LSP PDU"; } leaf lsp-id { type lsp-id; description "LSP ID"; } description "This notification is sent when we attempt to propagate an LSP that is larger than the dataLinkBlockSize (ISO10589) for the circuit. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification if-state-change { uses notification-instance-hdr; uses notification-interface-hdr; leaf state { type if-state-type; description "Interface state."; } description "This notification is sent when an interface state change is detected."; } notification corrupted-lsp-detected { uses notification-instance-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } description "This notification is sent when we find that an LSP that was stored in memory has become corrupted."; } notification attempt-to-exceed-max-sequence { uses notification-instance-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } description Litkowski, et al. Expires April 17, 2020 [Page 101] Internet-Draft isis-cfg October 2019 "This notification is sent when the system wraps the 32-bit sequence counter of an LSP."; } notification id-len-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf pdu-field-len { type uint8; description "Size of the ID length in the received PDU"; } leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when we receive a PDU with a different value for the system-id length. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification max-area-addresses-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf max-area-addresses { type uint8; description "Received number of supported areas"; } leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when we receive a PDU with a different value for the Maximum Area Addresses. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification own-lsp-purge { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { Litkowski, et al. Expires April 17, 2020 [Page 102] Internet-Draft isis-cfg October 2019 type lsp-id; description "LSP ID"; } description "This notification is sent when the system receives a PDU with its own system-id and zero age."; } notification sequence-number-skipped { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } description "This notification is sent when the system receives a PDU with its own system-id and different contents. The system has to originate the LSP with a higher sequence number."; } notification authentication-type-failure { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a PDU with the wrong authentication type field. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification authentication-failure { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a PDU with the wrong authentication information. The notification generation must be throttled Litkowski, et al. Expires April 17, 2020 [Page 103] Internet-Draft isis-cfg October 2019 with at least 5 seconds between successive notifications."; } notification version-skew { uses notification-instance-hdr; uses notification-interface-hdr; leaf protocol-version { type uint8; description "Protocol version received in the PDU."; } leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a PDU with a different protocol version number. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification area-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a Hello PDU from an IS that does not share any area address. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification rejected-adjacency { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } leaf reason { type string { Litkowski, et al. Expires April 17, 2020 [Page 104] Internet-Draft isis-cfg October 2019 length "0..255"; } description "The system may provide a reason to reject the adjacency. If the reason is not available, the reason string will not be returned. The expected format is a single line text."; } description "This notification is sent when the system receives a Hello PDU from an IS but does not establish an adjacency for some reason. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification protocols-supported-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } leaf-list protocols { type uint8; description "List of protocols supported by the remote system."; } description "This notification is sent when the system receives a non-pseudonode LSP that has no matching protocols supported. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification lsp-error-detected { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { type lsp-id; description "LSP ID."; } leaf raw-pdu { type binary; description "Received raw PDU."; } Litkowski, et al. Expires April 17, 2020 [Page 105] Internet-Draft isis-cfg October 2019 leaf error-offset { type uint32; description "If the problem is a malformed TLV, the error-offset points to the start of the TLV. If the problem is with the LSP header, the error-offset points to the errant byte"; } leaf tlv-type { type uint8; description "If the problem is a malformed TLV, the tlv-type is set to the type value of the suspicious TLV. Otherwise, this leaf is not present."; } description "This notification is sent when the system receives an LSP with a parse error. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification adjacency-state-change { uses notification-instance-hdr; uses notification-interface-hdr; leaf neighbor { type string { length "1..255"; } description "Name of the neighbor. It corresponds to the hostname associated with the system-id of the neighbor in the mapping database (RFC5301). If the name of the neighbor is not available, it is not returned."; } leaf neighbor-system-id { type system-id; description "Neighbor system-id"; } leaf state { type adj-state-type; description "New state of the IS-IS adjacency."; } leaf reason { type string { Litkowski, et al. Expires April 17, 2020 [Page 106] Internet-Draft isis-cfg October 2019 length "1..255"; } description "If the adjacency is going to DOWN, this leaf provides a reason for the adjacency going down. The reason is provided as a text. If the adjacency is going to UP, no reason is provided. The expected format is a single line text."; } description "This notification is sent when an IS-IS adjacency moves to Up state or to Down state."; } notification lsp-received { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } leaf sequence { type uint32; description "Sequence number of the received LSP."; } leaf received-timestamp { type yang:timestamp; description "Timestamp when the LSP was received."; } leaf neighbor-system-id { type system-id; description "Neighbor system-id of LSP sender"; } description "This notification is sent when an LSP is received. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification lsp-generation { uses notification-instance-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } Litkowski, et al. Expires April 17, 2020 [Page 107] Internet-Draft isis-cfg October 2019 leaf sequence { type uint32; description "Sequence number of the received LSP."; } leaf send-timestamp { type yang:timestamp; description "Timestamp when our LSP was regenerated."; } description "This notification is sent when an LSP is regenerated. The notification generation must be throttled with at least 5 seconds between successive notifications."; } } 7. Security Considerations The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre- configured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in ietf-isis.yang module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Writable data node represent configuration of each instance and interface. These correspond to the following schema nodes: /isis /isis/interfaces/interface[name] For IS-IS, the ability to modify IS-IS configuration will allow the entire IS-IS domain to be compromised including forming adjacencies with unauthorized routers to misroute traffic or mount a massive Litkowski, et al. Expires April 17, 2020 [Page 108] Internet-Draft isis-cfg October 2019 Denial-of-Service (DoS) attack. For example, adding IS-IS on any unprotected interface could allow an IS-IS adjacency to be formed with an unauthorized and malicious neighbor. Once an adjacency is formed, traffic could be hijacked. As a simpler example, a Denial- Of-Service attack could be mounted by changing the cost of an IS-IS interface to be asymmetric such that a hard routing loop ensues. In general, unauthorized modification of most IS-IS features will pose their own set of security risks and the "Security Considerations" in the respective reference RFCs should be consulted. Some of the readable data nodes in the ietf-isis.yang module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The exposure of the Link State Database (LSDB) will expose the detailed topology of the network. Similarly, the IS-IS local RIB exposes the reachable prefixes in the IS-IS routing domain. The Link State Database (LSDB) and local RIB are represented by the following schema nodes: /isis/database /isis/local-rib Exposure of the Link State Database and local RIB include information beyond the scope of the IS-IS router and this may be undesirable since exposure may facilitate other attacks. Additionally, the complete IP network topology and, if deployed, the traffic engineering topology of the IS-IS domain can be reconstructed from the Link State Database. Though not as straightforward, the IS-IS local RIB can also be discover topological information. Network operators may consider their topologies to be sensitive confidential data. For IS-IS authentication, configuration is supported via the specification of key-chain [RFC8177] or the direct specification of key and authentication algorithm. Hence, authentication configuration using the "auth-table-trailer" case in the "authentication" container inherits the security considerations of [RFC8177]. This includes the considerations with respect to the local storage and handling of authentication keys. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. The IS-IS YANG module support the "clear-adjacency" and "clear-database" RPCs. If access to either of these is compromised, they can result in temporary network outages be employed to mount DoS attacks. Litkowski, et al. Expires April 17, 2020 [Page 109] Internet-Draft isis-cfg October 2019 The actual authentication key data (whether locally specified or part of a key-chain) is sensitive and needs to be kept secret from unauthorized parties; compromise of the key data would allow an attacker to forge IS-IS traffic that would be accepted as authentic, potentially compromising the entirety IS-IS domain. The model describes several notifications, implementations must rate- limit the generation of these notifications to avoid creating significant notification load. Otherwise, this notification load may have some side effects on the system stability and may be exploited as an attack vector. 8. Contributors The authors would like to thank Kiran Agrahara Sreenivasa, Dean Bogdanovic, Yingzhen Qu, Yi Yang, Jeff Tanstura for their major contributions to the draft. 9. Acknowledgements The authors would like to thank Tom Petch, Alvaro Retana, Stewart Bryant, Barry Leiba, Benjamin Kaduk and Adam Roach, and Roman Danyliw for their review and comments. 10. IANA Considerations The IANA is requested to assign two new URIs from the IETF XML registry [RFC3688]. Authors are suggesting the following URI: URI: urn:ietf:params:xml:ns:yang:ietf-isis Registrant Contact: The IESG XML: N/A, the requested URI is an XML namespace This document also requests one new YANG module name in the YANG Module Names registry [RFC6020] with the following suggestion: name: ietf-isis namespace: urn:ietf:params:xml:ns:yang:ietf-isis prefix: isis reference: RFC XXXX 11. References 11.1. Normative References Litkowski, et al. Expires April 17, 2020 [Page 110] Internet-Draft isis-cfg October 2019 [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work in progress), August 2018. [ISO-10589] "Intermediate System to Intermediate System intra- domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589: 2002, Second Edition, 2002. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [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, . [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, . [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, September 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, . Litkowski, et al. Expires April 17, 2020 [Page 111] Internet-Draft isis-cfg October 2019 [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, . [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, . [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, DOI 10.17487/RFC5302, October 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, . [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Litkowski, et al. Expires April 17, 2020 [Page 112] Internet-Draft isis-cfg October 2019 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, . [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, 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, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [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, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S., and B. Decraene, "Advertising Node Administrative Tags in IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . Litkowski, et al. Expires April 17, 2020 [Page 113] Internet-Draft isis-cfg October 2019 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, DOI 10.17487/RFC8405, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Litkowski, et al. Expires April 17, 2020 [Page 114] Internet-Draft isis-cfg October 2019 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . 11.2. Informative References [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Camarillo, "Topology Independent Fast Reroute using Segment Routing", draft-ietf-rtgwg-segment-routing-ti- lfa-01 (work in progress), March 2019. [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . Appendix A. Example of IS-IS configuration in XML This section gives an example of configuration of an IS-IS instance on a device. The example is written in XML. SLI 192.0.2.1 ISIS-example isis:isis true level-2 87FC.FCDF.4432 49.0001 Litkowski, et al. Expires April 17, 2020 [Page 115] Internet-Draft isis-cfg October 2019 192.0.2.1 65535 65000 wide-only 111111 ipv4 true ipv6 true Loopback0 200 0 true Eth1 level-2 point-to-point 167890 Loopback0 Litkowski, et al. Expires April 17, 2020 [Page 116] Internet-Draft isis-cfg October 2019 ianaift:softwareLoopback enabled
192.0.2.1 32
2001:DB8::1 128
Eth1 ianaift:ethernetCsmacd enabled
198.51.100.1 30
2001:DB8:0:0:FF::1 64
Authors' Addresses Stephane Litkowski Cisco Systems Email: slitkows.ietf@gmail.com Litkowski, et al. Expires April 17, 2020 [Page 117] Internet-Draft isis-cfg October 2019 Derek Yeung Arrcus, Inc Email: derek@arrcus.com Acee Lindem Cisco Systems Email: acee@cisco.com Jeffrey Zhang Juniper Networks Email: zzhang@juniper.net Ladislav Lhotka CZ.NIC Email: lhotka@nic.cz Litkowski, et al. Expires April 17, 2020 [Page 118] ./draft-ietf-cbor-array-tags-08.txt0000644000764400076440000007145013547114620016367 0ustar iustyiusty Network Working Group C. Bormann, Ed. Internet-Draft Universitaet Bremen TZI Intended status: Standards Track October 08, 2019 Expires: April 10, 2020 Concise Binary Object Representation (CBOR) Tags for Typed Arrays draft-ietf-cbor-array-tags-08 Abstract The Concise Binary Object Representation (CBOR, RFC 7049) 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. The present document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as two additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined. 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 https://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 10, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Bormann Expires April 10, 2020 [Page 1] Internet-Draft CBOR tags for typed arrays October 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 3 2. Typed Arrays . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Types of numbers . . . . . . . . . . . . . . . . . . . . 4 3. Additional Array Tags . . . . . . . . . . . . . . . . . . . . 5 3.1. Multi-dimensional Array . . . . . . . . . . . . . . . . . 6 3.1.1. Row-major Order . . . . . . . . . . . . . . . . . . . 6 3.1.2. Column-Major order . . . . . . . . . . . . . . . . . 7 3.2. Homogeneous Array . . . . . . . . . . . . . . . . . . . . 8 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Concise Binary Object Representation (CBOR, [RFC7049]) provides for the interchange of structured data without a requirement for a pre-agreed schema. RFC 7049 defines a basic set of data types, as well as a tagging mechanism that enables extending the set of data types supported via an IANA registry. Recently, a simple form of typed arrays of numeric data has received interest both in the Web graphics community [TypedArray] and in the JavaScript specification [TypedArrayES6], as well as in corresponding implementations [ArrayBuffer]. Since these typed arrays may carry significant amounts of data, there is interest in interchanging them in CBOR without the need of lengthy conversion of each number in the array. This can also save space overhead with encoding a type for each element of an array. This document defines a number of interrelated CBOR tags that cover these typed arrays, as well as two additional tags for multi- Bormann Expires April 10, 2020 [Page 2] Internet-Draft CBOR tags for typed arrays October 2019 dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the tags defined. Note that an application that generates CBOR with these tags has considerable freedom in choosing variants, e.g., with respect to endianness, embedded type (signed vs. unsigned), and number of bits per element, or whether a tag defined in this specification is used at all instead of more basic CBOR. In contrast to representation variants of single CBOR numbers, there is no representation that could be identified as "preferred". If deterministic encoding is desired in a CBOR-based protocol making use of these tags, the protocol has to define which of the encoding variants are used in which case. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The term "byte" is used in its now customary sense as a synonym for "octet". Where bit arithmetic is explained, this document uses the notation familiar from the programming language C [C] (including C++14's 0bnnn binary literals [Cplusplus]), except that the operator "**" stands for exponentiation. The term "array" is used in a general sense in this document, unless further specified. The term "classical CBOR array" describes an array represented with CBOR major type 4. A "homogeneous array" is an array of elements that are all of the same type (the term is neutral as to whether that is a representation type or an application data model type). The terms "big endian" and "little endian" are used to indicate a most significant byte first (MSB first) representation of integers, and a least significant byte first (LSB first) representation, respectively. 2. Typed Arrays Typed arrays are homogeneous arrays of numbers, all of which are encoded in a single form of binary representation. The concatenation of these representations is encoded as a single CBOR byte string (major type 2), enclosed by a single tag indicating the type and encoding of all the numbers represented in the byte string. Bormann Expires April 10, 2020 [Page 3] Internet-Draft CBOR tags for typed arrays October 2019 2.1. Types of numbers Three classes of numbers are of interest: unsigned integers (uint), signed integers (two's complement, sint), and IEEE 754 binary floating point numbers (which are always signed). For each of these classes, there are multiple representation lengths in active use: +-----------+--------+--------+-----------+ | Length ll | uint | sint | float | +-----------+--------+--------+-----------+ | 0 | uint8 | sint8 | binary16 | | 1 | uint16 | sint16 | binary32 | | 2 | uint32 | sint32 | binary64 | | 3 | uint64 | sint64 | binary128 | +-----------+--------+--------+-----------+ Table 1: Length values Here, sintN stands for a signed integer of exactly N bits (for instance, sint16), and uintN stands for an unsigned integer of exactly N bits (for instance, uint32). The name binaryN stands for the number form of the same name defined in IEEE 754 [IEEE754]. Since one objective of these tags is to be able to directly ship the ArrayBuffers underlying the Typed Arrays without re-encoding them, and these may be either in big endian (network byte order) or in little endian form, we need to define tags for both variants. In total, this leads to 24 variants. In the tag, we need to express the choice between integer and floating point, the signedness (for integers), the endianness, and one of the four length values. In order to simplify implementation, a range of tags is being allocated that allows retrieving all this information from the bits of the tag: Tag values from 64 to 87. The value is split up into 5 bit fields: 0b010_f_s_e_ll, as detailed in Table 2. Bormann Expires April 10, 2020 [Page 4] Internet-Draft CBOR tags for typed arrays October 2019 +-------+-------------------------------------------------------+ | Field | Use | +-------+-------------------------------------------------------+ | 0b010 | the constant bits 0, 1, 0 | | f | 0 for integer, 1 for float | | s | 0 for float or unsigned integer, 1 for signed integer | | e | 0 for big endian, 1 for little endian | | ll | A number for the length (Table 1). | +-------+-------------------------------------------------------+ Table 2: Bit fields in the low 8 bits of the tag The number of bytes in each array element can then be calculated by "2**(f + ll)" (or "1 << (f + ll)" in a typical programming language). (Notice that 0f and ll are the two least significant bits, respectively, of each nibble (4bit) in the byte.) In the CBOR representation, the total number of elements in the array is not expressed explicitly, but implied from the length of the byte string and the length of each representation. It can be computed from the length, in bytes, of the byte string comprising the representation of the array by inverting the previous formula: "bytelength >> (f + ll)". For the uint8/sint8 values, the endianness is redundant. Only the tag for the big endian variant is used and assigned as such. The Tag that would signify the little endian variant of sint8 MUST NOT be used, its tag number is marked as reserved. As a special case, the Tag that would signify the little endian variant of uint8 is instead assigned to signify that the numbers in the array are using clamped conversion from integers, as described in more detail in Section 7.1.11 ("ToUint8Clamp") of the ES6 JavaScript specification [TypedArrayES6]; the assumption here is that a program-internal representation of this array after decoding would be marked this way for further processing, providing "roundtripping" of JavaScript typed arrays through CBOR. IEEE 754 binary floating numbers are always signed. Therefore, for the float variants ("f" == 1), there is no need to distinguish between signed and unsigned variants; the "s" bit is always zero. The Tag numbers where "s" would be one (which would have Tag values 88 to 95) remain free to use by other specifications. 3. Additional Array Tags This specification defines three additional array tags. The Multi- dimensional Array tags can be combined with classical CBOR arrays as well as with Typed Arrays in order to build multi-dimensional arrays Bormann Expires April 10, 2020 [Page 5] Internet-Draft CBOR tags for typed arrays October 2019 with constant numbers of elements in the sub-arrays. The Homogeneous Array tag can be used as a signal by an application to identify a classical CBOR array as a homogeneous array, even when a Typed Array does not apply. 3.1. Multi-dimensional Array A multi-dimensional array is represented as a tagged array that contains two (one-dimensional) arrays. The first array defines the dimensions of the multi-dimensional array (in the sequence of outer dimensions towards inner dimensions) while the second array represents the contents of the multi-dimensional array. If the second array is itself tagged as a Typed Array then the element type of the multi-dimensional array is known to be the same type as that of the Typed Array. Two tags are defined by this document, one for elements arranged in row-major order, and one for column-major order [RowColMajor]. 3.1.1. Row-major Order Tag: 40 Data Item: array (major type 4) of two arrays, one array (major type 4) of dimensions, which are unsigned integers distinct from zero, and one array (either a CBOR array of major type 4, or a Typed Array, or a Homogeneous Array) of elements Data in the second array consists of consecutive values where the last dimension is considered contiguous (row-major order). Figure 1 shows a declaration of a two-dimensional array in the C language, a representation of that in CBOR using both a multidimensional array tag and a typed array tag. Bormann Expires April 10, 2020 [Page 6] Internet-Draft CBOR tags for typed arrays October 2019 uint16_t a[2][3] = { {2, 4, 8}, /* row 0 */ {4, 16, 256}, }; # multi-dimensional array tag 82 # array(2) 82 # array(2) 02 # unsigned(2) 1st Dimension 03 # unsigned(3) 2nd Dimension # uint16 array 4c # byte string(12) 0002 # unsigned(2) 0004 # unsigned(4) 0008 # unsigned(8) 0004 # unsigned(4) 0010 # unsigned(16) 0100 # unsigned(256) Figure 1: Multi-dimensional array in C and CBOR Figure 2 shows the same two-dimensional array using the multidimensional array tag in conjunction with a basic CBOR array (which, with the small numbers chosen for the example, happens to be shorter). # multi-dimensional array tag 82 # array(2) 82 # array(2) 02 # unsigned(2) 1st Dimension 03 # unsigned(3) 2nd Dimension 86 # array(6) 02 # unsigned(2) 04 # unsigned(4) 08 # unsigned(8) 04 # unsigned(4) 10 # unsigned(16) 19 0100 # unsigned(256) Figure 2: Multi-dimensional array using basic CBOR array 3.1.2. Column-Major order The multidimensional arrays specified in the previous sub-subsection are in "row major" order, which is the preferred order for the purposes of this specification. An analogous representation that uses "column major" order arrays is provided in this subsection under the tag 1040, as illustrated in Figure 3. Bormann Expires April 10, 2020 [Page 7] Internet-Draft CBOR tags for typed arrays October 2019 Tag: 1040 Data Item: as with tag 40, except that the data in the second array consists of consecutive values where the first dimension is considered contiguous (column-major order). # multi-dimensional array tag, column major order 82 # array(2) 82 # array(2) 02 # unsigned(2) 1st Dimension 03 # unsigned(3) 2nd Dimension 86 # array(6) 02 # unsigned(2) 04 # unsigned(4) 04 # unsigned(4) 10 # unsigned(16) 08 # unsigned(8) 19 0100 # unsigned(256) Figure 3: Multi-dimensional array using basic CBOR array, column major order 3.2. Homogeneous Array Tag: 41 Data Item: array (major type 4) This tag identifies the classical CBOR array (a one-dimensional array) tagged by it as a homogeneous array, that is, it has elements that are all of the same application model data type. The element type of the array is thus determined by the application model data type of the first array element. This can be used in application data models that apply specific semantics to homogeneous arrays. Also, in certain cases, implementations in strongly typed languages may be able to create native homogeneous arrays of specific types instead of ordered lists while decoding. Which CBOR data items constitute elements of the same application type is specific to the application. Figure 4 shows an example for a homogeneous array of booleans in C++ [Cplusplus] and CBOR. Bormann Expires April 10, 2020 [Page 8] Internet-Draft CBOR tags for typed arrays October 2019 bool boolArray[2] = { true, false }; # Homogeneous Array Tag 82 #array(2) F5 # true F4 # false Figure 4: Homogeneous array in C++ and CBOR Figure 5 extends the example with a more complex structure. typedef struct { bool active; int value; } foo; foo myArray[2] = { {true, 3}, {true, -4} }; 82 # array(2) 82 # array(2) F5 # true 03 # 3 82 # array(2) F5 # true 23 # -4 Figure 5: Homogeneous array in C++ and CBOR 4. Discussion Support for both little- and big-endian representation may seem out of character with CBOR, which is otherwise fully big endian. This support is in line with the intended use of the typed arrays and the objective not to require conversion of each array element. This specification allocates a sizable chunk out of the single-byte tag space. This use of code point space is justified by the wide use of typed arrays in data interchange. Providing a column-major order variant of the multi-dimensional array may seem superfluous to some, and useful to others. It is cheap to define the additional tag so it is available when actually needed. Allocating it out of a different number space makes the preference for row-major evident. Applying a Homogeneous Array tag to a Typed Array would usually be redundant and is therefore not provided by the present specification. Bormann Expires April 10, 2020 [Page 9] Internet-Draft CBOR tags for typed arrays October 2019 5. CDDL typenames For the use with CDDL [RFC8610], the typenames defined in Figure 6 are recommended: ta-uint8 = #6.64(bstr) ta-uint16be = #6.65(bstr) ta-uint32be = #6.66(bstr) ta-uint64be = #6.67(bstr) ta-uint8-clamped = #6.68(bstr) ta-uint16le = #6.69(bstr) ta-uint32le = #6.70(bstr) ta-uint64le = #6.71(bstr) ta-sint8 = #6.72(bstr) ta-sint16be = #6.73(bstr) ta-sint32be = #6.74(bstr) ta-sint64be = #6.75(bstr) ; reserved: #6.76(bstr) ta-sint16le = #6.77(bstr) ta-sint32le = #6.78(bstr) ta-sint64le = #6.79(bstr) ta-float16be = #6.80(bstr) ta-float32be = #6.81(bstr) ta-float64be = #6.82(bstr) ta-float128be = #6.83(bstr) ta-float16le = #6.84(bstr) ta-float32le = #6.85(bstr) ta-float64le = #6.86(bstr) ta-float128le = #6.87(bstr) homogeneous = #6.41(array) multi-dim = #6.40([dim, array]) multi-dim-column-major = #6.1040([dim, array]) Figure 6: Recommended typenames for CDDL Bormann Expires April 10, 2020 [Page 10] Internet-Draft CBOR tags for typed arrays October 2019 6. IANA Considerations IANA has allocated the tags in Table 3, with the present document as the specification reference. (The reserved value is reserved for a future revision of typed array tags.) The allocations came out of the "specification required" space (24..255), with the exception of 1040, which came out of the "first come first served" space (256..). Bormann Expires April 10, 2020 [Page 11] Internet-Draft CBOR tags for typed arrays October 2019 +------+-------------------+----------------------------------------+ | Tag | Data Item | Semantics | +------+-------------------+----------------------------------------+ | 64 | byte string | uint8 Typed Array | | 65 | byte string | uint16, big endian, Typed Array | | 66 | byte string | uint32, big endian, Typed Array | | 67 | byte string | uint64, big endian, Typed Array | | 68 | byte string | uint8 Typed Array, clamped arithmetic | | 69 | byte string | uint16, little endian, Typed Array | | 70 | byte string | uint32, little endian, Typed Array | | 71 | byte string | uint64, little endian, Typed Array | | 72 | byte string | sint8 Typed Array | | 73 | byte string | sint16, big endian, Typed Array | | 74 | byte string | sint32, big endian, Typed Array | | 75 | byte string | sint64, big endian, Typed Array | | 76 | byte string | (reserved) | | 77 | byte string | sint16, little endian, Typed Array | | 78 | byte string | sint32, little endian, Typed Array | | 79 | byte string | sint64, little endian, Typed Array | | 80 | byte string | IEEE 754 binary16, big endian, Typed | | | | Array | | 81 | byte string | IEEE 754 binary32, big endian, Typed | | | | Array | | 82 | byte string | IEEE 754 binary64, big endian, Typed | | | | Array | | 83 | byte string | IEEE 754 binary128, big endian, Typed | | | | Array | | 84 | byte string | IEEE 754 binary16, little endian, | | | | Typed Array | | 85 | byte string | IEEE 754 binary32, little endian, | | | | Typed Array | | 86 | byte string | IEEE 754 binary64, little endian, | | | | Typed Array | | 87 | byte string | IEEE 754 binary128, little endian, | | | | Typed Array | | 40 | array of two | Multi-dimensional Array, row-major | | | arrays* | order | | 1040 | array of two | Multi-dimensional Array, column-major | | | arrays* | order | | 41 | array | Homogeneous Array | +------+-------------------+----------------------------------------+ Table 3: Values for Tags *) 40 or 1040 data item: second element of outer array in data item is native CBOR array (major type 4) or Typed Array (one of Tag 64..87) Bormann Expires April 10, 2020 [Page 12] Internet-Draft CBOR tags for typed arrays October 2019 7. Security Considerations The security considerations of RFC 7049 apply; special attention is drawn to the second paragraph of Section 8 of RFC 7049. The Tag for homogeneous arrays makes a promise about its tagged data item that a maliciously constructed CBOR input can then choose to ignore. As always, the decoder therefore has to ensure that it is not driven into an undefined state by array elements that do not fulfill the promise and that it does continue to fulfill its API contract in this case as well. As with all formats that are used for data interchange, an attacker may have control over the shape of the data delivered as input to the application, which therefore needs to validate that shape before it makes it the basis of its further processing. One unique aspect that typed arrays add to this is that an attacker might substitute a Uint8ClampedArray for where the application expects a Uint8Array, or vice versa, potentially leading to very different (and unexpected) processing semantics of the in-memory data structures constructed. Applications that could be affected by this therefore will need to be careful about making this distinction in their input validation. Bormann Expires April 10, 2020 [Page 13] Internet-Draft CBOR tags for typed arrays October 2019 8. References 8.1. Normative References [C] "Information technology -- Programming languages -- C", ISO/IEC 9899, 2018. [Cplusplus] "Programming languages -- C++", ISO/IEC 14882, 2017. [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [TypedArrayES6] "22.2 TypedArray Objects", in: ECMA-262 6th Edition, The ECMAScript 2015 Language Specification, June 2015, . 8.2. Informative References [ArrayBuffer] Mozilla Developer Network, "JavaScript typed arrays", 2013, . Bormann Expires April 10, 2020 [Page 14] Internet-Draft CBOR tags for typed arrays October 2019 [RowColMajor] Wikipedia, "Row- and column-major order", September 2019, . [TypedArray] Vukicevic, V. and K. Russell, "Typed Array Specification", February 2011, . Contributors The initial draft for this specification was written by Johnathan Roatch (roatch@gmail.com). Many thanks for getting this ball rolling. Glenn Engel suggested the tags for multi-dimensional arrays and homogeneous arrays. Acknowledgements Jim Schaad provided helpful comments and reminded us that column- major order still is in use. Jeffrey Yaskin helped improve the definition of homogeneous arrays. IANA helped correct an error in a previous version. Francesca Palombini acted as a shepherd, and Alexey Melnikov as responsible area director. Elwyn Davies as Gen- ART reviewer and IESG members Martin Vigoureux, Adam Roach, Roman Danyliw, and Benjamin Kaduk helped finding further improvements of the text; thanks also to the other reviewers. Author's Address Carsten Bormann (editor) Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Bormann Expires April 10, 2020 [Page 15] ./draft-ietf-ippm-twamp-yang-13.txt0000644000764400076440000041343513316511417016417 0ustar iustyiusty IPPM WG R. Civil Internet-Draft Ciena Corporation Intended status: Standards Track A. Morton Expires: January 3, 2019 AT&T Labs R. Rahman Cisco Systems M. Jethanandani Xoriant Corporation K. Pentikousis, Ed. Travelping July 2, 2018 Two-Way Active Measurement Protocol (TWAMP) Data Model draft-ietf-ippm-twamp-yang-13 Abstract This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). The document defines the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specifies it using a NDMA- compliant YANG model. 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 https://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 3, 2019. Copyright Notice Copyright (c) 2018 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 Civil, et al. Expires January 3, 2019 [Page 1] Internet-Draft TWAMP YANG Data Model July 2018 (https://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 . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Document Organization . . . . . . . . . . . . . . . . . . 4 2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4 3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5 3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6 3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7 3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 8 4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8 4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8 4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 13 4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 14 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 48 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 11.1. Normative References . . . . . . . . . . . . . . . . . . 57 11.2. Informative References . . . . . . . . . . . . . . . . . 59 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 64 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 65 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Civil, et al. Expires January 3, 2019 [Page 2] Internet-Draft TWAMP YANG Data Model July 2018 1. Introduction The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to measure network performance parameters such as latency, bandwidth, and packet loss by sending probe packets and measuring their experience in the network. To date, TWAMP implementations do not come with a standard management framework, and, as such, implementers have no choice except to provide a proprietary mechanism. This document addresses this gap by defining the model using UML [UML] class diagrams, and formally specifying a NMDA-complaint [RFC8342] TWAMP data model using YANG 1.1 [RFC7950]. 1.1. Motivation In current TWAMP deployments the lack of a standardized data model limits the flexibility to dynamically instantiate TWAMP-based measurements across equipment from different vendors. In large, virtualized, and dynamically instantiated infrastructures where network functions are placed according to orchestration algorithms, proprietary mechanisms for managing TWAMP measurements pose severe limitations with respect to programmability. Two major trends call for standardizing TWAMP management aspects. First, it is expected that in the coming years large-scale and multi- vendor TWAMP deployments will become the norm. From an operations perspective, using several vendor-specific TWAMP configuration mechanisms when one standard mechanism could provide an alternative is expensive and inefficient. Second, the increasingly software- defined and virtualized nature of network infrastructures, based on dynamic service chains [NSC] and programmable control and management planes Software-Defined Networking (SDN): Layers and Architecture Terminology [RFC7426] requires a well-defined data model for TWAMP implementations. This document defines such a TWAMP data model and specifies it formally using the YANG 1.1 [RFC7950] data modeling language. Note to RFC Editor: Please replace the date 2018-07-02 in Section 5.2 of the draft with the date of publication of this draft as a RFC. Also, replace reference to RFC XXXX, and draft-ietf-ippm-port-twamp-test with the RFC numbers assigned to the drafts. 1.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 Civil, et al. Expires January 3, 2019 [Page 3] Internet-Draft TWAMP YANG Data Model July 2018 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Document Organization The rest of this document is organized as follows. Section 2 presents the scope and applicability of this document. Section 3 provides a high-level overview of the TWAMP data model. Section 4 details the configuration parameters of the data model and Section 5 specifies in YANG the TWAMP data model. Section 6 lists illustrative examples which conform to the YANG data model specified in this document. Appendix A elaborates these examples further. 2. Scope, Model, and Applicability The purpose of this document is the specification of a vendor- independent data model for TWAMP implementations. Figure 1 illustrates a redrawn version of the TWAMP logical model found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated with pointers to the UML [UML] diagrams provided in this document and associated with the data model of the four logical entities in a TWAMP deployment, namely the TWAMP Control-Client, Server, Session- Sender and Session-Reflector. A UML [UML] Notation Guide is available in Section 5 of the said document. As per TWAMP [RFC5357], unlabeled links in Figure 1 are left unspecified and may be proprietary protocols. [Fig. 3] [Fig. 4] +----------------+ +--------+ | Control-Client | <-- TWAMP-Control --> | Server | +----------------+ +--------+ ^ ^ | | V V +----------------+ +-------------------+ | Session-Sender | <-- TWAMP-Test --> | Session-Reflector | +----------------+ +-------------------+ [Fig. 5] [Fig. 6] Figure 1: Annotated TWAMP logical model As per TWAMP [RFC5357], a TWAMP implementation may follow a simplified logical model, in which the same node acts both as Control-Client and Session-Sender, while another node acts at the same time as TWAMP Server and Session-Reflector. Figure 2 illustrates this simplified logical model and indicates the Civil, et al. Expires January 3, 2019 [Page 4] Internet-Draft TWAMP YANG Data Model July 2018 interaction between the TWAMP configuration client and server using, for instance, NETCONF [RFC6241] or RESTCONF [RFC8040]. o-------------------o o-------------------o | Config client | | Config client | o-------------------o o-------------------o || || NETCONF || RESTCONF NETCONF || RESTCONF || || o-------------------o o-------------------o | Config server | | Config server | | [Fig. 3, 5] | | [Fig. 4, 6] | +-------------------+ +-------------------+ | Control-Client | <-- TWAMP-Control --> | Server | | | | | | Session-Sender | <-- TWAMP-Test --> | Session-Reflector | +-------------------+ +-------------------+ Figure 2: Simplified TWAMP model and protocols The data model defined in this document is orthogonal to the specific protocol used between the Config client and Config server to communicate the TWAMP configuration parameters. Operational actions such as how TWAMP-Test sessions are started and stopped, how performance measurement results are retrieved, or how stored results are cleared, and so on, are not addressed by the configuration model defined in this document. As noted above, such operational actions are not part of the TWAMP specification TWAMP [RFC5357] and hence are out of scope of this document. See also Appendix B. In addition, for operational state, current work in Registry for Performance Metrics [I-D.ietf-ippm-metric-registry], can be used to develop an independent model for the performance metrics that need to be captured and retrieved. 3. Data Model Overview The TWAMP data model includes four categories of configuration items. First, global configuration items relate to parameters that are set on a per device level. For example, the administrative status of the device with respect to whether it allows TWAMP sessions and, if so, in what capacity (e.g. Control-Client, Server or both), is a typical instance of a global configuration item. A second category includes attributes that can be configured on a per TWAMP-Control connection basis, such as the Server IP address. Civil, et al. Expires January 3, 2019 [Page 5] Internet-Draft TWAMP YANG Data Model July 2018 A third category includes attributes related to per TWAMP-Test session attributes, for instance setting different values in the Differentiated Services Code Point (DSCP) field. Finally, the data model includes attributes that relate to the operational state of the TWAMP implementation. As the TWAMP data model is described in the remaining sections of this document, readers should keep in mind the functional entity grouping illustrated in Figure 1. 3.1. Control-Client A TWAMP Control-Client has an administrative status field set at the device level that indicates whether the node is enabled to function as such. Each TWAMP Control-Client is associated with zero or more TWAMP- Control connections. The main configuration parameters of each control connection are: o A name which can be used to uniquely identify at the Control- Client a particular control connection. This name is necessary for programmability reasons because at the time of creation of a TWAMP-Control connection not all IP and TCP port number information needed to uniquely identify the connection is available. o The IP address of the interface the Control-Client will use for connections. o The IP address of the remote TWAMP Server. o Authentication and encryption attributes such as KeyID, Token and the Client Initialization Vector (Client-IV); see also Section 3.1 in OWAMP [RFC4656] and Randomness Requirements for Security [RFC4086]. Each TWAMP-Control connection, in turn, is associated with zero or more TWAMP-Test sessions. For each test session, the following configuration items should be noted: o The test session name uniquely identifies a particular test session at the Control-Client and Session-Sender. Similar to the control connections above, this unique test session name is needed because at the time of creation of a TWAMP-Test session, for example, the source UDP port number is not known to uniquely identify the test session. Civil, et al. Expires January 3, 2019 [Page 6] Internet-Draft TWAMP YANG Data Model July 2018 o The IP address and UDP port number of the Session-Sender on the path under test by TWAMP. o The IP address and UDP port number of the Session-Reflector on said path. o Information pertaining to the test packet stream, such as the test starting time, which performance metric is to be used, as defined in Registry for Performance Metrics [I-D.ietf-ippm-metric-registry], or whether the test should be repeated. 3.2. Server Each TWAMP Server has an administrative status field set at the device level to indicate whether the node is enabled to function as a TWAMP Server. Each Server is associated with zero or more TWAMP-Control connections. Each control connection is uniquely identified by the 4-tuple {Control-Client IP address, Control-Client TCP port number, Server IP address, Server TCP port}. Control connection configuration items on a TWAMP Server are read-only. 3.3. Session-Sender A TWAMP Session-Sender has an administrative status field set at the device level that indicates whether the node is enabled to function as such. There is one Session-Sender instance for each TWAMP-Test session that is initiated from the sending device. Primary configuration fields include: o The test session name MUST be identical to the corresponding test session name on the TWAMP Control-Client (Section 3.1). o The control connection name, which along with the test session name uniquely identify the TWAMP Session-Sender instance. o Information pertaining to the test packet stream, such as, the number of test packets and the packet distribution to be employed; see also Network performance measurement with periodic streams [RFC3432]. Civil, et al. Expires January 3, 2019 [Page 7] Internet-Draft TWAMP YANG Data Model July 2018 3.4. Session-Reflector Each TWAMP Session-Reflector has an administrative status field set at the device level to indicate whether the node is enabled to function as such. Each Session-Reflector is associated with zero or more TWAMP-Test sessions. For each test session, the REFWAIT timeout parameter, which determines whether to discontinue the session if no packets have been received (TWAMP [RFC5357], Section 4.2), can be configured. Read-only access to other data model parameters, such as the Sender IP address, is foreseen. Each test session can be uniquely identified by the 4-tuple mentioned in Section 3.2. 4. Data Model Parameters This section defines the TWAMP data model using UML [UML] and introduces selected parameters associated with the four TWAMP logical entities. The complete TWAMP data model specification is provided in the YANG module presented in Section 5.2. 4.1. Control-Client The client container (see Figure 3) holds items that are related to the configuration of the TWAMP Control-Client logical entity (recall Figure 1). The client container includes an administrative configuration parameter (client/admin-state) that indicates whether the device is allowed to initiate TWAMP-Control connections. Civil, et al. Expires January 3, 2019 [Page 8] Internet-Draft TWAMP YANG Data Model July 2018 +-------------+ | client | +-------------+ 1..* +-----------------------+ | admin-state |<>----------------------| mode-preference-chain | | | +-----------------------+ | | 1..* +------------+ | priority | | |<>-----| key-chain | | mode | +-------------+ +------------+ +-----------------------+ ^ | key-id | V | secret-key | | +------------+ | 0..* +------------------------+ | ctrl-connection | +------------------------+ | name | | client-ip | | server-ip | | server-tcp-port | 0..* +----------------------+ | control-packet-dscp |<>-------| test-session-request | | key-id | +----------------------+ | max-count | | name | | client-tcp-port {ro} | | sender-ip | | server-start-time {ro} | | sender-udp-port | | state {ro} | | reflector-ip | | selected-mode {ro} | | reflector-udp-port | | token {ro} | | timeout | | client-iv {ro} | | padding-length | +------------------------+ | test-packet-dscp | | start-time | +-------------+ 1 | repeat | | pm-reg-list |------<>| repeat-interval | +-------------+ | state {ro} | | pm-index | | sid {ro} | +-------------+ +----------------------+ Figure 3: TWAMP Control-Client UML class diagram The client container holds a list (mode-preference-chain) which specifies the Mode values according to their preferred order of use by the operator of this Control-Client, including the authentication and encryption Modes. Specifically, mode-preference-chain lists the mode and its corresponding priority, as a 16-bit unsigned integer. Values for the priority start with zero, the highest priority, and decreasing priority value is indicated by every increase in value by one. Civil, et al. Expires January 3, 2019 [Page 9] Internet-Draft TWAMP YANG Data Model July 2018 Depending on the Modes available in the Server Greeting, the Control- Client MUST choose the highest priority Mode from the configured mode-preference-chain list. Note that the list of preferred Modes may set multiple bit positions independently, such as when referring to the extended TWAMP features in Mixed Security Mode for TWAMP [RFC5618], Individual Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717]. If the Control-Client cannot determine an acceptable Mode, or when the bit combinations do not make sense, e.g., both authenticated and unauthenticated bit are set, it MUST respond with zero Mode bits set in the Set-up Response message, indicating it will not continue with the control connection. In addition, the client container holds a list named key-chain which relates key-id with the respective secret-key. Both the Server and the Control-Client use the same mappings from key-id to secret-key (in Figure 3); in order for this to work properly, key-id must be unique across all systems in the administrative domain. The Server, being prepared to conduct sessions with more than one Control-Client, uses key-id to choose the appropriate secret-key; a Control-Client would typically have different secret keys for different Servers. The secret-key is the shared secret, of type binary and the length SHOULD contain at least 128 bits of entropy. The key-id and secret- key encoding SHOULD follow Section 9.8 of YANG [RFC7950]. The derived key length (dkLen in PKCS #5: Password-Based Cryptography Specification Version 2.1 [RFC8018]) MUST be 16 octets for the AES Session-key used for encryption and 32 octets for the HMAC-SHA1 Session-key used for authentication; see also Section 6.10 of OWAMP [RFC4656]. Each client container also holds a list of control connections, where each item in the list describes a TWAMP control connection initiated by this Control-Client. There SHALL be one ctrl-connection per TWAMP-Control (TCP) connection that is to be initiated from this device. In turn, each ctrl-connection holds a test-session-request list. Each test-session-request holds information associated with the Control-Client for this test session. This includes information associated with the Request-TW-Session/Accept-Session message exchange (see Section 3.5 of TWAMP [RFC5357]). There SHALL be one instance of test-session-request for each TWAMP- Test session that is to be negotiated by this TWAMP-Control connection via a Request-TW-Session/Accept-Session exchange. Civil, et al. Expires January 3, 2019 [Page 10] Internet-Draft TWAMP YANG Data Model July 2018 The Control-Client is also responsible for scheduling TWAMP-Test sessions, therefore test-session-request holds information related to these actions (e.g. pm-index, repeat-interval). 4.2. Server The server container (see Figure 4) holds items that are related to the configuration of the TWAMP Server logical entity (recall Figure 1). The server container includes an administrative configuration parameter (server/admin-state) that indicates whether the device is allowed to receive TWAMP-Control connections. A device operating in the Server role cannot configure attributes on a per TWAMP-Control connection basis, as it has no foreknowledge of the incoming TWAMP-Control connections to be received. Consequently, any parameter that the Server might want to apply to an incoming control connection must be configured at the overall Server level and applied to all incoming TWAMP-Control connections. Civil, et al. Expires January 3, 2019 [Page 11] Internet-Draft TWAMP YANG Data Model July 2018 +---------------------+ | server | +---------------------+ | admin-state | 1..* +------------+ | server-tcp-port |<>------| key-chain | | servwait | +------------+ | control-packet-dscp | | key-id | | count | | secret-key | | max-count | +------------+ | modes | | | 0..* +--------------------------+ | |<>------| ctrl-connection | +---------------------+ +--------------------------+ | client-ip {ro} | | client-tcp-port {ro} | | server-ip {ro} | | server-tcp-port {ro} | | state {ro} | | control-packet-dscp {ro} | | selected-mode {ro} | | key-id {ro} | | count {ro} | | max-count {ro} | | salt {ro} | | server-iv {ro} | | challenge {ro} | +--------------------------+ Figure 4: TWAMP Server UML class diagram Each server container holds a list named key-chain which relates key- id with the respective secret-key. As mentioned in Section 4.1, both the Server and the Control-Client use the same mapping from key-id to shared secret-key; in order for this to work properly, key-id must be unique across all the systems in the administrative domain. The Server, being prepared to conduct sessions with more than one Control-Client, uses key-id to choose the appropriate secret-key; a Control-Client would typically have different secret keys for different Servers. The key-id tells the Server which shared secret- key the Control-Client wishes to use for authentication or encryption. Each incoming control connection active on the Server is represented by a ctrl-connection. There SHALL be one ctrl-connection per incoming TWAMP-Control (TCP) connection that is received and active on the Server. Each ctrl-connection can be uniquely identified by the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port}. All items in the ctrl-connection list are read-only. Civil, et al. Expires January 3, 2019 [Page 12] Internet-Draft TWAMP YANG Data Model July 2018 4.3. Session-Sender The session-sender container, illustrated in Figure 5, holds items that are related to the configuration of the TWAMP Session-Sender logical entity. The session-sender container includes an administrative parameter (session-sender/admin-state) that controls whether the device is allowed to initiate TWAMP-Test sessions. +----------------+ | session-sender | +----------------+ 0..* +---------------------------+ | admin-state |<>-----| test-session | +----------------+ +---------------------------+ | name | | ctrl-connection-name {ro} | | fill-mode | | number-of-packets | | state {ro} | | sent-packets {ro} | | rcv-packets {ro} | | last-sent-seq {ro} | | last-rcv-seq {ro} | +---------------------------+ ^ V | 1 +---------------------+ | packet-distribution | +---------------------+ | periodic / poisson | +---------------------+ | | +-------------------+ | | periodic-interval | | +-------------------+ | | +--------------+ | lambda | | max-interval | +--------------+ Figure 5: TWAMP Session-Sender UML class diagram Each TWAMP-Test session initiated by the Session-Sender will be represented by an instance of a test-session object. There SHALL be Civil, et al. Expires January 3, 2019 [Page 13] Internet-Draft TWAMP YANG Data Model July 2018 one instance of test-session for each TWAMP-Test session for which packets are being sent. 4.4. Session-Reflector The session-reflector container, illustrated in Figure 6, holds items that are related to the configuration of the TWAMP Session-Reflector logical entity. The session-reflector container includes an administrative parameter (session-reflector/admin-state) that controls whether the device is allowed to respond to incoming TWAMP-Test sessions. A device operating in the Session-Reflector role cannot configure attributes on a per-session basis, as it has no foreknowledge of what incoming sessions it will receive. As such, any parameter that the Session-Reflector might want to apply to an incoming TWAMP-Test session must be configured at the overall Session-Reflector level and are applied to all incoming sessions. Civil, et al. Expires January 3, 2019 [Page 14] Internet-Draft TWAMP YANG Data Model July 2018 +-------------------+ | session-reflector | +-------------------+ | admin-state | | refwait | +-------------------+ ^ V | | 0..* +----------------------------------------+ | test-session | +----------------------------------------+ | sid {ro} | | sender-ip {ro} | | sender-udp-port {ro} | | reflector-ip {ro} | | reflector-udp-port {ro} | | parent-connection-client-ip {ro} | | parent-connection-client-tcp-port {ro} | | parent-connection-server-ip {ro} | | parent-connection-server-tcp-port {ro} | | test-packet-dscp {ro} | | sent-packets {ro} | | rcv-packets {ro} | | last-sent-seq {ro} | | last-rcv-seq {ro} | +----------------------------------------+ Figure 6: TWAMP Session-Reflector UML class diagram Each incoming TWAMP-Test session that is active on the Session- Reflector SHALL be represented by an instance of a test-session object. All items in the test-session object are read-only. Instances of test-session are indexed by a session identifier (sid). This value is auto-allocated by the TWAMP Server as test session requests are received, and communicated back to the Control-Client in the SID field of the Accept-Session message; see Section 4.3 of TWAMP Reflect Octets and Symmetrical Size Features [RFC6038]. When attempting to retrieve operational data for active test sessions from a Session-Reflector device, the user will not know what sessions are currently active on that device, or what SIDs have been auto- allocated for these test sessions. If the user has network access to the Control-Client device, then it is possible to read the data for this session under client/ctrl-connection/test-session-request/sid and obtain the SID (see Figure 3). The user may then use this SID Civil, et al. Expires January 3, 2019 [Page 15] Internet-Draft TWAMP YANG Data Model July 2018 value as an index to retrieve an individual session-reflector/test- session instance on the Session-Reflector device. If the user has no network access to the Control-Client device, then the only option is to retrieve all test-session instances from the Session-Reflector device, and then pick out specific test-session instances of interest to the user. This could be problematic if a large number of test sessions are currently active on that device. Each Session-Reflector TWAMP-Test session contains the following 4-tuple: {parent-connection-client-ip, parent-connection-client-tcp- port, parent-connection-server-ip, parent-connection-server-tcp- port}. This 4-tuple MUST correspond to the equivalent 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port} in server/ ctrl-connection. This 4-tuple allows the user to trace back from the TWAMP-Test session to the (parent) TWAMP-Control connection that negotiated this test session. 5. Data Model This section formally specifies the TWAMP data model using YANG. 5.1. YANG Tree Diagram This section presents a simplified graphical representation of the TWAMP data model using a YANG tree diagram. Readers should keep in mind that the limit of 72 characters per line forces us to introduce artificial line breaks in some tree diagram nodes. Tree diagrams used in this document follow the notation defined in YANG Tree Diagrams [RFC8340]. module: ietf-twamp +--rw twamp +--rw client {control-client}? | +--rw admin-state? boolean | +--rw mode-preference-chain* [priority] | | +--rw priority uint16 | | +--rw mode? twamp-modes | +--rw key-chain* [key-id] | | +--rw key-id string | | +--rw secret-key? binary | +--rw ctrl-connection* [name] | +--rw name string | +--rw client-ip? inet:ip-address | +--rw server-ip inet:ip-address | +--rw server-tcp-port? inet:port-number | +--rw control-packet-dscp? inet:dscp | +--rw key-id? string Civil, et al. Expires January 3, 2019 [Page 16] Internet-Draft TWAMP YANG Data Model July 2018 | +--rw max-count-exponent? uint8 | +--ro client-tcp-port? inet:port-number | +--ro server-start-time? uint64 | +--ro repeat-count? uint64 | +--ro state? | | control-client-connection-state | +--ro selected-mode? twamp-modes | +--ro token? binary | +--ro client-iv? binary | +--rw test-session-request* [name] | +--rw name string | +--rw sender-ip? inet:ip-address | +--rw sender-udp-port? union | +--rw reflector-ip inet:ip-address | +--rw reflector-udp-port? inet:port-number | +--rw timeout? uint64 | +--rw padding-length? uint32 | +--rw test-packet-dscp? inet:dscp | +--rw start-time? uint64 | +--rw repeat? uint32 | +--rw repeat-interval? uint32 | +--rw pm-reg-list* [pm-index] | | +--rw pm-index uint16 | +--ro state? test-session-state | +--ro sid? string +--rw server {server}? | +--rw admin-state? boolean | +--rw server-tcp-port? inet:port-number | +--rw servwait? uint32 | +--rw control-packet-dscp? inet:dscp | +--rw count? uint8 | +--rw max-count-exponent? uint8 | +--rw modes? twamp-modes | +--rw key-chain* [key-id] | | +--rw key-id string | | +--rw secret-key? binary | +--ro ctrl-connection* | [client-ip client-tcp-port server-ip server-tcp-port] | +--ro client-ip inet:ip-address | +--ro client-tcp-port inet:port-number | +--ro server-ip inet:ip-address | +--ro server-tcp-port inet:port-number | +--ro state? server-ctrl-connection-state | +--ro control-packet-dscp? inet:dscp | +--ro selected-mode? twamp-modes | +--ro key-id? string | +--ro count? uint8 | +--ro max-count-exponent? uint8 Civil, et al. Expires January 3, 2019 [Page 17] Internet-Draft TWAMP YANG Data Model July 2018 | +--ro salt? binary | +--ro server-iv? binary | +--ro challenge? binary +--rw session-sender {session-sender}? | +--rw admin-state? boolean | +--rw test-session* [name] | +--rw name string | +--ro ctrl-connection-name? string | +--rw fill-mode? padding-fill-mode | +--rw number-of-packets uint32 | +--rw (packet-distribution)? | | +--:(periodic) | | | +--rw periodic-interval decimal64 | | +--:(poisson) | | +--rw lambda decimal64 | | +--rw max-interval? decimal64 | +--ro state? sender-session-state | +--ro sent-packets? uint32 | +--ro rcv-packets? uint32 | +--ro last-sent-seq? uint32 | +--ro last-rcv-seq? uint32 +--rw session-reflector {session-reflector}? +--rw admin-state? boolean +--rw refwait? uint32 +--ro test-session* [sender-ip sender-udp-port reflector-ip reflector-udp -port] +--ro sid? string +--ro sender-ip inet:ip-address +--ro sender-udp-port | dynamic-port-number +--ro reflector-ip inet:ip-address +--ro reflector-udp-port inet:port-numbe r +--ro parent-connection-client-ip? inet:ip-address +--ro parent-connection-client-tcp-port? inet:port-numbe r +--ro parent-connection-server-ip? inet:ip-address +--ro parent-connection-server-tcp-port? inet:port-numbe r +--ro test-packet-dscp? inet:dscp +--ro sent-packets? uint32 +--ro rcv-packets? uint32 +--ro last-sent-seq? uint32 +--ro last-rcv-seq? uint32 Figure 7: YANG Tree Diagram. Civil, et al. Expires January 3, 2019 [Page 18] Internet-Draft TWAMP YANG Data Model July 2018 5.2. YANG Module This section presents the YANG module for the TWAMP data model defined in this document. The module imports definitions from Common YANG Data Types [RFC6991], and references NTPv4 Specification [RFC5905], Framework for IP Performance Metrics [RFC2330], Randomness Requirements for Security [RFC4086], OWAMP [RFC4656], TWAMP [RFC5357], More Features for TWAMP [RFC5618], Individual Session Control Feature [RFC5938], TWAMP Reflect Octets and Symmetrical Size Features [RFC6038], Advances Stream and Sampling Framework [RFC7312], IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717], and OWAMP and TWAMP Well-Known Port Assignments [I-D.ietf-ippm-port-twamp-test]. file "ietf-twamp@2018-07-02.yang" module ietf-twamp { yang-version 1.1; namespace urn:ietf:params:xml:ns:yang:ietf-twamp; prefix ietf-twamp; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Types."; } organization "IETF IPPM (IP Performance Metrics) Working Group"; contact "WG Web: http://tools.ietf.org/wg/ippm/ WG List: ippm@ietf.org Editor: Ruth Civil gcivil@ciena.com Editor: Al Morton acmorton@att.com Editor: Reshad Rehman rrahman@cisco.com Editor: Mahesh Jethanandani mjethanandani@gmail.com Editor: Kostas Pentikousis k.pentikousis@travelping.com"; description "This YANG module specifies a vendor-independent data Civil, et al. Expires January 3, 2019 [Page 19] Internet-Draft TWAMP YANG Data Model July 2018 model for the Two-Way Active Measurement Protocol (TWAMP). The data model covers four TWAMP logical entities, namely, Control-Client, Server, Session-Sender, and Session-Reflector, as illustrated in the annotated TWAMP logical model (Fig. 1 of RFC XXXX). This YANG module uses features to indicate which of the four logical entities are supported by a TWAMP implementation. Copyright (c) 2018 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, 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."; revision 2018-07-02 { description "Initial Revision. Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and draft-ietf-ippm-metric-registry"; reference "RFC XXXX: TWAMP YANG Data Model."; } /* * Typedefs */ typedef twamp-modes { type bits { bit unauthenticated { position 0; description "Unauthenticated mode, in which no encryption or authentication is applied in TWAMP-Control and TWAMP-Test. KeyID, Token, and Client-IV are not used in the Set-Up-Response message. See Section 3.1 of RFC 4656."; Civil, et al. Expires January 3, 2019 [Page 20] Internet-Draft TWAMP YANG Data Model July 2018 reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; } bit authenticated { position 1; description "Authenticated mode, in which the Control-Client and Server possess a shared secret thus prohibiting 'theft of service'. As per Section 6 of RFC 4656, in 'authenticated mode, the timestamp is in the clear and is not protected cryptographically in any way, while the rest of the message has the same protection as in encrypted mode. This mode allows one to trade off cryptographic protection against accuracy of timestamps.'"; reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; } bit encrypted { position 2; description "Encrypted mode 'makes it impossible to alter timestamps undetectably' [Section 6 of RFC 4656]. See also Section 4 of RFC 7717."; reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; } bit unauth-test-encrpyt-control { position 3; description "When using the Mixed Security Mode, the TWAMP-Test protocol follows the Unauthenticated mode and the TWAMP-Control protocol the Encrypted mode."; reference "RFC 5618: Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)"; } bit individual-session-control { position 4; description "This mode enables individual test sessions using Session Identifiers."; reference "RFC 5938: Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)"; Civil, et al. Expires January 3, 2019 [Page 21] Internet-Draft TWAMP YANG Data Model July 2018 } bit reflect-octets { position 5; description "This mode indicates the reflect octets capability."; reference "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features"; } bit symmetrical-size { position 6; description "This mode indicates support for the symmetrical size sender test packet format."; reference "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features"; } bit IKEv2Derived { position 7; description "In this mode the the shared key is derived from an IKEv2 security association (SA)."; reference "RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"; } } description "Specifies the configurable TWAMP-Modes supported during a TWAMP-Control Connection setup between a Control-Client and a Server. Section 7 of RFC 7717 summarizes the TWAMP-Modes registry and points to their formal specification."; } typedef control-client-connection-state { type enumeration { enum active { description "Indicates an active TWAMP-Control connection to Server."; } enum idle { description "Indicates an idle TWAMP-Control connection to Server."; } Civil, et al. Expires January 3, 2019 [Page 22] Internet-Draft TWAMP YANG Data Model July 2018 } description "Indicates the Control-Client TWAMP-Control connection state."; } typedef test-session-state { type enumeration { enum accepted { value 0; description "Indicates an accepted TWAMP-Test session request."; } enum failed { value 1; description "Indicates a TWAMP-Test session failure due to some unspecified reason (catch-all)."; } enum internal-error { value 2; description "Indicates a TWAMP-Test session failure due to an internal error."; } enum not-supported { value 3; description "Indicates a TWAMP-Test session failure because some aspect of the TWAMP-Test session request is not supported."; } enum permanent-resource-limit { value 4; description "Indicates a TWAMP-Test session failure due to permanent resource limitations."; } enum temp-resource-limit { value 5; description "Indicates a TWAMP-Test session failure due to temporary resource limitations."; } } description "Indicates the Control-Client TWAMP-Test session state."; } Civil, et al. Expires January 3, 2019 [Page 23] Internet-Draft TWAMP YANG Data Model July 2018 typedef server-ctrl-connection-state { type enumeration { enum active { description "Indicates an active TWAMP-Control connection to the Control-Client."; } enum servwait { description "Indicates that the TWAMP-Control connection to the Control-Client is in SERVWAIT as per the definition of Section 3.1 of RFC 5357."; } } description "Indicates the Server TWAMP-Control connection state."; } typedef sender-session-state { type enumeration { enum active { description "Indicates that the TWAMP-Test session is active."; } enum failure { description "Indicates that the TWAMP-Test session has failed."; } } description "Indicates the Session-Sender TWAMP-Test session state."; } typedef padding-fill-mode { type enumeration { enum zero { description "TWAMP-Test packets are padded with all zeros."; } enum random { description "TWAMP-Test packets are padded with pseudo-random numbers."; } } description "Indicates what type of packet padding is used in the TWAMP-Test packets."; Civil, et al. Expires January 3, 2019 [Page 24] Internet-Draft TWAMP YANG Data Model July 2018 } typedef dynamic-port-number { type inet:port-number { range 49152..65535; } description "Dynamic range for port numbers."; } /* * Features */ feature control-client { description "Indicates that the device supports configuration of the TWAMP Control-Client logical entity."; } feature server { description "Indicates that the device supports configuration of the TWAMP Server logical entity."; } feature session-sender { description "Indicates that the device supports configuration of the TWAMP Session-Sender logical entity."; } feature session-reflector { description "Indicates that the device supports configuration of the TWAMP Session-Reflector logical entity."; } /* * Reusable node groups */ grouping key-management { list key-chain { key key-id; leaf key-id { type string { length 1..80; Civil, et al. Expires January 3, 2019 [Page 25] Internet-Draft TWAMP YANG Data Model July 2018 } description "KeyID used for a TWAMP-Control connection. As per Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to 80 octets in length' and is used to select which 'shared shared secret the [Control-Client] wishes to use to authenticate or encrypt'."; } leaf secret-key { type binary; description "The secret key corresponding to the KeyID for this TWAMP-Control connection."; } description "Relates KeyIDs with their respective secret keys in a TWAMP-Control connection."; } description "Used by the Control-Client and Server for TWAMP-Control key management."; } grouping maintenance-statistics { leaf sent-packets { type uint32; config false; description "Indicates the number of packets sent."; } leaf rcv-packets { type uint32; config false; description "Indicates the number of packets received."; } leaf last-sent-seq { type uint32; config false; description "Indicates the last sent sequence number."; } leaf last-rcv-seq { type uint32; config false; Civil, et al. Expires January 3, 2019 [Page 26] Internet-Draft TWAMP YANG Data Model July 2018 description "Indicates the last received sequence number."; } description "Used for TWAMP-Test maintenance statistics."; } grouping count { leaf count { type uint8 { range "10..31"; } default 15; description "Parameter communicated to the Control-Client as part of the Server Greeting message and used for deriving a key from a shared secret as per Section 3.1 of RFC 4656: MUST be a power of 2 and at least 1024. It is configured by providing said power. For example, configuring 20 here means count 2^20 = 1048576. The default is 15, meaning 2^15 = 32768."; } description "Reusable data structure for count, which is used both in the Server and the Control-Client."; } grouping max-count-exponent { leaf max-count-exponent { type uint8 { range 10..31; } default 20; description "This parameter limits the maximum Count value, which MUST be a power of 2 and at least 1024 as per RFC 5357. It is configured by providing said power. For example, configuring 10 here means max count 2^10 = 1024. The default is 20, meaning 2^20 = 1048576. A TWAMP Server uses this configured value in the Server-Greeting message sent to the Control-Client. A TWAMP Control-Client uses this configured value to prevent denial-of-service (DOS) attacks by closing the control connection to the Server if it 'receives a Server-Greeting message with Count greater that its maximum configured value', as per Section 6 of RFC 5357. Civil, et al. Expires January 3, 2019 [Page 27] Internet-Draft TWAMP YANG Data Model July 2018 Further, note that according to Section 6 of RFC 5357: 'If an attacking system sets the maximum value in Count (2**32), then the system under attack would stall for a significant period of time while it attempts to generate keys. TWAMP-compliant systems SHOULD have a configuration control to limit the maximum count value. The default max-count-exponent value SHOULD be 15 which corresponds to a maximum value of 2**15 or 32768.' RFC 5357 does not qualify 'significant period' in terms of time, but it is clear that this depends on the processing capacity available and operators need to pay attention to this security consideration."; } description "Reusable data structure for max-count which is used both at the Control-Client and the Server containers."; } /* * Configuration data nodes */ container twamp { description "TWAMP logical entity configuration grouping of four models which correspond to the four TWAMP logical entities Control-Client, Server, Session-Sender, and Session-Reflector as illustrated in Fig. 1 of RFC XXXX."; container client { if-feature control-client; description "Configuration of the TWAMP Control-Client logical entity."; leaf admin-state { type boolean; default true; description "Indicates whether the device is allowed to operate as a TWAMP Control-Client."; } Civil, et al. Expires January 3, 2019 [Page 28] Internet-Draft TWAMP YANG Data Model July 2018 list mode-preference-chain { key priority; unique mode; leaf priority { type uint16; description "Indicates the Control-Client Mode preference priority expressed as a 16-bit unsigned integer. Values for the priority start with zero, the highest priority, and decreasing priority value is indicated by every increase in value by one."; } leaf mode { type twamp-modes; description "The supported TWAMP Mode matching the corresponding priority."; } description "Indicates the Control-Client preferred order of use of the supported TWAMP Modes. Depending on the Modes available in the TWAMP Server Greeting message (see Fig. 2 of RFC 7717), the Control-Client MUST choose the highest priority Mode from the configured mode-preference-chain list."; } uses key-management; list ctrl-connection { key name; description "List of TWAMP Control-Client control connections. Each item in the list describes a control connection that will be initiated by this Control-Client"; leaf name { type string; description "A unique name used as a key to identify this individual TWAMP-Control connection on the Control-Client device."; } leaf client-ip { type inet:ip-address; description Civil, et al. Expires January 3, 2019 [Page 29] Internet-Draft TWAMP YANG Data Model July 2018 "The IP address of the local Control-Client device, to be placed in the source IP address field of the IP header in TWAMP-Control (TCP) packets belonging to this control connection. If not configured, the device SHALL choose its own source IP address."; } leaf server-ip { type inet:ip-address; mandatory true; description "The IP address of the remote Server device, which the TWAMP-Control connection will be initiated to."; } leaf server-tcp-port { type inet:port-number; default 862; description "This parameter defines the TCP port number that is to be used by this outgoing TWAMP-Control connection. Typically, this is the well-known TWAMP-Control port number (862) as per RFC 5357 However, there are known realizations of TWAMP in the field that were implemented before this well-known port number was allocated. These early implementations allowed the port number to be configured. This parameter is therefore provided for backward compatibility reasons."; } leaf control-packet-dscp { type inet:dscp; default 0; description "The DSCP value to be placed in the IP header of TWAMP-Control (TCP) packets generated by this Control-Client."; } leaf key-id { type string { length 1..80; } description "Indicates the KeyID value selected for this TWAMP-Control connection."; } Civil, et al. Expires January 3, 2019 [Page 30] Internet-Draft TWAMP YANG Data Model July 2018 uses max-count-exponent; leaf client-tcp-port { type inet:port-number; config false; description "Indicates the source TCP port number used in the TWAMP-Control packets belonging to this control connection."; } leaf server-start-time { type uint64; config false; description "Indicates the Start-Time advertised by the Server in the Server-Start message (RFC 4656, Section 3.1), representing the time when the current instantiation of the Server started operating. The timestamp format follows RFC 5905 according to Section 4.1.2 of RFC 4656."; reference "RFC 4656: OWAMP, Section 3.1 and 4.1.2, RFC 5905: NTPv4 Specification."; } leaf repeat-count { type uint64; config false; description "Indicates how many times the test session has been repeated. When a test is running, this value will be greater than 0. If the repeat parameter is non-zero, this value is smaller than or equal to the repeat parameter."; } leaf state { type control-client-connection-state; config false; description "Indicates the current state of the TWAMP-Control connection state."; } leaf selected-mode { type twamp-modes; config false; description Civil, et al. Expires January 3, 2019 [Page 31] Internet-Draft TWAMP YANG Data Model July 2018 "The TWAMP Mode that the Control-Client has chosen for this control connection as set in the Mode field of the Set-Up-Response message"; reference "RFC 4656, Section 3.1."; } leaf token { type binary { length 64; } config false; description "This parameter holds the 64 octets containing the concatenation of a 16-octet Challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication; see also the last paragraph of Section 6 in RFC 4656. If the Mode defined in RFC 7717 is selected (selected-mode), Token is limited to 16 octets."; reference "RFC 4086: Randomness Requirements for Security RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"; } leaf client-iv { type binary { length 16; } config false; description "Indicates the Control-Client Initialization Vector (Client-IV), that is generated randomly by the Control-Client. As per RFC 4656: Client-IV merely needs to be unique (i.e., it MUST never be repeated for different sessions using the same secret key; a simple way to achieve that without the use of cumbersome state is to generate the Client-IV values using a cryptographically secure pseudo-random number source. If the Mode defined in RFC 7717 is selected (selected-mode), Client-IV is limited to 12 octets."; Civil, et al. Expires January 3, 2019 [Page 32] Internet-Draft TWAMP YANG Data Model July 2018 reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP). RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"; } list test-session-request { key name; description "Information associated with the Control-Client for this test session"; leaf name { type string; description "A unique name to be used for identification of this TWAMP-Test session on the Control-Client."; } leaf sender-ip { type inet:ip-address; description "The IP address of the Session-Sender device, which is to be placed in the source IP address field of the IP header in TWAMP-Test (UDP) packets belonging to this test session. This value will be used to populate the sender address field of the Request-TW-Session message. If not configured, the device SHALL choose its own source IP address."; } leaf sender-udp-port { type union { type dynamic-port-number; type enumeration { enum autoallocate { description "Indicates that the Contol-Client will auto-allocate the TWAMP-Test (UDP) port number from the dynamic port range."; } } } Civil, et al. Expires January 3, 2019 [Page 33] Internet-Draft TWAMP YANG Data Model July 2018 default autoallocate; description "The UDP port number that is to be used by the Session-Sender for this TWAMP-Test session. The number is restricted to the dynamic port range. By default the Control-Client SHALL auto-allocate a UDP port number for this TWAMP-Test session. The configured (or auto-allocated) value is advertised in the Sender Port field of the Request-TW-session message (see Section 3.5 of RFC 5357). Note that in the scenario where a device auto-allocates a UDP port number for a session, and the repeat parameter for that session indicates that it should be repeated, the device is free to auto-allocate a different UDP port number when it negotiates the next (repeated) iteration of this session."; } leaf reflector-ip { type inet:ip-address; mandatory true; description "The IP address belonging to the remote Session-Reflector device to which the TWAMP-Test session will be initiated. This value will be used to populate the receiver address field of the Request-TW-Session message."; } leaf reflector-udp-port { type inet:port-number { range "862 | 49152..65535"; } description "This parameter defines the UDP port number that will be used by the Session-Reflector for this TWAMP-Test session. The default number is within the dynamic port range and is to be placed in the Receiver Port field of the Request-TW-Session message. The well-known port (862) MAY be used."; reference "draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP Well-Known Port Assignments."; } Civil, et al. Expires January 3, 2019 [Page 34] Internet-Draft TWAMP YANG Data Model July 2018 leaf timeout { type uint64; units seconds; default 2; description "The length of time (in seconds) that the Session-Reflector should continue to respond to packets belonging to this TWAMP-Test session after a Stop-Sessions TWAMP-Control message has been received. This value will be placed in the Timeout field of the Request-TW-Session message."; reference "RFC 5357: TWAMP, Section 3.5."; } leaf padding-length { type uint32 { range 64..4096; } description "The number of padding bytes to be added to the TWAMP-Test (UDP) packets generated by the Session-Sender. This value will be placed in the Padding Length field of the Request-TW-Session message."; reference "RFC 4656, Section 3.5."; } leaf test-packet-dscp { type inet:dscp; default 0; description "The DSCP value to be placed in the IP header of TWAMP-Test packets generated by the Session-Sender, and in the UDP header of the TWAMP-Test response packets generated by the Session-Reflector for this test session. This value will be placed in the Type-P Descriptor field of the Request-TW-Session message"; reference "RFC 5357."; } Civil, et al. Expires January 3, 2019 [Page 35] Internet-Draft TWAMP YANG Data Model July 2018 leaf start-time { type uint64; default 0; description "Time when the session is to be started (but not before the TWAMP Start-Sessions command is issued; see Section 3.4 of RFC 5357). The start-time value is placed in the Start Time field of the Request-TW-Session message. The timestamp format follows RFC 5905 as per Section 3.5 of RFC 4656. The default value of 0 indicates that the session will be started as soon as the Start-Sessions message is received."; } leaf repeat { type uint32 { range 0..4294967295; } default 0; description "This value determines if the TWAMP-Test session must be repeated. When a test session has completed, the repeat parameter is checked. The default value of 0 indicates that the session MUST NOT be repeated. If the repeat value is 1 through 4,294,967,294 then the test session SHALL be repeated using the information in repeat-interval parameter, and the parent TWAMP-Control connection for this test session is restarted to negotiate a new instance of this TWAMP-Test session. A value of 4,294,967,295 indicates that the test session SHALL be repeated *forever* using the information in repeat-interval parameter, and SHALL NOT decrement the value."; } leaf repeat-interval { when "../repeat!='0'" { description Civil, et al. Expires January 3, 2019 [Page 36] Internet-Draft TWAMP YANG Data Model July 2018 "This parameter determines the timing of repeated TWAMP-Test sessions when repeat is more than 0. When the value of repeat-interval is 0, the negotiation of a new test session SHALL begin immediately after the previous test session completes. Otherwise, the Control-Client will wait for the number of seconds specified in the repeat-interval parameter before negotiating the new instance of this TWAMP-Test session."; } type uint32; units seconds; default 0; description "Repeat interval (in seconds)."; } list pm-reg-list { key pm-index; leaf pm-index { type uint16; description "Numerical index value of a Registered Metric in the Performance Metric Registry (see ietf-ippm-metric-registry). Output statistics are specified in the corresponding Registry entry."; } description "A list of one or more Performance Metric Registry Index values, which communicate packet stream characteristics along with one or more metrics to be measured. All members of the pm-reg-list MUST have the same stream characteristics, such that they combine to specify all metrics that shall be measured on a single stream."; reference "ietf-ippm-metric-registry: Registry for Performance Metrics"; } leaf state { type test-session-state; config false; description Civil, et al. Expires January 3, 2019 [Page 37] Internet-Draft TWAMP YANG Data Model July 2018 "Indicates the TWAMP-Test session state, accepted or indication of an error."; reference "Section 3.5 of RFC 5357."; } leaf sid { type string; config false; description "The SID allocated by the Server for this TWAMP-Test session, and communicated back to the Control-Client in the SID field of the Accept-Session message"; reference "Section 4.3 of RFC 6038."; } } } } container server { if-feature server; description "Configuration of the TWAMP Server logical entity."; leaf admin-state { type boolean; default true; description "Indicates whether the device is allowed to operate as a TWAMP Server."; } leaf server-tcp-port { type inet:port-number; default 862; description "This parameter defines the well known TCP port number that is used by TWAMP-Control. The Server will listen on this port number for incoming TWAMP-Control connections. Although this is defined as a fixed value (862) in RFC 5357, there are several realizations of TWAMP in the field that were implemented before this well-known port number was allocated. These early implementations allowed the port number to be configured. This parameter is therefore provided for backward compatibility reasons."; } Civil, et al. Expires January 3, 2019 [Page 38] Internet-Draft TWAMP YANG Data Model July 2018 leaf servwait { type uint32 { range 1..604800; } units seconds; default 900; description "TWAMP-Control (TCP) session timeout, in seconds. According to Section 3.1 of RFC 5357, Server MAY discontinue any established control connection when no packet associated with that connection has been received within SERVWAIT seconds."; } leaf control-packet-dscp { type inet:dscp; description "The DSCP value to be placed in the IP header of TWAMP-Control (TCP) packets generated by the Server. Section 3.1 of RFC 5357 specifies that the server SHOULD use the DSCP value from the Control-Clients TCP SYN. However, for practical purposes TWAMP will typically be implemented using a general purpose TCP stack provided by the underlying operating system, and such a stack may not provide this information to the user. Consequently, it is not always possible to implement the behavior described in RFC 5357 in an OS-portable version of TWAMP. The default behavior if this item is not set is to use the DSCP value from the Control-Clients TCP SYN."; reference "Section 3.1 of RFC 5357."; } uses count; uses max-count-exponent; leaf modes { type twamp-modes; description "The bit mask of TWAMP Modes this Server instance is willing to support; see IANA TWAMP Modes Registry."; } Civil, et al. Expires January 3, 2019 [Page 39] Internet-Draft TWAMP YANG Data Model July 2018 uses key-management; list ctrl-connection { key "client-ip client-tcp-port server-ip server-tcp-port"; config false; description "List of all incoming TWAMP-Control (TCP) connections."; leaf client-ip { type inet:ip-address; description "The IP address on the remote Control-Client device, which is the source IP address used in the TWAMP-Control (TCP) packets belonging to this control connection."; } leaf client-tcp-port { type inet:port-number; description "The source TCP port number used in the TWAMP-Control (TCP) packets belonging to this control connection."; } leaf server-ip { type inet:ip-address; description "The IP address of the local Server device, which is the destination IP address used in the TWAMP-Control (TCP) packets belonging to this control connection."; } leaf server-tcp-port { type inet:port-number; description "The destination TCP port number used in the TWAMP-Control (TCP) packets belonging to this control connection. This will usually be the same value as the server-tcp-port configured under twamp/server. However, in the event that the user re-configured server/server-tcp-port after this control connection was initiated, this value will indicate the server-tcp-port that is actually in use for this control connection."; } leaf state { Civil, et al. Expires January 3, 2019 [Page 40] Internet-Draft TWAMP YANG Data Model July 2018 type server-ctrl-connection-state; description "Indicates the Server TWAMP-Control connection state."; } leaf control-packet-dscp { type inet:dscp; description "The DSCP value used in the IP header of the TWAMP-Control (TCP) packets sent by the Server for this control connection. This will usually be the same value as is configured in the control-packet-dscp parameter under the twamp/server container. However, in the event that the user re-configures server/dscp after this control connection is already in progress, this read-only value will show the actual dscp value in use by this TWAMP-Control connection."; } leaf selected-mode { type twamp-modes; description "The Mode that was chosen for this TWAMP-Control connection as set in the Mode field of the Set-Up-Response message."; } leaf key-id { type string { length 1..80; } description "The KeyID value that is in use by this TWAMP-Control connection as selected by Control-Client."; } uses count { description "The count value that is in use by this TWAMP-Control connection. This will usually be the same value as is configured under twamp/server. However, in the event that the user re-configured server/count after this control connection is already in progress, this read-only value will show the actual count that is in use for this TWAMP-Control connection."; } Civil, et al. Expires January 3, 2019 [Page 41] Internet-Draft TWAMP YANG Data Model July 2018 uses max-count-exponent { description "This read-only value indicates the actual max-count in use for this control connection. Usually this would be the same value as configured under twamp/server."; } leaf salt { type binary { length 16; } description "A parameter used in deriving a key from a shared secret as described in Section 3.1 of RFC 4656. It is communicated to the Control-Client as part of the Server Greeting message."; } leaf server-iv { type binary { length 16; } description "The Server Initialization Vector (IV) generated randomly by the Server."; } leaf challenge { type binary { length 16; } description "A random sequence of octets generated by the Server. As described in client/token, Challenge is used by the Control-Client to prove possession of a shared secret."; } } } container session-sender { if-feature session-sender; description "Configuration of the TWAMP Session-Sender logical entity"; leaf admin-state { type boolean; default true; description Civil, et al. Expires January 3, 2019 [Page 42] Internet-Draft TWAMP YANG Data Model July 2018 "Indicates whether the device is allowed to operate as a TWAMP Session-Sender."; } list test-session{ key name; description "List of TWAMP Session-Sender test sessions."; leaf name { type string; description "A unique name for this TWAMP-Test session to be used for identifying this test session by the Session-Sender logical entity."; } leaf ctrl-connection-name { type string; config false; description "The name of the parent TWAMP-Control connection that is responsible for negotiating this TWAMP-Test session."; } leaf fill-mode { type padding-fill-mode; default zero; description "Indicates whether the padding added to the TWAMP-Test (UDP) packets will contain pseudo-random numbers, or whether it should consist of all zeroes, as per Section 4.2.1 of RFC 5357."; } leaf number-of-packets { type uint32; mandatory true; description "The overall number of TWAMP-Test (UDP) packets to be transmitted by the Session-Sender for this test session."; } choice packet-distribution { description "Indicates the distribution to be used for transmitting Civil, et al. Expires January 3, 2019 [Page 43] Internet-Draft TWAMP YANG Data Model July 2018 the TWAMP-Test (UDP) packets."; case periodic { leaf periodic-interval { type decimal64 { fraction-digits 5; } units seconds; mandatory true; description "Indicates the time to wait (in seconds) between the first bits of TWAMP-Test (UDP) packet transmissions for this test session."; reference "RFC 3432: Network performance measurement with periodic streams"; } } case poisson { leaf lambda { type decimal64 { fraction-digits 5; } units seconds; mandatory true; description "Indicates the average time interval (in seconds) between packets in the Poisson distribution. The packet is calculated using the reciprocal of lambda and the TWAMP-Test packet size (which depends on the selected Mode and the packet padding)."; reference "RFC 2330: Framework for IP Performance Metrics"; } leaf max-interval { type decimal64 { fraction-digits 5; } units seconds; description "Indicates the maximum time (in seconds) between packet transmissions."; reference "RFC 7312: Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)"; } } } Civil, et al. Expires January 3, 2019 [Page 44] Internet-Draft TWAMP YANG Data Model July 2018 leaf state { type sender-session-state; config false; description "Indicates the Session-Sender test session state."; } uses maintenance-statistics; } } container session-reflector { if-feature session-reflector; description "Configuration of the TWAMP Session-Reflector logical entity"; leaf admin-state { type boolean; default true; description "Indicates whether the device is allowed to operate as a TWAMP Session-Reflector."; } leaf refwait { type uint32 { range 1..604800; } units seconds; default 900; description "The Session-Reflector MAY discontinue any session that has been started when no packet associated with that session has been received for REFWAIT seconds. As per Section 3.1 of RFC 5357, this timeout allows a Session-Reflector to free up resources in case of failure."; } list test-session { key "sender-ip sender-udp-port reflector-ip reflector-udp-port"; config false; description "TWAMP Session-Reflectortest sessions."; Civil, et al. Expires January 3, 2019 [Page 45] Internet-Draft TWAMP YANG Data Model July 2018 leaf sid { type string; description "An auto-allocated identifier for this TWAMP-Test session that is unique within the context of this Server/Session-Reflector device only. This value is communicated to the Control-Client that requested the test session in the SID field of the Accept-Session message."; } leaf sender-ip { type inet:ip-address; description "The IP address on the remote device, which is the source IP address used in the TWAMP-Test (UDP) packets belonging to this test session."; } leaf sender-udp-port { type dynamic-port-number; description "The source UDP port used in the TWAMP-Test packets belonging to this test session."; } leaf reflector-ip { type inet:ip-address; description "The IP address of the local Session-Reflector device, which is the destination IP address used in the TWAMP-Test (UDP) packets belonging to this test session."; } leaf reflector-udp-port { type inet:port-number { range "862 | 49152..65535"; } description "The destination UDP port number used in the TWAMP-Test (UDP) test packets belonging to this test session."; } leaf parent-connection-client-ip { type inet:ip-address; description Civil, et al. Expires January 3, 2019 [Page 46] Internet-Draft TWAMP YANG Data Model July 2018 "The IP address on the Control-Client device, which is the source IP address used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf parent-connection-client-tcp-port { type inet:port-number; description "The source TCP port number used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf parent-connection-server-ip { type inet:ip-address; description "The IP address of the Server device, which is the destination IP address used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf parent-connection-server-tcp-port { type inet:port-number; description "The destination TCP port number used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf test-packet-dscp { type inet:dscp; description "The DSCP value present in the IP header of TWAMP-Test (UDP) packets belonging to this session."; } uses maintenance-statistics; } } } } Civil, et al. Expires January 3, 2019 [Page 47] Internet-Draft TWAMP YANG Data Model July 2018 6. Data Model Examples This section presents a simple but complete example of configuring all four entities in Figure 1, based on the YANG module specified in Section 5. The example is illustrative in nature, but aims to be self-contained, i.e. were it to be executed in a real TWAMP implementation it would lead to a correctly configured test session. For completeness, examples are provided for both IPv4 and IPv6. A more elaborated example, which also includes authentication parameters, is provided in Appendix A. 6.1. Control-Client Figure 8 shows a configuration example for a Control-Client with client/admin-state enabled. In a real implementation following Figure 2 this would permit the initiation of TWAMP-Control connections and TWAMP-Test sessions. true Figure 8: XML instance enabling Control-Client operation. The following example shows a Control-Client with two instances of client/ctrl-connection, one called "RouterA" and another called "RouterB". Each TWAMP-Control connection is to a different Server. The control connection named "RouterA" has two test session requests. The TWAMP-Control connection named "RouterB" has no TWAMP-Test session requests. true RouterA 203.0.113.1 203.0.113.2 Civil, et al. Expires January 3, 2019 [Page 48] Internet-Draft TWAMP YANG Data Model July 2018 Test1 203.0.113.3 54001 203.0.113.4 50001 0 Test2 203.0.113.1 54001 203.0.113.2 50001 0 RouterB 203.0.113.1 203.0.113.3 true RouterA 2001:DB8:203:0:113::1 2001:DB8:203:0:113::2 Test1 2001:DB8:203:1:113::3 54000 2001:DB8:203:1:113::4 55000 0 Test2 2001:DB8:203:0:113::1 54001 2001:DB8:203:0:113::2 55001 Civil, et al. Expires January 3, 2019 [Page 49] Internet-Draft TWAMP YANG Data Model July 2018 0 RouterB 2001:DB8:203:0:113::1 2001:DB8:203:0:113::3 6.2. Server Figure 9 shows a configuration example for a Server with server/ admin-state enabled, which permits a device following Figure 2 to respond to TWAMP-Control connections and TWAMP-Test sessions. true Figure 9: XML instance enabling Server operation. The following example presents a Server with the TWAMP-Control connection corresponding to the control connection name (client/ctrl- connection/name) "RouterA" presented in Section 6.1. Civil, et al. Expires January 3, 2019 [Page 50] Internet-Draft TWAMP YANG Data Model July 2018 true 203.0.113.1 16341 203.0.113.2 862 active true 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 862 active 6.3. Session-Sender Figure 10 shows a configuration example for a Session-Sender with session-sender/admin-state enabled, which permits a device following Figure 2 to initiate TWAMP-Test sessions. Civil, et al. Expires January 3, 2019 [Page 51] Internet-Draft TWAMP YANG Data Model July 2018 true Figure 10: XML instance enabling Session-Sender operation. The following configuration example shows a Session-Sender with the two TWAMP-Test sessions presented in Section 6.1. true Test1 RouterA 900 1 Test2 RouterA 900 1 2 6.4. Session-Reflector This configuration example shows a Session-Reflector with session- reflector/admin-state enabled, which permits a device following Figure 2 to respond to TWAMP-Test sessions. Civil, et al. Expires January 3, 2019 [Page 52] Internet-Draft TWAMP YANG Data Model July 2018 true Figure 11: XML instance enabling Session-Reflector operation. The following example shows the two Session-Reflector TWAMP-Test sessions corresponding to the test sessions presented in Section 6.3. [note: '\' line wrapping is for formatting only] true 203.0.113.3 54000 203.0.113.4 50001 1232 203.0.113.1 16341 203.0.113.2 862 2 2 1 1 203.0.113.1 54001 192.0.2.2 50001 178943 203.0.113.1 16341 203.0.113.2 862 21 21 20 20 [note: '\' line wrapping is for formatting only] true 203.0.113.3 54000 203.0.113.4 54001 1232 203.0.113.1 16341 203.0.113.2 862 2 2 1 1 203.0.113.1 54001 192.0.2.2 55001 178943 Civil, et al. Expires January 3, 2019 [Page 54] Internet-Draft TWAMP YANG Data Model July 2018 203.0.113.1 16341 203.0.113.2 862 21 21 20 20 7. Security Considerations Virtually all existing measurement systems using TWAMP [RFC5357] are administered by the same network operator. Attacks on the measurement infrastructure could be launched by third-parties to commandeer the packet generation capability, corrupt the measurements, or other examples of nefarious acts. The YANG module specified in Section 5 of this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF [RFC6241] layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- implement secure transport is TLS [RFC5246]. The NETCONF Access Control Module (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of nodes defined in this YANG module which are writeable. These data nodes may be considered sensitive and vulnerable to attacks in some network environments. Ability to write into these nodes without proper protection can have a negative effect on the devices that support this feature. If written, the 'admin-state' node can cause unintended test sessions to be created. If the node 'number-of-packets' that dictates how many packets are sent in any particular test session is written with Civil, et al. Expires January 3, 2019 [Page 55] Internet-Draft TWAMP YANG Data Model July 2018 a large value, it can cause a test session to run longer than expected. Nodes that are particularly vulnerable include several timeout values put in the protocol to protect against sessions that are not active but are consuming resources. These are the REFWAIT timeout parameter which determine whether to discontinue the session if no packets are received, and nodes 'count' and 'max-count- exponent' which can cause a long time to be spent on PBKDF2 iterations. In addition, 'dscp' node marked with different DSCP markings, can cause the test traffic on the network to be skewed, and the result manipulated. Finally, nodes within 'mode-preference- chain' which specify the 'mode' and 'priority' values and indicate the preferred order of use by an operator, can be manipulated to send unauthenticated or non-encrypted traffic, enabling a MITM attack. Limiting access to these nodes will limit the ability to launch an attack in network environments. The 'token' node defined in the model, containing a concatenation of a Challenge, AES Session-key used for encryption, and HMAC-SHA1 Session-key used for authentication, is sensitive from a privacy perspective, and can be used to disrupt a test session. The ability to read the field should be limited to the administrator of the test network. 8. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in IETF XML Registry [RFC3688], the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-twamp Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry YANG [RFC6020]. name: ietf-twamp namespace: urn:ietf:params:xml:ns:yang:ietf-twamp prefix: twamp reference: RFC XXXX Civil, et al. Expires January 3, 2019 [Page 56] Internet-Draft TWAMP YANG Data Model July 2018 9. Acknowledgements We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell, Robert Sherman, and Marius Georgescu for their thorough and constructive reviews, comments and text suggestions. Haoxing Shen contributed to the definition of the YANG module in Section 5. Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG module and the examples in Appendix A. Kostas Pentikousis was partially supported by FP7 UNIFY (http://fp7-unify.eu), a research project partially funded by the European Community under the Seventh Framework Program (grant agreement no. 619609). The views expressed here are those of the authors only. The European Commission is not liable for any use that may be made of the information in this document. 10. Contributors Lianshu Zheng. 11. References 11.1. Normative References [I-D.ietf-ippm-metric-registry] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, "Registry for Performance Metrics", draft-ietf- ippm-metric-registry-14 (work in progress), March 2018. [I-D.ietf-ippm-port-twamp-test] Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port Assignments", draft-ietf-ippm-port-twamp-test-01 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, . Civil, et al. Expires January 3, 2019 [Page 57] Internet-Draft TWAMP YANG Data Model July 2018 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 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, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, "IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7717, DOI 10.17487/RFC7717, December 2015, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Civil, et al. Expires January 3, 2019 [Page 58] Internet-Draft TWAMP YANG Data Model July 2018 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [UML] ISO/IEC, "Information technology - Open Distributed Processing - Unified Modeling Language", April 2005. 11.2. Informative References [NSC] John, W., Pentikousis, K., et al., "Research directions in network service chaining", Proc. SDN for Future Networks and Services (SDN4FNS), Trento, Italy IEEE, November 2013. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, DOI 10.17487/RFC5618, August 2009, . [RFC5938] Morton, A. and M. Chiba, "Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, . [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, . [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, . Civil, et al. Expires January 3, 2019 [Page 59] Internet-Draft TWAMP YANG Data Model July 2018 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Appendix A. Detailed Data Model Examples This appendix extends the example presented in Section 6 by configuring more fields such as authentication parameters, DSCP values and so on. A.1. Control-Client true 0 authenticated 1 Civil, et al. Expires January 3, 2019 [Page 60] Internet-Draft TWAMP YANG Data Model July 2018 unauthenticated KeyClient1ToRouterA c2VjcmV0MQ== KeyForRouterB c2VjcmV0Mg0K RouterA 203.0.113.1 203.0.113.2 32 KeyClient1ToRouterA Test1 203.0.113.3 54000 203.0.113.4 55000 64 0 Test2 203.0.113.1 54001 203.0.113.2 55001 128 0 true 0 authenticated Civil, et al. Expires January 3, 2019 [Page 61] Internet-Draft TWAMP YANG Data Model July 2018 1 unauthenticated KeyClient1ToRouterA c2VjcmV0MQ== KeyForRouterB c2VjcmV0Mg0K RouterA 2001:DB8:203:0:113::1 2001:DB8:203:0:113::2 32 KeyClient1ToRouterA Test1 2001:DB8:10:1:1::1 54000 2001:DB8:10:1:1::2 55000 64 0 Test2 2001:DB8:203:0:113::1 54001 2001:DB8:203:0:113::2 55001 128 0 A.2. Server Civil, et al. Expires January 3, 2019 [Page 62] Internet-Draft TWAMP YANG Data Model July 2018 true 1800 32 authenticated unauthenticated 15 KeyClient1ToRouterA c2VjcmV0MQ== KeyClient10ToRouterA c2VjcmV0MTANCg== 203.0.113.1 16341 203.0.113.2 862 32 unauthenticated KeyClient1ToRouterA 15 true 1800 32 authenticated unauthenticated 15 KeyClient1ToRouterA c2VjcmV0MQ== KeyClient10ToRouterA c2VjcmV0MTANCg== 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 Civil, et al. Expires January 3, 2019 [Page 63] Internet-Draft TWAMP YANG Data Model July 2018 862 32 unauthenticated KeyClient1ToRouterA 15 A.3. Session-Sender true Test1 RouterA zero 900 1 2 2 1 1 Test2 RouterA random 900 1 2 21 21 20 20 Civil, et al. Expires January 3, 2019 [Page 64] Internet-Draft TWAMP YANG Data Model July 2018 A.4. Session-Reflector [note: '\' line wrapping is for formatting only] true 203.0.113.3 54000 203.0.113.4 55000 1232 203.0.113.1 16341 203.0.113.2 862 32 2 2 1 1 203.0.113.1 54001 192.0.2.2 55001 178943 203.0.113.1 16341 203.0.113.2 862 32 21 21 20 20 Civil, et al. Expires January 3, 2019 [Page 65] Internet-Draft TWAMP YANG Data Model July 2018 [note: '\' line wrapping is for formatting only] true 2001:DB8:10:1:1::1 54000 2001:DB8:10:1:1::2 55000 1232 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 862 32 2 2 1 1 2001:DB8:203:0:113::1 54001 2001:DB8:192:68::2 55001 178943 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 862 32 21 Civil, et al. Expires January 3, 2019 [Page 66] Internet-Draft TWAMP YANG Data Model July 2018 21 20 20 Appendix B. TWAMP Operational Commands TWAMP operational commands could be performed programmatically or manually, e.g. using a command-line interface (CLI). With respect to programmability, YANG can be used to define NETCONF Remote Procedure Calls (RPC), therefore it would be, in principle, possible to define TWAMP RPC operations for actions such as starting or stopping control connections or test sessions or groups of sessions; retrieving results; clearing stored results, and so on. However, TWAMP [RFC5357] does not attempt to describe such operational actions. Refer also to Section 2 and the unlabeled links in Figure 1. In actual deployments different TWAMP implementations may support different sets of operational commands, with different restrictions. Therefore, this document considers it the responsibility of the individual implementation to define its corresponding TWAMP operational commands data model. Authors' Addresses Ruth Civil Ciena Corporation 307 Legget Drive Kanata, ON K2K 3C8 Canada Email: gcivil@ciena.com URI: www.ciena.com Civil, et al. Expires January 3, 2019 [Page 67] Internet-Draft TWAMP YANG Data Model July 2018 Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com Reshad Rahman Cisco Systems 2000 Innovation Drive Kanata, ON K2K 3E8 Canada Email: rrahman@cisco.com Mahesh Jethanandani Xoriant Corporation 1248 Reamswood Drive Sunnyvale, CA 94089 USA Email: mjethanandani@gmail.com Kostas Pentikousis (editor) Travelping Siemensdamm 50 Berlin 13629 Germany Email: k.pentikousis@travelping.com Civil, et al. Expires January 3, 2019 [Page 68] ./draft-ietf-cbor-sequence-02.txt0000644000764400076440000004764413542706556016141 0ustar iustyiusty Network Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track September 25, 2019 Expires: March 28, 2020 Concise Binary Object Representation (CBOR) Sequences draft-ietf-cbor-sequence-02 Abstract This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor- seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. 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 "+cbor-seq" as a structured syntax suffix for CBOR Sequences. 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 https://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 28, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Bormann Expires March 28, 2020 [Page 1] Internet-Draft CBOR Sequences September 2019 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. Conventions Used in This Document . . . . . . . . . . . . 3 2. CBOR Sequence Format . . . . . . . . . . . . . . . . . . . . 3 3. The "+cbor-seq" Structured Syntax Suffix . . . . . . . . . . 4 4. Practical Considerations . . . . . . . . . . . . . . . . . . 4 4.1. Specifying CBOR Sequences in CDDL . . . . . . . . . . . . 4 4.2. Diagnostic Notation . . . . . . . . . . . . . . . . . . . 5 4.3. Optimizing CBOR Sequences for Skipping Elements . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. CoAP Content-Format Registration . . . . . . . . . . . . 7 6.3. Structured Syntax Suffix . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Concise Binary Object Representation (CBOR) [RFC7049] can be used for serialization of data in the JSON [RFC8259] data model or in its own, somewhat expanded data model. When serializing a sequence of such values, it is sometimes convenient to have a format where these sequences can simply be concatenated to obtain a serialization of the concatenated sequence of values, or to encode a sequence of values that might grow at the end by just appending further CBOR data items. This document describes the concept and format of "CBOR Sequences", which are composed of zero or more encoded CBOR data items. CBOR Sequences can be consumed (and produced) incrementally without requiring a streaming CBOR parser that is able to deliver substructures of a data item incrementally (or a streaming encoder able to encode from substructures incrementally). This document defines and registers the "application/cbor-seq" media type in the media type registry, along with a CoAP Content-Format identifier. Media type structured syntax suffixes [RFC6838] were introduced as a way for a media type to signal that it is based on Bormann Expires March 28, 2020 [Page 2] Internet-Draft CBOR Sequences September 2019 another media type as its foundation. CBOR [RFC7049] defines the "+cbor" structured syntax suffix. This document defines and registers the "+cbor-seq" structured syntax suffix in the "Structured Syntax Suffix Registry". 1.1. Conventions Used in This Document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. In this specification, the term "byte" is used in its now-customary sense as a synonym for "octet". 2. CBOR Sequence Format Formally, a CBOR Sequence is a sequence of bytes that is recursively defined as either o an empty (zero-length) sequence of bytes o the sequence of bytes making up an encoded CBOR data item [RFC7049], followed by a CBOR Sequence. In short, concatenating zero or more encoded CBOR data items generates a CBOR Sequence. (Consequently, concatenating zero or more CBOR Sequences also results in a CBOR Sequence.) There is no end of sequence indicator. (If one is desired, CBOR- encoding an array of the CBOR data model values being encoded -- employing either a definite or an indefinite length encoding -- as a single CBOR data item may actually be the more appropriate representation.) CBOR Sequences, unlike JSON Text Sequences [RFC7464], do not use a marker between items. This is possible because CBOR encoded data items are self-delimiting and the end can always be calculated. (Note that, while the early object/array-only form of JSON was self- delimiting as well, this stopped being the case when simple values such as single numbers were made valid JSON documents.) Decoding a CBOR Sequence works as follows: o If the CBOR Sequence is an empty sequence of bytes, the result is an empty sequence of CBOR data model values. Bormann Expires March 28, 2020 [Page 3] Internet-Draft CBOR Sequences September 2019 o Otherwise, decode a single CBOR data item from the bytes of the CBOR sequence, and insert the resulting CBOR data model value at the start of the result of repeating this decoding process recursively with the remaining bytes. (A streaming decoder would therefore simply deliver zero or more CBOR data model values, each as soon as the bytes making it up are available.) This means that if any data item in the sequence is not well-formed, it is not possible to reliably decode the rest of the sequence. (An implementation may be able to recover from some errors in a sequence of bytes that is almost, but not entirely a well-formed encoded CBOR data item. Handling malformed data is outside the scope of this specification.) This also means that the CBOR Sequence format can reliably detect truncation of the bytes making up the last CBOR data item in the sequence, but not entirely missing CBOR data items at the end. A CBOR Sequence decoder that is used for consuming streaming CBOR Sequence data may simply pause for more data (e.g., by suspending and later resuming decoding) in case a truncated final item is being received. 3. The "+cbor-seq" Structured Syntax Suffix The use case for the "+cbor-seq" structured syntax suffix is analogous to that for "+cbor": It SHOULD be used by a media type when parsing the bytes of the media type object as a CBOR Sequence leads to a meaningful result that is at least sometimes not just a single CBOR data item. (Without the qualification at the end, this sentence is trivially true for any +cbor media type, which of course should continue to use the "+cbor" structured syntax suffix.) Applications encountering a "+cbor-seq" media type can then either simply use generic processing if all they need is a generic view of the CBOR Sequence, or they can use generic CBOR Sequence tools for initial parsing and then implement their own specific processing on top of that generic parsing tool. 4. Practical Considerations 4.1. Specifying CBOR Sequences in CDDL In CDDL [RFC8610], CBOR sequences are already supported as contents of byte strings using the ".cborseq" control operator (Section 3.8.4 of [RFC8610]), by employing an array as the controller type: Bormann Expires March 28, 2020 [Page 4] Internet-Draft CBOR Sequences September 2019 my-embedded-cbor-seq = bytes .cborseq my-array my-array = [* my-element] my-element = my-foo / my-bar CDDL currently does not provide for unadorned CBOR sequences as a top-level subject of a specification. For now, the suggestion is to use an array, as for the ".cborseq" control operator, for the top- level rule and add English text that explains that the specification is really about a CBOR sequence with the elements of the array: ; This defines an array, the elements of which are to be used ; in a CBOR sequence: my-sequence = [* my-element] my-element = my-foo / my-bar (Future versions of CDDL may provide a notation for top-level CBOR sequences, e.g. by using a group as the top-level rule in a CDDL specification.) 4.2. Diagnostic Notation CBOR diagnostic notation (see Section 6 of [RFC7049]) or extended diagnostic notation (Appendix G of [RFC8610]) also does not provide for unadorned CBOR Sequences at this time (the latter does provide for CBOR Sequences embedded in a byte string in Appendix G.3 of [RFC8610]). In a similar spirit to the recommendation for CDDL above, this specification recommends enclosing the CBOR data items in an array. In a more informal setting, where the boundaries within which the notation is used are obvious, it is also possible to leave off the outer brackets for this array, as shown in these two examples: [1, 2, 3] 1, 2, 3 Note that it is somewhat difficult to discuss zero-length CBOR Sequences in the latter form. 4.3. Optimizing CBOR Sequences for Skipping Elements In certain applications, being able to efficiently skip an element without the need for decoding its substructure, or efficiently fanning out elements to multi-threaded decoding processes, is of the utmost importance. For these applications, byte strings (which carry length information in bytes) containing embedded CBOR can be used as the elements of a CBOR sequence: Bormann Expires March 28, 2020 [Page 5] Internet-Draft CBOR Sequences September 2019 ; This defines an array of CBOR byte strings, the elements of which ; are to be used in a CBOR sequence: my-sequence = [* my-element] my-element = bytes .cbor my-element-structure my-element-structure = my-foo / my-bar Within limits, this may also enable recovering from elements that internally are not well-formed -- the limitation is that the sequence of byte strings does need to be well-formed as such. 5. Security Considerations The security considerations of CBOR [RFC7049] apply. This format provides no cryptographic integrity protection of any kind, but can be combined with security specifications such as COSE [RFC8152] to do so. (COSE protections can be applied to an entire CBOR sequence or to each of the elements of the sequence independently; in the latter case, additional effort may be required if there is a need to protect the relationship of the elements in the sequence.) As usual, decoders must operate on input that is assumed to be untrusted. This means that decoders MUST fail gracefully in the face of malicious inputs. 6. IANA Considerations 6.1. Media Type Media types are registered in the media types registry [IANA.media-types]. IANA is requested to register the MIME media type for CBOR Sequence, application/cbor-seq, as follows: Type name: application Subtype name: cbor-seq Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See RFCthis, Section 5. Interoperability considerations: Described herein. Published specification: RFCthis. Bormann Expires March 28, 2020 [Page 6] Internet-Draft CBOR Sequences September 2019 Applications that use this media type: Data serialization and deserialization. Fragment identifier considerations: N/A Additional information: o Deprecated alias names for this type: N/A o Magic number(s): N/A o File extension(s): N/A o Macintosh file type code(s): N/A Person & email address to contact for further information: cbor@ietf.org Intended usage: COMMON Author: Carsten Bormann (cabo@tzi.org) Change controller: IETF 6.2. CoAP Content-Format Registration IANA is requested to assign a CoAP Content-Format ID for the media type "application/cbor-seq", in the CoAP Content-Formats subregistry of the core-parameter registry [IANA.core-parameters], from the "Expert Review" (0-255) range. The assigned ID is shown in Table 1. +----------------------+----------+-------+-----------+ | Media type | Encoding | ID | Reference | +----------------------+----------+-------+-----------+ | application/cbor-seq | - | TBD63 | RFCthis | +----------------------+----------+-------+-----------+ Table 1: CoAP Content-Format ID RFC editor: Please replace TBD63 by the number actually assigned and delete this paragraph. 6.3. Structured Syntax Suffix Structured Syntax Suffixes are registered within the "Structured Syntax Suffix Registry" maintained at [IANA.media-type-structured-suffix]. IANA is requested to register Bormann Expires March 28, 2020 [Page 7] Internet-Draft CBOR Sequences September 2019 the "+cbor-seq" structured syntax suffix in accordance with [RFC6838], as follows: Name: CBOR Sequence +suffix: +cbor-seq References: RFCthis Encoding considerations: binary Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +cbor-seq SHOULD be as specified for "application/cbor-seq". (At publication of this document, there is no fragment identification syntax defined for "application/cbor-seq".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor-seq" SHOULD be processed as follows: For cases defined in +cbor-seq, where the fragment identifier resolves per the +cbor-seq rules, then process as specified in +cbor-seq. For cases defined in +cbor-seq, where the fragment identifier does not resolve per the +cbor-seq rules, then process as specified in "xxx/yyy+cbor-seq". For cases not defined in +cbor-seq, then process as specified in "xxx/yyy+cbor-seq". Interoperability considerations: n/a Security considerations: See RFCthis, Section 5 Bormann Expires March 28, 2020 [Page 8] Internet-Draft CBOR Sequences September 2019 Contact: CBOR WG mailing list (cbor@ietf.org), or any IESG- designated successor. Author/Change controller: IETF 7. References 7.1. Normative References [IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", . [IANA.media-type-structured-suffix] IANA, "Structured Syntax Suffix Registry", . [IANA.media-types] IANA, "Media Types", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [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, . Bormann Expires March 28, 2020 [Page 9] Internet-Draft CBOR Sequences September 2019 [RFC8091] Wilde, E., "A Media Type Structured Syntax Suffix for JSON Text Sequences", RFC 8091, DOI 10.17487/RFC8091, February 2017, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . Acknowledgements This draft has mostly been generated from [RFC7464] by Nico Williams and [RFC8091] by Erik Wilde, which do a similar, but slightly more complicated exercise for JSON [RFC8259]. Laurence Lundblade raised an issue on the CBOR mailing list that pointed out the need for this document. Jim Schaad and John Mattsson provided helpful comments. Author's Address Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Bormann Expires March 28, 2020 [Page 10] ./draft-ietf-httpbis-expect-ct-08.txt0000644000764400076440000014426413403264142016741 0ustar iustyiusty HTTP E. Stark Internet-Draft Google Intended status: Experimental December 9, 2018 Expires: June 12, 2019 Expect-CT Extension for HTTP draft-ietf-httpbis-expect-ct-08 Abstract This document defines a new HTTP header field named Expect-CT, which allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency deployments. Further, web host operaters can use Expect-CT to ensure that, if a UA which supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/expect-ct [3]. 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 https://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 12, 2019. Stark Expires June 12, 2019 [Page 1] Internet-Draft Expect-CT December 2018 Copyright Notice Copyright (c) 2018 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 (https://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 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 5 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 5 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 6 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 7 2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 7 2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Host Processing Model . . . . . . . . . . . . . . . . . . 8 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 8 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8 2.3.1. Missing or Malformed Expect-CT Header Fields . . . . 9 2.3.2. Expect-CT Header Field Processing . . . . . . . . . . 9 2.3.3. Reporting . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 11 2.4.1. Skipping CT compliance checks . . . . . . . . . . . . 12 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 12 3.1. Generating a violation report . . . . . . . . . . . . . . 12 3.2. Sending a violation report . . . . . . . . . . . . . . . 14 3.3. Receiving a violation report . . . . . . . . . . . . . . 15 4. Usability Considerations . . . . . . . . . . . . . . . . . . 16 5. Authoring Considerations . . . . . . . . . . . . . . . . . . 16 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7.1. Hostile header attacks . . . . . . . . . . . . . . . . . 17 7.2. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 17 7.3. Amplification attacks . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.1. Header Field Registry . . . . . . . . . . . . . . . . . . 18 Stark Expires June 12, 2019 [Page 2] Internet-Draft Expect-CT December 2018 8.2. Media Types Registry . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 21 A.2. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.4. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.5. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.6. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.7. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.8. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document defines a new HTTP header field that enables UAs to identify web hosts that expect the presence of Signed Certificate Timestamps (SCTs) [I-D.ietf-trans-rfc6962-bis] in subsequent Transport Layer Security (TLS) [RFC8446] connections. Web hosts that serve the Expect-CT HTTP header field are noted by the UA as Known Expect-CT Hosts. The UA evaluates each connection to a Known Expect-CT Host for compliance with the UA's Certificate Transparency (CT) Policy. If the connection violates the CT Policy, the UA sends a report to a URI configured by the Expect-CT Host and/ or fails the connection, depending on the configuration that the Expect-CT Host has chosen. If misconfigured, Expect-CT can cause unwanted connection failures (for example, if a host deploys Expect-CT but then switches to a legitimate certificate that is not logged in Certificate Transparency logs, or if a web host operator believes their certificate to conform to all UAs' CT policies but is mistaken). Web host operators are advised to deploy Expect-CT with precautions, by using the reporting feature and gradually increasing the time interval during which the UA regards the host as a Known Expect-CT Host. These precautions can help web host operators gain confidence that their Expect-CT deployment is not causing unwanted connection failures. Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to require SCTs for the connection. Thus, the UA will not be able to detect and thwart an attack on the UA's first connection to the host. Still, Expect-CT provides value by 1) allowing UAs to detect the use of unlogged certificates after the initial communication, and 2) Stark Expires June 12, 2019 [Page 3] Internet-Draft Expect-CT December 2018 allowing web hosts to be confident that UAs are only trusting publicly-auditable certificates. Expect-CT is similar to HSTS [RFC6797] and HPKP [RFC7469]. HSTS allows web sites to declare themselves accessible only via secure connections, and HPKP allows web sites to declare their cryptographic identifies. Similarly, Expect-CT allows web sites to declare themselves accessible only via connections that are compliant with CT policy. This Expect-CT specification is compatible with [RFC6962] and [I-D.ietf-trans-rfc6962-bis], but not with future versions of Certificate Transparency. Expect-CT header fields will be ignore from web hosts which use future versions of Certificate Transparency, unless a future version of this document specifies how they should be processed. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology Terminology is defined in this section. o "Certificate Transparency Policy" is a policy defined by the UA concerning the number, sources, and delivery mechanisms of Signed Certificate Timestamps that are associated with TLS connections. The policy defines the properties of a connection that must be met in order for the UA to consider it CT-qualified. o "Certificate Transparency Qualified" describes a TLS connection for which the UA has determined that a sufficient quantity and quality of Signed Certificate Timestamps have been provided. o "CT-qualified" is an abbreviation for "Certificate Transparency Qualified". o "CT Policy" is an abbreviation for "Certificate Transparency Policy". o "Effective Expect-CT Date" is the time at which a UA observed a valid Expect-CT header field for a given host. Stark Expires June 12, 2019 [Page 4] Internet-Draft Expect-CT December 2018 o "Expect-CT Host" is a conformant host implementing the HTTP server aspects of Expect-CT. This means that an Expect-CT Host returns the "Expect-CT" HTTP response header field in its HTTP response messages sent over secure transport. The term "host" is equivalent to "server" in this specification. o "Known Expect-CT Host" is an Expect-CT Host that the UA has noted as such. See Section 2.3.2.1 for particulars. o UA is an acronym for "user agent". For the purposes of this specification, a UA is an HTTP client application typically actively manipulated by a user [RFC7230]. o "Unknown Expect-CT Host" is an Expect-CT Host that the UA has not noted. 2. Server and Client Behavior 2.1. Response Header Field Syntax The "Expect-CT" response header field is a new field defined in this specification. It is used by a server to indicate that UAs should evaluate connections to the host emitting the header field for CT compliance (Section 2.4). Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header field, using the grammar defined in [RFC5234] and the rules defined in Section 3.2 of [RFC7230]. The "#" ABNF extension is specified in Section 7 of [RFC7230]. Expect-CT = 1#expect-ct-directive expect-ct-directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token / quoted-string Figure 1: Syntax of the Expect-CT header field The directives defined in this specification are described below. The overall requirements for directives are: 1. The order of appearance of directives is not significant. 2. A given directive MUST NOT appear more than once in a given header field. Directives are either optional or required, as stipulated in their definitions. 3. Directive names are case insensitive. Stark Expires June 12, 2019 [Page 5] Internet-Draft Expect-CT December 2018 4. UAs MUST ignore any header fields containing directives, or other header field value data that do not conform to the syntax defined in this specification. In particular, UAs MUST NOT attempt to fix malformed header fields. 5. If a header field contains any directive(s) the UA does not recognize, the UA MUST ignore those directives. 6. If the Expect-CT header field otherwise satisfies the above requirements (1 through 5), and Expect-CT is not disabled for local policy reasons (as discussed in Section 2.4.1), the UA MUST process the directives it recognizes. 2.1.1. The report-uri Directive The OPTIONAL "report-uri" directive indicates the URI to which the UA SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the reports to the given URI as described in Section 3. The "report-uri" directive is REQUIRED to have a directive value, for which the syntax is defined in Figure 2. report-uri-value = absolute-URI Figure 2: Syntax of the report-uri directive value "absolute-URI" is defined in Section 4.3 of [RFC3986]. UAs MUST ignore "report-uri"s that do not use the HTTPS scheme. UAs MUST check Expect-CT compliance when the host in the "report-uri" is a Known Expect-CT Host; similarly, UAs MUST apply HSTS [RFC6797] if the host in the "report-uri" is a Known HSTS Host. UAs SHOULD make their best effort to report Expect-CT failures to the "report-uri", but they may fail to report in exceptional conditions. For example, if connecting to the "report-uri" itself incurs an Expect-CT failure or other certificate validation failure, the UA MUST cancel the connection. Similarly, if Expect-CT Host A sets a "report-uri" referring to Expect-CT Host B, and if B sets a "report- uri" referring to A, and if both hosts fail to comply to the UA's CT Policy, the UA SHOULD detect and break the loop by failing to send reports to and about those hosts. Note that the report-uri need not necessarily be in the same Internet domain or web origin as the host being reported about. Hosts are in fact encouraged to use a separate host as the report-uri, so that CT failures on the Expect-CT host do not prevent reports from being sent. Stark Expires June 12, 2019 [Page 6] Internet-Draft Expect-CT December 2018 UAs SHOULD limit the rate at which they send reports. For example, it is unnecessary to send the same report to the same "report-uri" more than once in the same web browsing session. 2.1.2. The enforce Directive The OPTIONAL "enforce" directive is a valueless directive that, if present (i.e., it is "asserted"), signals to the UA that compliance to the CT Policy should be enforced (rather than report-only) and that the UA should refuse future connections that violate its CT Policy. When both the "enforce" directive and "report-uri" directive (as defined in Figure 2) are present, the configuration is referred to as an "enforce-and-report" configuration, signalling to the UA both that compliance to the CT Policy should be enforced and that violations should be reported. 2.1.3. The max-age Directive The "max-age" directive specifies the number of seconds after the reception of the Expect-CT header field during which the UA SHOULD regard the host from whom the message was received as a Known Expect- CT Host. If a response contains an "Expect-CT" header field, then the response MUST contain an "Expect-CT" header field with a "max-age" directive. (A "max-age" directive need not appear in every "Expect-CT" header field in the response.) The "max-age" directive is REQUIRED to have a directive value, for which the syntax (after quoted-string unescaping, if necessary) is defined in Figure 3. max-age-value = delta-seconds delta-seconds = 1*DIGIT Figure 3: Syntax of the max-age directive value "delta-seconds" is used as defined in Section 1.2.1 of [RFC7234]. 2.1.4. Examples The following three examples demonstrate valid Expect-CT response header fields (where the second splits the directives into two field instances): Stark Expires June 12, 2019 [Page 7] Internet-Draft Expect-CT December 2018 Expect-CT: max-age=86400, enforce Expect-CT: max-age=86400,enforce Expect-CT: report-uri="https://foo.example/report" Expect-CT: max-age=86400,report-uri="https://foo.example/report" Figure 4: Examples of valid Expect-CT response header fields 2.2. Host Processing Model This section describes the processing model that Expect-CT Hosts implement. The model has 2 parts: (1) the processing rules for HTTP request messages received over a secure transport (e.g., authenticated, non-anonymous TLS); and (2) the processing rules for HTTP request messages received over non-secure transports, such as TCP. 2.2.1. HTTP-over-Secure-Transport Request Type An Expect-CT Host includes an Expect-CT header field in its response. The header field MUST satisfy the grammar specified in Section 2.1. Establishing a given host as an Expect-CT Host, in the context of a given UA, is accomplished as follows: 1. Over the HTTP protocol running over secure transport, by correctly returning (per this specification) a valid Expect-CT header field to the UA. 2. Through other mechanisms, such as a client-side preloaded Expect- CT Host list. 2.2.2. HTTP Request Type Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP responses conveyed over non-secure transport. 2.3. User Agent Processing Model The UA processing model relies on parsing domain names. Note that internationalized domain names SHALL be canonicalized by the UA according to the scheme in Section 10 of [RFC6797]. The UA stores Known Expect-CT Hosts and their associated Expect-CT directives. This data is collectively known as a host's "Expect-CT" metadata". Stark Expires June 12, 2019 [Page 8] Internet-Draft Expect-CT December 2018 2.3.1. Missing or Malformed Expect-CT Header Fields If an HTTP response does not include an Expect-CT header field that conforms to the grammar specified in Section 2.1, then the UA MUST NOT update any Expect-CT metadata. 2.3.2. Expect-CT Header Field Processing If the UA receives an HTTP response over a secure transport that includes an Expect-CT header field conforming to the grammar specified in Section 2.1, the UA MUST evaluate the connection on which the header field was received for compliance with the UA's CT Policy, and then process the Expect-CT header field as follows. UAs MUST ignore any Expect-CT header field received in an HTTP response conveyed over non-secure transport. If the connection does not comply with the UA's CT Policy (i.e., the connection is not CT-qualified), then the UA MUST NOT update any Expect-CT metadata. If the header field includes a "report-uri" directive, the UA SHOULD send a report to the specified "report-uri" (Section 2.3.3). If the connection complies with the UA's CT Policy (i.e., the connection is CT-qualified), then the UA MUST either: o Note the host as a Known Expect-CT Host if it is not already so noted (see Section 2.3.2.1), or o Update the UA's cached information for the Known Expect-CT Host if the "enforce", "max-age", or "report-uri" header field value directives convey information different from that already maintained by the UA. If the "max-age" directive has a value of 0, the UA MUST remove its cached Expect-CT information if the host was previously noted as a Known Expect-CT Host, and MUST NOT note this host as a Known Expect-CT Host if it is not already noted. If a UA receives an Expect-CT header field over a CT-compliant connection which uses a version of Certificate Transparency other than [RFC6962] or [I-D.ietf-trans-rfc6962-bis], the UA MUST ignore the Expect-CT header field and clear any Expect-CT metadata associated with the host. 2.3.2.1. Noting Expect-CT Upon receipt of the Expect-CT response header field over an error- free TLS connection (with X.509 certificate chain validation as described in [RFC5280], as well as the validation described in Section 2.4), the UA MUST note the host as a Known Expect-CT Host, Stark Expires June 12, 2019 [Page 9] Internet-Draft Expect-CT December 2018 storing the host's domain name and its associated Expect-CT directives in non-volatile storage. To note a host as a Known Expect-CT Host, the UA MUST set its Expect- CT metadata in its Known Expect-CT Host cache (as specified in Section 2.3.2.2, using the metadata given in the most recently received valid Expect-CT header field. For forward compatibility, the UA MUST ignore any unrecognized Expect-CT header field directives, while still processing those directives it does recognize. Section 2.1 specifies the directives "enforce", "max-age", and "report-uri", but future specifications and implementations might use additional directives. 2.3.2.2. Storage Model If the substring matching the host production from the Request-URI (of the message to which the host responded) does not exactly match an existing Known Expect-CT Host's domain name, per the matching procedure for a Congruent Match specified in Section 8.2 of [RFC6797], then the UA MUST add this host to the Known Expect-CT Host cache. The UA caches: o the Expect-CT Host's domain name, o whether the "enforce" directive is present o the Effective Expiration Date, which is the Effective Expect-CT Date plus the value of the "max-age" directive. Alternatively, the UA MAY cache enough information to calculate the Effective Expiration Date. The Effective Expiration Date is calculated from when the UA observed the Expect-CT header field and is independent of when the response was generated. o the value of the "report-uri" directive, if present. If any other metadata from optional or future Expect-CT header directives are present in the Expect-CT header field, and the UA understands them, the UA MAY note them as well. UAs MAY set an upper limit on the value of max-age, so that UAs that have noted erroneous Expect-CT hosts (whether by accident or due to attack) have some chance of recovering over time. If the server sets a max-age greater than the UA's upper limit, the UA may behave as if the server set the max-age to the UA's upper limit. For example, if the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT Host sets a max- age directive of 90 days in its Expect-CT header field, the UA may behave as if the max-age were effectively 60 days. Stark Expires June 12, 2019 [Page 10] Internet-Draft Expect-CT December 2018 (One way to achieve this behavior is for the UA to simply store a value of 60 days instead of the 90-day value provided by the Expect- CT host.) 2.3.3. Reporting If the UA receives, over a secure transport, an HTTP response that includes an Expect-CT header field with a "report-uri" directive, and the connection does not comply with the UA's CT Policy (i.e., the connection is not CT-qualified), and the UA has not already sent an Expect-CT report for this connection, then the UA SHOULD send a report to the specified "report-uri" as specified in Section 3. 2.4. Evaluating Expect-CT Connections for CT Compliance When a UA sets up a TLS connection, the UA determines whether the host is a Known Expect-CT Host according to its Known Expect-CT Host cache. An Expect-CT Host is "expired" if the effective expiration date refers to a date in the past. The UA MUST ignore any expired Expect-CT Hosts in its cache and not treat such hosts as Known Expect-CT hosts. When a UA connects to a Known Expect-CT Host using a TLS connection, if the TLS connection has no errors, then the UA will apply an additional correctness check: compliance with a CT Policy. A UA should evaluate compliance with its CT Policy whenever connecting to a Known Expect-CT Host. However, the check can be skipped for local policy reasons (as discussed in Section 2.4.1), or in the event that other checks cause the UA to terminate the connection before CT compliance is evaluated. For example, a Public Key Pinning failure [RFC7469] could cause the UA to terminate the connection before CT compliance is checked. Similarly, if the UA terminates the connection due to an Expect-CT failure, this could cause the UA to skip subsequent correctness checks. When the CT compliance check is skipped or bypassed, Expect-CT reports (Section 3) will not be sent. When CT compliance is evaluated for a Known Expect-CT Host, the UA MUST evaluate compliance when setting up the TLS session, before beginning an HTTP conversation over the TLS channel. If a connection to a Known Expect-CT Host violates the UA's CT policy (i.e., the connection is not CT-qualified), and if the Known Expect- CT Host's Expect-CT metadata indicates an "enforce" configuration, the UA MUST treat the CT compliance failure as an error. The UA MAY allow the user to bypass the error, unless connection errors should have no user recourse due to other policies in effect (such as HSTS, as described in Section 12.1 of [RFC6797]. Stark Expires June 12, 2019 [Page 11] Internet-Draft Expect-CT December 2018 If a connection to a Known Expect-CT Host violates the UA's CT policy, and if the Known Expect-CT Host's Expect-CT metadata includes a "report-uri", the UA SHOULD send an Expect-CT report to that "report-uri" (Section 3). 2.4.1. Skipping CT compliance checks It is acceptable for a UA to skip CT compliance checks for some hosts according to local policy. For example, a UA MAY disable CT compliance checks for hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform). If the UA does not evaluate CT compliance, e.g., because the user has elected to disable it, or because a presented certificate chain chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect- CT reports. 3. Reporting Expect-CT Failure When the UA attempts to connect to a Known Expect-CT Host and the connection is not CT-qualified, the UA SHOULD report Expect-CT failures to the "report-uri", if any, in the Known Expect-CT Host's Expect-CT metadata. When the UA receives an Expect-CT response header field over a connection that is not CT-qualified, if the UA has not already sent an Expect-CT report for this connection, then the UA SHOULD report Expect-CT failures to the configured "report-uri", if any. 3.1. Generating a violation report To generate a violation report object, the UA constructs a JSON [RFC8259] object with the following keys and values: o "date-time": the value for this key indicates the UTC time that the UA observed the CT compliance failure. The value is a string formatted according to Section 5.6, "Internet Date/Time Format", of [RFC3339]. o "hostname": the value is the hostname to which the UA made the original request that failed the CT compliance check. The value is provided as a string. o "port": the value is the port to which the UA made the original request that failed the CT compliance check. The value is provided as an integer. Stark Expires June 12, 2019 [Page 12] Internet-Draft Expect-CT December 2018 o "scheme": the value is the scheme with which the UA made the original request that failed the CT compliance check. The value is provided as a string. This key is optional and is assumed to be "https" if not present. o "effective-expiration-date": the value indicates the Effective Expiration Date (see Section 2.3.2.2) for the Expect-CT Host that failed the CT compliance check, in UTC. The value is provided as a string formatted according to Section 5.6 of [RFC3339] ("Internet Date/Time Format"). o "served-certificate-chain": the value is the certificate chain as served by the Expect-CT Host during TLS session setup. The value is provided as an array of strings, which MUST appear in the order that the certificates were served; each string in the array is the Privacy-Enhanced Mail (PEM) representation of each X.509 certificate as described in [RFC7468]. o "validated-certificate-chain": the value is the certificate chain as constructed by the UA during certificate chain verification. (This may differ from the value of the "served-certificate-chain" key.) The value is provided as an array of strings, which MUST appear in the order matching the chain that the UA validated; each string in the array is the Privacy-Enhanced Mail (PEM) representation of each X.509 certificate as described in [RFC7468]. The first certificate in the chain represents the end- entity certificate being verified. UAs that build certificate chains in more than one way during the validation process SHOULD send the last chain built. o "scts": the value represents the SCTs (if any) that the UA received for the Expect-CT host and their validation statuses. The value is provided as an array of JSON objects. The SCTs may appear in any order. Each JSON object in the array has the following keys: * A "version" key, with an integer value. The UA MUST set this value to "1" if the SCT is in the format defined in Section 3.2 of [RFC6962] and "2" if it is in the format defined in Section 4.5 of [I-D.ietf-trans-rfc6962-bis]. * The "status" key, with a string value that the UA MUST set to one of the following values: "unknown" (indicating that the UA does not have or does not trust the public key of the log from which the SCT was issued), "valid" (indicating that the UA successfully validated the SCT as described in Section 5.2 of [RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]), or Stark Expires June 12, 2019 [Page 13] Internet-Draft Expect-CT December 2018 "invalid" (indicating that the SCT validation failed because of a bad signature or an invalid timestamp). * The "source" key, with a string value that indicates from where the UA obtained the SCT, as defined in Section 3 of [RFC6962] and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA MUST set the value to one of "tls-extension", "ocsp", or "embedded". These correspond to the three methods of delivering SCTs in the TLS handshake that are described in Section 3.3 of [RFC6962]. * The "serialized_sct" key, with a string value. If the value of the "version" key is "1", the UA MUST set this value to the base64 encoded [RFC4648] serialized "SignedCertificateTimestamp" structure from Section 3.2 of [RFC6962]. The base64 encoding is defined in Section 4 of [RFC4648]. If the value of the "version" key is "2", the UA MUST set this value to the base64 encoded [RFC4648] serialized "TransItem" structure representing the SCT, as defined in Section 4.5 of [I-D.ietf-trans-rfc6962-bis]. o "failure-mode": the value indicates whether the Expect-CT report was triggered by an Expect-CT policy in enforce or report-only mode. The value is provided as a string. The UA MUST set this value to "enforce" if the Expect-CT metadata indicates an "enforce" configuration, and "report-only" otherwise. o "test-report": the value is set to true if the report is being sent by a testing client to verify that the report server behaves correctly. The value is provided as a boolean, and MUST be set to true if the report serves to test the server's behavior and can be discarded. 3.2. Sending a violation report The UA SHOULD report Expect-CT failures for Known Expect-CT Hosts: that is, when a connection to a Known Expect-CT Host does not comply with the UA's CT Policy and the host's Expect-CT metadata contains a "report-uri". Additionally, the UA SHOULD report Expect-CT failures for hosts for which it does not have any stored Expect-CT metadata. That is, when the UA connects to a host and receives an Expect-CT header field which contains the "report-uri" directive, the UA SHOULD report an Expect-CT failure if the the connection does not comply with the UA's CT Policy. The steps to report an Expect-CT failure are as follows. Stark Expires June 12, 2019 [Page 14] Internet-Draft Expect-CT December 2018 1. Prepare a JSON object "report object" with the single key "expect-ct-report", whose value is the result of generating a violation report object as described in Section 3.1. 2. Let "report body" be the JSON stringification of "report object". 3. Let "report-uri" be the value of the "report-uri" directive in the Expect-CT header field. 4. Send an HTTP POST request to "report-uri" with a "Content-Type" header field of "application/expect-ct-report+json", and an entity body consisting of "report body". The UA MAY perform other operations as part of sending the HTTP POST request, for example sending a CORS preflight as part of [FETCH]. Future versions of this specification may need to modify or extend the Expect-CT report format. They may do so by defining a new top- level key to contain the report, replacing the "expect-ct-report" key. Section 3.3 defines how report servers should handle report formats that they do not support. 3.3. Receiving a violation report Upon receiving an Expect-CT violation report, the report server MUST respond with a 2xx (Successful) status code if it can parse the request body as valid JSON, the report conforms to the format described in Section 3.1, and it recognizes the scheme, hostname, and port in the "scheme", "hostname", and "port" fields of the report. If the report body cannot be parsed, or the report does not conform to the format described in Section 3.1, or the report server does not expect to receive reports for the scheme, hostname, or port in the report, then the report server MUST respond with a 400 Bad Request status code. As described in Section 3.2, future versions of this specification may define new report formats that are sent with a different top- level key. If the report server does not recognize the report format, the report server MUST respond with a 501 Not Implemented status code. If the report's "test-report" key is set to true, the server MAY discard the report without further processing but MUST still return a 2xx (Successful) status code. If the "test-report" key is absent or set to false, the server SHOULD store the report for processing and analysis by the owner of the Expect-CT Host. Stark Expires June 12, 2019 [Page 15] Internet-Draft Expect-CT December 2018 4. Usability Considerations When the UA detects a Known Expect-CT Host in violation of the UA's CT Policy, end users will experience denials of service. It is advisable for UAs to explain to users why they cannot access the Expect-CT Host, e.g., in a user interface that explains that the host's certificate cannot be validated. 5. Authoring Considerations Expect-CT could be specified as a TLS extension or X.509 certificate extension instead of an HTTP response header field. Using an HTTP header field as the mechanism for Expect-CT introduces a layering mismatch: for example, the software that terminates TLS and validates Certificate Transparency information might know nothing about HTTP. Nevertheless, an HTTP header field was chosen primarily for ease of deployment. In practice, deploying new certificate extensions requires certificate authorities to support them, and new TLS extensions require server software updates, including possibly to servers outside of the site owner's direct control (such as in the case of a third-party CDN). Ease of deployment is a high priority for Expect-CT because it is intended as a temporary transition mechanism for user agents that are transitioning to universal Certificate Transparency requirements. 6. Privacy Considerations Expect-CT can be used to infer what Certificate Transparency policy a UA is using, by attempting to retrieve specially-configured websites which pass one user agents' policies but not another's. Note that this consideration is true of UAs which enforce CT policies without Expect-CT as well. Additionally, reports submitted to the "report-uri" could reveal information to a third party about which webpage is being accessed and by which IP address, by using individual "report-uri" values for individually-tracked pages. This information could be leaked even if client-side scripting were disabled. Implementations store state about Known Expect-CT Hosts, and hence which domains the UA has contacted. Implementations may choose to not store this state subject to local policy (e.g., in the private browsing mode of a web browser). Violation reports, as noted in Section 3, contain information about the certificate chain that has violated the CT policy. In some cases, such as organization-wide compromise of the end-to-end security of TLS, this may include information about the interception Stark Expires June 12, 2019 [Page 16] Internet-Draft Expect-CT December 2018 tools and design used by the organization that the organization would otherwise prefer not be disclosed. Because Expect-CT causes remotely-detectable behavior, it's advisable that UAs offer a way for privacy-sensitive end users to clear currently noted Expect-CT hosts, and allow users to query the current state of Known Expect-CT Hosts. 7. Security Considerations 7.1. Hostile header attacks When UAs support the Expect-CT header field, it becomes a potential vector for hostile header attacks against site owners. If a site owner uses a certificate issued by a certificate authority which does not embed SCTs nor serve SCTs via OCSP or TLS extension, a malicious server operator or attacker could temporarily reconfigure the host to comply with the UA's CT policy, and add the Expect-CT header field in enforcing mode with a long "max-age". Implementing user agents would note this as an Expect-CT Host (see Section 2.3.2.1). After having done this, the configuration could then be reverted to not comply with the CT policy, prompting failures. Note this scenario would require the attacker to have substantial control over the infrastructure in question, being able to obtain different certificates, change server software, or act as a man-in-the-middle in connections. Site operators can mitigate this situation by one of: reconfiguring their web server to transmit SCTs using the TLS extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis], obtaining a certificate from an alternative certificate authority which provides SCTs by one of the other methods, or by waiting for the user agents' persisted notation of this as an Expect-CT host to reach its "max-age". User agents may choose to implement mechanisms for users to cure this situation, as noted in Section 4. 7.2. Maximum max-age There is a security trade-off in that low maximum values provide a narrow window of protection for users that visit the Known Expect-CT Host only infrequently, while high maximum values might result in a denial of service to a UA in the event of a hostile header attack, or simply an error on the part of the site-owner. There is probably no ideal maximum for the "max-age" directive. Since Expect-CT is primarily a policy-expansion and investigation technology rather than an end-user protection, a value on the order Stark Expires June 12, 2019 [Page 17] Internet-Draft Expect-CT December 2018 of 30 days (2,592,000 seconds) may be considered a balance between these competing security concerns. 7.3. Amplification attacks Another kind of hostile header attack uses the "report-uri" mechanism on many hosts not currently exposing SCTs as a method to cause a denial-of-service to the host receiving the reports. If some highly- trafficked websites emitted a non-enforcing Expect-CT header field with a "report-uri", implementing UAs' reports could flood the reporting host. It is noted in Section 2.1.1 that UAs should limit the rate at which they emit reports, but an attacker may alter the Expect-CT header's fields to induce UAs to submit different reports to different URIs to still cause the same effect. 8. IANA Considerations 8.1. Header Field Registry This document registers the "Expect-CT" header field in the "Permanent Message Header Field Names" registry located at https://www.iana.org/assignments/message-headers [4]. Header field name: Expect-CT Applicable protocol: http Status: experimental Author/Change controller: IETF Specification document(s): This document Related information: (empty) 8.2. Media Types Registry The MIME media type for Expect-CT violation reports is "application/ expect-ct-report+json" (which uses the suffix established in [RFC6839]). Type name: application Subtype name: expect-ct-report+json Required parameters: n/a Optional parameters: n/a Stark Expires June 12, 2019 [Page 18] Internet-Draft Expect-CT December 2018 Encoding considerations: binary Security considerations: See Section 7 Interoperability considerations: n/a Published specification: This document Applications that use this media type: UAs that implement Certificate Transparency compliance checks and reporting 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 & email address to contact for further information: Emily Stark (estark@google.com) Intended usage: COMMON Restrictions on usage: none Author: Emily Stark (estark@google.com) Change controller: IETF 9. References 9.1. Normative References [I-D.ietf-trans-rfc6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", draft- ietf-trans-rfc6962-bis-30 (work in progress), November 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Stark Expires June 12, 2019 [Page 19] Internet-Draft Expect-CT December 2018 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 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, . [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, . [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, . [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, . [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [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, . [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, . Stark Expires June 12, 2019 [Page 20] Internet-Draft Expect-CT December 2018 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 9.2. Informative References [FETCH] WHATWG, "Fetch - Living Standard", n.d., . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 9.3. URIs [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] http://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/expect-ct [4] https://www.iana.org/assignments/message-headers Appendix A. Changes A.1. Since -07 o Editorial changes o Specify that the end-entity certificate appears first in the "validated-certificate-chain" field of an Expect-CT report. o Define how report format can be extended by future versions of this specification. Stark Expires June 12, 2019 [Page 21] Internet-Draft Expect-CT December 2018 o Add optional "scheme" key to report format. o Specify exact status codes for report server errors. o Limit report-uris to HTTPS only. o Note that this version of Expect-CT is only compatible with RFC 6962 and 6962-bis, not any future versions of CT. A.2. Since -06 o Editorial changes A.3. Since -05 o Remove SHOULD requirement that UAs disallow certificate error overrides for Known Expect-CT Hosts. o Remove restriction that Expect-CT Hosts cannot be IP addresses. o Editorial changes A.4. Since -04 o Editorial changes A.5. Since -03 o Editorial changes A.6. Since -02 o Add concept of test reports and specify that servers must respond with 2xx status codes to valid reports. o Add "failure-mode" key to reports to allow report servers to distinguish report-only from enforced failures. A.7. Since -01 o Change SCT reporting format to support both RFC 6962 and 6962-bis SCTs. A.8. Since -00 o Editorial changes Stark Expires June 12, 2019 [Page 22] Internet-Draft Expect-CT December 2018 o Change Content-Type header of reports to 'application/expect-ct- report+json' o Update header field syntax to match convention (issue #327) o Reference RFC 6962-bis instead of RFC 6962 Author's Address Emily Stark Google Email: estark@google.com Stark Expires June 12, 2019 [Page 23] ./draft-ietf-clue-data-model-schema-17.txt0000644000764400076440000045012312753613400017561 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-ipwave-ipv6-over-80211ocb-52.txt0000644000764400076440000023112613523336504017653 0ustar iustyiusty IPWAVE Working Group N. Benamar Internet-Draft Moulay Ismail University of Meknes Intended status: Standards Track J. Haerri Expires: February 10, 2020 Eurecom J. Lee Sangmyung University T. Ernst YoGoKo August 9, 2019 Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside the Context of a Basic Service Set draft-ietf-ipwave-ipv6-over-80211ocb-52 Abstract This document provides methods and settings, for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios is not covered in this specification and is subject of future work. 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 https://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 10, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Benamar, et al. Expires February 10, 2020 [Page 1] Internet-Draft IPv6-over-80211-OCB August 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9 5.2. MAC Address and Interface ID Generation . . . . . . . . . 9 5.3. Pseudonymization impact on confidentiality and trust . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16 Appendix C. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver . . . . . . . . . . . . . 20 Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 21 Appendix E. Design Considerations . . . . . . . . . . . . . . . 22 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 22 Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23 G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24 G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 26 Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 28 Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Links . . . . . . . . . . . . . . . . . . . . . . . 29 Benamar, et al. Expires February 10, 2020 [Page 2] Internet-Draft IPv6-over-80211-OCB August 2019 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This document provides a baseline for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and Appendix C) with minimal changes to existing stacks. Moreover, the document identifies limitations of such usage. Concretely, the document describes the layering of IPv6 networking on top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame translation underneath. The resulting stack is derived from IPv6 over Ethernet [RFC2464], but operates over 802.11-OCB to provide at least P2P (Point to Point) connectivity using IPv6 ND and link-local addresses. The IPv6 network layer operates on 802.11-OCB in the same manner as operating on Ethernet with the following exceptions: o Exceptions due to different operation of IPv6 network layer on 802.11 than on Ethernet. The operation of IP on Ethernet is described in [RFC1042] and [RFC2464]. o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. This has impacts on security, privacy, subnet structure and movement detection. Security and privacy recommendations are discussed in Section 5 and Section 4.4. The subnet structure is described in Section 4.6. The movement detection on OCB links is not described in this document. Likewise, ND Extensions and IPWAVE optimizations for vehicular communications are not in scope. The expectation is that further specifications will be edited to cover more complex vehicular networking scenarios. The reader may refer to [I-D.ietf-ipwave-vehicular-networking] for an overview of problems related to running IPv6 over 802.11-OCB. It is out of scope of this document to reiterate those. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The document makes uses of the following terms: IP-OBU (Internet Protocol On-Board Unit): an IP-OBU denotes a computer situated in a vehicle such as a car, bicycle, or similar. It has at least one IP Benamar, et al. Expires February 10, 2020 [Page 3] Internet-Draft IPv6-over-80211-OCB August 2019 interface that runs in mode OCB of 802.11, and that has an "OBU" transceiver. See the definition of the term "OBU" in section Appendix H. IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It has at least two distinct IP-enabled interfaces. The wireless PHY/ MAC layer of at least one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode. An IP-RSU communicates with the IP- OBU in the vehicle over 802.11 wireless link operating in OCB mode. An IP-RSU is similar to an Access Network Router (ANR) defined in [RFC3753], and a Wireless Termination Point (WTP) defined in [RFC5415]. OCB (outside the context of a basic service set - BSS): is a mode of operation in which a STA is not a member of a BSS and does not utilize IEEE Std 802.11 authentication, association, or data confidentiality. 802.11-OCB: refers to the mode specified in IEEE Std 802.11-2016 when the MIB attribute dot11OCBActivited is 'true'. 3. Communication Scenarios where IEEE 802.11-OCB Links are Used The IEEE 802.11-OCB networks are used for vehicular communications, as 'Wireless Access in Vehicular Environments'. In particular, we refer the reader to [I-D.ietf-ipwave-vehicular-networking], that lists some scenarios and requirements for IP in Intelligent Transportation Systems (ITS). The link model is the following: STA --- 802.11-OCB --- STA. In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. All links are assumed to be P2P and multiple links can be on one radio interface. While 802.11-OCB is clearly specified, and a legacy IPv6 stack can operate on such links, the use of the operating environment (vehicular networks) brings in new perspectives. 4. IPv6 over 802.11-OCB 4.1. Maximum Transmission Unit (MTU) The default MTU for IP packets on 802.11-OCB is inherited from [RFC2464] and is, as such, 1500 octets. As noted in [RFC8200], every link on the Internet must have a minimum MTU of 1280 octets, as well as follow the other recommendations, especially with regard to fragmentation. Benamar, et al. Expires February 10, 2020 [Page 4] Internet-Draft IPv6-over-80211-OCB August 2019 4.2. Frame Format IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE 802.11 spec [IEEE-802.11-2016]. The IPv6 packet transmitted on 802.11-OCB are immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol Discrimination (EPD, see Appendix D), the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to the 802.11 data service SHOULD use a 'priority' value of 1 (QoS with a 'Background' user priority), reserving higher priority values for safety-critical and time- sensitive traffic, including the ones listed in [ETSI-sec-archi]. To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY implement IPv6-over-Ethernet as per [RFC2464] and then a frame translation from 802.3 to 802.11 in order to minimize the code changes. 4.3. Link-Local Addresses There are several types of IPv6 addresses [RFC4291], [RFC4193], that may be assigned to an 802.11-OCB interface. Among these types of addresses only the IPv6 link-local addresses can be formed using an EUI-64 identifier, in particular during transition time, (the time spent before an interface starts using a different address than the LL one). If the IPv6 link-local address is formed using an EUI-64 identifier, then the mechanism of forming that address is the same mechanism as used to form an IPv6 link-local address on Ethernet links. Moreover, whether or not the interface identifier is derived from the EUI-64 identifier, its length is 64 bits as is the case for Ethernet [RFC2464]. 4.4. Stateless Autoconfiguration The steps a host takes in deciding how to autoconfigure its interfaces in IPv6 are described in [RFC4862]. This section describes the formation of Interface Identifiers for IPv6 addresses of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6 address of type 'Link-Local' are discussed in Section 4.3. The RECOMMENDED method for forming stable Interface Identifiers (IIDs) is described in [RFC8064]. The method of forming IIDs described in Section 4 of [RFC2464] MAY be used during transition Benamar, et al. Expires February 10, 2020 [Page 5] Internet-Draft IPv6-over-80211-OCB August 2019 time, in particular for IPv6 link-local addresses. Regardless of how to form the IID, its length is 64 bits, similarely to IPv6 over Ethernet [RFC2464]. The bits in the IID have no specific meaning and the identifier should be treated as an opaque value. The bits 'Universal' and 'Group' in the identifier of an 802.11-OCB interface are significant, as this is an IEEE link-layer address. The details of this significance are described in [RFC7136]. Semantically opaque IIDs, instead of meaningful IIDs derived from a valid and meaningful MAC address ([RFC2464], Section 4), help avoid certain privacy risks (see the risks mentioned in Section 5.1.1). If semantically opaque IIDs are needed, they may be generated using the method for generating semantically opaque IIDs with IPv6 Stateless Address Autoconfiguration given in [RFC7217]. Typically, an opaque IID is formed starting from identifiers different than the MAC addresses, and from cryptographically strong material. Thus, privacy sensitive information is absent from Interface IDs, because it is impossible to calculate back the initial value from which the Interface ID was first generated. Some applications that use IPv6 packets on 802.11-OCB links (among other link types) may benefit from IPv6 addresses whose IIDs don't change too often. It is RECOMMENDED to use the mechanisms described in RFC 7217 to permit the use of Stable IIDs that do not change within one subnet prefix. A possible source for the Net-Iface Parameter is a virtual interface name, or logical interface name, that is decided by a local administrator. 4.5. Address Mapping Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces specified in Sections 6 and 7 of [RFC2464]. 4.5.1. Address Mapping -- Unicast This document is scoped for Address Resolution (AR) and Duplicate Address Detection (DAD) per [RFC4862]. 4.5.2. Address Mapping -- Multicast The multicast address mapping is performed according to the method specified in section 7 of [RFC2464]. The meaning of the value "3333" mentioned there is defined in section 2.3.1 of [RFC7042]. Benamar, et al. Expires February 10, 2020 [Page 6] Internet-Draft IPv6-over-80211-OCB August 2019 Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues [I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be exacerbated in OCB mode. A future improvement to this specification should consider solutions for these problems. 4.6. Subnet Structure When vehicles are in close range, a subnet may be formed over 802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix List conceptual data structure ([RFC4861] Section 5.1) is maintained for each 802.11-OCB interface. IPv6 Neighbor Discovery protocol (ND) requires reflexive properties (bidirectional connectivity) which is generally, though not always, the case for P2P OCB links. IPv6 ND also requires transitive properties for DAD and AR, so an IPv6 subnet can be mapped on an OCB network only if all nodes in the network share a single physical broadcast domain. The extension to IPv6 ND operating on a subnet that covers multiple OCB links and not fully overlapping (NBMA) is not in scope. Finally, IPv6 ND requires a permanent connectivity of all nodes in the subnet to defend their addresses, in other words very stable network conditions. The structure of this subnet is ephemeral, in that it is strongly influenced by the mobility of vehicles: the hidden terminal effects appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' networks with an addressing model as described in [RFC5889]. On another hand, the structure of the internal subnets in each vehicle is relatively stable. As recommended in [RFC5889], when the timing requirements are very strict (e.g., fast-drive-through IP-RSU coverage), no on-link subnet prefix should be configured on an 802.11-OCB interface. In such cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. Additionally, even if the timing requirements are not very strict (e.g., the moving subnet formed by two following vehicles is stable, a fixed IP-RSU is absent), the subnet is disconnected from the Internet (i.e., a default route is absent), and the addressing peers are equally qualified (that is, it is impossible to determine that some vehicle owns and distributes addresses to others) the use of link-local addresses is RECOMMENDED. The baseline ND protocol [RFC4861] MUST be supported over 802.11-OCB links. Transmitting ND packets may prove to have some performance issues as mentioned in Section 4.5.2, and Appendix I. These issues may be exacerbated in OCB mode. Solutions for these problems should Benamar, et al. Expires February 10, 2020 [Page 7] Internet-Draft IPv6-over-80211-OCB August 2019 consider the OCB mode of operation. Future solutions to OCB should consider solutions for avoiding broadcast. The best of current knowledge indicates the kinds of issues that may arise with ND in OCB mode; they are described in Appendix I. Protocols like Mobile IPv6 [RFC6275] , [RFC3963] and DNAv6 [RFC6059], which depend on a timely movement detection, might need additional tuning work to handle the lack of link-layer notifications during handover. This is for further study. 5. Security Considerations Any security mechanism at the IP layer or above that may be carried out for the general case of IPv6 may also be carried out for IPv6 operating over 802.11-OCB. The OCB operation does not use existing 802.11 link-layer security mechanisms. There is no encryption applied below the network layer running on 802.11-OCB. At the application layer, the IEEE 1609.2 document [IEEE-1609.2] provides security services for certain applications to use; application-layer mechanisms are out of scope of this document. On another hand, a security mechanism provided at networking layer, such as IPsec [RFC4301], may provide data security protection to a wider range of applications. 802.11-OCB does not provide any cryptographic protection, because it operates outside the context of a BSS (no Association Request/ Response, no Challenge messages). Therefore, an attacker can sniff or inject traffic while within range of a vehicle or IP-RSU (by setting an interface card's frequency to the proper range). Also, an attacker may not heed to legal limits for radio power and can use a very sensitive directional antenna; if attackers wishe to attack a given exchange they do not necessarily need to be in close physical proximity. Hence, such a link is less protected than commonly used links (wired link or aforementioned 802.11 links with link-layer security). Therefore, any node can join a subnet, directly communicate with any nodes on the subset to include potentially impersonating another node. This design allows for a number of threats outlined in Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971], [RFC3972] is a solution that can address Spoof-Based Attack Vectors. 5.1. Privacy Considerations As with all Ethernet and 802.11 interface identifiers ([RFC7721]), the identifier of an 802.11-OCB interface may involve privacy, MAC address spoofing and IP hijacking risks. A vehicle embarking an IP- Benamar, et al. Expires February 10, 2020 [Page 8] Internet-Draft IPv6-over-80211-OCB August 2019 OBU whose egress interface is 802.11-OCB may expose itself to eavesdropping and subsequent correlation of data. This may reveal data considered private by the vehicle owner; there is a risk of being tracked. In outdoors public environments, where vehicles typically circulate, the privacy risks are more important than in indoors settings. It is highly likely that attacker sniffers are deployed along routes which listen for IEEE frames, including IP packets, of vehicles passing by. For this reason, in the 802.11-OCB deployments, there is a strong necessity to use protection tools such as dynamically changing MAC addresses Section 5.2, semantically opaque Interface Identifiers and stable Interface Identifiers Section 4.4. An example of change policy is to change the MAC address of the OCB interface each time the system boots up. This may help mitigate privacy risks to a certain level. Furthermore, for privacy concerns, ([RFC8065]) recommends using an address generation scheme rather than addresses generated from a fixed link-layer address. However, there are some specificities related to vehicles. Since roaming is an important characteristic of moving vehicles, the use of the same Link-Local Address over time can indicate the presence of the same vehicle in different places and thus leads to location tracking. Hence, a vehicle should get hints about a change of environment (e.g. , engine running, GPS, etc..) and renew the IID in its LLAs. 5.1.1. Privacy Risks of Meaningful info in Interface IDs The privacy risks of using MAC addresses displayed in Interface Identifiers are important. The IPv6 packets can be captured easily in the Internet and on-link in public roads. For this reason, an attacker may realize many attacks on privacy. One such attack on 802.11-OCB is to capture, store and correlate Company ID information present in MAC addresses of many cars (e.g. listen for Router Advertisements, or other IPv6 application data packets, and record the value of the source address in these packets). Further correlation of this information with other data captured by other means, or other visual information (car color, others) may constitute privacy risks. 5.2. MAC Address and Interface ID Generation In 802.11-OCB networks, the MAC addresses may change during well defined renumbering events. In the moment the MAC address is changed on an 802.11-OCB interface all the Interface Identifiers of IPv6 addresses assigned to that interface MUST change. Implementations should use a policy dictating when the MAC address is changed on the 802.11-OCB interface. For more information on the Benamar, et al. Expires February 10, 2020 [Page 9] Internet-Draft IPv6-over-80211-OCB August 2019 motivation of this policy please refer to the privacy discussion in Appendix B. A 'randomized' MAC address has the following characteristics: o Bit "Local/Global" set to "locally administered". o Bit "Unicast/Multicast" set to "Unicast". o The 46 remaining bits are set to a random value, using a random number generator that meets the requirements of [RFC4086]. To meet the randomization requirements for the 46 remaining bits, a hash function may be used. For example, the [SHA256] hash function may be used with input a 256 bit local secret, the 'nominal' MAC Address of the interface, and a representation of the date and time of the renumbering event. A randomized Interface ID has the same characteristics of a randomized MAC address, except the length in bits. 5.3. Pseudonymization impact on confidentiality and trust Vehicles 'and drivers' privacy relies on pseudonymization mechanisms such as the ones described in Section 5.2. This pseudonymization means that upper-layer protocols and applications SHOULD NOT rely on layer-2 or layer-3 addresses to assume that the other participant can be trusted. 6. IANA Considerations No request to IANA. 7. Contributors Christian Huitema, Tony Li. Romain Kuntz contributed extensively about IPv6 handovers between links running outside the context of a BSS (802.11-OCB links). Tim Leinmueller contributed the idea of the use of IPv6 over 802.11-OCB for distribution of certificates. Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey Voronov provided significant feedback on the experience of using IP messages over 802.11-OCB in initial trials. Benamar, et al. Expires February 10, 2020 [Page 10] Internet-Draft IPv6-over-80211-OCB August 2019 Michelle Wetterwald contributed extensively the MTU discussion, offered the ETSI ITS perspective, and reviewed other parts of the document. 8. Acknowledgements The authors would like to thank Alexandre Petrescu for initiating this work and for being the lead author until the version 43 of this draft. The authors would like to thank Pascal Thubert for reviewing, proofreading and suggesting modifications of this document. The authors would like to thank Mohamed Boucadair for proofreading and suggesting modifications of this document. The authors would like to thank Eric Vyncke for reviewing suggesting modifications of this document. The authors would like to thank Witold Klaudel, Ryuji Wakikawa, Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo, Lorenzo Colitti, Pascal Thubert, Ole Troan, Jinmei Tatuya, Joel Halpern, Eric Gray and William Whyte. Their valuable comments clarified particular issues and generally helped to improve the document. Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB drivers for linux and described how. For the multicast discussion, the authors would like to thank Owen DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and participants to discussions in network working groups. The authors would like to thank participants to the Birds-of- a-Feather "Intelligent Transportation Systems" meetings held at IETF in 2016. Human Rights Protocol Considerations review by Amelia Andersdotter. Benamar, et al. Expires February 10, 2020 [Page 11] Internet-Draft IPv6-over-80211-OCB August 2019 9. References 9.1. Normative References [IEEE-802.11-2016] "IEEE Standard 802.11-2016 - IEEE Standard for Information Technology - Telecommunications and information exchange between systems Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. Status - Active Standard. Description retrieved freely; the document itself is also freely available, but with some difficulty (requires registration); description and document retrieved on April 8th, 2019, starting from URL https://standards.ieee.org/findstds/ standard/802.11-2016.html". [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, DOI 10.17487/RFC1042, February 1988, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . Benamar, et al. Expires February 10, 2020 [Page 12] Internet-Draft IPv6-over-80211-OCB August 2019 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [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, . [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, . [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, . [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, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . Benamar, et al. Expires February 10, 2020 [Page 13] Internet-Draft IPv6-over-80211-OCB August 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 9.2. Informative References [ETSI-sec-archi] "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical Specification, Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management, November 2016. Downloaded on September 9th, 2017, freely available from ETSI website at URL http://www.etsi.org/deliver/ etsi_ts/102900_102999/102940/01.02.01_60/ ts_102940v010201p.pdf". [I-D.ietf-ipwave-vehicular-networking] Jeong, J., "IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", draft-ietf- ipwave-vehicular-networking-11 (work in progress), July 2019. [I-D.ietf-mboned-ieee802-mcast-problems] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", draft-ietf-mboned-ieee802-mcast-problems-07 (work in progress), July 2019. [IEEE-1609.2] "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Security Services for Applications and Management Messages. Example URL http://ieeexplore.ieee.org/document/7426684/ accessed on August 17th, 2017.". [IEEE-1609.3] "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Networking Services. Example URL http://ieeexplore.ieee.org/document/7458115/ accessed on August 17th, 2017.". Benamar, et al. Expires February 10, 2020 [Page 14] Internet-Draft IPv6-over-80211-OCB August 2019 [IEEE-1609.4] "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Multi-Channel Operation. Example URL http://ieeexplore.ieee.org/document/7435228/ accessed on August 17th, 2017.". [IEEE-802.11p-2010] "IEEE Std 802.11p (TM)-2010, IEEE Standard for Information Technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 6: Wireless Access in Vehicular Environments; document freely available at URL http://standards.ieee.org/getieee802/ download/802.11p-2010.pdf retrieved on September 20th, 2013.". [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, . [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, . [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, DOI 10.17487/RFC6959, May 2013, . Benamar, et al. Expires February 10, 2020 [Page 15] Internet-Draft IPv6-over-80211-OCB August 2019 [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, . [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, . [SHA256] "Secure Hash Standard (SHS), National Institute of Standards and Technology. https://csrc.nist.gov/CSRC/media/Publications/fips/180/2/ archive/2002-08-01/documents/fips180-2.pdf". Appendix A. 802.11p The term "802.11p" is an earlier definition. The behaviour of "802.11p" networks is rolled in the document IEEE Std 802.11-2016. In that document the term 802.11p disappears. Instead, each 802.11p feature is conditioned by the IEEE Management Information Base (MIB) attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated is set to true the IEEE Std 802.11-OCB state is activated. For example, an 802.11 STAtion operating outside the context of a basic service set has the OCBActivated flag set. Such a station, when it has the flag set, uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. Appendix B. Aspects introduced by the OCB mode to 802.11 In the IEEE 802.11-OCB mode, all nodes in the wireless range can directly communicate with each other without involving authentication or association procedures. In OCB mode, the manner in which channels are selected and used is simplified compared to when in BSS mode. Contrary to BSS mode, at link layer, it is necessary to set statically the same channel number (or frequency) on two stations that need to communicate with each other (in BSS mode this channel set operation is performed automatically during 'scanning'). The manner in which stations set their channel number in OCB mode is not specified in this document. Stations STA1 and STA2 can exchange IP packets only if they are set on the same channel. At IP layer, they then discover each other by using the IPv6 Neighbor Discovery protocol. The allocation of a particular channel for a particular use is defined statically in standards authored by ETSI (in Europe), FCC in America, and similar organisations in South Korea, Japan and other parts of the world. Briefly, the IEEE 802.11-OCB mode has the following properties: Benamar, et al. Expires February 10, 2020 [Page 16] Internet-Draft IPv6-over-80211-OCB August 2019 o The use by each node of a 'wildcard' BSSID (i.e., each bit of the BSSID is set to 1) o No IEEE 802.11 Beacon frames are transmitted o No authentication is required in order to be able to communicate o No association is needed in order to be able to communicate o No encryption is provided in order to be able to communicate o Flag dot11OCBActivated is set to true All the nodes in the radio communication range (IP-OBU and IP-RSU) receive all the messages transmitted (IP-OBU and IP-RSU) within the radio communications range. The eventual conflict(s) are resolved by the MAC CDMA function. The message exchange diagram in Figure 1 illustrates a comparison between traditional 802.11 and 802.11 in OCB mode. The 'Data' messages can be IP packets such as HTTP or others. Other 802.11 management and control frames (non IP) may be transmitted, as specified in the 802.11 standard. For information, the names of these messages as currently specified by the 802.11 standard are listed in Appendix F. STA AP STA1 STA2 | | | | |<------ Beacon -------| |<------ Data -------->| | | | | |---- Probe Req. ----->| |<------ Data -------->| |<--- Probe Res. ------| | | | | |<------ Data -------->| |---- Auth Req. ------>| | | |<--- Auth Res. -------| |<------ Data -------->| | | | | |---- Asso Req. ------>| |<------ Data -------->| |<--- Asso Res. -------| | | | | |<------ Data -------->| |<------ Data -------->| | | |<------ Data -------->| |<------ Data -------->| (i) 802.11 Infrastructure mode (ii) 802.11-OCB mode Figure 1: Difference between messages exchanged on 802.11 (left) and 802.11-OCB (right) Benamar, et al. Expires February 10, 2020 [Page 17] Internet-Draft IPv6-over-80211-OCB August 2019 The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010 [IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007, titled "Amendment 6: Wireless Access in Vehicular Environments". Since then, this amendment has been integrated in IEEE 802.11(TM) -2012 and -2016 [IEEE-802.11-2016]. In document 802.11-2016, anything qualified specifically as "OCBActivated", or "outside the context of a basic service" set to be true, then it is actually referring to OCB aspects introduced to 802.11. In order to delineate the aspects introduced by 802.11-OCB to 802.11, we refer to the earlier [IEEE-802.11p-2010]. The amendment is concerned with vehicular communications, where the wireless link is similar to that of Wireless LAN (using a PHY layer specified by 802.11a/b/g/n), but which needs to cope with the high mobility factor inherent in scenarios of communications between moving vehicles, and between vehicles and fixed infrastructure deployed along roads. While 'p' is a letter identifying the Amendment, just like 'a, b, g' and 'n' are, 'p' is concerned more with MAC modifications, and a little with PHY modifications; the others are mainly about PHY modifications. It is possible in practice to combine a 'p' MAC with an 'a' PHY by operating outside the context of a BSS with OFDM at 5.4GHz and 5.9GHz. The 802.11-OCB links are specified to be compatible as much as possible with the behaviour of 802.11a/b/g/n and future generation IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer offers practically the same interface to IP as the 802.11a/b/g/n and 802.3. A packet sent by an IP-OBU may be received by one or multiple IP-RSUs. The link-layer resolution is performed by using the IPv6 Neighbor Discovery protocol. To support this similarity statement (IPv6 is layered on top of LLC on top of 802.11-OCB, in the same way that IPv6 is layered on top of LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on top of 802.3 (for Ethernet)) it is useful to analyze the differences between 802.11-OCB and 802.11 specifications. During this analysis, we note that whereas 802.11-OCB lists relatively complex and numerous changes to the MAC layer (and very little to the PHY layer), there are only a few characteristics which may be important for an implementation transmitting IPv6 packets on 802.11-OCB links. The most important 802.11-OCB point which influences the IPv6 functioning is the OCB characteristic; an additional, less direct influence, is the maximum bandwidth afforded by the PHY modulation/ demodulation methods and channel access specified by 802.11-OCB. The maximum bandwidth theoretically possible in 802.11-OCB is 54 Mbit/s Benamar, et al. Expires February 10, 2020 [Page 18] Internet-Draft IPv6-over-80211-OCB August 2019 (when using, for example, the following parameters: 20 MHz channel; modulation 64-QAM; coding rate R is 3/4); in practice of IP-over- 802.11-OCB a commonly observed figure is 12Mbit/s; this bandwidth allows the operation of a wide range of protocols relying on IPv6. o Operation Outside the Context of a BSS (OCB): the (earlier 802.11p) 802.11-OCB links are operated without a Basic Service Set (BSS). This means that the frames IEEE 802.11 Beacon, Association Request/Response, Authentication Request/Response, and similar, are not used. The used identifier of BSS (BSSID) has a hexadecimal value always 0xffffffffffff (48 '1' bits, represented as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to an arbitrary BSSID value set by administrator (e.g. 'My-Home-AccessPoint'). The OCB operation - namely the lack of beacon-based scanning and lack of authentication - should be taken into account when the Mobile IPv6 protocol [RFC6275] and the protocols for IP layer security [RFC4301] are used. The way these protocols adapt to OCB is not described in this document. o Timing Advertisement: is a new message defined in 802.11-OCB, which does not exist in 802.11a/b/g/n. This message is used by stations to inform other stations about the value of time. It is similar to the time as delivered by a GNSS system (Galileo, GPS, ...) or by a cellular system. This message is optional for implementation. o Frequency range: this is a characteristic of the PHY layer, with almost no impact on the interface between MAC and IP. However, it is worth considering that the frequency range is regulated by a regional authority (ARCEP, ECC/CEPT based on ENs from ETSI, FCC, etc.); as part of the regulation process, specific applications are associated with specific frequency ranges. In the case of 802.11-OCB, the regulator associates a set of frequency ranges, or slots within a band, to the use of applications of vehicular communications, in a band known as "5.9GHz". The 5.9GHz band is different from the 2.4GHz and 5GHz bands used by Wireless LAN. However, as with Wireless LAN, the operation of 802.11-OCB in "5.9GHz" bands is exempt from owning a license in EU (in US the 5.9GHz is a licensed band of spectrum; for the fixed infrastructure an explicit FCC authorization is required; for an on-board device a 'licensed-by-rule' concept applies: rule certification conformity is required.) Technical conditions are different than those of the bands "2.4GHz" or "5GHz". The allowed power levels, and implicitly the maximum allowed distance between vehicles, is of 33dBm for 802.11-OCB (in Europe), compared to 20 dBm for Wireless LAN 802.11a/b/g/n; this leads to a maximum distance of approximately 1km, compared to approximately 50m. Benamar, et al. Expires February 10, 2020 [Page 19] Internet-Draft IPv6-over-80211-OCB August 2019 Additionally, specific conditions related to congestion avoidance, jamming avoidance, and radar detection are imposed on the use of DSRC (in US) and on the use of frequencies for Intelligent Transportation Systems (in EU), compared to Wireless LAN (802.11a/b/g/n). o 'Half-rate' encoding: as the frequency range, this parameter is related to PHY, and thus has not much impact on the interface between the IP layer and the MAC layer. o In vehicular communications using 802.11-OCB links, there are strong privacy requirements with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses, in these settings there exists a strong need for dynamic change of these addresses (as opposed to the non- vehicular settings - real wall protection - where fixed MAC addresses do not currently pose some privacy risks). This is further described in Section 5. A relevant function is described in documents IEEE 1609.3-2016 [IEEE-1609.3] and IEEE 1609.4-2016 [IEEE-1609.4]. Appendix C. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver The 802.11p amendment modifies both the 802.11 stack's physical and MAC layers but all the induced modifications can be quite easily obtained by modifying an existing 802.11a ad-hoc stack. Conditions for a 802.11a hardware to be 802.11-OCB compliant: o The PHY entity shall be an orthogonal frequency division multiplexing (OFDM) system. It must support the frequency bands on which the regulator recommends the use of ITS communications, for example using IEEE 802.11-OCB layer, in France: 5875MHz to 5925MHz. o The OFDM system must provide a "half-clocked" operation using 10 MHz channel spacings. o The chip transmit spectrum mask must be compliant to the "Transmit spectrum mask" from the IEEE 802.11p amendment (but experimental environments tolerate otherwise). o The chip should be able to transmit up to 44.8 dBm when used by the US government in the United States, and up to 33 dBm in Europe; other regional conditions apply. Changes needed on the network stack in OCB mode: Benamar, et al. Expires February 10, 2020 [Page 20] Internet-Draft IPv6-over-80211-OCB August 2019 o Physical layer: * The chip must use the Orthogonal Frequency Multiple Access (OFDM) encoding mode. * The chip must be set in half-mode rate mode (the internal clock frequency is divided by two). * The chip must use dedicated channels and should allow the use of higher emission powers. This may require modifications to the local computer file that describes regulatory domains rules, if used by the kernel to enforce local specific restrictions. Such modifications to the local computer file must respect the location-specific regulatory rules. MAC layer: * All management frames (beacons, join, leave, and others) emission and reception must be disabled except for frames of subtype Action and Timing Advertisement (defined below). * No encryption key or method must be used. * Packet emission and reception must be performed as in ad-hoc mode, using the wildcard BSSID (ff:ff:ff:ff:ff:ff). * The functions related to joining a BSS (Association Request/ Response) and for authentication (Authentication Request/Reply, Challenge) are not called. * The beacon interval is always set to 0 (zero). * Timing Advertisement frames, defined in the amendment, should be supported. The upper layer should be able to trigger such frames emission and to retrieve information contained in received Timing Advertisements. Appendix D. Protocol Layering A more theoretical and detailed view of layer stacking, and interfaces between the IP layer and 802.11-OCB layers, is illustrated in Figure 2. The IP layer operates on top of the EtherType Protocol Discrimination (EPD); this Discrimination layer is described in IEEE Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP (Link Layer Control Service Access Point). Benamar, et al. Expires February 10, 2020 [Page 21] Internet-Draft IPv6-over-80211-OCB August 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ { LLC_SAP } 802.11-OCB +-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary | EPD | | | | | MLME | | +-+-+-{ MAC_SAP }+-+-+-| MLME_SAP | | MAC Sublayer | | | 802.11-OCB | and ch. coord. | | SME | Services +-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| | | | PLME | | | PHY Layer | PLME_SAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EtherType Protocol Discrimination Appendix E. Design Considerations The networks defined by 802.11-OCB are in many ways similar to other networks of the 802.11 family. In theory, the transportation of IPv6 over 802.11-OCB could be very similar to the operation of IPv6 over other networks of the 802.11 family. However, the high mobility, strong link asymmetry and very short connection makes the 802.11-OCB link significantly different from other 802.11 networks. Also, the automotive applications have specific requirements for reliability, security and privacy, which further add to the particularity of the 802.11-OCB link. Appendix F. IEEE 802.11 Messages Transmitted in OCB mode For information, at the time of writing, this is the list of IEEE 802.11 messages that may be transmitted in OCB mode, i.e. when dot11OCBActivated is true in a STA: o The STA may send management frames of subtype Action and, if the STA maintains a TSF Timer, subtype Timing Advertisement; o The STA may send control frames, except those of subtype PS-Poll, CF-End, and CF-End plus CFAck; o The STA MUST send data frames of subtype QoS Data. Benamar, et al. Expires February 10, 2020 [Page 22] Internet-Draft IPv6-over-80211-OCB August 2019 Appendix G. Examples of Packet Formats This section describes an example of an IPv6 Packet captured over a IEEE 802.11-OCB link. By way of example we show that there is no modification in the headers when transmitted over 802.11-OCB networks - they are transmitted like any other 802.11 and Ethernet packets. We describe an experiment of capturing an IPv6 packet on an 802.11-OCB link. In topology depicted in Figure 3, the packet is an IPv6 Router Advertisement. This packet is emitted by a Router on its 802.11-OCB interface. The packet is captured on the Host, using a network protocol analyzer (e.g. Wireshark); the capture is performed in two different modes: direct mode and 'monitor' mode. The topology used during the capture is depicted below. The packet is captured on the Host. The Host is an IP-OBU containing an 802.11 interface in format PCI express (an ITRI product). The kernel runs the ath5k software driver with modifications for OCB mode. The capture tool is Wireshark. The file format for save and analyze is 'pcap'. The packet is generated by the Router. The Router is an IP-RSU (ITRI product). +--------+ +-------+ | | 802.11-OCB Link | | ---| Router |--------------------------------| Host | | | | | +--------+ +-------+ Figure 3: Topology for capturing IP packets on 802.11-OCB During several capture operations running from a few moments to several hours, no message relevant to the BSSID contexts were captured (no Association Request/Response, Authentication Req/Resp, Beacon). This shows that the operation of 802.11-OCB is outside the context of a BSSID. Overall, the captured message is identical with a capture of an IPv6 packet emitted on a 802.11b interface. The contents are precisely similar. Benamar, et al. Expires February 10, 2020 [Page 23] Internet-Draft IPv6-over-80211-OCB August 2019 G.1. Capture in Monitor Mode The IPv6 RA packet captured in monitor mode is illustrated below. The radio tap header provides more flexibility for reporting the characteristics of frames. The Radiotap Header is prepended by this particular stack and operating system on the Host machine to the RA packet received from the network (the Radiotap Header is not present on the air). The implementation-dependent Radiotap Header is useful for piggybacking PHY information from the chip's registers as data in a packet understandable by userland applications using Socket interfaces (the PHY interface can be, for example: power levels, data rate, ratio of signal to noise). The packet present on the air is formed by IEEE 802.11 Data Header, Logical Link Control Header, IPv6 Base Header and ICMPv6 Header. Radiotap Header v0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Header Revision| Header Pad | Header length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Present flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Rate | Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IEEE 802.11 Data Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type/Subtype and Frame Ctrl | Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Receiver Address | Transmitter Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Transmitter Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSS Id... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... BSS Id | Frag Number and Seq Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Logical-Link Control Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSAP |I| SSAP |C| Control field | Org. code... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Organizational Code | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Benamar, et al. Expires February 10, 2020 [Page 24] Internet-Draft IPv6-over-80211-OCB August 2019 IPv6 Base Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router Advertisement +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- The value of the Data Rate field in the Radiotap header is set to 6 Mb/s. This indicates the rate at which this RA was received. The value of the Transmitter address in the IEEE 802.11 Data Header is set to a 48bit value. The value of the destination address is 33:33:00:00:00:1 (all-nodes multicast address). The value of the BSS Id field is ff:ff:ff:ff:ff:ff, which is recognized by the network protocol analyzer as being "broadcast". The Fragment number and sequence number fields are together set to 0x90C6. Benamar, et al. Expires February 10, 2020 [Page 25] Internet-Draft IPv6-over-80211-OCB August 2019 The value of the Organization Code field in the Logical-Link Control Header is set to 0x0, recognized as "Encapsulated Ethernet". The value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise #86DD), recognized as "IPv6". A Router Advertisement is periodically sent by the router to multicast group address ff02::1. It is an icmp packet type 134. The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags, as described in [RFC4861]. The IPv6 header contains the link local address of the router (source) configured via EUI-64 algorithm, and destination address set to ff02::1. The Ethernet Type field in the logical-link control header is set to 0x86dd which indicates that the frame transports an IPv6 packet. In the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 which is the corresponding multicast MAC address. The BSS id is a broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link duration between vehicles and the roadside infrastructure, there is no need in IEEE 802.11-OCB to wait for the completion of association and authentication procedures before exchanging data. IEEE 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) and may start communicating as soon as they arrive on the communication channel. G.2. Capture in Normal Mode The same IPv6 Router Advertisement packet described above (monitor mode) is captured on the Host, in the Normal mode, and depicted below. Benamar, et al. Expires February 10, 2020 [Page 26] Internet-Draft IPv6-over-80211-OCB August 2019 Ethernet II Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Destination | Source... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Base Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router Advertisement +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Benamar, et al. Expires February 10, 2020 [Page 27] Internet-Draft IPv6-over-80211-OCB August 2019 One notices that the Radiotap Header, the IEEE 802.11 Data Header and the Logical-Link Control Headers are not present. On the other hand, a new header named Ethernet II Header is present. The Destination and Source addresses in the Ethernet II header contain the same values as the fields Receiver Address and Transmitter Address present in the IEEE 802.11 Data Header in the "monitor" mode capture. The value of the Type field in the Ethernet II header is 0x86DD (recognized as "IPv6"); this value is the same value as the value of the field Type in the Logical-Link Control Header in the "monitor" mode capture. The knowledgeable experimenter will no doubt notice the similarity of this Ethernet II Header with a capture in normal mode on a pure Ethernet cable interface. A frame translation is inserted on top of a pure IEEE 802.11 MAC layer, in order to adapt packets, before delivering the payload data to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II headers. In further detail, this adaptation consists in the elimination of the Radiotap, 802.11 and LLC headers, and in the insertion of the Ethernet II header. In this way, IPv6 runs straight over LLC over the 802.11-OCB MAC layer; this is further confirmed by the use of the unique Type 0x86DD. Appendix H. Extra Terminology The following terms are defined outside the IETF. They are used to define the main terms in the main terminology Section 2. DSRC (Dedicated Short Range Communication): a term defined outside the IETF. The US Federal Communications Commission (FCC) Dedicated Short Range Communication (DSRC) is defined in the Code of Federal Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the definitions below. At the time of the writing of this Internet Draft, the last update of this Code was dated October 1st, 2010. DSRCS (Dedicated Short-Range Communications Services): a term defined outside the IETF. The use of radio techniques to transfer data over short distances between roadside and mobile units, between mobile units, and between portable and mobile units to perform operations related to the improvement of traffic flow, traffic safety, and other intelligent transportation service applications in a variety of environments. DSRCS systems may also transmit status and instructional messages related to the units involve. [Ref. 47 CFR 90.7 - Definitions] Benamar, et al. Expires February 10, 2020 [Page 28] Internet-Draft IPv6-over-80211-OCB August 2019 OBU (On-Board Unit): a term defined outside the IETF. An On-Board Unit is a DSRCS transceiver that is normally mounted in or on a vehicle, or which in some instances may be a portable unit. An OBU can be operational while a vehicle or person is either mobile or stationary. The OBUs receive and contend for time to transmit on one or more radio frequency (RF) channels. Except where specifically excluded, OBU operation is permitted wherever vehicle operation or human passage is permitted. The OBUs mounted in vehicles are licensed by rule under part 95 of the respective chapter and communicate with Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by rule under part 95 of the respective chapter. OBU operations in the Unlicensed National Information Infrastructure (UNII) Bands follow the rules in those bands. - [CFR 90.7 - Definitions]. RSU (Road-Side Unit): a term defined outside of IETF. A Roadside Unit is a DSRC transceiver that is mounted along a road or pedestrian passageway. An RSU may also be mounted on a vehicle or is hand carried, but it may only operate when the vehicle or hand- carried unit is stationary. Furthermore, an RSU operating under the respectgive part is restricted to the location where it is licensed to operate. However, portable or hand-held RSUs are permitted to operate where they do not interfere with a site-licensed operation. A RSU broadcasts data to OBUs or exchanges data with OBUs in its communications zone. An RSU also provides channel assignments and operating instructions to OBUs in its communications zone, when required. - [CFR 90.7 - Definitions]. Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Links IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was designed for point-to-point and transit links such as Ethernet, with the expectation of a cheap and reliable support for multicast from the lower layer. Section 3.2 of RFC 4861 indicates that the operation on Shared Media and on non-broadcast multi-access (NBMA) networks require additional support, e.g., for Address Resolution (AR) and duplicate address detection (DAD), which depend on multicast. An infrastructureless radio network such as OCB shares properties with both Shared Media and NBMA networks, and then adds its own complexity, e.g., from movement and interference that allow only transient and non-transitive reachability between any set of peers. The uniqueness of an address within a scoped domain is a key pillar of IPv6 and the base for unicast IP communication. RFC 4861 details the DAD method to avoid that an address is duplicated. For a link local address, the scope is the link, whereas for a Globally Reachable address the scope is much larger. The underlying assumption for DAD to operate correctly is that the node that owns an Benamar, et al. Expires February 10, 2020 [Page 29] Internet-Draft IPv6-over-80211-OCB August 2019 IPv6 address can reach any other node within the scope at the time it claims its address, which is done by sending a NS multicast message, and can hear any future claim for that address by another party within the scope for the duration of the address ownership. In the case of OCB, there is a potentially a need to define a scope that is compatible with DAD, and that cannot be the set of nodes that a transmitter can reach at a particular time, because that set varies all the time and does not meet the DAD requirements for a link local address that could possibly be used anytime, anywhere. The generic expectation of a reliable multicast is not ensured, and the operation of DAD and AR (Address Resolution) as specified by RFC 4861 cannot be guaranteed. Moreover, multicast transmissions that rely on broadcast are not only unreliable but are also often detrimental to unicast traffic (see [draft-ietf-mboned-ieee802-mcast-problems]). Early experience indicates that it should be possible to exchange IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR (Address Resolution) in good conditions. In the absence of a correct DAD operation, a node that relies only on IPv6 ND for AR and DAD over OCB should ensure that the addresses that it uses are unique by means others than DAD. It must be noted that deriving an IPv6 address from a globally unique MAC address has this property but may yield privacy issues. RFC 8505 provides a more recent approach to IPv6 ND and in particular DAD. RFC 8505 is designed to fit wireless and otherwise constrained networks whereby multicast and/or continuous access to the medium may not be guaranteed. RFC 8505 Section 5.6 "Link-Local Addresses and Registration" indicates that the scope of uniqueness for a link local address is restricted to a pair of nodes that use it to communicate, and provides a method to assert the uniqueness and resolve the link- Layer address using a unicast exchange. RFC 8505 also enables a router (acting as a 6LR) to own a prefix and act as a registrar (acting as a 6LBR) for addresses within the associated subnet. A peer host (acting as a 6LN) registers an address derived from that prefix and can use it for the lifetime of the registration. The prefix is advertised as not onlink, which means that the 6LN uses the 6LR to relay its packets within the subnet, and participation to the subnet is constrained to the time of reachability to the 6LR. Note that RSU that provides internet connectivity MAY announce a default router preference [RFC4191], whereas a car that does not provide that connectivity MUST NOT do so. This operation presents similarities with that of an access point, but at Layer-3. This is why RFC 8505 well-suited for wireless in general. Benamar, et al. Expires February 10, 2020 [Page 30] Internet-Draft IPv6-over-80211-OCB August 2019 Support of RFC 8505 may be implemented on OCB. OCB nodes that support RFC 8505 SHOULD support the 6LN operation in order to act as a host, and may support the 6LR and 6LBR operations in order to act as a router and in particular own a prefix that can be used by RFC 8505-compliant hosts for address autoconfiguration and registration. Authors' Addresses Nabil Benamar Moulay Ismail University of Meknes Morocco Phone: +212670832236 Email: n.benamar@est.umi.ac.ma Jerome Haerri Eurecom Sophia-Antipolis 06904 France Phone: +33493008134 Email: Jerome.Haerri@eurecom.fr Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan 31066 Republic of Korea Email: jonghyouk@smu.ac.kr Thierry Ernst YoGoKo France Email: thierry.ernst@yogoko.fr Benamar, et al. Expires February 10, 2020 [Page 31] ./draft-ietf-clue-datachannel-18.txt0000644000764400076440000007054613460016423016564 0ustar iustyiusty CLUE Working Group C. Holmberg Internet-Draft Ericsson Intended status: Experimental April 24, 2019 Expires: October 26, 2019 CLUE Protocol data channel draft-ietf-clue-datachannel-18 Abstract This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. 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 26, 2019. Copyright Notice Copyright (c) 2019 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 Expires October 26, 2019 [Page 1] Internet-Draft CLUE data channel April 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. CLUE data channel . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. SCTP Considerations . . . . . . . . . . . . . . . . . . . 4 3.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.2. SCTP Payload Protocol Identifier (PPID) . . . . . . . 4 3.2.3. Reliability . . . . . . . . . . . . . . . . . . . . . 4 3.2.4. Order . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.5. Stream Reset . . . . . . . . . . . . . . . . . . . . 5 3.2.6. SCTP Multihoming . . . . . . . . . . . . . . . . . . 5 3.2.7. Closing the CLUE data channel . . . . . . . . . . . . 5 3.3. SDP Considerations . . . . . . . . . . . . . . . . . . . 5 3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.2. SDP dcmap Attribute . . . . . . . . . . . . . . . . . 6 3.3.3. SDP dcsa Attribute . . . . . . . . . . . . . . . . . 7 3.3.4. Example . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. New WebRTC data channel Protocol Value . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This document defines how to use the WebRTC data channel mechanism [I-D.ietf-rtcweb-data-channel] to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol [I-D.ietf-clue-protocol] messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association [RFC8261] used to realize the CLUE data channel using the Session Description Protocol (SDP) [RFC4566], and defines usage of the SDP- based "SCTP over DTLS" data channel negotiation mechanism [I-D.ietf-mmusic-data-channel-sdpneg]. This includes SCTP considerations specific to a CLUE data channel, the SDP Media Description ("m=" line) values, and usage of SDP attributes specific to a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer [RFC3264] procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. Holmberg Expires October 26, 2019 [Page 2] Internet-Draft CLUE data channel April 2019 NOTE: The usage of the Data Channel Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel is outside the scope of this document. 2. Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. SCTPoDTLS association refers to an SCTP association carried over an DTLS connection [RFC8261]. WebRTC data channel refers to a pair of SCTP streams over a SCTPoDTLS association that is used to transport non-media data between two entities, as defined in [I-D.ietf-rtcweb-data-channel]. CLUE data channel refers to a WebRTC data channel [I-D.ietf-rtcweb-data-channel] realization, with a specific set of SCTP characteristics, with the purpose of transporting CLUE protocol [I-D.ietf-clue-protocol] messages between two CLUE entities. CLUE entity refers to a SIP User Agent (UA) [RFC3261] that supports the CLUE data channel and the CLUE protocol. CLUE session refers to a SIP session [RFC3261] between two SIP UAs, where a CLUE data channel, associated with the SIP session, has been established between the SIP UAs. SCTP stream is defined in [RFC4960] as a unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. SCTP identifier is defined in [RFC4960] as an unsigned integer, which identifies an SCTP stream. 3. CLUE data channel 3.1. General This section describes the realization of a CLUE data channel, using the WebRTC data channel mechanism. This includes a set of SCTP characteristics specific to a CLUE data channel, the values of the "m=" line describing the SCTPoDTLS association associated with the WebRTC data channel, and the usage of the SDP-based "SCTP over DTLS" Holmberg Expires October 26, 2019 [Page 3] Internet-Draft CLUE data channel April 2019 data channel negotiation mechanism for creating the CLUE data channel. As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association. In addition, both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. These rules also apply to a CLUE data channel. Within a given CLUE session, a CLUE entity MUST use a single CLUE data channel for transport of all CLUE messages towards its peer. 3.2. SCTP Considerations 3.2.1. General As described in [I-D.ietf-rtcweb-data-channel], different SCTP options (e.g., regarding ordered delivery ), can be used for a data channel. This section describes the SCTP options used for a CLUE data channel. Section 3.3 describes how SCTP options are signaled using SDP. NOTE: While SCTP allows SCTP options to be applied per SCTP message, [I-D.ietf-rtcweb-data-channel] mandates that, for a given data channel, the same SCTP options are applied to each SCTP message associated with that data channel. 3.2.2. SCTP Payload Protocol Identifier (PPID) A CLUE entity MUST use the PPID value 51 when sending a CLUE message on a CLUE data channel. NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 51 indicates that the SCTP message contains data encoded in a UTF-8 format. The PPID value 51 does not indicate which application protocol the SCTP message is associated with, only the format in which the data is encoded. 3.2.3. Reliability The usage of SCTP for the CLUE data channel ensures reliable transport of CLUE protocol [I-D.ietf-clue-protocol] messages. [I-D.ietf-rtcweb-data-channel] requires the support of the partial reliability extension defined in [RFC3758] and the limited retransmission policy defined in [RFC7496]. A CLUE entity MUST NOT use these extensions, as messages are required to always be sent Holmberg Expires October 26, 2019 [Page 4] Internet-Draft CLUE data channel April 2019 reliably. A CLUE entity MUST terminate the session if it detects that the peer entity uses any of the extensions. 3.2.4. Order A CLUE entity MUST use the ordered delivery SCTP service, as described in [RFC4960], for the CLUE data channel. 3.2.5. Stream Reset A CLUE entity MUST support the stream reset extension defined in [RFC6525]. As defined in [I-D.ietf-rtcweb-data-channel], the dynamic address reconfiguration extension ('Supported Extensions Parameter' parameter) defined in [RFC5061] must be used to signal the support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used for CLUE data channels. 3.2.6. SCTP Multihoming SCTP multi-homing is not supported for SCTPoDTLS associations, and can therefore not be used for a CLUE data channel. 3.2.7. Closing the CLUE data channel As described in [I-D.ietf-rtcweb-data-channel], to close a data channel, an entity sends an SCTP reset message [RFC6525] on its outgoing SCTP stream associated with the data channel. When the remote peer receives the reset message, it also sends (unless already sent) a reset message on its outgoing SCTP stream associated with the data channel. The SCTPoDTLS association, and other data channels established on the same association, are not affected by the SCTP reset messages. 3.3. SDP Considerations 3.3.1. General This section defines how to construct the SDP Media Description ("m=" line) for describing the SCTPoDTLS association used to realize a CLUE data channel. The section also defines how to use the SDP-based "SCTP over DTLS" data channel negotiation mechanism [I-D.ietf-mmusic-data-channel-sdpneg] for establishing a CLUE data channel on the SCTPoDTLS association. Holmberg Expires October 26, 2019 [Page 5] Internet-Draft CLUE data channel April 2019 NOTE: Other protocols than SDP for negotiating usage of an SCTPoDTLS association for realizing a CLUE data channel are outside the scope of this specification. [I-D.ietf-clue-signaling] describes the SDP Offer/Answer procedures for negotiating a CLUE session, including the CLUE controlled media streams and the CLUE data channel. 3.3.1.1. SDP Media Description Fields [I-D.ietf-mmusic-sctp-sdp] defines how to set the values of an "m=" line describing an SCTPoDTLS association. As defined in [I-D.ietf-mmusic-sctp-sdp], for a CLUE data channel the values are set as following: +---------------+----------+-----------------+----------------------+ | media | port | proto | fmt | +---------------+----------+-----------------+----------------------+ | "application" | UDP port | "UDP/DTLS/SCTP" | "webrtc-datachannel" | | | value | | | | "application" | TCP port | "TCP/DTLS/SCTP" | "webrtc-datachannel" | | | value | | | +---------------+----------+-----------------+----------------------+ Table 1: SDP "proto" field values CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/SCTP will not work (for instance, when the Interactive Connectivity Establishment (ICE) mechanism [RFC8445] is used and the ICE procedures determine that TCP transport is required). 3.3.1.2. SDP sctp-port Attribute As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute value is set to the SCTP port of the SCTPoDTLS association. A CLUE entity can choose any valid SCTP port value [I-D.ietf-mmusic-sctp-sdp]. 3.3.2. SDP dcmap Attribute The values of the SDP dcmap attribute [I-D.ietf-mmusic-data-channel-sdpneg], associated with the "m=" line describing the SCTPoDTLS association used to realize the WebRTC data channel, are set as following: Holmberg Expires October 26, 2019 [Page 6] Internet-Draft CLUE data channel April 2019 +----------+------------+------------+--------+----------+----------+ | stream- | sub- | label | ordere | max-retr | max-time | | id | protocol | | d | | | +----------+------------+------------+--------+----------+----------+ | Value of | "CLUE" | Appli- | "true" | N/A | N/A | | the SCTP | | cation | | | | | stream | | specific | | | | | used to | | | | | | | realize | | | | | | | the CLUE | | | | | | | data | | | | | | | channel | | | | | | +----------+------------+------------+--------+----------+----------+ Table 2: SDP dcmap attribute values NOTE: As CLUE entities are required to use ordered SCTP message delivery, with full reliability, according to the procedures in [I-D.ietf-mmusic-data-channel-sdpneg] the max-retr and max-time attribute parameters are not used when negotiating CLUE data channels. 3.3.3. SDP dcsa Attribute The SDP dcsa attribute [I-D.ietf-mmusic-data-channel-sdpneg] is not used when establishing a CLUE data channel. 3.3.4. Example The example in Figure 1 shows an SDP media description for a CLUE data channel. Examples of complete SDP examples can be found in [I-D.ietf-clue-signaling]. m=application 54111 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE";ordered=true Figure 1: SDP Media Description for a CLUE data channel 4. Security Considerations This specification relies on the security properties of the WebRTC data channel described in [I-D.ietf-rtcweb-data-channel], including reliance on DTLS. Since CLUE sessions are established using SIP/SDP, protecting the data channel against message modification and recovery requires the use of SIP authentication and authorization mechanisms Holmberg Expires October 26, 2019 [Page 7] Internet-Draft CLUE data channel April 2019 described in [RFC3261] for session establishment prior to establishing the data channel. 5. IANA Considerations 5.1. New WebRTC data channel Protocol Value [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] This document adds the 'CLUE' value to the "WebSocket Subprotocol Name Registry" as follows: Subprotocl Identifier: CLUE Subprotocol Common Name: CLUE Subprotocol Definition: RFC-XXXX Reference: RFC-XXXX 6. Acknowledgments Thanks to Paul Kyzivat, Christian Groves and Mark Duckworth for comments on the document. 7. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-clue-datachannel-17 o Editorial changes to Tables based on TSV-ART review. Changes from draft-ietf-clue-datachannel-16 o Category changed to Experimental. Changes from draft-ietf-clue-datachannel-15 o Updates based on IESG review by Roman Danyliw. o Make CLUE references Informative, as they are going to be published as Experimental RFCs. Changes from draft-ietf-clue-datachannel-14 o ICE reference update. o Reference draft versions updates. Holmberg Expires October 26, 2019 [Page 8] Internet-Draft CLUE data channel April 2019 Changes from draft-ietf-clue-datachannel-13 o Editorial changes based on Gen-ART review from Brian Carpenter. Changes from draft-ietf-clue-datachannel-12 o Changes based on AD comments from Alissa Cooper (https://www.ietf.org/mail-archive/web/clue/current/ msg04911.html): o - DCEP reference removed from security considerations. o - Editorial fixes. o - NOTE: Comment regarding the Security Considerations is still pending. Changes from draft-ietf-clue-datachannel-11 o Changes based on WGLC comments from Juergen Stoetzer-Bradler and Christian groves: o - Reference updates. o - 'Reference' added to IANA registration data. Changes from draft-ietf-clue-datachannel-10 o Security Considerations modified and enhanced, based on comments provided by Alissa Cooper. Changes from draft-ietf-clue-datachannel-09 o Reference updates: o - draft-ietf-tsvwg-sctp-prpolicies published as RFC 7496 o - Reference update of draft versions Changes from draft-ietf-clue-datachannel-08 o Changes based on WGLC comments from Daniel Burnett: o - Editorial corrections. o Changes based on WGLC comments from Paul Kyzivat: o - Editorial corrections. Changes from draft-ietf-clue-datachannel-07 o Changes based on WGLC comments from Christian Groves: o - IANA considerations for dcmap attribute removed. o - Explicit clarification that the dcmap attribute max-time and max-retr parameters are not used with ordered/reliable transmission of SCTP messages. o - Indication that TCP transport should only be used if ICE is used, and if usage of TCP is required by ICE. Holmberg Expires October 26, 2019 [Page 9] Internet-Draft CLUE data channel April 2019 o - Informative reference to ICE added. o - Editorial corrections. o Changes based on WGLC comments from Mark Duckworth: o - Make it more clear that the rules regarding usage of partial reliability and ordered reliability apply to CLUE data channels. o Changes based on WGLC comments from Paul Kyzivat: o - Clarify that same SCTP options are applied to each SCTP message associated with a given data channel. o - Switched location of sections 3.2 and 3.3. o - PPID table removed. Not needed, since only one value is used. o - Editorial corrections. Changes from draft-ietf-clue-datachannel-06 o Usage of DCEP removed. Changes from draft-ietf-clue-datachannel-05 o "DTLS/SCTP" split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". o Removed note regarding optionality of including the SDP sctp-port attribute. o Added defintion of 'SCTPoDTLS association' to the Conventions. o Reference to RFC 4566 (SDP) added. Changes from draft-ietf-clue-datachannel-04 o Defines DCEP and external SDP negotiation as two separate mechanisms for negotiating a CLUE data channel. o Updates based on technical changes in referenced specifications. o Reference to draft-ietf-mmusic-sctp-sdp added. Changes from draft-ietf-clue-datachannel-03 o IANA considerations added. o Editorial changes based on comments from Christian Groves. Changes from draft-ietf-clue-datachannel-02 o SDP "m=" line example fixed. o OPEN ISSUE #1 closed. o - It was agreed (IETF#91) to use draft-ejzak-mmusic-data-channel- sdpneg, as it was adopted as a WG item in MMUSIC. o - Details for draft-ejzak-mmusic-data-channel-sdpneg usage added. o SDP Offer/Answer procedures removed, as they will be defined in the CLUE protocol draft. o References updated. Changes from draft-ietf-clue-datachannel-01 Holmberg Expires October 26, 2019 [Page 10] Internet-Draft CLUE data channel April 2019 o Support of interleaving "MUST"->"SHOULD". o Example updated. o Reference update. Changes from draft-ietf-clue-datachannel-00 o SDP Offer/Answer procedures structures according to RFC 3264. o Reference update. Changes from draft-holmberg-clue-datachannel-04 o Draft submitted as draft-ietf-clue-data-channel-00. o Editorial nits fixed. o Changes based on comments from Paul Kyzivat (http://www.ietf.org/ mail-archive/web/clue/current/msg03559.html). o - Proto value fixed. o - Explicit text that the partial reliability and limited retransmission policies MUST NOT be used. o - Added open issue on whether the DCEP 'protocol' field value for CLUE should contain a version number. o - Removed paragraph saying that an offerer must not insert more than one "m=" line describing an SCTPoDTLS association to be used to realize a CLUE data channel, as the draft already states that only one CLUE data channel per CLUE session shall be opened. o - Added reference to draft-ietf-rtcweb-data-protocol regarding details on reseting SCTP streams. o - Added text saying that the value of the DCEP 'channel type' MUST be DATA_CHANNEL_RELIABLE. o - Clarified that DCEP must be supported, and used in the absence of another mechanism for opening a CLUE data channel. Changes from draft-holmberg-clue-datachannel-03 o Procedures updated, based on WG agreement (IETF#89) to use DCEP for the CLUE data channel. o Procedures updated, based on WG agreement (IETF#89) that offerer is responsible for sending DCEP DATA_CHANNEL_OPEN. o Editorial changes, and alignments caused by changes in referenced specifications. Changes from draft-holmberg-clue-datachannel-02 o PPID value for CLUE messages added o References updated Changes from draft-holmberg-clue-datachannel-01 o More text added Holmberg Expires October 26, 2019 [Page 11] Internet-Draft CLUE data channel April 2019 Changes from draft-holmberg-clue-datachannel-00 o Editorial corrections based on comments from Paul K 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, . [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, . [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, . [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, . [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, . [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, . Holmberg Expires October 26, 2019 [Page 12] Internet-Draft CLUE data channel April 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, . [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-26.txt (work in progress), April 2017. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data channels", draft-ietf-rtcweb-data-channel-13.txt (work in progress), January 2015. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, R., Stoetzer-Bradler, J., Ejzak, R., and J. Marcon, "SDP-based "SCTP over DTLS" data channel negotiation", draft-ietf-mmusic-data-channel-sdpneg-26.txt (work in progress), April 2019. 8.2. Informative References [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, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data channel Establishment Protocol", draft-ietf-rtcweb-data-protocol- 09.txt (work in progress), January 2015. [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft-ietf- clue-protocol-17.txt (work in progress), September 2018. Holmberg Expires October 26, 2019 [Page 13] Internet-Draft CLUE data channel April 2019 [I-D.ietf-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., and S. Romano, "CLUE Signaling", draft-ietf-clue-signaling-14.txt (work in progress), October 2018. Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires October 26, 2019 [Page 14] ./draft-ietf-isis-l2bundles-07.txt0000644000764400076440000010662613111564256016235 0ustar iustyiusty Networking Working Group L. Ginsberg Internet-Draft A. Bashandy Intended status: Standards Track C. Filsfils Expires: November 26, 2017 Cisco Systems M. Nanduri eBay E. Aries Private Contributer May 25, 2017 Advertising L2 Bundle Member Link Attributes in IS-IS draft-ietf-isis-l2bundles-07.txt Abstract There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle link attribute information about the bundle members is required. This document introduces the ability for IS-IS to advertise the link attributes of layer 2 (L2) bundle members. 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." Ginsberg, et al. Expires November 26, 2017 [Page 1] Internet-Draft isis-l2bundles May 2017 This Internet-Draft will expire on November 26, 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. L2 Bundle Member Attributes TLV . . . . . . . . . . . . . . . 3 2.1. Parallel L3 Adjacencies . . . . . . . . . . . . . . . . . 5 2.2. Shared Attribute sub-TLVs . . . . . . . . . . . . . . . . 5 3. Advertising L2 Bundle Member Adj-SIDs . . . . . . . . . . . . 6 3.1. L2 Bundle Member Adjacency Segment Identifier sub-TLV . . 6 3.2. L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informational References . . . . . . . . . . . . . . . . 13 Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction There are deployments where the Layer 3 interface on which an IS-IS adjacency is established is a Layer 2 interface bundle, for instance a Link Aggregation Group (LAG) [IEEE802.1AX]. This reduces the number of adjacencies which need to be maintained by the routing protocol in cases where there are parallel links between the neighbors. Entities external to IS-IS such as Path Computation Elements (PCE) [RFC4655] may wish to control traffic flows on individual members of the underlying Layer 2 bundle. In order to do so link attribute information about individual bundle members is Ginsberg, et al. Expires November 26, 2017 [Page 2] Internet-Draft isis-l2bundles May 2017 required. The protocol extensions defined in this document provide the means to advertise this information. This document introduces a new TLV to advertise link attribute information for each of the L2 bundle members which comprise the Layer 3 interface on which IS-IS operates. [SR-ISIS] introduces a new link attribute - adjacency segment identifier (Adj-SID) - which can be used as an instruction to forwarding to send traffic over a specific link. This document introduces additional sub-TLVs to advertise Adj-SIDs for L2 Bundle members. Note that the new advertisements defined in this document are intended to be provided to external (to IS-IS) entities. The following items are intentionally not defined and/or are outside the scope of this document: o What link attributes will be advertised. This is determined by the needs of the external entities. o A minimum or default set of link attributes. o How these attributes are configured o How the advertisements are used o What impact the use of these advertisements may have on traffic flow in the network o How the advertisements are passed to external entities 2. L2 Bundle Member Attributes TLV A new TLV is introduced to advertise L2 Bundle member attributes. Although much of the information is identical to and uses the same sub-TLVs included in Extended IS-Neighbor advertisements (TLVs 22 and 222), a new TLV is used so that changes to the advertisement of the L2 Bundle member link attributes does not trigger unnecessary action by the [ISO10589] Decision process. Advertisement of this information implies that the identified link is a member of the L2 Bundle associated with the identified Parent L3 Neighbor and that the member link is operationally up. Therefore advertisements MUST be withdrawn if the link becomes operationally down or it is no longer a member of the identified L2 Bundle. Ginsberg, et al. Expires November 26, 2017 [Page 3] Internet-Draft isis-l2bundles May 2017 This new TLV utilizes the sub-TLV space defined for TLVs 22, 23, 141, 222, and 223. The following new TLV is introduced: L2 Bundle Member Attributes Type: 25 (suggested - to be assigned by IANA) Length: Number of octets to follow Parent L3 Neighbor Descriptor L3 Neighbor System ID + pseudonode ID (7 octets) Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| | +-+-+-+-+-+-+-+-+ where: P-flag: When set to 1 one of the sub-TLVs described in Section 2.1 immediately follows the flags field. If the P-flag is set to 0, then none of the sub-TLVs described in Section 2.1 are present. Other bits: MUST be zero when originated and ignored when received. One or more of the following: L2 Bundle Attribute Descriptors Length of L2 Bundle Attribute Descriptor (1 octet) NOTE: This includes all fields described below. Number of L2 Bundle Member Descriptors (1 octet) L2 Bundle Member Link Local Identifiers (4 * Number of L2 Bundle Member Descriptors octets) NOTE: An L2 Bundle Member Descriptor is a Link Local Identifier as defined in [RFC4202]. sub-TLV(s) A sub-TLV may define an attribute common to all of the bundle members listed or a sub-TLV may define an attribute unique to each bundle member. Use of these two classes of sub-TLVs is described in the following sections. Ginsberg, et al. Expires November 26, 2017 [Page 4] Internet-Draft isis-l2bundles May 2017 NOTE: Only one Parent L3 Neighbor Descriptor is present in a given TLV. Multiple L2 Bundle Attribute Descriptors may be present in a single TLV. 2.1. Parallel L3 Adjacencies When there exist multiple L3 adjacencies to the same neighbor additional information is required to uniquely identify the L3 Neighbor. One and only one of the following three sub-TLVs is used to uniquely identify the L3 adjacency: o IPv4 Interface Address (sub-TLV 6 defined in [RFC5305]) o IPv6 Interface Address (sub-TLV 12 defined in [RFC6119]) o Link Local/Remote Identifiers (sub-TLV 4 defined in [RFC5307]) When the P-bit is set in the flags field in the Parent L3 Neighbor Descriptor one and only one of the above sub-TLVs MUST be present. The chosen sub-TLV MUST immediately follow the flags field described in Section 2. These sub-TLVs MAY be omitted if no parallel adjacencies to the neighbor exist. 2.2. Shared Attribute sub-TLVs These sub-TLVs advertise a single copy of an attribute (e.g. link bandwidth). The attribute applies to all of the L2 Bundle Members in the set advertised under the preceding L2 Bundle Member Attribute Descriptor. No more than one copy of a given sub-TLV in this category may appear in the set of sub-TLVs under the preceding L2 Bundle Member Attribute Descriptor. If multiple copies of a given sub-TLV are present all copies MUST be ignored. The set of L2 Bundle Member Descriptors which may be advertised under a single L2 Bundle Member Attribute Descriptor is therefore limited to bundle members which share the set of attributes advertised in the shared attribute sub-TLVs. All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry are in the category of shared attribute sub-TLVs unless otherwise specified in this document. Ginsberg, et al. Expires November 26, 2017 [Page 5] Internet-Draft isis-l2bundles May 2017 3. Advertising L2 Bundle Member Adj-SIDs [SR-ISIS] defines sub-TLVs to advertise Adj-SIDs for L3 adjacencies. However these sub-TLVs only support a advertisement of a single Adj- SID. As it is expected that each L2 Bundle member will have unique Adj-SIDs in many deployments it is desirable to define a new sub-TLV which allows more efficient encoding of a set of Adj-SIDs in a single sub-TLV. Two new sub-TLVs are therefore introduced to support advertising Adj-SIDs for L2 Bundle members. The format of the new sub-TLVs is similar to that used for L3 adjacencies, but is optimized to allow advertisement of a set of Adj-SIDs (one per L2 Bundle Member) in a single sub-TLV. The two new sub-TLVs defined in the following sections do not fall into the category of shared attribute sub-TLVs. 3.1. L2 Bundle Member Adjacency Segment Identifier sub-TLV This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members associated with a parent L3 adjacency which is Point-to-Point. The following format is defined for this sub-TLV: Type: 41 (suggested value to be assigned by IANA) (1 octet) Length: variable (1 octet) Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|*|V|L|S|P| | +-+-+-+-+-+-+-+-+ where: NOTE: The flags are deliberately kept congruent to the flags in the L3 ADJ-SID defined in [SR-ISIS]. * indicates a flag used in the L3 Adj-SID sub-TLV but which is NOT used in this sub-TLV. These bits SHOULD be sent as 0 and MUST be ignored on receipt. F-Flag: Address-Family flag. If unset, then the Adj-SID refers to an L2 Bundle Member with outgoing IPv4 encapsulation. If set then the Adj-SID refers to an L2 Bundle Member with outgoing IPv6 encapsulation. V-Flag: Value flag. If set, then the Adj-SID carries a value. By default the flag is SET. Ginsberg, et al. Expires November 26, 2017 [Page 6] Internet-Draft isis-l2bundles May 2017 L-Flag: Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. S-Flag. Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of L2 Bundle Members (and therefore MAY be assigned to other L2 Bundle Members as well). P-Flag. Persistent flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap. Other bits: MUST be zero when originated and ignored when received. Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [SR-ARCH]. NOTE: Flags and weight are shared by all L2 Bundle Members listed in the L2 Bundle Attribute Descriptor. L2 Bundle Member Adj-SID Descriptors. There MUST be one descriptor for each of the L2 Bundle Members advertised under the preceding L2 Bundle Member Attribute Descriptor. Each descriptor consists of one of the following fields: SID/Index/Label: according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the SID/Label space advertised by this router. See [SR-ISIS]. In this case V and L flags MUST be unset. 3.2. L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members associated with a parent L3 adjacency which is a LAN adjacency. In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the Pseudonode-LSP (PN-LSP) including all neighbors of the DIS. When Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its neighbors on the LAN. Ginsberg, et al. Expires November 26, 2017 [Page 7] Internet-Draft isis-l2bundles May 2017 Similarly, for each L2 Bundle Member a router MAY advertise an Adj- SID to each neighbor on the LAN. The following format is defined for this sub-TLV: Type: 42 (suggested value to be assigned by IANA) (1 octet) Length: variable (1 octet) Neighbor System ID: 6 octets Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|*|V|L|S|P| | +-+-+-+-+-+-+-+-+ where: NOTE: The flags are deliberately kept congruent to the flags in the L3 LAN_ADJ-SID defined in [SR-ISIS]. * indicates a flag used in the L3 Adj-SID sub-TLV but which is NOT used in this sub-TLV. These bits SHOULD be sent as 0 and MUST be ignored on receipt. F-Flag: Address-Family flag. If unset, then the Adj-SID refers to an L2 Bundle Member with outgoing IPv4 encapsulation. If set then the Adj-SID refers to an L2 Bundle Member with outgoing IPv6 encapsulation. V-Flag: Value flag. If set, then the Adj-SID carries a value. By default the flag is SET. L-Flag: Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. S-Flag. Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of L2 Bundle Members (and therefore MAY be assigned to other L2 Bundle Members as well). P-Flag. Persistent flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap. Other bits: MUST be zero when originated and ignored when received. Ginsberg, et al. Expires November 26, 2017 [Page 8] Internet-Draft isis-l2bundles May 2017 Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [SR-ARCH]. NOTE: Flags and weight are shared by all L2 Bundle Members listed in the L2 Bundle Attribute Descriptor. L2 Bundle Member LAN Adj-SID Descriptors. There MUST be one descriptor for each of the L2 Bundle Members advertised under the preceding L2 Bundle Member Attribute Descriptor. Each descriptor consists of one of the following fields: SID/Index/Label: according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the SID/Label space advertised by this router. See [SR-ISIS]. In this case V and L flags MUST be unset. 4. IANA Considerations This document adds the following new TLV to the IS-IS TLV Codepoints registry. Value: 25 (suggested - to be assigned by IANA) Name: L2 Bundle Member Attributes The name of the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry needs to be changed to Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 registry. An additional column needs to be added to the registry to indicate which sub-TLVs may appear in the new L2 Bundle Member Attributes TLV. The column for TLV 25 has one of the following three values: y - sub-TLV may appear in TLV 25 but MUST NOT be shared by multiple L2 Bundle Members y(s) - sub-TLV may appear in TLV 25 and MAY be shared by multiple L2 Bundle Members n - sub-TLV MUST NOT appear in TLV 25 Ginsberg, et al. Expires November 26, 2017 [Page 9] Internet-Draft isis-l2bundles May 2017 The following table indicates the appropriate settings for all currently defined sub-TLVs as regards their use in the new L2 Bundle Member Attributes TLV. 3 Administrative group (color) y(s) 4 Link Local/Remote Identifiers y(s) 6 IPv4 interface address y(s) 8 IPv4 neighbor address y(s) 9 Maximum link bandwidth y(s) 10 Maximum reservable link bandwidth y(s) 11 Unreserved bandwidth y(s) 12 IPv6 Interface Address y(s) 13 IPv6 Neighbor Address y(s) 14 Extended Administrative Group y(s) 18 TE Default metric y(s) 19 Link-attributes y(s) 20 Link Protection Type y(s) 21 Interface Switching Capability Descriptor y(s) 22 Bandwidth Constraints y(s) 23 Unconstrained TE LSP Count y(s) 24 Remote AS number n 25 IPv4 remote ASBR Identifier n 26 IPv6 remote ASBR Identifier n 27 Interface Adjustment Capability Descriptor (IACD) y(s) 28 MTU n 29 SPB-Metric y(s) 30 SPB-A-OALG y(s) 33 Unidirectional Link Delay y 34 Min/Max Unidirectional Link Delay y 35 Unidirectional Delay Variation y 36 Unidirectional Link Loss y 37 Unidirectional Residual Bandwidth y 38 Unidirectional Available Bandwidth y 39 Unidirectional Utilized Bandwidth y 40 RTM Capability n This document adds the following new sub-TLVs to the sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 registry. Value: 41 (suggested - to be assigned by IANA) Name: L2 Bundle Member Adj-SID This sub-TLV is allowed in the following TLVs: 22 23 25 141 222 223 n n y n n n Ginsberg, et al. Expires November 26, 2017 [Page 10] Internet-Draft isis-l2bundles May 2017 Value: 42 (suggested to be assigned by IANA) Name: L2 Bundle Member LAN Adj-SID This sub-TLV is allowed in the following TLVs: 22 23 25 141 222 223 n n y n n n 5. Security Considerations The IS-IS protocol has supported the advertisement of link attribute information, including link identifiers, for many years. The advertisements defined in this document are identical to existing advertisements defined in [RFC4202], [RFC5305], [RFC7810], and [SR- ISIS] - but are associated with L2 links which are part of a bundle interface on which the IS-IS protocol operates. There are therefore no new security issues introduced by the extensions in this document. As always, if the protocol is used in an environment where unauthorized access to the physical links on which IS-IS PDUs are sent occurs then attacks are possible. The use of authentication as defined in [RFC5304] and [RFC5310] is recommended to prevent such attacks. 6. Contributors The following people gave a substantial contribution to the content of this document and should be considered as co-authors: Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy Email: sprevidi@cisco.com 7. Acknowledgements The authors would like to thank Jon Mitchell for his careful review. 8. References Ginsberg, et al. Expires November 26, 2017 [Page 11] Internet-Draft isis-l2bundles May 2017 8.1. Normative References [IEEE802.1AX] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation.", Nov 2008. [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, . Ginsberg, et al. Expires November 26, 2017 [Page 12] Internet-Draft isis-l2bundles May 2017 [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, . [SR-ISIS] "IS-IS Extensions for Segment Routing, draft-ietf-isis- segment-routing-extensions-12(work in progress)", April 2017. 8.2. Informational References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment- routing-11(work in progress)", February 2017. Appendix A. Example Encoding Below is an example encoding of L2 Bundle advertisements in a case where we have two parallel adjacencies to the same neighbor whose system-id is 1234.1234.1234.00. The two L2 bundles have the following sets of attributes: Ginsberg, et al. Expires November 26, 2017 [Page 13] Internet-Draft isis-l2bundles May 2017 L3 Adjacency #1 L3 IPv4 local link address: 192.0.2.1 Four bundle members with the following attributes: -------------------------------------------------- Num | Link Local ID | Bandwidth | Adj-SID/Weight | -------------------------------------------------- 1 | 0x11111111 | 1G | 0x11111/1 | -------------------------------------------------- 2 | 0x11112222 | 1G | 0x11112/1 | -------------------------------------------------- 3 | 0x11113333 | 10G | 0x11113/1 | -------------------------------------------------- 4 | 0x11114444 | 10G | 0x11114/1 | -------------------------------------------------- L3 Adjacency #2 L3 IPv4 local link address: 192.0.2.2 Three bundle members with the following attributes: -------------------------------------------------- Num | Link Local ID | Bandwidth | Adj-SID/Weight | -------------------------------------------------- 1 | 0x22221111 | 10G | 22221/1 | -------------------------------------------------- 2 | 0x22222222 | 10G | 22222/1 | -------------------------------------------------- 3 | 0x22223333 | 10G | 22223/1 | -------------------------------------------------- This requires two TLVs, one for each L3 adjacency. TLV for Adjacency #1: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(25) |Len: 64 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parent L3 Neighbor Descriptor 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor System-ID octets 1-4: 1234.1234 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System-ID octets 5-6: 1234 | P-node: 00 |1|0|0|0|0|0|0|0| Ginsberg, et al. Expires November 26, 2017 [Page 14] Internet-Draft isis-l2bundles May 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Interface Address sub-TLV 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(6)) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address:192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 Bundle Attribute Descriptors 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Len:9+6+10 = 25| # Desc: 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #1: 0x11111111 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #2: 0x11112222 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Link Bandwidth 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(9) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Value: 1G/8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 Bundle Member Adjacency Segment Identifier 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(41) | Length(8) |0|0|1|1|0|0|0|0| Weight: 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #1: 0x11111 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #2: 0x11112 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 Bundle Attribute Descriptors 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Len:9+6+10 = 25| # Desc: 2 | Ginsberg, et al. Expires November 26, 2017 [Page 15] Internet-Draft isis-l2bundles May 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #3: 0x11113333 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #4: 0x11114444 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Link Bandwidth 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(9) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Value: 10G/8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 Bundle Member Adjacency Segment Identifier 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(41) | Length(8) |0|0|1|1|0|0|0|0| Weight: 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #3: 0x11113 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #4: 0x11114 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV for Adjacency #2 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(25) | Len: 46 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parent L3 Neighbor Descriptor 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor System-ID octets 1-4: 1234.1234 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System-ID octets 5-6: 1234 | P-node: 00 |1|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Interface Address sub-TLV Ginsberg, et al. Expires November 26, 2017 [Page 16] Internet-Draft isis-l2bundles May 2017 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(6)) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address: 192.0.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 Bundle Attribute Descriptors 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Len:13+6+13=32 | # Desc: 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #1: 0x22221111 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #2: 0x22222222 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #3: 0x22223333 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Link Bandwidth 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(9) | Length(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Value: 10G/8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 Bundle Member Adjacency Segment Identifier 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(41) | Length(11) |0|0|1|1|0|0|0|0| Weight: 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #1: 0x22221 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #2: 0x22222 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #3: 0x22223 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ginsberg, et al. Expires November 26, 2017 [Page 17] Internet-Draft isis-l2bundles May 2017 Authors' Addresses Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA Email: ginsberg@cisco.com Ahmed Bashandy Cisco Systems 170 West Tasman Drive San Jose, Ca 95134 US Clarence Filsfils Cisco Systems Email: cf@cisco.com Mohan Nanduri eBay Email: mnanduri@ebay.com Ebben Aries Private Contributer Email: exa@dscp.org Ginsberg, et al. Expires November 26, 2017 [Page 18] ./draft-ietf-clue-framework-25.txt0000644000764400076440000055466312643774145016342 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-lamps-cms-hash-sig-10.txt0000644000764400076440000007137613540513571016770 0ustar iustyiusty INTERNET-DRAFT R. Housley Internet Engineering Task Force (IETF) Vigil Security Intended Status: Proposed Standard Expires: 18 March 2020 18 September 2019 Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS) Abstract This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. 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 Housley [Page 1] INTERNET-DRAFT September 2019 Copyright and License Notice Copyright (c) 2019 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. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. HSS/LMS Hash-based Signature Algorithm Overview . . . . . . . 4 2.1. Hierarchical Signature System (HSS) . . . . . . . . . . . 4 2.2. Leighton-Micali Signature (LMS) . . . . . . . . . . . . . 5 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) . . 6 3. Algorithm Identifiers and Parameters . . . . . . . . . . . . . 7 4. HSS/LMS Public Key Identifier . . . . . . . . . . . . . . . . 8 5. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Housley [Page 2] INTERNET-DRAFT September 2019 1. Introduction This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS) [CMS] signed-data content type. The LMS system provides a one-time digital signature that is a variant of Merkle Tree Signatures (MTS). The HSS is built on top of the LMS system to efficiently scale for a larger numbers of signatures. The HSS/LMS algorithm is one form of hash- based digital signature, and it is described in [HASHSIG]. The HSS/LMS signature algorithm can only be used for a fixed number of signing operations with a given private key, and the number of signing operations depends upon the size of the tree. The HSS/LMS signature algorithm uses small public keys, and it has low computational cost; however, the signatures are quite large. The HSS/LMS private key can be very small when the signer is willing to perform additional computation at signing time; alternatively, the private key can consume additional memory and provide a faster signing time. The HSS/LMS signatures [HASHSIG] are currently defined to use exclusively SHA-256 [SHS]. 1.1. ASN.1 CMS values are generated using ASN.1 [ASN1-B], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [ASN1-E]. 1.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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Motivation Recent advances in cryptanalysis [BH2013] and progress in the development of quantum computers [NAS2019] pose a threat to widely deployed digital signature algorithms. As a result, there is a need to prepare for a day that cryptosystems such as RSA and DSA that depend on discrete logarithm and factoring cannot be depended upon. If large-scale quantum computers are ever built, these computers will be able to break many of the public-key cryptosystems currently in use. A post-quantum cryptosystem [PQC] is a system that is secure against quantum computers that have more than a trivial number of quantum bits (qubits). It is open to conjecture when it will be Housley [Page 3] INTERNET-DRAFT September 2019 feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA are all vulnerable if large-scale quantum computers come to pass. Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. One use of post- quantum secure signatures is the protection of software updates, perhaps using the format described in [FWPROT], to enable deployment of software that implements new cryptosystems. 2. HSS/LMS Hash-based Signature Algorithm Overview Merkle Tree Signatures (MTS) are a method for signing a large but fixed number of messages. An MTS system depends on a one-time signature method and a collision-resistant hash function. This specification makes use of the hash-based algorithm specified in [HASHSIG], which is the Leighton and Micali adaptation [LM] of the original Lamport-Diffie-Winternitz-Merkle one-time signature system [M1979][M1987][M1989a][M1989b]. As implied by the name, the hash-based signature algorithm depends on a collision-resistant hash function. The hash-based signature algorithm specified in [HASHSIG] uses only the SHA-256 one-way hash function [SHS], but it establishes an IANA registry [IANA-LMS] to permit the registration of additional one-way hash functions in the future. 2.1. Hierarchical Signature System (HSS) The MTS system specified in [HASHSIG] uses a hierarchy of trees. The Hierarchical N-time Signature System (HSS) allows subordinate trees to be generated when needed by the signer. Otherwise, generation of the entire tree might take weeks or longer. An HSS signature as specified in [HASHSIG] carries the number of signed public keys (Nspk), followed by that number of signed public keys, followed by the LMS signature as described in Section 2.2. The public key for the top-most LMS tree is the public key of the HSS system. The LMS private key in the parent tree signs the LMS public key in the child tree, and the LMS private key in the bottom-most tree signs the actual message. The signature over the public key and the signature over the actual message are LMS signatures as described in Section 2.2. Housley [Page 4] INTERNET-DRAFT September 2019 The elements of the HSS signature value for a stand-alone tree (a top tree with no children) can be summarized as: u32str(0) || lms_signature /* signature of message */ where, u32str() and || are used as defined in [HASHSIG]. The elements of the HSS signature value for a tree with Nspk signed public keys can be summarized as: u32str(Nspk) || signed_public_key[0] || signed_public_key[1] || ... signed_public_key[Nspk-2] || signed_public_key[Nspk-1] || lms_signature /* signature of message */ where, as defined in Section 3.3 of [HASHSIG], the signed_public_key structure contains the lms_signature over the public key followed by the public key itself. Note that Nspk is the number of levels in the hierarchy of trees minus 1. 2.2. Leighton-Micali Signature (LMS) Each tree in the system specified in [HASHSIG] uses the Leighton- Micali Signature (LMS) system. LMS systems have two parameters. The first parameter is the height of the tree, h, which is the number of levels in the tree minus one. The [HASHSIG] specification supports five values for this parameter: h=5; h=10; h=15; h=20; and h=25. Note that there are 2^h leaves in the tree. The second parameter, m, is the number of bytes output by the hash function, and it is the amount of data associated with each node in the tree. The [HASHSIG] specification supports only the SHA-256 hash function [SHS], with m=32. As a result, the [HASHSIG] specification supports five tree sizes; they are identified as: LMS_SHA256_M32_H5; LMS_SHA256_M32_H10; LMS_SHA256_M32_H15; LMS_SHA256_M32_H20; and LMS_SHA256_M32_H25. The [HASHSIG] specification establishes an IANA registry [IANA-LMS] to permit the registration of additional hash functions and additional tree sizes in the future. Housley [Page 5] INTERNET-DRAFT September 2019 As specified in [HASHSIG], the LMS public key consists of four elements: the lms_algorithm_type from the list above, the otstype to identify the LM-OTS type as discussed in Section 2.3, the private key identifier (I) as described in Section 5.3 of [HASHSIG], and the m- byte string associated with the root node of the tree (T[1]). The LMS public key can be summarized as: u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] As specified in [HASHSIG], an LMS signature consists of four elements: the number of the leaf (q) associated with the LM-OTS signature, an LM-OTS signature as described in Section 2.3, a typecode indicating the particular LMS algorithm, and an array of values that is associated with the path through the tree from the leaf associated with the LM-OTS signature to the root. The array of values contains the siblings of the nodes on the path from the leaf to the root but does not contain the nodes on the path itself. The array for a tree with height h will have h values. The first value is the sibling of the leaf, the next value is the sibling of the parent of the leaf, and so on up the path to the root. The four elements of the LMS signature value can be summarized as: u32str(q) || ots_signature || u32str(type) || path[0] || path[1] || ... || path[h-1] 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) Merkle Tree Signatures (MTS) depend on a one-time signature method, and [HASHSIG] specifies the use of the LM-OTS, which has five parameters: n - The length in bytes of the hash function output. [HASHSIG] supports only SHA-256 [SHS], with n=32. H - A preimage-resistant hash function that accepts byte strings of any length, and returns an n-byte string. w - The width in bits of the Winternitz coefficients. [HASHSIG] supports four values for this parameter: w=1; w=2; w=4; and w=8. p - The number of n-byte string elements that make up the LM-OTS signature. Housley [Page 6] INTERNET-DRAFT September 2019 ls - The number of bits that are left-shifted in the final step of the checksum function, which is defined in Section 4.4 of [HASHSIG]. The values of p and ls are dependent on the choices of the parameters n and w, as described in Appendix B of [HASHSIG]. The [HASHSIG] specification supports four LM-OTS variants: LMOTS_SHA256_N32_W1; LMOTS_SHA256_N32_W2; LMOTS_SHA256_N32_W4; and LMOTS_SHA256_N32_W8. The [HASHSIG] specification establishes an IANA registry [IANA-LMS] to permit the registration of additional variants in the future. Signing involves the generation of C, an n-byte random value. The LM-OTS signature value can be summarized as the identifier of the LM-OTS variant, the random value, and a sequence of hash values (y[0] through y[p-1]) that correspond to the elements of the public key as described in Section 4.5 of [HASHSIG]: u32str(otstype) || C || y[0] || ... || y[p-1] 3. Algorithm Identifiers and Parameters The algorithm identifier for an HSS/LMS hash-based signatures is: id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 } When this object identifier is used for an HSS/LMS signature, the AlgorithmIdentifier parameters field MUST be absent (that is, the parameters are not present; the parameters are not set to NULL). The signature value is a large OCTET STRING as described in Section 2 of this document. The signature format is designed for easy parsing. The HSS, LMS, and LMOTS component of the signature value each format include a counter and a type code that indirectly provide all of the information that is needed to parse the value during signature validation. The signature value identifies the hash function used in the HSS/LMS tree. In [HASHSIG] uses only the SHA-256 hash function [SHS], but it establishes an IANA registry [IANA-LMS] to permit the registration of Housley [Page 7] INTERNET-DRAFT September 2019 additional hash functions in the future. 4. HSS/LMS Public Key Identifier The AlgorithmIdentifier for an HSS/LMS public key uses the id-alg- hss-lms-hashsig object identifier, and the parameters field MUST be absent. When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of an X.509 certificate [RFC5280], the certificate key usage extension MAY contain digitalSignature, nonRepudiation, keyCertSign, and cRLSign; however, it MUST NOT contain other values. pk-HSS-LMS-HashSig PUBLIC-KEY ::= { IDENTIFIER id-alg-hss-lms-hashsig KEY HSS-LMS-HashSig-PublicKey PARAMS ARE absent CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } HSS-LMS-HashSig-PublicKey ::= OCTET STRING Note that the id-alg-hss-lms-hashsig algorithm identifier is also referred to as id-alg-mts-hashsig. This synonym is based on the terminology used in an early draft of the document that became [HASHSIG]. The public key value is an OCTET STRING. Like the signature format, it is designed for easy parsing. The value is the number of levels in the public key, L, followed by the LMS public key. The HSS/LMS public key value can be described as: u32str(L) || lms_public_key Note that the public key for the top-most LMS tree is the public key of the HSS system. When L=1, the HSS system is a single tree. 5. Signed-data Conventions As specified in [CMS], the digital signature is produced from the message digest and the signer's private key. The signature is computed over different values depending on whether signed attributes are absent or present. When signed attributes are absent, the HSS/LMS signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used Housley [Page 8] INTERNET-DRAFT September 2019 in the HSS/LMS tree, and then a message-digest attribute is constructed with the hash of the content, and then the HSS/LMS signature is computed over the DER-encoded set of signed attributes (which MUST include a content-type attribute and a message-digest attribute). In summary: IF (signed attributes are absent) THEN HSS_LMS_Sign(content) ELSE message-digest attribute = Hash(content); HSS_LMS_Sign(DER(SignedAttributes)) When using [HASHSIG], the fields in the SignerInfo are used as follows: digestAlgorithm MUST contain the one-way hash function used in the HSS/LMS tree. In [HASHSIG], SHA-256 is the only supported hash function, but other hash functions might be registered in the future. For convenience, the AlgorithmIdentifier for SHA-256 from [PKIXASN1] is repeated here: mda-sha256 DIGEST-ALGORITHM ::= { IDENTIFIER id-sha256 PARAMS TYPE NULL ARE preferredAbsent } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) hashalgs(2) 1 } signatureAlgorithm MUST contain id-alg-hss-lms-hashsig, and the algorithm parameters field MUST be absent. signature contains the single HSS signature value resulting from the signing operation as specified in [HASHSIG]. 6. Security Considerations Implementations MUST protect the private keys. Compromise of the private keys may result in the ability to forge signatures. Along with the private key, the implementation MUST keep track of which leaf nodes in the tree have been used. Loss of integrity of this tracking data can cause a one-time key to be used more than once. As a result, when a private key and the tracking data are stored on non- volatile media or stored in a virtual machine environment, failed writes, virtual machine snapshotting or cloning, and other operational concerns must be considered to ensure confidentiality and integrity. When generating an LMS key pair, an implementation MUST generate each Housley [Page 9] INTERNET-DRAFT September 2019 key pair independently of all other key pairs in the HSS tree. An implementation MUST ensure that a LM-OTS private key is used to generate a signature only one time, and ensure that it cannot be used for any other purpose. The generation of private keys relies on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate these values 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, and [RFC4086] offers important guidance in this area. The generation of hash-based signatures also depends on random numbers. While the consequences of an inadequate pseudo-random number generator (PRNG) to generate these values is much less severe than in the generation of private keys, the guidance in [RFC4086] remains important. When computing signatures, the same hash function SHOULD be used to compute the message digest of the content and the signed attributes, if they are present. 7. IANA Considerations SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry, change the reference for value 64 to point to this document. In the SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry, change the description for value 17 to "id-alg-hss-lms-hashsig" and change the reference to point to this document. Also, add the following note to the registry: Value 17, "id-alg-hss-lms-hashsig", is also referred to as "id-alg-mts-hashsig". 8. References 8.1. Normative References [ASN1-B] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2015. Housley [Page 10] INTERNET-DRAFT September 2019 [ASN1-E] 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. [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [HASHSIG] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali Hash-Based Signatures", RFC 8554, April 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SHS] National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008. 8.2. Informative References [BH2013] Ptacek, T., T. Ritter, J. Samuel, and A. Stamos, "The Factoring Dead: Preparing for the Cryptopocalypse", August 2013. [CMSASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, . Housley [Page 11] INTERNET-DRAFT September 2019 [CMSASN1U] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, . [FWPROT] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005, . [IANA-LMS] IANA Registry for Leighton-Micali Signatures (LMS). . [LM] Leighton, T. and S. Micali, "Large provably fast and secure digital signature schemes from secure hash functions", U.S. Patent 5,432,852, July 1995. [M1979] Merkle, R., "Secrecy, Authentication, and Public Key Systems", Stanford University Information Systems Laboratory Technical Report 1979-1, 1979. [M1987] Merkle, R., "A Digital Signature Based on a Conventional Encryption Function", Lecture Notes in Computer Science crypto87, 1988. [M1989a] Merkle, R., "A Certified Digital Signature", Lecture Notes in Computer Science crypto89, 1990. [M1989b] Merkle, R., "One Way Hash Functions and DES", Lecture Notes in Computer Science crypto89, 1990. [NAS2019] National Academies of Sciences, Engineering, and Medicine, "Quantum Computing: Progress and Prospects", The National Academies Press, DOI 10.17226/25196, 2019. [PKIXASN1] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [PQC] Bernstein, D., "Introduction to post-quantum cryptography", 2009. Housley [Page 12] INTERNET-DRAFT September 2019 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . Appendix: ASN.1 Module MTS-HashSig-2013 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ; -- -- Object Identifiers -- id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 17 } id-alg-mts-hashsig OBJECT IDENTIFIER ::= id-alg-hss-lms-hashsig -- -- Signature Algorithm and Public Key -- sa-HSS-LMS-HashSig SIGNATURE-ALGORITHM ::= { IDENTIFIER id-alg-hss-lms-hashsig PARAMS ARE absent PUBLIC-KEYS { pk-HSS-LMS-HashSig } SMIME-CAPS { IDENTIFIED BY id-alg-hss-lms-hashsig } } Housley [Page 13] INTERNET-DRAFT September 2019 pk-HSS-LMS-HashSig PUBLIC-KEY ::= { IDENTIFIER id-alg-hss-lms-hashsig KEY HSS-LMS-HashSig-PublicKey PARAMS ARE absent CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } HSS-LMS-HashSig-PublicKey ::= OCTET STRING -- -- Expand the signature algorithm set used by CMS [CMSASN1U] -- SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= { sa-HSS-LMS-HashSig, ... } -- -- Expand the S/MIME capabilities set used by CMS [CMSASN1] -- SMimeCaps SMIME-CAPS ::= { sa-HSS-LMS-HashSig.&smimeCaps, ... } END Acknowledgements Many thanks to Scott Fluhrer, Jonathan Hammell, Ben Kaduk, Panos Kampanakis, Barry Leiba, John Mattsson, Jim Schaad, Sean Turner, Daniel Van Geest, Roman Danyliw, Dale Worley, and Joe Clarke for their careful review and comments. Author's Address Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 USA EMail: housley@vigilsec.com Housley [Page 14] ./draft-ietf-clue-rtp-mapping-14.txt0000644000764400076440000007777313055040163016563 0ustar iustyiusty CLUE WG R. Even Internet-Draft Huawei Technologies Intended status: Standards Track J. Lennox Expires: August 31, 2017 Vidyo February 27, 2017 Mapping RTP streams to CLUE Media Captures draft-ietf-clue-rtp-mapping-14.txt Abstract This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId). 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 31, 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 Even & Lennox Expires August 31, 2017 [Page 1] Internet-Draft RTP mapping to CLUE February 2017 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. RTP topologies for CLUE . . . . . . . . . . . . . . . . . . . 3 4. Mapping CLUE Capture Encodings to RTP streams . . . . . . . . 4 5. MCC Constituent CaptureID definition . . . . . . . . . . . . 5 5.1. RTCP CaptureID SDES Item . . . . . . . . . . . . . . . . 5 5.2. RTP Header Extension . . . . . . . . . . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Communication Security . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Telepresence systems can send and receive multiple media streams. The CLUE framework [I-D.ietf-clue-framework] defines Media Captures (MC) as a source of Media, from one or more Capture Devices. A Media Capture may also be constructed from other Media streams. A middle box can express conceptual Media Captures that it constructs from Media streams it receives. A Multiple Content Capture (MCC) is a special Media Capture composed of multiple Media Captures. SIP Offer/Answer [RFC3264] uses SDP [RFC4566] to describe the RTP[RFC3550] media streams. Each RTP stream has a unique Synchronization Source (SSRC) within its RTP session. The content of the RTP stream is created by an encoder in the endpoint. This may be an original content from a camera or a content created by an intermediary device like an MCU (Multipoint Control Unit). This document makes recommendations for the CLUE architecture about how RTP and RTCP streams should be encoded and transmitted, and how their relation to CLUE Media Captures should be communicated. The proposed solution supports multiple RTP topologies [RFC7667]. With regards to the media (audio, video and timed text), systems that support CLUE use RTP for the media, SDP for codec and media transport negotiation (CLUE individual encodings) and the CLUE protocol for Media Capture description and selection. In order to associate the Even & Lennox Expires August 31, 2017 [Page 2] Internet-Draft RTP mapping to CLUE February 2017 media in the different protocols there are three mapping that need to be specified: 1. CLUE individual encodings to SDP 2. RTP streams to SDP (this is not a CLUE specific mapping) 3. RTP streams to MC to map the received RTP steam to the current MC in the MCC. 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[RFC2119] and indicate requirement levels for RTP processing in compliant CLUE implementations. The definitions from the CLUE framework document [I-D.ietf-clue-framework] section 3 are used by this document as well. 3. RTP topologies for CLUE The typical RTP topologies used by CLUE Telepresence systems specify different behaviors for RTP and RTCP distribution. A number of RTP topologies are described in [RFC7667]. For CLUE telepresence, the relevant topologies include Point-to-Point, as well as Media-Mixing mixers, Media- Switching mixers, and Selective Forwarding Middleboxs. In the Point-to-Point topology, one peer communicates directly with a single peer over unicast. There can be one or more RTP sessions, each sent on a separate 5-tuple, and having a separate SSRC space, with each RTP session carrying multiple RTP streams identified by their SSRC. All SSRCs are recognized by the peers based on the information in the RTCP Source description (SDES) report that includes the CNAME and SSRC of the sent RTP streams. There are different Point-to-Point use cases as specified in CLUE use case [RFC7205]. In some cases, a CLUE session which, at a high-level, is point-to-point may nonetheless have an RTP stream which is best described by one of the mixer topologies. For example, a CLUE endpoint can produce composite or switched captures for use by a receiving system with fewer displays than the sender has cameras. The Media Capture may be described using an MCC. For the Media Mixer topology [RFC7667], the peers communicate only with the mixer. The mixer provides mixed or composited media streams, using its own SSRC for the sent streams. If needed by CLUE Even & Lennox Expires August 31, 2017 [Page 3] Internet-Draft RTP mapping to CLUE February 2017 endpoint, the conference roster information including conference participants, endpoints, media and media-id (SSRC) can be determined using the conference event package [RFC4575] element. Media-switching mixers and Selective Forwarding Middleboxes behave as described in [RFC7667] 4. Mapping CLUE Capture Encodings to RTP streams The different topologies described in Section 3 create different SSRC distribution models and RTP stream multiplexing points. Most video conferencing systems today can separate multiple RTP sources by placing them into RTP sessions using the SDP description; the video conferencing application can also have some knowledge about the purpose of each RTP session. For example, video conferencing applications that have a primary video source and a slides video source can send each media source in a separate RTP session with a content attribute [RFC4796] enabling different application behavior for each received RTP media source. Demultiplexing is straightforward because each media capture is sent as a single RTP stream, with each RTP stream being sent in a separate RTP session, on a distinct UDP 5-tuple. This will also be true for mapping the RTP streams to Media Captures Encodings if each Media Capture Encodings uses a separate RTP session, and the consumer can identify it based on the receiving RTP port. In this case, SDP only needs to label the RTP session with an identifier that can be used to identify the Media Capture in the CLUE description. The SDP label attribute serves as this identifier. Each Capture Encoding MUST be sent as a separate RTP stream. CLUE endpoints MUST support sending each such RTP stream in a separate RTP session signalled by an SDP m= line. They MAY also support sending some or all of the RTP streams in a single RTP session, using the mechanism described in [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m= lines. MCCs bring another mapping issue, in that an MCC represents multiple Media Captures that can be sent as part of this MCC if configured by the consumer. When receiving an RTP stream which is mapped to the MCC, the consumer needs to know which original MC it is in order to get the MC parameters from the advertisement. If a consumer requested a MCC, the original MC does not have a capture encoding, so it cannot be associated with an m-line using a label as described in CLUE signaling [I-D.ietf-clue-signaling]. This is important, for example, to get correct scaling information for the original MC, which may be different for the various MCs that are contributing to the MCC. Even & Lennox Expires August 31, 2017 [Page 4] Internet-Draft RTP mapping to CLUE February 2017 5. MCC Constituent CaptureID definition For a MCC which can represent multiple switched MCs there is a need to know which MC is represented in the current RTP stream at any given time. This requires a mapping from the SSRC of the RTP stream conveying a particular MCC to the constituent MC. In order to address this mapping this document defines an RTP header extension and SDES item that includes the captureID of the original MC, allowing the consumer to use the original source MC's attributes like the spatial information. This mapping temporarily associates the SSRC of the RTP stream conveying a particular MCC with the captureID of the single original MC that is currently switched into the MCC. This mapping cannot be used for the composed case where more than one original MC is composed into the MCC simultaneously. If there is only one MC in the MCC then the media provider MUST send the captureID of the current constituent MC in the RTP Header Extension and as a RTCP CaptureID SDES item. When the media provider switches the MC it sends within an MCC, it MUST send the captureID value for the MC just switched into the MCC in an RTP Header Extension and as a RTCP CaptureID SDES item as specified in [RFC7941] If there is more than one MC composed into the MCC then the media provider MUST NOT send any of the MCs' captureIDs using this mechanism. However, if an MCC is sending contributing source (CSRC) information in the RTP header for a composed capture, it MAY send the captureID values in the RTCP SDES packets giving source information for the SSRC values sent as contributing sources (CSRCs). If the media provider sends the captureID of a single MC switched into an MCC, then later sends one composed stream of multiple MCs in the same MCC, it MUST send the special value "-", a single dash character, as the captureID RTP Header Extension and RTCP CaptureID SDES item. The single dash character indicates there is no applicable value for the MCC constituent CaptureID. The media consumer interprets this as meaning that any previous CaptureID value associated with this SSRC no longer applies. As [I-D.ietf-clue-data-model-schema] defines the captureID syntax as "xs:ID", the single dash character is not a legal captureID value, so there is no possibility of confusing it with an actual captureID. 5.1. RTCP CaptureID SDES Item This document specifies a new RTCP SDES item. Even & Lennox Expires August 31, 2017 [Page 5] Internet-Draft RTP mapping to CLUE February 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CaptId=TBA | length | CaptureID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+ Note to the RFC Editor: Please replace TBA with the value assigned by IANA. This CaptureID is a variable-length UTF-8 string corresponding either to a CaptureID negotiated in the CLUE protocol, or the single character "-". This SDES item MUST be sent in an SDES packet within a compound RTCP packet unless support for Reduced-size RTCP has been negotiated as specified in RFC 5506 [RFC5506], in which case it can be sent as an SDES packet in a non-compound RTCP packet. 5.2. RTP Header Extension The CaptureID is also carried in an RTP header extension [RFC5285], using the mechanism defined in [RFC7941]. Support is negotiated within SDP using the URN "urn:ietf:params:rtp- hdrext:sdes:CaptureID". The CaptureID is sent in a RTP Header Extension because for switched captures, receivers need to know which original MC corresponds to the media being sent for an MCC, in order to correctly apply geometric adjustments to the received media. As discussed in [RFC7941], there is no need to send the CaptId Header Extension with all RTP packets. Senders MAY choose to send it only when a new MC is sent. If such a mode is being used, the header extension SHOULD be sent in the first few RTP packets to reduce the risk of losing it due to packet loss. See [RFC7941] for more discussion of this. 6. Examples In this partial advertisement the Media Provider advertises a composed capture VC7 made of a big picture representing the current speaker (VC3) and two picture-in-picture boxes representing the previous speakers (the previous one -VC5- and the oldest one -VC6). Even & Lennox Expires August 31, 2017 [Page 6] Internet-Draft RTP mapping to CLUE February 2017 CS1 true VC3 VC5 VC6 3 false big picture of the current speaker pips about previous speakers 1 it static individual In this case the media provider will send capture IDs VC3, VC5 or VC6 as an RTP header extension and RTCP SDES message for the RTP stream associated with the MC. Note that this is part of the full advertisement message example from CLUE data model[I-D.ietf-clue-data-model-schema] example and is not a valid xml document. 7. Communication Security CLUE endpoints MUST support RTP/SAVPF profile and SRTP [RFC3711]. CLUE endpoints MUST support DTLS [RFC6347] and DTLS-SRTP [RFC5763] [RFC5764] for SRTP keying. All media channels SHOULD be secure via SRTP and the RTP/SAVPF profile unless the RTP media and its associated RTCP are secure by other means (see [RFC7201] [RFC7202]). All CLUE implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.Encrypted SRTP Header extensions [RFC6904] MUST be supported. Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. Even & Lennox Expires August 31, 2017 [Page 7] Internet-Draft RTP mapping to CLUE February 2017 NULL Protection profiles MUST NOT be used for RTP or RTCP. CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as specified in [RFC7022], and thus can't be used for long term tracking of the users. 8. Acknowledgments The authors would like to thanks Allyn Romanow and Paul Witty for contributing text to this work. Magnus Westerlund helped drafting the security section. 9. IANA Considerations This document defines a new extension URI in the RTP SDES Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext:sdes:CaptId Description: CLUE CaptId Contact: ron.even.tlv@gmail.com Reference: RFC XXXX 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 CCID CLUE CaptId [RFCXXXX] Note to the RFC Editor: Please replace RFCXXXX with this RFC number. 10. Security Considerations 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 Even & Lennox Expires August 31, 2017 [Page 8] Internet-Draft RTP mapping to CLUE February 2017 profile and DTLS-SRTP keying [RFC5764] as defined in the communication security section of this memo Section 7 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 calls. The communication security section of this memo Section 7 mandates generation of short- term persistent RTCP CNAMES, as specified in [RFC7022] so they can't be used for long term tracking of the users. 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 [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 ([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 Even & Lennox Expires August 31, 2017 [Page 9] Internet-Draft RTP mapping to CLUE February 2017 interval small enough that the RTCP bandwidth would exceed the media bandwidth. The guidelines in [RFC6562] apply when using variable bit rate (VBR) audio codecs such as Opus. 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; this middleboxes are REQUIRED, by this protocol, to not weaken the sessions' security. The middlebox SHOULD maintain the confidentiality, integrity and perform source authentication. The middlebox MAY 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 [RFC7667] The CaptureID is created as part of the CLUE protocol. The CaptId SDES item is used to convey the same CaptureID value in the SDES item. When sending the SDES item the security consideration specified in the security section of [RFC7941] and in the communication security section of this memo Section 7 are applicable. Note that since the CaptureID is carried also in CLUE protocol messages it is RECOMMENDED that this SDES item use at least similar protection profiles as the CLUE protocol messages carried in the CLUE data channel. . 11. References 11.1. Normative References [I-D.ietf-clue-data-model-schema] Presta, R. and S. Romano, "An XML Schema for the CLUE data model", draft-ietf-clue-data-model-schema-17 (work in progress), 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. Even & Lennox Expires August 31, 2017 [Page 10] Internet-Draft RTP mapping to CLUE February 2017 [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-36 (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, . [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, . [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, . [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, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 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, . 11.2. Informative References [FIPS186] National Institute of Standards and Technology, "Digital Signature Standard", FIPS PUB 186-4, July 2013. Even & Lennox Expires August 31, 2017 [Page 11] Internet-Draft RTP mapping to CLUE February 2017 [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., and R. Hansen, "CLUE Signaling", draft-ietf-clue-signaling-10 (work in progress), January 2017. [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, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [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, . [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, . Even & Lennox Expires August 31, 2017 [Page 12] Internet-Draft RTP mapping to CLUE February 2017 [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, . [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, . [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, . [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, . [RFC7205] Romanow, A., Botzko, S., Duckworth, M., and R. Even, Ed., "Use Cases for Telepresence Multistreams", RFC 7205, DOI 10.17487/RFC7205, April 2014, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Authors' Addresses Even & Lennox Expires August 31, 2017 [Page 13] Internet-Draft RTP mapping to CLUE February 2017 Roni Even Huawei Technologies Tel Aviv Israel Email: roni.even@huawei.com Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Even & Lennox Expires August 31, 2017 [Page 14] ./draft-ietf-lsr-isis-rfc5306bis-09.txt0000644000764400076440000017402013541020667016722 0ustar iustyiusty IS-IS for IP Internets L. Ginsberg Internet-Draft P. Wells Obsoletes: 5306 (if approved) Cisco Systems, Inc. Intended status: Standards Track September 19, 2019 Expires: March 22, 2020 Restart Signaling for IS-IS draft-ietf-lsr-isis-rfc5306bis-09 Abstract 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 router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. 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 5306. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 Ginsberg & Wells Expires March 22, 2020 [Page 1] Internet-Draft restart-signalling-for-IS-IS September 2019 working documents as Internet-Drafts. The list of current Internet- Drafts is at https://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 22, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Restart TLV . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Use of RR and RA Bits . . . . . . . . . . . . . . . . 7 3.2.2. Use of the SA Bit . . . . . . . . . . . . . . . . . . 8 3.2.3. Use of PR and PA Bits . . . . . . . . . . . . . . . . 9 3.3. Adjacency (Re)Acquisition . . . . . . . . . . . . . . . . 11 3.3.1. Adjacency Reacquisition during Restart . . . . . . . 11 3.3.2. Adjacency Acquisition during Start . . . . . . . . . 13 3.3.3. Multiple Levels . . . . . . . . . . . . . . . . . . . 15 3.4. Database Synchronization . . . . . . . . . . . . . . . . 15 3.4.1. LSP Generation and Flooding and SPF Computation . . . 16 4. State Tables . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Running Router . . . . . . . . . . . . . . . . . . . . . 19 4.2. Restarting Router . . . . . . . . . . . . . . . . . . . . 20 4.3. Starting Router . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Manageability Considerations . . . . . . . . . . . . . . . . 24 Ginsberg & Wells Expires March 22, 2020 [Page 2] Internet-Draft restart-signalling-for-IS-IS September 2019 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. Normative References . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Summary of Changes from RFC 5306 . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Overview The Intermediate System to Intermediate System (IS-IS) routing protocol [RFC1195] [ISO10589] is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router. The router that has been restarted computes its own routes before achieving database synchronization with its neighbors. The results of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain. Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the down state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes a temporary disruption of routes passing through the restarting router. In certain scenarios, the temporary disruption of the routes is highly undesirable. This document describes mechanisms to avoid or minimize the disruption due to both of these causes. When an adjacency is reinitialized as a result of a neighbor restarting, a router does three things: 1. It causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain). 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link, it transmits a complete set of Complete Sequence Number PDUs (CSNPs), over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database. The third action above minimizes the number of LSPs that must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. Ginsberg & Wells Expires March 22, 2020 [Page 3] Internet-Draft restart-signalling-for-IS-IS September 2019 This is desirable whether or not the router is being restarted (so that the overload bit can be cleared in the router's own LSP, for example). This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting. The mechanism further allows the neighbors to reestablish their adjacencies with the restarting router 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 and minimize transient routing disruption when a router starts. It is assumed that the three-way handshake [RFC5303] is being used on Point-to-Point circuits. 2. Conventions Used in This Document If the control and forwarding functions in a router can be maintained independently, it is possible for the forwarding function state to be maintained across a resumption of control function operations. This functionality is assumed when the terms "restart/restarting" are used in this document. The terms "start/starting" are used to refer to a router in which the control function has either commenced operations for the first time or has resumed operations, but the forwarding functions have not been maintained in a prior state. The terms "(re)start/(re)starting" are used when the text is applicable to both a "starting" and a "restarting" router. The terms "normal IIH" or "IIH normal" refer to IS-IS Hellos (IIHs) in which the Restart TLV (defined later in this document) has no flags set. 3. Approach 3.1. Timers Three additional timers, T1, T2, and T3, are required to support the mechanisms defined in this document. Timers T1 and T2 are used both by a restarting router and a starting router. Timer T3 is used only by a restarting router. Ginsberg & Wells Expires March 22, 2020 [Page 4] Internet-Draft restart-signalling-for-IS-IS September 2019 NOTE: These timers are NOT applicable to a router which is preparing to do a planned restart. An instance of the timer T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value is 3 seconds. An instance of the timer T2 is maintained for each LSP database (LSPDB) present in the system. For example, for a Level 1/2 system, there will be an instance of the timer T2 for Level 1 and an instance for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value is 60 seconds. A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with the Restart Acknowledgement (RA) set and an indication that the neighbor has an adjacency in the "UP" state to the restarting router. (See Section 3.2.1a.) 3.2. Restart TLV A new TLV is defined to be included in IIH PDUs. The TLV includes flags that are used to convey information during a (re)start. The absence of this TLV indicates that the sender supports none of the functionality defined in this document. Therefore, if a router supports any of the functionality defined in this document it MUST include this TLV in all transmitted IIHs. Type 211 Length: Number of octets in the Value field (1 to (3 + ID Length)) Value No. of octets +-----------------------+ | Flags | 1 +-----------------------+ | Remaining Time | 2 +-----------------------+ | Restarting Neighbor ID| ID Length +-----------------------+ Flags (1 octet) Ginsberg & Wells Expires March 22, 2020 [Page 5] Internet-Draft restart-signalling-for-IS-IS September 2019 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |Reserved|PA|PR|SA|RA|RR| +--+--+--+--+--+--+--+--+ RR - Restart Request RA - Restart Acknowledgement SA - Suppress adjacency advertisement PR - Restart is planned PA - Planned restart acknowledgement Remaining Time (2 octets) Remaining holding time (in seconds). Required when the RA, PR, or PA bit is set. Otherwise this field SHOULD be omitted when sent and MUST be ignored when received. Restarting Neighbor System ID (ID Length octets) The System ID of the neighbor to which an RA/PA refers. Required when the RA or PA bit is set. Otherwise this field SHOULD be omitted when sent and MUST be ignored when received. Note: Very early draft versions of the restart functionality did not include the Restarting Neighbor System ID in the TLV. RFC 5306 allowed for the possibility of interoperating with legacy implementations by stating that a router that is expecting an RA on a LAN circuit should assume that the acknowledgement is directed at the local system if the TLV is received with RA set and Restarting Neighbor System ID is not present. It is an implementation choice whether to continue to accept (on a LAN) a TLV with RA set and Restarting Neighbor System ID absent. Note that the omission of the Restarting Neighbor System ID only introduces ambiguity in the case where there are multiple systems on a LAN simultaneously performing restart. The RR and SA flags may both be set in the TLV under the conditions described in Section 3.3.2. All other combinations where multiple flags are set are invalid and MUST NOT be transmitted. Received TLVs which have invalid flag combinations set MUST be ignored. Ginsberg & Wells Expires March 22, 2020 [Page 6] Internet-Draft restart-signalling-for-IS-IS September 2019 3.2.1. Use of RR and RA Bits The RR bit is used by a (re)starting router to signal to its neighbors that a (re)start is in progress, that an existing adjacency SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of the SRMflags. The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a restart TLV with the RR bit set. When the neighbor of a (re)starting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "UP" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then, irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits) or the "Point-to-Point Three-Way Adjacency" option (Point-to-Point circuits): a. the state of the adjacency is not changed. If this is the first IIH with the RR bit set that this system has received associated with this adjacency, then the adjacency is marked as being in "Restart mode" and the adjacency holding time is refreshed -- otherwise, the holding time is not refreshed. The "remaining time" transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of an IIH with the RR bit reset will clear the "Restart mode" state. This procedure allows the restarting router to cause the neighbor to maintain the adjacency long enough for restart to successfully complete, while also preventing repetitive restarts from maintaining an adjacency indefinitely. Whether or not an adjacency is marked as being in "Restart mode" has no effect on adjacency state transitions. b. immediately (i.e., without waiting for any currently running timer interval to expire, but with a small random delay of a few tens of milliseconds on LANs to avoid "storms") transmit over the corresponding interface an IIH including the restart TLV with the RR bit clear and the RA bit set, in the case of Point-to-Point adjacencies having updated the "Point-to-Point Three-Way Adjacency" option to reflect any new values received from the (re)starting router. (This allows a restarting router to quickly acquire the correct information to place in its hellos.) The "Remaining Time" MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of Ginsberg & Wells Expires March 22, 2020 [Page 7] Internet-Draft restart-signalling-for-IS-IS September 2019 the router from which the IIH with the RR bit set was received. This is required to correctly associate the acknowledgement and holding time in the case where multiple systems on a LAN restart at approximately the same time. This IIH SHOULD be transmitted before any LSPs or SNPs are transmitted as a result of the receipt of the original IIH. c. if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with the highest source MAC (Media Access Control) address breaking ties) among those routers to which the receiving router has an adjacency in state "UP" on this interface whose IIHs contain the restart TLV, excluding adjacencies to all routers which are considered in "Restart mode" (note the actual DIS is NOT changed by this process), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. Otherwise (i.e., if there was no adjacency in the "UP" state to the System ID in question), process the IIH as normal by reinitializing the adjacency and setting the RA bit in the returned IIH. 3.2.2. Use of the SA Bit The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs. A router that is starting has no maintained forwarding function state. This may or may not be the first time the router has started. If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network. These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router. This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers. The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations. When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "UP" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the router MUST suppress advertisement Ginsberg & Wells Expires March 22, 2020 [Page 8] Internet-Draft restart-signalling-for-IS-IS September 2019 of the adjacency to the neighbor in its own LSPs. Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed. If the adjacency transitions to the "UP" state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received. Note that a router that suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation. In particular, if an implementation follows the example guidelines presented in [ISO10589], Annex C.2.5, Step 0:b) "pre-load TENT with the local adjacency database", the suppressed adjacency MUST NOT be loaded into TENT. 3.2.3. Use of PR and PA Bits The PR bit is used by a router which is planning to initiate a restart to signal to its neighbors that it will be restarting. The router sending an IIH with PR bit set SHOULD set the "remaining time" to a value greater than the expected control plane restart time. The PR bit SHOULD remain set in IIHs until the restart is initiated. The PA bit is sent by the neighbor of a router planning to restart to acknowledge receipt of a restart TLV with the PR bit set. When the neighbor of a router planning a restart receives an IIH with the restart TLV having the PR bit set, if there exists on this interface an adjacency in state "UP" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then: a. if this is the first IIH with the PR bit set that this system has received associated with this adjacency, then the adjacency is marked as being in "Planned Restart state" and the adjacency holding time is refreshed -- otherwise, the holding time is not refreshed. The holding time SHOULD be set to the "remaining time" specified in the received IIH with PR set. The "remaining time" transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of an IIH with the PR bit reset will clear the "Planned Restart state" and cause the receiving router to set the adjacency hold time to the locally configured value. This procedure allows the router planning a restart to cause the neighbor to maintain the adjacency long enough for restart to successfully complete. Whether or not an adjacency is marked as being in "Planned Restart state" has no effect on adjacency state transitions. b. immediately (i.e., without waiting for any currently running timer interval to expire, but with a small random delay of a few tens of milliseconds on LANs to avoid "storms") transmit over the Ginsberg & Wells Expires March 22, 2020 [Page 9] Internet-Draft restart-signalling-for-IS-IS September 2019 corresponding interface an IIH including the restart TLV with the PR bit clear and the PA bit set. The "Remaining Time" MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of the router from which the IIH with the PR bit set was received. This is required to correctly associate the acknowledgement and holding time in the case where multiple systems on a LAN are planning a restart at approximately the same time. NOTE: Receipt of an IIH with PA bit set indicates to the router planning a restart that the neighbor is aware of the planned restart and - in the absence of topology changes as described below - will maintain the adjacency for the "remaining time" included in the IIH with PA set. By definition, a restarting router maintains forwarding state across the control plane restart (see Section 2). But while a control plane restart is in progress it is expected that the restarting router will be unable to respond to topology changes. It is therefore useful to signal a planned restart so that the neighbors of the restarting router can determine whether it is safe to maintain the adjacency if other topology changes occur prior to the completion of the restart. Signalling a planned restart in the absence of maintained forwarding plane state is likely to lead to significant traffic loss and MUST NOT be done. Neighbors of the router which has signaled planned restart SHOULD maintain the adjacency in a planned restart state until it receives an IIH with the RR bit set, receives an IIH with both PR and RR bits clear, or the adjacency holding time expires - whichever occurs first. Neighbors which choose not to follow the recommended behavior need to consider the impact on traffic delivery of not using the restarting router for forwarding traffic during the restart period. While the adjacency is in planned restart state some or all of the following actions MAY be taken: a. if additional topology changes occur, the adjacency which is in planned restart state MAY be brought down even though the hold time has not yet expired. Given that the neighbor which has signaled a planned restart is not expected to update its forwarding plane in response to signalling of the topology changes (since it is restarting) traffic which transits that node is at risk of being improperly forwarded. On a LAN circuit, if the router in planned restart state is the DIS at any supported level, the adjacency(ies) SHOULD be brought down whenever any LSP Ginsberg & Wells Expires March 22, 2020 [Page 10] Internet-Draft restart-signalling-for-IS-IS September 2019 update is either generated or received, so as to trigger a new DIS election. Failure to do so will compromise the reliability of the Update Process on that circuit. What other criteria are used to determine what topology changes will trigger bringing the adjacency down is a local implementation decision. b. if a BFD [RFC5880] session to the neighbor which signals a planned restart is in the UP state and subsequently goes DOWN, the event MAY be ignored since it is possible this is an expected side effect of the restart. Use of the Control Plane Independent state as signalled in BFD control packets SHOULD be considered in the decision to ignore a BFD Session DOWN event. c. on a Point-to-Point circuit, transmission of LSPs, CSNPs, and PSNPs MAY be suppressed. It is expected that the PDUs will not be received. Use of the PR bit provides a means to safely support restart periods which are significantly longer than standard holdtimes. 3.3. Adjacency (Re)Acquisition Adjacency (re)acquisition is the first step in (re)initialization. Restarting and starting routers will make use of the RR bit in the restart TLV, though each will use it at different stages of the (re)start procedure. 3.3.1. Adjacency Reacquisition during Restart The restarting router explicitly notifies its neighbor that the adjacency is being reacquired, and hence that it SHOULD NOT reinitialize the adjacency. This is achieved by setting the RR bit in the restart TLV. When the neighbor of a restarting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "UP" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the procedures described in Section 3.2.1 are followed. A router that does not support the restart capability will ignore the restart TLV and reinitialize the adjacency as normal, returning an IIH without the restart TLV. On restarting, a router initializes the timer T3, starts the timer T2 for each LSPDB, and for each interface (and in the case of a LAN circuit, for each level) starts the timer T1 and transmits an IIH containing the restart TLV with the RR bit set. Ginsberg & Wells Expires March 22, 2020 [Page 11] Internet-Draft restart-signalling-for-IS-IS September 2019 On a Point-to-Point circuit, the restarting router SHOULD set the "Adjacency Three-Way State" to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter the "UP" state immediately. On a LAN circuit, the LAN-ID assigned to the circuit SHOULD be the same as that used prior to the restart. In particular, for any circuits for which the restarting router was previously DIS, the use of a different LAN-ID would necessitate the generation of a new set of pseudonode LSPs, and corresponding changes in all the LSPs referencing them from other routers on the LAN. By preserving the LAN-ID across the restart, this churn can be prevented. To enable a restarting router to learn the LAN-ID used prior to restart, the LAN- ID specified in an IIH with RR set MUST be ignored. Transmission of "normal IIHs" is inhibited until the conditions described below are met (in order to avoid causing an unnecessary adjacency initialization). Upon expiry of the timer T1, it is restarted and the IIH is retransmitted as above. When a restarting router receives an IIH a local adjacency is established as usual, and if the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID that matches that of the local system), the receipt of the acknowledgement over that interface is noted. When the RA bit is set and the state of the remote adjacency is "UP", then the timer T3 is set to the minimum of its current value and the value of the "Remaining Time" field in the received IIH. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNPs. Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see Section 3.4). In this case, we also want to be certain that the neighbor will reinitialize the adjacency in order to guarantee that the SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. This is guaranteed to happen except in the case where the Adjacency Three-Way State in the received IIH is "UP" and the Neighbor Extended Local Circuit ID matches the extended local circuit ID assigned by the restarting router. In this case, the restarting router MUST force the adjacency to reinitialize by setting the local Adjacency Three-Way State to "DOWN" and sending a normal IIH. Ginsberg & Wells Expires March 22, 2020 [Page 12] Internet-Draft restart-signalling-for-IS-IS September 2019 In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore, T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. In the case of a Point-to-Point circuit, the "LocalCircuitID" and "Extended Local Circuit ID" information contained in the IIH can be used immediately to generate an IIH containing the correct three-way handshake information. The presence of "Neighbor Extended Local Circuit ID" information that does not match the value currently in use by the local system is ignored (since the IIH may have been transmitted before the neighbor had received the new value from the restarting router), but the adjacency remains in the initializing state until the correct information is received. In the case of a LAN circuit, the source neighbor information (e.g., SNPAAddress) is recorded and used for adjacency establishment and maintenance as normal. When BOTH a complete set of CSNPs (for each active level, in the case of a Point-to-Point circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Once the timer T1 has been cancelled, subsequent IIHs are transmitted according to the normal algorithms, but including the restart TLV with both RR and RA clear. If a LAN contains a mixture of systems, only some of which support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have reinitialized their adjacencies. If an interface is active, but does not have any neighboring router reachable over that interface, the timer T1 would never be cancelled, and according to Section 3.4.1.1, the SPF would never be run. Therefore, timer T1 is cancelled after some predetermined number of expirations (which MAY be 1). 3.3.2. Adjacency Acquisition during Start The starting router wants to ensure that in the event that a neighboring router has an adjacency to the starting router in the "UP" state (from a previous incarnation of the starting router), this adjacency is reinitialized. The starting router also wants neighboring routers to suppress advertisement of an adjacency to the starting router until LSP database synchronization is achieved. This is achieved by sending IIHs with the RR bit clear and the SA bit set Ginsberg & Wells Expires March 22, 2020 [Page 13] Internet-Draft restart-signalling-for-IS-IS September 2019 in the restart TLV. The RR bit remains clear and the SA bit remains set in subsequent transmissions of IIHs until the adjacency has reached the "UP" state and the initial T1 timer interval (see below) has expired. Receipt of an IIH with the RR bit clear will result in the neighboring router utilizing normal operation of the adjacency state machine. This will ensure that any old adjacency on the neighboring router will be reinitialized. Upon receipt of an IIH with the SA bit set, the behavior described in Section 3.2.2 is followed. Upon starting, a router starts timer T2 for each LSPDB. For each interface (and in the case of a LAN circuit, for each level), when an adjacency reaches the "UP" state, the starting router starts a timer T1 and transmits an IIH containing the restart TLV with the RR bit clear and SA bit set. Upon expiry of the timer T1, it is restarted and the IIH is retransmitted with both RR and SA bits set (only the RR bit has changed state from earlier IIHs). Upon receipt of an IIH with the RR bit set (regardless of whether or not the SA bit is set), the behavior described in Section 3.2.1 is followed. When an IIH is received by the starting router and the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID that matches that of the local system), the receipt of the acknowledgement over that interface is noted. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. Since the neighbor will have reinitialized the adjacency, this guarantees that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNPs. Synchronization may therefore be deemed complete even though there are some LSPs that are held (only) by this neighbor (see Section 3.4). In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore, T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. The Ginsberg & Wells Expires March 22, 2020 [Page 14] Internet-Draft restart-signalling-for-IS-IS September 2019 usual operation of the update process will ensure that synchronization is eventually achieved. When BOTH a complete set of CSNPs (for each active level, in the case of a Point-to-Point circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Subsequent IIHs sent by the starting router have the RR and RA bits clear and the SA bit set in the restart TLV. Timer T1 is cancelled after some predetermined number of expirations (which MAY be 1). When the T2 timer(s) are cancelled or expire, transmission of "normal IIHs" will begin. 3.3.3. Multiple Levels A router that is operating as both a Level 1 and a Level 2 router on a particular interface MUST perform the above operations for each level. On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs and perform the CSNP synchronizations independently for each level. On a Point-to-Point interface, only a single IIH (indicating support for both levels) is required, but it MUST perform the CSNP synchronizations independently for each level. 3.4. Database Synchronization When a router is started or restarted, it can expect to receive a complete set of CSNPs over each interface. The arrival of the CSNP(s) is now guaranteed, since an IIH with the RR bit set will be retransmitted until the CSNP(s) are correctly received. The CSNPs describe the set of LSPs that are currently held by each neighbor. Synchronization will be complete when all these LSPs have been received. When (re)starting, a router starts an instance of timer T2 for each LSPDB as described in Section 3.3.1 or Section 3.3.2. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNPs received over each interface is recorded, together with their remaining lifetime. In the case of a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbors that are not restarting. If there are multiple interfaces on the (re)starting router, the recorded set of LSPIDs is Ginsberg & Wells Expires March 22, 2020 [Page 15] Internet-Draft restart-signalling-for-IS-IS September 2019 the union of those received over each interface. LSPs with a remaining lifetime of zero are NOT so recorded. As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if an LSP arrives before the CSNP containing the reference). When an LSPID has been held in the list for its indicated remaining lifetime, it is removed from the list. When the list of LSPIDs is empty and the timer T1 has been cancelled for all the interfaces that have an adjacency at this level, the timer T2 is cancelled. At this point, the local database is guaranteed to contain all the LSP(s) (either the same sequence number or a more recent sequence number) that were present in the neighbors' databases at the time of (re)starting. LSPs that arrived in a neighbor's database after the time of (re)starting may or may not be present, but the normal operation of the update process will guarantee that they will eventually be received. At this point, the local database is deemed to be "synchronized". Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, and those with a short remaining lifetime are deleted from the list when the lifetime expires, cancellation of the timer T2 will not be prevented by waiting for an LSP that will never arrive. 3.4.1. LSP Generation and Flooding and SPF Computation The operation of a router starting, as opposed to restarting, is somewhat different. These two cases are dealt with separately below. 3.4.1.1. Restarting In order to avoid causing unnecessary routing churn in other routers, it is highly desirable that the router's own LSPs generated by the restarting system are the same as those previously present in the network (assuming no other changes have taken place). It is important therefore not to regenerate and flood the LSPs until all the adjacencies have been re-established and any information required for propagation into the local LSPs is fully available. Ideally, the information is loaded into the LSPs in a deterministic way, such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions may not even cause SPF to be run in other systems. However, provided the same information is included in the set of LSPs (albeit in a different order, and possibly different Ginsberg & Wells Expires March 22, 2020 [Page 16] Internet-Draft restart-signalling-for-IS-IS September 2019 LSPs), the result of running the SPF will be the same and will not cause churn to the forwarding tables. In the case of a restarting router, none of the router's own LSPs are transmitted, nor are the router's own forwarding tables updated while the timer T3 is running. Redistribution of inter-level information MUST be regenerated before this router's LSP is flooded to other nodes. Therefore, the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has been run. This ensures that any inter-level information that is to be propagated can be included in the Level-n LSP(s). During this period, if one of the router's own (including pseudonodes) LSPs is received, which the local router does not currently have in its own database, it is NOT purged. Under normal operation, such an LSP would be purged, since the LSP clearly should not be present in the global LSP database. However, in the present circumstances, this would be highly undesirable, because it could cause premature removal of a router's own LSP -- and hence churn in remote routers. Even if the local system has one or more of the router's own LSPs (which it has generated, but not yet transmitted), it is still not valid to compare the received LSP against this set, since it may be that as a result of propagation between Level 1 and Level 2 (or vice versa), a further router's own LSP will need to be generated when the LSP databases have synchronized. During this period, a restarting router SHOULD send CSNPs as it normally would. Information about the router's own LSPs MAY be included, but if it is included it MUST be based on LSPs that have been received, not on versions that have been generated (but not yet transmitted). This restriction is necessary to prevent premature removal of an LSP from the global LSP database. When the timer T2 expires or is cancelled indicating that synchronization for that level is complete, the SPF for that level is run in order to derive any information that is required to be propagated to another level, but the forwarding tables are not yet updated. Once the other level's SPF has run and any inter-level propagation has been resolved, the router's own LSPs can be generated and flooded. Any own LSPs that were previously ignored, but that are not part of the current set of own LSPs (including pseudonodes), MUST then be purged. Note that it is possible that a Designated Router change may have taken place, and consequently the router SHOULD purge Ginsberg & Wells Expires March 22, 2020 [Page 17] Internet-Draft restart-signalling-for-IS-IS September 2019 those pseudonode LSPs that it previously owned, but that are now no longer part of its set of pseudonode LSPs. When all the T2 timers have expired or been cancelled, the timer T3 is cancelled and the local forwarding tables are updated. If the timer T3 expires before all the T2 timers have expired or been cancelled, this indicates that the synchronization process is taking longer than the minimum holding time of the neighbors. The router's own LSP(s) for levels that have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and therefore other routers MUST NOT compute routes through this router). Normal operation of the update process resumes, and the local forwarding tables are updated. In order to prevent the neighbor's adjacencies from expiring, IIHs with the normal interface value for the holding time are transmitted over all interfaces with neither RR nor RA set in the restart TLV. This will cause the neighbors to refresh their adjacencies. The router's own LSP(s) will continue to have the overload bit set until timer T2 has expired or been cancelled. 3.4.1.2. Starting In the case of a starting router, as soon as each adjacency is established, and before any CSNP exchanges, the router's own zeroth LSP is transmitted with the overload bit set. This prevents other routers from computing routes through the router until it has reliably acquired the complete set of LSPs. The overload bit remains set in subsequent transmissions of the zeroth LSP (such as will occur if a previous copy of the router's own zeroth LSP is still present in the network) while any timer T2 is running. When all the T2 timers have been cancelled, the router's own LSP(s) MAY be regenerated with the overload bit clear (assuming the router is not in fact overloaded, and there is no other reason, such as incomplete BGP convergence, to keep the overload bit set) and flooded as normal. Other LSPs owned by this router (including pseudonodes) are generated and flooded as normal, irrespective of the timer T2. The SPF is also run as normal and the Routing Information Base (RIB) and Forwarding Information Base (FIB) updated as routes become available. To avoid the possible formation of temporary blackholes, the starting router sets the SA bit in the restart TLV (as described in Section 3.3.2) in all IIHs that it sends. Ginsberg & Wells Expires March 22, 2020 [Page 18] Internet-Draft restart-signalling-for-IS-IS September 2019 When all T2 timers have been cancelled, the starting router MUST transmit IIHs with the SA bit clear. 4. State Tables This section presents state tables that summarize the behaviors described in this document. Other behaviors, in particular adjacency state transitions and LSP database update operation, are NOT included in the state tables except where this document modifies the behaviors described in [ISO10589] and [RFC5303]. The states named in the columns of the tables below are a mixture of states that are specific to a single adjacency (ADJ suppressed, ADJ Seen RA, ADJ Seen CSNP) and states that are indicative of the state of the protocol instance (Running, Restarting, Starting, SPF Wait). Three state tables are presented from the point of view of a running router, a restarting router, and a starting router. 4.1. Running Router Ginsberg & Wells Expires March 22, 2020 [Page 19] Internet-Draft restart-signalling-for-IS-IS September 2019 Event | Running | ADJ suppressed ============================================================== RX PR | Set Planned Restart | | state. | | Update hold time | Send PA | -------------+----------------------+------------------------- RX PR clr | Clear Planned | and RR clr | Restart State | | Restore holdtime to | | local value | -------------+----------------------+------------------------- RX RR | Maintain ADJ State | | Send RA | | Set SRM,send CSNP | | (Note 1) | | Update Hold Time, | | set Restart Mode | | (Note 2) | -------------+----------------------+------------------------- RX RR clr | Clr Restart mode | -------------+----------------------+------------------------- RX SA | Suppress IS neighbor | | TLV in LSP(s) | | Goto ADJ Suppressed | -------------+----------------------+------------------------- RX SA clr | |Unsuppress IS neighbor | | TLV in LSP(s) | |Goto Running ============================================================== Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c Note 2: If Restart Mode clear 4.2. Restarting Router Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait | | RA | CSNP | =================================================================== Restart | Send PR | | | planned | | | | ------------+--------------------+-----------+-----------+------------ Planned | Send PR clr | | | restart | | | | canceled | | | | ------------+--------------------+-----------+-----------+------------ Ginsberg & Wells Expires March 22, 2020 [Page 20] Internet-Draft restart-signalling-for-IS-IS September 2019 RX PA | Proceed with | | | | planned restart | | | ------------+--------------------+-----------+-----------+------------ Router | Send IIH/RR | | | restarts | ADJ Init | | | | Start T1,T2,T3 | | | ------------+--------------------+-----------+-----------+------------ RX RR | Send RA | | | ------------+--------------------+-----------+-----------+------------ RX RA | Adjust T3 | | Cancel T1 | | Goto ADJ Seen RA | | Adjust T3 | ----------- +--------------------+-----------+-----------+------------ RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | ------------+--------------------+-----------+-----------+------------ RX IIH w/o | Cancel T1 (Point- | | | Restart TLV| to-point only) | | | ------------+--------------------+-----------+-----------+------------ T1 expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| | Restart T1 | Restart T1| Restart T1| ------------+--------------------+-----------+-----------+------------ T1 expires | Send IIH/ | Send IIH/ | Send IIH/ | nth time | normal | normal | normal | ------------+--------------------+-----------+-----------+------------ T2 expires | Trigger SPF | | | | Goto SPF Wait | | | ------------+--------------------+-----------+-----------+------------ T3 expires | Set overload bit | | | | Flood local LSPs | | | | Update fwd plane | | | ------------+--------------------+-----------+-----------+------------ LSP DB Sync| Cancel T2, and T3 | | | | Trigger SPF | | | | Goto SPF wait | | | ------------+--------------------+-----------+-----------+------------ All SPF | | | | Clear done | | | | overload bit | | | | Update fwd | | | | plane | | | | Flood local | | | | LSPs | | | | Goto Running ====================================================================== Ginsberg & Wells Expires March 22, 2020 [Page 21] Internet-Draft restart-signalling-for-IS-IS September 2019 4.3. Starting Router Event | Starting | ADJ Seen RA| ADJ Seen CSNP ============================================================= Router | Send IIH/SA | | starts | Start T1,T2 | | -------------+-------------------+------------+--------------- RX RR | Send RA | | -------------+-------------------+------------+--------------- RX RA | Goto ADJ Seen RA | | Cancel T1 -------------+-------------------+------------+--------------- RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | -------------+-------------------+------------+--------------- RX IIH w | Cancel T1 | | no Restart | (Point-to-Point | | TLV | only) | | -------------+-------------------+------------+--------------- ADJ UP | Start T1 | | | Send local LSPs | | | with overload bit| | | set | | -------------+-------------------+------------+--------------- T1 expires | Send IIH/RR |Send IIH/RR | Send IIH/RR | and SA | and SA | and SA | Restart T1 |Restart T1 | Restart T1 -------------+-------------------+------------+--------------- T1 expires | Send IIH/SA |Send IIH/SA | Send IIH/SA nth time | | | -------------+-------------------+------------+--------------- T2 expires | Clear overload bit| | | Send IIH normal | | | Goto Running | | -------------+-------------------+------------+--------------- LSP DB Sync | Cancel T2 | | | Clear overload bit| | | Send IIH normal | | ============================================================== 5. IANA Considerations This document defines the following IS-IS TLV that is listed in the IS-IS TLV codepoint registry: Type Description IIH LSP SNP Purge ---- ------------------------------ --- --- --- ----- 211 Restart TLV y n n n Ginsberg & Wells Expires March 22, 2020 [Page 22] Internet-Draft restart-signalling-for-IS-IS September 2019 IANA is requested to update the entry in registry to point to this document. 6. Security Considerations Any new security issues raised by the procedures in this document depend upon the ability of an attacker to inject a false but apparently valid IIH, the ease/difficulty of which has not been altered. If the RR bit is set in a false IIH, neighbors who receive such an IIH will continue to maintain an existing adjacency in the "UP" state and may (re)send a complete set of CSNPs. While the latter action is wasteful, neither action causes any disruption in correct protocol operation. If the RA bit is set in a false IIH, a (re)starting router that receives such an IIH may falsely believe that there is a neighbor on the corresponding interface that supports the procedures described in this document. In the absence of receipt of a complete set of CSNPs on that interface, this could delay the completion of (re)start procedures by requiring the timer T1 to time out the locally defined maximum number of retries. This behavior is the same as would occur on a LAN where none of the (re)starting router's neighbors support the procedures in this document and is covered in Sections 3.3.1 and 3.3.2. If the SA bit is set in a false IIH, this could cause suppression of the advertisement of an IS neighbor, which could either continue for an indefinite period or occur intermittently with the result being a possible loss of reachability to some destinations in the network and/or increased frequency of LSP flooding and SPF calculation. If the PR bit is set in a false IIH, neighbors who receive such an IIH could modify the holding time of an existing adjacency inappropriately. In the event of topology changes, the neighbor might also choose to not flood the topology updates and/or bring the adjacency down in the false belief that the forwarding plane of the router identified as the source of the false IIH is not currently processing announced topology changes. This would result in unnecessary forwarding disruption. If the PA bit is set in a false IIH, a router that receives such an IIH may falsely believe that the neighbor on the corresponding interface supports the planned restart procedures defined in this document. If such a router is planning to restart it might then proceed to initiate a restart in the false expectation that the neighbor has updated its holding time as requested. This may result Ginsberg & Wells Expires March 22, 2020 [Page 23] Internet-Draft restart-signalling-for-IS-IS September 2019 in the neighbor bringing down the adjacency while the receiving router is restarting, causing unnecessary disruption to forwarding. The possibility of IS-IS PDU spoofing can be reduced by the use of authentication as described in [RFC1195] and [ISO10589], and especially the use of cryptographic authentication as described in [RFC5304] and [RFC5310]. 7. Manageability Considerations These extensions that have been designed, developed, and deployed for many years do not have any new impact on management and operation of the IS-IS protocol via this standardization process. 8. Acknowledgements For RFC 5306 the authors acknowledged contributions made by Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang. The authors of this updated version acknowledge the contribution of Mike Shand, co-auther of RFC 5306. 9. Normative References [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov 2002. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, DOI 10.17487/RFC5303, October 2008, . Ginsberg & Wells Expires March 22, 2020 [Page 24] Internet-Draft restart-signalling-for-IS-IS September 2019 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Summary of Changes from RFC 5306 This document extends RFC 5306 by introducing support for signalling the neighbors of a restarting router that a planned restart is about to occur. This allows the neighbors to be aware of the state of the restarting router so that appropriate action may be taken if other topology changes occur while the planned restart is in progress. Since the forwarding plane of the restarting router is maintained based upon the pre-restart state of the network, additional topology changes introduce the possibility that traffic may be lost if paths via the restarting router continue to be used while the restart is in progress. In support of this new functionality two new flags have been introduced: PR - Restart is planned PA - Planned restart acknowledgement No changes to the post restart exchange between the restarting router and its neighbors have been introduced. Authors' Addresses Les Ginsberg Cisco Systems, Inc. Email: ginsberg@cisco.com Ginsberg & Wells Expires March 22, 2020 [Page 25] Internet-Draft restart-signalling-for-IS-IS September 2019 Paul Wells Cisco Systems, Inc. Email: pauwells@cisco.com Ginsberg & Wells Expires March 22, 2020 [Page 26] ./draft-ietf-core-multipart-ct-04.txt0000644000764400076440000004723013527314506016743 0ustar iustyiusty CoRE T. Fossati Internet-Draft ARM Intended status: Standards Track K. Hartke Expires: February 22, 2020 Ericsson C. Bormann Universitaet Bremen TZI August 21, 2019 Multipart Content-Format for CoAP draft-ietf-core-multipart-ct-04 Abstract This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. 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 https://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 22, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Fossati, et al. Expires February 22, 2020 [Page 1] Internet-Draft Multipart Content-Format for CoAP August 2019 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. Multipart Content-Format Encoding . . . . . . . . . . . . . . 4 3. Usage Example: Observing Resources . . . . . . . . . . . . . 4 4. Implementation Hints . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1. Registration of media type application/multipart-core . . 6 5.2. Registration of a Content-Format identifier for application/multipart-core . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of zero or more different media types, each along with a CoAP Content- Format identifier, into a single representation, with minimal framing overhead. This combined representation may then be carried in a single message, such as a CoAP [RFC7252] request or response body. This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build on multiple already existing media types. As the name of the media-type suggests, it is inspired by the multipart media types that started to be defined with the original set of MIME specifications [RFC2046]. However, while those needed to focus on the syntactic aspects of integrating multiple representations into one e-mail, transfer protocols providing full data transparency such as CoAP as well as readily available encoding formats such as the Concise Binary Object Representation (CBOR) [RFC7049] shift the focus towards the intended use of the combined representations. In this respect, the basic intent of the application/multipart-core media type is like that of multipart/mixed (Section 5.1.3 of [RFC2046]). The detailed semantics of the representations are refined by the context established by the application in the accompanying request parameters, e.g., the Fossati, et al. Expires February 22, 2020 [Page 2] Internet-Draft Multipart Content-Format for CoAP August 2019 resource URI and any further options (header fields), but three usage scenarios are envisioned: The individual representations in an application/multipart-core body occur in a sequence, which may be employed by an application where such a sequence is natural, e.g. for a number of audio snippets in various formats to be played out in that sequence, or search results returned in order of relevance. In other cases, an application may be more interested in a bag of representations, which are distinguished by their Content-Format identifier, such as an audio snippet and a text representation accompanying it. In such a case, the sequence in which these occur may not be relevant to the application. This specification adds the option of substituting a null value for the representation of an optional part, which indicates that the part is not present. A third situation that is common only ever has a single representation in the sequence, where the sender already selects just one of a set of formats possible for this situation. This kind of union "type" of formats may also make the presence of the actual representation optional, the omission of which leads to a zero-length array. Where these rules are not sufficient for an application, it might still use the general format defined here, but register a new media type and an associated Content-Format identifier to associate the representation with these more specific semantics instead of using the application/multipart-core media type. Also, future specifications might want to define rough equivalents for other multipart media types with specific semantics not covered by the present specification, such as multipart/alternative (Section 5.1.4 of [RFC2046]), where several alternative representations are provided in the message, but only one of those is to be selected by the recipient for its use (this is less likely to be useful in a constrained environment that has facilities for pre- flight discovery). 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Fossati, et al. Expires February 22, 2020 [Page 3] Internet-Draft Multipart Content-Format for CoAP August 2019 2. Multipart Content-Format Encoding A representation of media-type application/multipart-core contains a collection of zero or more representations, each along with their respective content format. The collection is encoded as a CBOR [RFC7049] array with an even number of elements. Counting from zero, the odd-numbered elements are a byte string containing a representation, or the value "null" if an optional part is indicated as not given. The (even-numbered) element preceding each of these is an unsigned integer specifying the content format ID of the representation following it. For example, a collection containing two representations, one with content format ID 42 and one with content format ID 0, looks like this in CBOR diagnostic notation: [42, h'0123456789abcdef', 0, h'3031323334'] For illustration, the structure of an application/multipart-core representation can be described by the CDDL [RFC8610] specification in Figure 1: multipart-core = [* multipart-part] multipart-part = (type: uint .size 2, part: bytes / null) Figure 1: CDDL for application/multipart-core This format is intended as a strict specification: An implementation MUST stop processing the representation if there is a CBOR well- formedness error, a deviation from the structure defined above, or any residual data left after processing the CBOR data item. (This generally means the representation is not processed at all except if some streaming processing has already happened.) 3. Usage Example: Observing Resources This section illustrates one less obvious example for using application/multipart-core: combining it with observing a resource [RFC7641] to handle pending results. When a client registers to observe a resource for which no representation is available yet, the server may send one or more 2.05 (Content) notifications before sending the first actual 2.05 (Content) or 2.03 (Valid) notification. A diagram depicting possible resulting sequences of notifications, identified by their respective response code, is shown in Figure 2. Fossati, et al. Expires February 22, 2020 [Page 4] Internet-Draft Multipart Content-Format for CoAP August 2019 __________ __________ __________ | | | | | | ---->| 2.05 |---->| 2.05 / |---->| 4.xx / | | Pending | | 2.03 | | 5.xx | |__________| |__________| |__________| ^ \ \ ^ \ ^ \__/ \ \___/ / \_______________________/ Figure 2: Sequence of Notifications The specification of the Observe option requires that all notifications carry the same Content-Format. The application/ multipart-core media type can be used to provide that Content-Format: e.g., carrying an empty list of representations in the case marked as "Pending" in Figure 2, and carrying a single representation specified as the target content-format in the case in the middle of the figure. 4. Implementation Hints This section describes the serialization for readers that may be new to CBOR. It does not contain any new information. An application/multipart-core representation carrying no representations is represented by an empty CBOR array, which is serialized as a single byte with the value 0x80. An application/multipart-core representation carrying a single representation is represented by a two-element CBOR array, which is serialized as 0x82 followed by the two elements. The first element is an unsigned integer for the Content-Format value, which is represented as described in Table 1. The second element is the object as a byte string, which is represented as a length as described in Table 2 followed by the bytes of the object. +----------------+------------+ | Serialization | Value | +----------------+------------+ | 0x00..0x17 | 0..23 | | 0x18 0xnn | 24..255 | | 0x19 0xnn 0xnn | 256..65535 | +----------------+------------+ Table 1: Serialization of content-format Fossati, et al. Expires February 22, 2020 [Page 5] Internet-Draft Multipart Content-Format for CoAP August 2019 +-----------------------------+-------------------+ | Serialization | Length | +-----------------------------+-------------------+ | 0x40..0x57 | 0..23 | | 0x58 0xnn | 24..255 | | 0x59 0xnn 0xnn | 256..65535 | | 0x5a 0xnn 0xnn 0xnn 0xnn | 65536..4294967295 | | 0x5b 0xnn .. 0xnn (8 bytes) | 4294967296.. | +-----------------------------+-------------------+ Table 2: Serialization of object length For example, a single text/plain object (content-format 0) of value "Hello World" (11 characters) would be serialized as 0x82 0x00 0x4b H e l l o 0x20 W o r l d In effect, the serialization for a single object is done by prefixing the object with information that there is one object (here: 0x82), about its content-format (here: 0x00) and its length (here: 0x4b). For more than one representation included in an application/ multipart-core representation, the head of the CBOR array is adjusted (0x84 for two representations, 0x86 for three, ...) and the sequences of content-format and embedded representations follow. For instance, the example from Section 2 would be serialized as: 0x84 (*) 0x182A 0x48 0x0123456789ABCDEF (+) 0x00 0x45 0x3031323334 where (*) marks the start of the information about the first representation (content-format 42, byte string length 8) and, (+), of the second representation (content-format 0, byte string length 5). 5. IANA Considerations 5.1. Registration of media type application/multipart-core IANA is requested to register the following media type [RFC6838]: Type name: application Subtype name: multipart-core Required parameters: N/A Optional parameters: N/A Fossati, et al. Expires February 22, 2020 [Page 6] Internet-Draft Multipart Content-Format for CoAP August 2019 Encoding considerations: binary Security considerations: See the Security Considerations Section of RFCthis Interoperability considerations: N/A Published specification: RFCthis Applications that use this media type: Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP [I-D.ietf-ace-coap-est] Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for "application/multipart-core" is as specified for "application/cbor". (At publication of this document, there is no fragment identification syntax defined for "application/cbor".) 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 & email address to contact for further information: iesg&ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: CoRE WG Change controller: IESG Provisional registration? (standards tree only): no 5.2. Registration of a Content-Format identifier for application/ multipart-core IANA is requested to register the following Content-Format to the "CoAP Content-Formats" subregistry, within the "Constrained RESTful Fossati, et al. Expires February 22, 2020 [Page 7] Internet-Draft Multipart Content-Format for CoAP August 2019 Environments (CoRE) Parameters" registry, from the Expert Review space (0..255): +----------------------------+----------+------+-----------+ | Media Type | Encoding | ID | Reference | +----------------------------+----------+------+-----------+ | application/multipart-core | -- | TBD1 | RFCthis | +----------------------------+----------+------+-----------+ 6. Security Considerations The security considerations of [RFC7049] apply. In particular, resource exhaustion attacks may employ large values for the byte string size fields, or deeply nested structures of recursively embedded application/multipart-core representations. 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, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.ietf-ace-coap-est] Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- est-12 (work in progress), June 2019. Fossati, et al. Expires February 22, 2020 [Page 8] Internet-Draft Multipart Content-Format for CoAP August 2019 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . Acknowledgements Most of the text in this draft is from earlier contributions by two of the authors, Thomas Fossati and Klaus Hartke. The re-mix in this document is based on the requirements in [I-D.ietf-ace-coap-est], based on discussions with Michael Richardson, Panos Kampanis and Peter van der Stok. Authors' Addresses Thomas Fossati ARM Email: thomas.fossati@arm.com Klaus Hartke Ericsson Torshamnsgatan 23 Stockholm SE-16483 Sweden Email: klaus.hartke@ericsson.com Fossati, et al. Expires February 22, 2020 [Page 9] Internet-Draft Multipart Content-Format for CoAP August 2019 Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Fossati, et al. Expires February 22, 2020 [Page 10] ./draft-ietf-httpbis-http2-tls13-03.txt0000644000764400076440000002270113552143562017043 0ustar iustyiusty HTTP D. Benjamin Internet-Draft Google LLC Updates: 7540 (if approved) October 17, 2019 Intended status: Standards Track Expires: April 19, 2020 Using TLS 1.3 with HTTP/2 draft-ietf-httpbis-http2-tls13-03 Abstract This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction. Note to Readers _RFC EDITOR: please remove this section before publication_ Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at https://httpwg.org/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/http2-tls13 [3]. 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 https://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 19, 2020. Benjamin Expires April 19, 2020 [Page 1] Internet-Draft Using TLS 1.3 with HTTP/2 October 2019 Copyright Notice Copyright (c) 2019 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 (https://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 Language . . . . . . . . . . . . . . . . . . . . 3 3. Post-Handshake Authentication in HTTP/2 . . . . . . . . . . . 3 4. Other Post-Handshake TLS Messages in HTTP/2 . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction TLS 1.2 [RFC5246] and earlier support renegotiation, a mechanism for changing parameters and keys partway through a connection. This was sometimes used to implement reactive client authentication in HTTP/1.1 [RFC7230], where the server decides whether to request a client certificate based on the HTTP request. HTTP/2 [RFC7540] multiplexes multiple HTTP requests over a single connection, which is incompatible with the mechanism above. Clients cannot correlate the certificate request with the HTTP request which triggered it. Thus, Section 9.2.1 of [RFC7540] forbids renegotiation. TLS 1.3 [RFC8446] updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms. The former shares the same problems with multiplexed protocols, but the prohibition in [RFC7540] only applies to TLS 1.2 renegotiation. Benjamin Expires April 19, 2020 [Page 2] Internet-Draft Using TLS 1.3 with HTTP/2 October 2019 This document updates HTTP/2 to similarly forbid TLS 1.3 post- handshake authentication. 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Post-Handshake Authentication in HTTP/2 HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages. HTTP/2 clients MUST treat such messages as connection errors (see Section 5.4.1 of [RFC7540]) of type PROTOCOL_ERROR. [RFC7540] permitted renegotiation before the HTTP/2 connection preface to provide confidentiality of the client certificate. TLS 1.3 encrypts the client certificate in the initial handshake, so this is no longer necessary. HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages before the connection preface. The above applies even if the client offered the "post_handshake_auth" TLS extension. This extension is advertised independently of the selected ALPN protocol [RFC7301], so it is not sufficient to resolve the conflict with HTTP/2. HTTP/2 clients that also offer other ALPN protocols, notably HTTP/1.1, in a TLS ClientHello MAY include the "post_handshake_auth" extension to support those other protocols. This does not indicate support in HTTP/2. 4. Other Post-Handshake TLS Messages in HTTP/2 [RFC8446] defines two other messages that are exchanged after the handshake is complete, KeyUpdate and NewSessionTicket. KeyUpdate messages only affect TLS itself and do not require any interaction with the application protocol. HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. NewSessionTicket messages are also permitted. Though these interact with HTTP when early data is enabled, these interactions are defined in [RFC8470] and allowed for in the design of HTTP/2. Benjamin Expires April 19, 2020 [Page 3] Internet-Draft Using TLS 1.3 with HTTP/2 October 2019 Unless the use of a new type of TLS message depends on an interaction with the application-layer protocol, that TLS message can be sent after the handshake completes. 5. Security Considerations This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when supporting post-handshake authentication with HTTP/1.1. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2. 6. IANA Considerations This document has no IANA actions. 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, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [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, . [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, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Benjamin Expires April 19, 2020 [Page 4] Internet-Draft Using TLS 1.3 with HTTP/2 October 2019 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 7.2. Informative References [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, . 7.3. URIs [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/http2-tls13 Author's Address David Benjamin Google LLC Email: davidben@google.com Benjamin Expires April 19, 2020 [Page 5] ./draft-ietf-curdle-gss-keyex-sha2-10.txt0000644000764400076440000007126213515655072017420 0ustar iustyiusty Internet Engineering Task Force S. Sorce Internet-Draft H. Kario Updates: 4462 (if approved) Red Hat, Inc. Intended status: Standards Track Jul 22, 2019 Expires: January 23, 2020 GSS-API Key Exchange with SHA2 draft-ietf-curdle-gss-keyex-sha2-10 Abstract This document specifies additions and amendments to RFC4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak DH groups. The purpose of this specification is to modernize the cryptographic primitives used by GSS Key Exchanges. 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 https://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 23, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Sorce & Kario Expires January 23, 2020 [Page 1] Internet-Draft GSS Keyex SHA2 Jul 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 2 4. New Diffie-Hellman Key Exchange methods . . . . . . . . . . . 3 5. New Elliptic Curve Diffie-Hellman Key Exchange methods . . . 4 5.1. Generic GSS-API Key Exchange with ECDH . . . . . . . . . 4 5.2. ECDH Key Exchange Methods . . . . . . . . . . . . . . . . 8 6. Deprecated Algorithms . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8.1. New Finite Field DH mechanisms . . . . . . . . . . . . . 10 8.2. New Elliptic Curve DH mechanisms . . . . . . . . . . . . 10 8.3. GSSAPI Delegation . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction SSH GSS-API Methods [RFC4462] allows the use of GSSAPI [RFC2743] for authentication and key exchange in SSH. It defines three exchange methods all based on DH groups and SHA-1. This document updates RFC4462 with new methods intended to support environments that desire to use the SHA-2 cryptographic hash functions. 2. Rationale Due to security concerns with SHA-1 [RFC6194] and with MODP groups with less than 2048 bits [NIST-SP-800-131Ar1] we propose the use of hashes based on SHA-2 [RFC6234] with DH group14, group15, group16, group17 and group18 [RFC3526]. Additionally we add support for key exchange based on Elliptic Curve Diffie Hellman with the NIST P-256, P-384 and P-521 [SEC2v2] as well as the X25519 and X448 [RFC7748] curves. Following the practice of [RFC8268] only SHA-256 and SHA-512 hashes are used for DH groups. For NIST curves the same curve-to- hashing algorithm pairing used in [RFC5656] is adopted for consistency. 3. Document Conventions 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 RFC2119 [RFC2119] RFC8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. Sorce & Kario Expires January 23, 2020 [Page 2] Internet-Draft GSS Keyex SHA2 Jul 2019 4. New Diffie-Hellman Key Exchange methods This document adopts the same naming convention defined in [RFC4462] to define families of methods that cover any GSS-API mechanism used with a specific Diffie-Hellman group and SHA-2 Hash combination. +--------------------------+--------------------------------+ | Key Exchange Method Name | Implementation Recommendations | +--------------------------+--------------------------------+ | gss-group14-sha256-* | SHOULD/RECOMMENDED | | gss-group15-sha512-* | MAY/OPTIONAL | | gss-group16-sha512-* | SHOULD/RECOMMENDED | | gss-group17-sha512-* | MAY/OPTIONAL | | gss-group18-sha512-* | MAY/OPTIONAL | +--------------------------+--------------------------------+ Table 1: New key exchange algorithms Each key exchange method prefix is registered by this document. The IESG is the change controller of all these key exchange methods; this does NOT imply that the IESG is considered to be in control of the corresponding GSS-API mechanism. Each method in any family of methods (Table 2) specifies GSS-API- authenticated Diffie-Hellman key exchanges as described in Section 2.1 of [RFC4462]. The method name for each method (Table 1) is the concatenation of the family name prefix with the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding [ISO-IEC-8825-1] of the corresponding GSS-API mechanism's OID. Base64 encoding is described in Section 4 of [RFC4648]. +---------------------+-------------+-------------+-----------------+ | Family Name prefix | Hash | Group | Reference | | | Function | | | +---------------------+-------------+-------------+-----------------+ | gss-group14-sha256- | SHA-256 | 2048-bit | Section 3 of | | | | MODP | [RFC3526] | | gss-group15-sha512- | SHA-512 | 3072-bit | Section 4 of | | | | MODP | [RFC3526] | | gss-group16-sha512- | SHA-512 | 4096-bit | Section 5 of | | | | MODP | [RFC3526] | | gss-group17-sha512- | SHA-512 | 6144-bit | Section 6 of | | | | MODP | [RFC3526] | | gss-group18-sha512- | SHA-512 | 8192-bit | Section 7 of | | | | MODP | [RFC3526] | +---------------------+-------------+-------------+-----------------+ Table 2: Family method references Sorce & Kario Expires January 23, 2020 [Page 3] Internet-Draft GSS Keyex SHA2 Jul 2019 5. New Elliptic Curve Diffie-Hellman Key Exchange methods In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve Cryptography are introduced. We reuse much of section 4 of [RFC5656] to define GSS-API-authenticated ECDH Key Exchanges. Additionally, we also utilize the curves defined in [I-D.ietf-curdle-ssh-curves] to complement the three classic NIST- defined curves required by [RFC5656]. 5.1. Generic GSS-API Key Exchange with ECDH This section reuses much of the scheme defined in Section 2.1 of [RFC4462] and combines it with the scheme defined in Section 4 of [RFC5656]; in particular, all checks and verification steps prescribed in Section 4 of [RFC5656] apply here as well. Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 perform the Diffie-Helman protocol using the functions X25519 and X448, respectively. Implementations MUST compute these functions using the algorithms described in [RFC7748]. When they do so, implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. Alternative implementations of these functions SHOULD abort when either input forces the shared secret to one of a small set of values, as discussed in Section 7 of [RFC7748]. This section defers to [RFC7546] as the source of information on GSS- API context establishment operations, Section 3 being the most relevant. All Security Considerations described in [RFC7546] apply here too. The parties each generate an ephemeral key pair, according to Section 3.2.1 of [SEC1v2]. Keys are verified upon receipt by the parties according to Section 3.2.3.1 of [SEC1v2]. For NIST Curves the keys use the uncompressed point representation and MUST be converted using the algorithm in Section 2.3.4 of [SEC1v2]. If the conversion fails or the point is transmitted using the compressed representation, the key exchange MUST fail. A GSS Context is established according to Section 4 of [RFC5656]; The client initiates the establishment using GSS_Init_sec_context() and the server responds to it using GSS_Accept_sec_context(). For the negotiation, the client MUST set mutual_req_flag and integ_req_flag to "true". In addition, deleg_req_flag MAY be set to "true" to request access delegation, if requested by the user. Since the key exchange process authenticates only the host, the setting of Sorce & Kario Expires January 23, 2020 [Page 4] Internet-Draft GSS Keyex SHA2 Jul 2019 anon_req_flag is immaterial to this process. If the client does not support the "gssapi-keyex" user authentication method described in Section 4 of [RFC4462], or does not intend to use that method in conjunction with the GSS-API context established during key exchange, then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY be set to true if the client wishes to hide its identity. This key exchange process will exchange only a single message token once the context has been established, therefore the replay_det_req_flag and sequence_req_flag SHOULD be set to "false". The client MUST include its public key with the first message it sends to the server during this process; if the server receives more than one key or none at all, the key exchange MUST fail. During GSS Context establishment multiple tokens may be exchanged by the client and the server. When the GSS Context is established (major_status is GSS_S_COMPLETE) the parties check that mutual_state and integ_avail are both "true". If not the key exchange MUST fail. Once a party receives the peer's public key it proceeds to compute a shared secret K. For NIST Curves the computation is done according to Section 3.3.1 of [SEC1v2] and the resulting value z is converted to the octet string K using the conversion defined in Section 2.3.5 of [SEC1v2]. For curve25519 and curve448 the algorithms in Section 6 of [RFC7748] are used instead. To verify the integrity of the handshake, peers use the Hash Function defined by the selected Key Exchange method to calculate H: H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). The GSS_GetMIC() call is used by the server with H as the payload and generates a MIC. The GSS_VerifyMIC() call is used by the client to verify the MIC. If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or any other GSS-API call returns a major_status other than GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations expressed in Section 2.1 of [RFC4462] are followed with regards to error reporting. The following is an overview of the key exchange process: Sorce & Kario Expires January 23, 2020 [Page 5] Internet-Draft GSS Keyex SHA2 Jul 2019 Client Server ------ ------ Generate ephemeral key pair. Calls GSS_Init_sec_context(). SSH_MSG_KEXGSS_INIT ---------------> Verify received key is valid. (Optional) <------------- SSH_MSG_KEXGSS_HOSTKEY (Loop) | Calls GSS_Accept_sec_context(). | <------------ SSH_MSG_KEXGSS_CONTINUE | Calls GSS_Init_sec_context(). | SSH_MSG_KEXGSS_CONTINUE ------------> Calls GSS_Accept_sec_context(). Generate ephemeral key pair. Compute shared secret. Computes hash H. Calls GSS_GetMIC( H ) = MIC. <------------ SSH_MSG_KEXGSS_COMPLETE Verify received key is valid. Compute shared secret. Compute hash = H Calls GSS_VerifyMIC( MIC, H ) This is implemented with the following messages: The client sends: byte SSH_MSG_KEXGSS_INIT string output_token (from GSS_Init_sec_context()) string Q_C, client's ephemeral public key octet string The server may respond with: byte SSH_MSG_KEXGSS_HOSTKEY string server public host key and certificates (K_S) The server sends: byte SSH_MSG_KEXGSS_CONTINUE string output_token (from GSS_Accept_sec_context()) Each time the client receives the message described above, it makes another call to GSS_Init_sec_context(). Sorce & Kario Expires January 23, 2020 [Page 6] Internet-Draft GSS Keyex SHA2 Jul 2019 The client sends: byte SSH_MSG_KEXGSS_CONTINUE string output_token (from GSS_Init_sec_context()) As the final message the server sends either: byte SSH_MSG_KEXGSS_COMPLETE string Q_S, server's ephemeral public key octet string string mic_token (MIC of H) boolean TRUE string output_token (from GSS_Accept_sec_context()) Or the following if no output_token is available: byte SSH_MSG_KEXGSS_COMPLETE string Q_S, server's ephemeral public key octet string string mic_token (MIC of H) boolean FALSE The hash H is computed as the HASH hash of the concatenation of the following: string V_C, the client's version string (CR, NL excluded) string V_S, server's version string (CR, NL excluded) string I_C, payload of the client's SSH_MSG_KEXINIT string I_S, payload of the server's SSH_MSG_KEXINIT string K_S, server's public host key string Q_C, client's ephemeral public key octet string string Q_S, server's ephemeral public key octet string mpint K, shared secret This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the server or received by the client, then the empty string is used in place of K_S when computing the exchange hash. Since this key exchange method does not require the host key to be used for any encryption operations, the SSH_MSG_KEXGSS_HOSTKEY message is OPTIONAL. If the "null" host key algorithm described in Section 5 of [RFC4462] is used, this message MUST NOT be sent. If the client receives a SSH_MSG_KEXGSS_CONTINUE message after a call to GSS_Init_sec_context() has returned a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail. Sorce & Kario Expires January 23, 2020 [Page 7] Internet-Draft GSS Keyex SHA2 Jul 2019 If the client receives a SSH_MSG_KEXGSS_COMPLETE message and a call to GSS_Init_sec_context() does not result in a major_status code of GSS_S_COMPLETE, a protocol error has occurred and the key exchange MUST fail. 5.2. ECDH Key Exchange Methods +--------------------------+--------------------------------+ | Key Exchange Method Name | Implementation Recommendations | +--------------------------+--------------------------------+ | gss-nistp256-sha256-* | SHOULD/RECOMMENDED | | gss-nistp384-sha384-* | MAY/OPTIONAL | | gss-nistp521-sha512-* | MAY/OPTIONAL | | gss-curve25519-sha256-* | SHOULD/RECOMMENDED | | gss-curve448-sha512-* | MAY/OPTIONAL | +--------------------------+--------------------------------+ Table 3: New key exchange methods Each key exchange method prefix is registered by this document. The IESG is the change controller of all these key exchange methods; this does NOT imply that the IESG is considered to be in control of the corresponding GSS-API mechanism. Each method in any family of methods (Table 4) specifies GSS-API- authenticated Elliptic Curve Diffie-Hellman key exchanges as described in Section 5.1. The method name for each method (Table 3) is the concatenation of the family method name with the Base64 encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding [ISO-IEC-8825-1] of the corresponding GSS-API mechanism's OID. Base64 encoding is described in Section 4 of [RFC4648]. Sorce & Kario Expires January 23, 2020 [Page 8] Internet-Draft GSS Keyex SHA2 Jul 2019 +------------------------+----------+---------------+---------------+ | Family Name prefix | Hash | Parameters / | Definition | | | Function | Function Name | | +------------------------+----------+---------------+---------------+ | gss-nistp256-sha256- | SHA-256 | secp256r1 | Section 2.4.2 | | | | | of [SEC2v2] | | gss-nistp384-sha384- | SHA-384 | secp384r1 | Section 2.5.1 | | | | | of [SEC2v2] | | gss-nistp521-sha512- | SHA-512 | secp521r1 | Section 2.6.1 | | | | | of [SEC2v2] | | gss-curve25519-sha256- | SHA-256 | X22519 | Section 5 of | | | | | [RFC7748] | | gss-curve448-sha512- | SHA-512 | X448 | Section 5 of | | | | | [RFC7748] | +------------------------+----------+---------------+---------------+ Table 4: Family method refences 6. Deprecated Algorithms Because they have small key lengths and are no longer strong in the face of brute-force attacks, the algorithms in the following table are considered deprecated and SHOULD NOT be used. Deprecated Algorithms +--------------------------+--------------------------------+ | Key Exchange Method Name | Implementation Recommendations | +--------------------------+--------------------------------+ | gss-group1-sha1-* | SHOULD NOT | | gss-group14-sha1-* | SHOULD NOT | | gss-gex-sha1-* | SHOULD NOT | +--------------------------+--------------------------------+ 7. IANA Considerations This document augments the SSH Key Exchange Method Names in [RFC4462]. Sorce & Kario Expires January 23, 2020 [Page 9] Internet-Draft GSS Keyex SHA2 Jul 2019 IANA is requested to update the SSH Protocol Parameters [IANA-KEX-NAMES] registry with the following entries: +--------------------------+------------+ | Key Exchange Method Name | Reference | +--------------------------+------------+ | gss-group1-sha1-* | This draft | | gss-group14-sha1-* | This draft | | gss-gex-sha1-* | This draft | | gss-group14-sha256-* | This draft | | gss-group15-sha512-* | This draft | | gss-group16-sha512-* | This draft | | gss-group17-sha512-* | This draft | | gss-group18-sha512-* | This draft | | gss-nistp256-sha256-* | This draft | | gss-nistp384-sha384-* | This draft | | gss-nistp521-sha512-* | This draft | | gss-curve25519-sha256-* | This draft | | gss-curve448-sha512-* | This draft | +--------------------------+------------+ 8. Security Considerations 8.1. New Finite Field DH mechanisms Except for the use of a different secure hash function and larger DH groups, no significant changes has been made to the protocol described by [RFC4462]; therefore all the original Security Considerations apply. 8.2. New Elliptic Curve DH mechanisms Although a new cryptographic primitive is used with these methods the actual key exchange closely follows the key exchange defined in [RFC5656]; therefore all the original Security Considerations as well as those expressed in [RFC5656] apply. 8.3. GSSAPI Delegation Some GSSAPI mechanisms can act on a request to delegate credentials to the target host when the deleg_req_flag is set. In this case, extra care must be taken to ensure that the acceptor being authenticated matches the target the user intended. Some mechanism implementations (such as commonly used krb5 libraries) may use insecure DNS resolution to canonicalize the target name; in these cases spoofing a DNS response that points to an attacker-controlled machine may result in the user silently delegating credentials to the attacker, who can then impersonate the user at will. Sorce & Kario Expires January 23, 2020 [Page 10] Internet-Draft GSS Keyex SHA2 Jul 2019 9. References 9.1. Normative References [I-D.ietf-curdle-ssh-curves] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448", draft-ietf-curdle-ssh-curves-08 (work in progress), June 2018. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [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, . [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, . [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, . [RFC7546] Kaduk, B., "Structure of the Generic Security Service (GSS) Negotiation Loop", RFC 7546, DOI 10.17487/RFC7546, May 2015, . Sorce & Kario Expires January 23, 2020 [Page 11] Internet-Draft GSS Keyex SHA2 Jul 2019 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SEC1v2] Certicom Research, "SEC 1: Elliptic Curve Cryptography", Standards for Efficient Cryptography SEC 1, Version 2.0, 2009. [SEC2v2] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography SEC 2, Version 2.0, 2010. 9.2. Informative References [IANA-KEX-NAMES] Internet Assigned Numbers Authority, "Secure Shell (SSH) Protocol Parameters: Key Exchange Method Names", June 2005, . [ISO-IEC-8825-1] International Organization for Standardization / International Electrotechnical Commission, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1, November 2015, . [NIST-SP-800-131Ar1] National Institute of Standards and Technology, "Transitions: Recommendation for Transitioning of the Use of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A Revision 1, November 2015, . [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, . Sorce & Kario Expires January 23, 2020 [Page 12] Internet-Draft GSS Keyex SHA2 Jul 2019 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, . Authors' Addresses Simo Sorce Red Hat, Inc. 140 Broadway 24th Floor New York, NY 10025 USA Email: simo@redhat.com Hubert Kario Red Hat, Inc. Purkynova 115 Brno 612 00 Czech Republic Email: hkario@redhat.com Sorce & Kario Expires January 23, 2020 [Page 13] ./draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt0000644000764400076440000021071713505177025021257 0ustar iustyiusty Inter-Domain Routing S. Previdi Internet-Draft Huawei Technologies Intended status: Standards Track K. Talaulikar, Ed. Expires: December 29, 2019 C. Filsfils Cisco Systems, Inc. H. Gredler RtBrick Inc. M. Chen Huawei Technologies June 27, 2019 BGP Link-State extensions for Segment Routing draft-ietf-idr-bgp-ls-segment-routing-ext-16 Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. This document defines extensions to the BGP Link-state address-family in order to carry segment routing information via BGP. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 https://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." Previdi, et al. Expires December 29, 2019 [Page 1] Internet-Draft BGP LS extensions for Segment Routing June 2019 This Internet-Draft will expire on December 29, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 5 2.1. Node Attributes TLVs . . . . . . . . . . . . . . . . . . 5 2.1.1. SID/Label TLV . . . . . . . . . . . . . . . . . . . . 5 2.1.2. SR Capabilities TLV . . . . . . . . . . . . . . . . . 6 2.1.3. SR Algorithm TLV . . . . . . . . . . . . . . . . . . 8 2.1.4. SR Local Block TLV . . . . . . . . . . . . . . . . . 8 2.1.5. SRMS Preference TLV . . . . . . . . . . . . . . . . . 10 2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 11 2.2.1. Adjacency SID TLV . . . . . . . . . . . . . . . . . . 11 2.2.2. LAN Adjacency SID TLV . . . . . . . . . . . . . . . . 12 2.2.3. L2 Bundle Member Attribute TLV . . . . . . . . . . . 14 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 16 2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 17 2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 18 2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 19 2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 19 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 21 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 22 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 3.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 25 4. Manageability Considerations . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Previdi, et al. Expires December 29, 2019 [Page 2] Internet-Draft BGP LS extensions for Segment Routing June 2019 1. Introduction Segment Routing (SR) allows for a flexible definition of end-to-end paths by combining sub-paths called "segments". A segment can represent any instruction: topological or service-based. A segment can have a local semantic to an SR node or global semantic within a domain. Within IGP topologies, an SR path is encoded as a sequence of topological sub-paths, called "IGP segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPFv2 and OSPFv3). [RFC8402] defines the Link-State IGP segments - Prefix, Node, Anycast and Adjacency segments. Prefix segments, by default, represent an ECMP-aware shortest-path to a prefix, as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most of the cases, is a one-hop path. Node and anycast segments are variations of the prefix segment with their specific characteristics. When Segment Routing is enabled in an IGP domain, segments are advertised in the form of Segment Identifiers (SIDs). The IGP link- state routing protocols have been extended to advertise SIDs and other SR-related information. IGP extensions are described for: IS- IS [I-D.ietf-isis-segment-routing-extensions], OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Using these extensions, Segment Routing can be enabled within an IGP domain. Segment Routing (SR) allows advertisement of single or multi-hop paths. The flooding scope for the IGP extensions for Segment routing is IGP area-wide. Consequently, the contents of a Link State Database (LSDB) or a Traffic Engineering Database (TED) has the scope of an IGP area and therefore, by using the IGP alone it is not enough to construct segments across multiple IGP Area or AS boundaries. In order to address the need for applications that require topological visibility across IGP areas, or even across Autonomous Systems (AS), the BGP-LS address-family/sub-address-family have been defined to allow BGP to carry Link-State information. The BGP Network Layer Reachability Information (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are defined in [RFC7752]. The identifying key of each Link-State object, namely a node, link, or prefix, is encoded in the NLRI and the properties of the object are encoded in the BGP-LS attribute. Previdi, et al. Expires December 29, 2019 [Page 3] Internet-Draft BGP LS extensions for Segment Routing June 2019 +------------+ | Consumer | +------------+ ^ | v +-------------------+ | BGP Speaker | +-----------+ | (Route-Reflector) | | Consumer | +-------------------+ +-----------+ ^ ^ ^ ^ | | | | +---------------+ | +-------------------+ | | | | | v v v v +-----------+ +-----------+ +-----------+ | BGP | | BGP | | BGP | | Speaker | | Speaker | . . . | Speaker | +-----------+ +-----------+ +-----------+ ^ ^ ^ | | | IGP IGP IGP Figure 1: Link State info collection Figure 1 denotes a typical deployment scenario. In each IGP area, one or more nodes are configured with BGP-LS. These BGP speakers form an IBGP mesh by connecting to one or more route-reflectors. This way, all BGP speakers (specifically the route-reflectors) obtain Link-State information from all IGP areas (and from other ASes from EBGP peers). An external component connects to the route-reflector to obtain this information (perhaps moderated by a policy regarding what information is or isn't advertised to the external component) as described in [RFC7752]. This document describes extensions to BGP-LS to advertise the SR information. An external component (e.g., a controller) can collect SR information from across an SR domain (as described in [RFC8402]) and construct the end-to-end path (with its associated SIDs) that need to be applied to an incoming packet to achieve the desired end- to-end forwarding. SR operates within a trusted domain consisting of a single or multiple ASes managed by the same administrative entity e.g. within a single provider network. Previdi, et al. Expires December 29, 2019 [Page 4] Internet-Draft BGP LS extensions for Segment Routing June 2019 2. BGP-LS Extensions for Segment Routing This document defines SR extensions to BGP-LS and specifies the TLVs and sub-TLVs for advertising SR information within the BGP-LS Attribute. Section 2.4 and Section 2.5 lists the equivalent TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols. BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link NLRI or a Prefix NLRI. BGP-LS [RFC7752] defines the TLVs that map link-state information to BGP-LS NLRI within the BGP-LS Attribute. This document adds additional BGP-LS Attribute TLVs in order to encode SR information. It does not introduce any changes to the encoding of the BGP-LS NLRIs. 2.1. Node Attributes TLVs The following Node Attribute TLVs are defined: +------+-----------------+---------------+ | Type | Description | Section | +------+-----------------+---------------+ | 1161 | SID/Label | Section 2.1.1 | | 1034 | SR Capabilities | Section 2.1.2 | | 1035 | SR Algorithm | Section 2.1.3 | | 1036 | SR Local Block | Section 2.1.4 | | 1037 | SRMS Preference | Section 2.1.5 | +------+-----------------+---------------+ Table 1: Node Attribute TLVs These TLVs should only be added to the BGP-LS Attribute associated with the Node NLRI describing the IGP node that is originating the corresponding IGP TLV/sub-TLV described below. 2.1.1. SID/Label TLV The SID/Label TLV is used as a sub-TLV by the SR Capabilities (Section 2.1.2) and Segment Routing Local Block (SRLB) (Section 2.1.4) TLVs. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SID/Label sub-TLV in section 2.3 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SID/Label sub-TLV in section 2.1 of [I-D.ietf-ospf-segment-routing-extensions] and section 3.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Previdi, et al. Expires December 29, 2019 [Page 5] Internet-Draft BGP LS extensions for Segment Routing June 2019 The 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SID/Label TLV Format Where: Type: 1161 Length: Variable. Either 3 or 4 depending whether the value is encoded as a label or as an index/SID. SID/Label: If length is set to 3, then the 20 rightmost bits represent a label (the total TLV size is 7) and the 4 leftmost bits are set to 0. If length is set to 4, then the value represents a 32 bit SID (the total TLV size is 8). 2.1.2. SR Capabilities TLV The SR Capabilities TLV is used in order to advertise the node's SR Capabilities including its Segment Routing Global Base (SRGB) range(s). In the case of IS-IS, the capabilities also include the IPv4 and IPv6 support for the SR-MPLS forwarding plane. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SR Capabilities sub-TLV in section 3.1 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in section 3.2 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SR Capabilities TLV has the following format: Previdi, et al. Expires December 29, 2019 [Page 6] Internet-Draft BGP LS extensions for Segment Routing June 2019 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV 1 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV N // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: SR Capabilities TLV Format Where: Type: 1034 Length: Variable. Minimum length is 12. Flags: 1 octet of flags as defined in section 3.1 of [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. Reserved: 1 octet that MUST be set to 0 and ignored on receipt. One or more entries, each of which have the following format: Range Size: 3 octet with a non-zero value indicating the number of labels in the range. SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV which encodes the first label in the range. Since the SID/ Label TLV is used to indicate the first label of the SRGB range, only label encoding is valid under the SR Capabilities TLV. Previdi, et al. Expires December 29, 2019 [Page 7] Internet-Draft BGP LS extensions for Segment Routing June 2019 2.1.3. SR Algorithm TLV The SR Algorithm TLV is used in order to advertise the SR Algorithms supported by the node. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SR-Algorithm sub-TLV in section 3.2 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in section 3.1 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SR Algorithm 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm... | Algorithm N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: SR Algorithm TLV Format Where: Type: 1035 Length: Variable. Minimum length is 1 and maximum can be 256. Algorithm: One or more fields of 1 octet each identifying the algorithm. 2.1.4. SR Local Block TLV The SR Local Block (SRLB) TLV contains the range(s) of labels the node has reserved for local SIDs. Local SIDs are used, e.g., in IGP (IS-IS, OSPF) for Adjacency-SIDs, and may also be allocated by components other than IGP protocols. As an example, an application or a controller may instruct a node to allocate a specific local SID. Therefore, in order for such applications or controllers to know the range of local SIDs available, it is required that the node advertises its SRLB. This information is derived from the protocol specific advertisements. Previdi, et al. Expires December 29, 2019 [Page 8] Internet-Draft BGP LS extensions for Segment Routing June 2019 o IS-IS, as defined by the SR Local Block sub-TLV in section 3.3 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SR Local Block TLV in section 3.3. of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SRLB 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Range Size 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV 1 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Range Size N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV N // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: SRLB TLV Format Where: Type: 1036 Length: Variable. Minimum length is 12. Flags: 1 octet of flags. The flags are as defined in section 3.3 of [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. Reserved: 1 octet that MUST be set to 0 and ignored on receipt. Previdi, et al. Expires December 29, 2019 [Page 9] Internet-Draft BGP LS extensions for Segment Routing June 2019 One or more entries corresponding to sub-range(s), each of which have the following format: Range Size: 3 octet value indicating the number of labels in the range. SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV which encodes the first label in the sub-range. Since the SID/ Label TLV is used to indicate the first label of the SRLB sub- range, only label encoding is valid under the SR Local Block TLV. 2.1.5. SRMS Preference TLV The Segment Routing Mapping Server (SRMS) Preference TLV is used in order to associate a preference with SRMS advertisements from a particular source. [I-D.ietf-spring-segment-routing-ldp-interop] specifies the SRMS functionality along with SRMS preference of the node advertising the SRMS Prefix-to-SID Mapping ranges. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SRMS Preference sub-TLV in section 3.4 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in section 3.4 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SRMS Preference 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference | +-+-+-+-+-+-+-+-+ Figure 6: SRMS Preference TLV Format Where: Type: 1037 Length: 1. Previdi, et al. Expires December 29, 2019 [Page 10] Internet-Draft BGP LS extensions for Segment Routing June 2019 Preference: 1 octet carrying an unsigned 8 bit SRMS preference. 2.2. Link Attribute TLVs The following Link Attribute TLVs are are defined: +------+-----------------------+---------------+ | Type | Description | Section | +------+-----------------------+---------------+ | 1099 | Adjacency SID TLV | Section 2.2.1 | | 1100 | LAN Adjacency SID TLV | Section 2.2.2 | | 1172 | L2 Bundle Member TLV | Section 2.2.3 | +------+-----------------------+---------------+ Table 2: Link Attribute TLVs These TLVs should only be added to the BGP-LS Attribute associated with the Link NLRI describing the link of the IGP node that is originating the corresponding IGP TLV/sub-TLV described below. 2.2.1. Adjacency SID TLV The Adjacency SID TLV is used in order to advertise information related to an Adjacency SID. This information is derived from Adj- SID sub-TLV of IS-IS (section 2.2.1 of [I-D.ietf-isis-segment-routing-extensions]), OSPFv2 (section 6.1 of [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 7.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). The Adjacency SID 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) // +---------------------------------------------------------------+ Figure 7: Adjacency SID TLV Format Where: Type: 1099 Previdi, et al. Expires December 29, 2019 [Page 11] Internet-Draft BGP LS extensions for Segment Routing June 2019 Length: Variable. Either 7 or 8 depending on Label or Index encoding of the SID Flags. 1 octet value which should be set as: * IS-IS Adj-SID flags are defined in section 2.2.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 Adj-SID flags are defined in section 6.1 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 Adj-SID flags are defined in section 7.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Weight: 1 octet carrying the weight used for load-balancing purposes. The use of weight is described in section 3.4 of [RFC8402]. Reserved: 2 octets that MUST be set to 0 and ignored on receipt. SID/Index/Label: * IS-IS: Label or index value as defined in section 2.2.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2: Label or index value as defined in section 6.1 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3: Label or index value as defined in section 7.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI is used to determine the underlying protocol specification for parsing these fields. 2.2.2. LAN Adjacency SID TLV For a LAN, normally a node only announces its adjacency to the IS-IS pseudo-node (or the equivalent OSPF Designated and Backup Designated Routers). The LAN Adjacency Segment TLV allows a node to announce adjacencies to all other nodes attached to the LAN in a single instance of the BGP-LS Link NLRI. Without this TLV, the corresponding BGP-LS link NLRI would need to be originated for each additional adjacency in order to advertise the SR TLVs for these neighbor adjacencies. Previdi, et al. Expires December 29, 2019 [Page 12] Internet-Draft BGP LS extensions for Segment Routing June 2019 This information is derived from LAN-Adj-SID sub-TLV of IS-IS (section 2.2.2 of [I-D.ietf-isis-segment-routing-extensions]) and LAN Adj-SID sub-TLV of OSPFv2 (section 6.2 of [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 7.2 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). The LAN Adjacency SID 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Neighbor ID / IS-IS System-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) // +---------------------------------------------------------------+ Figure 8: LAN Adjacency SID TLV Format Where: Type: 1100 Length: Variable. For IS-IS it would be 13 or 14 depending on Label or Index encoding of the SID. For OSPF it would be 11 or 12 depending on Label or Index encoding of the SID. Flags. 1 octet value which should be set as: * IS-IS LAN Adj-SID flags are defined in section 2.2.2 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 LAN Adj-SID flags are defined in section 6.2 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 LAN Adj-SID flags are defined in section 7.2 of [I-D.ietf-ospf-segment-routing-extensions]. Previdi, et al. Expires December 29, 2019 [Page 13] Internet-Draft BGP LS extensions for Segment Routing June 2019 Weight: 1 octet carrying the weight used for load-balancing purposes. The use of weight is described in section 3.4 of [RFC8402]. Reserved: 2 octets that MUST be set to 0 and ignored on receipt. Neighbor ID: 6 octets for IS-IS for the System-ID and 4 octets for OSPF for the OSPF Router-ID of the neighbor. SID/Index/Label: * IS-IS: Label or index value as defined in section 2.2.2 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2: Label or index value as defined in section 6.2 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3: Label or index value as defined in section 7.2 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The Neighbor ID, Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI is used to determine the underlying protocol specification for parsing these fields. 2.2.3. L2 Bundle Member Attribute TLV The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member link which in turn is associated with a parent L3 link. The L3 link is described by the Link NLRI defined in [RFC7752] and the L2 Bundle Member Attribute TLV is associated with the Link NLRI. The TLV MAY include sub-TLVs which describe attributes associated with the bundle member. The identified bundle member represents a unidirectional path from the originating router to the neighbor specified in the parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be associated with a Link NLRI. This information is derived from L2 Bundle Member Attributes TLV of IS-IS (section 2 of [I-D.ietf-isis-l2bundles]). The equivalent functionality has not been specified as yet for OSPF. The L2 Bundle Member Attribute TLV has the following format: Previdi, et al. Expires December 29, 2019 [Page 14] Internet-Draft BGP LS extensions for Segment Routing June 2019 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 Bundle Member Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link attribute sub-TLVs(variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: L2 Bundle Member Attributes TLV Format Where: Type: 1172 Length: Variable. L2 Bundle Member Descriptor: 4 octets field that carries a Link Local Identifier as defined in [RFC4202]. Link attributes for L2 Bundle Member Links are advertised as sub-TLVs of the L2 Bundle Member Attribute TLV. The sub-TLVs are identical to existing BGP-LS TLVs as identified in the table below. Previdi, et al. Expires December 29, 2019 [Page 15] Internet-Draft BGP LS extensions for Segment Routing June 2019 +-------------+------------------------------------+----------------+ | TLV Code | Description | Reference | | Point | | Document | +-------------+------------------------------------+----------------+ | 1088 | Administrative group (color) | [RFC7752] | | 1089 | Maximum link bandwidth | [RFC7752] | | 1090 | Max. reservable link bandwidth | [RFC7752] | | 1091 | Unreserved bandwidth | [RFC7752] | | 1092 | TE default metric | [RFC7752] | | 1093 | Link protection type | [RFC7752] | | 1099 | Adjacency Segment Identifier (Adj- | Section 2.2.1 | | | SID) TLV | | | 1100 | LAN Adjacency Segment Identifier | Section 2.2.2 | | | (Adj-SID) TLV | | | 1114 | Unidirectional link delay | [RFC8571] | | 1115 | Min/Max Unidirectional link delay | [RFC8571] | | 1116 | Unidirectional Delay Variation | [RFC8571] | | 1117 | Unidirectional packet loss | [RFC8571] | | 1118 | Unidirectional residual bandwidth | [RFC8571] | | 1119 | Unidirectional available bandwidth | [RFC8571] | | 1120 | Unidirectional bandwidth | [RFC8571] | | | utilization | | +-------------+------------------------------------+----------------+ Table 3: BGP-LS Attribute TLVs also used as sub-TLVs of L2 Bundle Member Attribute TLV 2.3. Prefix Attribute TLVs The following Prefix Attribute TLVs are defined: +------+------------------------+---------------+ | Type | Description | Section | +------+------------------------+---------------+ | 1158 | Prefix SID | Section 2.3.1 | | 1159 | Range | Section 2.3.4 | | 1170 | Prefix Attribute Flags | Section 2.3.2 | | 1171 | Source Router-ID | Section 2.3.3 | +------+------------------------+---------------+ Table 4: Prefix Attribute TLVs These TLVs should only be added to the BGP-LS Attribute associated with the Prefix NLRI describing the prefix of the IGP node that is originating the corresponding IGP TLV/sub-TLV described below. Previdi, et al. Expires December 29, 2019 [Page 16] Internet-Draft BGP LS extensions for Segment Routing June 2019 2.3.1. Prefix SID TLV The Prefix SID TLV is used in order to advertise information related to a Prefix SID. This information is derived from Prefix-SID sub-TLV of IS-IS (section 2.1 of [I-D.ietf-isis-segment-routing-extensions]) and the Prefix SID sub-TLV of OSPFv2 (section 5 of [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 6 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). The Prefix SID 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Prefix SID TLV Format Where: Type: 1158 Length: Variable. 7 or 8 depending on Label or Index encoding of the SID Flags: 1 octet value which should be set as: * IS-IS Prefix SID flags are defined in section 2.1.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 Prefix SID flags are defined in section 5 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 Prefix SID flags are defined in section 6 of [I-D.ietf-ospf-segment-routing-extensions]. Algorithm: 1 octet value identify the algorithm. The semantics of algorithm are described in section 3.1.1 of [RFC8402]. Reserved: 2 octets that MUST be set to 0 and ignored on receipt. SID/Index/Label: Previdi, et al. Expires December 29, 2019 [Page 17] Internet-Draft BGP LS extensions for Segment Routing June 2019 * IS-IS: Label or index value as defined in section 2.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2: Label or index value as defined in section 5 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3: Label or index value as defined in section 6 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing these fields. 2.3.2. Prefix Attribute Flags TLV The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute flags information. These flags are defined for OSPFv2 in section 2.1 of [RFC7684], for OSPFv3 in section A.4.1.1 of [RFC5340] and for IS- IS in section 2.1 of [RFC7794]. The Prefix Attribute Flags 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Prefix Attribute Flags TLV Format Where: Type: 1170 Length: Variable. Flags: a variable length flag field (according to the length field). Flags are routing protocol specific and are to be set as below: * IS-IS flags correspond to the IPv4/IPv6 Extended Reachability Attribute Flags defined in section 2.1 of [RFC7794] Previdi, et al. Expires December 29, 2019 [Page 18] Internet-Draft BGP LS extensions for Segment Routing June 2019 * OSPFv2 flags correspond to the Flags field of the OSPFv2 Extended Prefix TLV defined in section 2.1 of [RFC7684] * OSPFv3 flags map to the Prefix Options field defined in section A.4.1.1 of [RFC5340] and extended in section 3.1 of [RFC8362] The Flags field of this TLV is interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing this field. 2.3.3. Source Router Identifier (Source Router-ID) TLV The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the originator of the Prefix. For the IS-IS protocol this is derived from the IPv4/IPv6 Source Router ID sub-TLV as defined in section 2.2 of [RFC7794]. For the OSPF protocol, this is derived from the Prefix Source Router-ID sub-TLV as defined in section 4 of [I-D.ietf-lsr-ospf-prefix-originator]. The Source Router-ID 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 or 16 octet Router-ID // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Source Router-ID TLV Format Where: Type: 1171 Length: Variable. 4 or 16 in case of IS-IS and 4 in case of OSPF. Router-ID: the IPv4 or IPv6 Router-ID in case of IS-IS and the OSPF Router-ID in the case of OSPF. 2.3.4. Range TLV The Range TLV is used in order to advertise a range of prefix-to-SID mappings as part of the Segment Routing Mapping Server (SRMS) functionality [I-D.ietf-spring-segment-routing-ldp-interop], as defined in the respective underlying IGP SR extensions Previdi, et al. Expires December 29, 2019 [Page 19] Internet-Draft BGP LS extensions for Segment Routing June 2019 [I-D.ietf-ospf-segment-routing-extensions] (section 4), [I-D.ietf-ospf-ospfv3-segment-routing-extensions] (section 5) and [I-D.ietf-isis-segment-routing-extensions] (section 2.4). The information advertised in the Range TLV is derived from the SID/Label Binding TLV in the case of IS-IS and the OSPFv2/OSPFv3 Extended Prefix Range TLV in the case of OSPFv2/OSPFv3. A Prefix NLRI, that been advertised with a Range TLV, is considered a normal routing prefix (i.e. prefix reachability) only when there is also an IGP metric TLV (TLV 1095) associated it. Otherwise, it is considered only as the first prefix in the range for prefix-to-SID mapping advertisement. The format of the Range 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Range TLV Format Where: Type: 1159 Length: Variable. 11 or 12 depending on Label or Index encoding of the SID Flags: 1 octet value which should be set as: * IS-IS SID/Label Binding TLV flags are defined in section 2.4.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 OSPF Extended Prefix Range TLV flags are defined in section 4 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 Extended Prefix Range TLV flags are defined in section 5 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Reserved: 1 octet that MUST be set to 0 and ignored on receipt. Previdi, et al. Expires December 29, 2019 [Page 20] Internet-Draft BGP LS extensions for Segment Routing June 2019 Range Size: 2 octets that carry the number of prefixes that are covered by the advertisement.. The Flags field of this TLV is interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing this field. The prefix-to-SID mappings are advertised using sub-TLVs as below: IS-IS: SID/Label Range TLV Prefix-SID sub-TLV OSPFv2/OSPFv3: OSPFv2/OSPFv3 Extended Prefix Range TLV Prefix SID sub-TLV BGP-LS: Range TLV Prefix-SID TLV (used as a sub-TLV in this context) The prefix-to-SID mapping information for the BGP-LS Prefix-SID TLV (used as sub-TLV in this context) is encoded as described in Section 2.3.1. 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs This section illustrate the IS-IS Segment Routing Extensions TLVs and sub-TLVs mapped to the ones defined in this document. The following table, illustrates for each BGP-LS TLV, its equivalence in IS-IS. Previdi, et al. Expires December 29, 2019 [Page 21] Internet-Draft BGP LS extensions for Segment Routing June 2019 +------------+---------------+--------------------------------------+ | Descriptio | IS-IS TLV | Reference | | n | /sub-TLV | | +------------+---------------+--------------------------------------+ | SR Capabil | SR- | [I-D.ietf-isis-segment-routing-exten | | ities | Capabilities | sions] | | | sub-TLV (2) | | | SR | SR-Algorithm | [I-D.ietf-isis-segment-routing-exten | | Algorithm | sub-TLV (19) | sions] | | SR Local | SR Local | [I-D.ietf-isis-segment-routing-exten | | Block | Block sub-TLV | sions] | | | (22) | | | SRMS | SRMS | [I-D.ietf-isis-segment-routing-exten | | Preference | Preference | sions] | | | sub-TLV (19) | | | Adjacency | Adj-SID sub- | [I-D.ietf-isis-segment-routing-exten | | SID | TLV (31) | sions] | | LAN | LAN-Adj-SID | [I-D.ietf-isis-segment-routing-exten | | Adjacency | sub-TLV (32) | sions] | | SID | | | | Prefix SID | Prefix-SID | [I-D.ietf-isis-segment-routing-exten | | | sub-TLV (3) | sions] | | Range | SID/Label | [I-D.ietf-isis-segment-routing-exten | | | Binding TLV | sions] | | | (149) | | | SID/Label | SID/Label | [I-D.ietf-isis-segment-routing-exten | | | sub-TLV (1) | sions] | | Prefix | Prefix | [RFC7794] | | Attribute | Attributes | | | Flags | Flags sub-TLV | | | | (4) | | | Source | IPv4/IPv6 | [RFC7794] | | Router-ID | Source Router | | | | ID sub-TLV | | | | (11/12) | | | L2 Bundle | L2 Bundle | [I-D.ietf-isis-l2bundles] | | Member | Member | | | Attributes | Attributes | | | | TLV (25) | | +------------+---------------+--------------------------------------+ Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs This section illustrate the OSPFv2 and OSPFv3 Segment Routing Extensions TLVs and sub-TLVs mapped to the ones defined in this document. Previdi, et al. Expires December 29, 2019 [Page 22] Internet-Draft BGP LS extensions for Segment Routing June 2019 The following table, illustrates for each BGP-LS TLV, its equivalence in OSPFv2 and OSPFv3. +------------+-------------+----------------------------------------+ | Descriptio | OSPFv2 TLV | Reference | | n | /sub-TLV | | +------------+-------------+----------------------------------------+ | SR Capabil | SID/Label | [I-D.ietf-ospf-segment-routing-extensi | | ities | Range TLV | ons] | | | (9) | | | SR | SR- | [I-D.ietf-ospf-segment-routing-extensi | | Algorithm | Algorithm | ons] | | | TLV (8) | | | SR Local | SR Local | [I-D.ietf-ospf-segment-routing-extensi | | Block | Block TLV | ons] | | | (14) | | | SRMS | SRMS | [I-D.ietf-ospf-segment-routing-extensi | | Preference | Preference | ons] | | | TLV (15) | | | Adjacency | Adj-SID | [I-D.ietf-ospf-segment-routing-extensi | | SID | sub-TLV (2) | ons] | | LAN | LAN Adj-SID | [I-D.ietf-ospf-segment-routing-extensi | | Adjacency | sub-TLV (3) | ons] | | SID | | | | Prefix SID | Prefix SID | [I-D.ietf-ospf-segment-routing-extensi | | | sub-TLV (2) | ons] | | Range | OSPF | [I-D.ietf-ospf-segment-routing-extensi | | | Extended | ons] | | | Prefix | | | | Range TLV | | | | (2) | | | SID/Label | SID/Label | [I-D.ietf-ospf-segment-routing-extensi | | | sub-TLV (1) | ons] | | Prefix | Flags of | [RFC7684] | | Attribute | OSPFv2 | | | Flags | Extended | | | | Prefix TLV | | | | (1) | | | Source | Prefix | [I-D.ietf-lsr-ospf-prefix-originator] | | Router-ID | Source | | | | Router-ID | | | | sub-TLV | | | | (TBD) | | +------------+-------------+----------------------------------------+ Table 6: OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs Previdi, et al. Expires December 29, 2019 [Page 23] Internet-Draft BGP LS extensions for Segment Routing June 2019 +-----------+------------+------------------------------------------+ | Descripti | OSPFv3 TLV | Reference | | on | /sub-TLV | | +-----------+------------+------------------------------------------+ | SR Capabi | SID/Label | [I-D.ietf-ospf-segment-routing-extension | | lities | Range TLV | s] | | | (9) | | | SR | SR- | [I-D.ietf-ospf-segment-routing-extension | | Algorithm | Algorithm | s] | | | TLV (8) | | | SR Local | SR Local | [I-D.ietf-ospf-segment-routing-extension | | Block | Block TLV | s] | | | (14) | | | SRMS Pref | SRMS | [I-D.ietf-ospf-segment-routing-extension | | erence | Preference | s] | | | TLV (15) | | | Adjacency | Adj-SID | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | SID | sub-TLV | tensions] | | | (5) | | | LAN | LAN Adj- | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | Adjacency | SID sub- | tensions] | | SID | TLV (6) | | | Prefix | Prefix SID | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | SID | sub-TLV | tensions] | | | (4) | | | Range | OSPFv3 | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | | Extended | tensions] | | | Prefix | | | | Range TLV | | | | (9) | | | SID/Label | SID/Label | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | | sub-TLV | tensions] | | | (7) | | | Prefix | Prefix | [RFC8362] | | Attribute | Option | | | Flags | Fields of | | | | Prefix TLV | | | | types | | | | 3,5,6 | | | Source | Prefix | [I-D.ietf-lsr-ospf-prefix-originator] | | Router-ID | Source | | | | Router-ID | | | | sub-TLV | | | | (TBD) | | +-----------+------------+------------------------------------------+ Table 7: OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs Previdi, et al. Expires December 29, 2019 [Page 24] Internet-Draft BGP LS extensions for Segment Routing June 2019 3. IANA Considerations Early allocation of codepoints has been done by IANA for this document from the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" under the "BGP-LS Parameters" registry based on Table 8. The column "IS-IS TLV/Sub-TLV" defined in the registry does not require any value and should be left empty. 3.1. TLV/Sub-TLV Code Points Summary This section contains the global table of all TLVs/sub-TLVs defined in this document. +----------------+-----------------------------+---------------+ | TLV Code Point | Description | Reference | +----------------+-----------------------------+---------------+ | 1034 | SR Capabilities | Section 2.1.2 | | 1035 | SR Algorithm | Section 2.1.3 | | 1036 | SR Local Block | Section 2.1.4 | | 1037 | SRMS Preference | Section 2.1.5 | | 1099 | Adjacency SID | Section 2.2.1 | | 1100 | LAN Adjacency SID | Section 2.2.2 | | 1158 | Prefix SID | Section 2.3.1 | | 1159 | Range | Section 2.3.4 | | 1161 | SID/Label | Section 2.1.1 | | 1170 | Prefix Attribute Flags | Section 2.3.2 | | 1171 | Source Router-ID | Section 2.3.3 | | 1172 | L2 Bundle Member Attributes | Section 2.2.3 | +----------------+-----------------------------+---------------+ Table 8: Summary Table of TLV/Sub-TLV Codepoints 4. Manageability Considerations This section is structured as recommended in [RFC5706]. The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via [RFC7752]. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in the Manageability Considerations section of [RFC7752]. Specifically, the malformed attribute tests for syntactic checks in the Fault Management section of [RFC7752] now encompass the new BGP- LS Attribute TLVs defined in this document. The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their BGP-LS Attribute is left to the consumer of the BGP-LS information (e.g. an application or a controller) and not the BGP protocol. Previdi, et al. Expires December 29, 2019 [Page 25] Internet-Draft BGP LS extensions for Segment Routing June 2019 A consumer of the BGP-LS information retrieves this information over a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling of semantic or content errors by the consumer would be dictated by the nature of its application usage and hence is beyond the scope of this document. This document only introduces new Attribute TLVs and any syntactic error in them would result in only that specific attribute being discarded with an error log. The SR information introduced in BGP-LS by this specification, may be used by BGP-LS consumer applications like a SR path computation engine (PCE) to learn the SR capabilities of the nodes in the topology and the mapping of SR segments to those nodes. This can enable the SR PCE to perform path computations based on SR for traffic engineering use-cases and to steer traffic on paths different from the underlying IGP based distributed best path computation. Errors in the encoding or decoding of the SR information may result in the unavailability of such information to the SR PCE or incorrect information being made available to it. This may result in the SR PCE not being able to perform the desired SR based optimization functionality or to perform it in an unexpected or inconsistent manner. The handling of such errors by applications like SR PCE may be implementation specific and out of scope of this document. The extensions, specified in this document, do not introduce any new configuration or monitoring aspects in BGP or BGP-LS other than as discussed in [RFC7752]. The manageability aspects of the underlying SR features are covered by [I-D.ietf-spring-sr-yang], [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang]. 5. Security Considerations The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via [RFC7752]. The advertisement of the SR link attribute information defined in this document presents similar risk as associated with the existing set of link attribute information as described in [RFC7752]. The Security Considerations section of [RFC7752] also applies to these extensions. The procedures and new TLVs defined in this document, by themselves, do not affect the BGP-LS security model discussed in [RFC7752]. The TLVs introduced in this document are used to propagate IGP defined information ([I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). These TLVs represent the SR information associated with the IGP node, link and prefix. The IGP instances originating these TLVs are assumed to Previdi, et al. Expires December 29, 2019 [Page 26] Internet-Draft BGP LS extensions for Segment Routing June 2019 support all the required security and authentication mechanisms (as described in [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]) in order to prevent any security issue when propagating the TLVs into BGP-LS. BGP-LS SR extensions enable traffic engineering use-cases within the Segment Routing domain. SR operates within a trusted domain [RFC8402] and its security considerations also apply to BGP-LS sessions when carrying SR information. The SR traffic engineering policies using the SIDs advertised via BGP-LS are expected to be used entirely within this trusted SR domain (e.g. between multiple AS/ domains within a single provider network). Therefore, precaution is necessary to ensure that the link-state information (including SR information) advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain. BGP peering sessions for address-families other than Link-State may be setup to routers outside the SR domain. The isolation of BGP-LS peering sessions is recommended to ensure that BGP-LS topology information (including the newly added SR information) is not advertised to an external BGP peering session outside the SR domain. 6. Contributors The following people have substantially contributed to the editing of this document: Peter Psenak Cisco Systems Email: ppsenak@cisco.com Les Ginsberg Cisco Systems Email: ginsberg@cisco.com Acee Lindem Cisco Systems Email: acee@cisco.com Saikat Ray Individual Email: raysaikat@gmail.com Jeff Tantsura Apstra Inc. Email: jefftant.ietf@gmail.com Previdi, et al. Expires December 29, 2019 [Page 27] Internet-Draft BGP LS extensions for Segment Routing June 2019 7. Acknowledgements The authors would like to thank Jeffrey Haas, Aijun Wang, Robert Raszuk and Susan Hares for their review of this document and their comments. The authors would also like to thank Alvaro Retana for his extensive review and comments which helped correct issues and improve the document. 8. References 8.1. Normative References [I-D.ietf-isis-l2bundles] Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising L2 Bundle Member Link Attributes in IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), May 2017. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-25 (work in progress), May 2019. [I-D.ietf-lsr-ospf-prefix-originator] Wang, A., Lindem, A., Dong, J., Talaulikar, K., and P. Psenak, "OSPF Extension for Prefix Originator", draft- ietf-lsr-ospf-prefix-originator-00 (work in progress), February 2019. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- extensions-23 (work in progress), January 2019. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-27 (work in progress), December 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Previdi, et al. Expires December 29, 2019 [Page 28] Internet-Draft BGP LS extensions for Segment Routing June 2019 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . Previdi, et al. Expires December 29, 2019 [Page 29] Internet-Draft BGP LS extensions for Segment Routing June 2019 8.2. Informative References [I-D.ietf-isis-sr-yang] Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J. Tantsura, "YANG Data Model for IS-IS Segment Routing", draft-ietf-isis-sr-yang-05 (work in progress), March 2019. [I-D.ietf-ospf-sr-yang] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for OSPF SR (Segment Routing) Protocol", draft-ietf-ospf-sr-yang-07 (work in progress), March 2019. [I-D.ietf-spring-segment-routing-ldp-interop] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment-routing-ldp-interop-15 (work in progress), September 2018. [I-D.ietf-spring-sr-yang] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", draft- ietf-spring-sr-yang-12 (work in progress), February 2019. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, . Authors' Addresses Stefano Previdi Huawei Technologies Rome Italy Email: stefano@previdi.net Ketan Talaulikar (editor) Cisco Systems, Inc. India Email: ketant@cisco.com Previdi, et al. Expires December 29, 2019 [Page 30] Internet-Draft BGP LS extensions for Segment Routing June 2019 Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Mach(Guoyi) Chen Huawei Technologies Huawei Building, No. 156 Beiqing Rd. Beijing 100095 China Email: mach.chen@huawei.com Previdi, et al. Expires December 29, 2019 [Page 31] ./draft-ietf-curdle-rc4-die-die-die-17.txt0000644000764400076440000002140713553542714017376 0ustar iustyiusty Internet Engineering Task Force L. Camara Internet-Draft Updates: 4253 (if approved) L. Velvindron Intended status: Best Current Practice cyberstorm.mu Expires: April 23, 2020 October 21, 2019 Deprecating RC4 in Secure Shell (SSH) draft-ietf-curdle-rc4-die-die-die-17 Abstract This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC4345 to historic status. 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 https://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 23, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Camara & Velvindron Expires April 23, 2020 [Page 1] Internet-Draft draft-ietf-curdle-rc4-die-die-die October 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Updates to RFC 4253 . . . . . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The usage of RC4 suites ( also designated as arcfour ) for SSH are specified in [RFC4253] and [RFC4345]. [RFC4253] specifies the allocation of the "arcfour" cipher for SSH. [RFC4345] specifies and allocates the "arcfour128" and "arcfour256" ciphers for SSH. RC4 encryption has known weaknesses [RFC7465] [RFC8429], and the deprecation process should be begun for their use in Secure Shell (SSH) [RFC4253]. Accordingly, [RFC4253] is updated to note the deprecation of the RC4 ciphers and [RFC4345] is moved to Historic as all ciphers it specifies MUST NOT be used. 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]RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Updates to RFC 4253 [RFC4253] is updated to prohibit arcfour's use in SSH. [RFC4253] allocates the "arcfour" cipher in Section 6.3 by defining a list of defined ciphers where the "arcfour" cipher appears as optional as mentioned below: +---------------+-----------------+---------------------------------+ | arcfour | OPTIONAL | the ARCFOUR stream cipher with | | | | a 128-bit key | +---------------+-----------------+---------------------------------+ This current document updates the status of the "arcfour" ciphers in the list of [RFC4253] Section 6.3 by moving it from OPTIONAL to MUST NOT. Camara & Velvindron Expires April 23, 2020 [Page 2] Internet-Draft draft-ietf-curdle-rc4-die-die-die October 2019 +----------+-----------+--------------------------------------------+ | arcfour | MUST NOT | the ARCFOUR stream cipher with a 128-bit | | | | key | +----------+-----------+--------------------------------------------+ [RFC4253] defines the "arcfour" ciphers with the text mentioned below: The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. The Arcfour cipher is compatible with the RC4 cipher [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and should be used with caution. This current document updates [RFC4253] Section 6.3 by replacing the text above with the following text: The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. The Arcfour cipher is compatible with the RC4 cipher [SCHNEIER]. Arcfour (and RC4) has known weaknesses [RFC7465] [RFC8429], and MUST NOT be used. 3. IANA Considerations The IANA is requested to update the Encryption Algorithm Name Registry of the Secure Shell (SSH) Protocol Parameters [IANA]. The Registration procedure is IETF Review which is achieved by this document. The registry should be updated as follows: +------------------------------+------------+------+ | Encryption Algorithm Name | Reference | Note | +------------------------------+------------+------+ | arcfour | [RFC-TBD] | | | arcfour128 | [RFC-TBD] | | | arcfour256 | [RFC-TBD] | | +------------------------------+------------+------+ Where TBD is the RFC number assigned to the document. 4. Acknowledgements The authors would like to thank Eric Rescorla, Daniel Migault and Rich Salz. 5. Security Considerations This document only prohibits the use of RC4 in SSH, and introduces no new security considerations. Camara & Velvindron Expires April 23, 2020 [Page 3] Internet-Draft draft-ietf-curdle-rc4-die-die-die October 2019 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [IANA] "Secure Shell (SSH) Protocol Parameters: Encryption Algorithm Names", . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC4345] Harris, B., "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol", RFC 4345, DOI 10.17487/RFC4345, January 2006, . [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, . [RFC8429] Kaduk, B. and M. Short, "Deprecate Triple-DES (3DES) and RC4 in Kerberos", BCP 218, RFC 8429, DOI 10.17487/RFC8429, October 2018, . [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", , 1996, . Authors' Addresses Luis Camara Email: luis.camara@live.com.pt Camara & Velvindron Expires April 23, 2020 [Page 4] Internet-Draft draft-ietf-curdle-rc4-die-die-die October 2019 Loganaden Velvindron cyberstorm.mu Mauritius Email: logan@cyberstorm.mu Camara & Velvindron Expires April 23, 2020 [Page 5] ./draft-ietf-iasa2-rfc7776bis-03.txt0000644000764400076440000002564413537151346016176 0ustar iustyiusty IASA 2.0 P. Resnick Internet-Draft Episteme Technology Consulting LLC BCP: 25 A. Farrel Updates: 7776 (if approved) Old Dog Consulting Intended status: Best Current Practice September 14, 2019 Expires: March 17, 2020 Update to the IETF Anti-Harassment Procedures for the Replacement of the IAOC with the IETF Administration LLC draft-ietf-iasa2-rfc7776bis-03 Abstract The IETF Anti-Harassment Procedures are described in RFC 7776. The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms. RFC 7776 contained updates to RFC 7437. draft-ietf-iasa2-rfc7437bis has incorporated those updates, so this document also updates RFC 7776 to remove those updates. NOTE for RFC Editor and Readers of this Document When published as an RFC o All references to and mentions of draft-ietf-iasa2-rfc7437bis in this document should be replaced by the RFC that results from draft-ietf-iasa2-rfc7437bis. o The string "XXXX" should be replaced with the RFC number assigned to the RFC that results from draft-ietf-iasa2-rfc7437bis. o This note should be removed. *** END OF NOTE *** 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 Resnick & Farrel Expires March 17, 2020 [Page 1] Internet-Draft Anti-Harassment LLC Update September 2019 working documents as Internet-Drafts. The list of current Internet- Drafts is at https://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 17, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Changes to RFC 7776 . . . . . . . . . . . . . . . . . . . . . 3 2.1. Changes to Section 3.4 . . . . . . . . . . . . . . . . . 3 2.2. Changes to Section 5 . . . . . . . . . . . . . . . . . . 3 2.3. Changes to References to RFC 7437 . . . . . . . . . . . . 4 2.3.1. Changes to Metadata . . . . . . . . . . . . . . . . . 4 2.3.2. Changes to the Abstract . . . . . . . . . . . . . . . 4 2.3.3. Changes to Section 5.1 . . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The IETF Anti-Harassment Procedures are described in RFC 7776 [RFC7776]. Those procedures include direction for the IETF Chair and Resnick & Farrel Expires March 17, 2020 [Page 2] Internet-Draft Anti-Harassment LLC Update September 2019 Ombudsteam to take advice from the IETF Administrative Oversight Committee (IAOC) with respect to the budget available for training. The IAOC has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these term and to update a reference. RFC 7776 contained updates to [RFC7437]. [I-D.ietf-iasa2-rfc7437bis] has incorporated those updates, so this document also updates RFC 7776 to remove those updates. This document makes no other changes to the procedures described in RFC 7776. 2. Changes to RFC 7776 2.1. Changes to Section 3.4 Section 3.4 of RFC 7776 [RFC7776] is about Qualifications and Training. The last paragraph of that section is replaced as follows: OLD In determining the appropriate training, the IETF Chair and Ombudsteam shall take professional advice and will consult with the IETF Administrative Oversight Committee (IAOC) with respect to the overall IETF budget. NEW In determining the appropriate training, the IETF Chair and Ombudsteam shall take professional advice and will consult with the IETF Administration LLC with respect to the overall IETF budget. END 2.2. Changes to Section 5 Section 5 of RFC 7776 [RFC7776] is about Remedies (available to the Ombudsteam). The last paragraph of that section is replaced as follows: OLD Where specific action is required to ensure that a remedy is realized or enforced, the Ombudsteam will make a request in Resnick & Farrel Expires March 17, 2020 [Page 3] Internet-Draft Anti-Harassment LLC Update September 2019 writing to the IETF Secretariat and/or IETF Administrative Director (IAD) to take action as appropriate. NEW Where specific action is required to ensure that a remedy is realized or enforced, the Ombudsteam will make a request in writing to the IETF Secretariat and/or IETF LLC Executive Director to take action as appropriate. END 2.3. Changes to References to RFC 7437 RFC 7776 updated RFC 7437 [RFC7437] by allowing the Obmudsteam to form a recall petition. This document does not change any of the associated processes, however during the process of documenting the replacement of the IAOC by the IETF Administration LLC, RFC 7437 has been obsoleted by [I-D.ietf-iasa2-rfc7437bis], and as part of that work, [I-D.ietf-iasa2-rfc7437bis] has included the update from RFC 7776. This document updates RFC 7776 to remove the update of RFC 7437. 2.3.1. Changes to Metadata The following change is made to the metadata at the head of [RFC7776]: OLD Updates: 2418, 7437 NEW Updates: 2418 END 2.3.2. Changes to the Abstract The following change is made to text in the Abstract of [RFC7776]: DELETE This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories. Resnick & Farrel Expires March 17, 2020 [Page 4] Internet-Draft Anti-Harassment LLC Update September 2019 END 2.3.3. Changes to Section 5.1 The following change is made to text in Section 5.1 of [RFC7776] OLD o Many IETF management positions are appointed by the NomCom with confirmation from the IESG, IAB, or ISOC. [RFC7437] describes the recall procedure for such appointments. This document updates [RFC7437] by allowing the Ombudsteam to form a recall petition on its own and without requiring 20 signatories from the community. Such a petition shall be treated in all ways like any other recall petition as described in [RFC7437]: that is, the fact of the petition and its signatories (the Ombudsteam) shall be announced to the IETF community, and a Recall Committee Chair shall be appointed to complete the Recall Committee process. It is expected that the Recall Committee will receive a briefing from the Ombudsteam explaining why recall is considered an appropriate remedy. NEW o The Ombudsteam may form a recall petition on its own without requiring signatures from the community as described in [I-D.ietf-iasa2-rfc7437bis]. END 3. IANA Considerations This document makes no request for IANA action. 4. Security Considerations This document has no implications for Internet security. 5. References 5.1. Normative References [I-D.ietf-iasa2-rfc7437bis] Kucherawy, M., Hinden, R., and J. Livingood, "IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", draft-ietf-iasa2-rfc7437bis-09 (work in progress), July 2019. Resnick & Farrel Expires March 17, 2020 [Page 5] Internet-Draft Anti-Harassment LLC Update September 2019 [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 2016, . 5.2. Informative References [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 7437, DOI 10.17487/RFC7437, January 2015, . Appendix A. Acknowledgements Thanks to Jason Livingwood for suggesting the need for this document. Subramanian Moonesamy, Sean Turner, Jon Peterson, Roman Danyliw, and Barry Leiba raised useful points during their reviews of this work. Authors' Addresses Pete Resnick Episteme Technology Consulting LLC 503 West Indiana Avenue Urbana, Illinois 61801-4941 United States Phone: +1 217 337 1905 Email: resnick@episteme.net Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Resnick & Farrel Expires March 17, 2020 [Page 6] ./draft-ietf-idr-bgpls-segment-routing-epe-19.txt0000644000764400076440000011237113467223140021150 0ustar iustyiusty Inter-Domain Routing S. Previdi Internet-Draft Individual Intended status: Standards Track K. Talaulikar, Ed. Expires: November 17, 2019 C. Filsfils Cisco Systems, Inc. K. Patel Arrcus, Inc. S. Ray Individual Contributor J. Dong Huawei Technologies May 16, 2019 BGP-LS extensions for Segment Routing BGP Egress Peer Engineering draft-ietf-idr-bgpls-segment-routing-epe-19 Abstract Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to BGP Link-State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 https://datatracker.ietf.org/drafts/current/. Previdi, et al. Expires November 17, 2019 [Page 1] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 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 17, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 3. BGP-LS NLRI Advertisement for BGP Protocol . . . . . . . . . 5 3.1. BGP Router-ID and Member AS Number . . . . . . . . . . . 6 3.2. Mandatory BGP Node Descriptors . . . . . . . . . . . . . 6 3.3. Optional BGP Node Descriptors . . . . . . . . . . . . . . 7 4. BGP-LS Attributes for BGP Peering Segments . . . . . . . . . 7 4.1. Advertisement of the PeerNode SID . . . . . . . . . . . . 10 4.2. Advertisement of the PeerAdj SID . . . . . . . . . . . . 11 4.3. Advertisement of the PeerSet SID . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 13 5.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 13 6. Manageability Considerations . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Previdi, et al. Expires November 17, 2019 [Page 2] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 1. Introduction Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header with segment identifiers (SID). A SID can represent any instruction, topological or service- based. SR segments allows to enforce a flow through any topological path or service function while maintaining per-flow state only at the ingress node of the SR domain. The SR architecture [RFC8402] defines three types of BGP Peering Segments that may be instantiated at a BGP node: o Peer Node Segment (PeerNode SID) : instruction to steer to a specific peer node o Peer Adjacency Segment (PeerAdj SID) : instruction to steer over a specific local interface towards a specific peer node o Peer Set Segment (PeerSet SID) : instruction to load-balance to a set of specific peer nodes SR can be directly applied to either to an MPLS dataplane (SR/MPLS) with no change on the forwarding plane or to a modified IPv6 forwarding plane (SRv6). This document describes extensions to the BGP Link-State NLRI (BGP-LS NLRI) and the BGP-LS Attribute defined for BGP-LS [RFC7752] for advertising BGP peering segments from a BGP node along with its peering topology information (i.e., its peers, interfaces, and peering ASs) to enable computation of efficient BGP Egress Peer Engineering (BGP-EPE) policies and strategies using the SR/MPLS dataplane. The corresponding extensions for SRv6 are specified in [I-D.dawra-idr-bgpls-srv6-ext]. [I-D.ietf-spring-segment-routing-central-epe] illustrates a centralized controller-based BGP Egress Peer Engineering solution involving SR path computation using the BGP Peering Segments. This use case comprises a centralized controller that learns the BGP Peering SIDs via BGP-LS and then uses this information to program a BGP-EPE policy at any node in the domain to perform traffic steering via a specific BGP egress node to a specific EBGP peer(s) optionally also over a specific interface. The BGP-EPE policy can be realized using the SR Policy framework [I-D.ietf-spring-segment-routing-policy]. This document introduces a new BGP-LS Protocol-ID for BGP and defines new BGP-LS Node and Link Descriptor TLVs to facilitate advertising Previdi, et al. Expires November 17, 2019 [Page 3] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 BGP-LS Link NLRI to represent the BGP peering topology. Further, it specifies the BGP-LS Attribute TLVs for advertisement of the BGP Peering Segments (i.e., PeerNode SID, PeerAdj SID, and PeerSet SID) to be advertised in the same BGP-LS Link NLRI. 2. BGP Peering Segments As described in [RFC8402], a BGP-EPE enabled Egress PE node instantiates SR Segments corresponding to its attached peers. These segments are called BGP Peering Segments or BGP Peering SIDs. In case of EBGP, they enable the expression of source-routed inter- domain paths. An ingress border router of an AS may compose a list of SIDs to steer a flow along a selected path within the AS, towards a selected egress border router C of the AS, and to a specific EBGP peer. At minimum, a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node SID of the chosen egress PE and then the BGP Peering SID for the chosen egress PE peer or peering interface. Each BGP session MUST be described by a PeerNode SID. The description of the BGP session MAY be augmented by additional PeerAdj SIDs. Finally, multiple PeerNode SIDs or PeerAdj SIDs MAY be part of the same group/set in order to group EPE resources under a common PeerSet SID. These BGP Peering SIDs and their encoding are described in detail in Section 4. The following BGP Peering SIDs need to be instantiated on a BGP router for each of its BGP peer sessions that are enabled for Egress Peer Engineering: o One PeerNode SID MUST be instantiated to describe the BGP peer session. o One or more PeerAdj SID MAY be instantiated corresponding to the underlying link(s) to the directly connected BGP peer session. o A PeerSet SID MAY be instantiated and additionally associated and shared between one or more PeerNode SIDs or PeerAdj SIDs. While an egress point in a topology usually refers to EBGP sessions between external peers, there's nothing in the extensions defined in this document that would prevent the use of these extensions in the context of IBGP sessions. However, unlike EBGP sessions which are generally between directly connected BGP routers which are also along the traffic forwarding path, IBGP peer sessions may be setup to BGP routers which are not in the forwarding path. As such, when the IBGP design includes sessions with route-reflectors, a BGP router SHOULD Previdi, et al. Expires November 17, 2019 [Page 4] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 NOT instantiate a BGP Peering SID for those sessions to peer nodes which are not in the forwarding path since the purpose of BGP Peering SID is to steer traffic to that specific peers. Thus, the applicability for IBGP peering may be limited to only those deployments where the IBGP peer is also along the forwarding data path. Any BGP Peering SIDs instantiated on the node are advertised via BGP- LS Link NLRI type as described in the sections below. An illustration of the BGP Peering SIDs' allocations in a reference BGP peering topology along with the information carried in the BGP-LS Link NLRI and its corresponding BGP-LS Attribute are described in [I-D.ietf-spring-segment-routing-central-epe]. 3. BGP-LS NLRI Advertisement for BGP Protocol This section describes the BGP-LS NLRI encodings that describe the BGP peering and link connectivity between BGP routers. This document specifies the advertisement of BGP peering topology information via BGP-LS Link NLRI type which requires use of a new BGP-LS Protocol-ID. +-------------+----------------------------------+ | Protocol-ID | NLRI information source protocol | +-------------+----------------------------------+ | 7 | BGP | +-------------+----------------------------------+ Table 1: BGP-LS Protocol Identifier for BGP The use of a new Protocol-ID allows separation and differentiation between the BGP-LS NLRIs carrying BGP information from the BGP-LS NLRIs carrying IGP link-state information defined in [RFC7752]. The BGP Peering information along with their Peering Segments are advertised using BGP-LS Link NLRI type with the Protocol-ID set to BGP. The BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS Attribute TLVs as defined in [RFC7752]. In order to correctly describe BGP nodes, new TLVs are defined in this section. [RFC7752] defines Link NLRI Type is as follows: Previdi, et al. Expires November 17, 2019 [Page 5] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Link Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: BGP-LS Link NLRI Node Descriptors and Link Descriptors are defined in [RFC7752]. 3.1. BGP Router-ID and Member AS Number Two new Node Descriptors TLVs are defined in this document: o BGP Router Identifier (BGP Router-ID): Type: 516 Length: 4 octets Value: 4 octet unsigned non-zero integer representing the BGP Identifier as defined in [RFC6286]. o Member-AS Number (Member-ASN) Type: 517 Length: 4 octets Value: 4 octet unsigned non-zero integer representing the Member-AS Number [RFC5065]. 3.2. Mandatory BGP Node Descriptors The following Node Descriptors TLVs MUST be included in BGP-LS NLRI as Local Node Descriptors when distributing BGP information: o BGP Router-ID (TLV 516), which contains a valid BGP Identifier of the local BGP node. Previdi, et al. Expires November 17, 2019 [Page 6] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 o Autonomous System Number (TLV 512) [RFC7752], which contains the ASN or AS Confederation Identifier (ASN) [RFC5065], if confederations are used, of the local BGP node. Note that [RFC6286] (section 2.1) requires the BGP identifier (Router-ID) to be unique within an Autonomous System and non-zero. Therefore, the tuple is globally unique. Their use in the Node Descriptor helps map Link-State NLRIs with BGP protocol-ID to a unique BGP router in the administrative domain where BGP-LS is enabled. The following Node Descriptors TLVs MUST be included in BGP-LS Link NLRI as Remote Node Descriptors when distributing BGP information: o BGP Router-ID (TLV 516), which contains the valid BGP Identifier of the peer BGP node. o Autonomous System Number (TLV 512) [RFC7752], which contains the ASN or the AS Confederation Identifier (ASN) [RFC5065], if confederations are used, of the peer BGP node. 3.3. Optional BGP Node Descriptors The following Node Descriptors TLVs MAY be included in BGP-LS NLRI as Local Node Descriptors when distributing BGP information: o Member-ASN (TLV 517), which contains the ASN of the confederation member (i.e., Member-AS Number), if BGP confederations are used, of the local BGP node. o Node Descriptors as defined in [RFC7752]. The following Node Descriptors TLVs MAY be included in BGP-LS Link NLRI as Remote Node Descriptors when distributing BGP information: o Member-ASN (TLV 517), which contains the ASN of the confederation member (i.e., Member-AS Number), if BGP confederations are used, of the peer BGP node. o Node Descriptors as defined in [RFC7752]. 4. BGP-LS Attributes for BGP Peering Segments This section defines the BGP-LS Attributes corresponding to the following BGP Peer Segment SIDs: Peer Node Segment Identifier (PeerNode SID) Previdi, et al. Expires November 17, 2019 [Page 7] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 Peer Adjacency Segment Identifier (PeerAdj SID) Peer Set Segment Identifier (PeerSet SID) The following new BGP-LS Link attributes TLVs are defined for use with BGP-LS Link NLRI for advertising BGP Peering SIDs: +----------+---------------------------+ | TLV Code | Description | | Point | | +----------+---------------------------+ | 1101 | PeerNode SID | | 1102 | PeerAdj SID | | 1103 | PeerSet SID | +----------+---------------------------+ Figure 2: BGP-LS TLV code points for BGP-EPE PeerNode SID, PeerAdj SID, and PeerSet SID have all the same format defined here 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: BGP Peering SIDs TLV Format o Type: 1101, 1102 or 1103 as listed in Figure 2. o Length: variable. Valid values are either 7 or 8 based on the whether the encoding is done as a SID Index or a label. o Flags: one octet of flags with the following definition: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L|B|P| Rsvd | +-+-+-+-+-+-+-+-+ Figure 4: Peering SID TLV Flags Format Previdi, et al. Expires November 17, 2019 [Page 8] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 * V-Flag: Value flag. If set, then the SID carries a label value. By default the flag is SET. * L-Flag: Local Flag. If set, then the value/index carried by the SID has local significance. By default the flag is SET. * B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection using fast re-route (FRR). The computation of the backup forwarding path and its association with the BGP Peering SID forwarding entry is implementation specific. [I-D.ietf-spring-segment-routing-central-epe] section 3.6 discusses some of the possible ways of identifying backup paths for BGP Peering SIDs. * P-Flag: Persistent Flag: If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap. * Rsvd bits: Reserved for future use and MUST be zero when originated and ignored when received. o Weight: 1 octet. The value represents the weight of the SID for the purpose of load balancing. An example use of the weight is described in [RFC8402]. o SID/Index/Label. According to the TLV length and to the V and L flags settings, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V and L flags MUST be SET. * A 4 octet index defining the offset in the Segment Routing Global Block (SRGB) [RFC8402] advertised by this router. In this case, the SRGB MUST be advertised using the extensions defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The values of the PeerNode SID, PeerAdj SID, and PeerSet SID Sub-TLVs SHOULD be persistent across router restart. When enabled for Egress Peer Engineering, the BGP router MUST include the PeerNode SID TLV in the BGP-LS Attribute for the BGP-LS Link NLRI corresponding to its BGP peering sessions. The PeerAdj SID and PeerSet SID TLVs MAY be included in the BGP-LS Attribute for the BGP- LS Link NLRI. Additional BGP-LS Link Attribute TLVs, as defined in [RFC7752] MAY be included with the BGP-LS Link NLRI in order to advertise the Previdi, et al. Expires November 17, 2019 [Page 9] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 characteristics of the peering link. E.g., one or more interface addresses (TLV 259 or TLV 261) of the underlying link(s) over which a multi-hop BGP peering session is setup may be included in the BGP-LS Attribute along with the PeerNode SID TLV. 4.1. Advertisement of the PeerNode SID The PeerNode SID TLV includes a SID associated with the BGP peer node that is described by a BGP-LS Link NLRI as specified in Section 3. The PeerNode SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]): o SR operation: NEXT. o Next-Hop: the connected peering node to which the segment is associated. The PeerNode SID is advertised with a BGP-LS Link NLRI, where: o Local Node Descriptors include: * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. * Local ASN (TLV 512). o Remote Node Descriptors include: * Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the BGP session) * Peer ASN (TLV 512). o Link Descriptors include the addresses used by the BGP session encoded using TLVs as defined in [RFC7752]: * IPv4 Interface Address (TLV 259) contains the BGP session IPv4 local address. * IPv4 Neighbor Address (TLV 260) contains the BGP session IPv4 peer address. * IPv6 Interface Address (TLV 261) contains the BGP session IPv6 local address. * IPv6 Neighbor Address (TLV 262) contains the BGP session IPv6 peer address. Previdi, et al. Expires November 17, 2019 [Page 10] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 o Link Attribute TLVs include the PeerNode SID TLV as defined in Figure 3. 4.2. Advertisement of the PeerAdj SID The PeerAdj SID TLV includes a SID associated with the underlying link to the BGP peer node that is described by a BGP-LS Link NLRI as specified in Section 3. The PeerAdj SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]): o SR operation: NEXT. o Next-Hop: the interface peer address. The PeerAdj SID is advertised with a BGP-LS Link NLRI, where: o Local Node Descriptors include: * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. * Local ASN (TLV 512). o Remote Node Descriptors include: * Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the BGP session). * Peer ASN (TLV 512). o Link Descriptors MUST include the following TLV, as defined in [RFC7752]: * Link Local/Remote Identifiers (TLV 258) contains the 4-octet Link Local Identifier followed by the 4-octet Link Remote Identifier. The value 0 is used by default when the link remote identifier is unknown. o Additional Link Descriptors TLVs, as defined in [RFC7752], MAY also be included to describe the addresses corresponding to the link between the BGP routers: * IPv4 Interface Address (Sub-TLV 259) contains the address of the local interface through which the BGP session is established. Previdi, et al. Expires November 17, 2019 [Page 11] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 * IPv6 Interface Address (Sub-TLV 261) contains the address of the local interface through which the BGP session is established. * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address of the peer interface used by the BGP session. * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address of the peer interface used by the BGP session. o Link Attribute TLVs include the PeerAdj SID TLV as defined in Figure 3. 4.3. Advertisement of the PeerSet SID The PeerSet SID TLV includes a SID that is shared amongst BGP peer nodes or the underlying links that are described by BGP-LS Link NLRI as specified in Section 3. The PeerSet SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]): o SR operation: NEXT. o Next-Hop: load balance across any connected interface to any peer in the associated peer set. The PeerSet SID TLV containing the same SID value (encoded as defined in Figure 3) is included in the BGP-LS Attribute for all of the BGP- LS Link NLRI corresponding to the PeerNode or PeerAdj segments associated with the peer set. 5. IANA Considerations This document defines: A new Protocol-ID: BGP. The codepoint is from the "BGP-LS Protocol-IDs" registry. Two new TLVs: BGP-Router-ID and BGP Confederation Member. The codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. Three new BGP-LS Attribute TLVs: PeerNode SID, PeerAdj SID and PeerSet SID. The codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. Previdi, et al. Expires November 17, 2019 [Page 12] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 5.1. New BGP-LS Protocol-ID This document defines a new value in the registry "BGP-LS Protocol- IDs": +------------------------------------------------------+ | Codepoint | Description | Status | +------------------------------------------------------+ | 7 | BGP | Early Allocation by IANA | +------------------------------------------------------+ Figure 5: BGP Protocol Codepoint 5.2. Node Descriptors and Link Attribute TLVs This document defines 5 new TLVs in the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": o Two new node descriptor TLVs o Three new link attribute TLVs All the new 5 codepoints are in the same registry: "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". The following new Node Descriptors TLVs are defined: +-------------------------------------------------------------------+ | Codepoint | Description | Status | +-------------------------------------------------------------------+ | 516 | BGP Router-ID | Early Allocation by IANA | | 517 | BGP Confederation Member | Early Allocation by IANA | +------------+------------------------------------------------------+ Figure 6: BGP-LS Descriptor TLVs Codepoints The following new Link Attribute TLVs are defined: +-------------------------------------------------------------------+ | Codepoint | Description | Status | +-------------------------------------------------------------------+ | 1101 | PeerNode SID | Early Allocation by IANA | | 1102 | PeerAdj SID | Early Allocation by IANA | | 1103 | PeerSet SID | Early Allocation by IANA | +------------+------------------------------------------------------+ Figure 7: BGP-LS Attribute TLVs Codepoints Previdi, et al. Expires November 17, 2019 [Page 13] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 6. Manageability Considerations The new protocol extensions introduced in this document augment the existing IGP topology information BGP-LS distribution [RFC7752] by adding support for distribution of BGP peering topology information. As such, the Manageability Considerations section of [RFC7752] applies to these new extensions as well. Specifically, the malformed Link-State NLRI and BGP-LS Attribute tests for syntactic checks in the Fault Management section of [RFC7752] now apply to the TLVs defined in this document. The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their associated BGP-LS Attributes is left to the consumer of the BGP-LS information (e.g., an application or a controller) and not the BGP protocol. A consumer of the BGP-LS information retrieves this information from a BGP Speaker, over a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling of semantic or content errors by the consumer would be dictated by the nature of its application usage and hence is beyond the scope of this document. It may be expected that an error detected in the NLRI descriptor TLVs would result in that specific NLRI update being unusable and hence its update to be discarded along with an error log. While an error in Attribute TLVs would result in only that specific attribute being discarded with an error log. The operator MUST be provided with the options of configuring, enabling, and disabling the advertisement of each of the PeerNode SID, PeerAdj SID, and PeerSet SID as well as control of which information is advertised to which internal or external peer. This is not different from what is required by a BGP speaker in terms of information origination and advertisement. BGP Peering Segments are associated with the normal BGP routing peering sessions. However, the BGP peering information along with these Peering Segments themselves are advertised via a distinct BGP- LS peering session. It is expected that this isolation as described in [RFC7752] is followed when advertising BGP peering topology information via BGP-LS. BGP-EPE functionality enables the capability for instantiation of an SR path for traffic engineering a flow via an egress BGP router to a specific peer, bypassing the normal BGP best path routing for that flow and any routing policies implemented in BGP on that egress BGP router. As with any traffic engineering solution, the controller or application implementing the policy needs to ensure that there is no looping or mis-routing of traffic. Traffic counters corresponding to Previdi, et al. Expires November 17, 2019 [Page 14] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 the MPLS label of the BGP Peering SID on the router would indicate the traffic being forwarded based on the specific EPE path. Monitoring these counters and the flows hitting the corresponding MPLS forwarding entry would help identify issues, if any, with traffic engineering over the EPE paths. Errors in the encoding or decoding of the SR information in the TLVs defined in this document may result in the unavailability of such information to a Centralized EPE Controller or incorrect information being made available to it. This may result in the controller not being able to perform the desired SR based optimization functionality or to perform it in an unexpected or inconsistent manner. The handling of such errors by applications like such a controller may be implementation specific and out of scope of this document. 7. Security Considerations [RFC7752] defines BGP-LS NLRI to which the extensions defined in this document apply. The Security Considerations section of [RFC7752] also applies to these extensions. The procedures and new TLVs defined in this document, by themselves, do not affect the BGP-LS security model discussed in [RFC7752]. BGP-EPE enables engineering of traffic when leaving the administrative domain via an egress BGP router. Therefore precaution is necessary to ensure that the BGP peering information collected via BGP-LS is limited to specific consumers in a secure manner. Segment Routing operates within a trusted domain [RFC8402] and its security considerations also apply to BGP Peering Segments. The BGP-EPE policies are expected to be used entirely within this trusted SR domain (e.g., between multiple AS/domains within a single provider network). The isolation of BGP-LS peering sessions is also required to ensure that BGP-LS topology information (including the newly added BGP peering topology) is not advertised to an external BGP peering session outside an administrative domain. 8. Contributors Mach (Guoyi) Chen Huawei Technologies China Email: mach.chen@huawei.com Previdi, et al. Expires November 17, 2019 [Page 15] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 Acee Lindem Cisco Systems Inc. US Email: acee@cisco.com 9. Acknowledgements The authors would like to thank Jakob Heitz, Howard Yang, Hannes Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their feedback and comments. Susan Hares helped in improving the clarity of the document with her substantial contributions during her shepherd's review. The authors would also like to thank Alvaro Retana for his extensive review and comments which helped correct issues and improve the document. 10. References 10.1. Normative References [I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-14 (work in progress), May 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, . [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . Previdi, et al. Expires November 17, 2019 [Page 16] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 10.2. Informative References [I-D.dawra-idr-bgpls-srv6-ext] Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and H. Elmalky, "BGP Link State Extensions for SRv6", draft- dawra-idr-bgpls-srv6-ext-06 (work in progress), March 2019. [I-D.ietf-spring-segment-routing-central-epe] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", draft-ietf-spring-segment-routing-central- epe-10 (work in progress), December 2017. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing- policy-03 (work in progress), May 2019. Authors' Addresses Stefano Previdi Individual Email: stefano@previdi.net Ketan Talaulikar (editor) Cisco Systems, Inc. India Email: ketant@cisco.com Previdi, et al. Expires November 17, 2019 [Page 17] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Keyur Patel Arrcus, Inc. Email: Keyur@arrcus.com Saikat Ray Individual Contributor Email: raysaikat@gmail.com Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Previdi, et al. Expires November 17, 2019 [Page 18] ./draft-ietf-iasa2-trust-rationale-03.txt0000644000764400076440000003254113357660152017522 0ustar iustyiusty Internet Engineering Task Force J. Arkko Internet-Draft Ericsson Intended status: Informational October 11, 2018 Expires: April 14, 2019 Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust draft-ietf-iasa2-trust-rationale-03 Abstract This document is published to capture the rationale for the changes introduced in RFC NNNN (RFC Editor: please replace NNNN with the RFC number of [I-D.ietf-iasa2-trust-update]), Update to the Process for Selection of Trustees for the IETF Trust. At the time RFC NNNN was published, IETF administrative structure changes ("IASA 2.0") had an impact on the IETF Trust because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update. 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 14, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Arkko Expires April 14, 2019 [Page 1] Internet-Draft IASA 2.0 and IETF Trust October 2018 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. General Approach . . . . . . . . . . . . . . . . . . . . . . 3 4. Changing the Way Trustees Are Selected . . . . . . . . . . . 4 5. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Changes from Previous Versions . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document is published to capture the rationale for the changes introduced in [I-D.ietf-iasa2-trust-update]. At the time [I-D.ietf-iasa2-trust-update] was published, IETF administrative structure changes ("IASA 2.0") had an impact on the IETF Trust [RFC4071] [RFC4371] [I-D.ietf-iasa2-struct]. This is because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. A minimal change regarding the selection of the trustees is implemented by [I-D.ietf-iasa2-trust-update]. This companion memo provides some background on the details of the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update. Arkko Expires April 14, 2019 [Page 2] Internet-Draft IASA 2.0 and IETF Trust October 2018 2. Background The purpose of the IETF Trust is to acquire, hold, maintain, and license certain existing and future intellectual property and other property used in connection with the administration of the IETF [RFC4371]. The intellectual property is, for instance, rights that the IETF contributors grant for text in RFCs and Internet-Drafts. The IETF Trust also manages trademarks such as "IETF" and domain names such as "ietf.org". The IETF Trust is also serving the broader Internet community by holding domains and trademarks associated with Internet Assigned Numbers Authority (IANA) [RFC7979]. The IETF Trust is a legal entity, registered in the Commonwealth of Virginia [Trust-FD]. Previously, the members of the IAOC also served as ex officio Trustees of the IETF Trust. The founding documents specify persons eligible to become trustees as having to be then-current members of the IAOC [Trust-FD]. The documents also specify that if for any reason there are fewer than three individuals serving as Trustees, then the Internet Engineering Steering Group (IESG), or the IESG's successor as the leadership of the IETF, shall appoint one or more individuals to serve in a temporary capacity as Trustee(s) until eligible persons can be found. In the previous system there were eight IAOC members. Two were named by the IETF Nominating Committee (NomCom), one by the IESG, one by the Internet Architecture Board (IAB), and one by the Internet Society (ISOC) Board of Trustees. In addition, there were three ex officio members via their roles as IETF Chair, ISOC CEO, and IAB Chair. In addition, the IETF Administrative Director (IAD) served also as one of the trustees. 3. General Approach There were two basic approaches to resolving the issue with the trustees, when the IAOC ceased to exist. One could have imagined merging all IETF Trust functions in the new IASA structure and under the new legal entity. This memo advocated a second approach where the IETF Trust is kept independent. The rationale for advocating the second approach is in part to minimize changes to the IETF Trust while the IETF's administrative structure is undergoing major change. In addition, the IETF Trust and other administrative IETF processes are quite different. While very important, the IETF Trust is a low-activity entity where changes are minimal and gradual, and there are no pressing issues. Arkko Expires April 14, 2019 [Page 3] Internet-Draft IASA 2.0 and IETF Trust October 2018 4. Changing the Way Trustees Are Selected At the time when the trustees served on both the IETF Trust and the IAOC, many of the requirements for naming a particular group of people were driven by the IAOC's requirements. For the IETF Trust in the new model, some of those arrangements were able to be rethought, both in terms of the number and source of the trustees, as well as the desired qualifications and length of terms. Several options were possible, of course. A newly designed naming process could have been devised. The argument here is for a relatively limited change, however, largely on the basis of the IETF Trust arrangements generally working well, and on the relatively modest expected time commitments combined with the need for very careful management of the assets. As a result, a smaller group of trustees appeared sufficient. In addition, the terms for the trustees selected from the IETF community could be set to longer than the two year period typical of other IETF bodies. One could have continued the practice of having the chairs and CEOs from IETF, IAB, and Internet Society be trustees as well, but this may not be necessary. In general, the tasks of the IETF Trust are well defined, and while there is a need for coordination, it does not need to be at the level of chairs or CEOs. Given all this, one approach was to have trustees appointed by the NomCom, IESG, and ISOC Board of Trustees. (One might also have considered the IETF Administration LLC legal entity instead of the Internet Society for this role. But the Internet Society is perhaps more suitable for the role, given their focus on the broad use of the IETF Trust assets and not merely administrative aspects). If the same principles would continue to be used as were used in previous appointments, then appointments performed by the NomCom would need to be confirmed by another entity, which could be, for instance, either the IESG or the IAB. The IESG had previously been the confirming body for the IAOC, so it has been retained in that role for the trustees. 5. Transition When the new entity for IETF Administration LLC was set up, the IAOC was expected to be discontinued soon thereafter. Fortunately, there was no pressing need to change all the components of the IAOC and its dependent organizations at the same time. As discussed above Arkko Expires April 14, 2019 [Page 4] Internet-Draft IASA 2.0 and IETF Trust October 2018 (Section 2), the IESG holds the ability to continue to name trustees. And once the updated procedures were in place, the IETF Trust had its management nominated in the usual manner, and the exceptional IESG process was no longer needed. 6. Security Considerations This memo has no security implications for the Internet. 7. IANA Considerations This memo requests no action from IANA. 8. Acknowledgements The author would like to thank other members of the earlier IASA 2.0 design team who were Brian Haberman, Eric Rescorla, Jason Livingood, Joe Hall, and Leslie Daigle. The authors would also like to thank Alissa Cooper, Ted Hardie, Andrew Sullivan, Brian Carpenter, Lucy Lynch, and John Levine for interesting discussions in this problem space, and Adrian Farrel, Tero Kivinen, Russ Housley, Benjamin Kaduk, Adam Roach and Meral Shirazipour for careful review. 9. References 9.1. Normative References [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, . [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, January 2006, . 9.2. Informative References [I-D.ietf-iasa2-struct] Haberman, B., Hall, J., and J. Livingood, "Record of Proposed Structure of the IETF Administrative Support Activity (IASA), Version 2.0", draft-ietf-iasa2-struct-06 (work in progress), September 2018. [I-D.ietf-iasa2-trust-update] Arkko, J. and T. Hardie, "Update to the Selection of Trustees for the IETF Trust", draft-ietf-iasa2-trust- update-00 (work in progress), September 2018. Arkko Expires April 14, 2019 [Page 5] Internet-Draft IASA 2.0 and IETF Trust October 2018 [RFC7979] Lear, E., Ed. and R. Housley, Ed., "Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries", RFC 7979, DOI 10.17487/RFC7979, August 2016, . [Trust-FD] IETF Trust, , "Founding Documents", February 2014 (https://trustee.ietf.org/founding-documents.html). Appendix A. Changes from Previous Versions RFC Editor: Please remove this section upon publication. The version draft-ietf-iasa2-trust-rationale-03.txt made some editorial corrections. The version draft-ietf-iasa2-trust-rationale-02.txt made some editorial corrections. The version draft-ietf-iasa2-trust-rationale-01.txt includes changes relating to last call comments. The changes are 1) indication of why this document is being published 2) updates to references, 3) the addition of empty security and IANA consideration sections, 4) editorial changes necessary for a document that is also read later, and not just used in discussions at this time. The version draft-ietf-iasa2-trust-rationale-00.txt includes only editorial and language updates. The version draft-arkko-iasa2-trust-rationale-00.txt was the initial version. Author's Address Jari Arkko Ericsson Kauniainen 02700 Finland Email: jari.arkko@piuha.net Arkko Expires April 14, 2019 [Page 6] ./draft-ietf-lamps-cms-mix-with-psk-07.txt0000644000764400076440000020357013530044276017625 0ustar iustyiusty INTERNET-DRAFT R. Housley Internet Engineering Task Force (IETF) Vigil Security Intended Status: Proposed Standard Expires: 23 February 2020 23 August 2019 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Abstract The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms, if the existing syntax does not accommodate them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. 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) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Housley [Page 1] INTERNET-DRAFT Using PSK in the CMS August 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A: Key Transport with PSK Example . . . . . . . . . . . . 17 A.1. Originator Processing Example . . . . . . . . . . . . . . 18 A.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 20 A.3. Recipient Processing Example . . . . . . . . . . . . . . . 22 Appendix B: Key Agreement with PSK Example . . . . . . . . . . . . 23 B.1. Originator Processing Example . . . . . . . . . . . . . . 23 B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26 B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today [S1994]. It is an open question whether or not it is feasible to build a large-scale quantum computer, and if so, when that might happen [NAS2019]. However, if such a quantum computer is invented, many of the cryptographic algorithms and the security protocols that use them would become vulnerable. Housley [Page 2] INTERNET-DRAFT Using PSK in the CMS August 2019 The Cryptographic Message Syntax (CMS) [RFC5652][RFC5083] supports key transport and key agreement algorithms that could be broken by the invention of a large-scale quantum computer [C2PQ]. These algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary that stores CMS-protected communications today, could decrypt those communications in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support them, if the existing syntax does not already accommodate the new algorithms. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of existing key transport and key agreement algorithms with a pre-shared key (PSK). Secure communication can be achieved today by mixing a strong PSK with the output of an existing key transport algorithm, like RSA [RFC8017], or an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is believed to be quantum resistant can be achieved by using a PSK with sufficient entropy along with a quantum resistant key derivation function (KDF), like HKDF [RFC5869], and a quantum resistant encryption algorithm, like 256-bit AES [AES]. In this way, today's CMS-protected communication can be resistant to an attacker with a large-scale quantum computer. In addition, there may be other reasons for including a strong PSK besides protection against the future invention of a large-scale quantum computer. For example, there is always the possibility of a cryptoanalytic breakthrough on one or more of the classic public-key algorithm, and there are longstanding concerns about undisclosed trapdoors in Diffie-Hellman parameters [FGHT2016]. Inclusion of a strong PSK as part of the overall key management offer additional protection against these concerns. Note that the CMS also supports key management techniques based on symmetric key-encryption keys and passwords, but they are not discussed in this document because they are already quantum resistant. The symmetric key-encryption key technique is quantum resistant when used with an adequate key size. The password technique is quantum resistant when used with a quantum-resistant key derivation function and a sufficiently large password. Housley [Page 3] INTERNET-DRAFT Using PSK in the CMS August 2019 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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. Version Numbers The major data structures include a version number as the first item in the data structure. The version number is intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and then if a decode error occurs, the version number is checked as part of the error handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender. Whenever the structure is updated, a higher version number will be assigned. However, to ensure maximum interoperability, the higher version number is only used when the new syntax feature is employed. That is, the lowest version number that supports the generated syntax is used. 2. Overview The CMS enveloped-data content type [RFC5652] and the CMS authenticated-enveloped-data content type [RFC5083] support both key transport and key agreement public-key algorithms to establish the key used to encrypt the content. No restrictions are imposed on the key transport or key agreement public-key algorithms, which means that any key transport or key agreement algorithm can be used, including algorithms that are specified in the future. In both cases, the sender randomly generates the content-encryption key, and then all recipients obtain that key. All recipients use the sender- generated symmetric content-encryption key for decryption. This specification defines two quantum-resistant ways to establish a symmetric key-encryption key, which is used to encrypt the sender- generated content-encryption key. In both cases, the PSK is used as one of the inputs to a key-derivation function to create a quantum- Housley [Page 4] INTERNET-DRAFT Using PSK in the CMS August 2019 resistant key-encryption key. The PSK MUST be distributed to the sender and all of the recipients by some out-of-band means that does not make it vulnerable to the future invention of a large-scale quantum computer, and an identifier MUST be assigned to the PSK. It is best if each PSK has a unique identifier; however, if a recipient has more than one PSK with the same identifier, the recipient can try each of them in turn. A PSK is expected to be used with many messages, with a lifetime of weeks or months. The content-encryption key or content-authenticated-encryption key is quantum-resistant, and the sender establishes it using these steps: When using a key transport algorithm: 1. The content-encryption key or the content-authenticated- encryption key, called CEK, is generated at random. 2. The key-derivation key, called KDK, is generated at random. 3. For each recipient, the KDK is encrypted in the recipient's public key, then the key derivation function (KDF) is used to mix the pre-shared key (PSK) and the KDK to produce the key- encryption key, called KEK. 4. The KEK is used to encrypt the CEK. When using a key agreement algorithm: 1. The content-encryption key or the content-authenticated- encryption key, called CEK, is generated at random. 2. For each recipient, a pairwise key-encryption key, called KEK1, is established using the recipient's public key and the sender's private key. Note that KEK1 will be used as a key- derivation key. 3. For each recipient, the key derivation function (KDF) is used to mix the pre-shared key (PSK) and the pairwise KEK1, and the result is called KEK2. 4. For each recipient, the pairwise KEK2 is used to encrypt the CEK. As specified in Section 6.2.5 of [RFC5652], recipient information for additional key management techniques are represented in the OtherRecipientInfo type. Two key management techniques are specified in this document, and they are each identified by a unique ASN.1 object identifier. Housley [Page 5] INTERNET-DRAFT Using PSK in the CMS August 2019 The first key management technique, called keyTransPSK, see Section 3, uses a key transport algorithm to transfer the key- derivation key from the sender to the recipient, and then the key- derivation key is mixed with the PSK using a KDF. The output of the KDF is the key-encryption key, which is used for the encryption of the content-encryption key or content-authenticated-encryption key. The second key management technique, called keyAgreePSK, see Section 4, uses a key agreement algorithm to establish a pairwise key-encryption key, which is then mixed with the PSK using a KDF to produce a second pairwise key-encryption key, which is then used to encrypt the content-encryption key or content-authenticated- encryption key. 3. keyTransPSK Per-recipient information using keyTransPSK is represented in the KeyTransPSKRecipientInfo type, which is indicated by the id-ori- keyTransPSK object identifier. Each instance of KeyTransPSKRecipientInfo establishes the content-encryption key or content-authenticated-encryption key for one or more recipients that have access to the same PSK. The id-ori-keyTransPSK object identifier is: id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } The KeyTransPSKRecipientInfo type is: KeyTransPSKRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 0 pskid PreSharedKeyIdentifier, kdfAlgorithm KeyDerivationAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, ktris KeyTransRecipientInfos, encryptedKey EncryptedKey } PreSharedKeyIdentifier ::= OCTET STRING KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo Housley [Page 6] INTERNET-DRAFT Using PSK in the CMS August 2019 The fields of the KeyTransPSKRecipientInfo type have the following meanings: version is the syntax version number. The version MUST be 0. The CMSVersion type is described in Section 10.2.5 of [RFC5652]. pskid is the identifier of the PSK used by the sender. The identifier is an OCTET STRING, and it need not be human readable. kdfAlgorithm identifies the key-derivation algorithm, and any associated parameters, used by the sender to mix the key- derivation key and the PSK to generate the key-encryption key. The KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of [RFC5652]. keyEncryptionAlgorithm identifies a key-encryption algorithm used to encrypt the content-encryption key. The KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of [RFC5652]. ktris contains one KeyTransRecipientInfo type for each recipient; it uses a key transport algorithm to establish the key-derivation key. That is, the encryptedKey field of KeyTransRecipientInfo contains the key-derivation key instead of the content-encryption key. KeyTransRecipientInfo is described in Section 6.2.1 of [RFC5652]. encryptedKey is the result of encrypting the content-encryption key or the content-authenticated-encryption key with the key- encryption key. EncryptedKey is an OCTET STRING. 4. keyAgreePSK Per-recipient information using keyAgreePSK is represented in the KeyAgreePSKRecipientInfo type, which is indicated by the id-ori- keyAgreePSK object identifier. Each instance of KeyAgreePSKRecipientInfo establishes the content-encryption key or content-authenticated-encryption key for one or more recipients that have access to the same PSK. The id-ori-keyAgreePSK object identifier is: id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } Housley [Page 7] INTERNET-DRAFT Using PSK in the CMS August 2019 The KeyAgreePSKRecipientInfo type is: KeyAgreePSKRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 0 pskid PreSharedKeyIdentifier, originator [0] EXPLICIT OriginatorIdentifierOrKey, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, kdfAlgorithm KeyDerivationAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, recipientEncryptedKeys RecipientEncryptedKeys } The fields of the KeyAgreePSKRecipientInfo type have the following meanings: version is the syntax version number. The version MUST be 0. The CMSVersion type is described in Section 10.2.5 of [RFC5652]. pskid is the identifier of the PSK used by the sender. The identifier is an OCTET STRING, and it need not be human readable. originator is a CHOICE with three alternatives specifying the sender's key agreement public key. Implementations MUST support all three alternatives for specifying the sender's public key. The sender uses their own private key and the recipient's public key to generate a pairwise key-encryption key. A key derivation function (KDF) is used to mix the PSK and the pairwise key- encryption key to produce a second key-encryption key. The OriginatorIdentifierOrKey type is described in Section 6.2.2 of [RFC5652]. ukm is optional. With some key agreement algorithms, the sender provides a User Keying Material (UKM) to ensure that a different key is generated each time the same two parties generate a pairwise key. Implementations MUST accept a KeyAgreePSKRecipientInfo SEQUENCE that includes a ukm field. Implementations that do not support key agreement algorithms that make use of UKMs MUST gracefully handle the presence of UKMs. The UserKeyingMaterial type is described in Section 10.2.6 of [RFC5652]. kdfAlgorithm identifies the key-derivation algorithm, and any associated parameters, used by the sender to mix the pairwise key- encryption key and the PSK to produce a second key-encryption key of the same length as the first one. The KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of [RFC5652]. Housley [Page 8] INTERNET-DRAFT Using PSK in the CMS August 2019 keyEncryptionAlgorithm identifies a key-encryption algorithm used to encrypt the content-encryption key or the content- authenticated-encryption key. The KeyEncryptionAlgorithmIdentifier type is described in Section 10.1.3 of [RFC5652]. recipientEncryptedKeys includes a recipient identifier and encrypted key for one or more recipients. The KeyAgreeRecipientIdentifier is a CHOICE with two alternatives specifying the recipient's certificate, and thereby the recipient's public key, that was used by the sender to generate a pairwise key-encryption key. The encryptedKey is the result of encrypting the content-encryption key or the content- authenticated-encryption key with the second pairwise key- encryption key. EncryptedKey is an OCTET STRING. The RecipientEncryptedKeys type is defined in Section 6.2.2 of [RFC5652]. 5. Key Derivation Many key derivation functions (KDFs) internally employ a one-way hash function. When this is the case, the hash function that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] is one example of a KDF that makes use of a hash function. Other KDFs internally employ an encryption algorithm. When this is the case, the encryption that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. For example, AES-128-CMAC can be used for randomness extraction in a KDF as described in [NIST2018]. A KDF has several input values. This section describes the conventions for using the KDF to compute the key-encryption key for KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For simplicity, the terminology used in the HKDF [RFC5869] specification is used here. The KDF inputs are: IKM is the input keying material; it is the symmetric secret input to the KDF. For KeyTransPSKRecipientInfo, it is the key- derivation key. For KeyAgreePSKRecipientInfo, it is the pairwise key-encryption key produced by the key agreement algorithm. salt is an optional non-secret random value. Many KDFs do not require a salt, and the KeyDerivationAlgorithmIdentifier assignments for HKDF [RFC8619] do not offer a parameter for a salt. If a particular KDF requires a salt, then the salt value is provided as a parameter of the KeyDerivationAlgorithmIdentifier. Housley [Page 9] INTERNET-DRAFT Using PSK in the CMS August 2019 L is the length of output keying material in octets; the value depends on the key-encryption algorithm that will be used. The algorithm is identified by the KeyEncryptionAlgorithmIdentifier. In addition, the OBJECT IDENTIFIER portion of the KeyEncryptionAlgorithmIdentifier is included in the next input value, called info. info is optional context and application specific information. The DER-encoding of CMSORIforPSKOtherInfo is used as the info value, and the PSK is included in this structure. Note that EXPLICIT tagging is used in the ASN.1 module that defines this structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is defined by the following ASN.1 structure: CMSORIforPSKOtherInfo ::= SEQUENCE { psk OCTET STRING, keyMgmtAlgType ENUMERATED { keyTrans (5), keyAgree (10) }, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, pskLength INTEGER (1..MAX), kdkLength INTEGER (1..MAX) } The fields of type CMSORIforPSKOtherInfo have the following meanings: psk is an OCTET STRING; it contains the PSK. keyMgmtAlgType is either set to 5 or 10. For KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. keyEncryptionAlgorithm is the KeyEncryptionAlgorithmIdentifier, which identifies the algorithm and provides algorithm parameters, if any. pskLength is a positive integer; it contains the length of the PSK in octets. kdkLength is a positive integer; it contains the length of the key-derivation key in octets. For KeyTransPSKRecipientInfo, the key-derivation key is generated by the sender. For KeyAgreePSKRecipientInfo, the key-derivation key is the pairwise key-encryption key produced by the key agreement algorithm. Housley [Page 10] INTERNET-DRAFT Using PSK in the CMS August 2019 The KDF output is: OKM is the output keying material, which is exactly L octets. The OKM is the key-encryption key that is used to encrypt the content- encryption key or the content-authenticated-encryption key. An acceptable KDF MUST accept IKM, L, and info inputs; and acceptable KDF MAY also accept salt and other inputs. All of these inputs MUST influence the output of the KDF. If the KDF requires a salt or other inputs, then those inputs MUST be provided as parameters of the KeyDerivationAlgorithmIdentifier. 6. ASN.1 Module This section contains the ASN.1 module for the two key management techniques defined in this document. This module imports types from other ASN.1 modules that are defined in [RFC5912] and [RFC6268]. CMSORIforPSK-2019 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-ori-psk-2019(TBD0) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All IMPORTS AlgorithmIdentifier{}, KEY-DERIVATION FROM AlgorithmInformation-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, KeyTransRecipientInfo, OriginatorIdentifierOrKey, UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier FROM CryptographicMessageSyntax-2010 -- [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; Housley [Page 11] INTERNET-DRAFT Using PSK in the CMS August 2019 -- -- OtherRecipientInfo Types (ori-) -- SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-keyTransPSK | ori-keyAgreePSK, ... } -- -- Key Transport with Pre-Shared Key -- ori-keyTransPSK OTHER-RECIPIENT ::= { KeyTransPSKRecipientInfo IDENTIFIED BY id-ori-keyTransPSK } id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } id-ori-keyTransPSK OBJECT IDENTIFIER ::= { id-ori 1 } KeyTransPSKRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 0 pskid PreSharedKeyIdentifier, kdfAlgorithm KeyDerivationAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, ktris KeyTransRecipientInfos, encryptedKey EncryptedKey } PreSharedKeyIdentifier ::= OCTET STRING KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo -- -- Key Agreement with Pre-Shared Key -- ori-keyAgreePSK OTHER-RECIPIENT ::= { KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } Housley [Page 12] INTERNET-DRAFT Using PSK in the CMS August 2019 KeyAgreePSKRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 0 pskid PreSharedKeyIdentifier, originator [0] EXPLICIT OriginatorIdentifierOrKey, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, kdfAlgorithm KeyDerivationAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, recipientEncryptedKeys RecipientEncryptedKeys } -- -- Structure to provide 'info' input to the KDF, -- including the Pre-Shared Key -- CMSORIforPSKOtherInfo ::= SEQUENCE { psk OCTET STRING, keyMgmtAlgType ENUMERATED { keyTrans (5), keyAgree (10) }, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, pskLength INTEGER (1..MAX), kdkLength INTEGER (1..MAX) } END 7. Security Considerations The security considerations in related to the CMS enveloped-data content type in [RFC5652] and the security considerations related to the CMS authenticated-enveloped-data content type in [RFC5083] continue to apply. Implementations of the key derivation function must compute the entire result, which in this specification is a key-encryption key, before outputting any portion of the result. The resulting key- encryption key must be protected. Compromise of the key-encryption key may result in the disclosure of all content-encryption keys or content-authenticated-encryption keys that were protected with that keying material, which in turn may result in the disclosure of the content. Note that there are two key-encryption keys when a PSK with a key agreement algorithm is used, with similar consequence for the compromise of either one of these keys. Implementations must protect the pre-shared key (PSK), key transport private key, the agreement private key, and the key-derivation key. Compromise of the PSK will make the encrypted content vulnerable to Housley [Page 13] INTERNET-DRAFT Using PSK in the CMS August 2019 the future invention of a large-scale quantum computer. Compromise of the PSK and either the key transport private key or the agreement private key may result in the disclosure of all contents protected with that combination of keying material. Compromise of the PSK and the key-derivation key may result in disclosure of all contents protected with that combination of keying material. A large-scale quantum computer will essentially negate the security provided by the key transport algorithm or the key agreement algorithm, which means that the attacker with a large-scale quantum computer can discover the key-derivation key. In addition a large- scale quantum computer effectively cuts the security provided by a symmetric key algorithm in half. Therefore, the PSK needs at least 256 bits of entropy to provide 128 bits of security. To match that same level of security, the key derivation function needs to be quantum-resistant and produce a key-encryption key that is at least 256 bits in length. Similarly, the content-encryption key or content-authenticated-encryption key needs to be at least 256 bits in length. When using a PSK with a key transport or a key agreement algorithm, a key-encryption key is produced to encrypt the content-encryption key or content-authenticated-encryption key. If the key-encryption algorithm is different than the algorithm used to protect the content, then the effective security is determined by the weaker of the two algorithms. If, for example, content is encrypted with 256-bit AES, and the key is wrapped with 128-bit AES, then at most 128 bits of protection is provided. Implementers must ensure that the key-encryption algorithm is as strong or stronger than the content-encryption algorithm or content-authenticated-encryption algorithm. The selection of the key-derivation function imposes an upper bound on the strength of the resulting key-encryption key. The strength of the selected key-derivation function should be at least as strong as the key-encryption algorithm that is selected. NIST SP 800-56C Revision 1 [NIST2018] offers advice on the security strength of several popular key-derivation functions. Implementers should not mix quantum-resistant key management algorithms with their non-quantum-resistant counterparts. For example, the same content should not be protected with KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the same content should not be protected with KeyAgreeRecipientInfo and KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable to the future invention of a large-scale quantum computer. Implementers should not send the same content in different messages, Housley [Page 14] INTERNET-DRAFT Using PSK in the CMS August 2019 one using a quantum-resistant key management algorithm and the other using a non-quantum-resistant key management algorithm, even if the content-encryption key is generated independently. Doing so may allow an eavesdropper to correlate the messages, making the content vulnerable to the future invention of a large-scale quantum computer. This specification does not require that PSK is known only by the sender and recipients. The PSK may be known to a group. Since confidentiality depends on the key transport or key agreement algorithm, knowledge of the PSK by other parties does not enable inherently eavesdropping. However, group members can record the traffic of other members, and then decrypt it if they ever gain access to a large-scale quantum computer. Also, when many parties know the PSK, there are many opportunities for theft of the PSK by an attacker. Once an attacker has the PSK, they can decrypt stored traffic if they ever gain access to a large-scale quantum computer in the same manner as a legitimate group member. Sound cryptographic key hygiene is to use a key for one and only one purpose. Use of the recipient's public key for both the traditional CMS and the PSK-mixing variation specified in this document would be a violation of this principle; however, there is no known way for an attacker to take advantage of this situation. That said, an application should enforce separation whenever possible. For example, a purpose identifier for use in the X.509 extended key usage certificate extension [RFC5280] could be identified in the future to indicate that a public key should only be used in conjunction with a PSK, or only without. Implementations must randomly generate key-derivation keys as well as the content-encryption keys or content-authenticated-encryption keys. Also, the generation of public/private key pairs for the key transport and key agreement algorithms rely on a random numbers. 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. [RFC4086] offers important guidance in this area. Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced. Therefore, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of supported algorithms to change over time. Housley [Page 15] INTERNET-DRAFT Using PSK in the CMS August 2019 The security properties provided by the mechanisms specified in this document can be validated using formal methods. A ProVerif proof in [H2019] shows that an attacker with a large-scale quantum computer that is capable of breaking the Diffie-Hellman key agreement algorithm cannot disrupt the delivery of the content-encryption key to the recipient and the attacker cannot learn the content-encryption key from the protocol exchange. 8. Privacy Considerations An observer can see which parties are using each PSK simply by watching the PSK key identifiers. However, the addition of these key identifiers is not really making privacy worse. When key transport is used, the RecipientIdentifier is always present, and it clearly identifies each recipient to an observer. When key agreement is used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier is always present, and these clearly identify each recipient. 9. IANA Considerations One object identifier for the ASN.1 module in Section 6 was assigned in the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) mod(0) TBD0 } One new registry was created for Other Recipient Info Identifiers within the SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16) [IANA-SMIME] registry: id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } Updates to the new registry are to be made according to the Specification Required policy as defined in [RFC8126]. The expert is expected to ensure that any new values identify additions RecipientInfo structures for use with the CMS. Object identifiers for other purposes should not be assigned in this arc. Housley [Page 16] INTERNET-DRAFT Using PSK in the CMS August 2019 Two assignments were made in the new SMI Security for Other Recipient Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with references to this document: id-ori-keyTransPSK OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 1 } id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 2 } 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. [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010. [RFC6268] Schaad, J., S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 2011. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2015. Housley [Page 17] INTERNET-DRAFT Using PSK in the CMS August 2019 [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. 10.2. Informative References [AES] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), 26 November 2001. [C2PQ] Hoffman, P., "The Transition from Classical to Post- Quantum Cryptography", work-in-progress, draft-hoffman- c2pq-05, August 2018. [FGHT2016] Fried, J., Gaudry, P., Heninger, N., and E. Thome, "A kilobit hidden SNFS discrete logarithm computation", Cryptology ePrint Archive, Report 2016/961, 2016. https://eprint.iacr.org/2016/961.pdf. [H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf- lamps-cms-mix-with-psk", , 27 May 2019. [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime-0. [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime. [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime-TBD1. [NAS2019] National Academies of Sciences, Engineering, and Medicine, "Quantum Computing: Progress and Prospects", The National Academies Press, DOI 10.17226/25196, 2019. [NIST2018] Barker, E., Chen, L., and R. Davis, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes", NIST Special Publication 800-56C Rev. 1, April 2018, . [S1994] Shor, P., "Algorithms for Quantum Computation: Discrete Logarithms and Factoring", Proceedings of the 35th Annual Symposium on Foundations of Computer Science, 1994, pp. 124-134. Housley [Page 18] INTERNET-DRAFT Using PSK in the CMS August 2019 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005. [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, May 2008. [RFC5753] Turner, S., and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010. [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- Expand Key Derivation Function (HKDF)", RFC 5869, May 2010. [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, November 2016. [RFC8619] Housley, R., "Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", June 2019. Appendix A: Key Transport with PSK Example This example shows the establishment of an AES-256 content-encryption key using: - a pre-shared key of 256 bits; - key transport using RSA PKCS#1 v1.5 with a 3072-bit key; - key derivation using HKDF with SHA-384; and - key wrap using AES-256-KEYWRAP. In real-world use, the originator would encrypt the key-derivation key in their own RSA public key as well as the recipient's public key. This is omitted in an attempt to simplify the example. A.1. Originator Processing Example The pre-shared key known to Alice and Bob, in hexadecimal: c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 Housley [Page 19] INTERNET-DRAFT Using PSK in the CMS August 2019 The identifier assigned to the pre-shared key is: ptf-kmc:13614122112 Alice obtains Bob's public key: -----BEGIN PUBLIC KEY----- MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA3ocW14cxncPJ47fnEjBZ AyfC2lqapL3ET4jvV6C7gGeVrRQxWPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JH Keeza+itfuhsz3yifgeEpeK8T+SusHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqq vS3jg/VO+OPnZbofoHOOevt8Q/roahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx 2AHHZJevo3nmRnlgJXo6mE00E/6qkhjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0v SH7qUl8/vN13y4UOFkn8hM4kmZ6bJqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39a uLNnH3EXdXaV1tk75H3qC7zJaeGWMJyQfOE3YfEGRKn8fxubji716D8UecAxAzFy FL6m1JiOyV5acAiOpxN14qRYZdHnXOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fS whSZG7VNf+vgNWTLNYSYLI04KiMdulnvU6ds+QPz+KKtAgMBAAE= -----END PUBLIC KEY----- Bob's RSA public key has the following key identifier: 9eeb67c9b95a74d44d2f16396680e801b5cba49c Alice randomly generates a content-encryption key: c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 Alice randomly generates a key-derivation key: df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb Alice encrypts the key-derivation key in Bob's public key: 4e6200431ed95e0e28f7288dba56d4b90e75959e068884664c43368f3d978f3d 8179e5837e3c27bf8dc1f6e2827b9ede969be77417516de07d90e37c560add01 48deb0c9178088ccb72c068d8a9076b6a5e7ecc9093e30fdeaecc9e138d80626 74fcf685f3082b910839551cd8741beedeee6e87c08ff84f03ba87118730cdf7 667002316f1a29a6cc596c7ddf95a51e398927d1916bf27929945de080fc7c80 6af6281aed6492acffa4ef1b4f53e67fca9a417db2350a2277d586ee3cabefd3 b4a44f04d3c6803d54fe9a7159210dabedda9a94f310d303331da51c0218d92a 2efb003792259195a9fd4cc403af613fdf1a6265ea70bf702fd1c6f734264c9a 59196e8e8fd657fa028e272ef741eb7711fd5b3f4ea7da9c33df66bf487da710 1c9bbfddaf1c073900a3ea99da513d8aa32605db07dc1c47504cab30c9304a85 d87377f603ec3df4056ddcf3d756fb7ed98254421a4ae151f17ad4e28c5ea077 63358dfb1ef5f73435f337b21a38c1a3fa697a530dd97e462f6b5fb2052a2d53 Housley [Page 20] INTERNET-DRAFT Using PSK in the CMS August 2019 Alice produces a 256-bit key-encryption key with HKDF using SHA-384; the secret value is the key-derivation key; the 'info' is the DER- encoded CMSORIforPSKOtherInfo structure with the following values: 0 56: SEQUENCE { 2 32: OCTET STRING : C2 44 CD D1 1A 0D 1F 39 D9 B6 12 82 77 02 44 FB : 0F 6B EF B9 1A B7 F9 6C B0 52 13 36 5C F9 5B 15 36 1: ENUMERATED 5 39 11: SEQUENCE { 41 9: OBJECT IDENTIFIER aes256-wrap : { 2 16 840 1 101 3 4 1 45 } : } 52 1: INTEGER 32 55 1: INTEGER 32 : } The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 30380420c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb0521336 5cf95b150a0105300b060960864801650304012d020120020120 The HKDF output is 256 bits: a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 Alice uses AES-KEY-WRAP to encrypt the 256-bit content-encryption key with the key-encryption key: ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566 c83d0dd5d1b4faa5 Alice encrypts the content using AES-256-GCM with the content- encryption key. The 12-octet nonce used is: cafebabefacedbaddecaf888 The content plaintext is: 48656c6c6f2c20776f726c6421 The resulting ciphertext is: 9af2d16f21547fcefed9b3ef2d The resulting 12-octet authentication tag is: a0e5925cc184e0172463c44c Housley [Page 21] INTERNET-DRAFT Using PSK in the CMS August 2019 A.2. ContentInfo and AuthEnvelopedData Alice encodes the AuthEnvelopedData and the ContentInfo, and sends the result to Bob. The resulting structure is: 0 650: SEQUENCE { 4 11: OBJECT IDENTIFIER authEnvelopedData : { 1 2 840 113549 1 9 16 1 23 } 17 633: [0] { 21 629: SEQUENCE { 25 1: INTEGER 0 28 551: SET { 32 547: [4] { 36 11: OBJECT IDENTIFIER ** Placeholder ** : { 1 2 840 113549 1 9 16 TBD 1 } 49 530: SEQUENCE { 53 1: INTEGER 0 56 19: OCTET STRING 'ptf-kmc:13614122112' 77 13: SEQUENCE { 79 11: OBJECT IDENTIFIER ** Placeholder ** : { 1 2 840 113549 1 9 16 3 TBD } : } 92 11: SEQUENCE { 94 9: OBJECT IDENTIFIER aes256-wrap : { 2 16 840 1 101 3 4 1 45 } : } 105 432: SEQUENCE { 109 428: SEQUENCE { 113 1: INTEGER 2 116 20: [0] : 9E EB 67 C9 B9 5A 74 D4 4D 2F 16 39 66 80 E8 01 : B5 CB A4 9C 138 13: SEQUENCE { 140 9: OBJECT IDENTIFIER rsaEncryption : { 1 2 840 113549 1 1 1 } 151 0: NULL : } 153 384: OCTET STRING : 18 09 D6 23 17 DF 2D 09 55 57 3B FE 75 95 EB 6A : 3D 57 84 6C 69 C1 49 0B F1 11 1A BB 40 0C D8 B5 : 26 5F D3 62 4B E2 D8 E4 CA EC 6A 12 36 CA 38 E3 : A0 7D AA E0 5F A1 E3 BC 59 F3 AD A8 8D 95 A1 6B : 06 85 20 93 C7 C5 C0 05 62 ED DF 02 1D FE 68 7C : 18 A1 3A AB AA 59 92 30 6A 1B 92 73 D5 01 C6 5B : FD 1E BB A9 B9 D2 7F 48 49 7F 3C 4F 3C 13 E3 2B : 2A 19 F1 7A CD BC 56 28 EF 7F CA 4F 69 6B 7E 92 : 66 22 0D 13 B7 23 AD 41 9E 5E 98 2A 80 B7 6C 77 : FF 9B 76 B1 04 BA 30 6D 4B 4D F9 25 57 E0 7F 0E Housley [Page 22] INTERNET-DRAFT Using PSK in the CMS August 2019 : 95 9A 43 6D 14 D5 72 3F AA 8F 66 35 40 D0 E3 71 : 4B 7F 20 9D ED 67 EA 33 79 CD AB 84 16 72 07 D2 : AC 8D 3A DA 12 43 B7 2F 3A CF 91 3E F1 D9 58 20 : 6D F2 9C 09 E1 EC D2 0B 82 BE 5D 69 77 6F FE F7 : EB F6 31 C0 D9 B7 15 BF D0 24 F3 05 1F FF 48 76 : 1D 73 17 19 2C 38 C6 D5 86 BD 67 82 2D B2 61 AA : 08 C7 E4 37 34 D1 2D E0 51 32 15 4A AC 6B 2B 28 : 5B CD FA 7C 65 89 2F A2 63 DB AB 64 88 43 CC 66 : 27 84 29 AC 15 5F 3B 9E 5B DF 99 AE 4F 1B B2 BC : 19 6C 17 A1 99 A5 CF F7 80 32 11 88 F1 9D B3 6F : 4B 16 5F 3F 03 F7 D2 04 3D DE 5F 30 CD 8B BB 3A : 38 DA 9D EC 16 6C 36 4F 8B 7E 99 AA 99 FB 42 D6 : 1A FF 3C 85 D7 A2 30 74 2C D3 AA F7 18 2A 25 3C : B5 02 C4 17 62 21 97 F1 E9 81 83 D0 4E BF 5B 5D : } : } 541 40: OCTET STRING : AE 4E A1 D9 9E 78 FC DC EA 12 D9 F1 0D 99 1A C7 : 15 02 93 9E E0 C3 0E BD CC 97 DD 1F C5 BA 35 66 : C8 3D 0D D5 D1 B4 FA A5 : } : } : } 583 55: SEQUENCE { 585 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 596 27: SEQUENCE { 598 9: OBJECT IDENTIFIER aes256-GCM : { 2 16 840 1 101 3 4 1 46 } 609 14: SEQUENCE { 611 12: OCTET STRING CA FE BA BE FA CE DB AD DE CA F8 88 : } : } 625 13: [0] 9A F2 D1 6F 21 54 7F CE FE D9 B3 EF 2D : } 640 12: OCTET STRING A0 E5 92 5C C1 84 E0 17 24 63 C4 4C : } : } : } Housley [Page 23] INTERNET-DRAFT Using PSK in the CMS August 2019 A.3. Recipient Processing Example Bob's private key: -----BEGIN RSA PRIVATE KEY----- MIIG5AIBAAKCAYEA3ocW14cxncPJ47fnEjBZAyfC2lqapL3ET4jvV6C7gGeVrRQx WPDwl+cFYBBR2ej3j3/0ecDmu+XuVi2+s5JHKeeza+itfuhsz3yifgeEpeK8T+Su sHhn20/NBLhYKbh3kiAcCgQ56dpDrDvDcLqqvS3jg/VO+OPnZbofoHOOevt8Q/ro ahJe1PlIyQ4udWB8zZezJ4mLLfbOA9YVaYXx2AHHZJevo3nmRnlgJXo6mE00E/6q khjDHKSMdl2WG6mO9TCDZc9qY3cAJDU6Ir0vSH7qUl8/vN13y4UOFkn8hM4kmZ6b JqbZt5NbjHtY4uQ0VMW3RyESzhrO02mrp39auLNnH3EXdXaV1tk75H3qC7zJaeGW MJyQfOE3YfEGRKn8fxubji716D8UecAxAzFyFL6m1JiOyV5acAiOpxN14qRYZdHn XOM9DqGIGpoeY1UuD4Mo05osOqOUpBJHA9fSwhSZG7VNf+vgNWTLNYSYLI04KiMd ulnvU6ds+QPz+KKtAgMBAAECggGATFfkSkUjjJCjLvDk4aScpSx6+Rakf2hrdS3x jwqhyUfAXgTTeUQQBs1HVtHCgxQd+qlXYn3/qu8TeZVwG4NPztyi/Z5yB1wOGJEV 3k8N/ytul6pJFFn6p48VM01bUdTrkMJbXERe6g/rr6dBQeeItCaOK7N5SIJH3Oqh 9xYuB5tH4rquCdYLmt17Tx8CaVqU9qPY3vOdQEOwIjjMV8uQUR8rHSO9KkSj8AGs Lq9kcuPpvgJc2oqMRcNePS2WVh8xPFktRLLRazgLP8STHAtjT6SlJ2UzkUqfDHGK q/BoXxBDu6L1VDwdnIS5HXtL54ElcXWsoOyKF8/ilmhRUIUWRZFmlS1ok8IC5IgX UdL9rJVZFTRLyAwmcCEvRM1asbBrhyEyshSOuN5nHJi2WVJ+wSHijeKl1qeLlpMk HrdIYBq4Nz7/zXmiQphpAy+yQeanhP8O4O6C8e7RwKdpxe44su4Z8fEgA5yQx0u7 8yR1EhGKydX5bhBLR5Cm1VM7rT2BAoHBAP/+e5gZLNf/ECtEBZjeiJ0VshszOoUq haUQPA+9Bx9pytsoKm5oQhB7QDaxAvrn8/FUW2aAkaXsaj9F+/q30AYSQtExai9J fdKKook3oimN8/yNRsKmhfjGOj8hd4+GjX0qoMSBCEVdT+bAjjry8wgQrqReuZnu oXU85dmb3jvv0uIczIKvTIeyjXE5afjQIJLmZFXsBm09BG87Ia5EFUKly96BOMJh /QWEzuYYXDqOFfzQtkAefXNFW21Kz4Hw2QKBwQDeiGh4lxCGTjECvG7fauMGlu+q DSdYyMHif6t6mx57eS16EjvOrlXKItYhIyzW8Kw0rf/CSB2j8ig1GkMLTOgrGIJ1 0322o50FOr5oOmZPueeR4pOyAP0fgQ8DD1L3JBpY68/8MhYbsizVrR+Ar4jM0f96 W2bF5Xj3h+fQTDMkx6VrCCQ6miRmBUzH+ZPs5n/lYOzAYrqiKOanaiHy4mjRvlsy mjZ6z5CG8sISqcLQ/k3Qli5pOY/v0rdBjgwAW/UCgcEAqGVYGjKdXCzuDvf9EpV4 mpTWB6yIV2ckaPOn/tZi5BgsmEPwvZYZt0vMbu28Px7sSpkqUuBKbzJ4pcy8uC3I SuYiTAhMiHS4rxIBX3BYXSuDD2RD4vG1+XM0h6jVRHXHh0nOXdVfgnmigPGz3jVJ B8oph/jD8O2YCk4YCTDOXPEi8Rjusxzro+whvRR+kG0gsGGcKSVNCPj1fNISEte4 gJId7O1mUAAzeDjn/VaS/PXQovEMolssPPKn9NocbKbpAoHBAJnFHJunl22W/lrr ppmPnIzjI30YVcYOA5vlqLKyGaAsnfYqP1WUNgfVhq2jRsrHx9cnHQI9Hu442PvI x+c5H30YFJ4ipE3eRRRmAUi4ghY5WgD+1hw8fqyUW7E7l5LbSbGEUVXtrkU5G64T UR91LEyMF8OPATdiV/KD4PWYkgaqRm3tVEuCVACDTQkqNsOOi3YPQcm270w6gxfQ SOEy/kdhCFexJFA8uZvmh6Cp2crczxyBilR/yCxqKOONqlFdOQKBwFbJk5eHPjJz AYueKMQESPGYCrwIqxgZGCxaqeVArHvKsEDx5whI6JWoFYVkFA8F0MyhukoEb/2x 2qB5T88Dg3EbqjTiLg3qxrWJ2OxtUo8pBP2I2wbl2NOwzcbrlYhzEZ8bJyxZu5i1 sYILC8PJ4Qzw6jS4Qpm4y1WHz8e/ElW6VyfmljZYA7f9WMntdfeQVqCVzNTvKn6f hg6GSpJTzp4LV3ougi9nQuWXZF2wInsXkLYpsiMbL6Fz34RwohJtYA== -----END RSA PRIVATE KEY----- Bob decrypts the key-derivation key with his RSA private key: df85af9e3cebffde6e9b9d24263db31114d0a8e33a0d50e05eb64578ccde81eb Housley [Page 24] INTERNET-DRAFT Using PSK in the CMS August 2019 Bob produces a 256-bit key-encryption key with HKDF using SHA-384; the secret value is the key-derivation key; the 'info' is the DER- encoded CMSORIforPSKOtherInfo structure with the same values as shown in A.1. The HKDF output is 256 bits: a14d87451dfd11d83cd54ffe2bd38c49a2adfed3ac49f1d3e62bbdc64ae43b32 Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the key-encryption key; the content-encryption key is: c8adc30f4a3e20ac420caa76a68f5787c02ab42afea20d19672fd963a5338e83 Bob decrypts the content using AES-256-GCM with the content- encryption key, and checks the received authentication tag. The 12-octet nonce used is: cafebabefacedbaddecaf888 The 12-octet authentication tag is: a0e5925cc184e0172463c44c The received ciphertext content is: 9af2d16f21547fcefed9b3ef2d The resulting plaintext content is: 48656c6c6f2c20776f726c6421 Appendix B: Key Agreement with PSK Example This example shows the establishment of an AES-256 content-encryption key using: - a pre-shared key of 256 bits; - key agreement using ECDH on curve P-384 and X9.63 KDF with SHA-384; - key derivation using HKDF with SHA-384; and - key wrap using AES-256-KEYWRAP. In real-world use, the originator would treat themselves as an additional recipient by performing key agreement with their own static public key and the ephemeral private key generated for this message. This is omitted in an attempt to simplify the example. B.1. Originator Processing Example The pre-shared key known to Alice and Bob, in hexadecimal: 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 The identifier assigned to the pre-shared key is: ptf-kmc:216840110121 Housley [Page 25] INTERNET-DRAFT Using PSK in the CMS August 2019 Alice randomly generates a content-encryption key: 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 Alice obtains Bob's static ECDH public key: -----BEGIN PUBLIC KEY----- MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEScGPBO9nmUwGrgbGEoFY9HR/bCo0WyeY /dePQVrwZmwN2yMJmO2d1kWCvLTz8U7atinxyIRe9CV54yau1KWU/wbkhPDnzuSM YkcpxMGo32z3JetEloW5aFOja13vv/W5 -----END PUBLIC KEY----- It has a key identifier of: e8218b98b8b7d86b5e9ebdc8aeb8c4ecdc05c529 Alice generates an ephemeral ECDH key pair on the same curve: -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDCMiWLG44ik+L8cYVvJrQdLcFA+PwlgRF+Wt1Ab25qUh8OB7OePWjxp /b8P6IOuI6GgBwYFK4EEACKhZANiAAQ5G0EmJk/2ks8sXY1kzbuG3Uu3ttWwQRXA LFDJICjvYfr+yTpOQVkchm88FAh9MEkw4NKctokKNgpsqXyrT3DtOg76oIYENpPb GE5lJdjPx9sBsZQdABwlsU0Zb7P/7i8= -----END EC PRIVATE KEY----- Alice computes a shared secret, called Z, using the Bob's static ECDH public key and her ephemeral ECDH private key; Z is: 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 19cf8807e6d800c2de40240fe0e26adc Alice computes the pairwise key-encryption key, called KEK1, from Z using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the following values: 0 21: SEQUENCE { 2 11: SEQUENCE { 4 9: OBJECT IDENTIFIER aes256-wrap : { 2 16 840 1 101 3 4 1 45 } : } 15 6: [2] { 17 4: OCTET STRING 00 00 00 20 : } : } The DER encoding of ECC-CMS-SharedInfo produces 23 octets: 3015300b060960864801650304012da206040400000020 The X9.63 KDF output is the 256-bit KEK1: 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da Housley [Page 26] INTERNET-DRAFT Using PSK in the CMS August 2019 Alice produces the 256-bit KEK2 with HKDF using SHA-384; the secret value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo structure with the following values: 0 56: SEQUENCE { 2 32: OCTET STRING : 4A A5 3C BF 50 08 50 DD 58 3A 5D 98 21 60 5C 6F : A2 28 FB 59 17 F8 7C 1C 07 86 60 21 4E 2D 83 E4 36 1: ENUMERATED 10 39 11: SEQUENCE { 41 9: OBJECT IDENTIFIER aes256-wrap : { 2 16 840 1 101 3 4 1 45 } : } 52 1: INTEGER 32 55 1: INTEGER 32 : } The DER encoding of CMSORIforPSKOtherInfo produces 58 octets: 303804204aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c07866021 4e2d83e40a010a300b060960864801650304012d020120020120 The HKDF output is the 256-bit KEK2: 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb Alice uses AES-KEY-WRAP to encrypt the content-encryption key with the KEK2; the wrapped key is: 229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b de08866a602d63f4 Alice encrypts the content using AES-256-GCM with the content- encryption key. The 12-octet nonce used is: dbaddecaf888cafebabeface The plaintext is: 48656c6c6f2c20776f726c6421 The resulting ciphertext is: fc6d6f823e3ed2d209d0c6ffcf The resulting 12-octet authentication tag is: 550260c42e5b29719426c1ff Housley [Page 27] INTERNET-DRAFT Using PSK in the CMS August 2019 B.2. ContentInfo and AuthEnvelopedData Alice encodes the AuthEnvelopedData and the ContentInfo, and sends the result to Bob. The resulting structure is: 0 327: SEQUENCE { 4 11: OBJECT IDENTIFIER authEnvelopedData : { 1 2 840 113549 1 9 16 1 23 } 17 310: [0] { 21 306: SEQUENCE { 25 1: INTEGER 0 28 229: SET { 31 226: [4] { 34 11: OBJECT IDENTIFIER ** Placeholder ** : { 1 2 840 113549 1 9 16 TBD 2 } 47 210: SEQUENCE { 50 1: INTEGER 0 53 20: OCTET STRING 'ptf-kmc:216840110121' 75 85: [0] { 77 83: [1] { 79 19: SEQUENCE { 81 6: OBJECT IDENTIFIER : dhSinglePass-stdDH-sha256kdf-scheme : { 1 3 132 1 11 1 } 89 9: OBJECT IDENTIFIER aes256-wrap : { 2 16 840 1 101 3 4 1 45 } : } 100 60: BIT STRING, encapsulates { 103 57: OCTET STRING : 1B 41 26 26 4F F6 92 CF 2C 5D 8D 64 CD BB 86 DD : 4B B7 B6 D5 B0 41 15 C0 2C 50 C9 20 28 EF 61 FA : FE C9 3A 4E 41 59 1C 86 6F 3C 14 08 7D 30 49 30 : E0 D2 9C B6 89 0A 36 0A 6C : } : } : } 162 13: SEQUENCE { 164 11: OBJECT IDENTIFIER ** Placeholder ** : { 1 2 840 113549 1 9 16 3 TBD } : } 177 11: SEQUENCE { 179 9: OBJECT IDENTIFIER aes256-wrap : { 2 16 840 1 101 3 4 1 45 } : } 190 68: SEQUENCE { 192 66: SEQUENCE { Housley [Page 28] INTERNET-DRAFT Using PSK in the CMS August 2019 194 22: [0] { 196 20: OCTET STRING : E8 21 8B 98 B8 B7 D8 6B 5E 9E BD C8 AE B8 C4 EC : DC 05 C5 29 : } 218 40: OCTET STRING : 22 9F E0 B4 5E 40 00 3E 7D 82 44 EC 1B 7E 7F FB : 2C 8D CA 16 C3 6F 57 37 22 25 53 A7 12 63 A9 2B : DE 08 86 6A 60 2D 63 F4 : } : } : } : } : } 260 55: SEQUENCE { 262 9: OBJECT IDENTIFIER data { 1 2 840 113549 1 7 1 } 273 27: SEQUENCE { 275 9: OBJECT IDENTIFIER aes256-GCM : { 2 16 840 1 101 3 4 1 46 } 286 14: SEQUENCE { 288 12: OCTET STRING DB AD DE CA F8 88 CA FE BA BE FA CE : } : } 302 13: [0] FC 6D 6F 82 3E 3E D2 D2 09 D0 C6 FF CF : } 317 12: OCTET STRING 55 02 60 C4 2E 5B 29 71 94 26 C1 FF : } : } : } B.3. Recipient Processing Example Bob obtains Alice's ephemeral ECDH public key from the message: -----BEGIN PUBLIC KEY----- MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEORtBJiZP9pLPLF2NZM27ht1Lt7bVsEEV wCxQySAo72H6/sk6TkFZHIZvPBQIfTBJMODSnLaJCjYKbKl8q09w7ToO+qCGBDaT 2xhOZSXYz8fbAbGUHQAcJbFNGW+z/+4v -----END PUBLIC KEY----- Bob's static ECDH private key: -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDAnJ4hB+tTUN9X03/W0RsrYy+qcptlRSYkhaDIsQYPXfTU0ugjJEmRk NTPj4y1IRjegBwYFK4EEACKhZANiAARJwY8E72eZTAauBsYSgVj0dH9sKjRbJ5j9 149BWvBmbA3bIwmY7Z3WRYK8tPPxTtq2KfHIhF70JXnjJq7UpZT/BuSE8OfO5Ixi RynEwajfbPcl60SWhbloU6NrXe+/9bk= -----END EC PRIVATE KEY----- Housley [Page 29] INTERNET-DRAFT Using PSK in the CMS August 2019 Bob computes a shared secret, called Z, using the Alice's ephemeral ECDH public key and his static ECDH private key; Z is: 3f015ed0ff4b99523a95157bbe77e9cc0ee52fcffeb7e41eac79d1c11b6cc556 19cf8807e6d800c2de40240fe0e26adc Bob computes the pairwise key-encryption key, called KEK1, from Z using the X9.63 KDF with the ECC-CMS-SharedInfo structure with the values shown in B.1. The X9.63 KDF output is the 256-bit KEK1: 27dc25ddb0b425f7a968ceada80a8f73c6ccaab115baafcce4a22a45d6b8f3da Bob produces the 256-bit KEK2 with HKDF using SHA-384; the secret value is KEK1; the 'info' is the DER-encoded CMSORIforPSKOtherInfo structure with the values shown in B.1. The HKDF output is the 256-bit KEK2: 7de693ee30ae22b5f8f6cd026c2164103f4e1430f1ab135dc1fb98954f9830bb Bob uses AES-KEY-WRAP to decrypt the content-encryption key with the KEK2; the content-encryption key is: 937b1219a64d57ad81c05cc86075e86017848c824d4e85800c731c5b7b091033 Bob decrypts the content using AES-256-GCM with the content- encryption key, and checks the received authentication tag. The 12-octet nonce used is: dbaddecaf888cafebabeface The 12-octet authentication tag is: 550260c42e5b29719426c1ff The received ciphertext content is: fc6d6f823e3ed2d209d0c6ffcf The resulting plaintext content is: 48656c6c6f2c20776f726c6421 Acknowledgements Many thanks to Roman Danyliw, Ben Kaduk, Burt Kaliski, Panos Kampanakis, Jim Schaad, Robert Sparks, Sean Turner, and Daniel Van Geest for their review and insightful comments. They have greatly improved the design, clarity, and implementation guidance. Housley [Page 30] INTERNET-DRAFT Using PSK in the CMS August 2019 Author's Address Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 USA EMail: housley@vigilsec.com Housley [Page 31] ./draft-ietf-iasa2-trust-update-03.txt0000644000764400076440000002762513426050314017023 0ustar iustyiusty Internet Engineering Task Force J. Arkko Internet-Draft Ericsson Obsoletes: 4371 (if approved) T. Hardie Intended status: Best Current Practice February 4, 2019 Expires: August 8, 2019 Update to the Process for Selection of Trustees for the IETF Trust draft-ietf-iasa2-trust-update-03 Abstract This memo updates the process for selection of trustees for the IETF Trust. Previously, the Internet Administrative Oversight Committee (IAOC) members also acted as trustees, but the IAOC has been eliminated as part of an update of the structure of the Internet Administrative Support Activity (IASA). This memo specifies that the trustees shall be selected separately. This memo obsoletes RFC 4371. The changes relate only to the selection of trustees. All other aspects of the IETF Trust remain as they are today. 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 8, 2019. Copyright Notice Copyright (c) 2019 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 Arkko & Hardie Expires August 8, 2019 [Page 1] Internet-Draft Trustees for the IETF Trust February 2019 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. IETF Trust . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Selection of Trustees . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Changes from Previous Versions . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction This memo updates the process for selection of trustees for the IETF Trust. Previously, the Internet Administrative Oversight Committee (IAOC) members also acted as trustees, but the IAOC has been eliminated as part of an update of the structure of the Internet Administrative Support Activity (IASA). This memo specifies that the trustees shall be selected separately. See Section 3. This memo obsoletes RFC 4371. The changes relate only to the selection of trustees. All other aspects of the IETF Trust remain as they are today. Section 2 copies the definition as it was in RFC 4371, only leaving out the part about trustee selection and adding a reference to the IETF Trust website. For a discussion of why this change is needed and a rationale for these specific changes, see [I-D.ietf-iasa2-trust-rationale]. 2. IETF Trust A Trust ("the IETF Trust") has been formed for the purpose of acquiring, holding, maintaining, and licensing certain existing and future intellectual property and other property used in connection with the administration of the IETF. The Trust was formed by the signatures of its Settlors and initial Trustees. The Settlors, who contributed initial intellectual property to the Trust, were ISOC and Arkko & Hardie Expires August 8, 2019 [Page 2] Internet-Draft Trustees for the IETF Trust February 2019 the Corporation for National Research Initiatives. The Beneficiary of the IETF Trust is the IETF as a whole. Further details of the IETF Trust may be found at the IETF Trust's website, . 3. Selection of Trustees This document revises the original Trustee selection procedures defined in [RFC4071] and [RFC4371], to eliminate the requirement that trustees be drawn from the members of the IAOC. In this newly revised IETF Trust structure, there will be five Trustees. Three shall be appointed by the IETF Nominating Committee (NomCom) and confirmed by the Internet Engineering Steering Group (IESG), one shall be appointed by the IESG, and one shall be appointed by the Internet Society (ISOC) Board of Trustees. The appointments by the IESG and ISOC Board of Trustees do not require confirmation. The IETF Trust Chair informs the nominating committee of the Trustee positions to be reviewed. The IETF Trust will provide a summary of the expertise desired of the Trustee candidates to each appointing body. A change to the Trust Agreement is required to put this change into effect, and this document requests that the current Trustees make this change at the earliest convenient time and no later than the end of the 104th IETF meeting in March 2019. The terms of the appointed trustees from IETF NomCom shall be three years. The initial selection shall be one, two, and three year terms in order to initially stagger the terms. The other appointments by the IESG and the ISOC Board of Trustees shall be two year terms, with the initial terms being one and two years, respectively. The goal of the staggered initial terms is to minimize potential Trustee turnover in any single year. To maintain the staggered terms, each appointing body may at its discretion appoint Trustees for shorter terms as needed in exceptional situations, e.g., for mid-term vacancies or when an appointment is not ready by the time of the first IETF of the year. Once the initial trustee selections according to the procedures in this document are complete, and at each subsequent annual meeting of the IETF Trust once new trustees are seated, the trustees shall elect by a majority vote of the IETF Trust one trustee to serve as IETF Trust Chair. Arkko & Hardie Expires August 8, 2019 [Page 3] Internet-Draft Trustees for the IETF Trust February 2019 The processes regarding NomCom appointments and recalls of Trustees for the IETF Trust follow those described in [I-D.ietf-iasa2-rfc7437bis]. For the appointments by the IESG, the IESG is expected to run an open selection process and to consider the necessary skill set and conflicts of interest as part of that process. 4. Security Considerations This memo has no security implications for the Internet. 5. IANA Considerations This memo requests no action from IANA. 6. Acknowledgements The authors would like to thank members of the earlier IASA 2.0 design team who were Brian Haberman, Eric Rescorla, Jari Arkko, Jason Livingood, Joe Hall, and Leslie Daigle. The authors would also like to thank Alissa Cooper, Andrew Sullivan, Brian Carpenter, Lucy Lynch, and John Levine for interesting discussions in this problem space. The authors would also like to thank Russ Housley, Bob Hinden, Scott Mansfield, Alexey Melnikov, Suresh Krishnan, Mirja Kuhlewind, Ben Campbell, Spencer Dawkins, Martin Vigoreux, Benjamin Kaduk, and Adrian Farrel for careful review. Finally, the authors would like to thank the authors of [RFC4371], as the text from that RFC remains in this document. 7. References 7.1. Normative References [I-D.ietf-iasa2-rfc7437bis] Kucherawy, M., Hinden, R., and J. Livingood, "IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", draft-ietf-iasa2-rfc7437bis-05 (work in progress), January 2019. [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, . [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, January 2006, . Arkko & Hardie Expires August 8, 2019 [Page 4] Internet-Draft Trustees for the IETF Trust February 2019 7.2. Informative References [I-D.ietf-iasa2-trust-rationale] Arkko, J., "Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust", draft-ietf-iasa2-trust- rationale-03 (work in progress), October 2018. Appendix A. Changes from Previous Versions RFC Editor: Please remove this section upon publication. The -03pre1b version replaced updates of RFCs 4071 and 4371 with obsoletion of RFC 4371, and updated the reference to RFC 7437 to its newer bis version. It also copied the one remaining paragraph from RFC 4371 to this document. The version draft-itef-iasa2-trust-update-02.txt made some editorial corrections, as well as clarifying that no confirmation is needed in the cases other than the nomcom appointment, specified how IETF Trust chair is chosen, and required that an open process be used by the IESG for the selections. The version draft-ietf-iasa2-trust-update-01.txt has taken into account last call comments. The changes are: 1) Clarification of the role of the IETF Trust Chair to indicate which trustee positions are up for selection, similar to how RFC 7437 requires the IETF Executive Director to do it. 2) The addition of empty security and IANA consideration sections. 3) The clarification of the staggering rules for NomCom selections. 4) Updated text regarding the application of rules from RFC 7437. 5) Update draft title to be correct in terms of specifying a process rather than the actual persons. 6) Update the text regarding desirable expertise to use the same language as in RFC 7437 instead of the "list of desired qualifications". The version draft-ietf-iasa2-trust-update-00.txt corrected the desired document status to BCP, and made several editorial and language updates. This version also updated the wording for the request for the current trustees to adopt this change, from "earliest convenience" to "earliest convenient time". The version draft-arkko-iasa2-trust-update-00.txt was the initial version. Authors' Addresses Arkko & Hardie Expires August 8, 2019 [Page 5] Internet-Draft Trustees for the IETF Trust February 2019 Jari Arkko Ericsson Kauniainen 02700 Finland Email: jari.arkko@piuha.net Ted Hardie Email: ted.ietf@gmail.com Arkko & Hardie Expires August 8, 2019 [Page 6] ./draft-ietf-lamps-cms-shakes-18.txt0000644000764400076440000011443213540216424016537 0ustar iustyiusty LAMPS WG P. Kampanakis Internet-Draft Cisco Systems Updates: 3370 (if approved) Q. Dang Intended status: Standards Track NIST Expires: March 19, 2020 September 16, 2019 Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) draft-ietf-lamps-cms-shakes-18 Abstract This document updates the "Cryptographic Message Syntax Algorithms" (RFC3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated signer public keys in CMS are also described. 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 https://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 19, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Kampanakis & Dang Expires March 19, 2020 [Page 1] Internet-Draft SHAKEs in CMS September 2019 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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 7 4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 8 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 9 4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Message Authentication Codes . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Change Log [ EDNOTE: Remove this section before publication. ] o draft-ietf-lamps-cms-shake-18: * Minor ASN.1 changes. o draft-ietf-lamps-cms-shake-17: * Minor updates for EDNOTE accuracy. o draft-ietf-lamps-cms-shake-16: * Minor nits. * Using bytes instead of bits for consistency. o draft-ietf-lamps-cms-shake-15: * Minor editorial nits. Kampanakis & Dang Expires March 19, 2020 [Page 2] Internet-Draft SHAKEs in CMS September 2019 o draft-ietf-lamps-cms-shake-14: * Fixing error with incorrect preimage resistance bits for SHA128 and SHA256. o draft-ietf-lamps-cms-shake-13: * Addressing comments from Dan M.'s secdir review. * Addressing comment from Scott B.'s opsdir review about references in the abstract. o draft-ietf-lamps-cms-shake-12: * Nits identified by Roman, Barry L. in ballot position review. o draft-ietf-lamps-cms-shake-11: * Minor nits. * Nits identified by Roman in AD Review. o draft-ietf-lamps-cms-shake-10: * Updated IANA considerations section to request for OID assignments. o draft-ietf-lamps-cms-shake-09: * Fixed minor text nit. * Updates in Sec Considerations section. o draft-ietf-lamps-cms-shake-08: * id-shake128-len and id-shake256-len were replaced with id- sha128 with 32 bytes output length and id-shake256 with 64 bytes output length. * Fixed a discrepancy between section 3 and 4.4 about the KMAC OIDs that have parameters as optional. o draft-ietf-lamps-cms-shake-07: * Small nit from Russ while in WGLC. o draft-ietf-lamps-cms-shake-06: Kampanakis & Dang Expires March 19, 2020 [Page 3] Internet-Draft SHAKEs in CMS September 2019 * Incorporated Eric's suggestion from WGLC. o draft-ietf-lamps-cms-shake-05: * Added informative references. * Updated ASN.1 so it compiles. * Updated IANA considerations. o draft-ietf-lamps-cms-shake-04: * Added RFC8174 reference and text. * Explicitly explained why RSASSA-PSS-params are omitted in section 4.2.1. * Simplified Public Keys section by removing redundant info from RFCs. o draft-ietf-lamps-cms-shake-03: * Removed paragraph suggesting KMAC to be used in generating k in Deterministic ECDSA. That should be RFC6979-bis. * Removed paragraph from Security Considerations that talks about randomness of k because we are using deterministic ECDSA. * Completed ASN.1 module and fixed KMAC ASN.1 based on Jim's feedback. * Text fixes. o draft-ietf-lamps-cms-shake-02: * Updates based on suggestions and clarifications by Jim. * Started ASN.1 module. o draft-ietf-lamps-cms-shake-01: * Significant reorganization of the sections to simplify the introduction, the new OIDs and their use in CMS. * Added new OIDs for RSASSA-PSS that hardcodes hash, salt and MGF, according the WG consensus. Kampanakis & Dang Expires March 19, 2020 [Page 4] Internet-Draft SHAKEs in CMS September 2019 * Updated Public Key section to use the new RSASSA-PSS OIDs and clarify the algorithm identifier usage. * Removed the no longer used SHAKE OIDs from section 3.1. o draft-ietf-lamps-cms-shake-00: * Various updates to title and section names. * Content changes filling in text and references. o draft-dang-lamps-cms-shakes-hash-00: * Initial version 2. Introduction The "Cryptographic Message Syntax (CMS)" [RFC5652] is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents. "Cryptographic Message Syntax (CMS) Algorithms" [RFC3370] defines the use of common cryptographic algorithms with CMS. This specification updates RFC3370 and describes the use of the SHAKE128 and SHAKE256 specified in [SHA3] as new hash functions in CMS. In addition, it describes the use of these functions with the RSASSA-PSS signature algorithm [RFC8017] and the Elliptic Curve Digital Signature Algorithm (ECDSA) [X9.62] with the CMS signed-data content type. In the SHA-3 family, two extendable-output functions (SHAKEs), SHAKE128 and SHAKE256, are defined. Four other hash function instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, are also defined but are out of scope for this document. A SHAKE is a variable length hash function defined as SHAKE(M, d) where the output is a d-bits-long digest of message M. The corresponding collision and second-preimage-resistance strengths for SHAKE128 are min(d/2,128) and min(d,128) bits, respectively (Appendix A.1 [SHA3]). And the corresponding collision and second-preimage-resistance strengths for SHAKE256 are min(d/2,256) and min(d,256) bits, respectively. In this specification we use d=256 (for SHAKE128) and d=512 (for SHAKE256). A SHAKE can be used in CMS as the message digest function (to hash the message to be signed) in RSASSA-PSS and ECDSA, message authentication code and as the mask generation function (MGF) in RSASSA-PSS. This specification describes the identifiers for SHAKEs to be used in CMS and their meaning. Kampanakis & Dang Expires March 19, 2020 [Page 5] Internet-Draft SHAKEs in CMS September 2019 2.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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Identifiers This section identifies eight new object identifiers (OIDs) for using SHAKE128 and SHAKE256 in CMS. Two object identifiers for SHAKE128 and SHAKE256 hash functions are defined in [shake-nist-oids] and we include them here for convenience. id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 12 } In this specification, when using the id-shake128 or id-shake256 algorithm identifiers, the parameters MUST be absent. That is, the identifier SHALL be a SEQUENCE of one component, the OID. [I-D.ietf-lamps-pkix-shake] [ EDNOTE: Update reference with the RFC when it is published. ] defines two identifiers for RSASSA-PSS signatures using SHAKEs which we include here for convenience. id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 } The same RSASSA-PSS algorithm identifiers can be used for identifying public keys and signatures. [I-D.ietf-lamps-pkix-shake] [ EDNOTE: Update reference with the RFC when it is published. ] also defines two algorithm identifiers of ECDSA signatures using SHAKEs which we include here for convenience. Kampanakis & Dang Expires March 19, 2020 [Page 6] Internet-Draft SHAKEs in CMS September 2019 id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 } The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be absent. That is, each identifier SHALL be a SEQUENCE of one component, the OID. Two object identifiers for KMACs using SHAKE128 and SHAKE256 as defined in by the National Institute of Standards and Technology (NIST) in [shake-nist-oids] and we include them here for convenience. id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 19 } id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 20 } The parameters for id-KmacWithSHAKE128 and id-KmacWithSHAKE256 are OPTIONAL. Section 4.1, Section 4.2.1, Section 4.2.2 and Section 4.4 specify the required output length for each use of SHAKE128 or SHAKE256 in message digests, RSASSA-PSS, ECDSA and KMAC. 4. Use in CMS 4.1. Message Digests The id-shake128 and id-shake256 OIDs (Section 3) can be used as the digest algorithm identifiers located in the SignedData, SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm fields in CMS [RFC5652]. The OID encoding MUST omit the parameters field and the output length of SHAKE128 or SHAKE256 as the message digest MUST be 32 or 64 bytes, respectively. The digest values are located in the DigestedData field and the Message Digest authenticated attribute included in the signedAttributes of the SignedData signerInfo. In addition, digest values are input to signature algorithms. The digest algorithm MUST be the same as the message hash algorithms used in signatures. Kampanakis & Dang Expires March 19, 2020 [Page 7] Internet-Draft SHAKEs in CMS September 2019 4.2. Signatures In CMS, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData content type and countersignature attribute. Signature values are located in the SignerInfo signature field of SignedData content type and countersignature attribute. Conforming implementations that process RSASSA-PSS and ECDSA with SHAKE signatures when processing CMS data MUST recognize the corresponding OIDs specified in Section 3. When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus or ECDSA curve order SHOULD be chosen in line with the SHAKE output length. Refer to Section 6 for more details. 4.2.1. RSASSA-PSS Signatures The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is used, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- PSS-params that are used to define the algorithms and inputs to the algorithm. This specification does not use parameters because the hash, mask generation algorithm, trailer and salt are embedded in the OID definition. The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same: both SHAKE128 or both SHAKE256. The output length of the hash algorithm which hashes the message SHALL be 32 (for SHAKE128) or 64 bytes (for SHAKE256). The mask generation function takes an octet string of variable length and a desired output length as input, and outputs an octet string of the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be used natively as the MGF function, instead of the MGF1 algorithm that uses the hash function in multiple iterations as specified in Section B.2.1 of [RFC8017]. In other words, the MGF is defined as the SHAKE128 or SHAKE256 with input being the mgfSeed for id-RSASSA- PSS- SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is the seed from which mask is generated, an octet string [RFC8017]. As explained in Step 9 of section 9.1.1 of [RFC8017], the output length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS- SHAKE256, respectively. Thus when SHAKE is used as the MGF, the Kampanakis & Dang Expires March 19, 2020 [Page 8] Internet-Draft SHAKEs in CMS September 2019 SHAKE output length maskLen is (8*emLen - 264) or (8*emLen - 520) bits, respectively. For example, when RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, respectively. The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField MUST be 1, which represents the trailer field with hexadecimal value 0xBC [RFC8017]. 4.2.2. ECDSA Signatures The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 (specified in Section 3) algorithm identifier appears, the respective SHAKE function is used as the hash. The encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ecdsa-with-shake128 or id- ecdsa-with-shake256. For simplicity and compliance with the ECDSA standard specification, the output length of the hash function must be explicitly determined. The output length for SHAKE128 or SHAKE256 used in ECDSA MUST be 32 or 64 bytes, respectively. Conforming CA implementations that generate ECDSA with SHAKE signatures in certificates or CRLs SHOULD generate such signatures with a deterministically generated, non-random k in accordance with all the requirements specified in [RFC6979]. They MAY also generate such signatures in accordance with all other recommendations in [X9.62] or [SEC1] if they have a stated policy that requires conformance to those standards. Those standards have not specified SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 with output length being 32 and 64 octets, respectively can be used instead of 256 and 512-bit output hash algorithms such as SHA256 and SHA512. 4.3. Public Keys In CMS, the signer's public key algorithm identifiers are located in the OriginatorPublicKey's algorithm attribute. The conventions and encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers are as specified in Section 2.3 of [RFC3279], Section 3.1 of [RFC4055] and Section 2.1 of [RFC5480]. Traditionally, the rsaEncryption object identifier is used to identify RSA public keys. The rsaEncryption object identifier Kampanakis & Dang Expires March 19, 2020 [Page 9] Internet-Draft SHAKEs in CMS September 2019 continues to identify the public key when the RSA private key owner does not wish to limit the use of the public key exclusively to RSASSA-PSS with SHAKEs. When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, the AlgorithmIdentifier for RSASSA-PSS defined in Section 3 SHOULD be used as the algorithm attribute in the OriginatorPublicKey sequence. Conforming client implementations that process RSASSA-PSS with SHAKE public keys in CMS message MUST recognize the corresponding OIDs in Section 3. Conforming implementations MUST specify and process the algorithms explicitly by using the OIDs specified in Section 3 when encoding ECDSA with SHAKE public keys in CMS messages. The identifier parameters, as explained in Section 3, MUST be absent. 4.4. Message Authentication Codes KMAC message authentication code (KMAC) is specified in [SP800-185]. In CMS, KMAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field. The KMAC values are located in the AuthenticatedData mac field. When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 OID is used as the MAC algorithm identifier, the parameters field is optional (absent or present). If absent, the SHAKE256 output length used in KMAC is 32 or 64 bytes, respectively, and the customization string is an empty string by default. Conforming implementations that process KMACs with the SHAKEs when processing CMS data MUST recognize these identifiers. When calculating the KMAC output, the variable N is 0xD2B282C2, S is an empty string, and L, the integer representing the requested output length in bits, is 256 or 512 for KmacWithSHAKE128 or KmacWithSHAKE256, respectively, in this specification. 5. IANA Considerations One object identifier for the ASN.1 module in Appendix A was requested for the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) registry: +---------+----------------------+--------------------+ | Decimal | Description | References | +---------+----------------------+--------------------+ | 70 | CMSAlgsForSHAKE-2019 | [EDNOTE: THIS RFC] | +---------+----------------------+--------------------+ Kampanakis & Dang Expires March 19, 2020 [Page 10] Internet-Draft SHAKEs in CMS September 2019 6. Security Considerations This document updates [RFC3370]. The security considerations section of that document applies to this specification as well. NIST has defined appropriate use of the hash functions in terms of the algorithm strengths and expected time frames for secure use in Special Publications (SPs) [SP800-78-4] and [SP800-107]. These documents can be used as guides to choose appropriate key sizes for various security scenarios. SHAKE128 with output length of 32 bytes offers 128-bits of collision and preimage resistance. Thus, SHAKE128 OIDs in this specification are RECOMMENDED with 2048 (112-bit security) or 3072-bit (128-bit security) RSA modulus or curves with group order of 256-bits (128-bit security). SHAKE256 with 64 bytes output length offers 256-bits of collision and preimage resistance. Thus, the SHAKE256 OIDs in this specification are RECOMMENDED with 4096-bit RSA modulus or higher or curves with group order of at least 512 bits such as NIST Curve P-521 (256-bit security). Note that we recommended 4096-bit RSA because we would need 15360-bit modulus for 256-bits of security which is impractical for today's technology. When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, therefore the content could originate from any one of the parties. 7. Acknowledgements This document is based on Russ Housley's draft [I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions by SHAKE128 and SHAKE256 as the LAMPS WG agreed. The authors would like to thank Russ Housley for his guidance and very valuable contributions with the ASN.1 module. Valuable feedback was also provided by Eric Rescorla. 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, . Kampanakis & Dang Expires March 19, 2020 [Page 11] Internet-Draft SHAKEs in CMS September 2019 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, . [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, . [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, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SHA3] National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard - Permutation- Based Hash and Extendable-Output Functions", FIPS PUB 202, August 2015. [SP800-185] National Institute of Standards and Technology, "SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash. NIST SP 800-185", December 2016, . 8.2. Informative References [I-D.housley-lamps-cms-sha3-hash] Housley, R., "Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS)", draft-housley- lamps-cms-sha3-hash-00 (work in progress), March 2017. Kampanakis & Dang Expires March 19, 2020 [Page 12] Internet-Draft SHAKEs in CMS September 2019 [I-D.ietf-lamps-pkix-shake] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs", draft-ietf-lamps-pkix- shake-15 (work in progress), July 2019. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2002, . [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, . [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, . [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 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, . [SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", May 2009, . [shake-nist-oids] National Institute of Standards and Technology, "Computer Security Objects Register", October 2017, . Kampanakis & Dang Expires March 19, 2020 [Page 13] Internet-Draft SHAKEs in CMS September 2019 [SP800-107] National Institute of Standards and Technology (NIST), "SP800-107: Recommendation for Applications Using Approved Hash Algorithms", May 2014, . [SP800-78-4] National Institute of Standards and Technology (NIST), "SP800-78-4: Cryptographic Algorithms and Key Sizes for Personal Identity Verification", May 2014, . [X9.62] American National Standard for Financial Services (ANSI), "X9.62-2005 Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA)", November 2005. Appendix A. ASN.1 Module This appendix includes the ASN.1 modules for SHAKEs in CMS. This module includes some ASN.1 from other standards for reference. CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-shakes-2019(70) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL; IMPORTS DIGEST-ALGORITHM, MAC-ALGORITHM, SMIME-CAPS 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) } RSAPublicKey, rsaEncryption, id-ecPublicKey FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-algorithms2008-02(56) } sa-rsassapssWithSHAKE128, sa-rsassapssWithSHAKE256, Kampanakis & Dang Expires March 19, 2020 [Page 14] Internet-Draft SHAKEs in CMS September 2019 sa-ecdsaWithSHAKE128, sa-ecdsaWithSHAKE256 FROM PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-shakes-2019(94) } ; -- Message Digest Algorithms (mda-) -- used in SignedData, SignerInfo, DigestedData, -- and the AuthenticatedData digestAlgorithm -- fields in CMS -- -- This expands MessageAuthAlgs from [RFC5652] and -- MessageDigestAlgs in [RFC5753] -- -- MessageDigestAlgs DIGEST-ALGORITHM ::= { -- mda-shake128 | -- mda-shake256, -- ... -- } -- -- One-Way Hash Functions -- SHAKE128 mda-shake128 DIGEST-ALGORITHM ::= { IDENTIFIER id-shake128 -- with output length 32 bytes. } id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 11 } -- SHAKE256 mda-shake256 DIGEST-ALGORITHM ::= { IDENTIFIER id-shake256 -- with output length 64 bytes. } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 12 } -- -- Public key algorithm identifiers located in the -- OriginatorPublicKey's algorithm attribute in CMS. -- And Signature identifiers used in SignerInfo -- signatureAlgorithm field of SignedData content -- type and countersignature attribute in CMS. -- -- From RFC5280, for reference. Kampanakis & Dang Expires March 19, 2020 [Page 15] Internet-Draft SHAKEs in CMS September 2019 -- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } -- When the rsaEncryption algorithm identifier is used -- for a public key, the AlgorithmIdentifier parameters -- field MUST contain NULL. -- id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 } -- When the id-RSASSA-PSS-* algorithm identifiers are used -- for a public key or signature in CMS, the AlgorithmIdentifier -- parameters field MUST be absent. The message digest algorithm -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or -- 64 byte outout length, respectively. The mask generation -- function MUST be SHAKE128 or SHAKE256 with an output length -- of (8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, -- respectively, where n is the RSA modulus in bits. -- The RSASSA-PSS saltLength MUST be 32 or 64 bytes, respectively. -- The trailerField MUST be 1, which represents the trailer -- field with hexadecimal value 0xBC. Regardless of -- id-RSASSA-PSS-* or rsaEncryption being used as the -- AlgorithmIdentifier of the OriginatorPublicKey, the RSA -- public key MUST be encoded using the RSAPublicKey type. -- From RFC4055, for reference. -- RSAPublicKey ::= SEQUENCE { -- modulus INTEGER, -- -- n -- publicExponent INTEGER } -- -- e id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 } -- When the id-ecdsa-with-shake* algorithm identifiers are -- used in CMS, the AlgorithmIdentifier parameters field -- MUST be absent and the signature algorithm should be -- deterministic ECDSA [RFC6979]. The message digest MUST -- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout -- length, respectively. In both cases, the ECDSA public key, -- MUST be encoded using the id-ecPublicKey type. Kampanakis & Dang Expires March 19, 2020 [Page 16] Internet-Draft SHAKEs in CMS September 2019 -- From RFC5480, for reference. -- id-ecPublicKey OBJECT IDENTIFIER ::= { -- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } -- The id-ecPublicKey parameters must be absent or present -- and are defined as -- ECParameters ::= CHOICE { -- namedCurve OBJECT IDENTIFIER -- -- -- implicitCurve NULL -- -- -- specifiedCurve SpecifiedECDomain -- } -- This expands SignatureAlgorithms from [RFC5912] -- -- SignatureAlgs SIGNATURE-ALGORITHM ::= { -- sa-rsassapssWithSHAKE128 | -- sa-rsassapssWithSHAKE256 | -- sa-ecdsaWithSHAKE128 | -- sa-ecdsaWithSHAKE256, -- ... -- } -- This expands MessageAuthAlgs from [RFC5652] and [RFC6268] -- -- Message Authentication (maca-) Algorithms -- used in AuthenticatedData macAlgorithm in CMS -- MessageAuthAlgs MAC-ALGORITHM ::= { maca-KMACwithSHAKE128 | maca-KMACwithSHAKE256, ... } -- This expands SMimeCaps from [RFC5911] -- SMimeCaps SMIME-CAPS ::= { -- sa-rsassapssWithSHAKE128.&smimeCaps | -- sa-rsassapssWithSHAKE256.&smimeCaps | -- sa-ecdsaWithSHAKE128.&smimeCaps | -- sa-ecdsaWithSHAKE256.&smimeCaps, maca-KMACwithSHAKE128.&smimeCaps | maca-KMACwithSHAKE256.&smimeCaps, ... } -- -- KMAC with SHAKE128 maca-KMACwithSHAKE128 MAC-ALGORITHM ::= { IDENTIFIER id-KMACWithSHAKE128 Kampanakis & Dang Expires March 19, 2020 [Page 17] Internet-Draft SHAKEs in CMS September 2019 PARAMS TYPE KMACwithSHAKE128-params ARE optional -- If KMACwithSHAKE128-params parameters are absent -- the SHAKE128 output length used in KMAC is 256 bits -- and the customization string is an empty string. IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE128} } id-KMACWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 19 } KMACwithSHAKE128-params ::= SEQUENCE { kMACOutputLength INTEGER DEFAULT 256, -- Output length in bits customizationString OCTET STRING DEFAULT ''H } -- KMAC with SHAKE256 maca-KMACwithSHAKE256 MAC-ALGORITHM ::= { IDENTIFIER id-KMACWithSHAKE256 PARAMS TYPE KMACwithSHAKE256-params ARE optional -- If KMACwithSHAKE256-params parameters are absent -- the SHAKE256 output length used in KMAC is 512 bits -- and the customization string is an empty string. IS-KEYED-MAC TRUE SMIME-CAPS {IDENTIFIED BY id-KMACWithSHAKE256} } id-KMACWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) 20 } KMACwithSHAKE256-params ::= SEQUENCE { kMACOutputLength INTEGER DEFAULT 512, -- Output length in bits customizationString OCTET STRING DEFAULT ''H } END Authors' Addresses Panos Kampanakis Cisco Systems Email: pkampana@cisco.com Kampanakis & Dang Expires March 19, 2020 [Page 18] Internet-Draft SHAKEs in CMS September 2019 Quynh Dang NIST 100 Bureau Drive Gaithersburg, MD 20899 Email: quynh.Dang@nist.gov Kampanakis & Dang Expires March 19, 2020 [Page 19] ./draft-ietf-ice-trickle-21.txt0000644000764400076440000022122613265005701015552 0ustar iustyiusty Network Working Group E. Ivov Internet-Draft Atlassian Intended status: Standards Track E. Rescorla Expires: October 17, 2018 RTFM, Inc. J. Uberti Google P. Saint-Andre Mozilla April 15, 2018 Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol draft-ietf-ice-trickle-21 Abstract This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication 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 October 17, 2018. Copyright Notice Copyright (c) 2018 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 Ivov, et al. Expires October 17, 2018 [Page 1] Internet-Draft Trickle ICE April 2018 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Determining Support for Trickle ICE . . . . . . . . . . . . . 6 4. Generating the Initial ICE Description . . . . . . . . . . . 7 5. Handling the Initial ICE Description and Generating the Initial ICE Response . . . . . . . . . . . . . . . . . . . . 7 6. Handling the Initial ICE Response . . . . . . . . . . . . . . 8 7. Forming Check Lists . . . . . . . . . . . . . . . . . . . . . 8 8. Performing Connectivity Checks . . . . . . . . . . . . . . . 8 9. Gathering and Conveying Newly Gathered Local Candidates . . . 9 10. Pairing Newly Gathered Local Candidates . . . . . . . . . . . 10 11. Receiving Trickled Candidates . . . . . . . . . . . . . . . . 11 12. Inserting Trickled Candidate Pairs into a Check List . . . . 12 13. Generating an End-of-Candidates Indication . . . . . . . . . 16 14. Receiving an End-of-Candidates Indication . . . . . . . . . . 17 15. Subsequent Exchanges and ICE Restarts . . . . . . . . . . . . 18 16. Half Trickle . . . . . . . . . . . . . . . . . . . . . . . . 18 17. Preserving Candidate Order while Trickling . . . . . . . . . 19 18. Requirements for Using Protocols . . . . . . . . . . . . . . 20 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 20. Security Considerations . . . . . . . . . . . . . . . . . . . 21 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 22.1. Normative References . . . . . . . . . . . . . . . . . . 22 22.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 23 Appendix B. Interaction with ICE Lite . . . . . . . . . . . . . 25 Appendix C. Changes from Earlier Versions . . . . . . . . . . . 26 C.1. Changes from draft-ietf-ice-trickle-20 . . . . . . . . . 26 C.2. Changes from draft-ietf-ice-trickle-19 . . . . . . . . . 26 C.3. Changes from draft-ietf-ice-trickle-18 . . . . . . . . . 26 C.4. Changes from draft-ietf-ice-trickle-17 . . . . . . . . . 27 C.5. Changes from draft-ietf-ice-trickle-16 . . . . . . . . . 27 C.6. Changes from draft-ietf-ice-trickle-15 . . . . . . . . . 27 C.7. Changes from draft-ietf-ice-trickle-14 . . . . . . . . . 27 C.8. Changes from draft-ietf-ice-trickle-13 . . . . . . . . . 27 C.9. Changes from draft-ietf-ice-trickle-12 . . . . . . . . . 27 C.10. Changes from draft-ietf-ice-trickle-11 . . . . . . . . . 28 Ivov, et al. Expires October 17, 2018 [Page 2] Internet-Draft Trickle ICE April 2018 C.11. Changes from draft-ietf-ice-trickle-10 . . . . . . . . . 28 C.12. Changes from draft-ietf-ice-trickle-09 . . . . . . . . . 28 C.13. Changes from draft-ietf-ice-trickle-08 . . . . . . . . . 28 C.14. Changes from draft-ietf-ice-trickle-07 . . . . . . . . . 28 C.15. Changes from draft-ietf-ice-trickle-06 . . . . . . . . . 28 C.16. Changes from draft-ietf-ice-trickle-05 . . . . . . . . . 28 C.17. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 29 C.18. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 29 C.19. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 29 C.20. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 29 C.21. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 29 C.22. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 29 C.23. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 30 C.24. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 30 C.25. Changes from draft-rescorla-01 . . . . . . . . . . . . . 31 C.26. Changes from draft-rescorla-00 . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction The Interactive Connectivity Establishment (ICE) protocol [rfc5245bis] describes how an ICE agent gathers candidates, exchanges candidates with a peer ICE agent, and creates candidate pairs. Once the pairs have been gathered, the ICE agent will perform connectivity checks, and eventually nominate and select pairs that will be used for sending and receiving data within a communication session. Following the procedures in [rfc5245bis] can lead to somewhat lengthy establishment times for communication sessions, because candidate gathering often involves querying STUN servers [RFC5389] and allocating relayed candidates using TURN servers [RFC5766]. Although many ICE procedures can be completed in parallel, the pacing requirements from [rfc5245bis] still need to be followed. This document defines "Trickle ICE", a supplementary mode of ICE operation in which candidates can be exchanged incrementally as soon as they become available (and simultaneously with the gathering of other candidates). Connectivity checks can also start as soon as candidate pairs have been created. Because Trickle ICE enables candidate gathering and connectivity checks to be done in parallel, the method can considerably accelerate the process of establishing a communication session. This document also defines how to discover support for Trickle ICE, how the procedures in [rfc5245bis] are modified or supplemented when using Trickle ICE, and how a Trickle ICE agent can interoperate with an ICE agent compliant to [rfc5245bis]. Ivov, et al. Expires October 17, 2018 [Page 3] Internet-Draft Trickle ICE April 2018 This document does not define any protocol-specific usage of Trickle ICE. Instead, protocol-specific details for Trickle ICE are defined in separate usage documents. Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip] (which defines usage with the Session Initiation Protocol (SIP) [RFC3261] and the Session Description Protocol [RFC3261]) and [XEP-0176] (which defines usage with XMPP [RFC6120]). However, some of the examples in the document use SDP and the offer/answer model [RFC3264] to explain the underlying concepts. The following diagram illustrates a successful Trickle ICE exchange with a using protocol that follows the offer/answer model: Alice Bob | Offer | |---------------------------------------------->| | Additional Candidates | |---------------------------------------------->| | Answer | |<----------------------------------------------| | Additional Candidates | |<----------------------------------------------| | Additional Candidates and Connectivity Checks | |<--------------------------------------------->| |<========== CONNECTION ESTABLISHED ===========>| Figure 1: Flow The main body of this document is structured to describe the behavior of Trickle ICE agents in roughly the order of operations and interactions during an ICE session: 1. Determining support for trickle ICE 2. Generating the initial ICE description 3. Handling the initial ICE description and generating the initial ICE response 4. Handling the initial ICE response 5. Forming check lists, pruning candidates, performing connectivity checks, etc. Ivov, et al. Expires October 17, 2018 [Page 4] Internet-Draft Trickle ICE April 2018 6. Gathering and conveying candidates after the initial ICE description and response 7. Handling inbound trickled candidates 8. Generating and handling the end-of-candidates indication 9. Handling ICE restarts There is quite a bit of operational experience with the technique behind Trickle ICE, going back as far as 2005 (when the XMPP Jingle extension defined a "dribble mode" as specified in [XEP-0176]); this document incorporates feedback from those who have implemented and deployed the technique over the years. 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]. This specification makes use of all terminology defined for Interactive Connectivity Establishment in [rfc5245bis]. In addition, it defines the following terms: Full Trickle: The typical mode of operation for Trickle ICE agents, in which the initial ICE description can include any number of candidates (even zero candidates) and does not need to include a full generation of candidates as in half trickle. Generation: All of the candidates conveyed within an ICE session. Half Trickle: A Trickle ICE mode of operation in which the initiator gathers a full generation of candidates strictly before creating and conveying the initial ICE description. Once conveyed, this candidate information can be processed by regular ICE agents, which do not require support for Trickle ICE. It also allows Trickle ICE capable responders to still gather candidates and perform connectivity checks in a non-blocking way, thus providing roughly "half" the advantages of Trickle ICE. The half trickle mechanism is mostly meant for use when the responder's support for Trickle ICE cannot be confirmed prior to conveying the initial ICE description. ICE Description: Any attributes related to the ICE session (not candidates) required to configure an ICE agent. These include but are not limited to the username fragment, password, and other attributes. Ivov, et al. Expires October 17, 2018 [Page 5] Internet-Draft Trickle ICE April 2018 Trickled Candidates: Candidates that a Trickle ICE agent conveys after conveying the initial ICE description or responding to the initial ICE description, but within the same ICE session. Trickled candidates can be conveyed in parallel with candidate gathering and connectivity checks. Trickling: The act of incrementally conveying trickled candidates. Empty Check List: A check list that initially does not contain any candidate pairs because they will be incrementally added as they are trickled. (This scenario does not arise with a regular ICE agent, because all candidate pairs are known when the agent creates the check list set). 3. Determining Support for Trickle ICE To fully support Trickle ICE, using protocols SHOULD incorporate one of the following mechanisms so that implementations can determine whether Trickle ICE is supported: 1. Provide a capabilities discovery method so that agents can verify support of Trickle ICE prior to initiating a session (XMPP's Service Discovery [XEP-0030] is one such mechanism). 2. Make support for Trickle ICE mandatory so that user agents can assume support. If a using protocol does not provide a method of determining ahead of time whether Trickle ICE is supported, agents can make use of the half trickle procedure described in Section 16. Prior to conveying the initial ICE description, agents that implement using protocols that support capabilities discovery can attempt to verify whether or not the remote party supports Trickle ICE. If an agent determines that the remote party does not support Trickle ICE, it MUST fall back to using regular ICE or abandon the entire session. Even if a using protocol does not include a capabilities discovery method, a user agent can provide an indication within the ICE description that it supports Trickle ICE by communicating an ICE option of 'trickle'. This token MUST be provided either at the session level or, if at the data stream level, for every data stream (an agent MUST NOT specify Trickle ICE support for some data streams but not others). Note: The encoding of the 'trickle' ICE option, and the message(s) used to carry it to the peer, are protocol specific; for instance, the encoding for the Session Description Protocol (SDP) [RFC4566] is defined in [I-D.ietf-mmusic-trickle-ice-sip]. Ivov, et al. Expires October 17, 2018 [Page 6] Internet-Draft Trickle ICE April 2018 Dedicated discovery semantics and half trickle are needed only prior to initiation of an ICE session. After an ICE session is established and Trickle ICE support is confirmed for both parties, either agent can use full trickle for subsequent exchanges (see also Section 15). 4. Generating the Initial ICE Description An ICE agent can start gathering candidates as soon as it has an indication that communication is imminent (e.g., a user interface cue or an explicit request to initiate a communication session). Unlike in regular ICE, in Trickle ICE implementations do not need to gather candidates in a blocking manner. Therefore, unless half trickle is being used, the user experience is improved if the initiating agent generates and transmits its initial ICE description as early as possible (thus enabling the remote party to start gathering and trickling candidates). An initiator MAY include any mix of candidates when conveying the initial ICE description. This includes the possibility of conveying all the candidates the initiator plans to use (as in half trickle), conveying only a publicly-reachable IP address (e.g., a candidate at a data relay that is known to not be behind a firewall), or conveying no candidates at all (in which case the initiator can obtain the responder's initial candidate list sooner and the responder can begin candidate gathering more quickly). For candidates included in the initial ICE description, the methods for calculating priorities and foundations, determining redundancy of candidates, and the like work just as in regular ICE [rfc5245bis]. 5. Handling the Initial ICE Description and Generating the Initial ICE Response When a responder receives the initial ICE description, it will first check if the ICE description or initiator indicates support for Trickle ICE as explained in Section 3. If not, the responder MUST process the initial ICE description according to regular ICE procedures [rfc5245bis] (or, if no ICE support is detected at all, according to relevant processing rules for the using protocol, such as offer/answer processing rules [RFC3264]). However, if support for Trickle ICE is confirmed, a responder will automatically assume support for regular ICE as well. If the initial ICE description indicates support for Trickle ICE, the responder will determine its role and start gathering and prioritizing candidates; while doing so, it will also respond by conveying an initial ICE response, so that both the initiator and the responder can form check lists and begin connectivity checks. Ivov, et al. Expires October 17, 2018 [Page 7] Internet-Draft Trickle ICE April 2018 A responder can respond to the initial ICE description at any point while gathering candidates. The initial ICE response MAY contain any set of candidates, including all candidates or no candidates. (The benefit of including no candidates is to convey the initial ICE response as quickly as possible, so that both parties can consider the ICE session to be under active negotiation as soon as possible.) As noted in Section 3, in using protocols that use SDP the initial ICE response can indicate support for Trickle ICE by including a token of "trickle" in the ice-options attribute. 6. Handling the Initial ICE Response When processing the initial ICE response, the initiator follows regular ICE procedures to determine its role, after which it forms check lists (Section 7) and performs connectivity checks (Section 8). 7. Forming Check Lists According to regular ICE procedures [rfc5245bis], in order for candidate pairing to be possible and for redundant candidates to be pruned, the candidates would need to be provided in the initial ICE description and initial ICE response. By contrast, under Trickle ICE check lists can be empty until candidates are conveyed or received. Therefore a Trickle ICE agent handles check list formation and candidate pairing in a slightly different way than a regular ICE agent: the agent still forms the check lists, but it populates a given check list only after it actually has candidate pairs for that check list. Every check list is initially placed in the Running state, even if the check list is empty (this is consistent with Section 6.1.2.1 of [rfc5245bis]). 8. Performing Connectivity Checks As specified in [rfc5245bis], whenever timer Ta fires, only check lists in the Running state will be picked when scheduling connectivity checks for candidate pairs. Therefore, a Trickle ICE agent MUST keep each check list in the Running state as long as it expects candidate pairs to be incrementally added to the check list. After that, the check list state is set according to the procedures in [rfc5245bis]. Whenever timer Ta fires and an empty check list is picked, no action is performed for the list. Without waiting for timer Ta to expire again, the agent selects the next check list in the Running state, in accordance with Section 6.1.4.2 of [rfc5245bis]. Ivov, et al. Expires October 17, 2018 [Page 8] Internet-Draft Trickle ICE April 2018 Section 7.2.5.3.3 of [rfc5245bis] requires that agents update check lists and timer states upon completing a connectivity check transaction. During such an update, regular ICE agents would set the state of a check list to Failed if both of the following two conditions are satisfied: o all of the pairs in the check list are either in the Failed state or Succeeded state; and o there is not a pair in the valid list for each component of the data stream. With Trickle ICE, the above situation would often occur when candidate gathering and trickling are still in progress, even though it is quite possible that future checks will succeed. For this reason, Trickle ICE agents add the following conditions to the above list: o all candidate gathering has completed and the agent is not expecting to discover any new local candidates; and o the remote agent has conveyed an end-of-candidates indication for that check list as described in Section 13. 9. Gathering and Conveying Newly Gathered Local Candidates After Trickle ICE agents have conveyed initial ICE descriptions and initial ICE responses, they will most likely continue gathering new local candidates as STUN, TURN, and other non-host candidate gathering mechanisms begin to yield results. Whenever an agent discovers such a new candidate it will compute its priority, type, foundation, and component ID according to regular ICE procedures. The new candidate is then checked for redundancy against the existing list of local candidates. If its transport address and base match those of an existing candidate, it will be considered redundant and will be ignored. This would often happen for server reflexive candidates that match the host addresses they were obtained from (e.g., when the latter are public IPv4 addresses). Contrary to regular ICE, Trickle ICE agents will consider the new candidate redundant regardless of its priority. Next the agent "trickles" the newly discovered candidate(s) to the remote agent. The actual delivery of the new candidates is handled by a using protocol such as SIP or XMPP. Trickle ICE imposes no restrictions on the way this is done (e.g., some using protocols might choose not to trickle updates for server reflexive candidates and instead rely on the discovery of peer reflexive ones). Ivov, et al. Expires October 17, 2018 [Page 9] Internet-Draft Trickle ICE April 2018 When candidates are trickled, the using protocol MUST deliver each candidate (and any end-of-candidates indication as described in Section 13) to the receiving Trickle ICE implementation exactly once and in the same order it was conveyed. If the using protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. Also, candidate trickling needs to be correlated to a specific ICE session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored by the receiving party. For example, using protocols that signal candidates via SDP might include a Username Fragment value in the corresponding a=candidate line, such as: a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY Or, as another example, WebRTC implementations might include a Username Fragment in the JavaScript objects that represent candidates. Note: The using protocol needs to provide a mechanism for both parties to indicate and agree on the ICE session in force (as identified by the Username Fragment and Password combination) so that they have a consistent view of which candidates are to be paired. This is especially important in the case of ICE restarts (see Section 15). Note: A using protocol might prefer not to trickle server reflexive candidates to entities that are known to be publicly accessible and where sending a direct STUN binding request is likely to reach the destination faster than the trickle update that travels through the signaling path. 10. Pairing Newly Gathered Local Candidates As a Trickle ICE agent gathers local candidates, it needs to form candidate pairs; this works as described in the ICE specification [rfc5245bis], with the following provisos: 1. A Trickle ICE agent MUST NOT pair a local candidate until it has been trickled to the remote party. 2. Once the agent has conveyed the local candidate to the remote party, the agent checks if any remote candidates are currently known for this same stream and component. If not, the agent Ivov, et al. Expires October 17, 2018 [Page 10] Internet-Draft Trickle ICE April 2018 merely adds the new candidate to the list of local candidates (without pairing it). 3. Otherwise, if the agent has already learned of one or more remote candidates for this stream and component, it attempts to pair the new local candidate as described in the ICE specification [rfc5245bis]. 4. If a newly formed pair has a local candidate whose type is server reflexive, the agent MUST replace the local candidate with its base before completing the relevant redundancy tests. 5. The agent prunes redundant pairs by following the rules in Section 6.1.2.4 of [rfc5245bis], but checks existing pairs only if they have a state of Waiting or Frozen; this avoids removal of pairs for which connectivity checks are in flight (a state of In- Progress) or for which connectivity checks have already yielded a definitive result (a state of Succeeded or Failed). 6. If after the relevant redundancy tests the check list where the pair is to be added already contains the maximum number of candidate pairs (100 by default as per [rfc5245bis]), the agent SHOULD discard any pairs in the Failed state to make room for the new pair. If there are no such pairs, the agent SHOULD discard a pair with a lower priority than the new pair in order to make room for the new pair, until the number of pairs is equal to the maximum number of pairs. This processing is consistent with Section 6.1.2.5 of [rfc5245bis]. 11. Receiving Trickled Candidates At any time during an ICE session, a Trickle ICE agent might receive new candidates from the remote agent, from which it will attempt to form a candidate pair; this works as described in the ICE specification [rfc5245bis], with the following provisos: 1. The agent checks if any local candidates are currently known for this same stream and component. If not, the agent merely adds the new candidate to the list of remote candidates (without pairing it). 2. Otherwise, if the agent has already gathered one or more local candidates for this stream and component, it attempts to pair the new remote candidate as described in the ICE specification [rfc5245bis]. Ivov, et al. Expires October 17, 2018 [Page 11] Internet-Draft Trickle ICE April 2018 3. If a newly formed pair has a local candidate whose type is server reflexive, the agent MUST replace the local candidate with its base before completing the redundancy check in the next step. 4. The agent prunes redundant pairs as described below, but checks existing pairs only if they have a state of Waiting or Frozen; this avoids removal of pairs for which connectivity checks are in flight (a state of In-Progress) or for which connectivity checks have already yielded a definitive result (a state of Succeeded or Failed). A. If the agent finds a redundancy between two pairs and one of those pairs contains a newly received remote candidate whose type is peer reflexive, the agent SHOULD discard the pair containing that candidate, set the priority of the existing pair to the priority of the discarded pair, and re-sort the check list. (This policy helps to eliminate problems with remote peer reflexive candidates for which a STUN binding request is received before signaling of the candidate is trickled to the receiving agent, such as a different view of pair priorities between the local agent and the remote agent, since the same candidate could be perceived as peer reflexive by one agent and as server reflexive by the other agent.) B. The agent then applies the rules defined in Section 6.1.2.4 of [rfc5245bis]. 5. If after the relevant redundancy tests the check list where the pair is to be added already contains the maximum number of candidate pairs (100 by default as per [rfc5245bis]), the agent SHOULD discard any pairs in the Failed state to make room for the new pair. If there are no such pairs, the agent SHOULD discard a pair with a lower priority than the new pair in order to make room for the new pair, until the number of pairs is equal to the maximum number of pairs. This processing is consistent with Section 6.1.2.5 of [rfc5245bis]. 12. Inserting Trickled Candidate Pairs into a Check List After a local agent has trickled a candidate and formed a candidate pair from that local candidate (Section 9), or after a remote agent has received a trickled candidate and formed a candidate pair from that remote candidate (Section 11), a Trickle ICE agent adds the new candidate pair to a check list as defined in this section. As an aid to understanding the procedures defined in this section, consider the following tabular representation of all check lists in Ivov, et al. Expires October 17, 2018 [Page 12] Internet-Draft Trickle ICE April 2018 an agent (note that initially for one of the foundations, i.e., f5, there are no candidate pairs): +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | F | F | F | | | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | F | F | F | F | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | F | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | F | | | | | +-----------------+------+------+------+------+------+ Figure 2: Example of Check List State Each row in the table represents a component for a given data stream (e.g., s1 and s2 might be the RTP and RTCP components for audio) and thus a single check list in the check list set. Each column represents one foundation. Each cell represents one candidate pair. In the tables shown in this section, "F" stands for "frozen", "W" stands for "waiting", and "S" stands for "succeeded"; in addition, "^^" is used to notate newly-added candidate pairs. When an agent commences ICE processing, in accordance with Section 6.1.2.6 of [rfc5245bis], for each foundation it will unfreeze the pair with the lowest component ID and, if the component IDs are equal, with the highest priority (this is the topmost candidate pair in every column). This initial state is shown in the following table. Ivov, et al. Expires October 17, 2018 [Page 13] Internet-Draft Trickle ICE April 2018 +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | W | W | W | | | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | F | F | F | W | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | F | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | F | | | | | +-----------------+------+------+------+------+------+ Figure 3: Initial Check List State Then, as the checks proceed (see Section 7.2.5.4 of [rfc5245bis]), for each pair that enters the Succeeded state (denoted here by "S"), the agent will unfreeze all pairs for all data streams with the same foundation (e.g., if the pair in column 1, row 1 succeeds then the agent will unfreeze the pair in column 1, rows 2, 3, and 4). +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 4: Check List State with Succeeded Candidate Pair Trickle ICE preserves all of these rules as they apply to "static" check list sets. This implies that if a Trickle ICE agent were to begin connectivity checks with all of its pairs already present, the way that pair states change is indistinguishable from that of a regular ICE agent. Of course, the major difference with Trickle ICE is that check list sets can be dynamically updated because candidates can arrive after connectivity checks have started. When this happens, an agent sets the state of the newly formed pair as described below. Ivov, et al. Expires October 17, 2018 [Page 14] Internet-Draft Trickle ICE April 2018 Rule 1: If the newly formed pair has the lowest component ID and, if the component IDs are equal, the highest priority of any candidate pair for this foundation (i.e., if it is the topmost pair in the column), set the state to Waiting. For example, this would be the case if the newly formed pair were placed in column 5, row 1. This rule is consistent with Section 6.1.2.6 of [rfc5245bis]. +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | ^W^ | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 5: Check List State with Newly Formed Pair, Rule 1 Rule 2: If there is at least one pair in the Succeeded state for this foundation, set the state to Waiting. For example, this would be the case if the pair in column 5, row 1 succeeded and the newly formed pair were placed in column 5, row 2. This rule is consistent with Section 7.2.5.3.3 of [rfc5245bis]. +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | S | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | ^W^ | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 6: Check List State with Newly Formed Pair, Rule 2 Rule 3: In all other cases, set the state to Frozen. For example, this would be the case if the newly formed pair were placed in column 3, row 3. Ivov, et al. Expires October 17, 2018 [Page 15] Internet-Draft Trickle ICE April 2018 +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | S | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | W | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | ^F^ | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 7: Check List State with Newly Formed Pair, Rule 3 13. Generating an End-of-Candidates Indication Once all candidate gathering is completed or expires for an ICE session associated with a specific data stream, the agent will generate an "end-of-candidates" indication for that session and convey it to the remote agent via the signaling channel. Although the exact form of the indication depends on the using protocol, the indication MUST specify the generation (Username Fragment and Password combination) so that an agent can correlate the end-of- candidates indication with a particular ICE session. The indication can be conveyed in the following ways: o As part of an initiation request (which would typically be the case with the initial ICE description for half trickle) o Along with the last candidate an agent can send for a stream o As a standalone notification (e.g., after STUN Binding requests or TURN Allocate requests to a server time out and the agent is no longer actively gathering candidates) Conveying an end-of-candidates indication in a timely manner is important in order to avoid ambiguities and speed up the conclusion of ICE processing. In particular: o A controlled Trickle ICE agent SHOULD convey an end-of-candidates indication after it has completed gathering for a data stream, unless ICE processing terminates before the agent has had a chance to complete gathering. o A controlling agent MAY conclude ICE processing prior to conveying end-of-candidates indications for all streams. However, it is RECOMMENDED for a controlling agent to convey end-of-candidates Ivov, et al. Expires October 17, 2018 [Page 16] Internet-Draft Trickle ICE April 2018 indications whenever possible for the sake of consistency and to keep middleboxes and controlled agents up-to-date on the state of ICE processing. When conveying an end-of-candidates indication during trickling (rather than as a part of the initial ICE description or a response thereto), it is the responsibility of the using protocol to define methods for associating the indication with one or more specific data streams. An agent MAY also choose to generate an end-of-candidates indication before candidate gathering has actually completed, if the agent determines that gathering has continued for more than an acceptable period of time. However, an agent MUST NOT convey any more candidates after it has conveyed an end-of-candidates indication. When performing half trickle, an agent SHOULD convey an end-of- candidates indication together with its initial ICE description unless it is planning to potentially trickle additional candidates (e.g., in case the remote party turns out to support Trickle ICE). After an agent conveys the end-of-candidates indication, it will update the state of the corresponding check list as explained in Section 8. Past that point, an agent MUST NOT trickle any new candidates within this ICE session. Therefore, adding new candidates to the negotiation is possible only through an ICE restart (see Section 15). This specification does not override regular ICE semantics for concluding ICE processing. Therefore, even if end-of-candidates indications are conveyed, an agent will still need to go through pair nomination. Also, if pairs have been nominated for components and data streams, ICE processing MAY still conclude even if end-of- candidates indications have not been received for all streams. In all cases, an agent MUST NOT trickle any new candidates within an ICE session after nomination of a candidate pair as described in Section 8.1.1 of [rfc5245bis]. 14. Receiving an End-of-Candidates Indication Receiving an end-of-candidates indication enables an agent to update check list states and, in case valid pairs do not exist for every component in every data stream, determine that ICE processing has failed. It also enables an agent to speed up the conclusion of ICE processing when a candidate pair has been validated but it involves the use of lower-preference transports such as TURN. In such situations, an implementation MAY choose to wait and see if higher- priority candidates are received; in this case the end-of-candidates Ivov, et al. Expires October 17, 2018 [Page 17] Internet-Draft Trickle ICE April 2018 indication provides a notification that such candidates are not forthcoming. When an agent receives an end-of-candidates indication for a specific data stream, it will update the state of the relevant check list as per Section 8 (which might lead to some check lists being marked as Failed). If the check list is still in the Running state after the update, the agent will persist the fact that an end-of-candidates indication has been received and take it into account in future updates to the check list. After an agent has received an end-of-candidates indication, it MUST ignore any newly received candidates for that data stream or data session. 15. Subsequent Exchanges and ICE Restarts Before conveying an end-of-candidates indication, either agent MAY convey subsequent candidate information at any time allowed by the using protocol. When this happens, agents will use [rfc5245bis] semantics (e.g., checking of the Username Fragment and Password combination) to determine whether or not the new candidate information requires an ICE restart. If an ICE restart occurs, the agents can assume that Trickle ICE is still supported if support was determined previously, and thus can engage in Trickle ICE behavior as they would in an initial exchange of ICE descriptions where support was determined through a capabilities discovery method. 16. Half Trickle In half trickle, the initiator conveys the initial ICE description with a usable but not necessarily full generation of candidates. This ensures that the ICE description can be processed by a regular ICE responder and is mostly meant for use in cases where support for Trickle ICE cannot be confirmed prior to conveying the initial ICE description. The initial ICE description indicates support for Trickle ICE, so that the responder can respond with something less than a full generation of candidates and then trickle the rest. The initial ICE description for half trickle can contain an end-of- candidates indication, although this is not mandatory because if trickle support is confirmed then the initiator can choose to trickle additional candidates before it conveys an end-of-candidates indication. The half trickle mechanism can be used in cases where there is no way for an agent to verify in advance whether a remote party supports Ivov, et al. Expires October 17, 2018 [Page 18] Internet-Draft Trickle ICE April 2018 Trickle ICE. Because the initial ICE description contain a full generation of candidates, it can thus be handled by a regular ICE agent, while still allowing a Trickle ICE agent to use the optimization defined in this specification. This prevents negotiation from failing in the former case while still giving roughly half the Trickle ICE benefits in the latter. Use of half trickle is only necessary during an initial exchange of ICE descriptions. After both parties have received an ICE description from their peer, they can each reliably determine Trickle ICE support and use it for all subsequent exchanges (see Section 15). In some instances, using half trickle might bring more than just half the improvement in terms of user experience. This can happen when an agent starts gathering candidates upon user interface cues that the user will soon be initiating an interaction, such as activity on a keypad or the phone going off hook. This would mean that some or all of the candidate gathering could be completed before the agent actually needs to convey the candidate information. Because the responder will be able to trickle candidates, both agents will be able to start connectivity checks and complete ICE processing earlier than with regular ICE and potentially even as early as with full trickle. However, such anticipation is not always possible. For example, a multipurpose user agent or a WebRTC web page where communication is a non-central feature (e.g., calling a support line in case of a problem with the main features) would not necessarily have a way of distinguishing between call intentions and other user activity. In such cases, using full trickle is most likely to result in an ideal user experience. Even so, using half trickle would be an improvement over regular ICE because it would result in a better experience for responders. 17. Preserving Candidate Order while Trickling One important aspect of regular ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by both agents, so that any firewalls or NATs fronting the agents would whitelist both endpoints and allow all except for the first ("suicide") packets to go through. This is also important to unfreezing candidates at the right time. While not crucial, preserving this behavior in Trickle ICE is likely to improve ICE performance. To achieve this, when trickling candidates, agents SHOULD respect the order of components as reflected by their component IDs; that is, candidates for a given component SHOULD NOT be conveyed prior to Ivov, et al. Expires October 17, 2018 [Page 19] Internet-Draft Trickle ICE April 2018 candidates for a component with a lower ID number within the same foundation. In addition, candidates SHOULD be paired, following the procedures in Section 12, in the same order they are conveyed. For example, the following SDP description contains two components (RTP and RTCP) and two foundations (host and server reflexive): v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 10.0.1.1 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 5000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx raddr 10.0.1.1 rport 8998 a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx raddr 10.0.1.1 rport 8998 For this candidate information the RTCP host candidate would not be conveyed prior to the RTP host candidate. Similarly the RTP server reflexive candidate would be conveyed together with or prior to the RTCP server reflexive candidate. 18. Requirements for Using Protocols In order to fully enable the use of Trickle ICE, this specification defines the following requirements for using protocols. o A using protocol SHOULD provide a way for parties to advertise and discover support for Trickle ICE before an ICE session begins (see Section 3). o A using protocol MUST provide methods for incrementally conveying (i.e., "trickling") additional candidates after conveying the initial ICE description (see Section 9). o A using protocol MUST deliver each trickled candidate or end-of- candidates indication exactly once and in the same order it was conveyed (see Section 9). Ivov, et al. Expires October 17, 2018 [Page 20] Internet-Draft Trickle ICE April 2018 o A using protocol MUST provide a mechanism for both parties to indicate and agree on the ICE session in force (see Section 9). o A using protocol MUST provide a way for parties to communicate the end-of-candidates indication, which MUST specify the particular ICE session to which the indication applies (see Section 13). 19. IANA Considerations IANA is requested to register the following ICE option in the "ICE Options" sub-registry of the "Interactive Connectivity Establishment (ICE) registry", following the procedures defined in [RFC6336]. ICE Option: trickle Contact: IESG, iesg@ietf.org Change control: IESG Description: An ICE option of "trickle" indicates support for incremental communication of ICE candidates. Reference: RFC XXXX 20. Security Considerations This specification inherits most of its semantics from [rfc5245bis] and as a result all security considerations described there apply to Trickle ICE. If the privacy implications of revealing host addresses on an endpoint device are a concern (see for example the discussion in [I-D.ietf-rtcweb-ip-handling] and in Section 19 of [rfc5245bis]), agents can generate ICE descriptions that contain no candidates and then only trickle candidates that do not reveal host addresses (e.g., relayed candidates). 21. Acknowledgements The authors would like to thank Bernard Aboba, Flemming Andreasen, Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco, Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin Thomson, Brandon Williams, and Dale Worley for their reviews and suggestions on improving this document. Sarah Banks, Roni Even, and David Mandelberg completed opsdir, genart, and security reviews, respectively. Thanks also to Ari Keranen and Peter Thatcher in their Ivov, et al. Expires October 17, 2018 [Page 21] Internet-Draft Trickle ICE April 2018 role as chairs, and Ben Campbell in his role as responsible Area Director. 22. References 22.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, . [rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-20 (work in progress), March 2018. 22.2. Informative References [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) usage for Trickle ICE", draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), February 2018. [I-D.ietf-rtcweb-ip-handling] Uberti, J. and G. Shieh, "WebRTC IP Address Handling Requirements", draft-ietf-rtcweb-ip-handling-06 (work in progress), March 2018. [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, . [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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . Ivov, et al. Expires October 17, 2018 [Page 22] Internet-Draft Trickle ICE April 2018 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [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, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [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, DOI 10.17487/RFC5766, April 2010, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, DOI 10.17487/RFC6336, July 2011, . [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- Andre, "XEP-0030: Service Discovery", XEP XEP-0030, June 2008. [XEP-0176] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP Transport Method", XEP XEP-0176, June 2009. Appendix A. Interaction with Regular ICE The ICE protocol was designed to be flexible enough to work in and adapt to as many network environments as possible. Despite that flexibility, ICE as specified in [rfc5245bis] does not by itself support trickle ICE. This section describes how trickling of candidates interacts with ICE. Ivov, et al. Expires October 17, 2018 [Page 23] Internet-Draft Trickle ICE April 2018 [rfc5245bis] describes the conditions required to update check lists and timer states while an ICE agent is in the Running state. These conditions are verified upon transaction completion and one of them stipulates that: If there is not a pair in the valid list for each component of the data stream, the state of the check list is set to Failed. This could be a problem and cause ICE processing to fail prematurely in a number of scenarios. Consider the following case: 1. Alice and Bob are both located in different networks with Network Address Translation (NAT). Alice and Bob themselves have different address but both networks use the same private internet block (e.g., the "20-bit block" 172.16/12 specified in [RFC1918]). 2. Alice conveys to Bob the candidate 172.16.0.1 which also happens to correspond to an existing host on Bob's network. 3. Bob creates a check list consisting solely of 172.16.0.1 and starts checks. 4. These checks reach the host at 172.16.0.1 in Bob's network, which responds with an ICMP "port unreachable" error; per [rfc5245bis] Bob marks the transaction as Failed. At this point the check list only contains Failed candidates and the valid list is empty. This causes the data stream and potentially all ICE processing to fail, even though if Trickle ICE agents could subsequently convey candidates that would cause previously empty check lists to become non-empty. A similar race condition would occur if the initial ICE description from Alice contain only candidates that can be determined as unreachable from any of the candidates that Bob has gathered (e.g., this would be the case if Bob's candidates only contain IPv4 addresses and the first candidate that he receives from Alice is an IPv6 one). Another potential problem could arise when a non-trickle ICE implementation initiates an interaction with a Trickle ICE implementation. Consider the following case: 1. Alice's client has a non-Trickle ICE implementation. 2. Bob's client has support for Trickle ICE. Ivov, et al. Expires October 17, 2018 [Page 24] Internet-Draft Trickle ICE April 2018 3. Alice and Bob are behind NATs with address-dependent filtering [RFC4787]. 4. Bob has two STUN servers but one of them is currently unreachable. After Bob's agent receives Alice's initial ICE description it would immediately start connectivity checks. It would also start gathering candidates, which would take a long time because of the unreachable STUN server. By the time Bob's answer is ready and conveyed to Alice, Bob's connectivity checks might have failed: until Alice gets Bob's answer, she won't be able to start connectivity checks and punch holes in her NAT. The NAT would hence be filtering Bob's checks as originating from an unknown endpoint. Appendix B. Interaction with ICE Lite The behavior of ICE lite agents that are capable of Trickle ICE does not require any particular rules other than those already defined in this specification and [rfc5245bis]. This section is hence provided only for informational purposes. An ICE lite agent would generate candidate information as per [rfc5245bis] and would indicate support for Trickle ICE. Given that the candidate information will contain a full generation of candidates, it would also be accompanied by an end-of-candidates indication. When performing full trickle, a full ICE implementation could convey the initial ICE description or response thereto with no candidates. After receiving a response that identifies the remote agent as an ICE lite implementation, the initiator can choose to not trickle any additional candidates. The same is also true in the case when the ICE lite agent initiates the interaction and the full ICE agent is the responder. In these cases the connectivity checks would be enough for the ICE lite implementation to discover all potentially useful candidates as peer reflexive. The following example illustrates one such ICE session using SDP syntax: Ivov, et al. Expires October 17, 2018 [Page 25] Internet-Draft Trickle ICE April 2018 ICE Lite Bob Agent | Offer (a=ice-lite a=ice-options:trickle) | |---------------------------------------------->| | |no cand | Answer (a=ice-options:trickle) |trickling |<----------------------------------------------| | Connectivity Checks | |<--------------------------------------------->| peer rflx| | cand disco| | |<========== CONNECTION ESTABLISHED ===========>| Figure 8: Example In addition to reducing signaling traffic this approach also removes the need to discover STUN bindings or make TURN allocations, which can considerably lighten ICE processing. Appendix C. Changes from Earlier Versions Note to the RFC Editor: please remove this section prior to publication as an RFC. C.1. Changes from draft-ietf-ice-trickle-20 o Slight corrections to hanlding of peer reflexive candidates. o Wordsmithing in a few sections. C.2. Changes from draft-ietf-ice-trickle-19 o Further clarified handling of remote peer reflexive candidates. o To improve readibility, renamed and restructured some sections and subsections, and modified some wording. C.3. Changes from draft-ietf-ice-trickle-18 o Cleaned up pairing and redundancy checking rules for newly discovered candidates per IESG feedback and WG discussion. o Improved wording in half trickle section. o Changed "not more than once" to "exactly once". Ivov, et al. Expires October 17, 2018 [Page 26] Internet-Draft Trickle ICE April 2018 o Changed NAT examples back to IPv4. C.4. Changes from draft-ietf-ice-trickle-17 o Simplified the rules for inserting a new pair in a check list. o Clarified it is not allowed to nominate a candidate pair after a pair has already been nominated (a.k.a. renomination or continuous nomination). o Removed some text that referenced older versions of rfc5245bis. o Removed some text that duplicated concepts and procedures specified in rfc5245bis. o Removed the ill-defined concept of stream order. o Shortened the introduction. C.5. Changes from draft-ietf-ice-trickle-16 o Made "ufrag" terminology consistent with 5245bis. o Applied in-order delivery rule to end-of-candidates indication. C.6. Changes from draft-ietf-ice-trickle-15 o Adjustments to address AD review feedback. C.7. Changes from draft-ietf-ice-trickle-14 o Minor modifications to track changes to ICE core. C.8. Changes from draft-ietf-ice-trickle-13 o Removed independent monitoring of check list "states" of frozen or active, since this is handled by placing a check list in the Running state defined in ICE core. C.9. Changes from draft-ietf-ice-trickle-12 o Specified that the end-of-candidates indication must include the generation (ufrag/pwd) to enable association with a particular ICE session. o Further editorial fixes to address WGLC feedback. Ivov, et al. Expires October 17, 2018 [Page 27] Internet-Draft Trickle ICE April 2018 C.10. Changes from draft-ietf-ice-trickle-11 o Editorial and terminological fixes to address WGLC feedback. C.11. Changes from draft-ietf-ice-trickle-10 o Minor editorial fixes. C.12. Changes from draft-ietf-ice-trickle-09 o Removed immediate unfreeze upon Fail. o Specified MUST NOT regarding ice-options. o Changed terminology regarding initial ICE parameters to avoid implementer confusion. C.13. Changes from draft-ietf-ice-trickle-08 o Reinstated text about in-order processing of messages as a requirement for signaling protocols. o Added IANA registration template for ICE option. o Corrected Case 3 rule in Section 8.1.1 to ensure consistency with regular ICE rules. o Added tabular representations to Section 8.1.1 in order to illustrate the new pair rules. C.14. Changes from draft-ietf-ice-trickle-07 o Changed "ICE description" to "candidate information" for consistency with 5245bis. C.15. Changes from draft-ietf-ice-trickle-06 o Addressed editorial feedback from chairs' review. o Clarified terminology regarding generations. C.16. Changes from draft-ietf-ice-trickle-05 o Rewrote the text on inserting a new pair into a check list. Ivov, et al. Expires October 17, 2018 [Page 28] Internet-Draft Trickle ICE April 2018 C.17. Changes from draft-ietf-ice-trickle-04 o Removed dependency on SDP and offer/answer model. o Removed mentions of aggressive nomination, since it is deprecated in 5245bis. o Added section on requirements for signaling protocols. o Clarified terminology. o Addressed various WG feedback. C.18. Changes from draft-ietf-ice-trickle-03 o Provided more detailed description of unfreezing behavior, specifically how to replace pre-existing peer-reflexive candidates with higher-priority ones received via trickling. C.19. Changes from draft-ietf-ice-trickle-02 o Adjusted unfreezing behavior when there are disparate foundations. C.20. Changes from draft-ietf-ice-trickle-01 o Changed examples to use IPv6. C.21. Changes from draft-ietf-ice-trickle-00 o Removed dependency on SDP (which is to be provided in a separate specification). o Clarified text about the fact that a check list can be empty if no candidates have been sent or received yet. o Clarified wording about check list states so as not to define new states for "Active" and "Frozen" because those states are not defined for check lists (only for candidate pairs) in ICE core. o Removed open issues list because it was out of date. o Completed a thorough copy edit. C.22. Changes from draft-mmusic-trickle-ice-02 o Addressed feedback from Rajmohan Banavi and Brandon Williams. Ivov, et al. Expires October 17, 2018 [Page 29] Internet-Draft Trickle ICE April 2018 o Clarified text about determining support and about how to proceed if it can be determined that the answering agent does not support Trickle ICE. o Clarified text about check list and timer updates. o Clarified when it is appropriate to use half trickle or to send no candidates in an offer or answer. o Updated the list of open issues. C.23. Changes from draft-ivov-01 and draft-mmusic-00 o Added a requirement to trickle candidates by order of components to avoid deadlocks in the unfreezing algorithm. o Added an informative note on peer-reflexive candidates explaining that nothing changes for them semantically but they do become a more likely occurrence for Trickle ICE. o Limit the number of pairs to 100 to comply with 5245. o Added clarifications on the non-importance of how newly discovered candidates are trickled/sent to the remote party or if this is done at all. o Added transport expectations for trickled candidates as per Dale Worley's recommendation. C.24. Changes from draft-ivov-00 o Specified that end-of-candidates is a media level attribute which can of course appear as session level, which is equivalent to having it appear in all m-lines. Also made end-of-candidates optional for cases such as aggressive nomination for controlled agents. o Added an example for ICE lite and Trickle ICE to illustrate how, when talking to an ICE lite agent doesn't need to send or even discover any candidates. o Added an example for ICE lite and Trickle ICE to illustrate how, when talking to an ICE lite agent doesn't need to send or even discover any candidates. o Added wording that explicitly states ICE lite agents have to be prepared to receive no candidates over signaling and that they Ivov, et al. Expires October 17, 2018 [Page 30] Internet-Draft Trickle ICE April 2018 should not freak out if this happens. (Closed the corresponding open issue). o It is now mandatory to use MID when trickling candidates and using m-line indexes is no longer allowed. o Replaced use of 0.0.0.0 to IP6 :: in order to avoid potential issues with RFC2543 SDP libraries that interpret 0.0.0.0 as an on- hold operation. Also changed the port number here from 1 to 9 since it already has a more appropriate meaning. (Port change suggested by Jonathan Lennox). o Closed the Open Issue about use about what to do with cands received after end-of-cands. Solution: ignore, do an ICE restart if you want to add something. o Added more terminology, including trickling, trickled candidates, half trickle, full trickle, o Added a reference to the SIP usage for Trickle ICE as requested at the Boston interim. C.25. Changes from draft-rescorla-01 o Brought back explicit use of Offer/Answer. There are no more attempts to try to do this in an O/A independent way. Also removed the use of ICE Descriptions. o Added SDP specification for trickled candidates, the trickle option and 0.0.0.0 addresses in m-lines, and end-of-candidates. o Support and Discovery. Changed that section to be less abstract. As discussed in IETF85, the draft now says implementations and usages need to either determine support in advance and directly use trickle, or do half trickle. Removed suggestion about use of discovery in SIP or about letting implementing protocols do what they want. o Defined Half Trickle. Added a section that says how it works. Mentioned that it only needs to happen in the first o/a (not necessary in updates), and added Jonathan's comment about how it could, in some cases, offer more than half the improvement if you can pre-gather part or all of your candidates before the user actually presses the call button. o Added a short section about subsequent offer/answer exchanges. Ivov, et al. Expires October 17, 2018 [Page 31] Internet-Draft Trickle ICE April 2018 o Added a short section about interactions with ICE Lite implementations. o Added two new entries to the open issues section. C.26. Changes from draft-rescorla-00 o Relaxed requirements about verifying support following a discussion on MMUSIC. o Introduced ICE descriptions in order to remove ambiguous use of 3264 language and inappropriate references to offers and answers. o Removed inappropriate assumption of adoption by RTCWEB pointed out by Martin Thomson. Authors' Addresses Emil Ivov Atlassian 303 Colorado Street, #1600 Austin, TX 78701 USA Phone: +1-512-640-3000 Email: eivov@atlassian.com Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 678 2350 Email: ekr@rtfm.com Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Phone: +1 857 288 8888 Email: justin@uberti.name Ivov, et al. Expires October 17, 2018 [Page 32] Internet-Draft Trickle ICE April 2018 Peter Saint-Andre Mozilla P.O. Box 787 Parker, CO 80134 USA Phone: +1 720 256 6756 Email: stpeter@mozilla.com URI: https://www.mozilla.com/ Ivov, et al. Expires October 17, 2018 [Page 33] ./draft-ietf-mmusic-rfc4566bis-37.txt0000644000764400076440000040437013523361001016454 0ustar iustyiusty Network Working Group A. Begen Internet-Draft Networked Media Obsoletes: 4566 (if approved) P. Kyzivat Intended status: Standards Track Expires: February 10, 2020 C. Perkins University of Glasgow M. Handley UCL August 9, 2019 SDP: Session Description Protocol draft-ietf-mmusic-rfc4566bis-37 Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. 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 https://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 10, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Begen, et al. Expires February 10, 2020 [Page 1] Internet-Draft SDP August 2019 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 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 4.1. Media and Transport Information . . . . . . . . . . . . . 7 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 4.3. Obtaining Further Information about a Session . . . . . . 8 4.4. Internationalization . . . . . . . . . . . . . . . . . . 8 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 26 Begen, et al. Expires February 10, 2020 [Page 2] Internet-Draft SDP August 2019 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 28 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 31 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 32 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 8.2. Registration of SDP Parameters with IANA . . . . . . . . 42 8.2.1. Registration Procedure . . . . . . . . . . . . . . . 42 8.2.2. Media Types ("media") . . . . . . . . . . . . . . . . 43 8.2.3. Transport Protocols ("proto") . . . . . . . . . . . . 43 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 48 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 48 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 49 8.3. Encryption Key Access Methods (OBSOLETE) . . . . . . . . 50 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 12.1. Normative References . . . . . . . . . . . . . . . . . . 57 12.2. Informative References . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 1. Introduction When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description -- it does not incorporate a transport Begen, et al. Expires February 10, 2020 [Page 3] Internet-Draft SDP August 2019 protocol, and it is intended to use different transport protocols as appropriate, including the Session Announcement Protocol (SAP) [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time Streaming Protocol (RTSP) [RFC7826], electronic mail [RFC5322] using the MIME extensions [RFC2045], and the Hypertext Transport Protocol (HTTP) [RFC7230]. SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negotiation of session content or media encodings: this is viewed as outside the scope of session description. This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are outlined in Section 10 of this memo. 2. Glossary of Terms The following terms are used in this document and have specific meaning within the context of this document. Session Description: A well-defined format for conveying sufficient information to discover and participate in a multimedia session. Media Description: A Media Description contains the information needed for one party to establish an application layer network protocol connection to another party. It starts with an "m=" line and is terminated by either the next "m=" line or by the end of the session description. Session-level Section: This refers to the parts that are not media descriptions, whereas the session description refers to the whole body that includes the session-level section and the media description(s). The terms "multimedia conference" and "multimedia session" are used in this document as defined in [RFC7656]. The terms "session" and "multimedia session" are used interchangeably in this document. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Begen, et al. Expires February 10, 2020 [Page 4] Internet-Draft SDP August 2019 3. Examples of SDP Usage 3.1. Session Initiation The Session Initiation Protocol (SIP) [RFC3261] is an application- layer control protocol for creating, modifying, and terminating sessions such as Internet multimedia conferences, Internet telephone calls, and multimedia distribution. The SIP messages used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types [RFC6838]. These session descriptions are commonly formatted using SDP. When used with SIP, the offer/answer model [RFC3264] provides a limited framework for negotiation using SDP. 3.2. Streaming Media The Real Time Streaming Protocol (RTSP) [RFC7826], 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. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters. 3.3. Email and the World Wide Web Alternative means of conveying session descriptions include electronic mail and the World Wide Web (WWW). For both email and WWW distribution, the media type "application/sdp" is used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner. Note that descriptions of multicast sessions sent only via email or the WWW do not have the property that the receiver of a session description can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope. 3.4. Multicast Session Announcement In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically sends packets containing a description of the session to a well-known multicast group. These advertisements are received by other session directories such that potential remote Begen, et al. Expires February 10, 2020 [Page 5] Internet-Draft SDP August 2019 participants can use the session description to start the tools required to participate in the session. One protocol used to implement such a distributed directory is the SAP [RFC2974]. SDP provides the recommended session description format for such session announcements. 4. Requirements and Recommendations The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use with Internet protocols, although it is sufficiently general that it can describe multimedia conferences in other network environments. Media streams can be many-to-many. Sessions need not be continually active. Thus far, multicast-based sessions on the Internet have differed from many other forms of conferencing in that anyone receiving the traffic can join the session (unless the session traffic is encrypted). In such an environment, SDP serves two primary purposes. It is a means to communicate the existence of a session, and it is a means to convey sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant. An SDP description includes the following: o Session name and purpose o Time(s) the session is active o The media comprising the session o Information needed to receive those media (addresses, ports, formats, etc.) As resources necessary to participate in a session may be limited, some additional information may also be desirable: o Information about the bandwidth to be used by the session o Contact information for the person responsible for the session In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys) and to announce the resources to be used to any non- participants that may need to know. (This latter feature is Begen, et al. Expires February 10, 2020 [Page 6] Internet-Draft SDP August 2019 primarily useful when SDP is used with a multicast session announcement protocol.) 4.1. Media and Transport Information An SDP description includes the following media information: o The type of media (video, audio, etc.) o The media transport protocol (RTP/UDP/IP, H.320, etc.) o The format of the media (H.261 video, MPEG video, etc.) In addition to media format and transport protocol, SDP conveys address and port details. For an IP multicast session, these comprise: o The multicast group address for media o The transport port for media This address and port are the destination address and destination port of the multicast stream, whether being sent, received, or both. For unicast IP sessions, the following are conveyed: o The remote address for media o The remote transport port for media The semantics of the address and port depend on context. Typically, this SHOULD be the remote address and remote port to which media is to be sent or received. Details may differ based on the network type, address type, protocol and media specified, and whether the SDP is being distributed as an advertisement or negotiated in an offer/ answer [RFC3264] exchange. (E.g., Some address types or protocols may not have a notion of port.) Deviating from typical behavior should be done cautiously since this complicates implementations (including middleboxes that must parse the addresses to open Network Address Translation (NAT) or firewall pinholes). 4.2. Timing Information Sessions may be either bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey: o An arbitrary list of start and stop times bounding the session Begen, et al. Expires February 10, 2020 [Page 7] Internet-Draft SDP August 2019 o For each bound, repeat times such as "every Wednesday at 10am for one hour" This timing information is globally consistent, irrespective of local time zone or daylight saving time (see Section 5.9). 4.3. Obtaining Further Information about a Session A session description could convey enough information to decide whether or not to participate in a session. SDP may include additional pointers in the form of Uniform Resource Identifiers (URIs) [RFC3986] for more information about the session. (Note that use of URIs to indicate remote resources is subject to the security considerations from [RFC3986].) 4.4. Internationalization The SDP specification recommends the use of the ISO 10646 character set in the UTF-8 encoding [RFC3629] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as [ISO.8859-1.1998] to be used when desired. Internationalization only applies to free-text sub-fields (session name and background information), and not to SDP as a whole. 5. SDP Specification An SDP description is denoted by the media type "application/sdp" (See Section 8). An SDP description is entirely textual. SDP field names and attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but textual fields and attribute values MAY use the full ISO 10646 character set in UTF-8 encoding, or some other character set defined by the "a=charset:" attribute. Field and attribute values that use the full UTF-8 character set are never directly compared, hence there is no requirement for UTF-8 normalization. The textual form, as opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance portability, to enable a variety of transports to be used, and to allow flexible, text-based toolkits to be used to generate and process session descriptions. However, since SDP may be used in environments where the maximum permissible size of a session description is limited, the encoding is deliberately compact. Also, since descriptions may be transported via very unreliable means or damaged by an intermediate caching server, the encoding was designed with strict order and formatting rules so that most errors would result in malformed session descriptions that could be detected easily and discarded. Begen, et al. Expires February 10, 2020 [Page 8] Internet-Draft SDP August 2019 An SDP description consists of a number of lines of text of the form: = where is exactly one case-significant character and is structured text whose format depends on . In general, is either a number of sub-fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace separators are not used on either side of the "=" sign, however, the value can contain a leading whitespace as part of its syntax, i.e., that whitespace is part of the value. An SDP description MUST conform to the syntax defined in Section 9. The following is an overview of the syntax: An SDP description consists of a session-level section followed by zero or more media descriptions. The session-level section starts with a "v=" line and continues to the first media description (or the end of the whole description, whichever comes first). Each media description starts with an "m=" line and continues to the next media description or the end of the whole session description, whichever comes first. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. Some lines in each description are required and some are optional, but when present must appear in exactly the order given here. (The fixed order greatly enhances error detection and allows for a simple parser). In the following overview optional items are marked with a "*". Begen, et al. Expires February 10, 2020 [Page 9] Internet-Draft SDP August 2019 Session description v= (protocol version) o= (originator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information -- not required if included in all media descriptions) b=* (zero or more bandwidth information lines) One or more time descriptions: ("t=", "r=" and "z=" lines; see below) k=* (obsolete) a=* (zero or more session attribute lines) Zero or more media descriptions Time description t= (time the session is active) r=* (zero or more repeat times) z=* (optional time zone offset line) Media description, if present m= (media name and transport address) i=* (media title) c=* (connection information -- optional if included at session level) b=* (zero or more bandwidth information lines) k=* (obsolete) a=* (zero or more media attribute lines) The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore or reject any session description that contains a type letter that it does not understand. The attribute mechanism ("a=" described below) is the primary means for extending SDP and tailoring it to particular applications or media. Some attributes (the ones listed in Section 6 of this memo) have a defined meaning, but others may be added on a media- or session-specific basis. (Attribute scopes in addition to media-specific and session-specific may also be defined in extensions to this document. E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore any attribute it doesn't understand. An SDP description may contain URIs that reference external content in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in some cases, making the session description non-self-contained. Begen, et al. Expires February 10, 2020 [Page 10] Internet-Draft SDP August 2019 The connection ("c=") information in the session-level section applies to all the media descriptions of that session unless overridden by connection information in the media description. For instance, in the example below, each audio media description behaves as if it were given a "c=IN IP4 198.51.100.1". An example SDP description is: v=0 o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1 s=Call to John Smith i=SDP Offer #1 u=http://www.jdoe.example.com/home.html e=Jane Doe p=+1 617 555-6011 c=IN IP4 198.51.100.1 t=0 0 m=audio 49170 RTP/AVP 0 m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 c=IN IP6 2001:db8::2 a=rtpmap:99 h263-1998/90000 Text-containing fields such as the session-name-field and information-field are octet strings that may contain any octet with the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a line, although parsers SHOULD be tolerant and also accept lines terminated with a single newline character. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 characters in UTF-8 encoding. When the "a=charset" attribute is present the session-name-field, information-field, and some attribute fields are interpreted according to the selected character set. A session description can contain domain names in the "o=", "u=", "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply with [RFC1034] and [RFC1035]. Internationalized domain names (IDNs) MUST be represented using the ASCII Compatible Encoding (ACE) form defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or any other encoding (this requirement is for compatibility with [RFC2327] and other early SDP-related standards, which predate the development of internationalized domain names). Begen, et al. Expires February 10, 2020 [Page 11] Internet-Draft SDP August 2019 5.1. Protocol Version ("v=") v=0 The "v=" line (version-field) gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. 5.2. Origin ("o=") o= The "o=" line (origin-field) gives the originator of the session (her username and the address of the user's host) plus a session identifier and version number: is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user IDs. The MUST NOT contain spaces. is a numeric string such that the tuple of , , , , and forms a globally unique identifier for the session. The method of allocation is up to the creating tool, but a timestamp, in seconds since January 1, 1900 UTC, is recommended to ensure uniqueness. is a version number for this session description. Its usage is up to the creating tool, so long as is increased when a modification is made to the session description. Again, as with it is RECOMMENDED that a timestamp be used. is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8). is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined, but other values MAY be registered in the future (see Section 8). is an address of the machine from which the session was created. For an address type of IP4, this is either a fully qualified domain name of the machine or the dotted-decimal representation of an IP version 4 address of the machine. For an address type of IP6, this is either a fully qualified domain name of the machine or the address of the machine represented as Begen, et al. Expires February 10, 2020 [Page 12] Internet-Draft SDP August 2019 specified in Section 4 of [RFC5952]. For both IP4 and IP6, the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case a globally unique address MAY be substituted. In general, the "o=" line serves as a globally unique identifier for this version of the session description, and the sub-fields excepting the version, taken together identify the session irrespective of any modifications. For privacy reasons, it is sometimes desirable to obfuscate the username and IP address of the session originator. If this is a concern, an arbitrary and private MAY be chosen to populate the "o=" line, provided that these are selected in a manner that does not affect the global uniqueness of the field. 5.3. Session Name ("s=") s= The "s=" line (session-name-field) is the textual session name. There MUST be one and only one "s=" line per session description. The "s=" line MUST NOT be empty. If a session has no meaningful name, then "s= " or "s=-" (i.e., a single space or dash as the session name) is RECOMMENDED. If a session-level "a=charset" attribute is present, it specifies the character set used in the "s=" field. If a session-level "a=charset" attribute is not present, the "s=" field MUST contain ISO 10646 characters in UTF-8 encoding. 5.4. Session Information ("i=") i= The "i=" line (information-field) provides textual information about the session. There can be at most one session-level "i=" line per session description, and at most one "i=" line in each media description. Unless a media-level "i=" line is provided, the session-level "i=" line applies to that media description. If the "a=charset" attribute is present, it specifies the character set used in the "i=" line. If the "a=charset" attribute is not present, the "i=" line MUST contain ISO 10646 characters in UTF-8 encoding. At most one "i=" line can be used for each media description. In media definitions, "i=" lines are primarily intended for labelling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions. Begen, et al. Expires February 10, 2020 [Page 13] Internet-Draft SDP August 2019 The "i=" line is intended to provide a free-form human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata. 5.5. URI ("u=") u= The "u=" line (uri-field) provides a URI (Uniform Resource Identifier) [RFC3986]. The URI should be a pointer to additional human readable information about the session. This line is OPTIONAL. No more than one "u=" line is allowed per session description. 5.6. Email Address and Phone Number ("e=" and "p=") e= p= The "e=" line (email-field) and "p=" line (phone-field) specify contact information for the person responsible for the session. This is not necessarily the same person that created the session description. Inclusion of an email address or phone number is OPTIONAL. If an email address or phone number is present, it MUST be specified before the first media description. More than one email or phone line can be given for a session description. Phone numbers SHOULD be given in the form of an international public telecommunication number (see ITU-T Recommendation E.164 [E164]) preceded by a "+". Spaces and hyphens may be used to split up a phone-field to aid readability if desired. For example: p=+1 617 555-6011 Both email addresses and phone numbers can have an OPTIONAL free text string associated with them, normally giving the name of the person who may be contacted. This MUST be enclosed in parentheses if it is present. For example: e=j.doe@example.com (Jane Doe) The alternative [RFC5322] name quoting convention is also allowed for both email addresses and phone numbers. For example: e=Jane Doe Begen, et al. Expires February 10, 2020 [Page 14] Internet-Draft SDP August 2019 The free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if the appropriate session-level "a=charset" attribute is set. 5.7. Connection Information ("c=") c= The "c=" line (connection-field) contains information necessary to establish a network connection. A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line and additional media- level "c=" line(s) per-media-description, in which case the media- level values override the session-level settings for the respective media. The first sub-field ("") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8). The second sub-field ("") is the address type. This allows SDP to be used for sessions that are not IP based. This memo only defines IP4 and IP6, but other values MAY be registered in the future (see Section 8). The third sub-field ("") is the connection address. Additional sub-fields MAY be added after the connection address depending on the value of the sub-field. When the is IP4 or IP6, the connection address is defined as follows: o If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source, data relay or data sink as determined by additional attribute-fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited. o Sessions using an IP4 multicast connection address MUST also have a time to live (TTL) value present in addition to the multicast address. The TTL and the address together define the scope with which multicast packets sent in this session will be sent. TTL Begen, et al. Expires February 10, 2020 [Page 15] Internet-Draft SDP August 2019 values MUST be in the range 0-255. Although the TTL MUST be specified, its use to scope multicast traffic is deprecated; applications SHOULD use an administratively scoped address instead. The TTL for the session is appended to the address using a slash as a separator. An example is: c=IN IP4 233.252.0.1/127 IP6 multicast does not use TTL scoping, and hence the TTL value MUST NOT be present for IP6 multicast. It is expected that IPv6 scoped addresses will be used to limit the scope of multimedia conferences. Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can choose the desired quality (and hence bandwidth) by only subscribing to a subset of these layers. Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning. This technique keeps unwanted traffic from sites only requiring certain levels of the hierarchy. For applications requiring multiple multicast groups, we allow the following notation to be used for the connection address: [/]/ If the number of addresses is not given, it is assumed to be one. Multicast addresses so assigned are contiguously allocated above the base address, so that, for example: c=IN IP4 233.252.0.1/127/3 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 are to be used with a TTL of 127. This is semantically identical to including multiple "c=" lines in a media description: c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.3/127 Similarly, an IPv6 example would be: c=IN IP6 ff00::db8:0:101/3 which is semantically equivalent to: Begen, et al. Expires February 10, 2020 [Page 16] Internet-Draft SDP August 2019 c=IN IP6 ff00::db8:0:101 c=IN IP6 ff00::db8:0:102 c=IN IP6 ff00::db8:0:103 (remembering that the TTL sub-field is not present in IP6 multicast). Multiple addresses or "c=" lines MAY be specified on a per media description basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. Multiple addresses or "c=" lines MUST NOT be specified at session level. The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses. 5.8. Bandwidth Information ("b=") b=: The OPTIONAL "b=" line (bandwidth-field) denotes the proposed bandwidth to be used by the session or media description. The is an alphanumeric modifier giving the meaning of the figure. Two values are defined in this specification, but other values MAY be registered in the future (see Section 8 and [RFC3556], [RFC3890]): CT If the bandwidth of a session is different from the bandwidth implicit from the scope, a "b=CT:..." line SHOULD be supplied for the session giving the proposed upper limit to the bandwidth used (the "conference total" bandwidth). Similarly, if the bandwidth of bundled media streams [I-D.ietf-mmusic-sdp-bundle-negotiation] in an "m=" line is different from the implicit value from the scope, a "b=CT:..." line SHOULD be supplied in the media level. The primary purpose of this is to give an approximate idea as to whether two or more sessions (or bundled media streams) can coexist simultaneously. Note that CT gives a total bandwidth figure for all the media at all endpoints. The Mux Category for CT is NORMAL. This is discussed in [I-D.ietf-mmusic-sdp-mux-attributes]. AS The bandwidth is interpreted to be application specific (it will be the application's concept of maximum bandwidth). Normally, this will coincide with what is set on the application's "maximum bandwidth" control if applicable. For RTP-based applications, AS gives the RTP "session bandwidth" as defined in Section 6.2 of [RFC3550]. Note that AS gives a bandwidth figure for a single Begen, et al. Expires February 10, 2020 [Page 17] Internet-Draft SDP August 2019 media at a single endpoint, although there may be many endpoints sending simultaneously. The Mux Category for AS is SUM. This is discussed in [I-D.ietf-mmusic-sdp-mux-attributes]. [RFC4566] defined an "X-" prefix for names. This was intended for experimental purposes only. For example: b=X-YZ:128 Use of the "X-" prefix is NOT RECOMMENDED. Instead new (non "X-" prefix) names SHOULD be defined, and then MUST be registered with IANA in the standard namespace. SDP parsers MUST ignore bandwidth-fields with unknown names. The names MUST be alphanumeric and, although no length limit is given, it is recommended that they be short. The is interpreted as kilobits per second by default (including the transport and network-layer but not the link-layer overhead). The definition of a new modifier MAY specify that the bandwidth is to be interpreted in some alternative unit (the "CT" and "AS" modifiers defined in this memo use the default units). 5.9. Time Active ("t=") t= A "t=" line (time-field) begins a time description that specifies the start and stop times for a session. Multiple time descriptions MAY be used if a session is active at multiple irregularly spaced times; each additional time description specifies additional periods of time for which the session will be active. If the session is active at regular repeat times, a repeat description, begun by an "r=" line (see below) can be included following the time-field -- in which case the time-field specifies the start and stop times of the entire repeat sequence. The following example specifies two active intervals: t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC The first and second sub-fields of the time-field give the start and stop times, respectively, for the session. These are the decimal representation of time values in seconds since January 1, 1900 UTC. To convert these values to UNIX time (UTC), subtract decimal 2208988800. Begen, et al. Expires February 10, 2020 [Page 18] Internet-Draft SDP August 2019 Some time representations will wrap in the year 2036. Because SDP uses an arbitrary length decimal representation, it does not have this issue. Implementations of SDP need to be prepared to handle these larger values. If the is set to zero, then the session is not bounded, though it will not become active until after the . If the is also zero, the session is regarded as permanent. User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult. The general assumption may be made, when displaying unbounded sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time or the session start time, whichever is the later. If behavior other than this is required, an end-time SHOULD be given and modified as appropriate when new information becomes available about when the session should really end. Permanent sessions may be shown to the user as never being active unless there are associated repeat times that state precisely when the session will be active. 5.10. Repeat Times ("r=") r= An"r=" line (repeat-field) specifies repeat times for a session. If needed to express complex schedules, multiple repeat-fields may be included. For example, if a session is active at 10am on Monday and 11am on Tuesday for one hour each week for three months, then the in the corresponding "t=" line would be the representation of 10am on the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 hours. The corresponding "t=" line stop time would be the representation of the end of the last session three months later. By default, all sub-fields are in seconds, so the "r=" and "t=" lines might be the following: t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC ; Tues 20-Mar-2018 12:00 UTC r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours To make the description more compact, times may also be given in units of days, hours, or minutes. The syntax for these is a number Begen, et al. Expires February 10, 2020 [Page 19] Internet-Draft SDP August 2019 immediately followed by a single case-sensitive character. Fractional units are not allowed -- a smaller unit should be used instead. The following unit specification characters are allowed: d - days (86400 seconds) h - hours (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness) Thus, the above repeat-field could also have been written: r=7d 1h 0 25h Monthly and yearly repeats cannot be directly specified with a single SDP repeat time; instead, separate time-descriptions should be used to explicitly list the session times. 5.11. Time Zone Adjustment ("z=") z= .... A "z=" line (zone-field) is an optional modifier to the repeat-fields it immediately follows. It does not apply to any other fields. To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify offsets from the base time. This is required because different time zones change time at different times of day, different countries change to or from daylight saving time on different dates, and some countries do not have daylight saving time at all. Thus, in order to schedule a session that is at the same time winter and summer, it must be possible to specify unambiguously by whose time zone a session is scheduled. To simplify this task for receivers, we allow the sender to specify the time (represented as seconds since January 1, 1900 UTC) that a time zone adjustment happens and the offset from the time when the session was first scheduled. The "z=" line allows the sender to specify a list of these adjustment times and offsets from the base time. An example might be the following: Begen, et al. Expires February 10, 2020 [Page 20] Internet-Draft SDP August 2019 t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC ; Tues 18-Dec-2018 12:00 UTC r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, ; offset 1 hour, ; Sun 28-Oct-2018 2:00 UTC, ; no offset This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the onset of British Summer Time) the time base by which the session's repeat times are calculated is shifted back by 1 hour, and that at time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer Time) the session's original time base is restored. Adjustments are always relative to the specified start time -- they are not cumulative. If a session is likely to last several years, it is expected that the session description will be modified periodically rather than transmit several years' worth of adjustments in one session description. 5.12. Encryption Keys ("k=") k= k=: The "k=" line (key-field) is obsolete and MUST NOT be used. It is included in this document for legacy reasons. One MUST NOT include a "k=" line in an SDP, and MUST discard it if it is received in an SDP. 5.13. Attributes ("a=") a= a=: Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. (Attribute scopes in addition to media- and session- level may also be defined in extensions to this document. E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) A media description may contain any number of "a=" lines (attribute- fields) that are media description specific. These are referred to as "media-level" attributes and add information about the media description. Attribute-fields can also be added before the first media description; these "session-level" attributes convey additional information that applies to the session as a whole rather than to individual media descriptions. Begen, et al. Expires February 10, 2020 [Page 21] Internet-Draft SDP August 2019 Attribute-fields may be of two forms: o A property attribute is simply of the form "a=". These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session. An example might be "a=recvonly". o A value attribute is of the form "a=:". For example, a whiteboard could have the value attribute "a=orient:landscape" Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular. Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Attribute values are octet strings, and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are to be interpreted as in ISO-10646 character set with UTF-8 encoding. Unlike other text fields, attribute values are NOT normally affected by the "charset" attribute as this would make comparisons against known values problematic. However, when an attribute is defined, it can be defined to be charset dependent, in which case its value should be interpreted in the session charset rather than in ISO-10646. Attributes MUST be registered with IANA (see Section 8). If an attribute is received that is not understood, it MUST be ignored by the receiver. 5.14. Media Descriptions ("m=") m= ... A session description may contain a number of media descriptions. Each media description starts with an "m=" line (media-field) and is terminated by either the next "m=" line or by the end of the session description. A media-field has several sub-fields: is the media type. This document defines the values "audio", "video", "text", "application", and "message". This list is extended by other memos and may be further extended by additional memos registering media types in the future (see Section 8). For example, [RFC6466] defined the "image" media type. Begen, et al. Expires February 10, 2020 [Page 22] Internet-Draft SDP August 2019 is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" line, and on the transport protocol defined in the sub-field of the media-field. Other ports used by the media application (such as the RTP Control Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example, "a=rtcp:" as defined in [RFC3605]). If non-contiguous ports are used or if they don't follow the parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute MUST be used. Applications that are requested to send media to a that is odd and where the "a=rtcp:" is present MUST NOT subtract 1 from the RTP port: that is, they MUST send the RTP to the port indicated in and send the RTCP to the port indicated in the "a=rtcp" attribute. For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=" line: m= / ... In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even-numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session, and the denoting the number of RTP sessions. For example: m=video 49170/2 RTP/AVP 31 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). This document does not include a mechanism for declaring hierarchically encoded streams using non-contiguous ports. (There is currently no attribute defined that can accomplish this. The "a=rtcp:" defined in [RFC3605] does not handle hierarchical encoding.) If a need arises to declare non-contiguous ports then it will be necessary to define a new attribute to do so. If multiple addresses are specified in the "c=" line and multiple ports are specified in the "m=" line, a one-to-one mapping from port to the corresponding address is implied. For example: Begen, et al. Expires February 10, 2020 [Page 23] Internet-Draft SDP August 2019 m=video 49170/2 RTP/AVP 31 c=IN IP4 233.252.0.1/127/2 would imply that address 233.252.0.1 is used with ports 49170 and 49171, and address 233.252.0.2 is used with ports 49172 and 49173. The mapping is similar if multiple addresses are specified using multiple "c=" lines. For example: m=video 49170/2 RTP/AVP 31 c=IN IP6 ff00::db8:0:101 c=IN IP6 ff00::db8:0:102 would imply that address ff00::db8:0:101 is used with ports 49170 and 49171, and address ff00::db8:0:102 is used with ports 49172 and 49173. This document gives no meaning to assigning the same media address to multiple media-descriptions. Doing so does not implicitly group those media-descriptions in any way. An explicit grouping framework (for example, [RFC5888]) should instead be used to express the intended semantics. For instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. is the transport protocol. The meaning of the transport protocol is dependent on the address type sub-field in the relevant "c=" line. Thus a "c=" line with an address type of IP4 indicates that the transport protocol runs over IPv4. The following transport protocols are defined, but may be extended through registration of new protocols with IANA (see Section 8): * udp: denotes that the data is transported directly in UDP with no additional framing. * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] running over UDP. * RTP/SAVP: denotes the Secure Real-time Transport Protocol [RFC3711] running over UDP. The main reason to specify the transport protocol in addition to the media format is that the same standard media formats may be carried over different transport protocols even when the network protocol is the same -- a historical example is VAT (MBone's popular multimedia audio tool) Pulse Code Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP PCM audio. In Begen, et al. Expires February 10, 2020 [Page 24] Internet-Draft SDP August 2019 addition, relays and monitoring tools that are transport-protocol- specific but format-independent are possible. is a media format description. The fourth and any subsequent sub-fields describe the format of the media. The interpretation of the media format depends on the value of the sub-field. If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session. For dynamic payload type assignments the "a=rtpmap:" attribute (see Section 6) SHOULD be used to map from an RTP payload type number to a media encoding name that identifies the payload format. The "a=fmtp:" attribute MAY be used to specify format parameters (see Section 6). If the sub-field is "udp" the sub-fields MUST reference a media type describing the format under the "audio", "video", "text", "application", or "message" top-level media types. The media type registration SHOULD define the packet format for use with UDP transport. For media using other transport protocols, the sub-field is protocol specific. Rules for interpretation of the sub- field MUST be defined when registering new protocols (see Section 8.2.2). Section 3 of [RFC4855] states that the payload format (encoding) names defined in the RTP Profile are commonly shown in upper case, while media subtype names are commonly shown in lower case. It also states that both of these names are case-insensitive in both places, similar to parameter names which are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute. 6. SDP Attributes The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8.2.4. Syntax is provided using ABNF [RFC7405] with some of the rules defined further in Section 9. Begen, et al. Expires February 10, 2020 [Page 25] Internet-Draft SDP August 2019 6.1. cat (category) Name: cat Value: cat-value Usage Level: session Charset Dependent: no Syntax: cat-value = category category = non-ws-string Example: a=cat:foo.bar This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. There is no central registry of categories. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received. 6.2. keywds (keywords) Name: keywds Value: keywds-value Usage Level: session Charset Dependent: yes Syntax: keywds-value = keywords keywords = text Example: a=keywds:SDP session description protocol Like the cat attribute, this was intended to assist identifying wanted sessions at the receiver. This allows a receiver to select interesting sessions based on keywords describing the purpose of the session; there is no central registry of keywords. Its value should Begen, et al. Expires February 10, 2020 [Page 26] Internet-Draft SDP August 2019 be interpreted in the charset specified for the session description if one is specified, or by default in ISO 10646/UTF-8. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received. 6.3. tool Name: tool Value: tool-value Usage Level: session Charset Dependent: no Syntax: tool-value = tool-name-and-version tool-name-and-version = text Example: a=tool:foobar V3.2 This gives the name and version number of the tool used to create the session description. 6.4. ptime (packet time) Name: ptime Value: ptime-value Usage Level: media Charset Dependent: no Syntax: ptime-value = non-zero-int-or-real Example: a=ptime:20 This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It should Begen, et al. Expires February 10, 2020 [Page 27] Internet-Draft SDP August 2019 not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetization of audio. 6.5. maxptime (maximum packet time) Name: maxptime Value: maxptime-value Usage Level: media Charset Dependent: no Syntax: maxptime-value = non-zero-int-or-real Example: a=maxptime:20 This gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. For frame-based codecs, the time SHOULD be an integer multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. Note that this attribute was introduced after [RFC2327], and non-updated implementations will ignore this attribute. 6.6. rtpmap Name: rtpmap Value: rtpmap-value Usage Level: media Charset Dependent: no Begen, et al. Expires February 10, 2020 [Page 28] Internet-Draft SDP August 2019 Syntax: rtpmap-value = payload-type SP encoding-name "/" clock-rate [ "/" encoding-params ] payload-type = zero-based-integer encoding-name = token clock-rate = integer encoding-params = channels channels = integer This attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. It also provides information on the clock rate and encoding parameters. Note that the payload type number is indicated in a 7-bit field, limiting the values to inclusively between 0 and 127. Although an RTP profile can make static assignments of payload type numbers to payload formats, it is more common for that assignment to be done dynamically using "a=rtpmap:" attributes. As an example of a static payload type, consider u-law PCM coded single-channel audio sampled at 8 kHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so there is no need for an "a=rtpmap:" attribute, and the media for such a stream sent to UDP port 49232 can be specified as: m=audio 49232 RTP/AVP 0 An example of a dynamic payload type is 16-bit linear encoded stereo audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP payload type 98 for this stream, additional information is required to decode it: m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 Up to one rtpmap attribute can be defined for each media format specified. Thus, we might have the following: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP. The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for encoding names, under Begen, et al. Expires February 10, 2020 [Page 29] Internet-Draft SDP August 2019 the top-level media type denoted in the "m=" line. In the example above, the media types are "audio/L8" and "audio/L16". For audio streams, encoding-params indicates the number of audio channels. This parameter is OPTIONAL and may be omitted if the number of channels is one, provided that no additional parameters are needed. For video streams, no encoding parameters are currently specified. Additional encoding parameters MAY be defined in the future, but codec-specific parameters SHOULD NOT be added. Parameters added to an "a=rtpmap:" attribute SHOULD only be those required for a session directory to make the choice of appropriate media to participate in a session. Codec-specific parameters should be added in other attributes (for example, "a=fmtp:"). Note: RTP audio formats typically do not include information about the number of samples per packet. If a non-default (as defined in the RTP Audio/Video Profile [RFC3551]) packetization is required, the "ptime" attribute is used as given above. 6.7. Media Direction Attributes At most one occurrence of recvonly, sendrecv, sendonly, or inactive MAY appear at session level, and at most one MAY appear in each media description. If any one of these appears in a media description then it applies for that media description. If none appear in a media description then the one from session level, if any, applies to that media description. If none of the media direction attributes is present at either session level or media level, "sendrecv" SHOULD be assumed as the default. Within the following SDP example, the "sendrecv" attribute applies to the first audio media and the "inactive" attribute applies to the others. Begen, et al. Expires February 10, 2020 [Page 30] Internet-Draft SDP August 2019 v=0 o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 s=- c=IN IP6 2001:db8::1 t=0 0 a=inactive m=audio 49170 RTP/AVP 0 a=sendrecv m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 6.7.1. recvonly (receive-only) Name: recvonly Value: Usage Level: session, media Charset Dependent: no Example: a=recvonly This specifies that the tools should be started in receive-only mode where applicable. Note that recvonly applies to the media only, not to any associated control protocol. An RTP-based system in recvonly mode MUST still send RTCP packets as described in [RFC3550] Section 6. 6.7.2. sendrecv (send-receive) Name: sendrecv Value: Usage Level: session, media Charset Dependent: no Example: a=sendrecv Begen, et al. Expires February 10, 2020 [Page 31] Internet-Draft SDP August 2019 This specifies that the tools should be started in send and receive mode. This is necessary for interactive multimedia conferences with tools that default to receive-only mode. 6.7.3. sendonly (send-only) Name: sendonly Value: Usage Level: session, media Charset Dependent: no Example: a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. 6.7.4. inactive Name: inactive Value: Usage Level: session, media Charset Dependent: no Example: a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive multimedia conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system MUST still send RTCP (if RTCP is used), even if started inactive. Begen, et al. Expires February 10, 2020 [Page 32] Internet-Draft SDP August 2019 6.8. orient (orientation) Name: orient Value: orient-value Usage Level: media Charset Dependent: no Syntax: orient-value = portrait / landscape / seascape portrait = %s"portrait" landscape = %s"landscape" seascape = %s"seascape" ; NOTE: These names are case-sensitive. Example: a=orient:portrait Normally this is only used for a whiteboard or presentation tool. It specifies the orientation of the workspace on the screen. Permitted values are "portrait", "landscape", and "seascape" (upside-down landscape). 6.9. type (conference type) Name: type Value: type-value Usage Level: session Charset Dependent: no Syntax: type-value = conference-type conference-type = broadcast / meeting / moderated / test / H332 broadcast = %s"broadcast" meeting = %s"meeting" moderated = %s"moderated" test = %s"test" H332 = %s"H332" ; NOTE: These names are case-sensitive. Begen, et al. Expires February 10, 2020 [Page 33] Internet-Draft SDP August 2019 Example: a=type:moderated This specifies the type of the multimedia conference. Allowed values are "broadcast", "meeting", "moderated", "test", and "H332". These values have implications for other options that are likely to be appropriate: o When "a=type:broadcast" is specified, "a=recvonly" is probably appropriate for those connecting. o When "a=type:meeting" is specified, "a=sendrecv" is likely to be appropriate. o "a=type:moderated" suggests the use of a floor control tool and that the media tools be started so as to mute new sites joining the multimedia conference. o Specifying "a=type:H332" indicates that this loosely coupled session is part of an H.332 session as defined in the ITU H.332 specification [ITU.H332.1998]. Media tools should be started using "a=recvonly". o Specifying "a=type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users. 6.10. charset (character set) Name: charset Value: charset-value Usage Level: session Charset Dependent: no Syntax: charset-value = This specifies the character set to be used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used. If a more compact representation is required, other character sets may be used. For example, the ISO 8859-1 is specified with the following SDP attribute: Begen, et al. Expires February 10, 2020 [Page 34] Internet-Draft SDP August 2019 a=charset:ISO-8859-1 The charset specified MUST be one of those registered in the IANA Character Sets registry (http://www.iana.org/assignments/character- sets), such as ISO-8859-1. The character set identifier is a string that MUST be compared against identifiers from the "Name" or "Preferred MIME Name" field of the registry using a case-insensitive comparison. If the identifier is not recognized or not supported, all strings that are affected by it SHOULD be regarded as octet strings. Charset-dependent fields MUST contain only sequences of bytes that are valid according to the definition of the selected character set. Furthermore, charset-dependent fields MUST NOT contain the bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). 6.11. sdplang (SDP language) Name: sdplang Value: sdplang-value Usage Level: session, media Charset Dependent: no Syntax: sdplang-value = Language-Tag ; Language-Tag defined in RFC5646 Example: a=sdplang:fr Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. As a session-level attribute, it specifies the language for the session description (not the language of the media). As a media- level attribute, it specifies the language for any media-level SDP information-field associated with that media (again not the language of the media), overriding any sdplang attributes specified at session level. In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple sesssion descriptions Begen, et al. Expires February 10, 2020 [Page 35] Internet-Draft SDP August 2019 SHOULD be sent describing the session, one in each language. However, this is not possible with all transport mechanisms, and so multiple sdplang attributes are allowed although NOT RECOMMENDED. The "sdplang" attribute value must be a single [RFC5646] language tag. An "sdplang" attribute SHOULD be specified when a session is distributed with sufficient scope to cross geographic boundaries, where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. 6.12. lang (language) Name: lang Value: lang-value Usage Level: session, media Charset Dependent: no Syntax: lang-value = Language-Tag ; Language-Tag defined in RFC5646 Example: a=lang:de Multiple lang attributes can be provided either at session or media level if the session or media has capabilities in more than one language, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred. As a session-level attribute, lang specifies a language capability for the session being described. As a media-level attribute, it specifies a language capability for that media, overriding any session-level language(s) specified. The "lang" attribute value must be a single [RFC5646] language tag. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of participants cannot be assumed, or where the session has capabilities in languages different from the locally assumed norm. The "lang" attribute is supposed to be used for setting the initial language(s) used in the session. Events during the session may Begen, et al. Expires February 10, 2020 [Page 36] Internet-Draft SDP August 2019 influence which language(s) are used, and the participants are not strictly bound to only use the declared languages. Most real-time use cases start with just one language used, while other cases involve a range of languages, e.g. an interpreted or subtitled session. When more than one 'lang' attribute is specified, the "lang" attribute itself does not provide any information about multiple languages being intended to be used during the session, or if the intention is to only select one of the languages. If needed, a new attribute can be defined and used to indicate such intentions. Without such semantics, it is assumed that for a negotiated session one of the declared languages will be selected and used. 6.13. framerate (frame rate) Name: framerate Value: framerate-value Usage Level: media Charset Dependent: no Syntax: framerate-value = non-zero-int-or-real Example: a=framerate:60 This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values are allowed. It is defined only for video media. 6.14. quality Name: quality Value: quality-value Usage Level: media Charset Dependent: no Begen, et al. Expires February 10, 2020 [Page 37] Internet-Draft SDP August 2019 Syntax: quality-value = zero-based-integer Example: a=quality:10 This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value is in the range 0 to 10, with the following suggested meaning: 10 - the best still-image quality the compression scheme can give. 5 - the default behavior given no quality suggestion. 0 - the worst still-image quality the codec designer thinks is still usable. 6.15. fmtp (format parameters) Name: fmtp Value: fmtp-value Usage Level: media Charset Dependent: no Syntax: fmtp-value = fmt SP format-specific-params format-specific-params = byte-string ; Notes: ; - The format parameters are media type parameters and ; need to reflect their syntax. Example: a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters, semicolon separated, may be any set of parameters required to be conveyed by SDP and given unchanged to the Begen, et al. Expires February 10, 2020 [Page 38] Internet-Draft SDP August 2019 media tool that will use this format. At most one instance of this attribute is allowed for each format. The fmtp attribute may be used to specify parameters for any protocol and format that defines use of such parameters. 7. Security Considerations SDP is frequently used with the Session Initiation Protocol [RFC3261] using the offer/answer model [RFC3264] to agree on parameters for unicast sessions. When used in this manner, the security considerations of those protocols apply. SDP is a session description format that describes multimedia sessions. Entities receiving and acting upon an SDP message SHOULD be aware that a session description cannot be trusted unless it has been obtained by an authenticated and integrity-protected transport protocol from a known and trusted source. Many different transport protocols may be used to distribute session descriptions, and the nature of the authentication and integrity-protection will differ from transport to transport. For some transports, security features are often not deployed. In case a session description has not been obtained in a trusted manner, the endpoint SHOULD exercise care because, among other attacks, the media sessions received may not be the intended ones, the destination where media is sent to may not be the expected one, any of the parameters of the session may be incorrect, or the media security may be compromised. It is up to the endpoint to make a sensible decision taking into account the security risks of the application and the user preferences - the endpoint may decide to ask the user whether or not to accept the session. On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session description should take a few precautions. Similar concerns apply if integrity protection is not in place. Session descriptions contain information required to start software on the receiver's system. Software that parses a session description MUST NOT be able to start other software except that which is specifically configured as appropriate software to participate in multimedia sessions. It is normally considered inappropriate for software parsing a session description to start, on a user's system, software that is appropriate to participate in multimedia sessions, without the user first being informed that such software will be started and giving the user's consent. Thus, a session description arriving by session announcement, email, session invitation, or WWW page MUST NOT deliver the user into an interactive multimedia session unless the user has explicitly pre-authorized such action. As it is not always simple to tell whether or not a session is interactive, applications that are Begen, et al. Expires February 10, 2020 [Page 39] Internet-Draft SDP August 2019 unsure should assume sessions are interactive. Software processing URLs contained in session descriptions should also heed the security considerations identified in [RFC3986]. In this specification, there are no attributes that would allow the recipient of a session description to be informed to start multimedia tools in a mode where they default to transmitting. Under some circumstances it might be appropriate to define such attributes. If this is done, an application parsing a session description containing such attributes SHOULD either ignore them or inform the user that joining this session will result in the automatic transmission of multimedia data. The default behavior for an unknown attribute is to ignore it. In certain environments, it has become common for intermediary systems to intercept and analyze session descriptions contained within other signaling protocols. This is done for a range of purposes, including but not limited to opening holes in firewalls to allow media streams to pass, or to mark, prioritize, or block traffic selectively. In some cases, such intermediary systems may modify the session description, for example, to have the contents of the session description match NAT bindings dynamically created. These behaviors are NOT RECOMMENDED unless the session description is conveyed in such a manner that allows the intermediary system to conduct proper checks to establish the authenticity of the session description, and the authority of its source to establish such communication sessions. SDP by itself does not include sufficient information to enable these checks: they depend on the encapsulating protocol (e.g., SIP or RTSP). Use of some procedures and SDP extensions (e.g., ICE [RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid the need for intermediaries to modify SDP. SDP MUST NOT be used to convey keying material (e.g., using "a=crypto" [RFC4568]) unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. 8. IANA Considerations 8.1. The "application/sdp" Media Type One media type registration from [RFC4566] is to be updated, as defined below. To: ietf-types@iana.org Subject: Registration of media type "application/sdp" Type name: application Begen, et al. Expires February 10, 2020 [Page 40] Internet-Draft SDP August 2019 Subtype name: sdp Required parameters: None. Optional parameters: None. Encoding considerations: 8-bit text. SDP files are primarily UTF-8 format text. The "a=charset:" attribute may be used to signal the presence of other character sets in certain parts of an SDP file (see Section 6 of RFC XXXX). Arbitrary binary content cannot be directly represented in SDP. Security considerations: See Section 7 of RFC XXXX. Interoperability considerations: See RFC XXXX. Published specification: See RFC XXXX. Applications which use this media type: Voice over IP, video teleconferencing, streaming media, instant messaging, among others. See also Section 3 of RFC XXXX. Fragment identifier considerations: None Additional information: Deprecated alias names for this type: N/A Magic number(s): None. File extension(s): The extension ".sdp" is commonly used. Macintosh File Type Code(s): "sdp " Person & email address to contact for further information: IETF MMUSIC working group Intended usage: COMMON Restrictions on usage: None Author/Change controller: Authors of RFC XXXX IETF MMUSIC working group delegated from the IESG Begen, et al. Expires February 10, 2020 [Page 41] Internet-Draft SDP August 2019 8.2. Registration of SDP Parameters with IANA This document specifies IANA parameter registries for six named SDP sub-fields. Using the terminology in the SDP specification Augmented Backus-Naur Form (ABNF), they are "media", "proto", "att-field", "bwtype", "nettype", and "addrtype". This document also replaces and updates the definitions of all those parameters previously defined by [RFC4566]. IANA: Please change all references to RFC4566 in these registries to instead refer to this document. The contact name and email address for all parameters registered in this document is: The IETF MMUSIC working group or its successor as designated by the IESG. All of these registries have a common format: ---------------------------------------------------- | Type | SDP Name | [other fields] | Reference | ---------------------------------------------------- 8.2.1. Registration Procedure A specification document that defines values for SDP "media", "proto", "att-field", "bwtype", "nettype", and "addrtype" parameters MUST include the following information: o contact name; o contact email address; o name being defined (as it will appear in SDP); o type of name ("media", "proto", "bwtype", "nettype", or "addrtype"); o a description of the purpose of the defined name; o a stable reference to the document containing this information and the definition of the value. (This will typically be an RFC number.) Begen, et al. Expires February 10, 2020 [Page 42] Internet-Draft SDP August 2019 The subsections below specify what other information (if any) must be specified for particular parameters, and what other fields are to be included in the registry. 8.2.2. Media Types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level media types, and where possible the same name should be registered for SDP as for MIME. For media other than existing top-level media types, a Standards Track RFC MUST be produced for a new top-level media type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of [RFC8126]). This memo registers the media types "audio", "video", "text", "application", and "message". Note: The media types "control" and "data" were listed as valid in an early version of this specification (RFC 2327); however, their semantics were never fully specified and they are not widely used. These media types have been removed in this specification, although they still remain valid media type capabilities for a SIP user agent as defined in [RFC3840]. If these media types are considered useful in the future, a Standards Track RFC MUST be produced to document their use. Until that is done, applications SHOULD NOT use these types and SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by [RFC3840]). Also note that [RFC6466] defined the "image" media type. 8.2.3. Transport Protocols ("proto") The "proto" sub-field describes the transport protocol used. The registration procedure for this registry is "RFC Required". This document registers two values: o "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] running over UDP/IP, o "UDP" indicates direct use of the UDP protocol. New transport protocols MAY be defined, and MUST be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable that it be Standards Track. The RFC defining a new Begen, et al. Expires February 10, 2020 [Page 43] Internet-Draft SDP August 2019 protocol MUST define the rules by which the "fmt" (see below) namespace is managed. "proto" names starting with "RTP/" MUST only be used for defining transport protocols that are profiles of the RTP protocol. For example, a profile whose short name is "XYZ" would be denoted by a "proto" sub-field of "RTP/XYZ". Each transport protocol, defined by the "proto" sub-field, has an associated "fmt" namespace that describes the media formats that may be conveyed by that protocol. Formats cover all the possible encodings that could be transported in a multimedia session. RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned by this session description, an additional "rtpmap" attribute MUST be included to specify the format name and parameters as defined by the media type registration for the payload format. It is RECOMMENDED that other RTP profiles that are registered (in combination with RTP) as SDP transport protocols specify the same rules for the "fmt" namespace. For the "UDP" protocol, allowed "fmt" values are media subtypes from the IANA Media Types registry. The media type and subtype combination / specifies the format of the body of UDP packets. Use of an existing media subtype for the format is encouraged. If no suitable media subtype exists, it is RECOMMENDED that a new one be registered through the IETF process [RFC6838] by production of, or reference to, a standards-track RFC that defines the format. For other protocols, formats MAY be registered according to the rules of the associated "proto" specification. Registrations of new formats MUST specify which transport protocols they apply to. 8.2.4. Attribute Names ("att-field") Attribute-field names ("att-field") MUST be registered with IANA and documented, to avoid any issues due to conflicting attribute definitions under the same name. (While unknown attributes in SDP are simply ignored, conflicting ones that fragment the protocol are a serious problem.) The format of the attribute registry is: Begen, et al. Expires February 10, 2020 [Page 44] Internet-Draft SDP August 2019 ---------------------------------------------------------------------- | | | | Mux | | | Type | SDP Name | Usage Level | Category | Reference | ---------------------------------------------------------------------- For example, the attribute "setup" which is defined for both session and media level, will be listed in the new registry as follows: ---------------------------------------------------------------------- | | | | Mux | | | Type | SDP Name | Usage Level | Category | Reference | |----------|------------|----------------|----------|----------------| |attribute |setup | session,media, |IDENTICAL | [RFC4145] | | | | dcsa,dcsa(msrp)| | [RFC6135] | | | | | | [I-D.mmusic- | | | | | | msrp-usage- | | | | | | data-channel] | ---------------------------------------------------------------------- This one registry combines all of the previous usage-level-specific "att-field" registries, including updates made by [I-D.ietf-mmusic-sdp-mux-attributes]. IANA is requested to do the necessary reformatting. Section 6 of this document replaces the initial set of attribute definitions made by [RFC4566]. IANA is requested to update the registry accordingly. Documents can define new attributes and can also extend the definitions of previously defined attributes: 8.2.4.1. New Attributes New attribute registrations are accepted according to the "Specification Required" policy of [RFC8126], provided that the specification includes the following information: o Contact Name. o Contact Email Address. o Attribute Name: The name of the attribute that will appear in SDP). This MUST conform to the definition of . o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF definition of the attribute value syntax (see Section 9) MUST be provided. The syntax MUST follow the rule form as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define Begen, et al. Expires February 10, 2020 [Page 45] Internet-Draft SDP August 2019 the allowable values that the attribute might take. It MAY also define an extension method for the addition of future values. For a property attribute, the ABNF definition is omitted as the property attribute takes no values. o Attribute Semantics: For a value attribute, a semantic description of the values that the attribute might take MUST be provided. The usage of a property attribute is described under purpose below. o Attribute Value: The name of an ABNF syntax rule defining the syntax of the value. Absence of a rule name indicates that the attribute takes no values. Enclosing the rule name in "[" and "]" indicates that a value is optional. o Usage Level: Usage level(s) of the attribute. This MUST be one or more of the following: session, media, source, dcsa and dcsa(subprotocol). For a definition of source level attributes, see [RFC5576]. For a definition of dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. o Charset Dependent: This MUST be "Yes" or "No" depending on whether the attribute value is subject to the charset attribute. o Purpose: An explanation of the purpose and usage of the attribute. o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. o Mux Category: This MUST indicate one of the following categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by [I-D.ietf-mmusic- sdp-mux-attributes]. o Reference: A reference to the specification defining the attribute. The above is the minimum that IANA will accept. Attributes that are expected to see widespread use and interoperability SHOULD be documented with a standards-track RFC that specifies the attribute more precisely. Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability. Submitters of registrations should also carefully choose the attribute usage level. They should not choose only "session" when Begen, et al. Expires February 10, 2020 [Page 46] Internet-Draft SDP August 2019 the attribute can have different values when media is disaggregated, i.e., when each m= section has its own IP address on a different endpoint. In that case the attribute type chosen should be "session, media" or "media" (depending on desired semantics). The default rule is that for all new SDP attributes that can occur both in session and media level, the media level overrides the session level. When this is not the case for a new SDP attribute, it MUST be explicitly stated. IANA has registered the initial set of attribute names ("att-field" values) with definitions as in Section 6 of this memo (these definitions replace those in [RFC4566]). 8.2.4.2. Updates to Existing Attributes Updated attribute registrations are accepted according to the "Specification Required" policy of [RFC8126]. The Designated Expert reviewing the update is requested to evaluate whether the update is compatible with the prior intent and use of the attribute, and whether the new document is of sufficient maturity and authority in relation to the prior document. The specification updating the attribute (for example, by adding a new value) MUST update registration information items from Section 8.2.4.1 according to the following constraints: o Contact Name: A name for an entity responsible for the update MUST be provided. o Contact Email Address: An email address for an entity responsible for the update MUST be provided. o Attribute Name: MUST be provided and MUST NOT be changed. Otherwise it is a new attribute. o Attribute Syntax: The existing rule syntax with the syntax extensions MUST be provided if there is a change to the syntax. A revision to an existing attribute usage MAY extend the syntax of an attribute, but MUST be backward compatible. o Attribute Semantics: A semantic description of new additional attribute values or a semantic extension of existing values. Existing attribute values semantics MUST only be extended in a backward compatible manner. o Usage Level: Updates MAY only add additional levels. Begen, et al. Expires February 10, 2020 [Page 47] Internet-Draft SDP August 2019 o Charset Dependent: MUST NOT be changed. o Purpose: MAY be extended according to the updated usage. o O/A Procedures: MAY be updated in a backward compatible manner and/or it applies to a new usage level only. o Mux Category: No change unless from "TBD" to another value (see [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if 'media' level is being added to the definition of an attribute that previously did not include it. o Reference: A new (additional or replacement) reference MUST be provided. Items SHOULD be omitted if there is no impact to them as a result of the attribute update. 8.2.5. Bandwidth Specifiers ("bwtype") A proliferation of bandwidth specifiers is strongly discouraged. New bandwidth specifiers ( sub-field values) MUST be registered with IANA. The submission MUST reference a standards- track RFC specifying the semantics of the bandwidth specifier precisely, and indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice. The RFC MUST specify the Mux Category for this value as defined by [I-D.ietf-mmusic-sdp-mux-attributes]. The format of the "bwtype" registry is: -------------------------------------------------- | Type | SDP Name | Mux Category | Reference | -------------------------------------------------- IANA is requested to update the "bwtype" registry entries for the bandwidth specifiers "CT" and "AS" with the definitions in Section 5.8 of this memo (these definitions replace those in [RFC4566]). 8.2.6. Network Types ("nettype") Network type "IN", representing the Internet, is defined in Section 5.2 and Section 5.7 of this memo. (This definition replaces that in [RFC4566].) Begen, et al. Expires February 10, 2020 [Page 48] Internet-Draft SDP August 2019 To enable SDP to reference a new non-Internet environment a new network type ( sub-field value) MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. Although non-Internet environments are not normally the preserve of IANA, there may be circumstances when an Internet application needs to interoperate with a non-Internet application, such as when gatewaying an Internet telephone call into the Public Switched Telephone Network (PSTN). The number of network types should be small and should be rarely extended. A new network type registration MUST reference an RFC that gives details of the network type and the address type(s) that may be used with it. The format of the "nettype" registry is: -------------------------------------------------------------------- |Type | SDP Name | Usable addrtype Values | Reference | -------------------------------------------------------------------- IANA is requested to update the "nettype" registry to this new format. The following is the updated content of th registry: -------------------------------------------------------------------- |Type | SDP Name | Usable addrtype Values | Reference | -------------------------------------------------------------------- |nettype | IN | IP4, IP6 | [RFCXXXX] | |nettype | TN | RFC2543 | [RFC2848] | |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | |nettype | PSTN | E164 | [RFC7195] | -------------------------------------------------------------------- Note that both [RFC7195] and [RFC3108] registered "E164" as an address type, although [RFC7195] mentions that the "E164" address type has a different context for ATM and PSTN networks. 8.2.7. Address Types ("addrtype") New address types ("addrtype") MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. A new address type registration MUST reference an RFC giving details of the syntax of the address type. Address types are not expected to be registered frequently. Section 5.7 of this document gives new definitions of address types "IP4" and "IP6". Begen, et al. Expires February 10, 2020 [Page 49] Internet-Draft SDP August 2019 8.3. Encryption Key Access Methods (OBSOLETE) The IANA previously maintained a table of SDP encryption key access method ("enckey") names. This table is obsolete, since the "k=" line is not extensible. New registrations MUST NOT be accepted. 9. SDP Grammar This section provides an Augmented BNF grammar for SDP. ABNF is defined in [RFC5234] and [RFC7405]. ; SDP Syntax session-description = version-field origin-field session-name-field [information-field] [uri-field] *email-field *phone-field [connection-field] *bandwidth-field 1*time-description [key-field] *attribute-field *media-description version-field = %s"v" "=" 1*DIGIT CRLF ;this memo describes version 0 origin-field = %s"o" "=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF session-name-field = %s"s" "=" text CRLF information-field = %s"i" "=" text CRLF uri-field = %s"u" "=" uri CRLF email-field = %s"e" "=" email-address CRLF phone-field = %s"p" "=" phone-number CRLF connection-field = %s"c" "=" nettype SP addrtype SP connection-address CRLF ;a connection field must be present ;in every media description or at the ;session level Begen, et al. Expires February 10, 2020 [Page 50] Internet-Draft SDP August 2019 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF time-description = time-field [repeat-description] repeat-description = 1*repeat-field [zone-field] time-field = %s"t" "=" start-time SP stop-time CRLF repeat-field = %s"r" "=" repeat-interval SP typed-time 1*(SP typed-time) CRLF zone-field = %s"z" "=" time SP ["-"] typed-time *(SP time SP ["-"] typed-time) CRLF key-field = %s"k" "=" key-type CRLF attribute-field = %s"a" "=" attribute CRLF media-description = media-field [information-field] *connection-field *bandwidth-field [key-field] *attribute-field media-field = %s"m" "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF ; sub-rules of 'o=' username = non-ws-string ;pretty wide definition, but doesn't ;include space sess-id = 1*DIGIT ;should be unique for this username/host sess-version = 1*DIGIT nettype = token ;typically "IN" addrtype = token ;typically "IP4" or "IP6" ; sub-rules of 'u=' uri = URI-reference Begen, et al. Expires February 10, 2020 [Page 51] Internet-Draft SDP August 2019 ; see RFC 3986 ; sub-rules of 'e=', see RFC 5322 for definitions email-address = address-and-comment / dispname-and-address / addr-spec address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" ; sub-rules of 'p=' phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe "<" phone ">" / phone phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) ; sub-rules of 'c=' connection-address = multicast-address / unicast-address ; sub-rules of 'b=' bwtype = token bandwidth = 1*DIGIT ; sub-rules of 't=' start-time = time / "0" stop-time = time / "0" time = POS-DIGIT 9*DIGIT ; Decimal representation of time in ; seconds since January 1, 1900 UTC. ; The representation is an unbounded ; length field containing at least ; 10 digits. Unlike some representations ; used elsewhere, time in SDP does not ; wrap in the year 2036. ; sub-rules of 'r=' and 'z=' repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit] fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" ; NOTE: These units are case-sensitive. ; sub-rules of 'k=' key-type = %s"prompt" / %s"clear:" text / Begen, et al. Expires February 10, 2020 [Page 52] Internet-Draft SDP August 2019 %s"base64:" base64 / %s"uri:" uri ; NOTE: These names are case-sensitive. base64 = *base64-unit [base64-pad] base64-unit = 4base64-char base64-pad = 2base64-char "==" / 3base64-char "=" base64-char = ALPHA / DIGIT / "+" / "/" ; sub-rules of 'a=' attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string ; sub-rules of 'm=' media = token ;typically "audio", "video", "text", "image" ;or "application" fmt = token ;typically an RTP payload type for audio ;and video media proto = token *("/" token) ;typically "RTP/AVP" or "udp" port = 1*DIGIT ; generic sub-rules: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr multicast-address = IP4-multicast / IP6-multicast / FQDN / extn-addr IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" numaddr ] ; IP4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = IP6-address [ "/" numaddr ] ; IP6 address starting with FF numaddr = integer Begen, et al. Expires February 10, 2020 [Page 53] Internet-Draft SDP August 2019 ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified ; in RFC 1035 (and updates) IP4-address = b1 3("." decimal-uchar) b1 = decimal-uchar ; less than "224" IP6-address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" h16 = 1*4HEXDIG ls32 = ( h16 ":" h16 ) / IP4-address ; Generic for other address families extn-addr = non-ws-string ; generic sub-rules: datatypes text = byte-string ;default is to interpret this as UTF8 text. ;ISO 8859-1 requires "a=charset:ISO-8859-1" ;session-level attribute to be used byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR, or LF non-ws-string = 1*(VCHAR/%x80-FF) ;string of visible characters token-char = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" ; (single quote) / "*" / "+" / "-" / "." / "^" / "_" / "`" ; (Grave accent) / "{" / "|" / "}" / "~" token = 1*(token-char) Begen, et al. Expires February 10, 2020 [Page 54] Internet-Draft SDP August 2019 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;any byte except NUL, CR, LF, or the quoting ;characters ()<> integer = POS-DIGIT *DIGIT zero-based-integer = "0" / integer non-zero-int-or-real = integer / non-zero-real non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT ; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT POS-DIGIT = %x31-39 ; 1 - 9 decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) ; external references: ALPHA = DIGIT = CRLF = HEXDIG = SP = VCHAR = URI-reference = addr-spec = 10. Summary of Changes from RFC 4566 o Generally clarified and refined terminology. o Identified now-obsolete items: "a=cat", "a=keywds", "k=". o Updated normative and informative references, and added references to additional relevant related RFCs. o Reformatted the SDP Attributes section for readability. The syntax of attribute values is now given in ABNF. o Made mandatory the sending of RTCP with inactive media streams. Begen, et al. Expires February 10, 2020 [Page 55] Internet-Draft SDP August 2019 o Removed the section "Private Sessions". That section dates back to a time when the primary use of SDP was with SAP (Session Announcement Protocol). That has fallen out of use. Now the vast majority of uses of SDP is for establishment of private sessions. The considerations for that are covered in Section 7. o Expanded and clarified the specification of the "lang" and "sdplang" attributes. o Removed some references to SAP because it is no longer in widespread use. o Changed the way values for UDP transport are registered. o Changed the mechanism and documentation required for registering new attributes. o Tightened up IANA registration procedures for extensions. Removed phone number and long-form name. o Expanded the IANA nettype registry to identify valid addrtypes. o Reorganized the several IANA att-type registries into a single registry o Revised ABNF syntax for clarity. Backward compatibility is maintained with a few exceptions: * Revised the syntax of time descriptions ("t=", "r=", "z=") to remove ambiguities. Clarified that "z=" only modifies the immediately preceding "r=" lines. Made "z=" without a preceding "r=" a syntax error. (This is incompatible with certain aberrant usage.) * Updated the "IP6-address" and "IP6-multicast" rules, consistent with the syntax in RFC3986. (This mirrors a bug fix made to RFC3261 by RFC5964.) Removed rules that were unused as a result of this change. o Revised normative statements that were redundant with ABNF syntax, making the text non-normative. o Revised IPv4 unicast and multicast addresses in the example SDP descriptions per RFCs 5735 and 5771. o Changed some examples to use IPv6 addresses, and added additional examples using IPv6. Begen, et al. Expires February 10, 2020 [Page 56] Internet-Draft SDP August 2019 o Incorporated case-insensitivity rules from RFC 4855. o Revised sections that incorrectly referenced NTP. o Clarified the explanation of the impact and use of a=charset. o Revised the description of a=type to remove implication that it sometimes changes the default media direction to something other than sendrecv. 11. Acknowledgements Many people in the IETF Multiparty Multimedia Session Control (MMUSIC) working group have made comments and suggestions contributing to this document. In particular, we would like to thank the following people who contributed to the creation of this document or one of its predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, Gonzalo Camarillo, Joerg Ott, John Elwell, Jon Peterson, Jonathan Lennox, Jonathan Rosenberg, Keith Drage, Peter Parnes, Rob Lanphier, Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, Steve Hanna, Van Jacobson. 12. References 12.1. Normative References [E164] International Telecommunication Union, "E.164 : The international public telecommunication numbering plan", ITU Recommendation E.164, November 2010. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, "SDP-based Data Channel Negotiation", draft-ietf- mmusic-data-channel-sdpneg-28 (work in progress), May 2019. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. Begen, et al. Expires February 10, 2020 [Page 57] Internet-Draft SDP August 2019 [ISO.8859-1.1998] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/ SC2", ISO/IEC Standard 8859-1, 1998. [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, . [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, DOI 10.17487/RFC2848, June 2000, . [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, . [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, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [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, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . Begen, et al. Expires February 10, 2020 [Page 58] Internet-Draft SDP August 2019 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 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, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, DOI 10.17487/RFC6135, February 2011, . [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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Begen, et al. Expires February 10, 2020 [Page 59] Internet-Draft SDP August 2019 12.2. Informative References [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., Keranen, A., Shpount, R., and C. Holmberg, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-38 (work in progress), August 2019. [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-54 (work in progress), December 2018. [ITU.H332.1998] International Telecommunication Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998. [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, . [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, . [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, . [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, . [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, . Begen, et al. Expires February 10, 2020 [Page 60] Internet-Draft SDP August 2019 [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, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 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, . [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, . [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, . [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, . [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . Begen, et al. Expires February 10, 2020 [Page 61] Internet-Draft SDP August 2019 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)", RFC 6466, DOI 10.17487/RFC6466, December 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, . [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, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 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, . [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . Authors' Addresses Ali Begen Networked Media Konya Turkey EMail: ali.begen@networked.media Begen, et al. Expires February 10, 2020 [Page 62] Internet-Draft SDP August 2019 Paul Kyzivat USA EMail: pkyzivat@alum.mit.edu Colin Perkins University of Glasgow School of Computing Science University of Glasgow Glasgow G12 8QQ UK EMail: csp@csperkins.org Mark Handley University College London Department of Computer Science London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk Begen, et al. Expires February 10, 2020 [Page 63] ./draft-ietf-pce-stateful-hpce-15.txt0000644000764400076440000015430313553247522016705 0ustar iustyiusty PCE Working Group D. Dhody Internet-Draft Huawei Technologies Intended status: Informational Y. Lee Expires: April 23, 2020 SKKU D. Ceccarelli Ericsson J. Shin SK Telecom D. King Lancaster University October 21, 2019 Hierarchical Stateful Path Computation Element (PCE) draft-ietf-pce-stateful-hpce-15 Abstract A Stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The Path computation response from a PCE is helpful for the PCC to gracefully establish the computed LSP. The Hierarchical Path Computation Element (H-PCE) architecture provides an architecture to allow the optimum sequence of inter-connected domains to be selected, and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs. Combining the capabilities of Stateful PCE and the Hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of Stateful, and not Stateless, PCEs using the Hierarchical PCE architecture. 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 https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Dhody, et al. Expires April 2020 [Page 1] Internet-Draft STATEFUL-HPCE October 2019 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 23, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Use cases and Applicability of Hierarchical Stateful PCE . 4 1.2.1. Applicability to ACTN . . . . . . . . . . . . . . . . 5 1.2.2. End-to-End Contiguous LSP . . . . . . . . . . . . . . 5 1.2.3. Applicability of a Stateful P-PCE . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Requirement Language . . . . . . . . . . . . . . . . . . . 7 3. Hierarchical Stateful PCE . . . . . . . . . . . . . . . . . . 7 3.1. Passive Operations . . . . . . . . . . . . . . . . . . . . 9 3.2. Active Operations . . . . . . . . . . . . . . . . . . . . 11 3.3. PCE Initiation of LSPs . . . . . . . . . . . . . . . . . . 12 3.3.1. Per-Domain Stitched LSP . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Manageability Considerations . . . . . . . . . . . . . . . . . 16 5.1. Control of Function and Policy . . . . . . . . . . . . . . 16 5.2. Information and Data Models . . . . . . . . . . . . . . . 16 5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 5.4. Verify Correct Operations . . . . . . . . . . . . . . . . 17 5.5. Requirements On Other Protocols . . . . . . . . . . . . . 17 5.6. Impact On Network Operations . . . . . . . . . . . . . . . 17 5.7. Error Handling between PCEs . . . . . . . . . . . . . . . 17 Dhody, et al. Expires April 2020 [Page 2] Internet-Draft STATEFUL-HPCE October 2019 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.1. Applicability to Inter-Layer Traffic Engineering . . . . . 18 6.2. Scalability Considerations . . . . . . . . . . . . . . . . 18 6.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction 1.1. Background The Path Computation Element communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients' (PCCs) requests. A stateful PCE is capable of considering, for the purposes of path computation, not only the network state in terms of links and nodes (referred to as the Traffic Engineering Database or TED) but also the status of active services (previously computed paths, and currently reserved resources, stored in the Label Switched Paths Database (LSP-DB). [RFC8051] 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. [RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. [RFC8281] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. [RFC8231] also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP or make changes to the attributes of an existing LSP, or delegate control of specific LSPs to a new PCE. Dhody, et al. Expires April 2020 [Page 3] Internet-Draft STATEFUL-HPCE October 2019 The ability to compute constrained paths for TE LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key motivation for PCE development. [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can be used for computing end-to-end paths for inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). Within the Hierarchical PCE (H-PCE) architecture [RFC6805], the Parent PCE (P-PCE) is used to compute a multi-domain path based on the domain connectivity information. A Child PCE (C-PCE) may be responsible for a single domain or multiple domains. The C-PCE is used to compute the intra-domain path based on its domain topology information. This document presents general considerations for stateful PCEs, and not Stateless PCEs, in the hierarchical PCE architecture. It focuses on the behavior changes and additions to the existing stateful PCE mechanisms (including PCE-initiated LSP setup and active stateful PCE usage) in the context of networks using the H-PCE architecture. In this document, Sections 3.1 and 3.2 focus on end to end (E2E) inter-domain TE LSP. Section 3.3.1 describes the operations for stitching Per-Domain LSPs. 1.2. Use cases and Applicability of Hierarchical Stateful PCE As per [RFC6805], in the hierarchical PCE architecture, a P-PCE maintains a domain topology map that contains the child domains and their interconnections. Usually, the P-PCE has no information about the content of the child domains. But if the PCE is applied to the Abstraction and Control of TE Networks (ACTN) [RFC8453] as described in [RFC8637], the Provisioning Network Controller (PNC) can provide an abstract topology to the Multi-Domain Service Coordinator (MDSC). Thus the P-PCE in MDSC could be aware of topology information in much more detail than just the domain topology. In a PCEP session between a PCC (Ingress) and a C-PCE, the C-PCE acts as per the stateful PCE operations described in [RFC8231] and [RFC8281]. The same C-PCE behaves as a PCC on the PCEP session towards the P-PCE. The P-PCE is stateful in nature and thus maintains the state of the inter-domain LSPs that are reported to it. The inter-domain LSP could also be delegated by the C-PCE to the P-PCE, so that the P-PCE could update the inter-domain path. The trigger for this update could be the LSP state change reported for this LSP or any other LSP. It could also be a change in topology at the P-PCE, such as inter-domain link status change. In case of use of stateful H-PCE in ACTN, a change in abstract topology learned by the P-PCE could also trigger the update. Some other external factors (such as a measurement probe) could also be a trigger at the P-PCE. Any such Dhody, et al. Expires April 2020 [Page 4] Internet-Draft STATEFUL-HPCE October 2019 update would require an inter-domain path recomputation as described in [RFC6805]. The end-to-end inter-domain path computation and setup is described in [RFC6805]. Additionally, a per-domain stitched LSP model is also applicable in a P-PCE initiation model. Section 3.1, Section 3.2, and Section 3.3 describe the end-to-end Contiguous LSP setup, whereas Section 3.3.1 describes the per-domain stitching. 1.2.1. Applicability to ACTN [RFC8453] describes a framework for the Abstraction and Control of TE Networks (ACTN), where each Provisioning Network Controller (PNC) is equivalent to a C-PCE, and the P-PCE is the Multi-Domain Service Coordinator (MDSC). The Per-Domain stitched LSP as per the Hierarchical PCE architecture described in Section 3.3.1 and Section 4.1 is well suited for ACTN deployments. [RFC8637] examines the applicability of PCE to the ACTN framework. To support the function of multi-domain coordination via hierarchy, the hierarchy of stateful PCEs plays a crucial role. In the ACTN framework, a Customer Network Controller (CNC) can request the MDSC to check whether there is a possibility to meet Virtual Network (VN) requirements before requesting that the VN be provisioned. The H-PCE architecture as described in [RFC6805] can support this function using PCReq and PCRep messages between the P-PCE and C-PCEs. When the CNC requests VN provisioning, the MDSC decomposes this request into multiple inter-domain LSP provisioning requests, which might be further decomposed to per-domain path segments. This is described in Section 3.3.1. The MDSC uses the LSP Initiate Request (PCInitiate) message from the P-PCE towards the C-PCE, and the C-PCE reports the state back to the P-PCE via a Path Computation State Report (PCRpt) message. The P-PCE could make changes to the LSP via the use of a Path Computation Update Request (PCUpd) message. In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as PNCs) along the inter-domain path of the LSP. 1.2.2. End-to-End Contiguous LSP Different signaling options for inter-domain RSVP-TE are identified in [RFC4726]. Contiguous LSPs are achieved using the procedures of [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans all domains. [RFC6805] describes the technique to establish the optimum path when the sequence of domains is not known in advance. Dhody, et al. Expires April 2020 [Page 5] Internet-Draft STATEFUL-HPCE October 2019 It 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. A stateful P-PCE has to be aware of the inter-domain LSPs for it to consider them during path computation. For instance when a domain diverse path is required from another LSP, the P-PCE needs to be aware of the LSP. This is the Passive Stateful P-PCE as described in Section 3.1. Additionally, the inter-domain LSP could be delegated to the P-PCE, so that P-PCE could trigger an update via a PCUpd message. The update could be triggered on receipt of the PCRpt message that indicates a status change of this LSP or some other LSP. The other LSP could be an associated LSP (such as protection [I-D.ietf-pce-stateful-path-protection]) or an unrelated LSP whose resource change leads to re-optimization at the P-PCE. This is the Active Stateful Operation as described in Section 3.2. Further, the P-PCE could be instructed to create an inter-domain LSP on its own using the PCInitiate message for an E2E contiguous LSP. The P-PCE would send the PCInitiate message to the Ingress domain C-PCE, which would further instruct the Ingress PCC. In this document, for the Contiguous LSP, the above interactions are only between the ingress domain C-PCE and the P-PCE. The use of stateful operations for an inter-domain LSP between the transit/egress domain C-PCEs and the P-PCE is out of scope of this document. 1.2.3. Applicability of a Stateful P-PCE [RFC8051] 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. These are also applicable to the stateful P-PCE when used for the inter- domain LSP path computation and setup. It should be noted that though the stateful P-PCE has limited direct visibility inside the child domain, it could still trigger re-optimization with the help of child PCEs based on LSP state changes, abstract topology changes, or some other external factors. The C-PCE would delegate control of the inter-domain LSP to the P-PCE so that the P-PCE can make changes to it. Note that, if the C-PCE becomes aware of a topology change that is hidden from the P-PCE, it could take back the delegation from the P-PCE to act on it itself. Similarly, a P-PCE could also request delegation if it needs to make a change to the LSP (refer to [I-D.ietf-pce-lsp-control-request]). 2. Terminology Dhody, et al. Expires April 2020 [Page 6] Internet-Draft STATEFUL-HPCE October 2019 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8051], [RFC8231], and [RFC8281]. Some key terms are listed below for easy reference. ACTN: Abstraction and Control of Traffic Engineering Networks CNC: Customer Network Controller C-PCE: Child Path Computation Element H-PCE: Hierarchical Path Computation Element IGP: Interior Gateway Protocol LSP: Label Switched Path LSP-DB: Label Switched Path Database LSR: Label Switching Router MDSC: Multi-Domain Service Coordinator PCC: Path Computation Client PCE: Path Computation Element PCEP: Path Computation Element communication Protocol PNC: Provisioning Network Controller P-PCE: Parent Path Computation Element TED: Traffic Engineering Database VN: Virtual Network 2.1. Requirement Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Hierarchical Stateful PCE As described in [RFC6805], in the hierarchical PCE architecture a Dhody, et al. Expires April 2020 [Page 7] Internet-Draft STATEFUL-HPCE October 2019 P-PCE maintains a domain topology map that contains the child domains (seen as vertices in the topology) and their interconnections (links in the topology). Usually, the P-PCE has no information about the content of the child domains. Each child domain has at least one PCE capable of computing paths across the domain. These PCEs are known as Child PCEs (C-PCEs) [RFC6805] and have a direct relationship with the P-PCE. The P-PCE builds the domain topology map either via direct configuration or from learned information received from each C-PCE. The network policy could be be applied while building the domain topology map. This has been described in detail in [RFC6805]. Note that, in the scope of this document, both the C-PCEs and the P- PCE are stateful in nature. [RFC8231] specifies new functions to support a stateful PCE. It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). This document extends these functions to support H-PCE Architecture from a C-PCE towards P-PCE (EC-EP) or from a P-PCE towards C-PCE (EP-EC). All PCE types herein (EC-EP and EP-EC) are assumed to be "Stateful PCE". A number of interactions are expected in the Hierarchical Stateful PCE architecture. These include: LSP State Report (EC-EP): a child stateful PCE sends an LSP state report to a Parent Stateful PCE to indicate the state of a LSP. LSP State Synchronization (EC-EP): after the session between the Child and Parent stateful PCEs is initialized, the P-PCE must learn the state of C-PCE's TE LSPs. LSP Control Delegation (EC-EP,EP-EC): a C-PCE grants to the P-PCE the right to update LSP attributes on one or more LSPs; the C-PCE may withdraw the delegation or the P-PCE may give up the delegation at any time. LSP Update Request (EP-EC): a stateful P-PCE requests modification of attributes on a C-PCE's TE LSP. PCE LSP Initiation Request (EP-EC): a stateful P-PCE requests C-PCE to initiate a TE LSP. Note that this hierarchy is recursive, so a Label Switching Router (LSR), as a PCC, could delegate control to a PCE, which may in turn delegate to its parent, which may further delegate to its parent (if Dhody, et al. Expires April 2020 [Page 8] Internet-Draft STATEFUL-HPCE October 2019 it exists). Similarly, update operations can also be applied recursively. [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV that is used in the Open message to advertise the H-PCE capability. [RFC8231] defines the Stateful PCE Capability TLV used in the Open message to indicate stateful support. To indicates the support for stateful H-PCE operations described in this document, a PCEP speaker MUST include both TLVs in an Open message. It is RECOMMENDED that any implementation that supports stateful operations [RFC8231] and H-PCE [I-D.ietf-pce-hierarchy-extensions] would also implements the stateful H-PCE operations as described in this document. Further consideration may be made for optional procedures for stateful communication coordination between PCEs, including procedures to minimize computational loops. The procedures described in [I-D.litkowski-pce-state-sync] facilitate stateful communication between PCEs for various use cases. The procedures and extensions as described in Section 3 of [I-D.litkowski-pce-state-sync] are also applicable to Child and Parent PCE communication. The SPEAKER-IDENTITY-TLV (defined in [RFC8232]) is included in the LSP object to identify the Ingress (PCC). The PLSP-ID (PCEP-specific identifier for the LSP, as per [RFC8231]) used in the forwarded PCRpt by the C-PCE to P-PCE is same as the original one used by the PCC. 3.1. Passive Operations Procedures as described in [RFC6805] are applied, where the ingress PCC triggers a path computation request for the destination towards the C-PCE in the domain where the LSP originates. The C-PCE further forwards the request to the P-PCE. The P-PCE selects a set of candidate domain paths based on the domain topology and the state of the inter-domain links. It then sends computation requests to the C-PCEs responsible for each of the domains on the candidate domain paths. Each C-PCE computes a set of candidate path segments across its domain and sends the results to the P-PCE. The P-PCE uses this information to select path segments and concatenate them to derive the optimal end-to-end inter-domain path. The end-to-end path is then sent to the C-PCE that received the initial path request, and this C-PCE passes the path on to the PCC that issued the original request. As per [RFC8231], PCC sends an LSP State Report carried on a PCRpt message to the C-PCE, indicating the LSP's status. The C-PCE may further propagate the State Report to the P-PCE. A local policy at C-PCE may dictate which LSPs are reported to the P-PCE. The PCRpt message is sent from C-PCE to P-PCE. Dhody, et al. Expires April 2020 [Page 9] Internet-Draft STATEFUL-HPCE October 2019 State synchronization mechanisms as described in [RFC8231] and [RFC8232] are applicable to a PCEP session between C-PCE and P-PCE as well. We use the hierarchical domain topology example from [RFC6805] as the reference topology for the entirety of this document. It is shown in Figure 1. ----------------------------------------------------------------- | Domain 5 | | ----- | | |PCE 5| | | ----- | | | | ---------------- ---------------- ---------------- | | | Domain 1 | | Domain 2 | | Domain 3 | | | | | | | | | | | | ----- | | ----- | | ----- | | | | |PCE 1| | | |PCE 2| | | |PCE 3| | | | | ----- | | ----- | | ----- | | | | | | | | | | | | ----| |---- ----| |---- | | | | |BN11+---+BN21| |BN23+---+BN31| | | | | - ----| |---- ----| |---- - | | | | |S| | | | | |D| | | | | - ----| |---- ----| |---- - | | | | |BN12+---+BN22| |BN24+---+BN32| | | | | ----| |---- ----| |---- | | | | | | | | | | | | ---- | | | | ---- | | | | |BN13| | | | | |BN33| | | | -----------+---- ---------------- ----+----------- | | \ / | | \ ---------------- / | | \ | | / | | \ |---- ----| / | | ----+BN41| |BN42+---- | | |---- ----| | | | | | | | ----- | | | | |PCE 4| | | | | ----- | | | | | | | | Domain 4 | | | ---------------- | | | ----------------------------------------------------------------- Dhody, et al. Expires April 2020 [Page 10] Internet-Draft STATEFUL-HPCE October 2019 Figure 1: Hierarchical Domain Topology Example Steps 1 to 11 are exactly as described in section 4.6.2 of [RFC6805] (Hierarchical PCE End-to-End Path Computation Procedure), the following additional steps are added for stateful PCE, to be executed at the end: (A) The Ingress LSR initiates the setup of the LSP as per the path and reports to the PCE1 the LSP status ("GOING-UP"). (B) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). (C) The Ingress LSR notifies the LSP state to PCE1 when the state is "UP". (D) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). The Ingress LSR could trigger path re-optimization by sending the path computation request as described in [RFC6805], at this time it can include the LSP object in the PCReq message as described in [RFC8231]. 3.2. Active Operations [RFC8231] describes the case of active stateful PCE. The active PCE functionality uses two specific PCEP messages: o Update Request (PCUpd) o State Report (PCRpt) The first is sent by the PCE to a PCC for modifying LSP attributes. The PCC sends back a PCRpt to acknowledge the requested operation or report any change in LSP's state. As per [RFC8051], Delegation is an operation to grant a PCE temporary rights to modify a subset of LSP parameters on one or more PCC's LSPs. The C-PCE may further choose to delegate to its P-PCE based on a local policy. The PCRpt message with the "D" (delegate) flag is sent from C-PCE to P-PCE. To update an LSP, a PCE sends an LSP Update Request to the PCC using a PCUpd message. For an LSP delegated to a P-PCE via the C-PCE; the P-PCE can use the same PCUpd message to request a change to the C-PCE (the Ingress domain PCE). The C-PCE further propagates the update Dhody, et al. Expires April 2020 [Page 11] Internet-Draft STATEFUL-HPCE October 2019 request to the PCC. The P-PCE uses the same mechanism described in Section 3.1 to compute the end to end path using PCReq and PCRep messages. For active operations, the following steps are required when delegating the LSP, again using the reference architecture described in Figure 1 (Hierarchical Domain Topology Example). (A) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message with D flag set. (B) The PCE1 further delegates the LSP to the P-PCE (PCE5). (C) Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed at P-PCE (PCE5) to determine the end to end path. (D) The P-PCE (PCE5) sends the update request to the C-PCE (PCE1) via PCUpd message. (E) The PCE1 further updates the LSP to the Ingress LSR (PCC). (F) The Ingress LSR initiates the setup of the LSP as per the path and reports to the PCE1 the LSP status ("GOING-UP"). (G) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). (H) The Ingress LSR notifies the LSP state to PCE1 when the state is "UP". (I) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). 3.3. PCE Initiation of LSPs [RFC8281] describes the setup, maintenance and teardown of PCE- initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. To instantiate or delete an LSP, the PCE sends the Path Computation LSP Initiate Request (PCInitiate) message to the PCC. In case of an inter-domain LSP in Hierarchical PCE architecture, the initiation operations can be carried out at the P-PCE. In which case after the P-PCE finishes the E2E path computation, it can send the PCInitiate message to the C-PCE (the Ingress domain PCE), the C-PCE further propagates the initiate request to the PCC. Dhody, et al. Expires April 2020 [Page 12] Internet-Draft STATEFUL-HPCE October 2019 The following steps are performed for PCE-initiated operations, again using the reference architecture described in Figure 1 (Hierarchical Domain Topology Example): (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine the end to end path. (B) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE1) via PCInitiate message. (C) The PCE1 further propagates the initiate message to the Ingress LSR (PCC). (D) The Ingress LSR initiates the setup of the LSP as per the path and reports to the PCE1 the LSP status ("GOING-UP"). (E) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). (F) The Ingress LSR notifies the LSP state to PCE1 when the state is "UP". (G) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). The Ingress LSR (PCC) would generate the PLSP-ID for the LSP and inform the C-PCE, which is propagated to the P-PCE. 3.3.1. Per-Domain Stitched LSP The Hierarchical PCE architecture as per [RFC6805] is primarily used for E2E LSP. With PCE-Initiated capability, another mode of operation is possible, where multiple intra-domain LSPs are initiated in each domain, which are further stitched to form an E2E LSP. The P-PCE sends PCInitiate message to each C-PCE separately to initiate individual LSP segments along the domain path. These individual Per- Domain LSP are stitched together by some mechanism, which is out of scope of this document (Refer [I-D.dugeon-pce-stateful- interdomain]). The following steps are performed for the Per-Domain stitched LSP operation, again using the reference architecture described in Figure 1 (Hierarchical Domain Topology Example): (A) The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine the end Dhody, et al. Expires April 2020 [Page 13] Internet-Draft STATEFUL-HPCE October 2019 to end path, which are broken into per-domain LSPs say - o S-BN41 o BN41-BN33 o BN33-D It should be noted that the P-PCE may use other mechanisms to determine the suitable per-domain LSPs (apart from [RFC6805]). For LSP (BN33-D) (B) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE3) via PCInitiate message for LSP (BN33-D). (C) The PCE3 further propagates the initiate message to BN33. (D) BN33 initiates the setup of the LSP as per the path and reports to the PCE3 the LSP status ("GOING-UP"). (E) The PCE3 further reports the status of the LSP to the P-PCE (PCE5). (F) The node BN33 notifies the LSP state to PCE3 when the state is "UP". (G) The PCE3 further reports the status of the LSP to the P-PCE (PCE5). For LSP (BN41-BN33) (H) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE4) via PCInitiate message for LSP (BN41-BN33). (I) The PCE4 further propagates the initiate message to BN41. (J) BN41 initiates the setup of the LSP as per the path and reports to the PCE4 the LSP status ("GOING-UP"). (K) The PCE4 further reports the status of the LSP to the P-PCE (PCE5). (L) The node BN41 notifies the LSP state to PCE4 when the state is "UP". (M) The PCE4 further reports the status of the LSP to the P-PCE (PCE5). Dhody, et al. Expires April 2020 [Page 14] Internet-Draft STATEFUL-HPCE October 2019 For LSP (S-BN41) (N) The P-PCE (PCE5) sends the initiate request to the child PCE (PCE1) via PCInitiate message for LSP (S-BN41). (O) The PCE1 further propagates the initiate message to node S. (P) S initiates the setup of the LSP as per the path and reports to the PCE1 the LSP status ("GOING-UP"). (Q) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). (R) The node S notifies the LSP state to PCE1 when the state is "UP". (S) The PCE1 further reports the status of the LSP to the P-PCE (PCE5). Additionally: (T) Once P-PCE receives report of each per-domain LSP, it should use suitable stitching mechanism, which is out of scope of this document. In this step, P-PCE (PCE5) could also initiate an E2E LSP (S-D) by sending the PCInitiate message to Ingress C-PCE (PCE1). Note that each per-domain LSP can be set up in parallel. Further, it is also possible to stitch the per-domain LSP at the same time as the per-domain LSPs are initiated. This option is defined in [I-D.dugeon-pce-stateful-interdomain]. 4. Security Considerations The security considerations listed in [RFC8231],[RFC6805] and [RFC5440] apply to this document as well. As per [RFC6805], it is expected that the parent PCE will require all child PCEs to use full security (i.e. the highest security mechanism available for PCEP) when communicating with the parent. Any multi-domain operation necessarily involves the exchange of information across domain boundaries. This is bound to represent a significant security and confidentiality risk especially when the child domains are controlled by different commercial concerns. PCEP allows individual PCEs to maintain confidentiality of their domain path information using path-keys [RFC5520], and the hierarchical PCE architecture is specifically designed to enable as much isolation of Dhody, et al. Expires April 2020 [Page 15] Internet-Draft STATEFUL-HPCE October 2019 domain topology and capabilities information as is possible. The LSP state in the PCRpt message must continue to maintain the internal domain confidentiality when required. The security consideration for PCE-Initiated LSP as per [RFC8281] is also applicable from P-PCE to C-PCE. Further, section 6.3 describes the use of path-key [RFC5520] for confidentiality between C-PCE and P-PCE. Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE and the C-PCE) using Transport Layer Security (TLS) [RFC8446] (per the recommendations and best current practices in BCP 195 [RFC7525]) and/or TCP Authentication Option (TCP-AO) [RFC5925]. The guidance for implementing PCEP with TLS can be found in [RFC8253]. In case of TLS, due care needs to be taken while exposing the parameters of the X.509 certificate, such as subjectAltName:otherName which is set to Speaker Entity Identifier [RFC8232] as per [RFC8253], to ensure uniqueness and avoid any mismatch. 5. Manageability Considerations All manageability requirements and considerations listed in [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to Stateful H- PCE defined in this document. In addition, requirements and considerations listed in this section apply. 5.1. Control of Function and Policy Support of the hierarchical procedure will be controlled by the management organization responsible for each child PCE. The parent PCE must only accept path computation requests from authorized child PCEs. If a parent PCE receives a report from an unauthorized child PCE, the report should be dropped. All mechanisms as described in [RFC8231] and [RFC8281] continue to apply. 5.2. Information and Data Models An implementation should allow the operator to view the stateful and H-PCE capabilities advertised by each peer. The "ietf-pcep" PCEP YANG module is specified in [I-D.ietf-pce-pcep-yang]. This YANG module will be required to be augmented to also include details for stateful H-PCE deployment and operation. The exact model and attributes are out of scope for this document. 5.3. Liveness Detection and Monitoring Dhody, et al. Expires April 2020 [Page 16] Internet-Draft STATEFUL-HPCE October 2019 Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 5.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [RFC8231]. 5.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. 5.6. Impact On Network Operations Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document. The stateful H-PCE technique brings the applicability of stateful PCE as described in [RFC8051], for the LSP traversing multiple domains. As described in Section 3, a PCEP speaker includes both the H-PCE Capability TLV [I-D.ietf-pce-hierarchy-extensions] and Stateful PCE Capability TLV [RFC8231] to indicate support for Stateful H-PCE. Note that there is a possibility of a PCEP speaker that does not support the Stateful H-PCE feature but does provide support for Stateful PCE [RFC8231] and H-PCE [I-D.ietf-pce-hierarchy-extensions] features. This PCEP speaker will also include both the TLVs and in this case a PCEP peer could falsely assume that the stateful H-PCE feature is also supported. On further PCEP message exchange, the stateful messages will not get further propagated (as described in this document) and a stateful H-PCE based 'parent' control of the LSP will not happen. A PCEP peer should be prepared for this eventuality as a part of normal procedures. 5.7. Error Handling between PCEs Apart from the basic error handling described in this document, an implementation could also use the enhanced error and notification mechanism for stateful H-PCE operations as per [I-D.ietf-pce- enhanced-errors]. Enhanced features such as error behavior propagation, notification and error criticality level, are further defined in [I-D.ietf-pce-enhanced-errors]. 6. Other Considerations Dhody, et al. Expires April 2020 [Page 17] Internet-Draft STATEFUL-HPCE October 2019 6.1. Applicability to Inter-Layer Traffic Engineering [RFC5623] describes a framework for applying the PCE-based architecture to inter-layer (G)MPLS traffic engineering. The H-PCE Stateful architecture with stateful P-PCE coordinating with the stateful C-PCEs of higher and lower layer is shown in the figure below. +----------+ | Parent | /| PCE | / +----------+ / / Stateful / / P-PCE / / / / Stateful+-----+ / / C-PCE | PCE |/ / Hi | Hi | / +-----+ / +---+ +---+ / +---+ +---+ + LSR +--+ LSR +........................+ LSR +--+ LSR + + H1 + + H2 + / + H3 + + H4 + +---+ +---+\ +-----+/ /+---+ +---+ \ | PCE | / \ | Lo | / Stateful \ +-----+ / C-PCE \ / Lo \+---+ +---+/ + LSR +--+ LSR + + L1 + + L2 + +---+ +---+ Figure 2: Sample Inter-Layer Topology All procedures described in Section 3 are applicable to inter-layer (and therefore separate domains) path setup as well. 6.2. Scalability Considerations It should be noted that if all the C-PCEs would report all the LSPs in their domain, it could lead to scalability issues for the P-PCE. Thus it is recommended to only report the LSPs which are involved in H-PCE, i.e. the LSPs which are either delegated to the P-PCE or initiated by the P-PCE. Scalability considerations for PCEP as per [RFC8231] continue to apply for the PCEP session between child and parent PCE. Dhody, et al. Expires April 2020 [Page 18] Internet-Draft STATEFUL-HPCE October 2019 6.3. Confidentiality As described in section 4.2 of [RFC6805], information about the content of child domains is not shared for both scaling and confidentiality reasons. The child PCE could also conceal the path information during path computation. A C-PCE may replace a path segment with a path-key [RFC5520], effectively hiding the content of a segment of a path. 7. IANA Considerations There are no IANA considerations. 8. Acknowledgments Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano Parodi, Giacomo Agostini, Jeff Tantsura, Rajan Rao, Adrian Farrel and Haomian Zheng, for their reviews and suggestions. Thanks to Tal Mazrahi for the RTGDIR review, Paul Kyzivat for the GENART review, and Stephen Farrell for SECDIR review. Thanks to Barry Leiba, Martin Vigoureux, Benjamin Kaduk, and Roman Danyliw for IESG review. 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, . [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, Dhody, et al. Expires April 2020 [Page 19] Internet-Draft STATEFUL-HPCE October 2019 . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 9.2. Informative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Dhody, et al. Expires April 2020 [Page 20] Internet-Draft STATEFUL-HPCE October 2019 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, . [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, . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)", RFC 8637, DOI 10.17487/RFC8637, July 2019, . [I-D.litkowski-pce-state-sync] Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Stateful Path Computation Element communication procedures", draft-litkowski-pce-state-sync-06 (work in progress), July 2019. Dhody, et al. Expires April 2020 [Page 21] Internet-Draft STATEFUL-HPCE October 2019 [I-D.ietf-pce-hierarchy-extensions] Zhang, F., Zhao, Q., Dios, O., Casellas, R., and D. King, "Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)", draft-ietf-pce-hierarchy-extensions-11 (work in progress), June 2019. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang-12 (work in progress), July 2019. [I-D.dugeon-pce-stateful-interdomain] Dugeon, O., Meuric, J., Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extension for Stateful Inter-Domain Tunnels", draft-dugeon-pce-stateful-interdomain-02 (work in progress), March 2019. [I-D.ietf-pce-lsp-control-request] Raghuram, A., Goddard, A., Yadlapalli, C., Karthik, J., Sivabalan, S., Parker, J., and M. Negi, "Ability for a stateful Path Computation Element (PCE) to request and obtain control of a LSP", draft-ietf-pce-lsp-control- request-11 (work in progress), October 2019. [I-D.ietf-pce-enhanced-errors] Pouyllau, et al., "Extensions to PCEP for Enhanced Errors" , draft-ietf-pce-enhanced-errors-06 (work in progress), August 2019. [I-D.ietf-pce-stateful-path-protection] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., and M. Negi, "PCEP Extensions for Associating Working and Protection LSPs with Stateful PCE", draft-ietf-pce- stateful-path-protection-11 (work in progress), September 2019. Contributors Avantika ECI Telecom India EMail: avantika.srm@gmail.com Xian Zhang Huawei Technologies Dhody, et al. Expires April 2020 [Page 22] Internet-Draft STATEFUL-HPCE October 2019 Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China EMail: zhang.xian@huawei.com Udayasree Palle EMail: udayasreereddy@gmail.com Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz 82-84 Madrid, 28045 Spain Phone: +34913128832 EMail: oscar.gonzalezdedios@telefonica.com Authors' Addresses Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Young Lee SKKU EMail: younglee.tx@gmail.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm Sweden EMail: daniele.ceccarelli@ericsson.com Jongyoon Shin SK Telecom 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, Gyeonggi-do 463-784 Republic of Korea Dhody, et al. Expires April 2020 [Page 23] Internet-Draft STATEFUL-HPCE October 2019 EMail: jongyoon.shin@sk.com Daniel King Lancaster University UK EMail: d.king@lancaster.ac.uk Dhody, et al. Expires April 2020 [Page 24] ./queue2.xml0000644000764400076440000026523413555641062012322 0ustar iustyiusty
draft-ietf-rtcweb-data-channel-13.txt 2015-01-08 REF*R draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE 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 REF*R draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE R. Jesup, S. Loreto, M. Tuexen WebRTC Data Channel Establishment Protocol 28411 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-rtp-usage-26.txt 2015-07-01 REF*R draft-ietf-avtcore-multi-media-rtp-session IN-QUEUE draft-ietf-avtcore-rtp-multi-stream-optimisation IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-rtcweb-fec IN-QUEUE draft-ietf-rtcweb-overview IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE 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 EDIT*R draft-ietf-bfcpbis-rfc4583bis IN-QUEUE 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-multi-media-rtp-session-13.txt 2015-12-28 EDIT*R draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE 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 IN-QUEUE 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 EDIT*R 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 REF*R draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE M. Thomson Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) 15355 Real-Time Communication in WEB-browsers yes draft-ietf-mmusic-msid-17.txt 2016-07-12 REF*R draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE H. Alvestrand WebRTC MediaStream Identification in the Session Description Protocol 35897 Multiparty Multimedia Session Control yes draft-ietf-mmusic-mux-exclusive-12.txt 2016-08-09 REF*R draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE 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 IN-QUEUE 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-tsvwg-rtcweb-qos-18.txt 2016-08-22 REF*R draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE 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-avtext-rid-09.txt 2016-10-19 REF*R draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE 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 REF*R draft-ietf-mmusic-sctp-sdp IN-QUEUE 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 IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-tsvwg-rtcweb-qos IN-QUEUE H. Alvestrand Transports for WebRTC 41832 Real-Time Communication in WEB-browsers yes draft-ietf-mmusic-sdp-mux-attributes-17.txt 2016-12-20 REF*R draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE S. Nandakumar A Framework for SDP Attributes when Multiplexing 234454 Multiparty Multimedia Session Control yes draft-ietf-bfcpbis-bfcp-websocket-15.txt 2017-02-13 EDIT*R draft-ietf-bfcpbis-rfc4582bis IN-QUEUE draft-ietf-bfcpbis-rfc4583bis IN-QUEUE V. Pascual, A. Roman, S. Cazeaux, G. Salgueiro, R. Ravindranath The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) 30505 Binary Floor Control Protocol Bis yes draft-ietf-clue-rtp-mapping-14.txt 2017-02-27 MISSREF*R(2G) draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-clue-data-model-schema IN-QUEUE draft-ietf-clue-framework IN-QUEUE R. Even, J. Lennox Mapping RTP streams to CLUE Media Captures 32763 ControLling mUltiple streams for tElepresence yes draft-ietf-mmusic-sctp-sdp-26.txt 2017-03-20 EDIT*R draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE C. Holmberg, R. Shpount, S. Loreto, G. Camarillo Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. 54708 Multiparty Multimedia Session Control yes draft-ietf-isis-l2bundles-07.txt 2017-05-26 AUTH48*R http://www.rfc-editor.org/auth48/rfc8668 draft-ietf-isis-segment-routing-extensions IN-QUEUE L. Ginsberg, A. Bashandy, C. Filsfils, M. Nanduri, E. Aries Advertising L2 Bundle Member Link Attributes in IS-IS 36246 IS-IS for IP Internets yes draft-ietf-avtext-lrr-07.txt 2017-07-07 MISSREF*R(1G) draft-ietf-avtext-framemarking NOT-RECEIVED J. Lennox, D. Hong, J. Uberti, S. Holmer, M. Flodman The Layer Refresh Request (LRR) RTCP Feedback Message 31966 Audio/Video Transport Extensions yes draft-ietf-anima-grasp-15.txt 2017-07-19 MISSREF*R(1G) draft-ietf-anima-autonomic-control-plane NOT-RECEIVED C. Bormann, B. Carpenter, Ed., B. Liu, Ed. A Generic Autonomic Signaling Protocol (GRASP) 181149 Autonomic Networking Integrated Model and Approach yes draft-ietf-ospf-encapsulation-cap-09.txt 2017-10-24 MISSREF*R(1G) draft-ietf-idr-tunnel-encaps NOT-RECEIVED X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil The Tunnel Encapsulations OSPF Router Information 22330 Open Shortest Path First IGP yes draft-ietf-mmusic-dtls-sdp-32.txt 2017-11-02 EDIT*R draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE C. Holmberg, R. Shpount Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) 58022 Multiparty Multimedia Session Control yes draft-ietf-rtcweb-overview-19.txt 2017-11-12 REF*R draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-rtcweb-transports IN-QUEUE H. Alvestrand Overview: Real Time Protocols for Browser-based Applications 53526 Real-Time Communication in WEB-browsers yes draft-ietf-ospf-segment-routing-extensions-27.txt 2017-12-18 AUTH48*R http://www.rfc-editor.org/auth48/rfc8665 draft-ietf-spring-segment-routing-ldp-interop IN-QUEUE draft-ietf-spring-segment-routing-mpls IN-QUEUE P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura OSPF Extensions for Segment Routing 60933 Open Shortest Path First IGP yes draft-ietf-rtgwg-yang-rip-11.txt 2018-01-15 EDIT X. Liu, P. Sarda, V. Choudhary A YANG Data Model for Routing Information Protocol (RIP) 78938 Routing Area Working Group yes draft-ietf-rtcweb-jsep-26.txt 2018-03-01 EDIT*R draft-ietf-avtext-rid IN-QUEUE draft-ietf-ice-trickle IN-QUEUE draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-mmusic-msid IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-rid IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-sdp-simulcast IN-QUEUE draft-ietf-rtcweb-fec IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE J. Uberti, C. Jennings, E. Rescorla, Ed. JavaScript Session Establishment Protocol 256248 Real-Time Communication in WEB-browsers yes draft-ietf-bess-dci-evpn-overlay-10.txt 2018-03-05 MISSREF*R(1G) draft-ietf-idr-tunnel-encaps NOT-RECEIVED J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake Interconnect Solution for EVPN Overlay networks 67427 BGP Enabled Services yes draft-ietf-trill-ecn-support-07.txt 2018-03-12 MISSREF*R(1G) draft-ietf-tsvwg-ecn-encap-guidelines NOT-RECEIVED draft-ietf-tsvwg-ecn-l4s-id NOT-RECEIVED D. Eastlake 3rd, B. Briscoe TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support 33826 Transparent Interconnection of Lots of Links yes draft-ietf-netmod-syslog-model-26.txt 2018-03-16 MISSREF*R(1G) draft-ietf-netconf-keystore NOT-RECEIVED draft-ietf-netconf-tls-client-server NOT-RECEIVED C. Wildes, Ed., K. Koushik, Ed. A YANG Data Model for Syslog Configuration 65515 Network Modeling yes draft-ietf-pim-yang-17.txt 2018-05-16 MISSREF*R(2G) draft-ietf-bfd-yang IN-QUEUE X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, f. Hu A YANG Data Model for Protocol Independent Multicast (PIM) 206487 Protocols for IP Multicast yes draft-ietf-mmusic-rid-15.txt 2018-05-16 REF*R draft-ietf-avtext-rid IN-QUEUE A.B. Roach, Ed. RTP Payload Format Restrictions 61967 Multiparty Multimedia Session Control yes draft-ietf-ice-trickle-21.txt 2018-05-22 E. Ivov, J. Uberti, P. Saint-Andre Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol 74390 Interactive Connectivity Establishment yes draft-ietf-bess-evpn-prefix-advertisement-11.txt 2018-05-24 MISSREF*R(1G) draft-ietf-bess-evpn-inter-subnet-forwarding NOT-RECEIVED J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi IP Prefix Advertisement in EVPN 83101 BGP Enabled Services yes draft-ietf-mmusic-sdp-bundle-negotiation-54.txt 2018-06-18 EDIT*R draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE draft-ietf-mmusic-trickle-ice-sip IN-QUEUE C. Holmberg, H. Alvestrand, C. Jennings Negotiating Media Multiplexing Using the Session Description Protocol (SDP) 147171 Multiparty Multimedia Session Control yes draft-ietf-mmusic-trickle-ice-sip-18.txt 2018-07-02 EDIT*R draft-ietf-ice-trickle IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE E. Ivov, T. Stach, E. Marocco, C. Holmberg A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) 101829 Multiparty Multimedia Session Control yes draft-ietf-mmusic-sdp-simulcast-14.txt 2018-07-10 REF*R draft-ietf-avtext-rid IN-QUEUE draft-ietf-mmusic-rid IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty Using Simulcast in SDP and RTP Sessions 94865 Multiparty Multimedia Session Control yes draft-ietf-ippm-twamp-yang-13.txt 2018-07-11 MISSREF*R(1G) draft-ietf-ippm-metric-registry NOT-RECEIVED R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed. Two-Way Active Measurement Protocol (TWAMP) Data Model 136989 IP Performance Measurement yes draft-ietf-mpls-spring-entropy-label-12.txt 2018-07-16 AUTH48*R http://www.rfc-editor.org/auth48/rfc8662 draft-ietf-spring-segment-routing-mpls IN-QUEUE S. Kini, K. Kompella, S. Sivabalan, S. Litkowski, R. Shakir, J. Tantsura Entropy label for SPRING tunnels 61934 Multiprotocol Label Switching yes draft-ietf-dnssd-hybrid-10.txt 2018-07-19 MISSREF*R(1G) draft-ietf-dnssd-push NOT-RECEIVED S. Cheshire Discovery Proxy for Multicast DNS-Based Service Discovery 82558 Extensions for Scalable DNS Service Discovery yes draft-ietf-bfd-yang-17.txt 2018-08-06 MISSREF*R(1G) draft-ietf-mpls-base-yang NOT-RECEIVED draft-ietf-teas-yang-te NOT-RECEIVED R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky YANG Data Model for Bidirectional Forwarding Detection (BFD) 145281 Bidirectional Forwarding Detection yes draft-ietf-idr-bgp-prefix-sid-27.txt 2018-08-06 AUTH48*R http://www.rfc-editor.org/auth48/rfc8669 draft-ietf-spring-segment-routing-mpls IN-QUEUE S. Previdi, C. Filsfils, A. Lindem, Ed., A. Sreekantiah, H. Gredler Segment Routing Prefix SID extensions for BGP 38276 Inter-Domain Routing yes draft-ietf-spring-segment-routing-ldp-interop-15.txt 2018-09-06 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8661 draft-ietf-spring-segment-routing-mpls IN-QUEUE A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski Segment Routing interworking with LDP 48255 Source Packet Routing in Networking yes draft-ietf-homenet-babel-profile-07.txt 2018-09-10 MISSREF*R(1G) draft-ietf-babel-source-specific NOT-RECEIVED draft-ietf-babel-rfc6126bis NOT-RECEIVED J. Chroboczek Homenet profile of the Babel routing protocol 19874 Home Networking yes draft-ietf-bfcpbis-rfc4583bis-27.txt 2018-12-21 EDIT*R draft-ietf-bfcpbis-rfc4582bis IN-QUEUE draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE G. Camarillo, T. Kristensen, C. Holmberg Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams 48918 Binary Floor Control Protocol Bis yes draft-ietf-ospf-ospfv3-segment-routing-extensions-23.txt 2019-01-11 AUTH48*R http://www.rfc-editor.org/auth48/rfc8666 draft-ietf-ospf-segment-routing-extensions IN-QUEUE draft-ietf-spring-segment-routing-ldp-interop IN-QUEUE draft-ietf-spring-segment-routing-mpls IN-QUEUE P. Psenak, Ed., S. Previdi, Ed. OSPFv3 Extensions for Segment Routing 42346 Link State Routing yes draft-ietf-lisp-rfc8113bis-03.txt 2019-01-28 MISSREF*R(1G) draft-ietf-lisp-rfc6833bis NOT-RECEIVED M. Boucadair, C. Jacquenet Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations 10277 Locator/ID Separation Protocol yes draft-ietf-softwire-yang-16.txt 2019-02-07 RFC-EDITOR*R draft-ietf-softwire-iftunnel IN-QUEUE I. Farrer, Ed., M. Boucadair, Ed. YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires 98207 Softwires yes draft-ietf-pce-segment-routing-16.txt 2019-03-12 AUTH48*R http://www.rfc-editor.org/auth48/rfc8664 draft-ietf-spring-segment-routing-mpls IN-QUEUE S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick PCEP Extensions for Segment Routing 79236 Path Computation Element yes draft-ietf-pce-wson-rwa-ext-17.txt 2019-03-20 MISSREF*R(1G) draft-ietf-pce-gmpls-pcep-extensions NOT-RECEIVED Y. Lee, Ed., R. Casellas, Ed. PCEP Extension for WSON Routing and Wavelength Assignment 62546 Path Computation Element yes draft-ietf-tram-stunbis-21.txt 2019-03-23 AUTH48 http://www.rfc-editor.org/auth48/rfc8489 M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, P. Matthews Session Traversal Utilities for NAT (STUN) 180048 TURN Revised and Modernized yes draft-ietf-idr-bgpls-segment-routing-epe-19.txt 2019-05-20 MISSREF*R(2G) draft-ietf-idr-bgp-ls-segment-routing-ext IN-QUEUE S. Previdi, K. Talaulikar, C. Filsfils, K. Patel, S. Ray, J. Dong BGP-LS extensions for Segment Routing BGP Egress Peer Engineering 38137 Inter-Domain Routing yes draft-ietf-mmusic-data-channel-sdpneg-28.txt 2019-05-21 EDIT*R draft-ietf-mmusic-rfc4566bis IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed. SDP-based Data Channel Negotiation 91932 Multiparty Multimedia Session Control yes draft-ietf-spring-segment-routing-mpls-22.txt 2019-05-28 AUTH48 http://www.rfc-editor.org/auth48/rfc8660 A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski, R. Shakir Segment Routing with MPLS data plane 74196 Source Packet Routing in Networking yes draft-ietf-pce-hierarchy-extensions-11.txt 2019-06-03 RFC-EDITOR F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) 68596 Path Computation Element yes draft-ietf-isis-segment-routing-extensions-25.txt 2019-06-05 AUTH48*R http://www.rfc-editor.org/auth48/rfc8667 draft-ietf-ospf-segment-routing-extensions IN-QUEUE draft-ietf-spring-segment-routing-ldp-interop IN-QUEUE draft-ietf-spring-segment-routing-mpls IN-QUEUE S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene IS-IS Extensions for Segment Routing 63157 Link State Routing yes draft-ietf-perc-private-media-framework-12.txt 2019-06-11 MISSREF*R(1G) draft-ietf-perc-double IN-QUEUE draft-ietf-perc-srtp-ekt-diet NOT-RECEIVED P. Jones, D. Benham, C. Groves A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC) 68797 Privacy Enhanced RTP Conferencing yes draft-ietf-lamps-rfc6844bis-07.txt 2019-06-13 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8659 P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews DNS Certification Authority Authorization (CAA) Resource Record 40105 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-pim-igmp-mld-yang-15.txt 2019-06-17 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8652 X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 96623 Protocols for IP Multicast yes draft-ietf-softwire-iftunnel-07.txt 2019-06-17 AUTH48 http://www.rfc-editor.org/auth48/rfc8675 M. Boucadair, I. Farrer, R. Asati Tunnel Interface Types YANG Module 30775 Softwires yes draft-ietf-softwire-map-radius-26.txt 2019-06-17 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8658 S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms 77229 Softwires yes draft-ietf-tsvwg-tinymt32-06.txt 2019-06-18 RFC-EDITOR M. Saito, M. Matsumoto, V. Roca, E. Baccelli TinyMT32 Pseudo Random Number Generator (PRNG) 24893 Transport Area Working Group yes draft-ietf-tsvwg-rlc-fec-scheme-16.txt 2019-06-20 RFC-EDITOR*R draft-ietf-tsvwg-fecframe-ext IN-QUEUE draft-ietf-tsvwg-tinymt32 IN-QUEUE V. Roca, B. Teibi Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME 94648 Transport Area Working Group yes draft-ietf-tsvwg-fecframe-ext-08.txt 2019-06-20 RFC-EDITOR V. Roca, A. Begen Forward Error Correction (FEC) Framework Extension to Sliding Window Codes 45800 Transport Area Working Group yes draft-ietf-acme-caa-10.txt 2019-06-20 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8657 draft-ietf-lamps-rfc6844bis IN-QUEUE H. Landau CAA Record Extensions for Account URI and ACME Method Binding 23786 Automated Certificate Management Environment yes draft-ietf-mpls-sr-over-ip-07.txt 2019-06-21 AUTH48*R http://www.rfc-editor.org/auth48/rfc8663 draft-ietf-spring-segment-routing-mpls IN-QUEUE X. Xu, S. Bryant, A. Farrel, S. Hassan, W. Henderickx, Z. Li SR-MPLS over IP 43189 Multiprotocol Label Switching yes draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt 2019-07-04 MISSREF*R(1G) draft-ietf-isis-l2bundles IN-QUEUE draft-ietf-isis-segment-routing-extensions IN-QUEUE draft-ietf-lsr-ospf-prefix-originator NOT-RECEIVED draft-ietf-ospf-ospfv3-segment-routing-extensions IN-QUEUE draft-ietf-ospf-segment-routing-extensions IN-QUEUE S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen BGP Link-State extensions for Segment Routing 70095 Inter-Domain Routing yes draft-ietf-roll-useofrplinfo-31.txt 2019-07-11 IESG M. Robles, M. Richardson, P. Thubert Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane 128736 Routing Over Low power and Lossy networks yes draft-ietf-roll-efficient-npdao-16.txt 2019-07-11 IESG R. Jadhav, Ed., P. Thubert, R. Sahoo, Z. Cao Efficient Route Invalidation 55789 Routing Over Low power and Lossy networks yes draft-ietf-rtcweb-ip-handling-12.txt 2019-07-12 EDIT*R draft-ietf-rtcweb-security-arch IN-QUEUE J. Uberti WebRTC IP Address Handling Requirements 26488 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-security-12.txt 2019-07-12 EDIT*R draft-ietf-rtcweb-security-arch IN-QUEUE E. Rescorla Security Considerations for WebRTC 65610 Real-Time Communication in WEB-browsers yes draft-ietf-sipcore-rejected-09.txt 2019-07-16 RFC-EDITOR E. Burger, B. Nagda A Session Initiation Protocol (SIP) Response Code for Rejected Calls 58797 Session Initiation Protocol Core yes draft-ietf-rtcweb-fec-10.txt 2019-07-16 J. Uberti WebRTC Forward Error Correction Requirements 27189 Real-Time Communication in WEB-browsers yes draft-ietf-teas-yang-te-topo-22.txt 2019-07-19 MISSREF*R(1G) draft-ietf-teas-yang-te-types NOT-RECEIVED X. Liu, I. Bryskin, V. Beeram, T. Saad, H. Shah, O. Dios YANG Data Model for Traffic Engineering (TE) Topologies 412706 Traffic Engineering Architecture and Signaling yes draft-ietf-oauth-token-exchange-19.txt 2019-07-21 RFC-EDITOR M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. Mortimore OAuth 2.0 Token Exchange 79303 Web Authorization Protocol yes draft-ietf-mptcp-rfc6824bis-18.txt 2019-07-22 RFC-EDITOR A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch TCP Extensions for Multipath Operation with Multiple Addresses 213934 Multipath TCP yes draft-ietf-lamps-pkix-shake-15.txt 2019-07-22 RFC-EDITOR P. Kampanakis, Q. Dang Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs 34514 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-rtcweb-security-arch-20.txt 2019-07-22 EDIT*R draft-ietf-mmusic-sdp-uks IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-rtcweb-overview IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE E. Rescorla WebRTC Security Architecture 102483 Real-Time Communication in WEB-browsers yes draft-ietf-tram-turnbis-29.txt 2019-07-29 RFC-EDITOR*R draft-ietf-tram-stunbis IN-QUEUE T. Reddy, Ed., A. Johnston, Ed., P. Matthews, J. Rosenberg Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) 235795 TURN Revised and Modernized yes draft-ietf-mpls-egress-protection-framework-07.txt 2019-08-01 RFC-EDITOR*R draft-ietf-isis-segment-routing-extensions IN-QUEUE Y. Shen, M. Jeganathan, B. Decraene, H. Gredler, C. Michel, H. Chen MPLS Egress Protection Framework 74511 Multiprotocol Label Switching yes draft-ietf-pce-association-group-10.txt 2019-08-01 RFC-EDITOR I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships Between Sets of Label Switched Paths (LSPs) 66722 Path Computation Element yes draft-ietf-uta-smtp-require-tls-09.txt 2019-08-05 RFC-EDITOR J. Fenton SMTP Require TLS Option 43858 Using TLS in Applications yes draft-ietf-curdle-gss-keyex-sha2-10.txt 2019-08-07 EDIT*R draft-ietf-curdle-ssh-curves IN-QUEUE S. Sorce, H. Kario GSS-API Key Exchange with SHA2 29362 CURves, Deprecating and a Little more Encryption yes draft-ietf-netconf-restconf-notif-15.txt 2019-08-08 AUTH48 http://www.rfc-editor.org/auth48/rfc8650 E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman Dynamic subscription to YANG Events and Datastores over RESTCONF 53578 Network Configuration yes draft-ietf-ipwave-ipv6-over-80211ocb-52.txt 2019-08-09 EDIT N. Benamar, J. Haerri, J. Lee, T. Ernst Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside the Context of a Basic Service Set 78422 IP Wireless Access in Vehicular Environments yes draft-ietf-mmusic-sdp-uks-07.txt 2019-08-13 REF*R draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE M. Thomson, E. Rescorla Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP) 47406 Multiparty Multimedia Session Control yes draft-ietf-dots-data-channel-31.txt 2019-08-13 MISSREF*R(1G) draft-ietf-dots-signal-channel NOT-RECEIVED M. Boucadair, Ed., K. Reddy, Ed. Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification 134623 DDoS Open Threat Signaling yes draft-ietf-mmusic-ice-sip-sdp-39.txt 2019-08-14 M. Petit-Huguenin, S. Nandakumar, C. Holmberg, A. Keränen, R. Shpount Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) 94766 Multiparty Multimedia Session Control yes draft-ietf-mmusic-rfc4566bis-37.txt 2019-08-20 EDIT*R draft-ietf-mmusic-data-channel-sdpneg IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE A. Begen, P. Kyzivat, C. Perkins, M. Handley SDP: Session Description Protocol 133368 Multiparty Multimedia Session Control yes draft-ietf-grow-bmp-adj-rib-out-07.txt 2019-08-26 AUTH48 http://www.rfc-editor.org/auth48/rfc8671 T. Evens, S. Bayraktar, P. Lucente, P. Mi, S. Zhuang Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) 20514 Global Routing Operations yes draft-ietf-alto-xdom-disc-06.txt 2019-08-26 EDIT S. Kiesel, M. Stiemerling Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery 96725 Application-Layer Traffic Optimization yes draft-ietf-lamps-cms-mix-with-psk-07.txt 2019-08-26 EDIT R. Housley Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) 67448 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-ospf-yang-29.txt 2019-08-26 MISSREF*R(2G) draft-ietf-bfd-yang IN-QUEUE D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem YANG Data Model for OSPF Protocol 234221 Link State Routing yes draft-ietf-ospf-xaf-te-07.txt 2019-08-27 RFC-EDITOR A. Smirnov, A. Retana, M. Barnes OSPF Routing with Cross-Address Family Traffic Engineering Tunnels 19344 Link State Routing yes draft-ietf-perc-double-12.txt 2019-08-29 EDIT C. Jennings, P. Jones, R. Barnes, A. Roach SRTP Double Encryption Procedures 40954 Privacy Enhanced RTP Conferencing yes draft-ietf-mpls-rfc8287-len-clarification-04.txt 2019-08-30 RFC-EDITOR N. Nainar, C. Pignataro, F. Iqbal, A. Vainshtein RFC8287 Sub-TLV Length Clarification 12957 Multiprotocol Label Switching yes draft-ietf-lamps-cms-shakes-18.txt 2019-09-09 EDIT P. Kampanakis, Q. Dang Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) 38531 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-curdle-ssh-curves-12.txt 2019-09-09 EDIT A. Adamantiadis, S. Josefsson, M. Baushke Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 14197 CURves, Deprecating and a Little more Encryption yes draft-ietf-oauth-resource-indicators-08.txt 2019-09-11 RFC-EDITOR B. Campbell, J. Bradley, H. Tschofenig Resource Indicators for OAuth 2.0 31052 Web Authorization Protocol yes draft-ietf-oauth-mtls-17.txt 2019-09-11 EDIT B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens 76781 Web Authorization Protocol yes draft-ietf-curdle-ssh-ed25519-ed448-11.txt 2019-09-16 EDIT B. Harris, L. Velvindron Ed25519 and Ed448 public key algorithms for the Secure Shell (SSH) protocol 12183 CURves, Deprecating and a Little more Encryption yes draft-ietf-manet-dlep-lid-extension-06.txt 2019-09-19 EDIT R. Taylor, S. Ratliff DLEP Link Identifier Extension 17839 Mobile Ad-hoc Networks yes draft-ietf-lsr-isis-rfc5306bis-09.txt 2019-09-20 EDIT L. Ginsberg, P. Wells Restart Signaling for IS-IS 63504 Link State Routing yes draft-ietf-lamps-cms-hash-sig-10.txt 2019-09-23 EDIT R. Housley Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS) 29438 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-core-multipart-ct-04.txt 2019-09-23 EDIT T. Fossati, K. Hartke, C. Bormann Multipart Content-Format for CoAP 20120 Constrained RESTful Environments yes draft-ietf-pim-reserved-bits-04.txt 2019-09-26 EDIT S. Venaas, A. Retana PIM Message Type Space Extension and Reserved Bits 15746 Protocols for IP Multicast yes draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt 2019-09-27 EDIT D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE 81243 Path Computation Element yes draft-ietf-cbor-sequence-02.txt 2019-10-08 EDIT C. Bormann Concise Binary Object Representation (CBOR) Sequences 20388 Concise Binary Object Representation Maintenance and Extensions yes draft-ietf-6lo-deadline-time-05.txt 2019-10-10 MISSREF*R(1G) draft-ietf-6tisch-architecture NOT-RECEIVED L. Thomas, S. Anamalamudi, S. Anand, M. Hegde, C. Perkins Packet Delivery Deadline time in 6LoWPAN Routing Header 47643 IPv6 over Networks of Resource-constrained Nodes yes draft-ietf-acme-ip-08.txt 2019-10-11 EDIT*R draft-ietf-acme-tls-alpn IN-QUEUE R. Shoemaker ACME IP Identifier Validation Extension 10913 Automated Certificate Management Environment yes draft-ietf-acme-tls-alpn-07.txt 2019-10-17 EDIT R. Shoemaker ACME TLS ALPN Challenge Extension 21476 Automated Certificate Management Environment yes draft-ietf-isis-yang-isis-cfg-42.txt 2019-10-17 MISSREF*R(2G) draft-ietf-bfd-yang IN-QUEUE S. Litkowski, D. Yeung, A. Lindem, Z. Zhang, L. Lhotka YANG Data Model for IS-IS Protocol 211538 Link State Routing yes draft-ietf-httpbis-http2-tls13-03.txt 2019-10-21 EDIT D. Benjamin Using TLS 1.3 with HTTP/2 9665 HyperText Transfer Protocol yes draft-ietf-pce-lsp-control-request-11.txt 2019-10-21 EDIT*A A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi Ability for a Stateful Path Computation Element (PCE) to request and obtain control of a Label Switched Path (LSP) 25574 Path Computation Element yes draft-ietf-cbor-array-tags-08.txt 2019-10-21 EDIT C. Bormann Concise Binary Object Representation (CBOR) Tags for Typed Arrays 29480 Concise Binary Object Representation Maintenance and Extensions yes draft-ietf-pce-stateful-path-protection-11.txt 2019-10-22 EDIT*A*R draft-ietf-pce-association-group IN-QUEUE H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi PCEP Extensions for Associating Working and Protection LSPs with Stateful PCE 38266 Path Computation Element yes draft-ietf-6man-segment-routing-header-26.txt 2019-10-24 EDIT*A C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer IPv6 Segment Routing Header (SRH) 65606 IPv6 Maintenance yes draft-ietf-acme-star-11.txt 2019-10-24 EDIT*A Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME) 65201 Automated Certificate Management Environment yes
draft-ietf-rmcat-cc-requirements-09.txt 2014-12-12 EDIT*R draft-ietf-rtcweb-overview IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE 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-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-lwig-cellular-06.txt 2016-01-04 MISSREF*R(1G) draft-ietf-core-resource-directory NOT-RECEIVED J. Arkko, A. Eriksson, A. Keranen Building Power-Efficient CoAP Devices for Cellular Networks 39751 Light-Weight Implementation Guidance yes draft-ietf-rmcat-coupled-cc-09.txt 2017-09-18 EDIT*R draft-ietf-rmcat-nada IN-QUEUE S. Islam, M. Welzl, S. Gjessing Coupled congestion control for RTP media 54076 RTP Media Congestion Avoidance Techniques yes draft-ietf-anima-prefix-management-07.txt 2017-12-19 MISSREF*R(1G) draft-ietf-anima-autonomic-control-plane NOT-RECEIVED draft-ietf-anima-bootstrapping-keyinfra NOT-RECEIVED draft-ietf-anima-grasp IN-QUEUE S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun Autonomic IPv6 Edge Prefix Management in Large-scale Networks 52556 Autonomic Networking Integrated Model and Approach yes draft-ietf-spring-segment-routing-central-epe-10.txt 2017-12-21 MISSREF*R(3G) draft-ietf-idr-bgpls-segment-routing-epe IN-QUEUE C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev Segment Routing Centralized BGP Egress Peer Engineering 35539 Source Packet Routing in Networking yes draft-ietf-mtgvenue-iaoc-venue-selection-process-16.txt 2018-06-15 REF*R draft-ietf-mtgvenue-meeting-policy IN-QUEUE draft-ietf-iasa2-rfc4071bis IN-QUEUE E. Lear, Ed. IETF Plenary Meeting Venue Selection Process 28795 Meeting Venue yes draft-ietf-mtgvenue-meeting-policy-07.txt 2018-08-08 S. Krishnan High level guidance for the meeting policy of the IETF 11311 Meeting Venue yes draft-ietf-taps-minset-11.txt 2018-10-01 MISSREF*R(1G) draft-ietf-taps-transport-security NOT-RECEIVED M. Welzl, S. Gjessing A Minimal Set of Transport Services for End Systems 113475 Transport Services yes draft-ietf-iasa2-trust-rationale-03.txt 2018-11-05 REF*R draft-ietf-iasa2-rfc7437bis IN-QUEUE J. Arkko Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust 13665 IETF Administrative Support Activity 2 yes draft-ietf-iasa2-trust-update-03.txt 2018-11-05 REF*R draft-ietf-iasa2-rfc7437bis IN-QUEUE draft-ietf-iasa2-rfc2031bis IN-QUEUE J. Arkko, T. Hardie Update to the Process for Selection of Trustees for the IETF Trust 10662 IETF Administrative Support Activity 2 yes draft-ietf-anima-reference-model-10.txt 2018-11-24 MISSREF*R(1G) draft-ietf-anima-autonomic-control-plane NOT-RECEIVED draft-ietf-anima-bootstrapping-keyinfra NOT-RECEIVED draft-ietf-anima-grasp IN-QUEUE M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre A Reference Model for Autonomic Networking 72222 Autonomic Networking Integrated Model and Approach yes draft-ietf-spring-segment-routing-msdc-11.txt 2018-11-30 AUTH48*R http://www.rfc-editor.org/auth48/rfc8670 draft-ietf-idr-bgp-prefix-sid IN-QUEUE draft-ietf-spring-segment-routing-central-epe IN-QUEUE C. Filsfils, Ed., S. Previdi, G. Dawra, E. Aries, P. Lapukhov BGP-Prefix Segment in large-scale data centers 45566 Source Packet Routing in Networking yes draft-ietf-httpbis-expect-ct-08.txt 2018-12-21 MISSREF*R(1G) draft-ietf-trans-rfc6962-bis NOT-RECEIVED E. Stark Expect-CT Extension for HTTP 51380 Hypertext Transfer Protocol Bis yes draft-ietf-hip-rfc4423-bis-20.txt 2019-03-23 MISSREF*R(1G) draft-ietf-hip-dex NOT-RECEIVED draft-ietf-hip-native-nat-traversal NOT-RECEIVED R. Moskowitz, Ed., M. Komu Host Identity Protocol Architecture 133290 Host Identity Protocol yes draft-ietf-iasa2-consolidated-upd-07.txt 2019-04-15 EDIT*R draft-ietf-iasa2-rfc7437bis IN-QUEUE draft-ietf-iasa2-rfc4071bis IN-QUEUE draft-ietf-iasa2-trust-rationale IN-QUEUE draft-ietf-iasa2-trust-update IN-QUEUE J. Klensin, Ed. Consolidated IASA 2.0 Updates of IETF Administrative Terminology 22028 IETF Administrative Support Activity 2 yes draft-ietf-iasa2-rfc4071bis-11.txt 2019-04-16 EDIT*R draft-ietf-iasa2-rfc7437bis IN-QUEUE draft-ietf-iasa2-rfc2031bis IN-QUEUE draft-ietf-iasa2-trust-rationale IN-QUEUE draft-ietf-iasa2-trust-update IN-QUEUE B. Haberman, J. Hall, J. Livingood Structure of the IETF Administrative Support Activity, Version 2.0 56221 IETF Administrative Support Activity 2 yes draft-ietf-clue-datachannel-18.txt 2019-04-17 EDIT*R draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-mmusic-data-channel-sdpneg IN-QUEUE C. Holmberg CLUE Protocol data channel 29058 ControLling mUltiple streams for tElepresence yes draft-ietf-sipbrandy-rtpsec-08.txt 2019-05-14 EDIT*R draft-ietf-mmusic-trickle-ice-sip IN-QUEUE J. Peterson, R. Barnes, R. Housley Best Practices for Securing RTP Media Signaled with SIP 35321 SIP Best-practice Recommendations Against Network Dangers to privacY yes draft-ietf-rmcat-eval-test-10.txt 2019-05-30 MISSREF*R(1G) draft-ietf-rmcat-cc-requirements IN-QUEUE draft-ietf-rmcat-eval-criteria NOT-RECEIVED draft-ietf-rmcat-wireless-tests NOT-RECEIVED Z. Sarker, V. Singh, X. Zhu, M. Ramalho Test Cases for Evaluating RMCAT Proposals 68718 RTP Media Congestion Avoidance Techniques yes draft-ietf-v6ops-nat64-deployment-08.txt 2019-07-15 RFC-EDITOR J. Palet Martinez Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks 107856 IPv6 Operations yes draft-ietf-iasa2-rfc7437bis-09.txt 2019-07-15 EDIT*R draft-ietf-iasa2-consolidated-upd IN-QUEUE draft-ietf-iasa2-rfc4071bis IN-QUEUE draft-ietf-iasa2-trust-update IN-QUEUE M. Kucherawy, Ed., B. Hinden, Ed., J. Livingood, Ed. IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees 92279 IETF Administrative Support Activity 2 yes draft-ietf-dmm-ondemand-mobility-18.txt 2019-08-06 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8653 A. Yegin, D. Moses, S. Jeon On Demand Mobility Management 28305 Distributed Mobility Management yes draft-ietf-pce-inter-area-as-applicability-08.txt 2019-08-14 EDIT D. King, H. Zheng Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering 58215 Path Computation Element yes draft-ietf-rtgwg-enterprise-pa-multihoming-12.txt 2019-08-19 EDIT F. Baker, C. Bowers, J. Linkova Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions 136566 Routing Area Working Group yes draft-ietf-tls-grease-04.txt 2019-08-26 EDIT D. Benjamin Applying GREASE to TLS Extensibility 28058 Transport Layer Security yes draft-ietf-httpbis-rand-access-live-04.txt 2019-08-26 RFC-EDITOR C. Pratt, D. Thakore, B. Stark HTTP Random Access and Live Content 24451 Hypertext Transfer Protocol Bis yes draft-ietf-iasa2-rfc2031bis-08.txt 2019-08-26 EDIT*R draft-ietf-iasa2-rfc4071bis IN-QUEUE G. Camarillo, J. Livingood The IETF-ISOC Relationship 19367 IETF Administrative Support Activity 2 yes draft-ietf-opsec-urpf-improvements-04.txt 2019-09-03 RFC-EDITOR K. Sriram, D. Montgomery, J. Haas Enhanced Feasible-Path Unicast Reverse Path Forwarding 47806 Operational Security Capabilities for IP Network Infrastructure yes draft-ietf-rmcat-nada-13.txt 2019-09-09 EDIT X. Zhu, R. Pan, M. Ramalho, S. de la Cruz NADA: A Unified Congestion Control Scheme for Real-Time Media 69331 RTP Media Congestion Avoidance Techniques yes draft-ietf-iasa2-rfc5377bis-03.txt 2019-09-09 EDIT J. Halpern, Ed. Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents 18725 IETF Administrative Support Activity 2 yes draft-ietf-iasa2-rfc7776bis-03.txt 2019-09-16 EDIT*R draft-ietf-iasa2-rfc7437bis IN-QUEUE P. Resnick, A. Farrel Update to the IETF Anti-Harassment Procedures for the Replacement of the IAOC with the IETF Administration LLC 11172 IETF Administrative Support Activity 2 yes draft-ietf-curdle-rc4-die-die-die-17.txt 2019-09-23 EDIT L. Velvindron Deprecating RC4 in Secure Shell (SSH) 8963 CURves, Deprecating and a Little more Encryption yes draft-ietf-intarea-frag-fragile-17.txt 2019-10-10 MISSREF*R(1G) draft-ietf-tsvwg-datagram-plpmtud NOT-RECEIVED R. Bonica, F. Baker, G. Huston, B. Hinden, O. Trøan, F. Gont IP Fragmentation Considered Fragile 62382 Internet Area Working Group yes draft-ietf-oauth-jwt-bcp-07.txt 2019-10-21 EDIT Y. Sheffer, D. Hardt, M. Jones JSON Web Token Best Current Practices 35473 Web Authorization Protocol yes draft-ietf-pce-stateful-hpce-15.txt 2019-10-22 EDIT D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King Hierarchical Stateful Path Computation Element (PCE) 55491 Path Computation Element yes
draft-iab-rfc7500-bis-00.txt 2019-08-21 EDIT R. Housley, Ed., O. Kolkman, Ed. Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries 16958 IAB yes draft-iab-fiftyyears-01.txt 2019-09-04 EDIT H. Flanagan, Ed. Fifty Years of RFCs 68929 IAB yes
draft-ribose-asciirfc-08.txt 2018-04-19 AUTH R. Tse, N. Nicholas, J. Lau, P. Brasolin draft-ribose-asciirfc-08 287041 INDEPENDENT N/A draft-kanugovi-intarea-mams-framework-04.txt 2019-05-31 EDIT S. Kanugovi, F. Baboescu, J. Zhu, J. Mueller, S. Seo Multiple Access Management Services 271727 INDEPENDENT N/A draft-jenkins-cnsa-cmc-profile-05.txt 2019-06-12 MISSREF*R(1G) draft-jenkins-cnsa-smime-profile NOT-RECEIVED M. Jenkins, L. Zieglar Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS 45324 INDEPENDENT N/A draft-trossen-sfc-name-based-sff-07.txt 2019-07-05 RFC-EDITOR D. Trossen, D. Purkayastha, A. Rahman Name-Based Service Function Forwarder (nSFF) component within SFC framework 72810 INDEPENDENT N/A draft-aranda-dispatch-q4s-10.txt 2019-07-17 MISSREF*R(1G) draft-ietf-quic-invariants NOT-RECEIVED J. Aranda, M. Cortes, J. Salvachua, M. Narganes, I. Sarriegui The Quality for Service Protocol 182791 INDEPENDENT N/A draft-sheffer-tls-pinning-ticket-12.txt 2019-08-12 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8672 Y. Sheffer, D. Migault TLS Server Identity Pinning with Tickets 66249 INDEPENDENT N/A draft-sekar-dns-llq-06.txt 2019-08-23 MISSREF*R(1G) draft-ietf-dnssd-push NOT-RECEIVED S. Cheshire, M. Krochmal Apple's DNS Long-Lived Queries protocol 50905 INDEPENDENT N/A draft-nottingham-safe-hint-11.txt 2019-08-29 RFC-EDITOR M. Nottingham The "safe" HTTP Preference 18098 INDEPENDENT yes draft-ise-iana-policy-03.txt 2019-09-23 EDIT A. Farrel How Requests for IANA Action Will be Handled on the Independent Stream 11295 INDEPENDENT N/A draft-bruckert-brainpool-for-tls13-07.txt 2019-09-26 EDIT L. Bruckert, J. Merkle, M. Lochter ECC Brainpool Curves for Transport Layer Security (TLS) Version 1.3 20470 INDEPENDENT N/A
./draft-ietf-isis-segment-routing-extensions-25.txt0000644000764400076440000017326513470416760021676 0ustar iustyiusty IS-IS for IP Internets S. Previdi, Ed. Internet-Draft Huawei Intended status: Standards Track L. Ginsberg, Ed. Expires: November 20, 2019 C. Filsfils Cisco Systems, Inc. A. Bashandy Arrcus H. Gredler RtBrick Inc. B. Decraene Orange May 19, 2019 IS-IS Extensions for Segment Routing draft-ietf-isis-segment-routing-extensions-25 Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 https://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 Previdi, et al. Expires November 20, 2019 [Page 1] Internet-Draft IS-IS Extensions for Segment Routing May 2019 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 20, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . 4 2.1.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Prefix-SID Propagation . . . . . . . . . . . . . . . 8 2.2. Adjacency Segment Identifier . . . . . . . . . . . . . . 8 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . 9 2.2.2. Adjacency Segment Identifiers in LANs . . . . . . . . 10 2.3. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 2.4. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 13 2.4.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.2. Range . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.3. Prefix Length, Prefix . . . . . . . . . . . . . . . . 15 2.4.4. Mapping Server Prefix-SID . . . . . . . . . . . . . . 15 2.4.5. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 16 2.4.6. Example Encodings . . . . . . . . . . . . . . . . . . 16 2.5. Multi-Topology SID/Label Binding TLV . . . . . . . . . . 18 3. Router Capabilities . . . . . . . . . . . . . . . . . . . . . 19 3.1. SR-Capabilities Sub-TLV . . . . . . . . . . . . . . . . . 19 3.2. SR-Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 22 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 23 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 25 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 . . . . . . . 26 4.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 26 4.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 26 Previdi, et al. Expires November 20, 2019 [Page 2] Internet-Draft IS-IS Extensions for Segment Routing May 2019 4.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Prefix segments represent an ECMP-aware shortest-path to a prefix (or a node), as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most of the cases, is a one-hop path. SR's control-plane can be applied to both IPv6 and MPLS data-planes, and does not require any additional signaling (other than the regular IGP). For example, when used in MPLS networks, SR paths do not require any LDP or RSVP-TE signaling. Still, SR can interoperate in the presence of LSPs established with RSVP or LDP. There are additional segment types, e.g., Binding SID defined in [RFC8402]. This document also defines an advertisement for one type of Binding SID: the Mirror Context segment. This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. The Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are described in [RFC7855]. 2. Segment Routing Identifiers The Segment Routing architecture [RFC8402] defines different types of Segment Identifiers (SID). This document defines the IS-IS encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN- Adjacency Segment and the Binding Segment. Previdi, et al. Expires November 20, 2019 [Page 3] Internet-Draft IS-IS Extensions for Segment Routing May 2019 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV (Prefix-SID sub-TLV). The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as defined in [RFC8402]. The 'Prefix SID' MUST be unique within a given IGP domain (when the L-flag is not set). A Prefix-SID sub-TLV is associated to a prefix advertised by a node and MAY be present in any of the following TLVs: TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. Binding-TLV and Multi-Topology Binding-TLV defined in Section 2.4 and Section 2.5 respectively. The Prefix-SID 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 | Length | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 3 Length: 5 or 6 depending on the size of the SID (described below) Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R|N|P|E|V|L| | +-+-+-+-+-+-+-+-+ where: Previdi, et al. Expires November 20, 2019 [Page 4] Internet-Draft IS-IS Extensions for Segment Routing May 2019 R-Flag: Re-advertisement flag. If set, then the prefix to which this Prefix-SID is attached, has been propagated by the router either from another level (i.e., from level-1 to level-2 or the opposite) or from redistribution (e.g.: from another protocol). N-Flag: Node-SID flag. If set, then the Prefix-SID refers to the router identified by the prefix. Typically, the N-Flag is set on Prefix-SIDs attached to a router loopback address. The N-Flag is set when the Prefix-SID is a Node-SID as described in [RFC8402]. P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT pop the Prefix-SID before delivering the packet to the node that advertised the Prefix-SID. E-Flag: Explicit-Null Flag. If set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with a Prefix-SID having an Explicit-NULL value (0 for IPv4 and 2 for IPv6) before forwarding the packet. V-Flag: Value flag. If set, then the Prefix-SID carries a value (instead of an index). By default the flag is UNSET. L-Flag: Local Flag. If set, then the value/index carried by the Prefix-SID has local significance. By default the flag is UNSET. Other bits: MUST be zero when originated and ignored when received. Algorithm: the router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these nodes. Algorithm identifiers are defined in Section 3.2. Examples of these algorithms are metric based Shortest Path First (SPF), various sorts of Constrained SPF, etc. The algorithm field of the Prefix-SID contains the identifier of the algorithm the router uses to compute the reachability of the prefix to which the Prefix-SID is associated. At origination, the Prefix-SID algorithm field MUST be set to 0 or to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). A router receiving a Prefix-SID from a remote node and with an algorithm value that such remote node has not advertised in the SR-Algorithm sub-TLV (Section 3.2) MUST ignore the Prefix-SID sub- TLV. Previdi, et al. Expires November 20, 2019 [Page 5] Internet-Draft IS-IS Extensions for Segment Routing May 2019 SID/Index/Label as defined in Section 2.1.1.1. When the Prefix SID is an index (the V-flag is not set) the value is used to determine the actual label value inside the set of all advertised label ranges of a given router. This allows a receiving router to construct forwarding state to a particular destination router. In many use-cases a 'stable transport' address is overloaded as an identifier of a given node. Because Prefixes may be re-advertised into other levels there may be some ambiguity (e.g. Originating router vs. L1L2 router) for which node a particular IP prefix serves as identifier. The Prefix-SID sub-TLV contains the necessary flags to disambiguate Prefix to node mappings. Furthermore if a given node has several 'stable transport' addresses there are flags to differentiate those among other Prefixes advertised from a given node. 2.1.1. Flags 2.1.1.1. V and L Flags The V-flag indicates whether the SID/Index/Label field is a value or an index. The L-Flag indicates whether the value/index in the SID/Index/Label field has local or global significance. The following settings for V and L flags are valid: V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field is a 4 octet index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1. V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field is a 3 octet local label where the 20 rightmost bits are used for encoding the label value. All other combinations of V-flag and L-flag are invalid and any SID advertisement received with an invalid setting for V and L flags MUST be ignored. 2.1.1.2. R and N Flags The R-Flag MUST be set for prefixes that are not local to the router and either: advertised because of propagation (Level-1 into Level-2); Previdi, et al. Expires November 20, 2019 [Page 6] Internet-Draft IS-IS Extensions for Segment Routing May 2019 advertised because of leaking (Level-2 into Level-1); advertised because of redistribution (e.g.: from another protocol). In the case where a Level-1-2 router has local interface addresses configured in one level, it may also propagate these addresses into the other level. In such case, the Level-1-2 router MUST NOT set the R bit. The N-Flag is used in order to define a Node-SID. A router MAY set the N-Flag only if all of the following conditions are met: The prefix to which the Prefix-SID is attached is local to the router (i.e., the prefix is configured on one of the local interfaces, e.g., a 'stable transport' loopback). The prefix to which the Prefix-SID is attached has a Prefix length of either /32 (IPv4) or /128 (IPv6). The router MUST ignore the N-Flag on a received Prefix-SID if the prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). The Prefix Attributes Flags sub-TLV [RFC7794] also defines the N and R flags and with the same semantics of the equivalent flags defined in this document. Whenever the Prefix Attributes Flags sub-TLV is present for a given prefix the values of the N and R flags advertised in that sub-TLV MUST be used and the values in a corresponding Prefix SID sub-TLV (if present) MUST be ignored. 2.1.1.3. E and P Flags The following behavior is associated with the settings of the E and P flags: o If the P-flag is not set then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane which improves performance of the ultimate hop. MPLS EXP bits of the Prefix-SID are not preserved to the ultimate hop (the Prefix-SID being removed). If the P-flag is unset the received E-flag is ignored. o If the P-flag is set then: * If the E-flag is not set then any upstream neighbor of the Prefix-SID originator MUST keep the Prefix-SID on top of the stack. This is useful when, e.g., the originator of the Previdi, et al. Expires November 20, 2019 [Page 7] Internet-Draft IS-IS Extensions for Segment Routing May 2019 Prefix-SID must stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at an inter-area border router (prefix propagation from one area to another) or at an inter-domain border router (prefix propagation from one domain to another). * If the E-flag is set then any upstream neighbor of the Prefix- SID originator MUST replace the PrefixSID with a Prefix-SID having an Explicit-NULL value. This is useful, e.g., when the originator of the Prefix-SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. When propagating (either from Level-1 to Level-2 or vice versa) a reachability advertisement originated by another IS-IS speaker, the router MUST set the P-flag and MUST clear the E-flag of the related Prefix-SIDs. 2.1.2. Prefix-SID Propagation The Prefix-SID sub-TLV MUST be included when the associated Prefix Reachability TLV is propagated across level boundaries. The level-1-2 router that propagates the Prefix-SID sub-TLV between levels maintains the content (flags and SID) except as noted in Section 2.1.1.2 and Section 2.1.1.3. 2.2. Adjacency Segment Identifier A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier sub- TLV (Adj-SID sub-TLV). The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment Routing IGP-Adjacency-SID as defined in [RFC8402] with flags and fields that may be used, in future extensions of Segment Routing, for carrying other types of SIDs. IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs below: TLV-22 (Extended IS reachability)[RFC5305] TLV-222 (Multitopology IS)[RFC5120] TLV-23 (IS Neighbor Attribute)[RFC5311] TLV-223 (Multitopology IS Neighbor Attribute)[RFC5311] Previdi, et al. Expires November 20, 2019 [Page 8] Internet-Draft IS-IS Extensions for Segment Routing May 2019 TLV-141 (inter-AS reachability information)[RFC5316] Multiple Adj-SID sub-TLVs MAY be associated with a single IS- neighbor. 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV The following format is defined for the Adj-SID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 31 Length: 5 or 6 depending on size of the SID Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|B|V|L|S|P| | +-+-+-+-+-+-+-+-+ where: F-Flag: Address-Family flag. If unset, then the Adj-SID is used when forwarding IPv4 encapsulated traffic to the neighbor. If set then the Adj-SID is used when forwarding IPv6 encapsulated traffic to the neighbor. B-Flag: Backup flag. If set, the Adj-SID is eligible for protection (e.g.: using IPFRR or MPLS-FRR) as described in [RFC8402]. V-Flag: Value flag. If set, then the Adj-SID carries a value. By default the flag is SET. L-Flag: Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. Previdi, et al. Expires November 20, 2019 [Page 9] Internet-Draft IS-IS Extensions for Segment Routing May 2019 S-Flag. Set flag. When set, the S-Flag indicates that the Adj-SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well). P-Flag. Persistent flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap. Other bits: MUST be zero when originated and ignored when received. Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [RFC8402]. SID/Index/Label as defined in Section 2.1.1.1. An SR capable router MAY allocate an Adj-SID for each of its adjacencies An SR capable router MAY allocate more than one Adj-SID to an adjacency. An SR capable router MAY allocate the same Adj-SID to different adjacencies. When the P-flag is not set, the Adj-SID MAY be persistent. When the P-flag is set, the Adj-SID MUST be persistent. Examples of use of the Adj-SID sub-TLV are described in [RFC8402]. The F-flag is used in order for the router to advertise the outgoing encapsulation of the adjacency the Adj-SID is attached to. 2.2.2. Adjacency Segment Identifiers in LANs In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the Pseudonode-LSP (PN-LSP) including all neighbors of the DIS. When Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its neighbors. Since, on LANs, each router only advertises one adjacency to the DIS (and doesn't advertise any other adjacency), each router advertises the set of Adj-SIDs (for each of its neighbors) inside a newly defined sub-TLV part of the TLV advertising the adjacency to the DIS (e.g.: TLV-22). Previdi, et al. Expires November 20, 2019 [Page 10] Internet-Draft IS-IS Extensions for Segment Routing May 2019 The following new sub-TLV is defined: LAN-Adj-SID containing the set of Adj-SIDs the router assigned to each of its LAN neighbors. The format of the LAN-Adj-SID sub-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor System-ID (ID length octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 32 Length: variable. Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|B|V|L|S|P| | +-+-+-+-+-+-+-+-+ where F, B, V, L, S and P flags are defined in Section 2.2.1. Other bits: MUST be zero when originated and ignored when received. Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [RFC8402]. Neighbor System-ID: IS-IS System-ID of length "ID Length" as defined in [ISO10589]. SID/Index/Label as defined in Section 2.1.1.1. Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Previdi, et al. Expires November 20, 2019 [Page 11] Internet-Draft IS-IS Extensions for Segment Routing May 2019 Note that this sub-TLV MUST NOT appear in TLV 141. In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple advertisements of the adjacency to the DIS MUST be used and all advertisements MUST have the same metric. Each router within the level, by receiving the DIS PN LSP as well as the non-PN LSP of each router in the LAN, is capable of reconstructing the LAN topology as well as the set of Adj-SIDs each router uses for each of its neighbors. 2.3. SID/Label Sub-TLV The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs defined in this document: SR-Capabilities Sub-TLV (Section 3.1) SR Local Block Sub-TLV (Section 3.3) SID/Label Binding TLV (Section 2.4) Multi-Topology SID/Label Binding TLV (Section 2.5) Note that the code point used in all of the above cases is the SID/ Label Sub-TLV code point specified in the new "sub-TLVs for TLV 149 and 150" registry created by this document. The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 1 Length: 3 or 4 Previdi, et al. Expires November 20, 2019 [Page 12] Internet-Draft IS-IS Extensions for Segment Routing May 2019 SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label. If length is set to 4 then the value is a 32 bit index 2.4. SID/Label Binding TLV The SID/Label Binding TLV MAY be originated by any router in an IS-IS domain. There are multiple uses of the SID/Label Binding TLV. The SID/Label Binding TLV may be used to advertise prefixes to SID/ Label mappings. This functionality is called the Segment Routing Mapping Server (SRMS). The behavior of the SRMS is defined in [I-D.ietf-spring-segment-routing-ldp-interop]. The SID/Label Binding TLV may also be used to advertise a Mirror SID to advertise the ability to process traffic originally destined to another IGP node. This behavior is defined in [RFC8402]. The SID/Label Binding 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 | Length | Flags | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range | Prefix Length | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Prefix (continued, variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SID/Label Binding TLV format o Type: 149 o Length: variable. o 1 octet of flags o 1 octet of RESERVED (SHOULD be transmitted as 0 and MUST be ignored on receipt) o 2 octets of Range o 1 octet of Prefix Length o 0-16 octets of Prefix Previdi, et al. Expires November 20, 2019 [Page 13] Internet-Draft IS-IS Extensions for Segment Routing May 2019 o sub-TLVs, where each sub-TLV consists of a sequence of: * 1 octet of sub-TLV type * 1 octet of length of the value field of the sub-TLV * 0-243 octets of value 2.4.1. Flags Flags: 1 octet field of following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|M|S|D|A| | +-+-+-+-+-+-+-+-+ where: F-Flag: Address Family flag. If unset, then the Prefix carries an IPv4 Prefix. If set then the Prefix carries an IPv6 Prefix. M-Flag: Mirror Context flag. Set if the advertised SID corresponds to a mirrored context. The use of a mirrored context is described in [RFC8402]. S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across the entire routing domain. If the S flag is not set, the SID/ Label Binding TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking. D-Flag: when the SID/Label Binding TLV is leaked from level-2 to level-1, the D-Flag MUST be set. Otherwise, this flag MUST be clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping across levels. A-Flag: Attached flag. The originator of the SID/Label Binding TLV MAY set the A bit in order to signal that the prefixes and SIDs advertised in the SID/Label Binding TLV are directly connected to their originators. The mechanisms through which the originator of the SID/Label Binding TLV can figure out if a prefix is attached or not are outside the scope of this document (e.g.: through explicit configuration). If the Binding TLV is leaked to other areas/levels the A-flag MUST be cleared. An implementation may decide not to honor the S-flag in order not to leak Binding TLV's between levels (for policy reasons). Previdi, et al. Expires November 20, 2019 [Page 14] Internet-Draft IS-IS Extensions for Segment Routing May 2019 Other bits: MUST be zero when originated and ignored when received. 2.4.2. Range The 'Range' field provides the ability to specify a range of addresses and their associated Prefix SIDs. This advertisement supports the SRMS functionality. It is essentially a compression scheme to distribute a continuous Prefix and their continuous, corresponding SID/Label Block. If a single SID is advertised then the range field MUST be set to one. For range advertisements > 1, the range field MUST be set to the number of addresses that need to be mapped into a Prefix-SID. In either case the prefix is the first address to which a SID is to be assigned. 2.4.3. Prefix Length, Prefix The 'Prefix' represents the Forwarding equivalence class at the tail- end of the advertised path. The 'Prefix' does not need to correspond to a routable prefix of the originating node. The 'Prefix Length' field contains the length of the prefix in bits. Only the most significant octets of the Prefix are encoded (i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). 2.4.4. Mapping Server Prefix-SID The Prefix-SID sub-TLV is defined in Section 2.1 and contains the SID/index/label value associated with the prefix and range. The Prefix-SID Sub-TLV MUST be present in the SID/Label Binding TLV when the M-flag is clear. The Prefix-SID Sub-TLV MUST NOT be present when the M-flag is set. 2.4.4.1. Prefix-SID Flags The Prefix-SID flags are defined in Section 2.1. The Mapping Server MAY advertise a mapping with the N flag set when the prefix being mapped is known in the link-state topology with a mask length of 32 (IPv4) or 128 (IPv6) and when the prefix represents a node. The mechanisms through which the operator defines that a prefix represents a node are outside the scope of this document (typically it will be through configuration). The other flags defined in Section 2.1 are not used by the Mapping Server and MUST be ignored at reception. Previdi, et al. Expires November 20, 2019 [Page 15] Internet-Draft IS-IS Extensions for Segment Routing May 2019 2.4.4.2. PHP Behavior when using Mapping Server Advertisements As the mapping server does not specify the originator of a prefix advertisement it is not possible to determine PHP behavior solely based on the Mapping Server Advertisement. However, if additional information is available PHP behavior may safely be done. The required information consists of: o A prefix reachability advertisement for the prefix has been received which includes the Prefix Attribute Flags sub-TLV [RFC7794]. o X and R flags are both set to 0 in the Prefix Attribute Flags sub- TLV. In the absence of an Prefix Attribute Flags sub-TLV [RFC7794] the A flag in the binding TLV indicates that the originator of a prefix reachability advertisement is directly connected to the prefix and thus PHP MUST be done by the neighbors of the router originating the prefix reachability advertisement. Note that A-flag is only valid in the original area in which the Binding TLV is advertised. 2.4.4.3. Prefix-SID Algorithm The algorithm field contains the identifier of the algorithm associated with the SIDs for the prefix(es) in the range. Use of the algorithm field is described in Section 2.1. 2.4.5. SID/Label Sub-TLV The SID/Label sub-TLV (Type: 1) contains the SID/Label value as defined in Section 2.3. It MUST be present in the SID/Label Binding TLV when the M-flag is set in the Flags field of the parent TLV. 2.4.6. Example Encodings Example 1: if the following IPv4 router addresses (loopback addresses) need to be mapped into the corresponding Prefix SID indexes. Router-A: 192.0.2.1/32, Prefix-SID: Index 1 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 Previdi, et al. Expires November 20, 2019 [Page 16] Internet-Draft IS-IS Extensions for Segment Routing May 2019 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 |0|0|0|0|0| | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 4 | 32 | 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 2 | 1 |Prefix-SID Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Length| Flags | Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example-2: If the following IPv4 prefixes need to be mapped into the corresponding Prefix-SID indexes: 10.1.1/24, Prefix-SID: Index 51 10.1.2/24, Prefix-SID: Index 52 10.1.3/24, Prefix-SID: Index 53 10.1.4/24, Prefix-SID: Index 54 10.1.5/24, Prefix-SID: Index 55 10.1.6/24, Prefix-SID: Index 56 10.1.7/24, Prefix-SID: Index 57 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 |0|0|0|0|0| | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 7 | 24 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 1 |Prefix-SID Type| sub-TLV Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 51 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example-3: If the following IPv6 prefixes need to be mapped into the corresponding Prefix-SID indexes: 2001:db8:1/48, Prefix-SID: Index 151 2001:db8:2/48, Prefix-SID: Index 152 2001:db8:3/48, Prefix-SID: Index 153 2001:db8:4/48, Prefix-SID: Index 154 Previdi, et al. Expires November 20, 2019 [Page 17] Internet-Draft IS-IS Extensions for Segment Routing May 2019 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 |1|0|0|0|0| | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 4 | 48 | 0x20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x0d | 0xb8 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 |Prefix-SID Type| sub-TLV Length| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 151 | +-+-+-+-+-+-+-+-+ It is not expected that a network operator will be able to keep fully continuous Prefix / SID/Index mappings. In order to support noncontinuous mapping ranges an implementation MAY generate several instances of Binding TLVs. For example if a router wants to advertise the following ranges: Range 16: { 192.0.2.1-15, Index 1-15 } Range 6: { 192.0.2.22-27, Index 22-27 } Range 41: { 192.0.2.44-84, Index 80-120 } A router would need to advertise three instances of the Binding TLV. 2.5. Multi-Topology SID/Label Binding TLV The Multi-Topology SID/Label Binding TLV allows the support of M-ISIS as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV has the same format as the SID/Label Binding TLV defined in Section 2.4 with the difference consisting of a Multitopology Identifier (MTID) as defined here below: Previdi, et al. Expires November 20, 2019 [Page 18] Internet-Draft IS-IS Extensions for Segment Routing May 2019 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 | MTID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | RESERVED | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Multi-Topology SID/Label Binding TLV format where: Type: 150 Length: variable MTID is the multitopology identifier defined as: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESVD | MTID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RESVD: reserved bits. MUST be reset on transmission and ignored on receive. MTID: a 12-bit field containing the non-zero ID of the topology being announced. The TLV MUST be ignored if the ID is zero. This is to ensure the consistent view of the standard unicast topology. The other fields and Sub-TLVs are defined in Section 2.4. 3. Router Capabilities This section defines sub-TLVs which are inserted into the IS-IS Router Capability TLV-242 that is defined in [RFC7981]. 3.1. SR-Capabilities Sub-TLV Segment Routing requires each router to advertise its SR data-plane capability and the range of MPLS label values it uses for Segment Routing in the case where global SIDs are allocated (i.e., global Previdi, et al. Expires November 20, 2019 [Page 19] Internet-Draft IS-IS Extensions for Segment Routing May 2019 indexes). Data-plane capabilities and label ranges are advertised using the newly defined SR-Capabilities sub-TLV. The Router Capability TLV specifies flags that control its advertisement. The SR Capabilities sub-TLV MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. Therefore Router Capability TLV distribution flags are set accordingly, i.e., the S flag in the Router Capability TLV [RFC7981] MUST be unset. The SR Capabilities sub-TLV has 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 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SID/Label Sub-TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 2 Length: variable. Flags: 1 octet of flags. The following are defined: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|V| | +-+-+-+-+-+-+-+-+ where: I-Flag: MPLS IPv4 flag. If set, then the router is capable of processing SR MPLS encapsulated IPv4 packets on all interfaces. V-Flag: MPLS IPv6 flag. If set, then the router is capable of processing SR MPLS encapsulated IPv6 packets on all interfaces. One or more SRGB Descriptor entries, each of which have the following format: Range: 3 octets. Previdi, et al. Expires November 20, 2019 [Page 20] Internet-Draft IS-IS Extensions for Segment Routing May 2019 SID/Label sub-TLV (as defined in Section 2.3). SID/Label sub-TLV contains the first value of the SRGB while the range contains the number of SRGB elements. The range value MUST be higher than 0. The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number but a router MUST NOT advertise more than one SR-Capabilities sub- TLV. A router receiving multiple SR-Capabilities sub-TLVs from the same originator SHOULD select the first advertisement in the lowest numbered LSP. When multiple SRGB Descriptors are advertised the entries define an ordered set of ranges on which a SID index is to be applied. For this reason changing the order in which the descriptors are advertised will have a disruptive effect on forwarding. When a router adds a new SRGB Descriptor to an existing SR- Capabilities sub-TLV the new Descriptor SHOULD add the newly configured block at the end of the sub-TLV and SHOULD NOT change the order of previously advertised blocks. Changing the order of the advertised descriptors will create label churn in the FIB and blackhole / misdirect some traffic during the IGP convergence. In particular, if a range which is not the last is extended it's preferable to add a new range rather than extending the previously advertised range. The originating router MUST ensure the order is unchanged after a graceful restart (using checkpointing, non-volatile storage or any other mechanism). The originating router MUST NOT advertise overlapping ranges. When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. Here follows an example of advertisement of multiple ranges: Previdi, et al. Expires November 20, 2019 [Page 21] Internet-Draft IS-IS Extensions for Segment Routing May 2019 The originating router advertises following ranges: SR-Cap: range: 100, SID value: 100 SR-Cap: range: 100, SID value: 1000 SR-Cap: range: 100, SID value: 500 The receiving routers concatenate the ranges in the received order and build the SRGB as follows: SRGB = [100, 199] [1000, 1099] [500, 599] The indexes span multiple ranges: index=0 means label 100 ... index 99 means label 199 index 100 means label 1000 index 199 means label 1099 ... index 200 means label 500 ... 3.2. SR-Algorithm Sub-TLV The router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these nodes. Examples of these algorithms are metric based Shortest Path First (SPF), various sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the router to advertise the algorithms that the router is currently using. Algorithm values are defined in the "IGP Algorithm Type" registry defined in [I-D.ietf-ospf-segment-routing-extensions]. The following values have been defined: 0: Shortest Path First (SPF) algorithm based on link metric. This is the well-known shortest path algorithm as computed by the IS-IS Decision process. Consistent with the deployed practice for link- state protocols, algorithm 0 permits any node to overwrite the SPF path with a different path based on local policy. 1: Strict Shortest Path First (SPF) algorithm based on link metric. The algorithm is identical to algorithm 0 but algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy MUST NOT alter the forwarding decision computed by algorithm 1 at the node claiming to support algorithm 1. Previdi, et al. Expires November 20, 2019 [Page 22] Internet-Draft IS-IS Extensions for Segment Routing May 2019 The Router Capability TLV specifies flags that control its advertisement. The SR-Algorithm MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. Therefore Router Capability TLV distribution flags are set accordingly, i.e., the S flag MUST be unset. The SR-Algorithm sub-TLV is optional. It MUST NOT be advertsied more than once at a given level. A router receiving multiple SR-Algorithm sub-TLVs from the same originator SHOULD select the first advertisement in the lowest numbered LSP. When the originating router does not advertise the SR-Algorithm sub- TLV, this implies that the only algorithm supported by routers supporting the extensions defined in this document is Algorithm 0. When the originating router does advertise the SR-Algorithm sub-TLV, then algorithm 0 MUST be present while non-zero algorithms MAY be present. The SR-Algorithm 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 19 Length: variable. Algorithm: 1 octet of algorithm 3.3. SR Local Block Sub-TLV The SR Local Block (SRLB) Sub-TLV contains the range of labels the node has reserved for local SIDs. Local SIDs are used, e.g., for Adjacency-SIDs, and may also be allocated by components other than the IS-IS protocol. As an example, an application or a controller may instruct the router to allocate a specific local SID. Therefore, in order for such applications or controllers to know what are the local SIDs available in the router, it is required that the router advertises its SRLB. Previdi, et al. Expires November 20, 2019 [Page 23] Internet-Draft IS-IS Extensions for Segment Routing May 2019 The SRLB Sub-TLV is used for this purpose and has 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 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SID/Label Sub-TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 22 Length: variable. Flags: 1 octet of flags. None are defined at this stage. One or more SRLB Descriptor entries, each of which have the following format: Range: 3 octets. SID/Label sub-TLV (as defined in Section 2.3). SID/Label sub-TLV contains the first value of the SRLB while the range contains the number of SRLB elements. The range value MUST be higher than 0. The SRLB sub-TLV MAY be advertised in an LSP of any number but a router MUST NOT advertise more than one SRLB sub-TLV. A router receiving multiple SRLB sub-TLVs, from the same originator, SHOULD select the first advertisement in the lowest numbered LSP. The originating router MUST NOT advertise overlapping ranges. When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. It is important to note that each time a SID from the SRLB is allocated, it should also be reported to all components (e.g.: controller or applications) in order for these components to have an up-to-date view of the current SRLB allocation and in order to avoid collision between allocation instructions. Previdi, et al. Expires November 20, 2019 [Page 24] Internet-Draft IS-IS Extensions for Segment Routing May 2019 Within the context of IS-IS, the reporting of local SIDs is done through IS-IS Sub-TLVs such as the Adjacency-SID. However, the reporting of allocated local SIDs may also be done through other means and protocols which are outside the scope of this document. A router advertising the SRLB sub-TLV may also have other label ranges, outside the SRLB, for its local allocation purposes which are NOT advertised in the SRLB. For example, it is possible that an Adjacency-SID is allocated using a local label not part of the SRLB. 3.4. SRMS Preference Sub-TLV The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used in order to associate a preference with SRMS advertisements from a particular source. The SRMS Preference sub-TLV has 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 | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 24 Length: 1. Preference: 1 octet. Unsigned 8 bit SRMS preference. The SRMS Preference sub-TLV MAY be advertised in an LSP of any number but a router MUST NOT advertise more than one SRMS Preference sub- TLV. A router receiving multiple SRMS Preference sub-TLVs, from the same originator, SHOULD select the first advertisement in the lowest numbered LSP. The use of the SRMS Preference during the SID selection process is described in [I-D.ietf-spring-segment-routing-ldp-interop] 4. IANA Considerations This document requests allocation for the following TLVs and Sub- TLVs. Previdi, et al. Expires November 20, 2019 [Page 25] Internet-Draft IS-IS Extensions for Segment Routing May 2019 4.1. Sub TLVs for Type 22,23,25,141,222, and 223 This document makes the following registrations in the "sub-TLVs for TLV 22, 23, 25, 141, 222 and 223" registry. Type Description 22 23 25 141 222 223 ---- -------------------------------- --- --- --- --- --- --- 31 Adjacency Segment Identifier y y n y y y 32 LAN Adjacency Segment Identifier y y n y y y 4.2. Sub TLVs for Type 135,235,236 and 237 This document makes the following registrations in the "sub-TLVs for TLV 135,235,236 and 237" registry. Type Description 135 235 236 237 ---- ------------------------- --- --- --- --- 3 Prefix Segment Identifier y y y y 4.3. Sub TLVs for Type 242 This document makes the following registrations in the "sub-TLVs for TLV 242" registry. Type Description ---- ----------- 2 Segment Routing Capability 19 Segment Routing Algorithm 22 Segment Routing Local Block (SRLB) 24 Segment Routing Mapping Server Preference (SRMS Preference) 4.4. New TLV Codepoint and Sub-TLV registry This document registers the following TLV: Value Name IIH LSP SNP Purge ----- --------------------------------- --- --- --- ----- 149 Segment Identifier/Label Binding n y n n 150 Multi-Topology Segment Identifier n y n n /Label Binding This document creates the following sub-TLV Registry: Previdi, et al. Expires November 20, 2019 [Page 26] Internet-Draft IS-IS Extensions for Segment Routing May 2019 Name: sub-TLVs for TLVs 149 and 150 Registration Procedure: Expert Review Type Description ---- ----------- 0 Reserved 1 SID/Label 2 Unassigned 3 Prefix SID 4-255 Unassigned 5. Security Considerations With the use of the extensions defined in this document, IS-IS carries information which will be used to program the MPLS data plane [RFC3031]. In general, the same types of attacks that can be carried out on the IP/IPv6 control plane can be carried out on the MPLS control plane resulting in traffic being misrouted in the respective data planes. However, the latter may be more difficult to detect and isolate. Existing security extensions as described in [RFC5304] and [RFC5310] apply to these segment routing extensions. 6. Acknowledgements We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre Francois and Jesper Skrivers for their contribution to the content of this document. 7. Contributors The following people gave a substantial contribution to the content of this document and should be considered as co-authors: Stephane Litkowski Orange FR Email: stephane.litkowski@orange.com Jeff Tantsura Apstra, Inc. Email: jefftant@gmail.com Peter Psenak Previdi, et al. Expires November 20, 2019 [Page 27] Internet-Draft IS-IS Extensions for Segment Routing May 2019 Cisco Systems Inc. US Email: ppsenak@cisco.com Martin Horneffer Deutsche Telekom DE Email: Martin.Horneffer@telekom.de Wim Henderickx Nokia BE Email: wim.henderickx@nokia.com Edward Crabbe Oracle US Email: edward.crabbe@oracle.com Rob Shakir Google UK Email: robjs@google.com Igor Milojevic Individual RS Email: milojevicigor@gmail.com Saku Ytti TDC FI Email: saku@ytti.fi Steven Luong Cisco Systems Inc. Previdi, et al. Expires November 20, 2019 [Page 28] Internet-Draft IS-IS Extensions for Segment Routing May 2019 US Email: sluong@cisco.com 8. References 8.1. Normative References [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-27 (work in progress), December 2018. [I-D.ietf-spring-segment-routing-ldp-interop] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment-routing-ldp-interop-15 (work in progress), September 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-22 (work in progress), May 2019. [ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . Previdi, et al. Expires November 20, 2019 [Page 29] Internet-Draft IS-IS Extensions for Segment Routing May 2019 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 8.2. Informative References [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, . Previdi, et al. Expires November 20, 2019 [Page 30] Internet-Draft IS-IS Extensions for Segment Routing May 2019 [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, . [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . Authors' Addresses Stefano Previdi (editor) Huawei IT Email: stefano@previdi.net Les Ginsberg (editor) Cisco Systems, Inc. USA Email: ginsberg@cisco.com Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Ahmed Bashandy Arrcus Email: abashandy.ietf@gmail.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Previdi, et al. Expires November 20, 2019 [Page 31] Internet-Draft IS-IS Extensions for Segment Routing May 2019 Bruno Decraene Orange FR Email: bruno.decraene@orange.com Previdi, et al. Expires November 20, 2019 [Page 32] ./draft-ietf-pim-igmp-mld-yang-15.txt0000644000764400076440000027455713501246222016624 0ustar iustyiustyPIM Working Group X. Liu Internet-Draft Volta Networks Intended Status: Standard Track F. Guo Expires: December 14, 2019 Huawei M. Sivakumar Juniper P. McAllister Metaswitch Networks A. Peter Individual June 14, 2019 A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) draft-ietf-pim-igmp-mld-yang-15 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), 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 December 14, 2019. Copyright Notice Copyright (c) 2019 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 Liu & Guo, etc Expires December, 2019 [Page 1] Internet-Draft IGMP & MLD Yang Model June 2019 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. Abstract This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices. Conventions used in this document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................3 1.2. Tree Diagrams.............................................4 1.3. Prefixes in Data Node Names...............................4 2. Design of Data model...........................................4 2.1. Scope of Model............................................4 2.1.1. Parameters Not Covered at Global Level..................5 2.1.2. Parameters Not Covered at Interface Level...............5 2.2. Optional Capabilities.....................................6 2.3. Position of Address Family in Hierarchy...................6 3. Module Structure...............................................7 3.1. IGMP Configuration and Operational State..................7 3.2. MLD Configuration and Operational State..................10 3.3. IGMP and MLD Actions.....................................13 4. IGMP and MLD YANG Module......................................13 5. Security Considerations.......................................43 6. IANA Considerations...........................................45 7. Acknowledgments...............................................46 8. Contributing Authors..........................................46 9. References....................................................46 9.1. Normative References.....................................46 9.2. Informative References...................................48 Liu & Guo, etc Expires December, 2019 [Page 2] Internet-Draft IGMP & MLD Yang Model June 2019 1. Introduction YANG [RFC6020] [RFC7950] is a data definition language that was introduced to model the configuration and running state of a device managed using network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. YANG is now also being used as a component of wider management interfaces, such as command line interfaces (CLIs). This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices. The protocol versions include IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376], MLDv1 [RFC2710], and MLDv2 [RFC3810]. The core features of the IGMP and MLD protocols are defined as required. Non-core features are defined as optional in the provided data model. The YANG model in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. 1.1. Terminology The terminology for describing YANG data models is found in [RFC6020] and [RFC7950], including: o augment o data model o data node o identity o module The following abbreviations are used in this document and the defined model: IGMP: Internet Group Management Protocol [RFC3376]. MLD: Multicast Listener Discovery [RFC3810]. SSM: Source-Specific Multicast service model [RFC3569] [RFC4607]. Liu & Guo, etc Expires December, 2019 [Page 3] Internet-Draft IGMP & MLD Yang Model June 2019 1.2. Tree Diagrams Tree diagrams used in this document follow the notation defined in [RFC8340]. 1.3. Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +-----------+--------------------------+---------------------+ | Prefix | YANG module | Reference | +-----------+--------------------------+---------------------+ | yang | ietf-yang-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] | | if | ietf-interfaces | [RFC8343] | | ip | ietf-ip | [RFC8344] | | rt | ietf-routing | [RFC8349] | | rt-types | ietf-routing-types | [RFC8294] | | acl | ietf-access-control-list | [RFC8519] | +-----------+--------------------------+---------------------+ Table 1: Prefixes and Corresponding YANG Modules 2. Design of Data model 2.1. Scope of Model The model covers IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376], MLDv1 [RFC2710], and MLDv2 [RFC3810]. This model does not cover other IGMP and MLD related protocols such as IGMP/MLD Proxy [RFC4605] or IGMP/MLD Snooping [RFC4541] etc., which will be specified in separate documents. This model can be used to configure and manage various versions of IGMP and MLD protocols. The operational state data and statistics can be retrieved by this model. Even though no protocol specific notifications are defined in this model, the subscription and push mechanism defined in [I-D.ietf-netconf-subscribed-notifications] and [I-D.ietf-netconf-yang-push] can be used by the user to subscribe to notifications on the data nodes in this model. The model contains all the basic configuration parameters to operate the protocols listed above. Depending on the implementation choices, some systems may not allow some of the advanced parameters to be Liu & Guo, etc Expires December, 2019 [Page 4] Internet-Draft IGMP & MLD Yang Model June 2019 configurable. The occasionally implemented parameters are modeled as optional features in this model, while the rarely implemented parameters are not included this model and left for augmentation. This model can be extended, and has been structured in a way that such extensions can be conveniently made. The protocol parameters covered in this model can been seen from the model structure described in Section 3. The protocol parameters that were considered but are not covered in this model are described in the following sections. 2.1.1. Parameters Not Covered at Global Level The configuration parameters and operational states not covered on an IGMP instance or an MLD instance are: o Explicit tracking o Maximum transmit rate o Last member query count o Other querier present time o Send router alert o Startup query interval o Startup query count 2.1.2. Parameters Not Covered at Interface Level The configuration parameters and operational states not covered on an IGMP interface or an MLD interface are: o Disable router alert check o Drop IGMP version 1, IGMP version 2, or MLD version 1 o Last member query count o Maximum number of sources o Other querier present time o Passive mode o Promiscuous mode Liu & Guo, etc Expires December, 2019 [Page 5] Internet-Draft IGMP & MLD Yang Model June 2019 o Query before immediate leave o Send router alert 2.2. Optional Capabilities This model is designed to represent the capabilities of IGMP and MLD devices with various specifications, including the basic capability subsets of the IGMP and MLD protocols. The main design goals of this document are that the basic capabilities described in the model are supported by any major now-existing implementation, and that the configuration of all implementations meeting the specifications is easy to express through some combination of the optional features in the model and simple vendor augmentations. There is also value in widely-supported features being standardized, to provide a standardized way to access these features, to save work for individual vendors, and so that mapping between different vendors' configuration is not needlessly complicated. Therefore this model declares a number of features representing capabilities that not all deployed devices support. The extensive use of feature declarations should also substantially simplify the capability negotiation process for a vendor's IGMP and MLD implementations. On the other hand, operational state parameters are not so widely designated as features, as there are many cases where the defaulting of an operational state parameter would not cause any harm to the system, and it is much more likely that an implementation without native support for a piece of operational state would be able to derive a suitable value for a state variable that is not natively supported. 2.3. Position of Address Family in Hierarchy The protocol IGMP only supports IPv4, while the protocol MLD only supports IPv6. The data model defined in this document can be used for both IPv4 and IPv6 address families. This document defines IGMP and MLD as separate schema branches in the structure. The benefits are: o The model can support IGMP (IPv4), MLD (IPv6), or both optionally and independently. Such flexibility cannot be achieved cleanly with a combined branch. o The structure is consistent with other YANG models such as RFC 8344, which uses separate branches for IPv4 and IPv6. Liu & Guo, etc Expires December, 2019 [Page 6] Internet-Draft IGMP & MLD Yang Model June 2019 o The separate branches for IGMP and MLD can accommodate their differences better and cleaner. The two branches can better support different features and node types. 3. Module Structure This model augments the core routing data model specified in [RFC8349]. +--rw routing +--rw router-id? +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw type | +--rw name | +--rw igmp <= Augmented by this Model ... | +--rw mld <= Augmented by this Model ... The "igmp" container instantiates an IGMP protocol of version IGMPv1, IGMPv2, or IGMPv3. The "mld" container instantiates an MLD protocol of version MLDv1 or MLDv2. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [RFC8407]. A configuration data node is marked as mandatory only when its value must be provided by the user. Where nodes are not essential to protocol operation, they are marked as optional. Some other nodes are essential but have a default specified, so that they are also optional and need not be configured explicitly. 3.1. IGMP Configuration and Operational State The IGMP data is modeled as a schema subtree augmenting the "control-plane-protocol" data node under "/rt:routing/rt:control- plane-protocols" in the module ietf-routing, following the convention described in [RFC8349]. The augmentation to the module ietf-routing allows this model to support multiple instances of IGMP, but a restriction MAY be added depending on the implementation and the device. The identity "igmp" is derived from the "rt:control- plane-protocol" base identity and indicates that a control-plane- protocol instance is IGMP. The IGMP subtree is a three-level hierarchy structure as listed below: Liu & Guo, etc Expires December, 2019 [Page 7] Internet-Draft IGMP & MLD Yang Model June 2019 Global level: Including IGMP configuration and operational state attributes for the entire IGMP protocol instance in this router. Interface-global level: Including configuration data nodes that are applicable to all the interfaces whose corresponding nodes are not defined or not configured at the interface level. For such a node at the interface level, the system uses the same value of the corresponding node at the interface-global level. Interface level: Including IGMP configuration and operational state attributes specific to the given interface. For a configuration node at the interface level, there may exist a corresponding configuration node with the same name at the interface-global level. The value configured on a node at the interface level overrides the value configured on the corresponding node at the interface-global level. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw igmp {feature-igmp}? +--rw global | +--rw enable? boolean {global-admin-enable}? | +--rw max-entries? uint32 {global-max-entries}? | +--rw max-groups? uint32 {global-max-groups}? | +--ro entries-count? uint32 | +--ro groups-count? uint32 | +--ro statistics | +--ro discontinuity-time? yang:date-and-time | +--ro error | | +--ro total? yang:counter64 | | +--ro query? yang:counter64 | | +--ro report? yang:counter64 | | +--ro leave? yang:counter64 | | +--ro checksum? yang:counter64 | | +--ro too-short? yang:counter64 | +--ro received | | +--ro total? yang:counter64 | | +--ro query? yang:counter64 | | +--ro report? yang:counter64 | | +--ro leave? yang:counter64 | +--ro sent | +--ro total? yang:counter64 | +--ro query? yang:counter64 | +--ro report? yang:counter64 | +--ro leave? yang:counter64 +--rw interfaces +--rw last-member-query-interval? uint16 +--rw query-interval? uint16 +--rw query-max-response-time? uint16 Liu & Guo, etc Expires December, 2019 [Page 8] Internet-Draft IGMP & MLD Yang Model June 2019 +--rw require-router-alert? boolean | {intf-require-router-alert}? +--rw robustness-variable? uint8 +--rw version? uint8 +--rw max-groups-per-interface? uint32 | {intf-max-groups}? +--rw interface* [interface-name] +--rw interface-name if:interface-ref +--rw last-member-query-interval? uint16 +--rw query-interval? uint16 +--rw query-max-response-time? uint16 +--rw require-router-alert? boolean | {intf-require-router-alert}? +--rw robustness-variable? uint8 +--rw version? uint8 +--rw enable? boolean | {intf-admin-enable}? +--rw group-policy? | -> /acl:acls/acl/name +--rw immediate-leave? empty | {intf-immediate-leave}? +--rw max-groups? uint32 | {intf-max-groups}? +--rw max-group-sources? uint32 | {intf-max-group-sources}? +--rw source-policy? | -> /acl:acls/acl/name {intf-source-policy}? +--rw verify-source-subnet? empty | {intf-verify-source-subnet}? +--rw explicit-tracking? empty | {intf-explicit-tracking}? +--rw exclude-lite? empty | {intf-exclude-lite}? +--rw join-group* | rt-types:ipv4-multicast-group-address | {intf-join-group}? +--rw ssm-map* | | [ssm-map-source-addr ssm-map-group-policy] | | {intf-ssm-map}? | +--rw ssm-map-source-addr ssm-map-ipv4-addr-type | +--rw ssm-map-group-policy string +--rw static-group* [group-addr source-addr] | | {intf-static-group}? | +--rw group-addr | | rt-types:ipv4-multicast-group-address | +--rw source-addr | rt-types:ipv4-multicast-source-address +--ro oper-status enumeration +--ro querier inet:ipv4-address Liu & Guo, etc Expires December, 2019 [Page 9] Internet-Draft IGMP & MLD Yang Model June 2019 +--ro joined-group* | rt-types:ipv4-multicast-group-address | {intf-join-group}? +--ro group* [group-address] +--ro group-address | rt-types:ipv4-multicast-group-address +--ro expire uint32 +--ro filter-mode enumeration +--ro up-time uint32 +--ro last-reporter? inet:ipv4-address +--ro source* [source-address] +--ro source-address inet:ipv4-address +--ro expire uint32 +--ro up-time uint32 +--ro host-count? uint32 | {intf-explicit-tracking}? +--ro last-reporter? inet:ipv4-address +--ro host* [host-address] | {intf-explicit-tracking}? +--ro host-address inet:ipv4-address +--ro host-filter-mode enumeration 3.2. MLD Configuration and Operational State The MLD data is modeled as a schema subtree augmenting the "control- plane-protocol" data node under "/rt:routing/rt:control-plane- protocols" in the module ietf-routing, following the convention described in [RFC8349]. The augmentation to the module ietf-routing allows this model to support multiple instances of MLD, but a restriction MAY be added depending on the implementation and the device. The identity "mld" is derived from the "rt:control-plane- protocol" base identity and indicates that a control-plane-protocol instance is MLD. The MLD subtree is a three-level hierarchy structure as listed below: Global level: Including MLD configuration and operational state attributes for the entire MLD protocol instance in this router. Interface-global level: Including configuration data nodes that are applicable to all the interfaces whose corresponding nodes are not defined or not configured at the interface level. For such a node at the interface level, the system uses the same value of the corresponding node at the interface-global level. Interface level: Including MLD configuration and operational state attributes specific to the given interface. For a configuration node at the interface level, there may exist a Liu & Guo, etc Expires December, 2019 [Page 10] Internet-Draft IGMP & MLD Yang Model June 2019 corresponding configuration node with the same name at the interface-global level. The value configured on a node at the interface level overrides the value configured on the corresponding node at the interface-global level. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw mld {feature-mld}? +--rw global | +--rw enable? boolean {global-admin-enable}? | +--rw max-entries? uint32 {global-max-entries}? | +--rw max-groups? uint32 {global-max-groups}? | +--ro entries-count? uint32 | +--ro groups-count? uint32 | +--ro statistics | +--ro discontinuity-time? yang:date-and-time | +--ro error | | +--ro total? yang:counter64 | | +--ro query? yang:counter64 | | +--ro report? yang:counter64 | | +--ro leave? yang:counter64 | | +--ro checksum? yang:counter64 | | +--ro too-short? yang:counter64 | +--ro received | | +--ro total? yang:counter64 | | +--ro query? yang:counter64 | | +--ro report? yang:counter64 | | +--ro leave? yang:counter64 | +--ro sent | +--ro total? yang:counter64 | +--ro query? yang:counter64 | +--ro report? yang:counter64 | +--ro leave? yang:counter64 +--rw interfaces +--rw last-member-query-interval? uint16 +--rw query-interval? uint16 +--rw query-max-response-time? uint16 +--rw require-router-alert? boolean | {intf-require-router-alert}? +--rw robustness-variable? uint8 +--rw version? uint8 +--rw max-groups-per-interface? uint32 | {intf-max-groups}? +--rw interface* [interface-name] +--rw interface-name if:interface-ref +--rw last-member-query-interval? uint16 +--rw query-interval? uint16 +--rw query-max-response-time? uint16 +--rw require-router-alert? boolean Liu & Guo, etc Expires December, 2019 [Page 11] Internet-Draft IGMP & MLD Yang Model June 2019 | {intf-require-router-alert}? +--rw robustness-variable? uint8 +--rw version? uint8 +--rw enable? boolean | {intf-admin-enable}? +--rw group-policy? | -> /acl:acls/acl/name +--rw immediate-leave? empty | {intf-immediate-leave}? +--rw max-groups? uint32 | {intf-max-groups}? +--rw max-group-sources? uint32 | {intf-max-group-sources}? +--rw source-policy? | -> /acl:acls/acl/name {intf-source-policy}? +--rw verify-source-subnet? empty | {intf-verify-source-subnet}? +--rw explicit-tracking? empty | {intf-explicit-tracking}? +--rw exclude-lite? empty | {intf-exclude-lite}? +--rw join-group* | rt-types:ipv6-multicast-group-address | {intf-join-group}? +--rw ssm-map* | | [ssm-map-source-addr ssm-map-group-policy] | | {intf-ssm-map}? | +--rw ssm-map-source-addr ssm-map-ipv6-addr-type | +--rw ssm-map-group-policy string +--rw static-group* [group-addr source-addr] | | {intf-static-group}? | +--rw group-addr | | rt-types:ipv6-multicast-group-address | +--rw source-addr | rt-types:ipv6-multicast-source-address +--ro oper-status enumeration +--ro querier inet:ipv6-address +--ro joined-group* | rt-types:ipv6-multicast-group-address | {intf-join-group}? +--ro group* [group-address] +--ro group-address | rt-types:ipv6-multicast-group-address +--ro expire uint32 +--ro filter-mode enumeration +--ro up-time uint32 +--ro last-reporter? inet:ipv6-address +--ro source* [source-address] +--ro source-address inet:ipv6-address Liu & Guo, etc Expires December, 2019 [Page 12] Internet-Draft IGMP & MLD Yang Model June 2019 +--ro expire uint32 +--ro up-time uint32 +--ro host-count? uint32 | {intf-explicit-tracking}? +--ro last-reporter? inet:ipv6-address +--ro host* [host-address] | {intf-explicit-tracking}? +--ro host-address inet:ipv6-address +--ro host-filter-mode enumeration 3.3. IGMP and MLD Actions IGMP and MLD each have one action which clears the group membership cache entries for that protocol. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw igmp {feature-igmp}? +---x clear-groups {action-clear-groups}? +---w input +---w (interface) | +--:(name) | | +---w interface-name? leafref | +--:(all) | +---w all-interfaces? empty +---w group-address union +---w source-address rt-types:ipv4-multicast-source-address augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw mld {feature-mld}? +---x clear-groups {action-clear-groups}? +---w input +---w (interface) | +--:(name) | | +---w interface-name? leafref | +--:(all) | +---w all-interfaces? empty +---w group-address? union +---w source-address? rt-types:ipv6-multicast-source-address 4. IGMP and MLD YANG Module This module references [RFC1112], [RFC2236], [RFC2710], [RFC3376], [RFC3810], [RFC5790], [RFC6636], [RFC6991], [RFC8294], [RFC8343], [RFC8344], [RFC8349], and [RFC8519]. Liu & Guo, etc Expires December, 2019 [Page 13] Internet-Draft IGMP & MLD Yang Model June 2019 file "ietf-igmp-mld@2019-06-12.yang" module ietf-igmp-mld { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld"; prefix igmp-mld; import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-access-control-list { prefix "acl"; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-ip { prefix ip; reference "RFC 8344: A YANG Data Model for IP Management"; } organization "IETF PIM Working Group"; Liu & Guo, etc Expires December, 2019 [Page 14] Internet-Draft IGMP & MLD Yang Model June 2019 contact "WG Web: WG List: Editor: Xufeng Liu Editor: Feng Guo Editor: Mahesh Sivakumar Editor: Pete McAllister Editor: Anish Peter "; description "The module defines the configuration and operational state for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) protocols. Copyright (c) 2019 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 revision 2019-06-12 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for IGMP and MLD"; } /* * Features */ Liu & Guo, etc Expires December, 2019 [Page 15] Internet-Draft IGMP & MLD Yang Model June 2019 feature feature-igmp { description "Support IGMP protocol for IPv4 group membership record."; } feature feature-mld { description "Support MLD protocol for IPv6 group membership record."; } feature global-admin-enable { description "Support global configuration to enable or disable protocol."; } feature global-max-entries { description "Support configuration of global max-entries."; } feature global-max-groups { description "Support configuration of global max-groups."; } feature interface-global-config { description "Support global configuration applied for all interfaces."; } feature intf-admin-enable { description "Support configuration of interface administrative enabling."; } feature intf-immediate-leave { description "Support configuration of interface immediate-leave."; } feature intf-join-group { description "Support configuration of interface join-group."; } feature intf-max-groups { description "Support configuration of interface max-groups."; } Liu & Guo, etc Expires December, 2019 [Page 16] Internet-Draft IGMP & MLD Yang Model June 2019 feature intf-max-group-sources { description "Support configuration of interface max-group-sources."; } feature intf-require-router-alert { description "Support configuration of interface require-router-alert."; } feature intf-source-policy { description "Support configuration of interface source policy."; } feature intf-ssm-map { description "Support configuration of interface ssm-map."; } feature intf-static-group { description "Support configuration of interface static-group."; } feature intf-verify-source-subnet { description "Support configuration of interface verify-source-subnet."; } feature intf-explicit-tracking { description "Support configuration of interface explicit-tracking hosts."; } feature intf-lite-exclude-filter { description "Support configuration of interface lite-exclude-filter."; } feature per-interface-config { description "Support per interface configuration."; } feature action-clear-groups { description "Support actions to clear groups."; Liu & Guo, etc Expires December, 2019 [Page 17] Internet-Draft IGMP & MLD Yang Model June 2019 } /* * Typedefs */ typedef ssm-map-ipv4-addr-type { type union { type enumeration { enum 'policy' { description "Source address is specified in SSM map policy."; } } type inet:ipv4-address; } description "Multicast source IP address type for SSM map."; } // source-ipv4-addr-type typedef ssm-map-ipv6-addr-type { type union { type enumeration { enum 'policy' { description "Source address is specified in SSM map policy."; } } type inet:ipv6-address; } description "Multicast source IP address type for SSM map."; } // source-ipv6-addr-type /* * Identities */ identity igmp { base "rt:control-plane-protocol"; description "IGMP protocol."; reference "RFC 3376: Internet Group Management Protocol, Version 3."; } identity mld { base "rt:control-plane-protocol"; description "MLD protocol."; reference "RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6."; Liu & Guo, etc Expires December, 2019 [Page 18] Internet-Draft IGMP & MLD Yang Model June 2019 } /* * Groupings */ grouping global-config-attributes { description "This grouping is used in either IGMP schema or MLD schema. When used in IGMP schema, this grouping contains the global configuration for IGMP; when used in MLD schema, this grouping contains the global configuration for MLD."; leaf enable { if-feature global-admin-enable; type boolean; default true; description "When this grouping is used for IGMP, this leaf indicates whether IGMP is enabled ('true') or disabled ('false') in the routing instance. When this grouping is used for MLD, this leaf indicates whether MLD is enabled ('true') or disabled ('false') in the routing instance."; } leaf max-entries { if-feature global-max-entries; type uint32; description "When this grouping is used for IGMP, this leaf indicates the maximum number of entries in the IGMP instance. When this grouping is used for MLD, this leaf indicates the maximum number of entries in the MLD instance. If this leaf is not specified, the number of entries is not limited."; } leaf max-groups { if-feature global-max-groups; type uint32; description "When this grouping is used for IGMP, this leaf indicates the maximum number of groups in the IGMP instance. When this grouping is used for MLD, this leaf indicates the maximum number of groups in the MLD instance. If this leaf is not specified, the number of groups is not limited."; } } // global-config-attributes Liu & Guo, etc Expires December, 2019 [Page 19] Internet-Draft IGMP & MLD Yang Model June 2019 grouping global-state-attributes { description "This grouping is used in either IGMP schema or MLD schema. When used in IGMP schema, this grouping contains the global IGMP state attributes; when used in MLD schema, this grouping contains the global MLD state attributes;"; leaf entries-count { type uint32; config false; description "When this grouping is used for IGMP, this leaf indicates the number of entries in the IGMP instance. When this grouping is used for MLD, this leaf indicates the number of entries in the MLD instance."; } leaf groups-count { type uint32; config false; description "When this grouping is used for IGMP, this leaf indicates the number of existing groups in the IGMP instance. When this grouping is used for MLD, this leaf indicates the number of existing groups in the MLD instance."; } container statistics { config false; description "When this grouping is used for IGMP, this container contains the statistics for the IGMP instance. When this grouping is used for MLD, this leaf indicates the statistics for the MLD instance."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of the statistic counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container error { description "Statistics of errors."; uses global-statistics-error; } Liu & Guo, etc Expires December, 2019 [Page 20] Internet-Draft IGMP & MLD Yang Model June 2019 container received { description "Statistics of received messages."; uses global-statistics-sent-received; } container sent { description "Statistics of sent messages."; uses global-statistics-sent-received; } } // statistics } // global-state-attributes grouping global-statistics-error { description "A grouping defining statistics attributes for errors."; uses global-statistics-sent-received; leaf checksum { type yang:counter64; description "The number of checksum errors."; } leaf too-short { type yang:counter64; description "The number of messages that are too short."; } } // global-statistics-error grouping global-statistics-sent-received { description "A grouping defining statistics attributes."; leaf total { type yang:counter64; description "The number of total messages."; } leaf query { type yang:counter64; description "The number of query messages."; } leaf report { type yang:counter64; description "The number of report messages."; } leaf leave { type yang:counter64; Liu & Guo, etc Expires December, 2019 [Page 21] Internet-Draft IGMP & MLD Yang Model June 2019 description "The number of leave messages."; } } // global-statistics-sent-received grouping interface-global-config-attributes { description "Configuration attributes applied to the interface-global level whose per interface attributes are not configured."; leaf max-groups-per-interface { if-feature intf-max-groups; type uint32; description "The maximum number of groups associated with each interface. If this leaf is not specified, the number of groups is not limited."; } } //interface-global-config-attributes grouping interface-common-config-attributes { description "Configuration attributes applied to both the interface-global level and interface level."; leaf last-member-query-interval { type uint16 { range "1..1023"; } units seconds; description "When used in IGMP schema, this leaf indicates the Last Member Query Interval, which may be tuned to modify the leave latency of the network; when used in MLD schema, this leaf indicates the Last Listener Query Interval, which may be tuned to modify the leave latency of the network. This leaf is not applicable for version 1 of the IGMP. For version 2 and version 3 of the IGMP, and for all versions of the MLD, the default value of this leaf is 1. This leaf may be configured at the interface level or the interface-global level, with precedence given to the value at the interface level. If the leaf is not configured at either level, the default value is used."; reference "RFC 2236. Sec. 8.8. RFC 3376. Sec. 8.8. RFC 2710. Sec. 7.8. RFC 3810. Sec. 9.8."; } leaf query-interval { Liu & Guo, etc Expires December, 2019 [Page 22] Internet-Draft IGMP & MLD Yang Model June 2019 type uint16 { range "1..31744"; } units seconds; description "The Query Interval is the interval between General Queries sent by the Querier. In RFC 3376, the Querier's Query Interval(QQI) is represented from the Querier's Query Interval Code in query message as follows: If QQIC < 128, QQI = QQIC. If QQIC >= 128, QQIC represents a floating-point value as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1| exp | mant | +-+-+-+-+-+-+-+-+ QQI = (mant | 0x10) << (exp + 3). The maximum value of QQI is 31744. The default value is 125. This leaf may be configured at the interface level or the interface-global level, with precedence given to the value at the interface level. If the leaf is not configured at either level, the default value is used."; reference "RFC 3376. Sec. 4.1.7, 8.2, 8.14.2."; } leaf query-max-response-time { type uint16 { range "1..1023"; } units seconds; description "Query maximum response time specifies the maximum time allowed before sending a responding report. The default value is 10. This leaf may be configured at the interface level or the interface-global level, with precedence given to the value at the interface level. If the leaf is not configured at either level, the default value is used."; reference "RFC 3376. Sec. 4.1.1, 8.3, 8.14.3."; } leaf require-router-alert { if-feature intf-require-router-alert; type boolean; description "Protocol packets should contain router alert IP option. When this leaf is not configured, the server uses the following rules to determine the operational value of this leaf: if this grouping is used in IGMP schema and the value of the Liu & Guo, etc Expires December, 2019 [Page 23] Internet-Draft IGMP & MLD Yang Model June 2019 leaf 'version' is 1, the value 'false' is operationally used by the server; if this grouping is used in IGMP schema and the value of the leaf 'version' is 2 or 3, the value 'true' is operationally used by the server; if this grouping is used in MLD schema, the value 'true' is operationally used by the server. This leaf may be configured at the interface level or the interface-global level, with precedence given to the value at the interface level. If the leaf is not configured at either level, the default value is used."; } leaf robustness-variable { type uint8 { range "1..7"; } description "Querier's Robustness Variable allows tuning for the expected packet loss on a network. The default value is 2. This leaf may be configured at the interface level or the interface-global level, with precedence given to the value at the interface level. If the leaf is not configured at either level, the default value is used."; reference "RFC 3376. Sec. 4.1.6, 8.1, 8.14.1."; } } // interface-common-config-attributes grouping interface-common-config-attributes-igmp { description "Configuration attributes applied to both the interface-global level and interface level for IGMP."; uses interface-common-config-attributes; leaf version { type uint8 { range "1..3"; } description "IGMP version. The default value is 2. This leaf may be configured at the interface level or the interface-global level, with precedence given to the value at the interface level. If the leaf is not configured at either level, the default value is used."; reference "RFC 1112, RFC 2236, RFC 3376."; } } Liu & Guo, etc Expires December, 2019 [Page 24] Internet-Draft IGMP & MLD Yang Model June 2019 grouping interface-common-config-attributes-mld { description "Configuration attributes applied to both the interface-global level and interface level for MLD."; uses interface-common-config-attributes; leaf version { type uint8 { range "1..2"; } description "MLD version. The default value is 2. This leaf may be configured at the interface level or the interface-global level, with precedence given to the value at the interface level. If the leaf is not configured at either level, the default value is used."; reference "RFC 2710, RFC 3810."; } } grouping interfaces-config-attributes-igmp { description "Configuration attributes applied to the interface-global level for IGMP."; uses interface-common-config-attributes-igmp; uses interface-global-config-attributes; } grouping interfaces-config-attributes-mld { description "Configuration attributes applied to the interface-global level for MLD."; uses interface-common-config-attributes-mld; uses interface-global-config-attributes; } grouping interface-level-config-attributes { description "This grouping is used in either IGMP schema or MLD schema. When used in IGMP schema, this grouping contains the IGMP configuration attributes that are defined at the interface level but are not defined at the interface-global level; when used in MLD schema, this grouping contains the MLD configuration attributes that are defined at the interface level but are not defined at the interface-global level."; Liu & Guo, etc Expires December, 2019 [Page 25] Internet-Draft IGMP & MLD Yang Model June 2019 leaf enable { if-feature intf-admin-enable; type boolean; default true; description "When this grouping is used for IGMP, this leaf indicates whether IGMP is enabled ('true') or disabled ('false') on the interface. When this grouping is used for MLD, this leaf indicates whether MLD is enabled ('true') or disabled ('false') on the interface."; } leaf group-policy { type leafref { path "/acl:acls/acl:acl/acl:name"; } description "When this grouping is used for IGMP, this leaf specifies the name of the access policy used to filter the IGMP membership. When this grouping is used for MLD, this leaf specifies the name of the access policy used to filter the MLD membership. The value space of this leaf is restricted to the existing policy instances defined by the referenced schema RFC 8519. As specified by RFC 8519, the length of the name is between 1 and 64; a device MAY further restrict the length of this name; space and special characters are not allowed. If this leaf is not specified, no policy is applied, and all packets received from this interface are accepted."; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } leaf immediate-leave { if-feature intf-immediate-leave; type empty; description "When this grouping is used for IGMP, the presence of this leaf requests IGMP to perform an immediate leave upon receiving an IGMPv2 leave message. If the router is IGMP-enabled, it sends an IGMP last member query with a last member query response time. However, the router does not wait for the response time before it prunes the group. When this grouping is used for MLD, the presence of this leaf requests MLD to perform an immediate leave upon receiving an MLDv1 leave message. If the router is MLD-enabled, it sends an MLD last member Liu & Guo, etc Expires December, 2019 [Page 26] Internet-Draft IGMP & MLD Yang Model June 2019 query with a last member query response time. However, the router does not wait for the response time before it prunes the group."; } leaf max-groups { if-feature intf-max-groups; type uint32; description "When this grouping is used for IGMP, this leaf indicates the maximum number of groups associated with the IGMP interface. When this grouping is used for MLD, this leaf indicates the maximum number of groups associated with the MLD interface. If this leaf is not specified, the number of groups is not limited."; } leaf max-group-sources { if-feature intf-max-group-sources; type uint32; description "The maximum number of group sources. If this leaf is not specified, the number of group sources is not limited."; } leaf source-policy { if-feature intf-source-policy; type leafref { path "/acl:acls/acl:acl/acl:name"; } description "Name of the access policy used to filter sources. The value space of this leaf is restricted to the existing policy instances defined by the referenced schema RFC 8519. As specified by RFC 8519, the length of the name is between 1 and 64; a device MAY further restrict the length of this name; space and special characters are not allowed. If this leaf is not specified, no policy is applied, and all packets received from this interface are accepted."; } leaf verify-source-subnet { if-feature intf-verify-source-subnet; type empty; description "If present, the interface accepts packets with matching source IP subnet only."; } leaf explicit-tracking { if-feature intf-explicit-tracking; Liu & Guo, etc Expires December, 2019 [Page 27] Internet-Draft IGMP & MLD Yang Model June 2019 type empty; description "When this grouping is used for IGMP, the presence of this leaf enables IGMP-based explicit membership tracking function for multicast routers and IGMP proxy devices supporting IGMPv3. When this grouping is used for MLD, the presence of this leaf enables MLD-based explicit membership tracking function for multicast routers and MLD proxy devices supporting MLDv2. The explicit membership tracking function contributes to saving network resources and shortening leave latency."; reference "RFC 6636. Sec 3."; } leaf lite-exclude-filter { if-feature intf-lite-exclude-filter; type empty; description "When this grouping is used for IGMP, the presence of this leaf enables the support of the simplified EXCLUDE filter in the Lightweight IGMPv3 protocol, which simplifies the standard versions of IGMPv3. When this grouping is used for MLD, the presence of this leaf enables the support of the simplified EXCLUDE filter in the Lightweight MLDv2 protocol, which simplifies the standard versions of MLDv2."; reference "RFC 5790"; } } // interface-level-config-attributes grouping interface-config-attributes-igmp { description "Per interface configuration attributes for IGMP."; uses interface-common-config-attributes-igmp; uses interface-level-config-attributes; leaf-list join-group { if-feature intf-join-group; type rt-types:ipv4-multicast-group-address; description "The router joins this multicast group on the interface."; } list ssm-map { if-feature intf-ssm-map; key "ssm-map-source-addr ssm-map-group-policy"; description "The policy for (*,G) mapping to (S,G)."; leaf ssm-map-source-addr { Liu & Guo, etc Expires December, 2019 [Page 28] Internet-Draft IGMP & MLD Yang Model June 2019 type ssm-map-ipv4-addr-type; description "Multicast source IPv4 address."; } leaf ssm-map-group-policy { type string; description "Name of the policy used to define ssm-map rules. A device can restrict the length and value of this name, possibly space and special characters are not allowed. "; } } list static-group { if-feature intf-static-group; key "group-addr source-addr"; description "A static multicast route, (*,G) or (S,G). The version of IGMP must be 3 to support (S,G)."; leaf group-addr { type rt-types:ipv4-multicast-group-address; description "Multicast group IPv4 address."; } leaf source-addr { type rt-types:ipv4-multicast-source-address; description "Multicast source IPv4 address."; } } } // interface-config-attributes-igmp grouping interface-config-attributes-mld { description "Per interface configuration attributes for MLD."; uses interface-common-config-attributes-mld; uses interface-level-config-attributes; leaf-list join-group { if-feature intf-join-group; type rt-types:ipv6-multicast-group-address; description "The router joins this multicast group on the interface."; } list ssm-map { if-feature intf-ssm-map; key "ssm-map-source-addr ssm-map-group-policy"; description "The policy for (*,G) mapping to (S,G)."; Liu & Guo, etc Expires December, 2019 [Page 29] Internet-Draft IGMP & MLD Yang Model June 2019 leaf ssm-map-source-addr { type ssm-map-ipv6-addr-type; description "Multicast source IPv6 address."; } leaf ssm-map-group-policy { type string; description "Name of the policy used to define ssm-map rules. A device can restrict the length and value of this name, possibly space and special characters are not allowed."; } } list static-group { if-feature intf-static-group; key "group-addr source-addr"; description "A static multicast route, (*,G) or (S,G). The version of MLD must be 2 to support (S,G)."; leaf group-addr { type rt-types:ipv6-multicast-group-address; description "Multicast group IPv6 address."; } leaf source-addr { type rt-types:ipv6-multicast-source-address; description "Multicast source IPv6 address."; } } } // interface-config-attributes-mld grouping interface-state-attributes { description "Per interface state attributes for both IGMP and MLD."; leaf oper-status { type enumeration { enum up { description "Ready to pass packets."; } enum down { description "The interface does not pass any packets."; } Liu & Guo, etc Expires December, 2019 [Page 30] Internet-Draft IGMP & MLD Yang Model June 2019 } config false; mandatory true; description "Indicates whether the operational state of the interface is up or down."; } } // interface-state-attributes grouping interface-state-attributes-igmp { description "Per interface state attributes for IGMP."; uses interface-state-attributes; leaf querier { type inet:ipv4-address; config false; mandatory true; description "The querier address in the subnet"; } leaf-list joined-group { if-feature intf-join-group; type rt-types:ipv4-multicast-group-address; config false; description "The routers that joined this multicast group."; } list group { key "group-address"; config false; description "Multicast group membership information that joined on the interface."; leaf group-address { type rt-types:ipv4-multicast-group-address; description "Multicast group address."; } uses interface-state-group-attributes; leaf last-reporter { type inet:ipv4-address; description "The IPv4 address of the last host which has sent the report to join the multicast group."; } list source { key "source-address"; description Liu & Guo, etc Expires December, 2019 [Page 31] Internet-Draft IGMP & MLD Yang Model June 2019 "List of multicast source information of the multicast group."; leaf source-address { type inet:ipv4-address; description "Multicast source address in group record."; } uses interface-state-source-attributes; leaf last-reporter { type inet:ipv4-address; description "The IPv4 address of the last host which has sent the report to join the multicast source and group."; } list host { if-feature intf-explicit-tracking; key "host-address"; description "List of hosts with the membership for the specific multicast source-group."; leaf host-address { type inet:ipv4-address; description "The IPv4 address of the host."; } uses interface-state-host-attributes; }// list host } // list source } // list group } // interface-state-attributes-igmp grouping interface-state-attributes-mld { description "Per interface state attributes for MLD."; uses interface-state-attributes; leaf querier { type inet:ipv6-address; config false; mandatory true; description "The querier address in the subnet."; } leaf-list joined-group { if-feature intf-join-group; type rt-types:ipv6-multicast-group-address; config false; Liu & Guo, etc Expires December, 2019 [Page 32] Internet-Draft IGMP & MLD Yang Model June 2019 description "The routers that joined this multicast group."; } list group { key "group-address"; config false; description "Multicast group membership information that joined on the interface."; leaf group-address { type rt-types:ipv6-multicast-group-address; description "Multicast group address."; } uses interface-state-group-attributes; leaf last-reporter { type inet:ipv6-address; description "The IPv6 address of the last host which has sent the report to join the multicast group."; } list source { key "source-address"; description "List of multicast sources of the multicast group."; leaf source-address { type inet:ipv6-address; description "Multicast source address in group record"; } uses interface-state-source-attributes; leaf last-reporter { type inet:ipv6-address; description "The IPv6 address of the last host which has sent the report to join the multicast source and group."; } list host { if-feature intf-explicit-tracking; key "host-address"; description "List of hosts with the membership for the specific multicast source-group."; leaf host-address { type inet:ipv6-address; description Liu & Guo, etc Expires December, 2019 [Page 33] Internet-Draft IGMP & MLD Yang Model June 2019 "The IPv6 address of the host."; } uses interface-state-host-attributes; }// list host } // list source } // list group } // interface-state-attributes-mld grouping interface-state-group-attributes { description "Per interface state attributes for both IGMP and MLD groups."; leaf expire { type uint32; units seconds; mandatory true; description "The time left before multicast group state expires."; } leaf filter-mode { type enumeration { enum "include" { description "In include mode, reception of packets sent to the specified multicast address is requested only from those IP source addresses listed in the source-list parameter"; } enum "exclude" { description "In exclude mode, reception of packets sent to the given multicast address is requested from all IP source addresses except those listed in the source-list parameter."; } } mandatory true; description "Filter mode for a multicast group, may be either include or exclude."; } leaf up-time { type uint32; units seconds; mandatory true; description "The elapsed time since the device created multicast group record."; Liu & Guo, etc Expires December, 2019 [Page 34] Internet-Draft IGMP & MLD Yang Model June 2019 } } // interface-state-group-attributes grouping interface-state-source-attributes { description "Per interface state attributes for both IGMP and MLD source-group records."; leaf expire { type uint32; units seconds; mandatory true; description "The time left before multicast source-group state expires."; } leaf up-time { type uint32; units seconds; mandatory true; description "The elapsed time since the device created multicast source-group record."; } leaf host-count { if-feature intf-explicit-tracking; type uint32; description "The number of host addresses."; } } // interface-state-source-attributes grouping interface-state-host-attributes { description "Per interface state attributes for both IGMP and MLD hosts of source-group records."; leaf host-filter-mode { type enumeration { enum "include" { description "In include mode"; } enum "exclude" { description "In exclude mode."; } } mandatory true; description Liu & Guo, etc Expires December, 2019 [Page 35] Internet-Draft IGMP & MLD Yang Model June 2019 "Filter mode for a multicast membership host may be either include or exclude."; } } // interface-state-host-attributes /* * Configuration and Operational state data nodes (NMDA version) */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'igmp-mld:igmp')" { description "This augmentation is only valid for a control-plane protocol instance of IGMP (type 'igmp')."; } description "IGMP augmentation to routing control plane protocol configuration and state."; container igmp { if-feature feature-igmp; description "IGMP configuration and operational state data."; container global { description "Global attributes."; uses global-config-attributes; uses global-state-attributes; } container interfaces { description "Containing a list of interfaces."; uses interfaces-config-attributes-igmp { if-feature interface-global-config; refine query-interval { default 125; } refine query-max-response-time { default 10; } refine robustness-variable { default 2; } refine version { default 2; } Liu & Guo, etc Expires December, 2019 [Page 36] Internet-Draft IGMP & MLD Yang Model June 2019 } list interface { key "interface-name"; description "List of IGMP interfaces."; leaf interface-name { type if:interface-ref; must "/if:interfaces/if:interface[if:name = current()]/" + "ip:ipv4" { error-message "The interface must have IPv4 configured, either " + "enabled or disabled."; } description "Reference to an entry in the global interface list."; } uses interface-config-attributes-igmp { if-feature per-interface-config; refine last-member-query-interval { must "../version != 1 or " + "(not(../version) and " + "(../../version != 1 or not(../../version)))" { error-message "IGMPv1 does not support " + "last-member-query-interval."; } } refine max-group-sources { must "../version = 3 or " + "(not(../version) and (../../version = 3))" { error-message "The version of IGMP must be 3 to support the " + "source specific parameters."; } } refine source-policy { must "../version = 3 or " + "(not(../version) and (../../version = 3))" { error-message "The version of IGMP must be 3 to support the " + "source specific parameters."; } } refine explicit-tracking { must "../version = 3 or " + "(not(../version) and (../../version = 3))" { error-message "The version of IGMP must be 3 to support the " Liu & Guo, etc Expires December, 2019 [Page 37] Internet-Draft IGMP & MLD Yang Model June 2019 + "explicit tracking function."; } } refine lite-exclude-filter { must "../version = 3 or " + "(not(../version) and (../../version = 3))" { error-message "The version of IGMP must be 3 to support the " + "simplified EXCLUDE filter in the Lightweight " + "IGMPv3 protocol."; } } } uses interface-state-attributes-igmp; } // interface } // interfaces /* * Actions */ action clear-groups { if-feature action-clear-groups; description "Clears the specified IGMP cache entries."; input { choice interface { mandatory true; description "Indicates the interface(s) from which the cache entries are cleared."; case name { leaf interface-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/" + "igmp-mld:igmp/igmp-mld:interfaces/" + "igmp-mld:interface/igmp-mld:interface-name"; } description "Name of the IGMP interface."; } } case all { leaf all-interfaces { type empty; description "IGMP groups from all interfaces are cleared."; } Liu & Guo, etc Expires December, 2019 [Page 38] Internet-Draft IGMP & MLD Yang Model June 2019 } } leaf group-address { type union { type enumeration { enum '*' { description "Any group address."; } } type rt-types:ipv4-multicast-group-address; } mandatory true; description "Multicast group IPv4 address. If the value '*' is specified, all IGMP group entries are cleared."; } leaf source-address { type rt-types:ipv4-multicast-source-address; mandatory true; description "Multicast source IPv4 address. If the value '*' is specified, all IGMP source-group entries are cleared."; } } } // action clear-groups } // igmp } //augment augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'igmp-mld:mld')" { description "This augmentation is only valid for a control-plane protocol instance of IGMP (type 'mld')."; } description "MLD augmentation to routing control plane protocol configuration and state."; container mld { if-feature feature-mld; description "MLD configuration and operational state data."; container global { description Liu & Guo, etc Expires December, 2019 [Page 39] Internet-Draft IGMP & MLD Yang Model June 2019 "Global attributes."; uses global-config-attributes; uses global-state-attributes; } container interfaces { description "Containing a list of interfaces."; uses interfaces-config-attributes-mld { if-feature interface-global-config; refine last-member-query-interval { default 1; } refine query-interval { default 125; } refine query-max-response-time { default 10; } refine require-router-alert { default true; } refine robustness-variable { default 2; } refine version { default 2; } } list interface { key "interface-name"; description "List of MLD interfaces."; leaf interface-name { type if:interface-ref; must "/if:interfaces/if:interface[if:name = current()]/" + "ip:ipv6" { error-message "The interface must have IPv6 configured, either " + "enabled or disabled."; } description "Reference to an entry in the global interface list."; } uses interface-config-attributes-mld { if-feature per-interface-config; refine max-group-sources { Liu & Guo, etc Expires December, 2019 [Page 40] Internet-Draft IGMP & MLD Yang Model June 2019 must "../version = 2 or " + "(not(../version) and " + "(../../version = 2 or not(../../version)))" { error-message "The version of MLD must be 2 to support the " + "source specific parameters."; } } refine source-policy { must "../version = 2 or " + "(not(../version) and " + "(../../version = 2 or not(../../version)))" { error-message "The version of MLD must be 2 to support the " + "source specific parameters."; } } refine explicit-tracking { must "../version = 2 or " + "(not(../version) and " + "(../../version = 2 or not(../../version)))" { error-message "The version of MLD must be 2 to support the " + "explicit tracking function."; } } refine lite-exclude-filter { must "../version = 2 or " + "(not(../version) and " + "(../../version = 2 or not(../../version)))" { error-message "The version of MLD must be 2 to support the " + "simplified EXCLUDE filter in the Lightweight " + "MLDv2 protocol."; } } } uses interface-state-attributes-mld; } // interface } // interfaces /* * Actions */ action clear-groups { if-feature action-clear-groups; description "Clears the specified MLD cache entries."; Liu & Guo, etc Expires December, 2019 [Page 41] Internet-Draft IGMP & MLD Yang Model June 2019 input { choice interface { mandatory true; description "Indicates the interface(s) from which the cache entries are cleared."; case name { leaf interface-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/" + "igmp-mld:mld/igmp-mld:interfaces/" + "igmp-mld:interface/igmp-mld:interface-name"; } description "Name of the MLD interface."; } } case all { leaf all-interfaces { type empty; description "MLD groups from all interfaces are cleared."; } } } leaf group-address { type union { type enumeration { enum '*' { description "Any group address."; } } type rt-types:ipv6-multicast-group-address; } description "Multicast group IPv6 address. If the value '*' is specified, all MLD group entries are cleared."; } leaf source-address { type rt-types:ipv6-multicast-source-address; description "Multicast source IPv6 address. If the value '*' is specified, all MLD source-group entries are cleared."; } } Liu & Guo, etc Expires December, 2019 [Page 42] Internet-Draft IGMP & MLD Yang Model June 2019 } // action clear-mld-groups } // mld } // augment } 5. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: Under /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/igmp-mld:igmp, igmp-mld:global This subtree specifies the configuration for the IGMP attributes at the global level on an IGMP instance. Modifying the configuration can cause IGMP membership to be deleted or reconstructed on all the interfaces of an IGMP instance. igmp-mld:interfaces This subtree specifies the configuration for the IGMP attributes at the interface-global level on a IGMP instance. Modifying the configuration can cause IGMP membership to be deleted or reconstructed on all the interfaces of an IGMP instance. igmp-mld:interfaces/interface Liu & Guo, etc Expires December, 2019 [Page 43] Internet-Draft IGMP & MLD Yang Model June 2019 This subtree specifies the configuration for the IGMP attributes at the interface level on an IGMP instance. Modifying the configuration can cause IGMP membership to be deleted or reconstructed on a specific interface of an IGMP instance. Under /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/igmp-mld:mld, igmp-mld:global This subtree specifies the configuration for the MLD attributes at the global level on an MLD instance. Modifying the configuration can cause MLD membership to be deleted or reconstructed on all the interfaces of an MLD instance. igmp-mld:interfaces This subtree specifies the configuration for the MLD attributes at the interface-global level on an MLD instance. Modifying the configuration can cause MLD membership to be deleted or reconstructed on all the interfaces of an MLD instance. igmp-mld:interfaces/interface This subtree specifies the configuration for the MLD attributes at the interface level on a device. Modifying the configuration can cause MLD membership to be deleted or reconstructed on a specific interface of an MLD instance. Unauthorized access to any data node of these subtrees can adversely affect the membership records of multicast routing subsystem on the local device. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/igmmp-mld:igmp /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/igmp-mld:mld Liu & Guo, etc Expires December, 2019 [Page 44] Internet-Draft IGMP & MLD Yang Model June 2019 Unauthorized access to any data node of the above subtree can disclose the operational state information of IGMP or MLD on this device. Some of the action operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/igmmp-mld:igmp/igmmp-mld:clear-groups /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/igmp-mld:mld/igmp-mld:clear-groups Unauthorized access to any of the above action operations can delete the IGMP or MLD membership records on this device. 6. IANA Considerations RFC Ed.: In this section, replace all occurrences of 'XXXX' with the actual RFC number (and remove this note). This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document registers the following YANG modules in the YANG Module Names registry [RFC6020]: -------------------------------------------------------------------- name: ietf-igmp-mld namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld prefix: igmp-mld reference: RFC XXXX Liu & Guo, etc Expires December, 2019 [Page 45] Internet-Draft IGMP & MLD Yang Model June 2019 -------------------------------------------------------------------- 7. Acknowledgments The authors would like to thank Steve Baillargeon, Hu Fangwei, Robert Kebler, Tanmoy Kundu, and Stig Venaas for their valuable contributions. 8. Contributing Authors Yisong Liu Huawei Technologies Huawei Bldg., No.156 Beiqing Rd. Beijing 100095 China Email: liuyisong@huawei.com 9. References 9.1. Normative References [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. Liu & Guo, etc Expires December, 2019 [Page 46] Internet-Draft IGMP & MLD Yang Model June 2019 [RFC6020] Bjorklund, M., Ed., "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, June 2011. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, July 2013. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, December 2017. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, March 2018. [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, March 2018. [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, March 2018. [RFC8344] M. Bjorklund, "A YANG Data Model for IP Management", RFC8344, March 2018. [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, March 2018. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. [RFC8519] M. Jethanandani, S. Agarwal, L. Huang and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, March 2019. Liu & Guo, etc Expires December, 2019 [Page 47] Internet-Draft IGMP & MLD Yang Model June 2019 9.2. Informative References [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [RFC4541] M. Christensen, K. Kimball and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC5790] H. Liu, W. Cao and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. [RFC6636] H. Asaeda, H. Liu and Q. Wu, "Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks", RFC 6636, May 2012. [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, March 2018. [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", RFC 8407, October 2018. [I-D.ietf-netconf-subscribed-notifications] Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Customized Subscriptions to a Publisher's Event Streams", draft-ietf-netconf-subscribed- notifications-26 (work in progress), May 2019. [I-D.ietf-netconf-yang-push] Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore Subscription", draft-ietf-netconf-yang-push-25 (work in progress), May 2019. Liu & Guo, etc Expires December, 2019 [Page 48] Internet-Draft IGMP & MLD Yang Model June 2019 Authors' Addresses Xufeng Liu Volta Networks Email: xufeng.liu.ietf@gmail.com Feng Guo Huawei Technologies Huawei Bldg., No.156 Beiqing Rd. Beijing 100095 China Email: guofeng@huawei.com Mahesh Sivakumar Juniper Networks 1133 Innovation Way Sunnyvale, California USA Email: sivakumar.mahesh@gmail.com Pete McAllister Metaswitch Networks 100 Church Street Enfield EN2 6BQ UK Email: pete.mcallister@metaswitch.com Anish Peter Individual Email: anish.ietf@gmail.com Liu & Guo, etc Expires December, 2019 [Page 49] ./draft-ietf-manet-dlep-lid-extension-06.txt0000644000764400076440000004265713535736016020213 0ustar iustyiusty Mobile Ad hoc Networks Working Group R. Taylor Internet-Draft Airbus Defence & Space Intended status: Standards Track S. Ratliff Expires: March 13, 2020 VT iDirect September 10, 2019 DLEP Link Identifier Extension draft-ietf-manet-dlep-lid-extension-06 Abstract The Dynamic Link Exchange Protocol, RFC 8175, describes a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol assumes that every modem in the radio network has an attached DLEP router, and requires that the MAC address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination. This document describes a DLEP Extension allowing modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain. 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 13, 2020. Taylor & Ratliff Expires March 13, 2020 [Page 1] Internet-Draft DLEP Link Identifier Extension September 2019 Copyright Notice Copyright (c) 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Identifier Restrictions . . . . . . . . . . . . . . . . . 5 2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 3. New Data Items . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Link Identifier Length Data Item . . . . . . . . . . . . 6 3.2. Link Identifier Data Item . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Dynamic Link Exchange Protocol (DLEP), RFC 8175, describes a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol assumes that every modem in the radio network has an attached DLEP router, and requires that the MAC address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination. This document describes a DLEP Extension allowing modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain. Taylor & Ratliff Expires March 13, 2020 [Page 2] Internet-Draft DLEP Link Identifier Extension September 2019 As with core DLEP, a router can use this knowledge to influence any routing or flow-control decisions regarding traffic to this destination, understanding that such traffic flows via Layer 3. 1.1. Terminology Local Layer 2 domain: The Layer 2 domain that links the router and modem participants of the current DLEP session. Layer 3 DLEP Destination: A DLEP Destination that is not directly addressable within the local Layer 2 domain, but is reachable via a node addressable within the local Layer 2 domain. Gateway Node: The last device with a MAC address reachable in the local Layer 2 domain on the path from the DLEP router participant, towards the Layer 3 DLEP Destination. This device is commonly the DLEP peer modem but could be another DLEP Destination in the Layer 2 domain. 1.2. Applicability This extension was designed primarily to address the following use cases: 1. A radio system that does not operate in Layer 2 bridge mode, but instead provides Layer 3 connectivity between destinations, often using its own embedded Layer 3 routing function. 2. A point-to-multipoint tunnel system, such as an SD-WAN deployment, where the tunnel provider acts as a modem, having knowledge of the characteristics of the underlay network, and providing that information as availability and metrics between tunnel endpoints in the overlay network. 3. A modem that provides connectivity to a remote wide-area network via a wireless link, but the concept of a Layer 2 reachable remote router does not apply. An example of such a modem would be an LTE device or 802.11 station that provides variable connectivity to the Internet. This list of use-cases is not exhaustive, and this extension may well be applicable to future, currently unforeseen, use-cases. Taylor & Ratliff Expires March 13, 2020 [Page 3] Internet-Draft DLEP Link Identifier Extension September 2019 1.3. Requirements 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Operation To refer to a Layer 3 DLEP Destination, the DLEP session participant adds a Link Identifier Data Item (Section 3.2) to the relevant Destination Message, and (as usual) includes a MAC Address Data Item. When paired with a Link Identifier Data Item, the MAC Address Data Item MUST contain the MAC address of the Gateway Node. As only modems are initially aware of Layer 3 DLEP Destinations, Link Identifier Data Items referring to a new link MUST first appear in a DLEP Destination Up Message from the modem to the router. Once a link has been identified in this way, Link Identifier Data Items may be used by either DLEP participant during the lifetime of a DLEP session. Because of this, a router MUST NOT send a DLEP Destination Announce Message containing a Link Identifier Data Item referring to a link that has not been mentioned in a prior DLEP Destination Up Message. If a modem receives such a message, it MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 131 'Invalid Destination' and transition to the Session Termination state. If a router receives a Destination Up Message specifying a Link Identifier that has already been used, the router MUST respond with a Destination Up Response Message containing a Status Data Item with status code set to 130 'Invalid Data', and transition to the Session Termination state. Because the MAC Address associated with any DLEP Destination Message containing a Link Identifier Data Item is not the Layer 2 address of the final destination, all DLEP Destination Up Messages containing a Link Identifier Data Item MUST contain Layer 3 information. In the case of modems that provide Layer 3 wide area network connectivity between devices, this means one or more IPv4 or IPv6 Address Data Items providing the Layer 3 address of the final destination. When referring to some upstream backbone network infrastructure, this means one or more IPv4 or IPv6 Attached Subnet Data Items, for example: '0.0.0.0/0' or '::/0'. This allows the DLEP peer router to understand the properties of the link to those routes. The address or addresses in the IPv4 or IPv6 Address Data Items MUST be the addresses in use on the public side of any Network Address Translation. Taylor & Ratliff Expires March 13, 2020 [Page 4] Internet-Draft DLEP Link Identifier Extension September 2019 When the DLEP peer router wishes to route packets to the Layer 3 DLEP Destination, the MAC address associated with the Gateway Node MUST be used as the Layer 2 destination of the packet, if it wishes to use the modem network to forward the packet. As routers populate their routing information base with the IP address of the next hop router towards a destination, implementations supporting this extension SHOULD announce at least one valid IPv4 or IPv6 addresses of the Gateway Node, this removes the need for the router to use an additional IP address resolution protocol before adding the route to its routing information base. 2.1. Identifier Restrictions A Link Identifier is by default 4 octets in length. If a modem wishes to use a Link Identifier of a different length, it MUST be announced using the Link Identifier Length Data Item (Section 3.1) contained in the DLEP Session Initialization Response message sent by the modem to the router. During the lifetime of a DLEP session, the length of Link Identifiers MUST remain constant, i.e. the Length field of the Link Identifier Data Item MUST NOT differ between destinations. The method for generating Link Identifiers is a modem implementation matter and out of scope of this document. Routers must not make any assumptions about the meaning of Link Identifiers, or how Link Identifiers are generated. Within a single DLEP session, all Link Identifiers MUST be unique per MAC Address. This means that a Layer 3 DLEP Destination is uniquely identified by the pair: {MAC Address,Link Identifier}. Link Identifiers MUST NOT be reused, i.e. a {MAC Address,Link Identifier} pair that has been used to refer to one Layer 3 DLEP Destination MUST NOT be used again within the lifetime of a single DLEP peer-to-peer session. 2.2. Negotiation Taylor & Ratliff Expires March 13, 2020 [Page 5] Internet-Draft DLEP Link Identifier Extension September 2019 To use this extension, as with all DLEP extensions, the extension MUST be announced during DLEP session initialization. A router advertises support by including the value 'Link Identifiers', TBD1 (Section 5), in the Extension Data Item within the Session Initialization Message. A modem advertises support by including the value 'Link Identifiers' in the Extension Data Item within the Session Initialization Response Message. If both DLEP peers advertise support for this extension then Link Identifier Data Items can be included in DLEP Messages. If a modem requires support for this extension in order to describe destinations, and the router does not advertise support, then the modem MUST NOT include a Link Identifier Data Item in any DLEP Message. However, the modem SHOULD NOT immediately terminate the DLEP session, rather it SHOULD use a combination of DLEP Session Messages and DLEP Attached Subnet Data Items to provide general information. 3. New Data Items This extension introduces two new DLEP Data Items: the Link Identifier Data Item (Section 3.2) used to identify a Layer 3 link at or beyond a destination, and the Link Identifier Length Data Item (Section 3.1) used to announce the length of Link Identifiers at session initialization. 3.1. Link Identifier Length Data Item The Link Identifier Length Data Item is used by a DLEP modem implementation to specify the length of Link Identifier Data Items. If the router advertised support by including the value 'Link Identifiers' in the Extension Data Item inside the Session Initialization Message, this data item MAY be used in the Session Initialization Response Message, if the specified length is not the default value of 4 octets. If the router did not specify support by including the value 'Link Identifiers' in the Extension Data item, this Data Item MUST NOT be sent. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD2 (Section 5) Taylor & Ratliff Expires March 13, 2020 [Page 6] Internet-Draft DLEP Link Identifier Extension September 2019 Length: 2 Link Identifier Length: The length, in octets, of Link Identifiers used by the DLEP modem for this session. A Link Identifier Length Data Item that specifies a Link Identifier Length of 4 octets (the default) is valid, even if it has no effect. 3.2. Link Identifier Data Item The Link Identifier Data Item MAY be used wherever a MAC Address Data Item is defined as usable in core DLEP. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD3 (Section 5) Length: The length of the Data Item, by default 4, but may be different if a Link Identifier Length Data Item (Section 3.1) has been announced during session initialization. Link Identifier: The unique identifier of the Layer 3 DLEP Destination. This Link Identifier has no implicit meaning and is only used to discriminate between multiple links. 4. Security Considerations As an extension to the core DLEP protocol, the security considerations of that protocol apply to this extension. This extension adds no additional security mechanisms or features. None of the features introduced by this extension require extra security consideration by an implementation. 5. IANA Considerations Upon approval of this document, IANA is requested to: o Assign a new DLEP Extensions Type Registry value (TBD1) from the Specification Required section, named "Link Identifiers". Taylor & Ratliff Expires March 13, 2020 [Page 7] Internet-Draft DLEP Link Identifier Extension September 2019 o Assign a new DLEP Data Item Type Values Registry value (TBD2) from the Specification Required section, named "Link Identifier Length". o Assign a new DLEP Data Item Type Values Registry value (TBD3) from the Specification Required section, named "Link Identifier". 6. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, June 2017, . Authors' Addresses Rick Taylor Airbus Defence & Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ UK Email: rick.taylor@airbus.com Stan Ratliff VT iDirect 13861 Sunrise Valley Drive, Suite 300 Herndon, VA 20171 USA Email: sratliff@idirect.net Taylor & Ratliff Expires March 13, 2020 [Page 8] ./draft-ietf-pim-reserved-bits-04.txt0000644000764400076440000003660213540766276016744 0ustar iustyiusty Network Working Group S. Venaas Internet-Draft Cisco Systems, Inc. Obsoletes: 6166 (if approved) A. Retana Updates: 3973, 5015, 5059, 6754, 7761, Futurewei Technologies, Inc. 8364 (if approved) September 19, 2019 Intended status: Standards Track Expires: March 22, 2020 PIM Message Type Space Extension and Reserved Bits draft-ietf-pim-reserved-bits-04 Abstract The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types, and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range. This document Updates RFC 7761 and RFC 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFC 7761 and RFC 3973, along with RFC 5015, RFC 5059, RFC 6754 and RFC 8364, by specifying the use of the currently Reserved bits for each PIM message. This document obsoletes RFC 6166. 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 https://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 22, 2020. Venaas & Retana Expires March 22, 2020 [Page 1] Internet-Draft PIM Type Extension and Reserved Bits September 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Conventions used in this document . . . . . . . . . . . . . . 3 3. PIM header common format . . . . . . . . . . . . . . . . . . 3 4. Flag Bit definitions . . . . . . . . . . . . . . . . . . . . 3 4.1. Flag Bits for Type 4 (Bootstrap) . . . . . . . . . . . . 4 4.2. Flag Bits for Type 10 (DF Election) . . . . . . . . . . . 4 4.3. Flag Bits for Type 12 (PFM) . . . . . . . . . . . . . . . 4 4.4. Flag Bits for Types 13, 14 and 15 (Type Space Extension) 4 5. PIM Type Space Extension . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The PIM version 2 messages share a common message header format defined in the PIM Sparse Mode [RFC7761] specification. The common header definition contains eight Reserved bits. While all message types use this common header, there is no document formally specifying that these bits are to be used per message type. This document refers to the bits specified as Reserved in the common PIM header [RFC7761] as PIM message type Flag Bits, or simply Flag Bits, and it specifies that they are to be separately used on a per- message-type basis. It creates a registry containing the per- message-type usage. Venaas & Retana Expires March 22, 2020 [Page 2] Internet-Draft PIM Type Extension and Reserved Bits September 2019 This document Updates [RFC7761] and [RFC3973] by defining the use of the currently Reserved field in the PIM common header. This document further updates [RFC7761] and [RFC3973], along with [RFC5015], [RFC5059], [RFC6754] and [RFC8364], by specifying the use of the currently Reserved bits for each PIM message. The currently defined PIM message types are in the range from 0 to 15. That type space is almost exhausted. Message type 15 was reserved by [RFC6166] for type space extension. In Section 5, this document specifies the use of the Flag Bits for message types 13, 14 and 15 in order to extend the PIM type space. This document Obsoletes [RFC6166]. 2. Conventions used in this document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. PIM header common format The common PIM header is defined in section 4.9 of [RFC7761]. This document updates the definition of the Reserved field and refers to that field as PIM message type Flag Bits, or simply Flag Bits. The new common header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Flag Bits | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: New Common Header The Flag Bits field is defined in Section 4. All other fields remain unchanged. 4. Flag Bit definitions Unless otherwise specified, all the Flag Bits for each PIM type are Reserved [RFC8126]. They MUST be set to zero on transmission, and they MUST be ignored upon receipt. The specification of a new PIM type MUST indicate whether the bits should be treated differently. When defining Flag Bits, it is helpful to have a well-defined way of referring to a particular bit. The most significant of the Flag Venaas & Retana Expires March 22, 2020 [Page 3] Internet-Draft PIM Type Extension and Reserved Bits September 2019 Bits, the bit immediately following the type field is referred to as bit 7. The least significant, the bit right in front of the checksum field is referred to as bit 0. This is shown in the diagram 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |7 6 5 4 3 2 1 0| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Flag Bits 4.1. Flag Bits for Type 4 (Bootstrap) PIM message type 4 (Bootstrap) [RFC5059] defines Flag Bit 7 as No- Forward. The usage of the bit is defined in that document. The remaining Flag Bits are Reserved. 4.2. Flag Bits for Type 10 (DF Election) PIM message type 10 (DF Election) [RFC5015] specifies that the four most significant Flag Bits (bits 4-7) are to be used as a Subtype. The usage of those bits is defined in that document. The remaining Flag Bits are Reserved. 4.3. Flag Bits for Type 12 (PFM) PIM message type 12 (PFM) [RFC8364] defines Flag Bit 7 as No-Forward. The usage of the bit is defined in that document. The remaining Flag Bits are Reserved. 4.4. Flag Bits for Types 13, 14 and 15 (Type Space Extension) These types and the corresponding Flag Bits are defined in Section 5. 5. PIM Type Space Extension This document defines types 13, 14 and 15, such that each of these types has 16 subtypes, providing a total of 48 subtypes available for future PIM extensions. This is achieved by defining a new SubType field (see Figure 3) using the four most significant Flag Bits (bits 4-7). The notation type.subtype is used to reference these new extended types. The remaining four Flag Bits (bits 0-3) are Reserved to be used by each extended type (abbreviated as FB below). Venaas & Retana Expires March 22, 2020 [Page 4] Internet-Draft PIM Type Extension and Reserved Bits September 2019 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |SubType| FB | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Sub-Types 6. Security Considerations This document clarifies the use of the Flag Bits in the common PIM header and it extends the PIM type space. As such, there is no impact on security or changes to the considerations in [RFC7761] and [RFC3973]. 7. IANA Considerations This document updates the PIM Message Types registry to indicate which Flag Bits are defined for use by each of the PIM message types. The Registry should now reference this document instead of [RFC6166]. The Registration Policy remains IETF Review [RFC8126]. Assignments into this registry MUST define any non-default usage (see Section 4) of the Flag Bits in addition to defining the Type. The updated PIM Message Types registry is shown below. Venaas & Retana Expires March 22, 2020 [Page 5] Internet-Draft PIM Type Extension and Reserved Bits September 2019 Type Name Flag Bits Reference --------------------------------------------------------------------- 0 Hello 0-7: Reserved [RFC3973][RFC7761] 1 Register 0-7: Reserved [RFC7761] 2 Register Stop 0-7: Reserved [RFC7761] 3 Join/Prune 0-7: Reserved [RFC3973][RFC7761] 4 Bootstrap 0-6: Reserved [RFC5059][RFC7761] 7: No-Forward [RFC5059] 5 Assert 0-7: Reserved [RFC3973][RFC7761] 6 Graft 0-7: Reserved [RFC3973] 7 Graft-Ack 0-7: Reserved [RFC3973] 8 Candidate RP 0-7: Reserved [RFC7761] Advertisement 9 State Refresh 0-7: Reserved [RFC3973] 10 DF Election 0-3: Reserved [RFC5015] 4-7: Subtype [RFC5015] 11 ECMP Redirect 0-7: Reserved [RFC6754] 12 PIM Flooding Mechanism 0-6: Reserved [RFC8364] 7: No-Forward [RFC8364] 13.0-15.15 Unassigned 0-3: Unassigned [this document] Table 1: Updated PIM Message Types Registry The Unassigned types above, as explained in Section 5, use the extended type notation of type.subtype. Each extended type only has 4 Flag Bits available. New extended message types should be assigned conscutively, starting with 13.0, then 13.1, etc. 8. References 8.1. Normative References Venaas & Retana Expires March 22, 2020 [Page 6] Internet-Draft PIM Type Extension and Reserved Bits September 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, January 2005, . [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, . [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, . [RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166, DOI 10.17487/RFC6166, April 2011, . [RFC6754] Cai, Y., Wei, L., Ou, H., Arya, V., and S. Jethwani, "Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect", RFC 6754, DOI 10.17487/RFC6754, October 2012, . Venaas & Retana Expires March 22, 2020 [Page 7] Internet-Draft PIM Type Extension and Reserved Bits September 2019 [RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM Flooding Mechanism (PFM) and Source Discovery (SD)", RFC 8364, DOI 10.17487/RFC8364, March 2018, . Authors' Addresses Stig Venaas Cisco Systems, Inc. Tasman Drive San Jose CA 95134 USA Email: stig@cisco.com Alvaro Retana Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara CA 95050 USA Email: alvaro.retana@futurewei.com Venaas & Retana Expires March 22, 2020 [Page 8] ./draft-ietf-mmusic-data-channel-sdpneg-28.txt0000644000764400076440000026343413465726550020503 0ustar iustyiusty MMUSIC K. Drage Internet-Draft Unaffiliated Intended status: Standards Track M. Makaraju Expires: November 12, 2019 Nokia R. Ejzak J. Marcon Unaffiliated R. Even, Ed. Huawei May 11, 2019 SDP-based Data Channel Negotiation draft-ietf-mmusic-data-channel-sdpneg-28 Abstract Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or using some out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. 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 https://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 12, 2019. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Drage, et al. Expires November 12, 2019 [Page 1] Internet-Draft SDP-based Data Channel Negotiation May 2019 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 6 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 10 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 13 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 6.3. Generating the Initial Offer for A Data Channel . . . . . 14 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 16 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 20 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 20 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 22 Drage, et al. Expires November 12, 2019 [Page 2] Internet-Draft SDP-based Data Channel Negotiation May 2019 12.2. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 22 12.3. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 22 12.4. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 22 12.5. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22 12.6. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22 12.7. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23 12.8. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 24 12.9. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 24 12.10. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 24 12.11. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 25 12.12. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 26 12.13. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 27 12.14. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 28 12.15. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 30 12.16. Changes against 'draft-ejzak-mmusic-data-channel- sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 33 12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 34 12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Generic Data Channel Negotiation Aspects When Not Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 38 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 38 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 38 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Drage, et al. Expires November 12, 2019 [Page 3] Internet-Draft SDP-based Data Channel Negotiation May 2019 1. Introduction The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) is in [I-D.ietf-rtcweb-data-channel] allowing applications to use data channels. An in-band Data Channel Establishment Protocol (DCEP) is in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of- band protocols may be used for establishing data channels. Each data channel consists of paired SCTP streams sharing the same SCTP Stream Identifier. Data channels are created by endpoint applications using the WebRTC API (Application Programming Interface), or other protocols like CLUE [I-D.ietf-clue-datachannel]. The protocols can be signaled by the data channel "subprotocol" parameter, conceptually similar to the WebSocket [RFC5234] "subprotocol". However, apart from the "subprotocol" value transmitted to the peer, an endpoint application can agree on how to instantiate a given subprotocol on a data channel, and whether it is signaled in-band using DCEP or out- of-band using a non-DCEP protocol (or both). This document defines SDP offer/answer [RFC3264] procedures that enable out-of-band negotiation for establishing data channels for transport of well-defined subprotocols. These procedures are based on generic SDP offer/answer negotiation rules for SCTP based media transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. This document uses MSRP (Message Session Relay Protocol) [RFC4975] and BFCP (Binary Floor Control Protocol) [RFC4582] in many of the examples. It does not provide a complete specification of how to negotiate the use of a data channel to transport MSRP. Procedures specific to each subprotocol would have to be documented elsewhere. For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some examples is only to show how the generic procedures described herein might apply to a specific subprotocol. 2. Conventions 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Drage, et al. Expires November 12, 2019 [Page 4] Internet-Draft SDP-based Data Channel Negotiation May 2019 3. Terminology This document uses the following terms: Data channel: A WebRTC data channel as specified in [I-D.ietf-rtcweb-data-channel]. Data channel stack: An entity which, upon application request, runs the data channel protocol to keep track of states, sending and receiving data. If the application is a browser based JavaScript application then this stack resides in the browser. If the application is a native application then this stack resides in the application and is accessible via some sort of APIs. Data channel properties: Fixed properties assigned to a data channel at the time of its creation. Some of these properties determine the way the data channel stack transmits data on this channel (e.g., stream identifier, reliability, order of delivery, etc.). Data channel subprotocol: The application protocol which is transported over a single data channel. Data channel subprotocol messages are sent as data channel payload over an established data channel. SDP offer/answer exchange can be used as specified in this document to negotiate the establishment of data channels, corresponding data channel properties, associated data channel subprotocols and data channel subprotocol properties. In this case the data channel subprotocols may be identified by the values of the "subprotocol" parameters of the SDP "a=dcmap" attribute as described in Section 5.1.4. Within this document the term "data channel subprotocol" is often abbreviated as just "subprotocol". DCEP: Data Channel Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol]. In-band: Transmission through the peer-to-peer SCTP association. Out-of-band: Transmission through the application signaling path. Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the SDP offerer, the peer is the SDP answerer. From the perspective of the SDP answerer, the peer is the SDP offerer. SCTP Stream Sequence Number (SSN): the SCTP stream sequence number as specified in [RFC4960]. Drage, et al. Expires November 12, 2019 [Page 5] Internet-Draft SDP-based Data Channel Negotiation May 2019 Stream identifier: The identifier of the outbound and inbound SCTP streams composing a data channel. 4. Applicability Statement The mechanism in this document only applies to the Session Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope for this document, and is thus undefined. 5. SDP Data Channel Attributes This section defines two new SDP media-level attributes that can be used together with the SDP Offer/Answer mechanism to negotiate data channel-specific and subprotocol-specific parameters without the usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute provides for negotiation of channel-specific parameters. The second attribute provides for negotiation of subprotocol-specific parameters. Note: Appendix A provides information how data channels work in general and especially summarizes some key aspects, which should be considered for the negotiation of data channels if DCEP is not used. 5.1. SDP DCMAP Attribute This section defines a new media level attribute "a=dcmap:" that defines the data channel parameters for each data channel to be negotiated. The attribute is used to create bi-directional SCTP data channels having the same set of attributes. The data channel properties (reliable/partially reliable, ordered/unordered) need to be suitable per the subprotocol transport requirements. 5.1.1. DCMAP Attribute Syntax "a=dcmap:" is a media level attribute having the following ABNF (Augmented Backus-Naur Form, [RFC5234]) syntax. Formal Syntax: Name: dcmap Value: dcmap-value Usage Level: media Drage, et al. Expires November 12, 2019 [Page 6] Internet-Draft SDP-based Data Channel Negotiation May 2019 Charset Dependent: no Syntax: dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt / priority-opt ; maxretr-opt and maxtime-opt are mutually exclusive ; dcmap-stream-id = 1*5DIGIT ordering-opt = "ordered=" ordering-value ordering-value = "true" / "false" subprotocol-opt = "subprotocol=" quoted-string label-opt = "label=" quoted-string maxretr-opt = "max-retr=" maxretr-value maxretr-value = "0" / integer ; number of retransmissions, ; less than 2^32, ; derived from 'Reliability Parameter' of ; [I-D.ietf-rtcweb-data-protocol] maxtime-opt = "max-time=" maxtime-value maxtime-value = "0" / integer ; milliseconds, ; less than 2^32, ; derived from 'Reliability Parameter' of ; [I-D.ietf-rtcweb-data-protocol] priority-opt = "priority=" priority-value priority-value = "0" / integer ; unsigned integer value indicating the priority of ; the data channel, ; less than 2^16, ; derived from 'Priority' of ; [I-D.ietf-rtcweb-data-protocol] quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char = SP / quoted-visible quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char = "%" HEXDIG HEXDIG DQUOTE = integer = Examples: a=dcmap:0 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" Drage, et al. Expires November 12, 2019 [Page 7] Internet-Draft SDP-based Data Channel Negotiation May 2019 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 Note: The last example (a=dcmap:4) shows a 'label' parameter value which contains one non-printable 'escaped-char' character (the tabulator character). Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be present. Both MUST NOT be present. 5.1.2. Dcmap-stream-id Parameter The 'dcmap-stream-id' parameter indicates the SCTP stream identifier within the SCTP association used to form the data channel. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. In order to communicate with WEbRTC API the label attribute should: o Serialize the WebRTC label as a UTF-8 string [RFC3629]. o Treat the UTF-8 serialization as a series of bytes o For each byte in the serialization: * If the byte can be expressed as a `quoted-char`, do so * Otherwise, express the byte as an `escaped-char`. Note: The empty string MAY also be explicitly used as a 'label' value, such that 'label=""' is equivalent to the 'label' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 5.1.4. Subprotocol Parameter The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. Drage, et al. Expires November 12, 2019 [Page 8] Internet-Draft SDP-based Data Channel Negotiation May 2019 Section 9.1 specifies how new subprotocol parameter values are registered. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to an empty string. Note: The empty string MAY also be explicitly used as 'subprotocol' value, such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an empty string. 5.1.5. Max-retr Parameter This parameter indicates that the data channel is partially reliable. The 'max-retr' parameter indicates the maximal number of times a user message will be retransmitted. The max-retr parameter is optional. If the max-retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960]. This parameter maps to the 'Number of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 5.1.6. Max-time Parameter This parameter indicates that the data channel is partially reliable. A user message will no longer be transmitted or retransmitted after a specified life-time given in milliseconds in the 'max-time' parameter. The life-time starts when providing the user message to the protocol stack. The max-time parameter is optional. If the max- retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960]. This parameter maps to the 'Lifetime in ms' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 5.1.7. Ordered Parameter The 'ordered' parameter with value "true" indicates that the receiver will dispatch DATA chunks in the data channel to the upper layer while preserving the order. The ordered parameter is optional and takes two values: "true" for ordered and "false" for unordered delivery with "true" as the default value. Any other value is ignored and default "ordered=true" is assumed. In the absence of this parameter "ordered=true" is assumed. This parameter maps to the ordered or unordered data channel types as defined in [I-D.ietf-rtcweb-data-protocol]. Drage, et al. Expires November 12, 2019 [Page 9] Internet-Draft SDP-based Data Channel Negotiation May 2019 5.1.8. Priority Parameter The 'priority' parameter indicates the data channel's priority relative to the priorities of other data channels, which may additionally exist over the same SCTP association. The 'priority' parameter maps to the 'Priority' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is optional. In the absence of this parameter "priority=256" is assumed. 5.1.9. DCMAP Multiplexing Category The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the "a=dcmap:" attribute is SPECIAL. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no "a=dcmap:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLS association, or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcmap:" attribute need to be defined as well, for instance in an extension of this SDP offer/answer based data channel negotiation specification. 5.2. SDP DCSA Attribute In the SDP media description, each data channel declaration MAY also be followed by other media level SDP attributes, which are either specifically defined for or applied to the subprotocol in use. Each of these attributes is represented by one new attribute line, and it includes the contents of a media-level SDP attribute already defined for use with this (sub)protocol in another IETF document. Subprotocol specific attributes MAY also be defined for exclusive use with data channel transport, but MUST use the same syntax described here for other subprotocol related attributes. Each SDP attribute, related to the subprotocol, that would normally be used to negotiate the subprotocol using SDP offer/answer is replaced with an attribute of the form "a=dcsa:stream-id original- attribute", where dcsa stands for "data channel subprotocol attribute", stream-id is the SCTP stream identifier assigned to this subprotocol instance, and original-attribute represents the contents of the subprotocol related attribute to be included. The same syntax applies to any other SDP attribute required for negotiation of this instance of the subprotocol. Drage, et al. Expires November 12, 2019 [Page 10] Internet-Draft SDP-based Data Channel Negotiation May 2019 The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol. If no offer/answer procedures exist for the sub-protocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The IANA registration procedures for the WebSocket Subprotocol Name Registry (Section 9.1) do not strictly require a specification of the offer/ answer procedures for the sub-protocol when used with dcsa. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, but no specification exists for the offer/answer procedures for the sub-protocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise- negotiable and applicable sub-protocol parameters. 5.2.1. DCSA Syntax Formal Syntax: Name: dcsa Value: dcsa-value Usage Level: media Charset Dependent: no Syntax: dcsa-value = stream-id SP attribute stream-id = 1*5DIGIT attribute = Example: a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcsa:2 accept-types:text/plain Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where the attribute definition can be found; it does not provide any limitation on support of attributes defined in other documents in accordance with this attribute definition. Note however that not all SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA (Internet Assigned Numbers Authority) registered session and media level or media level only SDP attributes. Drage, et al. Expires November 12, 2019 [Page 11] Internet-Draft SDP-based Data Channel Negotiation May 2019 Thus in the example above, the original attribute line "a=accept- types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/plain", which specifies that this instance of the MSRP subprotocol being transported on the SCTP association using the data channel with stream id 2 accepts plain text files. As opposed to the data channel "a=dcmap:" attribute parameters, these parameters are subject to offer/answer negotiation following the procedures defined in the subprotocol specific documents. It is assumed that in general the usages of subprotocol related media level attributes are independent from the subprotocol's transport protocol. Such transport protocol independent subprotocol related attributes are used in the same way as defined in the original subprotocol specification, also if the subprotocol is transported over a data channel and if the attribute is correspondingly embedded in a "a=dcsa" attribute. There may be cases, where the usage of a subprotocol related media level attribute depends on the subprotocol's transport protocol. In such cases the subprotocol related usage of the attribute is expected to be described for the data channel transport. A data channel specific usage of a subprotocol attribute is expected to be specified in the same document that registers the subprotocol's identifier for data channel usage as described in Section 9.1. SDP attributes that are only defined for use at the dcsa usage level, SHALL use the dcsa usage level when registering the attribute. If existing media attributes are used in a datachannel subprotocol specific way, then a new dcsa usage level MUST be defined for the existing media attribute. Where the SDP attribute is applicable to a particular subprotocol/s this SHALL also be registered by indicating the applicable subprotocol identifiers (see /[I-D.ietf-mmusic-rfc4566bis] section-8.5) along with the dcsa usage level. 5.2.2. DCSA Multiplexing Category The multiplexing category of the "a=dcsa:" attribute is SPECIAL. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no "a=dcsa:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLS association, or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcsa:" attribute need to be defined as Drage, et al. Expires November 12, 2019 [Page 12] Internet-Draft SDP-based Data Channel Negotiation May 2019 well, for instance in an extension of this SDP based data channel negotiation specification. 6. SDP Offer/Answer Procedures This section defines how data channels can be negotiated using the SDP offer/answer mechanism. A given media description can describe multiple data channels (each represented by a separate SDP dcmap attribute) that can be created, modified and closed using different offer/answer exchanges. The procedures in this section apply for a given data channel. The generic offer/answer procedures for negotiating the SCTP association used to realize data channels are defined in [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data channel specific procedures. "Initial offer" refers to the offer in which a data channel is opened. It can be the initial offer, or a subsequent offer, of the associated SDP session. The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol see Section 5.2. 6.1. Managing Stream Identifiers In order to avoid SCTP Stream identifier collisions, in alignment with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS client (for the SCTP association used to realize data channels) MUST use even identifier values, and the endpoint acting as DTLS server MUST use odd identifier values. SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers. 6.2. Negotiating Data Channel Parameters The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are mapped to the dcmap SDP attribute parameters in the following manner where "ordered=true" is the default and may be omitted: Drage, et al. Expires November 12, 2019 [Page 13] Internet-Draft SDP-based Data Channel Negotiation May 2019 DATA_CHANNEL_RELIABLE ordered=true DATA_CHANNEL_RELIABLE_UNORDERED ordered=false DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT ordered=true;max-retr= DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED ordered=false;max-retr= DATA_CHANNEL_PARTIAL_RELIABLE_TIMED ordered=true;max-time= DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED ordered=false;max-time= By definition max-retr and max-time are mutually exclusive, so both MUST NOT be present in the "a=dcmap:" attribute line. If an SDP offer contains both of these parameters then the receiver of such an SDP offer MUST reject the SDP offer. If an SDP answer contains both of these parameters then the offerer MUST treat the associated SDP offer/answer as failed. 6.3. Generating the Initial Offer for A Data Channel When an offerer sends an initial offer, in order to negotiate an SCTP stream for a data channel, the offerer: o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) associated with the data channel in the "m=" section representing the SCTP association used to realize the data channel; and o MAY include one or more SDP dcsa attributes (Section 5.2) associated with the data channel. The value of the stream-id part of each attribute SHALL match the dcmap-stream-id value of the dcmap attribute. 6.4. Generating SDP Answer When an answerer receives an offer that includes an "m=" section for an SCTP association, that describes an SCTP stream for a data channel, if the answerer accepts the data channel it: o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) associated with the data channel in the "m=" section representing the SCTP association used to realize the data channel. The value Drage, et al. Expires November 12, 2019 [Page 14] Internet-Draft SDP-based Data Channel Negotiation May 2019 of the dcmap-stream-id, max-retr and max-time values of the dcmap attribute SHALL be identical to the value used for the data channel in the offer; and o MAY include one or more SDP dcsa attributes (Section 5.2) associated with the data channel. 6.5. Offerer Processing of the SDP Answer An offerer receiving an SDP answer performs the following: o SHALL close any created data channels as described in Section 6.6.1 for which the expected "a=dcmap:" attributes are not present in the SDP answer. If the SDP answer has no "a=dcmap" attribute either the peer does not support "a=dcmap:" attributes or it rejected all the data channels. In either case the offerer closes all the SDP offered data channels that were open at the time of offer. The DTLS association and SCTP association will still be setup. At this point the offerer may use DCEP negotiation [I-D.ietf-rtcweb-data-protocol] to open data channels Each agent application MUST wait to send data until it has confirmation that the data channel at the peer is instantiated. For WebRTC, this is when both data channel stacks have channel parameters instantiated. This occurs: o At both peers when a data channel is created without a previously established SCTP association, as soon as the SCTP association is successfully established. o At the agent receiving an SDP offer for which there is an established SCTP association, as soon as it creates the negotiated data channel based on information signaled in the SDP offer. o At the agent sending an SDP offer to create a new data channel for which there is an established SCTP association, when it receives the SDP answer confirming acceptance of the data channel or when it begins to receive data on the data channel from the peer, whichever occurs first. 6.6. Modifying the Session When an offer sends a subsequent offer, that includes information for a previously negotiated data channel, unless the offerer intends to close the data channel (Section 6.6.1), the offerer SHALL include the previously negotiated SDP attributes and attribute values associated with the data channel. The answerer may reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. Drage, et al. Expires November 12, 2019 [Page 15] Internet-Draft SDP-based Data Channel Negotiation May 2019 The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer [RFC3264]. 6.6.1. Closing a Data Channel In order to close a data channel, the endpoint that wants to close SHALL send the SCTP SSN reset message [RFC6525], following the procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In addition, if the closed data channel was negotiated using the offer/ answer mechanism Section 6.3, the endpoint that closed the data channel SHALL send a subsequent offer in which it either: o removes the SDP dcmap attribute and SDP dcsa attributes associated with the closed data channel. Once the endpoint receives a successful answer, the SCTP stream identifier value can later be used for a new data channel (negotiated using DCTP or using the offer/answer mechanism); or o after a reset has been performed re-uses the SCTP stream used for the closed data channel for a new data channel, using the procedures in Section 6.3. The offerer SHALL use a different SDP dcmap attribute value for the data channel using the same SCTP stream. 6.7. Various SDP Offer/Answer Considerations An SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" attributes. * This is considered an error case. In this case the receiver of such an SDP offer or answer MUST discard this "a=dcsa:" attributes. SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is unknown. * The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line. SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is known, but whose subprotocol attribute semantic is not known for the data channel transport case. * The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line. Drage, et al. Expires November 12, 2019 [Page 16] Internet-Draft SDP-based Data Channel Negotiation May 2019 7. Examples SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::3 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:0 subprotocol="bfcp";label="bfcp" SDP answer: m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::1 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 Figure 1: Example 1 In the example in Figure 1 the SDP answerer rejected the data channel with stream id 0 either for explicit reasons or because it does not understand the "a=dcmap:" attribute. As a result the offerer will close the data channel created with the SDP offer/answer negotiation option. The SCTP association will still be setup over DTLS. At this point the offerer or the answerer may use DCEP negotiation to open data channels. Drage, et al. Expires November 12, 2019 [Page 17] Internet-Draft SDP-based Data Channel Negotiation May 2019 SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:0 subprotocol="bfcp";label="bfcp" a=dcmap:2 subprotocol="msrp";label="msrp" a=dcsa:2 accept-types:message/cpim text/plain a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc SDP answer: m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.2 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 a=dcmap:2 subprotocol="msrp";label="msrp" a=dcsa:2 accept-types:message/cpim text/plain a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc Figure 2: Example 2 In the example in Figure 2 the SDP offer contains data channels for BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP answer rejected BFCP and accepted MSRP. So, the offerer closes the data channel for BFCP and both offerer and answerer may start using the MSRP data channel (after the SCTP association is set up). The data channel with stream id 0 is free and can be used for future DCEP or SDP offer/answer negotiation. Continuing the example in Figure 2. Drage, et al. Expires November 12, 2019 [Page 18] Internet-Draft SDP-based Data Channel Negotiation May 2019 Subsequent SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:4 subprotocol="msrp";label="msrp" a=dcsa:4 accept-types:message/cpim text/plain a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc Subsequent SDP answer: m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.2 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 a=dcmap:4 subprotocol="msrp";label="msrp" a=dcsa:4 accept-types:message/cpim text/plain a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc Figure 3: Example 3 The example in Figure 3 is a continuation of the example in Figure 2. The SDP offerer now removes the MSRP data channel with stream id 2, but opens a new MSRP data channel with stream id 4. The answerer accepts the entire offer. As a result the offerer closes the earlier negotiated MSRP related data channel and both offerer and answerer may start using new the MSRP related data channel. 8. Security Considerations This document specifies new SDP attributes used in the negotiation of the DATA channel parameters. These parameter are negotiated as part of opening a SCTP channel over DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol may come with it's own security considerations that need to be documented as part of the subprotocol definition. Otherwise this document does not add any security considerations to the ones specified in [I-D.ietf-mmusic-sctp-sdp] Drage, et al. Expires November 12, 2019 [Page 19] Internet-Draft SDP-based Data Channel Negotiation May 2019 Error cases like the use of unknown parameter values or violation the odd/even rule MUST be handled by closing the corresponding Data Channel. 9. IANA Considerations 9.1. Subprotocol Identifiers Registration of new subprotocol identifiers is performed using the existing IANA "WebSocket Subprotocol Name Registry" table. The following text should be added following the title of the table. "This table also includes subprotocol identifiers specified for usage within a WebRTC data channel." The following reference should be added to under the heading reference: "RFC XXXX". This document assigns no new values to this table. A subprotocol may simultaneously be defined for data channel transport and for Websocket transport. In such a case the "Subprotocol Definition" and "Reference" cells in the subprotocol's row of the IANA "WebSocket Subprotocol Name Registry" table should contain two entries. One entry in each of these cells should refer to the Websocket related subprotocol specification, and the other entry should refer to the data channel related subprotocol specification. NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. 9.2. New SDP Attributes 9.2.1. dcmap NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document defines a new SDP media-level attribute "a=dcmap:" as follows: Drage, et al. Expires November 12, 2019 [Page 20] Internet-Draft SDP-based Data Channel Negotiation May 2019 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | dcmap | | Attribute syntax: | As per Section 5.1.1 | | Attribute semantics: | As per Section 5.1.1 | | Usage level: | media | | Charset dependent: | No | | Purpose: | Define data channel specific parameters | | Appropriate values: | As per Section 5.1.1 | | O/A procedures: | As per Section 6 | | Mux category: | SPECIAL. See Section 5.1.9 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 9.2.2. dcsa NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document defines a new SDP media-level attribute "a=dcsa:" as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | dcsa | | Attribute syntax: | As per Section 5.2.1 | | Attribute semantics: | As per Section 5.2.1 | | Usage level: | media | | Charset dependent: | No | | Purpose: | Define data channel subprotocol specific | | | attributes | | Appropriate values: | As per Section 5.2.1 | | O/A procedures: | As per Section 6 | | Mux category: | SPECIAL. See Section 5.2.2 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 10. Contributors Juergen Stoetzer-Bradler co-authored this document. 11. Acknowledgments The authors wish to acknowledge the borrowing of ideas from other internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Drage, et al. Expires November 12, 2019 [Page 21] Internet-Draft SDP-based Data Channel Negotiation May 2019 Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their invaluable comments. Special thanks to Christer Holmberg for helping finish the document and cleaning the SDP offer/answer section. 12. CHANGE LOG 12.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' o Editorial changes separate sections for offer/answer procedures. o Update security section. 12.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' o Change "dtls-id" to "tls-id" and assign 20 octet long values o Remove of RFC4566bis draft from list of normative references. 12.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' o Modification of Keith's address information. 12.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' o dcmap-stream-id syntax change to limit size to 5 digits. o Add missing 'x' prefix to quoted-visible syntax. o Align SDP offerer and answerer handling when both max-retr and max-time are present. o Use of TEST-NET-1 ip addresses in examples. o Add missing a=dtls-id in one example. 12.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' o Removal of the "a=connection" attribute lines from all SDP examples. 12.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' o In the introduction: * Replacement of the sentence "The RTCWeb working group has defined the concept of bi-directional data channels running on Drage, et al. Expires November 12, 2019 [Page 22] Internet-Draft SDP-based Data Channel Negotiation May 2019 top of SCTP/DTLS (SCTP over the Datagram Transport Layer Security protocol)" with "The RTCWeb working group has defined the concept of bi-directional data channels running on top of the Stream Control Transmission Protocol (SCTP)". * Addition of following sentences to the second paragraph: "These procedures are based on generic SDP offer/answer negotiation rules for SCTP based media transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels could be defined over other SCTP based protocols, such as SCTP over IP. However, corresponding potential other "m" line proto values are not considered in this document." o Replacement of "DTLS connection" with "DTLS association" throughout the document. o In sections Section 5.1.9 and Section 5.2.2 removal of the sentences "This document also does not specify multiplexing rules for this attribute for SCTP or SCTP/DTLS proto values". o In the text related to "Subsequent SDP answer" in section Section 6.7 replacement of "The DTLS/SCTP association remains open ..." with "The SCTP association remains open ...". o In the text after the second SDP answer in section Section 7 replacement of "... (after SCTP/DTLS association is setup)" with "... (after the SCTP association is set up)". o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative references. o Addition of "a=dtls-id" attribute lines to the SDP offer/answer examples in Section 7. 12.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' o Addition of definition of "data channel subprotocol" to Section 3 as proposed on the MMUSIC list, https://www.ietf.org/mail- archive/web/mmusic/current/msg15827.html. o Addition of RFC4566bis draft to list of normative references. o Updates of tables in Section 9.2.1 and Section 9.2.2 as per section 8.2.4 of RFC4566bis draft. o Addition of new "new-usage-level">. Drage, et al. Expires November 12, 2019 [Page 23] Internet-Draft SDP-based Data Channel Negotiation May 2019 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' o Addition of two new paragraphs to Section 5.2.1 regarding subprotocol attribute relationship with transport protocol. o Addition of a note to Section 9.1 regarding subprotocols simultaneously defined for data channel and Websocket usage. o Addition of two further SDP offer/answer considerations to Section 6.7 regarding unknown subprotocol attributes and known subprotocol attributes with unknown data channel transport related semantic. 12.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' o Changes addressing Christian Groves's WGLC review comments raised in http://www.ietf.org/mail-archive/web/mmusic/current/ msg15357.html and http://www.ietf.org/mail- archive/web/mmusic/current/msg15359.html. 12.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' o In IANA registration Section 9.2.1 and Section 9.2.2 replacement of contact name and e-mail address with "MMUSIC Chairs" and "mmusic-chairs@ietf.org". o In Section 5.2.1 replacement of "Thus in the example above, the original attribute line "a=accept- types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/ plain", which specifies that this instance of MSRP being transported on the SCTP association using the data channel with stream id 2 accepts plain text files." with "... which specifies that this instance of the MSRP subprotocol being transported ...". o The last paragraph of Section 5.2.1 started with "Note: This document does not provide a complete specification ...". Removal of "Note:" and move of this paragraph to the introduction in Section 1 as last paragraph. o Section 5.2's headline was "Subprotocol Specific Attributes". Change of this headline to "Other Media Level Attributes" and adaptations of the first paragraph of this section and the first paragraph of Section 5.2.1 in order to clarify that not only those attributes may be encapsulated in a "dcsa" attribute, which are specifically defined for the subprotocol, but that also other attributes may be encapsulated if they are related to the specific subprotocol instance. Drage, et al. Expires November 12, 2019 [Page 24] Internet-Draft SDP-based Data Channel Negotiation May 2019 o Move of the last but one paragraph of Section 5.2.1 starting with "The same syntax applies to ..." right in front of the formal syntax definition of the "dcsa" attribute. o Modifications of the text in Section 5.1.9 and Section 5.2.2 in order not to explicitly restrict usage of the "a=dcmap:" and "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ SCTP" or "TCP/DTLS/SCTP". 12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' o In Section 5.1.4 the first (and only) paragraph was "The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string." Replacement of this paragraph with following two paragraphs: * The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new subprotocol parameter values are registered. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string. * Note: The empty string MAY also be explicitly used as 'subprotocol' value, such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'subprotocol' value to be an empty string. o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of normative references. o Addition of dcmap attribute specific IANA registration Section 9.2.1. o Addition of dcsa attribute specific IANA registration Section 9.2.2. o Addition of new Section 5.1.9 describing the mux category of the dcmap SDP attribute. This section and the new "a=dcsa:" attribute related mux category section are similar to the "Mux Category" sections of the "a=sctp-port:" and "a=max-message-size:" attributes in [I-D.ietf-mmusic-sctp-sdp]. Drage, et al. Expires November 12, 2019 [Page 25] Internet-Draft SDP-based Data Channel Negotiation May 2019 o Addition of new Section 5.2.2 describing the mux category of the dcsa SDP attribute. 12.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' o In Section 1 replacement of "RTCWeb leaves it open for other applications to use data channels and its in-band DCEP or out-of- band non-DCEP protocols for creating them" with "... to use data channels and its in-band DCEP or other in-band or out-of-band protocols for creating them". Additionally replacement of "In particular, the SDP offer generated by the application includes no channel-specific information" with "... generated by the RTCweb data channel stack includes no channel-specific information". o Move of former section 5 ("Data Channels") to new Appendix A and removal of JavaScript API specific discussions from this moved text (like mentioning of data channel stack specific states). Therefore former section 6 ("SDP Offer/Answer Negotiation") is now Section 5. o In Section 5: * Relacement of Section 5's first paragraph "This section defines a method of non-DCEP negotiation by which two clients can negotiate data channel-specific and subprotocol-specific parameters, using the out-of-band SDP offer/answer exchange. This SDP extension can only be used with the SDP offer/answer model." with "This section defines an SDP extension by which two clients can negotiate data channel-specific and subprotocol-specific parameters without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP extension only defines usage in the context of SDP offer/answer." * Addition of new paragraph: "Appendix A provides information how data channels work in general and especially summarizes some key aspects, which should be considered for the negotiation of data channels if DCEP is not used." o In Section 5.1 replacement of "The intention of exchanging these attributes is to create data channels on both the peers with the same set of attributes without actually using the DCEP [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging these attributes is to create, on two peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely directed data channels having the same set of attributes". o In Section 5.1.5 replacement of "The 'max-retr' parameter indicates the maximal number a user message will be retransmitted" Drage, et al. Expires November 12, 2019 [Page 26] Internet-Draft SDP-based Data Channel Negotiation May 2019 with "The 'max-retr' parameter indicates the maximal number of times a user message will be retransmitted". o In Section 6.1 replacement of "However, an SDP offer/answer exchange MUST NOT be initiated if the associated SCTP stream is already negotiated via DCEP" with "However, an SCTP stream MUST NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ answer exchange if the associated SCTP stream has already been negotiated via DCEP". o In the examples in Section 7 addition of the previously missing colons to the "a=sctp-port" attribute lines. 12.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' o Move of reference draft-ietf-rtcweb-jsep from the list of normative references to the list of informative references. Remover in -07 since not referenced o Addition of IANA SDP parameters to the list of informative references and addition of following two sentences to the first paragraph after the ABNF definition: "Note however that not all SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA registered session and media level or media level only SDP attributes." o In the introduction replacement of last sentence "This document defines SDP-based out-of-band negotiation procedures to establish data channels for transport of well-defined subprotocols" with "This document defines SDP offer/answer negotiation procedures to establish data channels for transport of well-defined subprotocols, to enable out-of-band negotiation". o Throughout the document replacement of "external negotiation" with "SDP offer/answer negotiation" and removal of term "external negotiation" from the terminology list in Section 3. o Throughout the document replacement of "internal negotiation" with "DCEP" and removal of terms "internal negotiation" and "in-band negotiation" from the terminology list in Section 3. o Addition of "SCTP Stream Sequence Number (SSN)" to the list of terms. o In Section 6.1 replacement of sentence "However, a single stream is managed using one method at a time." with "However, an SDP offer/answer exchange MUST NOT be initiated if the associated SCTP stream is already negotiated via DCEP". Drage, et al. Expires November 12, 2019 [Page 27] Internet-Draft SDP-based Data Channel Negotiation May 2019 o In Section 6.2 replacement of sentence "By definition max-retr and max-time are mutually exclusive, so only one of them can be present in a=dcmap" with "By definition max-retr and max-time are mutually exclusive, so aBoth MUST NOT be present in a=dcmap". o Move of reference [WebRtcAPI] from list of normative references to list of informative references. o Removal of almost all text parts, which discussed JavaScript or other API specific aspects. Such API specific aspects were mainly discussed in sub-sections of Section 5 and Section 5 of draft- ietf-mmusic-data-channel-sdpneg-02. 12.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' o New Section 4 regarding applicability to SDP offer/answer only. o Addition of new Section 9.1 "Subprotocol identifiers" as subsection of the "IANA Considerations" related Section 9. Also removal of the temporary note "To be completed. As [I-D.ietf- rtcweb-data-protocol] this document should refer to IANA's WebSocket Subprotocol Name Registry defined in [RFC6455]" o In Section 6.2: * In the first paragraph replacement of the sentence "If an SDP offer contains both of these parameters then such an SDP offer will be rejected." with "If an SDP offer contains both of these parameters then the receiver of such an SDP offer MUST reject the SDP offer." * In the second paragraph capitalization of "shall" and "may" such that both sentences now read: "The SDP answer SHALL echo the same subprotocol, max-retr, max-time, ordered parameters, if those were present in the offer, and MAY include a label parameter. They MAY appear in any order, which could be different from the SDP offer, in the SDP answer." * In the third paragraph replacement of the sentence "The same information MUST be replicated without changes in any subsequent offer or answer, as long as the data channel is still opened at the time of offer or answer generation." with "When sending a subsequent offer or an answer, and for as long as the data channel is still open, the sender MUST replicate the same information.". o In Section 6.2 the mapping of data channel types defined in [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute Drage, et al. Expires November 12, 2019 [Page 28] Internet-Draft SDP-based Data Channel Negotiation May 2019 parameters were illustrated using example "a=dcmap" attribute lines. Replacement of these example "a=dcmap" attribute lines with just the "a=dcmap" attribute parameters being relevant for the channel type. o In Section 6.7 the description of bullet point "SDP offer has no a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: No data channel negotiated yet." Replacement of this description with "Initial SDP offer: No data channel is negotiated yet. The DTLS connection and SCTP association is negotiated and, if agreed, established as per [I-D.ietf-mmusic-sctp-sdp]." o In Section 6.7 in both bullet points related to "Subsequent SDP offer" and "Subsequent SDP answer" replacement of "All the externally negotiated data channels must be closed now." with "All the externally negotiated data channels are expected to be closed now.". o In Appendix A.2.2's sixth paragraph replacement of the two occurrences of "must" with "MUST". o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" there was a comment saying that "Only maxretr-opt or maxtime-opt is present. Both MUST NOT be present." Removal of the second normative sentence and instead addition of following new paragraph to the end of this section: "Within an 'a=dcmap' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter is present. Both MUST NOT be present." o In Section 5.1.7 replacement of the first sentence "The 'ordered' parameter with value "true" indicates that DATA chunks in the channel MUST be dispatched to the upper layer by the receiver while preserving the order." with "The 'ordered' parameter with value "true" indicates that the receiver MUST dispatch DATA chunks in the data channel to the upper layer while preserving the order.". o In Section 6.3's first paragraph replacement of the one occurrence of "must" with "..., it MUST wait until ...". o In Section 6.6.1: * In the second paragraph replacement of "must" with "... whether this closing MUST in addition ..." * In the third paragraph replacement of the sentence "The port value for the "m" line SHOULD NOT be changed (e.g., to zero) when closing a data channel ..." with "The offerer SHOULD NOT Drage, et al. Expires November 12, 2019 [Page 29] Internet-Draft SDP-based Data Channel Negotiation May 2019 change the port value for the "m" line (e.g., to zero) when closing a data channel ...". * In the last but two paragraph replacement of the sentence "... then an SDP offer which excludes this closed data channel SHOULD be generated." with "... then the client SHOULD generate an SDP offer which excludes this closed data channel.". * In the last but one paragraph replacement of "must" with "The application MUST also close...". o In Section 5.2 addition of following note after the formal definition of the 'a=dcsa' attribute: "Note that the above reference to RFC 4566 defines were the attribute definition can be found; it does not provide any limitation on support of attributes defined in other documents in accordance with this attribute definition." 12.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' o In Section 3 "WebRTC data channel" was defined as "A bidirectional channel consisting of paired SCTP outbound and inbound streams." Replacement of this definition with "Data channel: A WebRTC data channel as specified in [I-D.ietf-rtcweb-data-channel]", and consistent usage of "data channel" in the remainder of the document including the document's headline." o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. In particular we expect "webrtc-datachannel" to become a more general term.' o Consistent usage of '"m" line' in whole document as per RFC4566. o In Section 5.1 removal of the example dcmap attribute line 'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are already four examples right after the ABNF rules in Section 5.1.1. Corresponding removal of following related note: "Note: This document does not provide a complete specification of how to negotiate the use of a WebRTC data channel to transport BFCP. Procedures specific to each subprotocol such as BFCP will be documented elsewhere. The use of BFCP is only an example of how the generic procedures described herein might apply to a specific subprotocol." o In Section 5.1 removal of following note: "Note: This attribute is derived from attribute "webrtc-DataChannel", which was defined in old version 03 of the following draft, but which was removed along Drage, et al. Expires November 12, 2019 [Page 30] Internet-Draft SDP-based Data Channel Negotiation May 2019 with any support for SDP external negotiation in subsequent versions: [I-D.ietf-mmusic-sctp-sdp]." o Insertion of following new sentence to the beginning of Section 5.1.1: "dcmap is a media level attribute having following ABNF syntax:" o Insertion of new Section 5.1.2 containing the dcmap-stream-id specifying sentence, which previously was placed right before the formal ABNF rules. Removal of the sentence 'Stream is a mandatory parameter and is noted directly after the "a=dcmap:" attribute's colon' as this information is part of the ABNF specification. o In Section 5.1.1 modification of the 'ordering-value' values from "0" or "1" to "true" or "false". Corresponding text modifications in Section 5.1.7. o In Section 5.1.1 the ABNF definition of "quoted-string" referred to rule name "escaped-char", which was not defined. Instead a rule with name "escaped" was defined. Renamed that rule's name to "escaped-char". o Insertion of a dedicated note right after the "a=dcmap:4" attribute example in Section 5.1.1 regarding the non-printable "escaped-char" character within the "label" value. o In Section 5.2's second paragraph replacement of "sctp stream identifier" with "SCTP stream identifier". o In first paragraph of Section 6.1 replacement of first two sentences 'For the SDP-based external negotiation described in this document, the initial offerer based "SCTP over DTLS" owns by convention the even stream identifiers whereas the initial answerer owns the odd stream identifiers. This ownership is invariant for the whole lifetime of the signaling session, e.g. it does not change if the initial answerer sends a new offer to the initial offerer.' with 'If an SDP offer/answer exchange (could be the initial or a subsequent one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media description being accepted, and if this SDP offer/answer exchange results in the establishment of a new SCTP association, then the SDP offerer owns the even SCTP stream ids of this new SCTP association and the answerer owns the odd SCTP stream identifiers. If this "m" line is removed from the signaling session (its port number set to zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is renegotiated later on, then the even and odd SCTP stream identifier ownership is redetermined as well as described above.' Drage, et al. Expires November 12, 2019 [Page 31] Internet-Draft SDP-based Data Channel Negotiation May 2019 o In Section 6.3 the first action of an SDP answerer, when receiving an SDP offer, was described as "Applies the SDP offer. Note that the browser ignores data channel specific attributes in the SDP." Replacement of these two sentences with "Parses and applies the SDP offer. Note that the typical parser normally ignores unknown SDP attributes, which includes data channel related attributes." o In Section 6.3 the second sentence of the third SDP answerer action was "Note that the browser is asked to create data channels with stream identifiers not "owned" by the agent.". Replacement of this sentence with "Note that the agent is asked to create data channels with SCTP stream identifiers contained in the SDP offer if the SDP offer is accepted." o In Section 6.6.1 the third paragraph began with "A data channel can be closed by sending a new SDP offer which excludes the dcmap and dcsa attribute lines for the data channel. The port value for the m line SHOULD NOT be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST also exclude the corresponding attribute lines in the answer. ..." Replacement of this part with "The intention to close a data channel can be signaled by sending a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute lines for the data channel. The port value for the "m" line SHOULD NOT be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST close those data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the received SDP offer, unless those data channels were already closed, and it MUST also exclude the corresponding attribute lines in the answer." o In Section 6.6.1 the hanging text after the third paragraph was "This delayed close is to handle cases where a successful SDP answer is not received, in which case the state of session should be kept per the last successful SDP offer/answer." Replacement of this sentence with "This delayed closure is RECOMMENDED in order to handle cases where a successful SDP answer is not received, in which case the state of the session SHOULD be kept per the last successful SDP offer/answer." o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects Section 5.1 contained already procedural descriptions related to data channel reliability negotiation. Creation of new Section 6.2 Drage, et al. Expires November 12, 2019 [Page 32] Internet-Draft SDP-based Data Channel Negotiation May 2019 and moval of reliability negotiation related text to this new section. 12.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' o Removal of note "ACTION ITEM" from section "subprotocol parameter". As [I-D.ietf-rtcweb-data-protocol] this document should refer to IANA's WebSocket Subprotocol Name Registry defined in [RFC6455] o In whole document, replacement of "unreliable" with "partially reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in [I-D.ietf-rtcweb-data-protocol] in most places. o Clarification of the semantic if the "max-retr" parameter is not present in an "a=dcmap" attribute line. In section "max-retr parameter" the sentence "The max-retr parameter is optional with default value unbounded" was replaced with "The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal number of retransmissions is determined as per the generic SCTP retransmission rules as specified in [RFC4960]". o Clarification of the semantic if the "max-time" parameter is not present in an "a=dcmap" attribute line. In section "max-time parameter" the sentence "The max-time parameter is optional with default value unbounded" was replaced with "The max-time parameter is optional. If the max-time parameter is not present, then the generic SCTP retransmission timing rules apply as specified in [RFC4960]". o In section "label parameter" the sentence "Label is a mandatory parameter." was removed and following new sentences (including the note) were added: "The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. Note: The empty string may also be explicitly used as 'label' value, such that 'label=""' is equivalent to the 'label' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." o In section "subprotocol parameter" the sentence "subprotocol is a mandatory parameter." was replaced with "'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string." o In the "Examples" section, in the first two SDP offer examples in the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 'label="bfcp"'. Drage, et al. Expires November 12, 2019 [Page 33] Internet-Draft SDP-based Data Channel Negotiation May 2019 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were replaced with "a=max-message-size" attribute lines, as per draft- ietf-mmusic-sctp-sdp-12. 12.17. Changes against '-01' o Formal syntax for dcmap and dcsa attribute lines. o Making subprotocol as an optional parameter in dcmap. o Specifying disallowed parameter combinations for max-time and max- retr. o Clarifications on WebRTC data channel close procedures. 12.18. Changes against '-00' o Revisions to identify difference between internal and external negotiation and their usage. o Introduction of more generic terminology, e.g. "application" instead of "browser". o Clarification of how "max-retr and max-time affect the usage of unreliable and reliable WebRTC data channels. o Updates of examples to take into account the SDP syntax changes introduced with draft-ietf-mmusic-sctp-sdp-07. o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" attributes as this is now contained in the a=sctp-port attribute, and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP association on top of the DTLS connection. 13. References 13.1. Normative References [I-D.ietf-mmusic-rfc4566bis] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", draft-ietf-mmusic- rfc4566bis-32 (work in progress), December 2018. Drage, et al. Expires November 12, 2019 [Page 34] Internet-Draft SDP-based Data Channel Negotiation May 2019 [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 2017. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [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-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. [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, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Drage, et al. Expires November 12, 2019 [Page 35] Internet-Draft SDP-based Data Channel Negotiation May 2019 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf- clue-datachannel-18 (work in progress), April 2019. [I-D.ietf-mmusic-msrp-usage-data-channel] Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Marcon, J., and J. Recio, "MSRP over Data Channels", draft-ietf-mmusic-msrp-usage-data-channel-10 (work in progress), April 2019. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, . [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, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [WebRtcAPI] Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium CR CR-webrtc-20180927, September 2018, . Appendix A. Generic Data Channel Negotiation Aspects When Not Using DCEP This appendix summarizes how data channels work in general and discusses some key aspects, which should be considered for the out- of-band negotiation of data channels if DCEP is not used. Drage, et al. Expires November 12, 2019 [Page 36] Internet-Draft SDP-based Data Channel Negotiation May 2019 A WebRTC application creates a data channel by providing a number of setup parameters (subprotocol, label, maximal number of retransmissions, maximal retransmission time, order of delivery, priority). The application also specifies if it wants to make use of the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if the application intends to negotiate data channels using the SDP offer/answer protocol. In any case, the SDP offer generated by the application is per [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for the SCTP association on top of which data channels will run: m=application 54111 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=tls-id:abc3de65cddef001be82 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB Note: A WebRTC application will only use "m" line format "webrtc- datachannel", and will not use other formats in the "m" line for other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports only one SCTP association to be established on top of a DTLS association. Note: The above SDP media description does not contain any channel- specific information. A.1. Stream Identifier Numbering Independently from the requested type of negotiation, the application creating a data channel can either pass the stream identifier to the data channel stack to assign to the data channel or else let the data channel stack pick one identifier from the unused ones. To avoid glare situations [RFC3264], each endpoint can moreover own an exclusive set of stream identifiers, in which case an endpoint can only create a data channel with a stream identifier it owns. Which set of stream identifiers is owned by which endpoint is determined by convention or other means. Note:For data channels negotiated with the DCEP, one endpoint owns by convention the even stream identifiers, whereas the other owns the odd stream identifiers, as defined in [I-D.ietf-rtcweb-data-protocol]. Drage, et al. Expires November 12, 2019 [Page 37] Internet-Draft SDP-based Data Channel Negotiation May 2019 Note:For data channels negotiated via different protocol from DCEP, no convention is defined by default. A.2. Generic Data Channel Negotiation Not Using DCEP A.2.1. Overview DCEP negotiation only provides for negotiation of data channel transport parameters and does not provide for negotiation of subprotocol specific parameters. DCEP-less data channel negotiation can be defined to allow negotiation of parameters beyond those handled by DCEP, e.g., parameters specific to the subprotocol instantiated on a particular data channel. The following procedures are common to all methods of data channel negotiation not using DCEP, whether in-band (communicated using proprietary means on an already established data channel) or out-of- band (using SDP offer/answer or some other protocol associated with the signaling channel). A.2.2. Opening a Data Channel In the case of DCEP-less negotiation, the endpoint application has the option to fully control the stream identifier assignments. However these assignments have to coexist with the assignments controlled by the data channel stack for the DCEP negotiated data channels (if any). It is the responsibility of the application to ensure consistent assignment of stream identifiers. When the application requests the creation of a new data channel to be set up via DCEP-less negotiation, the data channel stack creates the data channel locally without sending any DATA_CHANNEL_OPEN message in-band. However, even if the ICE (Interactive Connectivity Establishment), DTLS and SCTP procedures were already successfully completed, the application can't send data on this data channel until the negotiation is complete with the peer. This is because the peer needs to be aware of and accept the usage of this data channel. The peer, after accepting the data channel offer, can start sending data immediately. This implies that the offerer may receive data channel subprotocol messages before the negotiation is complete and the application should be ready to handle it. If the peer rejects the data channel part of the offer then it doesn't have to do anything as the data channel was not created using the stack. The offerer on the other hand needs to close the data channel that was opened by invoking relevant data channel stack API procedures. Drage, et al. Expires November 12, 2019 [Page 38] Internet-Draft SDP-based Data Channel Negotiation May 2019 It is also worth noting that a data channel stack implementation may not provide any API to create and close data channels; instead the data channels may be used on the fly as needed just by communicating via non-DCEP means or by even having some local configuration/ assumptions on both the peers. The application then negotiates the data channel properties and subprotocol properties with the peer's application using a mechanism different from DCEP. The peer then symmetrically creates a data channel with these negotiated data channel properties. This is the only way for the peer's data channel stack to know which properties to apply when transmitting data on this channel. The data channel stack must allow data channel creation with any non-conflicting stream identifier so that both peers can create the data channel with the same stream identifier. A.2.3. Closing a Data Channel When the application requests the closing of a data channel negotiated without DCEP, the data channel stack always performs an SCTP SSN reset for this channel. Depending upon the method used for DCEP-less negotiation and the subprotocol associated with the data channel, the closing might in addition be signaled to the peer via SDP offer/answer negotiation. Authors' Addresses Keith Drage Unaffiliated Email: drageke@ntlworld.com Maridi R. Makaraju (Raju) Nokia 2000 Lucent Lane Naperville, Illinois US Email: Raju.Makaraju@nokia.com Drage, et al. Expires November 12, 2019 [Page 39] Internet-Draft SDP-based Data Channel Negotiation May 2019 Richard Ejzak Unaffiliated Email: richard.ejzak@gmail.com Jerome Marcon Unaffiliated Email: jeromee.marcon@free.fr Roni Even (editor) Huawei Email: roni.even@huawei.com Drage, et al. Expires November 12, 2019 [Page 40] ./draft-ietf-pim-yang-17.txt0000644000764400076440000060776413300110563015115 0ustar iustyiusty PIM Working Group X. Liu Internet-Draft Volta Networks Intended status: Standards Track P. McAllister Expires: November 20, 2018 Metaswitch Networks A. Peter Individual M. Sivakumar Juniper Networks Y. Liu Huawei Technologies F. Hu ZTE Corporation May 19, 2018 A YANG Data Model for Protocol Independent Multicast (PIM) draft-ietf-pim-yang-17 Abstract This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). The model covers the PIM protocol configuration, operational state, and event notifications 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 https://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 20, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires November 20, 2018 [Page 1] Internet-Draft PIM YANG May 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 6 2.1. Scope of Model . . . . . . . . . . . . . . . . . . . . . 6 2.2. Optional Capabilities . . . . . . . . . . . . . . . . . . 6 2.3. Datastore Applicability . . . . . . . . . . . . . . . . . 7 2.4. Module and Hierarchy Organization . . . . . . . . . . . . 7 2.5. Position of Address Family in Hierarchy . . . . . . . . . 7 3. Module Structure . . . . . . . . . . . . . . . . . . . . . . 8 3.1. PIM Base Module . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. High-Level Structure . . . . . . . . . . . . . . . . 8 3.1.2. Global Data . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Per Address Family Data . . . . . . . . . . . . . . . 9 3.1.4. PIM Interface Modeling . . . . . . . . . . . . . . . 11 3.1.5. Neighbor Modeling . . . . . . . . . . . . . . . . . . 12 3.1.6. Notifications . . . . . . . . . . . . . . . . . . . . 12 3.2. PIM RP Module . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Static RP . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. BSR . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3. RP State Data . . . . . . . . . . . . . . . . . . . . 15 3.2.4. RP to Group Mappings . . . . . . . . . . . . . . . . 16 3.2.5. Notifications . . . . . . . . . . . . . . . . . . . . 16 3.3. PIM-SM Module . . . . . . . . . . . . . . . . . . . . . . 17 3.4. PIM-DM Module . . . . . . . . . . . . . . . . . . . . . . 18 3.5. PIM-BIDIR Module . . . . . . . . . . . . . . . . . . . . 18 4. Complete Tree Structure . . . . . . . . . . . . . . . . . . . 20 4.1. PIM Base Module . . . . . . . . . . . . . . . . . . . . . 20 4.2. PIM RP Module . . . . . . . . . . . . . . . . . . . . . . 25 4.3. PIM-SM Module . . . . . . . . . . . . . . . . . . . . . . 26 4.4. PIM-DM Module . . . . . . . . . . . . . . . . . . . . . . 27 4.5. PIM-BIDIR Module . . . . . . . . . . . . . . . . . . . . 28 5. Relationship to the PIM-STD-MIB . . . . . . . . . . . . . . . 29 5.1. pimInterfaceTable . . . . . . . . . . . . . . . . . . . . 29 5.2. pimNeighborTable . . . . . . . . . . . . . . . . . . . . 30 Liu, et al. Expires November 20, 2018 [Page 2] Internet-Draft PIM YANG May 2018 5.3. pimStarGTable . . . . . . . . . . . . . . . . . . . . . . 31 5.4. pimSGTable . . . . . . . . . . . . . . . . . . . . . . . 32 5.5. pimSGRptTable . . . . . . . . . . . . . . . . . . . . . . 32 5.6. pimBidirDFElectionTable . . . . . . . . . . . . . . . . . 33 5.7. pimStaticRPTable . . . . . . . . . . . . . . . . . . . . 33 5.8. pimAnycastRPSetTable . . . . . . . . . . . . . . . . . . 34 5.9. pimGroupMappingTable . . . . . . . . . . . . . . . . . . 34 6. PIM YANG Modules . . . . . . . . . . . . . . . . . . . . . . 35 6.1. PIM base module . . . . . . . . . . . . . . . . . . . . . 35 6.2. PIM RP Module . . . . . . . . . . . . . . . . . . . . . . 58 6.3. PIM-SM Module . . . . . . . . . . . . . . . . . . . . . . 73 6.4. PIM-DM Module . . . . . . . . . . . . . . . . . . . . . . 79 6.5. PIM-BIDIR Module . . . . . . . . . . . . . . . . . . . . 81 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 93 11.2. Informative References . . . . . . . . . . . . . . . . . 96 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 1. Introduction YANG [RFC7950] is a data modeling language that was introduced to model the configuration and operational state of a device managed using network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. YANG is now also being used as a component of other management interfaces, such as CLIs. This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). This model supports the core PIM protocol, as well as many other features described in Section 2.1. Non-core features are defined as optional in the provided data model. 1.1. Terminology The terminology for describing YANG data models is found in [RFC7950]. The following abbreviations are used in this document and the defined model: ASM: Any-Source Multicast service model [RFC3569] [RFC4607]. Liu, et al. Expires November 20, 2018 [Page 3] Internet-Draft PIM YANG May 2018 BFD: Bidirectional Forwarding Detection [RFC5880]. BSR: Bootstrap Router [RFC5059]. DF: Designated Forwarder [RFC5015]. DR: Designated Router [RFC7761]. IGMP: Internet Group Management Protocol [RFC3376]. MLD: Multicast Listener Discovery [RFC3810]. MSDP: Multicast Source Discovery Protocol [RFC3618]. mLDP: Multipoint extensions for LDP [RFC6388]. MRIB: Multicast Routing Information Base [RFC3973] [RFC5015] [RFC7761]. mVPN: Multicast VPN. PIM: Protocol Independent Multicast. [RFC3973] [RFC5015] [RFC7761]. PIM-BIDIR: Protocol Independent Multicast - Bidirectional Mode [RFC5015]. PIM-DM: Protocol Independent Multicast - Dense Mode [RFC3973]. PIM-SM: Protocol Independent Multicast - Sparse Mode [RFC7761]. RP: Rendezvous Point. [RFC7761]. RPA: Rendezvous Point Address. [RFC5015]. Liu, et al. Expires November 20, 2018 [Page 4] Internet-Draft PIM YANG May 2018 RPF: Reverse Path Forwarding. [RFC3973] [RFC5015] [RFC7761]. RPT: Rendezvous-Point Tree. [RFC7761]. SPT: Shortest Path Tree. [RFC7761]. SSM: Source-Specific Multicast service model [RFC3569] [RFC4607]. VRF: Virtual Routing and Forwarding. 1.2. Tree Diagrams Tree diagrams used in this document follow the notation defined in [RFC8340]. In addition, the following notation is used as a placeholder at the location of the name of a tree node, to represent a section of nodes: 1.3. Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +-----------+--------------------+---------------------+ | Prefix | YANG module | Reference | +-----------+--------------------+---------------------+ | yang | ietf-yang-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] | | if | ietf-interfaces | [RFC8343] | | rt | ietf-routing | [RFC8349] | | rt-types | ietf-routing-types | [RFC8294] | | bfd-types | ietf-bfd-types | [I-D.ietf-bfd-yang] | +-----------+--------------------+---------------------+ Table 1: Prefixes and Corresponding YANG Modules Liu, et al. Expires November 20, 2018 [Page 5] Internet-Draft PIM YANG May 2018 2. Design of Data Model 2.1. Scope of Model The model covers PIM Sparse Mode [RFC7761], including the Source- Specific subset [RFC3569] [RFC4607], Dense Mode [RFC3973], and Bi- directional PIM [RFC5015]. The PIM extensions represented in the model include BSR [RFC5059] and Anycast-RP [RFC4610]. The data model can be used to configure and manage these protocol features. The operational state data and statistics can be retrieved by this model. The protocol specific notifications are also defined in the model. This model does not cover other multicast protocols such as IGMP/MLD, MSDP, mVPN, or mLDP in-band signalling. It does not cover any configuration required to generate the MRIB. These will be specified in separate documents. 2.2. Optional Capabilities This model is designed to represent the capabilities of devices supporting PIM with various specifications, including some with basic subsets of the PIM protocol. The main design goals of this document are that any major now-existing implementation may be said to support the base model, and that the configuration of all implementations meeting the specification is easy to express through some combination of the features in the base model and simple vendor augmentations. There is also value in widely-supported features being standardized, to save work for individual vendors, and so that mapping between different vendors' configuration is not needlessly complicated. Therefore, these modules declare a number of features representing capabilities that not all deployed devices support. The extensive use of feature declarations should also substantially simplify the capability negotiation process for a vendor's PIM implementation. On the other hand, operational state parameters are not so widely designated as features, as there are many cases where the defaulting of an operational state parameter would not cause any harm to the system, and it is much more likely that an implementation without native support for a piece of operational state would be able to derive a suitable value for a state variable that is not natively supported. Liu, et al. Expires November 20, 2018 [Page 6] Internet-Draft PIM YANG May 2018 For the same reason, wide constant ranges (for example, timer maxima and minima) are used in the model. It is expected that vendors will augment the model with any specific extensions and restrictions needed to adapt it to their vendor-specific implementation. 2.3. Datastore Applicability This model conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [I-D.ietf-netmod-rfc6087bis]. 2.4. Module and Hierarchy Organization This model defines several separate modules for modelling PIM configuration, defined below. Again, this separation makes it easier to express the specific capabilities of a PIM device. The module organization, along with the usage of the YANG extensible features such as identity, allows the model to be easily augmented for new capabilities. The hierarchy of PIM configuration is designed so that objects that are only relevant for one situation or feature are collected in a container for that feature. For example, the configuration for PIM- SM that is not relevant for an SSM-only implementation is collected in an ASM container. Where fields are not genuinely essential to protocol operation, they are marked as optional. Some fields are essential but have a default specified, so they need not be explicitly configured. This module structure also applies, where applicable, to the operational state and notifications of the model. 2.5. Position of Address Family in Hierarchy This document contains address-family as a node in the hierarchy multiple times: both under the interface list, and under the PIM instance. The reasoning for this is to make it easier for implementations in which configuration options are not supported for specific address families. For these implementations, the restriction that interface configuration must be address-family independent may either be expressed as a vendor augmentation of an address-family-independent Liu, et al. Expires November 20, 2018 [Page 7] Internet-Draft PIM YANG May 2018 parameter above the address-family level, or by a constraint on the base model objects of a form similar to: deviation "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { deviate add { must "(address-family = 'rt:ipv4' and dr-priority = " + "../address-family[address-family = 'rt:ipv6']/" + "dr-priority) or " + "(address-family = 'rt:ipv6' and dr-priority = " + "../address-family[address-family = 'rt:ipv4']/" + "dr-priority)" { error-message "Error: IPv6 DR priority must match IPv4 DR priority."; error-app-tag "dr-priority-mismatch"; } } } 3. Module Structure 3.1. PIM Base Module The PIM base module defines the base framework not specific to any PIM mode, and is imported by the other modules. The base module by itself does not provide sufficient data for any PIM mode to operate. Other mode specific and feature specific modules need to be implemented in addition to this module, depending on the feature set required by the implementation. This model augments the core routing data model "ietf-routing" specified in [RFC8349]. The PIM base model augments "/rt:routing/ rt:control-plane-protocols" as opposed to augmenting "/rt:routing/ rt:control-plane-protocols/rt:control-plane-protocol", as the latter would allow multiple protocol instances, while the PIM protocol is designed to be enabled or disabled as a single protocol instance on a network instance or a logical network element. 3.1.1. High-Level Structure The high-level structure of the model is shown below: Liu, et al. Expires November 20, 2018 [Page 8] Internet-Draft PIM YANG May 2018 module: ietf-pim-base augment /rt:routing/rt:control-plane-protocols: +--rw pim! +--rw +--ro +--rw address-family* [address-family] | +--rw address-family identityref | +--rw | +--ro +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw address-family* [address-family] +--rw address-family identityref +--rw +--ro +--ro neighbors +--ro ipv4-neighbor* [address] | +--ro address inet:ipv4-address | +--ro +--ro ipv6-neighbor* [address] +--ro address inet:ipv6-address +--ro The presence of the top-level container "pim" enables the PIM protocols. 3.1.2. Global Data The global configuration and operational state data covers the support for graceful restart in the PIM base model. Additional features can be added by augmentation if required by an implementation. 3.1.3. Per Address Family Data The support for per address family data is shown below: Liu, et al. Expires November 20, 2018 [Page 9] Internet-Draft PIM YANG May 2018 +--rw pim! +--rw address-family* [address-family] | +--rw address-family identityref | +--rw graceful-restart ... | +--ro statistics | | +--ro discontinuity-time? yang:date-and-time | | +--ro error | | | +--ro assert? yang:counter32 ... | | +--ro queue | | | +--ro size? uint32 | | | +--ro overflow? yang:counter32 | | +--ro received | | | +--ro assert? yang:counter32 ... | | +--ro sent | | +--ro assert? yang:counter32 ... | +--ro topology-tree-info | | +--ro ipv4-route* [group source-address is-rpt] | | | +--ro group | | | | rt-types:ipv4-multicast-group-address | | | +--ro source-address | | | | rt-types:ipv4-multicast-source-address | | | +--ro is-rpt boolean | | +--ro ipv6-route* [group source-address is-rpt] | | +--ro group | | | rt-types:ipv6-multicast-group-address | | +--ro source-address | | | rt-types:ipv6-multicast-source-address | | +--ro is-rpt boolean ... | | +--ro incoming-interface? if:interface-ref ... | | +--ro outgoing-interface* [name] | | +--ro name if:interface-ref | | +--ro expiration? rt-types:timer-value-seconds16 | | +--ro up-time? rt-types:timeticks64 | | +--ro jp-state? enumeration This is the location that most of the PIM RP module (ietf-pim-rp) augments. Each of the mode specific modules also augments this schema tree. Liu, et al. Expires November 20, 2018 [Page 10] Internet-Draft PIM YANG May 2018 3.1.4. PIM Interface Modeling The configuration and operational state data of PIM interfaces is modeled as below: +--rw pim! +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw address-family* [address-family] +--rw address-family identityref +--rw bfd {bfd}? ... +--rw dr-priority? uint32 {intf-dr-priority}? +--rw hello-interval? rt-types:timer-value-seconds16 | {intf-hello-interval}? +--rw (hello-holdtime-or-multiplier)? | +--:(holdtime) {intf-hello-holdtime}? | | +--rw hello-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-hello-multiplier}? | +--rw hello-multiplier? | rt-types:timer-multiplier +--rw jp-interval? rt-types:timer-value-seconds16 | {intf-jp-interval}? +--rw (jp-holdtime-or-multiplier)? | +--:(holdtime) {intf-jp-holdtime}? | | +--rw jp-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-jp-multiplier}? | +--rw jp-multiplier? | rt-types:timer-multiplier +--rw override-interval? uint16 | {intf-override-interval}? +--rw propagation-delay? uint16 | {intf-propagation-delay}? +--ro oper-status? enumeration +--ro gen-id? uint32 +--ro hello-expiration? rt-types:timer-value-seconds16 +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 | +--ro address* inet:ipv6-address | +--ro dr-address? inet:ipv6-address Liu, et al. Expires November 20, 2018 [Page 11] Internet-Draft PIM YANG May 2018 The support for bfd is achieved by using a grouping provided by an external module ietf-bfd-types, defined in [I-D.ietf-bfd-yang]. 3.1.5. Neighbor Modeling For each PIM interface, there can be a list of neighbors, which contain operational state data. To model such data, the following structure is specified: +--rw pim! +--rw interfaces +--rw interface* [name] +--rw address-family* [address-family] +--ro neighbors +--ro ipv4-neighbor* [address] | +--ro address inet:ipv4-address | +--ro bfd-status? enumeration | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro dr-priority? uint32 | +--ro gen-id? uint32 | +--ro lan-prune-delay | | +--ro present? boolean | | +--ro override-interval? uint16 | | +--ro propagation-delay? uint16 | | +--ro t-bit? boolean | +--ro up-time? rt-types:timeticks64 +--ro ipv6-neighbor* [address] +--ro address inet:ipv6-address +--ro bfd-status? enumeration +--ro expiration? | rt-types:timer-value-seconds16 +--ro dr-priority? uint32 +--ro gen-id? uint32 +--ro lan-prune-delay | +--ro present? boolean | +--ro override-interval? uint16 | +--ro propagation-delay? uint16 | +--ro t-bit? boolean +--ro up-time? rt-types:timeticks64 3.1.6. Notifications The PIM base module also defines the notifications for PIM interface and neighbor events, as shown below: Liu, et al. Expires November 20, 2018 [Page 12] Internet-Draft PIM YANG May 2018 notifications: +---n pim-neighbor-event | +--ro event-type? neighbor-event-type | +--ro interface-ref? leafref | +--ro interface-af-ref? leafref | +--ro neighbor-ipv4-ref? leafref | +--ro neighbor-ipv6-ref? leafref | +--ro up-time? rt-types:timeticks64 +---n pim-interface-event +--ro event-type? interface-event-type +--ro interface-ref? leafref +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 +--ro address* inet:ipv6-address +--ro dr-address? inet:ipv6-address 3.2. PIM RP Module The PIM RP module augments the PIM base module to define the configuration and operational state information scoped to RP related features: module: ietf-pim-rp augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw rp +--rw static-rp ... +--rw bsr {bsr}? ... +--ro rp-list ... +--ro rp-mappings ... This module is shared by the PIM-SM mode and the PIM-BIDIR mode, but not by the PIM-DM mode. PIM-SM module and PIM-BIDIR module augment this module to cover mode specific data. The following sections describe the features and capabilities covered in this module. Liu, et al. Expires November 20, 2018 [Page 13] Internet-Draft PIM YANG May 2018 3.2.1. Static RP Static RPs can be configured by using the following portion of the module: +--rw rp +--rw static-rp | +--rw ipv4-rp* [rp-address] | | +--rw rp-address inet:ipv4-address | +--rw ipv6-rp* [rp-address] | +--rw rp-address inet:ipv6-address 3.2.2. BSR The support for BSR includes both configuration data and operational state data, as shown below: Liu, et al. Expires November 20, 2018 [Page 14] Internet-Draft PIM YANG May 2018 +--rw rp +--rw bsr {bsr}? | +--rw bsr-candidate! | | +--rw (interface-or-address)? | | | +--:(interface) {candidate-interface}? | | | | +--rw interface if:interface-ref | | | +--:(ipv4-address) {candidate-ipv4}? | | | | +--rw ipv4-address inet:ipv4-address | | | +--:(ipv6-address) {candidate-ipv6}? | | | +--rw ipv6-address inet:ipv6-address | | +--rw hash-mask-length uint8 | | +--rw priority? uint8 | +--rw rp-candidate | | +--rw interface* [name] {candidate-interface}? | | | +--rw name if:interface-ref | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv4-address* [address] {candidate-ipv4}? | | | +--rw address inet:ipv4-address | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv6-address* [address] {candidate-ipv6}? | | +--rw address inet:ipv6-address | | +--rw policy-name? string | | +--rw mode? identityref | +--ro bsr | | +--ro address? inet:ip-address | | +--ro hash-mask-length? uint8 | | +--ro priority? uint8 | | +--ro up-time? rt-types:timeticks64 | +--ro (election-state)? {bsr-election-state}? | | +--:(candidate) | | | +--ro candidate-bsr-state? enumeration | | +--:(non-candidate) | | +--ro non-candidate-bsr-state? enumeration | +--ro bsr-next-bootstrap? uint16 | +--ro rp | | +--ro rp-address? inet:ip-address | | +--ro policy-name? string | | +--ro up-time? rt-types:timeticks64 | +--ro rp-candidate-next-advertisement? uint16 3.2.3. RP State Data This portion of the model provides the operational state information for all RPs on the router, including the statically configured RPs and the BSR elected RPs. Liu, et al. Expires November 20, 2018 [Page 15] Internet-Draft PIM YANG May 2018 +--rw rp +--ro rp-list | +--ro ipv4-rp* [rp-address mode] | | +--ro rp-address inet:ipv4-address | | +--ro mode identityref | | +--ro info-source-address? inet:ipv4-address | | +--ro info-source-type? identityref | | +--ro up-time? rt-types:timeticks64 | | +--ro expiration? rt-types:timer-value-seconds16 | +--ro ipv6-rp* [rp-address mode] | +--ro rp-address inet:ipv6-address | +--ro mode identityref | +--ro info-source-address? inet:ipv6-address | +--ro info-source-type? identityref | +--ro up-time? rt-types:timeticks64 | +--ro expiration? rt-types:timer-value-seconds16 3.2.4. RP to Group Mappings The operational state data of the mappings between RPs and multicast groups is modeled as follows: +--rw rp +--ro rp-mappings +--ro ipv4-rp* [group rp-address] | +--ro group inet:ipv4-prefix | +--ro rp-address inet:ipv4-address | +--ro up-time? rt-types:timeticks64 | +--ro expiration? rt-types:timer-value-seconds16 +--ro ipv6-rp* [group rp-address] +--ro group inet:ipv6-prefix +--ro rp-address inet:ipv6-address +--ro up-time? rt-types:timeticks64 +--ro expiration? rt-types:timer-value-seconds16 3.2.5. Notifications The PIM RP module also defines the notifications for RP related events, as shown below: Liu, et al. Expires November 20, 2018 [Page 16] Internet-Draft PIM YANG May 2018 notifications: +---n pim-rp-event +--ro event-type? rp-event-type +--ro instance-af-ref? leafref +--ro group? rt-types:ip-multicast-group-address +--ro rp-address? inet:ip-address +--ro is-rpt? boolean +--ro mode? pim-base:pim-mode +--ro message-origin? inet:ip-address 3.3. PIM-SM Module The PIM-SM module covers Sparse Mode modeling, including PIM-ASM and PIM-SSM. This module has dependencies on PIM base module and PIM RP module, both of which are augmented by this module. The augmentation to the address-family branch of the PIM base module is shown below: module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw sm +--rw asm | +--rw anycast-rp! | | +--rw ipv4-anycast-rp* [anycast-address rp-address] | | | +--rw anycast-address inet:ipv4-address | | | +--rw rp-address inet:ipv4-address | | +--rw ipv6-anycast-rp* [anycast-address rp-address] | | +--rw anycast-address inet:ipv6-address | | +--rw rp-address inet:ipv6-address | +--rw spt-switch | +--rw infinity! {spt-switch-infinity}? | +--rw policy-name? string {spt-switch-policy}? +--rw ssm! +--rw range-policy? string To support SM mode on an interface, this module augments the interface branch of the PIM base module, as follows: Liu, et al. Expires November 20, 2018 [Page 17] Internet-Draft PIM YANG May 2018 module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family: +--rw sm! +--rw passive? empty This module also augments the PIM RP module to allow an RP to be configured in the PIM-SM mode: module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv4-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv6-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? 3.4. PIM-DM Module The PIM-DM module covers Dense Mode modeling. This module augments the PIM base module, but it has no dependency on the PIM RP module. module: ietf-pim-dm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw dm! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw dm! 3.5. PIM-BIDIR Module The PIM-BIDIR module covers Bidirectional PIM modeling. Like PIM-SM, this module augments both PIM base module and PIM RP module. The followings are the augmentations to the PIM base module, on the address-family, the interface, and the neighbor branches: Liu, et al. Expires November 20, 2018 [Page 18] Internet-Draft PIM YANG May 2018 module: ietf-pim-bidir augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw bidir! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family: +--rw bidir! +--rw df-election {intf-df-election}? +--rw offer-interval? uint16 +--rw backoff-interval? uint16 +--rw offer-multiplier? uint8 augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family /pim-base:neighbors/pim-base:ipv4-neighbor: +--ro bidir-capable? boolean augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family /pim-base:neighbors/pim-base:ipv6-neighbor: +--ro bidir-capable? boolean This module also augments the PIM RP module to extend the capabilities of RP for the PIM-BIDIR mode: Liu, et al. Expires November 20, 2018 [Page 19] Internet-Draft PIM YANG May 2018 module: ietf-pim-bidir augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv4-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv6-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp: +--ro bidir +--ro df-election | +--ro ipv4-rp* [rp-address] | | +--ro rp-address inet:ipv4-address | +--ro ipv6-rp* [rp-address] | +--ro rp-address inet:ipv6-address +--ro interface-df-election +--ro ipv4-rp* [rp-address interface-name] | +--ro rp-address inet:ipv4-address | +--ro interface-name if:interface-ref | +--ro df-address? inet:ipv4-address | +--ro interface-state? identityref | +--ro up-time? rt-types:timeticks64 | +--ro winner-metric? uint32 | +--ro winner-metric-preference? uint32 +--ro ipv6-rp* [rp-address interface-name] +--ro rp-address inet:ipv6-address +--ro interface-name if:interface-ref +--ro df-address? inet:ipv6-address +--ro interface-state? identityref +--ro up-time? rt-types:timeticks64 +--ro winner-metric? uint32 +--ro winner-metric-preference? uint32 4. Complete Tree Structure 4.1. PIM Base Module module: ietf-pim-base augment /rt:routing/rt:control-plane-protocols: +--rw pim! Liu, et al. Expires November 20, 2018 [Page 20] Internet-Draft PIM YANG May 2018 +--rw graceful-restart | +--rw enabled? boolean | +--rw duration? uint16 +--rw address-family* [address-family] | +--rw address-family identityref | +--rw graceful-restart | | +--rw enabled? boolean | | +--rw duration? uint16 | +--ro statistics | | +--ro discontinuity-time? yang:date-and-time | | +--ro error | | | +--ro assert? yang:counter64 | | | +--ro bsr? yang:counter64 | | | +--ro candidate-rp-advertisement? yang:counter64 | | | +--ro df-election? yang:counter64 | | | +--ro graft? yang:counter64 | | | +--ro graft-ack? yang:counter64 | | | +--ro hello? yang:counter64 | | | +--ro join-prune? yang:counter64 | | | +--ro register? yang:counter64 | | | +--ro register-stop? yang:counter64 | | | +--ro state-refresh? yang:counter64 | | | +--ro checksum? yang:counter64 | | | +--ro format? yang:counter64 | | +--ro queue | | | +--ro size? uint32 | | | +--ro overflow? yang:counter32 | | +--ro received | | | +--ro assert? yang:counter64 | | | +--ro bsr? yang:counter64 | | | +--ro candidate-rp-advertisement? yang:counter64 | | | +--ro df-election? yang:counter64 | | | +--ro graft? yang:counter64 | | | +--ro graft-ack? yang:counter64 | | | +--ro hello? yang:counter64 | | | +--ro join-prune? yang:counter64 | | | +--ro register? yang:counter64 | | | +--ro register-stop? yang:counter64 | | | +--ro state-refresh? yang:counter64 | | +--ro sent | | +--ro assert? yang:counter64 | | +--ro bsr? yang:counter64 | | +--ro candidate-rp-advertisement? yang:counter64 | | +--ro df-election? yang:counter64 | | +--ro graft? yang:counter64 | | +--ro graft-ack? yang:counter64 | | +--ro hello? yang:counter64 | | +--ro join-prune? yang:counter64 Liu, et al. Expires November 20, 2018 [Page 21] Internet-Draft PIM YANG May 2018 | | +--ro register? yang:counter64 | | +--ro register-stop? yang:counter64 | | +--ro state-refresh? yang:counter64 | +--ro topology-tree-info | +--ro ipv4-route* [group source-address is-rpt] | | +--ro group | | | rt-types:ipv4-multicast-group-address | | +--ro source-address | | | rt-types:ipv4-multicast-source-address | | +--ro is-rpt boolean | | +--ro expiration? | | | rt-types:timer-value-seconds16 | | +--ro incoming-interface? if:interface-ref | | +--ro is-spt? boolean | | +--ro mode? identityref | | +--ro msdp-learned? boolean | | +--ro rp-address? inet:ip-address | | +--ro rpf-neighbor? inet:ip-address | | +--ro up-time? rt-types:timeticks64 | | +--ro outgoing-interface* [name] | | +--ro name if:interface-ref | | +--ro expiration? rt-types:timer-value-seconds16 | | +--ro up-time? rt-types:timeticks64 | | +--ro jp-state? enumeration | +--ro ipv6-route* [group source-address is-rpt] | +--ro group | | rt-types:ipv6-multicast-group-address | +--ro source-address | | rt-types:ipv6-multicast-source-address | +--ro is-rpt boolean | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro incoming-interface? if:interface-ref | +--ro is-spt? boolean | +--ro mode? identityref | +--ro msdp-learned? boolean | +--ro rp-address? inet:ip-address | +--ro rpf-neighbor? inet:ip-address | +--ro up-time? rt-types:timeticks64 | +--ro outgoing-interface* [name] | +--ro name if:interface-ref | +--ro expiration? rt-types:timer-value-seconds16 | +--ro up-time? rt-types:timeticks64 | +--ro jp-state? enumeration +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw address-family* [address-family] Liu, et al. Expires November 20, 2018 [Page 22] Internet-Draft PIM YANG May 2018 +--rw address-family identityref +--rw bfd {bfd}? | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval uint32 | | +--rw required-min-rx-interval uint32 | +--:(single-interval) | +--rw min-interval uint32 +--rw dr-priority? uint32 | {intf-dr-priority}? +--rw hello-interval? | rt-types:timer-value-seconds16 | {intf-hello-interval}? +--rw (hello-holdtime-or-multiplier)? | +--:(holdtime) {intf-hello-holdtime}? | | +--rw hello-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-hello-multiplier}? | +--rw hello-multiplier? | rt-types:timer-multiplier +--rw jp-interval? | rt-types:timer-value-seconds16 | {intf-jp-interval}? +--rw (jp-holdtime-or-multiplier)? | +--:(holdtime) {intf-jp-holdtime}? | | +--rw jp-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-jp-multiplier}? | +--rw jp-multiplier? | rt-types:timer-multiplier +--rw override-interval? uint16 | {intf-override-interval}? +--rw propagation-delay? uint16 | {intf-propagation-delay}? +--ro oper-status? enumeration +--ro gen-id? uint32 +--ro hello-expiration? | rt-types:timer-value-seconds16 +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 | +--ro address* inet:ipv6-address | +--ro dr-address? inet:ipv6-address +--ro neighbors +--ro ipv4-neighbor* [address] Liu, et al. Expires November 20, 2018 [Page 23] Internet-Draft PIM YANG May 2018 | +--ro address inet:ipv4-address | +--ro bfd-state? bfd-types:state | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro dr-priority? uint32 | +--ro gen-id? uint32 | +--ro lan-prune-delay | | +--ro present? boolean | | +--ro override-interval? uint16 | | +--ro propagation-delay? uint16 | | +--ro t-bit? boolean | +--ro up-time? rt-types:timeticks64 +--ro ipv6-neighbor* [address] +--ro address inet:ipv6-address +--ro bfd-state? bfd-types:state +--ro expiration? | rt-types:timer-value-seconds16 +--ro dr-priority? uint32 +--ro gen-id? uint32 +--ro lan-prune-delay | +--ro present? boolean | +--ro override-interval? uint16 | +--ro propagation-delay? uint16 | +--ro t-bit? boolean +--ro up-time? rt-types:timeticks64 notifications: +---n pim-neighbor-event | +--ro event-type? neighbor-event-type | +--ro interface-ref? leafref | +--ro interface-af-ref? leafref | +--ro neighbor-ipv4-ref? leafref | +--ro neighbor-ipv6-ref? leafref | +--ro up-time? rt-types:timeticks64 +---n pim-interface-event +--ro event-type? interface-event-type +--ro interface-ref? leafref +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 +--ro address* inet:ipv6-address +--ro dr-address? inet:ipv6-address Liu, et al. Expires November 20, 2018 [Page 24] Internet-Draft PIM YANG May 2018 4.2. PIM RP Module module: ietf-pim-rp augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw rp +--rw static-rp | +--rw ipv4-rp* [rp-address] | | +--rw rp-address inet:ipv4-address | +--rw ipv6-rp* [rp-address] | +--rw rp-address inet:ipv6-address +--rw bsr {bsr}? | +--rw bsr-candidate! | | +--rw (interface-or-address)? | | | +--:(interface) {candidate-interface}? | | | | +--rw interface if:interface-ref | | | +--:(ipv4-address) {candidate-ipv4}? | | | | +--rw ipv4-address inet:ipv4-address | | | +--:(ipv6-address) {candidate-ipv6}? | | | +--rw ipv6-address inet:ipv6-address | | +--rw hash-mask-length uint8 | | +--rw priority? uint8 | +--rw rp-candidate | | +--rw interface* [name] {candidate-interface}? | | | +--rw name if:interface-ref | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv4-address* [address] {candidate-ipv4}? | | | +--rw address inet:ipv4-address | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv6-address* [address] {candidate-ipv6}? | | +--rw address inet:ipv6-address | | +--rw policy-name? string | | +--rw mode? identityref | +--ro bsr | | +--ro address? inet:ip-address | | +--ro hash-mask-length? uint8 | | +--ro priority? uint8 | | +--ro up-time? rt-types:timeticks64 | +--ro (election-state)? {bsr-election-state}? | | +--:(candidate) | | | +--ro candidate-bsr-state? enumeration | | +--:(non-candidate) | | +--ro non-candidate-bsr-state? enumeration | +--ro bsr-next-bootstrap? uint16 | +--ro rp Liu, et al. Expires November 20, 2018 [Page 25] Internet-Draft PIM YANG May 2018 | | +--ro rp-address? inet:ip-address | | +--ro policy-name? string | | +--ro up-time? rt-types:timeticks64 | +--ro rp-candidate-next-advertisement? uint16 +--ro rp-list | +--ro ipv4-rp* [rp-address mode] | | +--ro rp-address inet:ipv4-address | | +--ro mode identityref | | +--ro info-source-address? inet:ipv4-address | | +--ro info-source-type? identityref | | +--ro up-time? rt-types:timeticks64 | | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro ipv6-rp* [rp-address mode] | +--ro rp-address inet:ipv6-address | +--ro mode identityref | +--ro info-source-address? inet:ipv6-address | +--ro info-source-type? identityref | +--ro up-time? rt-types:timeticks64 | +--ro expiration? | rt-types:timer-value-seconds16 +--ro rp-mappings +--ro ipv4-rp* [group-range rp-address] | +--ro group-range inet:ipv4-prefix | +--ro rp-address inet:ipv4-address | +--ro up-time? rt-types:timeticks64 | +--ro expiration? rt-types:timer-value-seconds16 +--ro ipv6-rp* [group-range rp-address] +--ro group-range inet:ipv6-prefix +--ro rp-address inet:ipv6-address +--ro up-time? rt-types:timeticks64 +--ro expiration? rt-types:timer-value-seconds16 notifications: +---n pim-rp-event +--ro event-type? rp-event-type +--ro instance-af-ref? leafref +--ro group? rt-types:ip-multicast-group-address +--ro rp-address? inet:ip-address +--ro is-rpt? boolean +--ro mode? identityref +--ro message-origin? inet:ip-address 4.3. PIM-SM Module Liu, et al. Expires November 20, 2018 [Page 26] Internet-Draft PIM YANG May 2018 module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw sm +--rw asm | +--rw anycast-rp! | | +--rw ipv4-anycast-rp* [anycast-address rp-address] | | | +--rw anycast-address inet:ipv4-address | | | +--rw rp-address inet:ipv4-address | | +--rw ipv6-anycast-rp* [anycast-address rp-address] | | +--rw anycast-address inet:ipv6-address | | +--rw rp-address inet:ipv6-address | +--rw spt-switch | +--rw infinity! {spt-switch-infinity}? | +--rw policy-name? string {spt-switch-policy}? +--rw ssm! +--rw range-policy? string augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw sm! +--rw passive? empty augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv4-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv6-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? 4.4. PIM-DM Module module: ietf-pim-dm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw dm! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw dm! Liu, et al. Expires November 20, 2018 [Page 27] Internet-Draft PIM YANG May 2018 4.5. PIM-BIDIR Module module: ietf-pim-bidir augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw bidir! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw bidir! +--rw df-election {intf-df-election}? +--rw offer-interval? uint16 +--rw backoff-interval? uint16 +--rw offer-multiplier? uint8 augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv4-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv6-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp: +--ro bidir +--ro df-election | +--ro ipv4-rp* [rp-address] | | +--ro rp-address inet:ipv4-address | +--ro ipv6-rp* [rp-address] | +--ro rp-address inet:ipv6-address +--ro interface-df-election +--ro ipv4-rp* [rp-address interface-name] | +--ro rp-address inet:ipv4-address | +--ro interface-name if:interface-ref | +--ro df-address? inet:ipv4-address | +--ro interface-state? identityref | +--ro up-time? rt-types:timeticks64 | +--ro winner-metric? uint32 | +--ro winner-metric-preference? uint32 +--ro ipv6-rp* [rp-address interface-name] +--ro rp-address inet:ipv6-address +--ro interface-name if:interface-ref +--ro df-address? inet:ipv6-address Liu, et al. Expires November 20, 2018 [Page 28] Internet-Draft PIM YANG May 2018 +--ro interface-state? identityref +--ro up-time? rt-types:timeticks64 +--ro winner-metric? uint32 +--ro winner-metric-preference? uint32 augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family/pim-base:neighbors /pim-base:ipv4-neighbor: +--ro bidir-capable? boolean augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family/pim-base:neighbors /pim-base:ipv6-neighbor: +--ro bidir-capable? boolean 5. Relationship to the PIM-STD-MIB The following sections describe the mappings between the objects in the PIM-STD-MIB defined in [RFC5060] and the YANG data nodes defined in this document. 5.1. pimInterfaceTable pimInterfaceTable is mapped to pim/interfaces/interface. The key of pimInterfaceTable is pimInterfaceIfIndex and pimInterfaceIPVersion, while the key of the "interface" list in YANG is the node "name". For each value of pimInterfaceIPVersion, the "interface" list contains a corresponding sublist whose key is the node "address- family". The following table lists the YANG data nodes with corresponding objects of pimInterfaceTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 29] Internet-Draft PIM YANG May 2018 +------------------------+----------------------------------+ | YANG node | PIM-STD-MIB object | +------------------------+----------------------------------+ | address-family | pimInterfaceAddressType | | ipv4/address | pimInterfaceAddress | | ipv6/address | | | gen-id | pimInterfaceGenerationIDValue | | ipv4/dr-address | pimInterfaceDR | | ipv6/dr-address | | | dr-priority | pimInterfaceDRPriority | | hello-interval | pimInterfaceHelloInterval | | hello-holdtime | pimInterfaceHelloHoldtime | | jp-interval | pimInterfaceJoinPruneInterval | | jp-holdtime | pimInterfaceJoinPruneHoldtime | | bidir/offer-multiplier | pimInterfaceDFElectionRobustness | | propagation-delay | pimInterfacePropagationDelay | | override-interval | pimInterfaceOverrideInterval | +------------------------+----------------------------------+ Table 2: YANG Nodes and pimInterfaceTable Objects 5.2. pimNeighborTable pimNeighborTable is mapped to pim/interfaces/interface/neighbors/ ipv4-neighbor and pim/interfaces/interface/neighbors/ipv6-neighbor. The following table lists the YANG data nodes with corresponding objects of pimNeighborTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 30] Internet-Draft PIM YANG May 2018 +------------------------------+---------------------------------+ | YANG node | PIM-STD-MIB object | +------------------------------+---------------------------------+ | ipv4-neighbor | pimNeighborAddressType | | ipv6-neighbor | | | address | pimNeighborAddress | | gen-id | pimNeighborGenerationIDValue | | up-time | pimNeighborUpTime | | expiration | pimNeighborExpiryTime | | dr-priority | pimNeighborDRPriority | | lan-prune-delay/present | pimNeighborLanPruneDelayPresent | | lan-prune-delay/t-bit | pimNeighborTBit | | lan-prune-delay/ | pimNeighborPropagationDelay | | propagation-delay | | | lan-prune-delay/ | pimNeighborOverrideInterval | | override-interval | | | ietf-pim-bidir:bidir-capable | pimNeighborBidirCapable | +------------------------------+---------------------------------+ Table 3: YANG Nodes and pimNeighborTable Objects 5.3. pimStarGTable pimStarGTable is mapped to pim/address-family/topology-tree-info/ ipv4-route and pim/address-family/topology-tree-info/ipv6-route, when the value of source-address leaf is "ietf-routing-types:*" and the value of is-rpt leaf is "false". The following table lists the YANG data nodes with corresponding objects of pimStarGTable in the PIM-STD-MIB. +--------------------+------------------------------+ | YANG node | PIM-STD-MIB object | +--------------------+------------------------------+ | ipv4-route | pimStarGAddressType | | ipv6-route | | | group | pimStarGGrpAddress | | up-time | pimStarGUpTime | | mode | pimStarGPimMode | | rp-address | pimStarGRPAddressType | | rp-address | pimStarGRPAddress | | rpf-neighbor | pimStarGUpstreamNeighborType | | rpf-neighbor | pimStarGUpstreamNeighbor | | incoming-interface | pimStarGRPFIfIndex | +--------------------+------------------------------+ Table 4: YANG Nodes and pimStarGTable Objects Liu, et al. Expires November 20, 2018 [Page 31] Internet-Draft PIM YANG May 2018 In addtion, the object pimStarGPimModeOrigin in pimStarGTable is mapped to the node rp/rp-list/ipv4-rp/info-source-type or the node rp/rp-list/ipv6-rp/info-source-type in the YANG module ietf-pim-rp. 5.4. pimSGTable pimSGTable is mapped to pim/address-family/topology-tree-info/ ipv4-route and pim/address-family/topology-tree-info/ipv6-route, when the value of source-address leaf is not "ietf-routing-types:*" and the value of is-rpt leaf is "false". The following table lists the YANG data nodes with corresponding objects of pimSGTable in the PIM-STD-MIB. +--------------------+--------------------------+ | YANG node | PIM-STD-MIB object | +--------------------+--------------------------+ | ipv4-route | pimSGAddressType | | ipv6-route | | | group | pimSGGrpAddress | | source-address | pimSGSrcAddress | | up-time | pimSGUpTime | | mode | pimSGPimMode | | rpf-neighbor | pimStarGUpstreamNeighbor | | incoming-interface | pimStarGRPFIfIndex | | is-spt | pimSGSPTBit | | expiration | pimSGKeepaliveTimer | +--------------------+--------------------------+ Table 5: YANG Nodes and pimSGTable Objects 5.5. pimSGRptTable pimSGRptTable is mapped to pim/address-family/topology-tree-info/ ipv4-route and pim/address-family/topology-tree-info/ipv6-route, when the value of is-rpt leaf is "true". The following table lists the YANG data nodes with corresponding objects of pimSGRptTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 32] Internet-Draft PIM YANG May 2018 +----------------+---------------------+ | YANG node | PIM-STD-MIB object | +----------------+---------------------+ | ipv4-route | pimStarGAddressType | | ipv6-route | | | group | pimStarGGrpAddress | | source-address | pimSGRptSrcAddress | | up-time | pimSGRptUpTime | +----------------+---------------------+ Table 6: YANG Nodes and pimSGRptTable Objects 5.6. pimBidirDFElectionTable pimBidirDFElectionTable is mapped to pim/address-family/rp/bidir/ interface-df-election/ipv4-rp and pim/address-family/rp/bidir/ interface-df-election/ipv6-rp. The key of pimBidirDFElectionTable includes pimBidirDFElectionIfIndex whose type is InterfaceIndex, while the YANG lists use a node "name" with the type string instead. The following table lists the YANG data nodes with corresponding objects of pimBidirDFElectionTable in the PIM-STD-MIB. +--------------------------+-------------------------------------+ | YANG node | PIM-STD-MIB object | +--------------------------+-------------------------------------+ | ipv4-rp | pimBidirDFElectionAddressType | | ipv6-rp | | | rp-address | pimBidirDFElectionRPAddress | | df-address | pimBidirDFElectionWinnerAddressType | | | pimBidirDFElectionWinnerAddress | | up-time | pimBidirDFElectionWinnerUpTime | | winner-metric-preference | pimBidirDFElectionWinnerMetricPref | | winner-metric-preference | pimBidirDFElectionWinnerMetric | | interface-state | pimBidirDFElectionState | +--------------------------+-------------------------------------+ Table 7: YANG Nodes and pimBidirDFElectionTable Objects 5.7. pimStaticRPTable pimStaticRPTable is mapped to pim/address-family/rp/static-rp/ipv4-rp and pim/address-family/rp/static-rp/ipv6-rp. The following table lists the YANG data nodes with corresponding objects of pimStaticRPTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 33] Internet-Draft PIM YANG May 2018 +----------------+----------------------------+ | YANG node | PIM-STD-MIB object | +----------------+----------------------------+ | ipv4-rp | pimStaticRPAddressType | | ipv6-rp | | | rp-address | pimStaticRPRPAddress | | bidir | pimStaticRPPimMode | | sm | | | bidir/override | pimStaticRPOverrideDynamic | | sm/override | | +----------------+----------------------------+ Table 8: YANG Nodes and pimStaticRPTable Objects 5.8. pimAnycastRPSetTable pimAnycastRPSetTable is mapped to pim/address-family/sm/asm/anycast- rp/ipv4-anycast-rp and pim/address-family/sm/asm/anycast-rp/ipv6- anycast-rp. The following table lists the YANG data nodes with corresponding objects of pimAnycastRPSetTable in the PIM-STD-MIB. +-----------------+-------------------------------+ | YANG node | PIM-STD-MIB object | +-----------------+-------------------------------+ | ipv4-anycast-rp | pimAnycastRPSetAddressType | | ipv6-anycast-rp | | | anycast-address | pimAnycastRPSetAnycastAddress | | rp-address | pimAnycastRPSetRouterAddress | +-----------------+-------------------------------+ Table 9: YANG Nodes and pimAnycastRPSetTable Objects 5.9. pimGroupMappingTable pimGroupMappingTable is mapped to pim/address-family/rp/rp-mappings/ ipv4-rp and pim/address-family/rp/rp-mappings/ipv6-rp. The following table lists the YANG data nodes with corresponding objects of pimGroupMappingTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 34] Internet-Draft PIM YANG May 2018 +------------+--------------------------------+ | YANG node | PIM-STD-MIB object | +------------+--------------------------------+ | ipv4-rp | pimGroupMappingAddressType | | ipv6-rp | | | group | pimGroupMappingGrpAddress | | | pimGroupMappingGrpPrefixLength | | ipv4-rp | pimGroupMappingRPAddressType | | ipv6-rp | | | rp-address | pimGroupMappingRPAddress | | | pimGroupMappingPimMode | +------------+--------------------------------+ Table 10: YANG Nodes and pimGroupMappingTable Objects In addtion, the object pimGroupMappingPimMode in pimGroupMappingTable is mapped to the node rp/rp-list/ipv4-rp/mode or the node rp/rp-list/ipv6-rp/mode in the YANG module ietf-pim-rp. 6. PIM YANG Modules 6.1. PIM base module This module references [RFC3973], [RFC5015], [RFC5306], [RFC5880], and [RFC7761]. file "ietf-pim-base@2018-04-16.yang" module ietf-pim-base { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-base"; prefix pim-base; import ietf-inet-types { prefix "inet"; } import ietf-yang-types { prefix "yang"; } import ietf-routing-types { prefix "rt-types"; } import ietf-interfaces { prefix "if"; } Liu, et al. Expires November 20, 2018 [Page 35] Internet-Draft PIM YANG May 2018 import ietf-routing { prefix "rt"; } import ietf-bfd-types { prefix "bfd-types"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The module defines a collection of YANG definitions common for all PIM (Protocol Independent Multicast) modes. Copyright (c) 2018 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 Liu, et al. Expires November 20, 2018 [Page 36] Internet-Draft PIM YANG May 2018 RFC itself for full legal notices."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ feature bfd { description "Support BFD (Bidirectional Forwarding Detection)."; reference "RFC5880: Bidirectional Forwarding Detection (BFD)"; } feature global-graceful-restart { description "Global configuration for graceful restart support as per RFC5306."; } feature intf-dr-priority { description "Support configuration of interface DR (Designated Router) priority."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.3.2."; } feature intf-hello-holdtime { description "Support configuration of interface hello holdtime."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.3.3. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-hello-interval { description "Support configuration of interface hello interval."; reference Liu, et al. Expires November 20, 2018 [Page 37] Internet-Draft PIM YANG May 2018 "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-hello-multiplier { description "Support configuration of interface hello multiplier."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-jp-interval { description "Support configuration of interface join prune interval."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-jp-holdtime { description "Support configuration of interface join prune holdtime."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-jp-multiplier { description "Support configuration of interface join prune multiplier."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-propagation-delay { description Liu, et al. Expires November 20, 2018 [Page 38] Internet-Draft PIM YANG May 2018 "Support configuration of interface propagation delay."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.3.5. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.3.3."; } feature intf-override-interval { description "Support configuration of interface override interval."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.3.3. RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM). Sec. 3.6. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature per-af-graceful-restart { description "Per address family configuration for graceful restart support as per RFC5306."; } /* * Typedefs */ typedef interface-event-type { type enumeration { enum up { description "Neighbor status changed to up."; } enum down { description "Neighbor status changed to down."; } enum new-dr { description "A new DR (Designated Router) was elected on the connected network."; } enum new-df { description "A new DF (Designated Forwarder) was elected on the connected network."; Liu, et al. Expires November 20, 2018 [Page 39] Internet-Draft PIM YANG May 2018 } } description "Operational status event type for notifications."; } typedef neighbor-event-type { type enumeration { enum up { description "Neighbor status changed to up."; } enum down { description "Neighbor status changed to down."; } } description "Operational status event type for notifications."; } /* * Identities */ identity pim-mode { description "The PIM mode in which a group is operating."; } identity pim-none { base pim-mode; description "PIM is not operating."; } identity pim-bidir { base pim-mode; description "PIM operates in the Bidirectional Mode."; } identity pim-dm { base pim-mode; description "PIM operates in the Dense Mode (DM)."; } identity pim-sm { base pim-mode; description "PIM operates in the Sparse Mode (SM)."; } identity pim-asm { base pim-sm; Liu, et al. Expires November 20, 2018 [Page 40] Internet-Draft PIM YANG May 2018 description "PIM operates in the Sparse Mode with Any Source Multicast (ASM)."; } identity pim-ssm { base pim-sm; description "PIM operates in the Sparse Mode with Source-Specific Multicast (SSM)."; } /* * Groupings */ grouping graceful-restart-container { description "A grouping defining a container of graceful restart attributes."; container graceful-restart { leaf enabled { type boolean; default false; description "Enable or disable graceful restart."; } leaf duration { type uint16; units seconds; default 60; description "Maximum time for graceful restart to finish."; } description "Container of graceful restart attributes."; } } // graceful-restart-container grouping multicast-route-attributes { description "A grouping defining multicast route attributes."; leaf expiration { type rt-types:timer-value-seconds16; description "When the route will expire."; } leaf incoming-interface { type if:interface-ref; description Liu, et al. Expires November 20, 2018 [Page 41] Internet-Draft PIM YANG May 2018 "Reference to an entry in the global interface list."; } leaf is-spt { type boolean; description "'true' if SPT (Shortest Path Tree) bit is set to indicate forwarding is taking place on the (S,G) Shortest Path Tree (SPT)."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.1.3."; } leaf mode { type identityref { base pim-mode; } description "PIM mode."; } leaf msdp-learned { type boolean; description "'true' if route is learned from MSDP (Multicast Source Discovery Protocol)."; } leaf rp-address { type inet:ip-address; description "RP (Rendezvous Point) address."; } leaf rpf-neighbor { type inet:ip-address; description "RPF (Reverse Path Forwarding) neighbor address."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the route last transitioned into the active state."; } list outgoing-interface { key "name"; description "A list of outgoing interfaces."; leaf name { type if:interface-ref; description "Interface name."; Liu, et al. Expires November 20, 2018 [Page 42] Internet-Draft PIM YANG May 2018 } leaf expiration { type rt-types:timer-value-seconds16; description "Expiring time."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the oper-status of the interface was last changed to 'up'."; } leaf jp-state { type enumeration { enum "no-info" { description "The interface has no (*,G) Join state and no timers running."; } enum "join" { description "The interface has Join state."; } enum "prune-pending" { description "The router has received a Prune on this interface from a downstream neighbor and is waiting to see whether the prune will be overridden by another downstream router. For forwarding purposes, the Prune-Pending state functions exactly like the Join state."; } } description "Join-prune state."; } } } // multicast-route-attributes grouping neighbor-state-af-attributes { description "A grouping defining neighbor per address family attributes."; leaf bfd-state { type bfd-types:state; description "BFD (Bidirectional Forwarding Detection) status."; } leaf expiration { Liu, et al. Expires November 20, 2018 [Page 43] Internet-Draft PIM YANG May 2018 type rt-types:timer-value-seconds16; description "Neighbor expiring time."; } leaf dr-priority { type uint32; description "DR (Designated Router) priority as the preference in the DR election process."; } leaf gen-id { type uint32; description "The value of the Generation ID in the last Hello message from the neighbor."; } container lan-prune-delay { description "The information of the LAN Prune Delay option in the Hello message from the neighbor."; leaf present { type boolean; description "'true' if the LAN Prune Delay option is present in the last Hello message from the neighbor."; } leaf override-interval { when "../present = 'true'" { description "Available only when the leaf present is 'true'."; } type uint16; units milliseconds; description "The value of the Override_Interval field of the LAN Prune Delay option in the last Hello message from the neighbor. The neighbor uses this value to indicate a short period after a Join or Prune to allow other routers on the LAN to override the Join or Prune."; } leaf propagation-delay { when "../present = 'true'" { description "Available only when the leaf present is 'true'."; } type uint16; units milliseconds; description "The value of the Propagation_Delay field of the LAN Prune Liu, et al. Expires November 20, 2018 [Page 44] Internet-Draft PIM YANG May 2018 Delay option in the last Hello message from the neighbor. The value is the propagation delay over the local link expected by the neighbor."; } leaf t-bit { when "../present = 'true'" { description "Available only when the leaf present is 'true'."; } type boolean; description "'true' if the T bit is set in the LAN Prune Delay option in the last Hello message from the neighbor. This flag indicates the neighbor's capability to disable Join message suppression."; } } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the neighbor relationship has been formed as reachable without beeing timed out."; } } // neighbor-state-af-attributes grouping pim-instance-af-state-ref { description "An absolute reference to a PIM instance address family."; leaf instance-af-ref { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/" + "pim-base:address-family"; } description "Reference to a PIM instance address family."; } } // pim-instance-af-state-ref grouping pim-interface-state-ref { description "An absolute reference to a PIM interface state."; leaf interface-ref { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:name"; Liu, et al. Expires November 20, 2018 [Page 45] Internet-Draft PIM YANG May 2018 } description "Reference to a PIM interface."; } } // pim-interface-state-ref grouping statistics-sent-received { description "A grouping defining sent and received statistics on PIM messages."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.7.1. RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM). Sec. 3.7. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.9."; leaf assert { type yang:counter64; description "The number of Assert messages, with the message Type of 5 in RFC3973 and RFC7761."; } leaf bsr { type yang:counter64; description "The number of Bootstrap messages, with the message Type of 4 in RFC3973 and RFC7761."; } leaf candidate-rp-advertisement { type yang:counter64; description "The number of Candidate RP Advertisement messages, with the message Type of 8 in RFC3973 and RFC7761."; } leaf df-election { type yang:counter64; description "The number of DF (Designated Forwarder) Election messages, with the message Type of 10 in RFC5015."; } leaf graft { type yang:counter64; description "The number of Graft messages, with the message Type of 6 in RFC3973 and RFC7761."; } leaf graft-ack { Liu, et al. Expires November 20, 2018 [Page 46] Internet-Draft PIM YANG May 2018 type yang:counter64; description "The number of Graft-Ack messages, with the message Type of 7 in RFC3973 and RFC7761."; } leaf hello { type yang:counter64; description "The number of Hello messages, with the message Type of 0 in RFC3973 and RFC7761."; } leaf join-prune { type yang:counter64; description "The number of Join/Prune messages, with the message Type of 3 in RFC3973 and RFC7761."; } leaf register { type yang:counter64; description "The number of Register messages, with the message Type of 1 in RFC3973 and RFC7761."; } leaf register-stop { type yang:counter64; description "The number of Register Stop messages, with the message Type of 2 in RFC3973 and RFC7761."; } leaf state-refresh { type yang:counter64; description "The number of State Refresh messages, with the message Type of 9 in RFC3973."; } } // statistics-sent-received /* * Data nodes */ augment "/rt:routing/rt:control-plane-protocols" { description "PIM augmentation to the routing instance model."; container pim { presence "Enables the PIM protocol."; Liu, et al. Expires November 20, 2018 [Page 47] Internet-Draft PIM YANG May 2018 description "PIM configuration and operational data."; uses graceful-restart-container { if-feature global-graceful-restart; } list address-family { key "address-family"; description "Each list entry for one address family."; uses rt:address-family; uses graceful-restart-container { if-feature per-af-graceful-restart; } container statistics { config false; description "A container defining statistics attributes."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of the statistic counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container error { description "Containing error statistics."; uses statistics-sent-received { description "Statistic counters on the PIM messages per PIM message Type. Each leaf attribute counts the number of PIM messages that were of a particular Type (such as Hello) and contained errors preventing them from being processed by PIM. Such messages are also counted by the corresponding counter of the same Type (such as Hello) in the 'received' container."; } leaf checksum { type yang:counter64; description "The number of PIM messages that were passed to PIM Liu, et al. Expires November 20, 2018 [Page 48] Internet-Draft PIM YANG May 2018 and contained checksum errors."; } leaf format { type yang:counter64; description "The number of PIM messages that passed checksum validation but contained format errors, including the errors such as PIM Version, Type, and message length."; } } container queue { description "Containing queue statistics."; leaf size { type uint32; description "The size of the input queue."; } leaf overflow { type yang:counter32; description "The number of the input queue overflows."; } } container received { description "Containing statistics of received messages."; uses statistics-sent-received; } container sent { description "Containing statistics of sent messages."; uses statistics-sent-received; } } container topology-tree-info { config false; description "Containing topology tree information."; list ipv4-route { when "../../address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "group source-address is-rpt"; description "A list of IPv4 routes."; leaf group { type rt-types:ipv4-multicast-group-address; Liu, et al. Expires November 20, 2018 [Page 49] Internet-Draft PIM YANG May 2018 description "Group address."; } leaf source-address { type rt-types:ipv4-multicast-source-address; description "Source address."; } leaf is-rpt { type boolean; description "'true' if the tree is RPT (Rendezvous-Point Tree)."; } uses multicast-route-attributes; } // ipv4-route list ipv6-route { when "../../address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "group source-address is-rpt"; description "A list of IPv6 routes."; leaf group { type rt-types:ipv6-multicast-group-address; description "Group address."; } leaf source-address { type rt-types:ipv6-multicast-source-address; description "Source address."; } leaf is-rpt { type boolean; description "'true' if the tree is RPT (Rendezvous-Point Tree)."; } uses multicast-route-attributes; } // ipv6-route } // topology-tree-info } // address-family container interfaces { description "Containing a list of interfaces."; list interface { key "name"; description "List of pim interfaces."; Liu, et al. Expires November 20, 2018 [Page 50] Internet-Draft PIM YANG May 2018 leaf name { type if:interface-ref; description "Reference to an entry in the global interface list."; } list address-family { key "address-family"; description "Each list entry for one address family."; uses rt:address-family; container bfd { if-feature bfd; description "BFD (Bidirectional Forwarding Detection) operation."; uses bfd-types:client-cfg-parms; } leaf dr-priority { if-feature intf-dr-priority; type uint32; default 1; description "DR (Designated Router) priority as the preference in the DR election process."; } leaf hello-interval { if-feature intf-hello-interval; type rt-types:timer-value-seconds16; default 30; description "Periodic interval for Hello messages. If 'infinity' or 'not-set' is used, no periodic Hello messages are sent."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } choice hello-holdtime-or-multiplier { description "Holdtime is timer value to time out the neighbor state when the timer expires. The holdtime value can be specified either by the Liu, et al. Expires November 20, 2018 [Page 51] Internet-Draft PIM YANG May 2018 given holdtime value or by the calculation of the hello-interval multiplied by the given value of the multiplier."; case holdtime { if-feature intf-hello-holdtime; leaf hello-holdtime { type rt-types:timer-value-seconds16; default 105; description "Hello holdtime is the amount of time to keep the neighbor reachable until a new Hello message is received."; } } case multiplier { if-feature intf-hello-multiplier; leaf hello-multiplier { type rt-types:timer-multiplier; default 3; description "Hello multiplier is the number by which the hello interval is multplied to obtain the Hello holdtime. The value of the Hello holdtime is calculated as: hello-holdtime = (multiplier + 0.5) * (hello-interval)"; } } } leaf jp-interval { if-feature intf-jp-interval; type rt-types:timer-value-seconds16; default 60; description "Periodic interval between Join/Prune messages. If 'infinity' or 'not-set' is used, no periodic Join/Prune messages are sent."; } choice jp-holdtime-or-multiplier { description "Join/Prune holdtime is the amount of time a receiver must keep the Join/Prune state alive. The holdtime value can be specified either by the given holdtime value or by the calculation of the jp-interval multiplied by the given value of the multiplier."; case holdtime { Liu, et al. Expires November 20, 2018 [Page 52] Internet-Draft PIM YANG May 2018 if-feature intf-jp-holdtime; leaf jp-holdtime { type rt-types:timer-value-seconds16; default 210; description "Join/Prune holdtime is the amount of time a receiver must keep the Join/Prune state alive."; } } case multiplier { if-feature intf-jp-multiplier; leaf jp-multiplier { type rt-types:timer-multiplier; default 3; description "Join prune multiplier is the number by which the join prune interval is multplied to obtain the Join/Prune holdtime. The value of the Join/Prune holdtime is calculated as: jp-holdtime = (multiplier + 0.5) * (jp-interval)"; } } } leaf override-interval { if-feature intf-override-interval; type uint16; units milliseconds; default 2500; description "A short period after a Join or Prune to allow other routers on the LAN to override the Join or Prune."; } leaf propagation-delay { if-feature intf-propagation-delay; type uint16; units milliseconds; default 500; description "Expected propagation delay over the local link."; } // Interface state attributes leaf oper-status { type enumeration { enum up { description Liu, et al. Expires November 20, 2018 [Page 53] Internet-Draft PIM YANG May 2018 "The interface is ready to pass PIM messages."; } enum down { description "The interface does not pass PIM messages."; } } config false; description "PIM operational status on the interface. This status is PIM specific and separate from the operational status of the underlying interface."; } leaf gen-id { type uint32; config false; description "The value of the Generation ID this router uses to insert in the PIM Hello message sent on this interface."; } leaf hello-expiration { type rt-types:timer-value-seconds16; config false; description "Hello interval expiration time."; } container ipv4 { when "../address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } config false; description "Interface state attributes for IPv4."; leaf-list address { type inet:ipv4-address; description "List of addresses on which PIM is operating."; } leaf dr-address { type inet:ipv4-address; description "DR (Designated Router) address."; } } container ipv6 { when "../address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } Liu, et al. Expires November 20, 2018 [Page 54] Internet-Draft PIM YANG May 2018 config false; description "Interface state attributes for IPv6."; leaf-list address { type inet:ipv6-address; description "List of addresses on which PIM is operating."; } leaf dr-address { type inet:ipv6-address; description "DR (Designated Router) address."; } } container neighbors { config false; description "Information learned from neighbors through this interface."; list ipv4-neighbor { when "../../address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "address"; description "Neighbor state information."; leaf address { type inet:ipv4-address; description "Neighbor address."; } uses neighbor-state-af-attributes; } // list ipv4-neighbor list ipv6-neighbor { when "../../address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "address"; description "Neighbor state information."; leaf address { type inet:ipv6-address; description "Neighbor address."; } uses neighbor-state-af-attributes; } // list ipv6-neighbor } // neighbors } // address-family } // interface } // interfaces } // pim Liu, et al. Expires November 20, 2018 [Page 55] Internet-Draft PIM YANG May 2018 } // augment /* * Notifications */ notification pim-neighbor-event { description "Notification event for neighbor."; leaf event-type { type neighbor-event-type; description "Event type."; } uses pim-interface-state-ref; leaf interface-af-ref { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface" + "[pim-base:name = current()/../interface-ref]/" + "pim-base:address-family/pim-base:address-family"; } description "Reference to a PIM interface address family."; } leaf neighbor-ipv4-ref { when "../interface-af-ref = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface" + "[pim-base:name = current()/../interface-ref]/" + "pim-base:address-family" + "[pim-base:address-family = " + "current()/../interface-af-ref]/" + "pim-base:neighbors/pim-base:ipv4-neighbor/" + "pim-base:address"; } description "Reference to a PIM IPv4 neighbor."; } leaf neighbor-ipv6-ref { when "../interface-af-ref = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface" + "[pim-base:name = current()/../interface-ref]/" + "pim-base:address-family" Liu, et al. Expires November 20, 2018 [Page 56] Internet-Draft PIM YANG May 2018 + "[pim-base:address-family = " + "current()/../interface-af-ref]/" + "pim-base:neighbors/pim-base:ipv6-neighbor/" + "pim-base:address"; } description "Reference to a PIM IPv6 neighbor."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the neighbor relationship has been formed as reachable without beeing timed out."; } } notification pim-interface-event { description "Notification event for interface."; leaf event-type { type interface-event-type; description "Event type."; } uses pim-interface-state-ref; container ipv4 { description "Containing IPv4 information."; leaf-list address { type inet:ipv4-address; description "List of addresses."; } leaf dr-address { type inet:ipv4-address; description "DR (Designated Router) address."; } } container ipv6 { description "Containing IPv6 information."; leaf-list address { type inet:ipv6-address; description "List of addresses."; } leaf dr-address { type inet:ipv6-address; description "DR (Designated Router) address."; } } } } Liu, et al. Expires November 20, 2018 [Page 57] Internet-Draft PIM YANG May 2018 6.2. PIM RP Module This module references [RFC5059] and [RFC7761]. file "ietf-pim-rp@2018-04-16.yang" module ietf-pim-rp { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-rp"; prefix pim-rp; import ietf-inet-types { prefix "inet"; } import ietf-routing-types { prefix "rt-types"; } import ietf-interfaces { prefix "if"; } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Editor: Mahesh Sivakumar Liu, et al. Expires November 20, 2018 [Page 58] Internet-Draft PIM YANG May 2018 Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) RP (Rendezvous Point) model. Copyright (c) 2018 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."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ feature bsr { description "This feature indicates that the system supports BSR (Bootstrap Router)."; reference "RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)."; } feature bsr-election-state { if-feature bsr; description "This feature indicates that the system supports providing Liu, et al. Expires November 20, 2018 [Page 59] Internet-Draft PIM YANG May 2018 BSR election state."; reference "RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)."; } feature static-rp-override { description "This feature indicates that the system supports configuration of static RP (Rendezvous Point) override."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 3.7."; } feature candidate-interface { description "This feature indicates that the system supports using an interface to configure a BSR or RP candidate."; } feature candidate-ipv4 { description "This feature indicates that the system supports using an IPv4 address to configure a BSR or RP candidate."; } feature candidate-ipv6 { description "This feature indicates that the system supports using an IPv6 address to configure a BSR or RP candidate."; } /* * Typedefs */ typedef rp-event-type { type enumeration { enum invalid-jp { description "An invalid JP (Join/Prune) message has been received."; } enum invalid-register { description "An invalid register message has been received."; } enum mapping-created { Liu, et al. Expires November 20, 2018 [Page 60] Internet-Draft PIM YANG May 2018 description "A new mapping has been created."; } enum mapping-deleted { description "A mapping has been deleted."; } } description "Operational status event type for notifications."; } /* * Identities */ identity rp-mode { description "The mode of an RP, which can be SM (Sparse Mode) or BIDIR (bi-directional)."; } identity rp-info-source-type { description "The information source of an RP."; } identity static { base rp-info-source-type; description "The RP is statically configured."; } identity bootstrap { base rp-info-source-type; description "The RP is learned from bootstrap."; } /* * Groupings */ grouping rp-mapping-state-attributes { description "Grouping of RP mapping attributes."; leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the RP mapping or the RP became actively available."; } leaf expiration { Liu, et al. Expires November 20, 2018 [Page 61] Internet-Draft PIM YANG May 2018 type rt-types:timer-value-seconds16; description "Expiration time."; } } // rp-mapping-state-attributes grouping rp-state-attributes { description "Grouping of RP state attributes."; leaf info-source-type { type identityref { base rp-info-source-type; } description "The information source of an RP."; } // info-source-type leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the RP became actively available."; } leaf expiration { type rt-types:timer-value-seconds16; description "Expiration time."; } } // rp-state-attributes grouping static-rp-attributes { description "Grouping of static RP attributes, used in augmenting modules."; leaf policy-name { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to determine which multicast group addresses are mapped to this statically configured RP address. If a policy is not specified, the entire multicast address space is mapped. The definition of such a policy is outside the scope of this document."; } leaf override { if-feature static-rp-override; type boolean; default false; description "When there is a conflict between static RP and dynamic Liu, et al. Expires November 20, 2018 [Page 62] Internet-Draft PIM YANG May 2018 RP, setting this attribute to 'true' will ask the system to use static RP."; } } // static-rp-attributes grouping rp-candidate-attributes { description "Grouping of RP candidate attributes."; leaf policy-name { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. If a policy is not specified, the entire multicast address space is accepted. The definition of such a policy is outside the scope of this document."; } leaf mode { type identityref { base rp-mode; } description "The mode of an RP, which can be SM (Sparse Mode) or BIDIR (bi-directional), each of them is defined in a saparate YNAG module. If a system supports an RP mode, the corresponding YANG module is implemented. When the value of this leaf is not specified, the default value is the supported mode if only one mode is implemented, or the default value is SM (Sparce Mode) if both SM and BIDIR are implemented."; } } // rp-candidate-attributes /* * Configuration data nodes */ augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM RP augmentation."; container rp { description "PIM RP configuration data."; container static-rp { Liu, et al. Expires November 20, 2018 [Page 63] Internet-Draft PIM YANG May 2018 description "Containing static RP attributes."; list ipv4-rp { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "Specifies a static RP address."; } } list ipv6-rp { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; description "Specifies a static RP address."; } } } // static-rp container bsr { if-feature bsr; description "Containing BSR (BootStrap Router) attributes."; container bsr-candidate { presence "Present to serve as a BSR candidate"; description "BSR candidate attributes."; choice interface-or-address { description "Use either interface or ip-address."; case interface { if-feature candidate-interface; Liu, et al. Expires November 20, 2018 [Page 64] Internet-Draft PIM YANG May 2018 leaf interface { type if:interface-ref; mandatory true; description "Interface to be used by BSR."; } } case ipv4-address { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } if-feature candidate-ipv4; leaf ipv4-address { type inet:ipv4-address; mandatory true; description "IP address to be used by BSR."; } } case ipv6-address { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } if-feature candidate-ipv6; leaf ipv6-address { type inet:ipv6-address; mandatory true; description "IP address to be used by BSR."; } } } leaf hash-mask-length{ type uint8 { range "0..128"; } mandatory true; description "Value contained in BSR messages used by all routers to hash (map) to an RP."; } leaf priority { type uint8 { range "0..255"; Liu, et al. Expires November 20, 2018 [Page 65] Internet-Draft PIM YANG May 2018 } default 64; description "BSR election priority among different candidate BSRs. A larger value has a higher priority over a smaller value."; } } // bsr-candidate container rp-candidate { description "Containing RP candidate attributes."; list interface { if-feature candidate-interface; key "name"; description "A list of RP candidates"; leaf name { type if:interface-ref; description "Interface that the RP candidate uses."; } uses rp-candidate-attributes; } list ipv4-address { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } if-feature candidate-ipv4; key "address"; description "A list of RP candidate addresses."; leaf address { type inet:ipv4-address; description "IPv4 address that the RP candidate uses."; } uses rp-candidate-attributes; } list ipv6-address { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } if-feature candidate-ipv6; Liu, et al. Expires November 20, 2018 [Page 66] Internet-Draft PIM YANG May 2018 key "address"; description "A list of RP candidate addresses."; leaf address { type inet:ipv6-address; description "IPv6 address that the RP candidate uses."; } uses rp-candidate-attributes; } } // BSR state attributes. container bsr { config false; description "BSR information."; leaf address { type inet:ip-address; description "BSR address"; } leaf hash-mask-length { type uint8 { range "0..128"; } description "Hash mask length."; } leaf priority { type uint8 { range "0..255"; } description "Priority."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the BSR became up."; } } choice election-state { if-feature bsr-election-state; config false; description "BSR election state."; case candidate { leaf candidate-bsr-state { type enumeration { enum "candidate" { Liu, et al. Expires November 20, 2018 [Page 67] Internet-Draft PIM YANG May 2018 description "The router is a candidate to be the BSR for the scope zone, but currently another router is the preferred BSR."; } enum "pending" { description "The router is a candidate to be the BSR for the scope zone. Currently, no other router is the preferred BSR, but this router is not yet the elected BSR. This is a temporary state that prevents rapid thrashing of the choice of BSR during BSR election."; } enum "elected" { description "The router is the elected BSR for the scope zone and it must perform all the BSR functions."; } } description "Candidate-BSR state."; reference "RFC5059, Section 3.1.1."; } } case "non-candidate" { leaf non-candidate-bsr-state { type enumeration { enum "no-info" { description "The router has no information about this scope zone."; } enum "accept-any" { description "The router does not know of an active BSR, and will accept the first Bootstrap message it sees as giving the new BSR's identity and the RP-Set."; } enum "accept" { description "The router knows the identity of the current BSR, and is using the RP-Set provided by that BSR. Only Bootstrap messages from that BSR or from a Candidate-BSR (C-BSR) with higher weight than the current BSR will be accepted."; Liu, et al. Expires November 20, 2018 [Page 68] Internet-Draft PIM YANG May 2018 } } description "Non-candidate-BSR state."; reference "RFC5059, Section 3.1.2."; } } } // election-state leaf bsr-next-bootstrap { type uint16; units seconds; config false; description "The remaining time interval in seconds until the next bootstrap will be sent."; } container rp { config false; description "State information of the RP."; leaf rp-address { type inet:ip-address; description "RP address."; } leaf policy-name { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. If a policy is not specified, the entire multicast address space is accepted. The definition of such a policy is outside the scope of this document."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the RP became actively available."; } } leaf rp-candidate-next-advertisement { type uint16; units seconds; config false; Liu, et al. Expires November 20, 2018 [Page 69] Internet-Draft PIM YANG May 2018 description "The remaining time interval in seconds until the next RP candidate advertisement will be sent."; } } // bsr container rp-list { config false; description "Containing a list of RPs."; list ipv4-rp { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address mode"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "RP address."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } leaf info-source-address { type inet:ipv4-address; description "The address where RP information is learned."; } uses rp-state-attributes; } list ipv6-rp { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address mode"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; Liu, et al. Expires November 20, 2018 [Page 70] Internet-Draft PIM YANG May 2018 description "RP address."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } leaf info-source-address { type inet:ipv6-address; description "The address where RP information is learned."; } uses rp-state-attributes; } } // rp-list container rp-mappings { config false; description "Containing a list of group-to-RP mappings."; list ipv4-rp { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "group-range rp-address"; description "A list of group-to-RP mappings."; leaf group-range { type inet:ipv4-prefix; description "Group range presented in the format of prefix."; } leaf rp-address { type inet:ipv4-address; description "RP address."; } uses rp-mapping-state-attributes; } list ipv6-rp { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; Liu, et al. Expires November 20, 2018 [Page 71] Internet-Draft PIM YANG May 2018 } key "group-range rp-address"; description "A list of IPv6 RP addresses."; leaf group-range { type inet:ipv6-prefix; description "Group range presented in the format of prefix."; } leaf rp-address { type inet:ipv6-address; description "RP address."; } uses rp-mapping-state-attributes; } } // rp-mappings } // rp } // augment /* * Notifications */ notification pim-rp-event { description "Notification event for RP."; leaf event-type { type rp-event-type; description "Event type."; } uses pim-base:pim-instance-af-state-ref; leaf group { type rt-types:ip-multicast-group-address; description "Group address."; } leaf rp-address { type inet:ip-address; description "RP address."; } leaf is-rpt { type boolean; description "'true' if the tree is RPT (RP-Tree)."; } leaf mode { type identityref { base pim-base:pim-mode; } description "PIM mode."; } Liu, et al. Expires November 20, 2018 [Page 72] Internet-Draft PIM YANG May 2018 leaf message-origin { type inet:ip-address; description "Where the message is originated."; } } } 6.3. PIM-SM Module This module references [RFC4607] and [RFC7761]. file "ietf-pim-sm@2018-04-16.yang" module ietf-pim-sm { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-sm"; prefix pim-sm; import ietf-inet-types { prefix "inet"; } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } import ietf-pim-rp { prefix "pim-rp"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Liu, et al. Expires November 20, 2018 [Page 73] Internet-Draft PIM YANG May 2018 Editor: Anish Peter Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) SM (Sparse Mode) model. Copyright (c) 2018 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."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.2."; } /* * Features */ feature spt-switch-infinity { description "This feature indicates that the system supports configuration choice whether to trigger the switchover from the RPT (Rendezvous Point Tree) to the SPT (Shortest Path Tree)."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode Liu, et al. Expires November 20, 2018 [Page 74] Internet-Draft PIM YANG May 2018 (PIM-SM): Protocol Specification (Revised). Sec. 4.2."; } feature spt-switch-policy { description "This feature indicates that the system supports configuring policy for the switchover from the RPT to the SPT."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.2."; } /* * Identities */ identity rp-sm { base pim-rp:rp-mode; description "SM (Sparse Mode)."; } /* * Groupings */ grouping static-rp-sm-container { description "Grouping that contains SM attributes for static RP."; container sm { presence "Indicate the support of sparse mode."; description "PIM SM configuration data."; uses pim-rp:static-rp-attributes; } // sm } // static-rp-sm-container /* * Configuration data nodes */ augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM SM augmentation."; container sm { description "PIM SM configuration data."; Liu, et al. Expires November 20, 2018 [Page 75] Internet-Draft PIM YANG May 2018 container asm { description "ASM (Any Source Multicast) attributes."; container anycast-rp { presence "Present to enable anycast RP (Rendezvous Point)."; description "Anycast RP attributes."; list ipv4-anycast-rp { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "anycast-address rp-address"; description "A list of IPv4 anycast RP settings, only applicable when pim-base:address-family is IPv4."; leaf anycast-address { type inet:ipv4-address; description "IP address of the anycast RP set. This IP address is used by the multicast groups or sources to join or register."; } leaf rp-address { type inet:ipv4-address; description "IP address of the router configured with anycast RP. This is the IP address where the Register messages are forwarded."; } } list ipv6-anycast-rp { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "anycast-address rp-address"; description "A list of IPv6 anycast RP settings, only applicable when pim-base:address-family is IPv6."; leaf anycast-address { type inet:ipv6-address; description "IP address of the anycast RP set. This IP address Liu, et al. Expires November 20, 2018 [Page 76] Internet-Draft PIM YANG May 2018 is used by the multicast groups or sources to join or register."; } leaf rp-address { type inet:ipv6-address; description "IP address of the router configured with anycast RP. This is the IP address where the Register messages are forwarded."; } } } container spt-switch { description "SPT (Shortest Path Tree) switching attributes."; container infinity { if-feature spt-switch-infinity; presence "Present if SPT switchover threshold is set to infinity, according to the policy specified below."; description "The receiver's DR (Designated Router) never triggers the switchover from the RPT to the SPT."; leaf policy-name { if-feature spt-switch-policy; type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. The groups accepted by this policy have the SPT switchover threshold set to infinity, meaning that they will stay on the shared tree forever. If a policy is not specified, the entire multicast address space is accepted. The definition of such a policy is outside the scope of this document."; } } // infinity } } // asm container ssm { presence "Present to enable SSM (Source-Specific Multicast)."; description Liu, et al. Expires November 20, 2018 [Page 77] Internet-Draft PIM YANG May 2018 "SSM (Source-Specific Multicast) attributes."; leaf range-policy { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. The groups accepted by this policy define the multicast group rang used by SSM. If a policy is not specified, the default SSM multicast group rang is used. The default SSM multicast group range is 232.0.0.0/8 for IPv4 and ff3x::/96 for IPv6 where x reprents any valid scope identifier. The definition of such a policy is outside the scope of this document."; reference "RFC4607: Source-Specific Multicast for IP."; } } // ssm } // sm } // augment augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { description "PIM SM augmentation."; container sm { presence "Present to enable sparse-mode."; description "PIM SM configuration data."; leaf passive { type empty; description "Specifies that no PIM messages are sent or accepted on this PIM interface, but the interface can be included in a multicast forwarding entry."; } } // sm } // augment augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv4-rp" { description "PIM SM augmentation."; Liu, et al. Expires November 20, 2018 [Page 78] Internet-Draft PIM YANG May 2018 uses static-rp-sm-container; } // augment augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv6-rp" { description "PIM SM augmentation."; uses static-rp-sm-container; } // augment } 6.4. PIM-DM Module This module references [RFC3973]. file "ietf-pim-dm@2018-04-16.yang" module ietf-pim-dm { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-dm"; prefix pim-dm; import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Liu, et al. Expires November 20, 2018 [Page 79] Internet-Draft PIM YANG May 2018 Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) DM (Dense Mode) model. Copyright (c) 2018 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."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM. RFC 3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)."; } /* * Configuration data nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family" { description "PIM DM (Dense Mode) augmentation."; container dm { presence "Present to enable dense-mode."; description "PIM DM configuration data."; } // Dm Liu, et al. Expires November 20, 2018 [Page 80] Internet-Draft PIM YANG May 2018 } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { description "PIM DM augmentation to PIM base interface."; container dm { presence "Present to enable dense-mode."; description "PIM DM configuration data."; } // sm } // augment } 6.5. PIM-BIDIR Module This module references [RFC5015]. file "ietf-pim-bidir@2018-04-16.yang" module ietf-pim-bidir { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-bidir"; prefix pim-bidir; import ietf-inet-types { prefix "inet"; } import ietf-routing-types { prefix "rt-types"; } import ietf-interfaces { prefix "if"; } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } Liu, et al. Expires November 20, 2018 [Page 81] Internet-Draft PIM YANG May 2018 import ietf-pim-rp { prefix "pim-rp"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) BIDIR (Bidirectional) mode model. Copyright (c) 2018 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."; revision 2018-04-16 { description Liu, et al. Expires November 20, 2018 [Page 82] Internet-Draft PIM YANG May 2018 "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM. RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM)."; } /* * Features */ feature intf-df-election { description "Support configuration of interface DF election."; reference "RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM). Sec. 3.5."; } /* * Identities */ identity rp-bidir { base pim-rp:rp-mode; description "BIDIR (Bidirectional) mode."; } identity df-state { description "DF (Designated Forwarder) election state type."; reference "RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM)."; } identity df-state-offer { base df-state; description "Initial election state. When in the Offer state, a router thinks it can eventually become the winner and periodically generates Offer messages."; } identity df-state-lose { base df-state; description "There either is a different election winner or that no Liu, et al. Expires November 20, 2018 [Page 83] Internet-Draft PIM YANG May 2018 router on the link has a path to the RPA (Rendezvous-Point Address)."; } identity df-state-win { base df-state; description "The router is the acting DF without any contest."; } identity df-state-backoff { base df-state; description "The router is the acting DF but another router has made a bid to take over."; } /* * Groupings */ grouping static-rp-bidir-container { description "Grouping that contains BIDIR (Bidirectional) attributes for static RP (Rendezvous-Point)."; container bidir { presence "Indicate the support of BIDIR mode."; description "PIM BIDIR configuration data."; uses pim-rp:static-rp-attributes; } // bidir } // static-rp-bidir-container grouping interface-df-election-state-attributes { description "Grouping that contains the state attributes of a DF election on an interface."; leaf interface-state { type identityref { base df-state; } description "Interface state with respect to the DF election."; } leaf up-time { type rt-types:timeticks64; description Liu, et al. Expires November 20, 2018 [Page 84] Internet-Draft PIM YANG May 2018 "The number of time ticks (hundredths of a second) since the current DF has been elected as the winner."; } leaf winner-metric { type uint32; description "The unicast routing metric used by the DF to reach the RP. The value is announced by the DF."; } leaf winner-metric-preference { type uint32; description "The preference value assigned to the unicast routing protocol that the DF used to obtain the route to the RP. The value is announced by the DF."; } } // interface-df-election-state-attributes /* * Configuration data and operational state date nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family" { description "PIM BIDIR (Bidirectional) augmentation."; container bidir { presence "Present to enable BIDIR mode."; description "PIM BIDIR configuration data."; } // bidir } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { description "PIM BIDIR augmentation."; container bidir { presence "Present to enable BIDIR mode."; description "PIM BIDIR configuration data."; container df-election { if-feature intf-df-election; description "DF election attributes."; leaf offer-interval { type uint16; Liu, et al. Expires November 20, 2018 [Page 85] Internet-Draft PIM YANG May 2018 units milliseconds; default 100; description "Offer interval specifies the interval between repeated DF election messages."; } leaf backoff-interval { type uint16; units milliseconds; default 1000; description "This is the interval that the acting DF waits between receiving a better DF Offer and sending the Pass message to transfer DF responsibility"; } leaf offer-multiplier { type uint8; default 3; description "This is number of transmission attempts for DF election messages. When a DF election Offer or Winner message fails to be received, the message is retransmitted. The offer-multiplier sets the minimum number of DF election messages that must fail to be received for DF election to fail. If a router receives from a neighbor a better offer than its own, the router stops participating in the election for a period of offer-multiplier * offer-interval. Eventually, all routers except the best candidate stop sending Offer messages."; } } // df-election } // bidir } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv4-rp" { description "PIM BIDIR augmentation."; uses static-rp-bidir-container; } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv6-rp" { description "PIM BIDIR augmentation."; Liu, et al. Expires November 20, 2018 [Page 86] Internet-Draft PIM YANG May 2018 uses static-rp-bidir-container; } // augment /* * Operational state data nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/pim-rp:rp" { description "PIM BIDIR augmentation to RP state data."; container bidir { config false; description "PIM BIDIR state data."; container df-election { description "DF election data."; list ipv4-rp { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "The address of the RP."; } } // ipv4-rp list ipv6-rp { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; description "The address of the RP."; } } // ipv6-rp } // df-election Liu, et al. Expires November 20, 2018 [Page 87] Internet-Draft PIM YANG May 2018 container interface-df-election { description "Interface DF election data."; list ipv4-rp { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address interface-name"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "The address of the RP."; } leaf interface-name { type if:interface-ref; description "The name of the interface for which the DF state is being maintained."; } leaf df-address { type inet:ipv4-address; description "The address of the elected DF, which is the winner of the DF Election process."; } uses interface-df-election-state-attributes; } // ipv4-rp list ipv6-rp { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address interface-name"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; description "The address of the RP."; } leaf interface-name { type if:interface-ref; description "The address of the RP."; } Liu, et al. Expires November 20, 2018 [Page 88] Internet-Draft PIM YANG May 2018 leaf df-address { type inet:ipv6-address; description "DF address."; } uses interface-df-election-state-attributes; } // ipv6-rp } // interface-df-election } } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family/pim-base:neighbors/" + "pim-base:ipv4-neighbor" { description "PIM BIDIR augmentation to the IPv4 neighbor state data."; leaf bidir-capable { type boolean; description "'true' if the neighbor is using the Bidirectional Capable option in the last Hello message."; } } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family/pim-base:neighbors/" + "pim-base:ipv6-neighbor" { description "PIM BIDIR augmentation to the IPv6 neighbor state data."; leaf bidir-capable { type boolean; description "'true' if the neighbor is using the Bidirectional Capable option in the last Hello message."; } } // augment } 7. Implementation Status This section to be removed by the RFC editor. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Liu, et al. Expires November 20, 2018 [Page 89] Internet-Draft PIM YANG May 2018 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 RFC 7942, "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". This document is the work result of the PIM working group's YANG multicast design team. The following wiki page contains the information on the design team members, the meeting discussions, lists of modeled features, and which features are supported by which existing implementations: https://trac.ietf.org/trac/pim/wiki/yang 8. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: Liu, et al. Expires November 20, 2018 [Page 90] Internet-Draft PIM YANG May 2018 pim-base:graceful-restart This subtree specifies the configuration for the PIM graceful restart at the global level on a device. Modifying the configuration can cause temporary interruption to the multicast routing during restart. pim-base:address-family/pim-base:graceful-restart This subtree specifies the per address family configuration for the PIM graceful restart on a device. Modifying the configuration can cause temporary interruption to the multicast routing during restart. pim-base:address-family/pim-rp:pim-rp:rp This subtree specifies the configuration for the PIM Rendezvous Point (RP) on a device. Modifying the configuration can cause RP malfunctions. pim-base:address-family/pim-sm:sm This subtree specifies the configuration for the PIM Sparse Mode (PIM-SM) on a device. Modifying the configuration can cause multicast traffic disabled or rerouted in PIM-SM. pim-base:address-family/pim-dm:dm This subtree specifies the configuration for the PIM Dense Mode (PIM-DM) on a device. Modifying the configuration can cause multicast traffic disabled or rerouted in PIM-DM. pim-base:address-family/pim-bidir:bidir This subtree specifies the configuration for the PIM Bidirectional Mode (PIM-BIDIR) on a device. Modifying the configuration can cause multicast traffic disabled or rerouted in PIM-BIDIR. pim-base:interfaces This subtree specifies the configuration for the PIM interfaces on a device. Modifying the configuration can cause the PIM protocol to get insufficient or incorrect information. These subtrees are all nnder /rt:routing/rt:control-plane-protocols/ pim-base:pim. Unauthorized access to any data node of these subtrees can adversely affect the multicast routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or Liu, et al. Expires November 20, 2018 [Page 91] Internet-Draft PIM YANG May 2018 notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /rt:routing/rt:control-plane-protocols/pim-base:pim Unauthorized access to any data node of the above subtree can disclose the operational state information of PIM on this device. 9. IANA Considerations RFC Ed.: In this section, replace all occurrences of 'XXXX' with the actual RFC number (and remove this note). This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-base Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-bidir Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-dm Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-rp Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-sm Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document registers the following YANG modules in the YANG Module Names registry [RFC7950]: Liu, et al. Expires November 20, 2018 [Page 92] Internet-Draft PIM YANG May 2018 -------------------------------------------------------------------- name: ietf-pim-base namespace: urn:ietf:params:xml:ns:yang:ietf-pim-base prefix: pim-base reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-bidir namespace: urn:ietf:params:xml:ns:yang:ietf-pim-bidir prefix: pim-bidir reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-dm namespace: urn:ietf:params:xml:ns:yang:ietf-pim-dm prefix: pim-dm reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-rp namespace: urn:ietf:params:xml:ns:yang:ietf-pim-rp prefix: pim-rp reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-sm namespace: urn:ietf:params:xml:ns:yang:ietf-pim-sm prefix: pim-sm reference: RFC XXXX -------------------------------------------------------------------- 10. Acknowledgements The authors would like to thank Steve Baillargeon, Guo Feng, Robert Kebler, Tanmoy Kundu, and Stig Venaas for their valuable contributions. 11. References 11.1. Normative References [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, . Liu, et al. Expires November 20, 2018 [Page 93] Internet-Draft PIM YANG May 2018 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, January 2005, . [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, . [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10.17487/RFC4610, August 2006, . [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, . [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, . [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. Kessler, "Protocol Independent Multicast MIB", RFC 5060, DOI 10.17487/RFC5060, 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, . [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, . Liu, et al. Expires November 20, 2018 [Page 94] Internet-Draft PIM YANG May 2018 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-13 (work in progress), March 2018. Liu, et al. Expires November 20, 2018 [Page 95] Internet-Draft PIM YANG May 2018 11.2. Informative References [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, . [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . [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, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", draft-ietf-netmod-rfc6087bis-20 (work in progress), March 2018. Liu, et al. Expires November 20, 2018 [Page 96] Internet-Draft PIM YANG May 2018 Appendix A. Data Tree Example This section contains an example of an instance data tree in the JSON encoding [RFC7951], containing both configuration and state data. lo0: 2001:db8:0:200::1 (RP address) | +-------+ | | | Router| | eth21 +---+ R2 +---+ eth23 | | (RP) | | | +-------+ | lo0: 2001:db8:0:300::1 | +-------+ | | +-------+ | | | Router| | | | Router| | eth10 +--+ R1 +---+ eth12 eth32 +---+ R3 +--+ eth30 | | | | | | | | | +-------+ | +-------+ | +-------+ | | +-------+ | +-------+ | | | | | Router| | | | | | +--+ +---+ R4 +---+ +-------+ +--+ | | | | | | | | | Router| | | | +-------+ | | +-------+ +---+ R5 | | +-------+ Source | | | Receiver | +-------+ The configuration instance data tree for Router R3 in the above figure could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "lo0", "description": "R3 loopback interface.", "type": "iana-if-type:softwareLoopback", "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:300::1", "prefix-length": 64 } ] } }, { "name": "eth30", "description": "An interface connected to the receiver.", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv6": { Liu, et al. Expires November 20, 2018 [Page 97] Internet-Draft PIM YANG May 2018 "forwarding": true } }, { "name": "eth32", "description": "An interface connected to RP (R2).", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv6": { "forwarding": true } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.3", "control-plane-protocols": { "ietf-pim-base:pim": { "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-rp:rp": { "static-rp": { "ipv6-rp": [ { "rp-address": "2001:db8:0:200::1", "ietf-pim-sm:sm": { } } ] } } } ], "interfaces": { "interface": [ { "name": "lo0", "address-family": [ { "address-family": "ietf-routing:ipv6", "hello-interval": "infinity", "ietf-pim-sm:sm": { } } ] }, { "name": "eth30", Liu, et al. Expires November 20, 2018 [Page 98] Internet-Draft PIM YANG May 2018 "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { } } ] }, { "name": "eth32", "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { } } ] } ] } } } } } The corresponding operational state data for Router R3 could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "lo0", "description": "R3 loopback interface.", "type": "iana-if-type:softwareLoopback", "phys-address": "00:00:5e:00:53:03", "oper-status": "up", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "ietf-ip:ipv6": { "mtu": 1500, "address": [ { "ip": "2001:db8:0:300::1", "prefix-length": 64, "origin": "static", "status": "preferred" Liu, et al. Expires November 20, 2018 [Page 99] Internet-Draft PIM YANG May 2018 }, { "ip": "fe80::200:5eff:fe00:5303", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ ] } }, { "name": "eth30", "description": "An interface connected to the receiver.", "type": "iana-if-type:ethernetCsmacd", "phys-address": "00:00:5e:00:53:30", "oper-status": "up", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "ietf-ip:ipv6": { "forwarding": true, "mtu": 1500, "address": [ { "ip": "fe80::200:5eff:fe00:5330", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ ] } }, { "name": "eth32", "description": "An interface connected to RP (R2).", "type": "iana-if-type:ethernetCsmacd", "phys-address": "00:00:5e:00:53:32", "oper-status": "up", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "ietf-ip:ipv6": { "forwarding": true, "mtu": 1500, Liu, et al. Expires November 20, 2018 [Page 100] Internet-Draft PIM YANG May 2018 "address": [ { "ip": "fe80::200:5eff:fe00:5332", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ { "ip": "fe80::200:5eff:fe00:5323", "link-layer-address": "00:00:5e:00:53:23", "origin": "dynamic", "is-router": [null], "state": "reachable" } ] } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.1", "interfaces": { "interface": [ "lo0", "eth30", "eth32" ] }, "control-plane-protocols": { "ietf-pim-base:pim": { "address-family": [ { "address-family": "ietf-routing:ipv6", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "topology-tree-info": { "ipv6-route": [ { "group": "ff06::1", "source-address": "*", "is-rpt": true, "expiration": 16, "incoming-interface": "eth32", "is-spt": false, "mode": "pim-asm", Liu, et al. Expires November 20, 2018 [Page 101] Internet-Draft PIM YANG May 2018 "msdp-learned": false, "rp-address": "2001:db8:0:200::1", "rpf-neighbor": "fe80::200:5eff:fe00:5323", "up-time": 123400, "outgoing-interface": [ { "name": "eth30", "expiration": 36, "up-time": 223400, "jp-state": "join" } ] }, { "group": "ff06::1", "source-address": "2001:db8:1:1::100", "is-rpt": false, "expiration": 8, "incoming-interface": "eth32", "is-spt": true, "mode": "pim-asm", "msdp-learned": false, "rp-address": "2001:db8:0:200::1", "rpf-neighbor": "fe80::200:5eff:fe00:5323", "up-time": 5200, "outgoing-interface": [ { "name": "eth30", "expiration": 6, "up-time": 5600, "jp-state": "join" } ] } ] }, "ietf-pim-rp:rp": { "static-rp": { "ipv6-rp": [ { "rp-address": "2001:db8:0:200::1", "ietf-pim-sm:sm": { } } ] }, "rp-list": { "ipv6-rp": [ Liu, et al. Expires November 20, 2018 [Page 102] Internet-Draft PIM YANG May 2018 { "rp-address": "2001:db8:0:200::1", "mode": "ietf-pim-sm:rp-sm", "info-source-type": "static", "up-time": 323400, "expiration": "not-set" } ] }, "rp-mappings": { "ipv6-rp": [ { "group-range": "ff06::1/128", "rp-address": "2001:db8:0:200::1", "up-time": 123400, "expiration": "36" } ] } } } ], "interfaces": { "interface": [ { "name": "lo0", "address-family": [ { "address-family": "ietf-routing:ipv6", "hello-interval": "infinity", "ietf-pim-sm:sm": { }, "oper-status": "up", "gen-id": 103689, "hello-expiration": "infinity", "ipv6": { "address": [ "fe80::200:5eff:fe00:5303" ], "dr-address": "fe80::200:5eff:fe00:5303" }, "neighbors": { "ipv6-neighbor": [ ] } } ] }, Liu, et al. Expires November 20, 2018 [Page 103] Internet-Draft PIM YANG May 2018 { "name": "eth30", "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { }, "oper-status": "up", "gen-id": 203689, "hello-expiration": 18, "ipv6": { "address": [ "fe80::200:5eff:fe00:5330" ], "dr-address": "fe80::200:5eff:fe00:5330" }, "neighbors": { "ipv6-neighbor": [ ] } } ] }, { "name": "eth32", "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { }, "oper-status": "up", "gen-id": 303689, "hello-expiration": 21, "ipv6": { "address": [ "fe80::200:5eff:fe00:5332" ], "dr-address": "fe80::200:5eff:fe00:5332" }, "neighbors": { "ipv6-neighbor": [ { "address": "fe80::200:5eff:fe00:5323", "expiration": 28, "dr-priority": 1, "gen-id": 102, "lan-prune-delay": { "present": false Liu, et al. Expires November 20, 2018 [Page 104] Internet-Draft PIM YANG May 2018 }, "up-time": 323500 } ] } } ] } ] } } } } } Authors' Addresses Xufeng Liu Volta Networks EMail: xufeng.liu.ietf@gmail.com Pete McAllister Metaswitch Networks 100 Church Street Enfield EN2 6BQ UK EMail: pete.mcallister@metaswitch.com Anish Peter Individual EMail: anish.ietf@gmail.com Mahesh Sivakumar Juniper Networks 1133 Innovation Way Sunnyvale, California USA EMail: sivakumar.mahesh@gmail.com Liu, et al. Expires November 20, 2018 [Page 105] Internet-Draft PIM YANG May 2018 Yisong Liu Huawei Technologies Huawei Administration Building Longgang, Guangdong 518129 China EMail: liuyisong@huawei.com Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai, Shanghai 201203 China EMail: hu.fangwei@zte.com.cn Liu, et al. Expires November 20, 2018 [Page 106] ./draft-ietf-mmusic-mux-exclusive-12.txt0000644000764400076440000006221313103102012017447 0ustar iustyiusty Network Working Group C. Holmberg Internet-Draft Ericsson Updates: 5761 (if approved) May 5, 2017 Intended status: Standards Track Expires: November 6, 2017 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP draft-ietf-mmusic-mux-exclusive-12.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 November 6, 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 Holmberg Expires November 6, 2017 [Page 1] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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 November 6, 2017 [Page 2] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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 [RFC5761], 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 November 6, 2017 [Page 3] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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' attribute [RFC5761] 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 'rtcp-mux-only' attribute in an SDP answer is forbidden. 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 Holmberg Expires November 6, 2017 [Page 4] Internet-Draft Exclusive RTP/RTCP Mux May 2017 4. SDP Offer/Answer Procedures 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 MUST 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' attribute with the corresponding SDP media description ("m=") in the associated answer, following the procedures in [RFC5761]. 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]. The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line) in the answer. Holmberg Expires November 6, 2017 [Page 5] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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' 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' attribute, the offerer MUST either take appropriate actions in order to disable the associated RTP-based media, e.g., send a new offer with a zero port value associated with the SDP media description ("m=" line), 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 MUST 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 November 6, 2017 [Page 6] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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 [RFC5761], 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 NOTE: [RFC8035] also updates section 5.1.1 of [RFC5761]. While the paragraph updated in this document is not updated by [RFC8035], the location of the paragraph within section 5.1.1 is moved. Holmberg Expires November 6, 2017 [Page 7] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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. 5.3. Update to 2nd paragraph of section 5.1.3 Holmberg Expires November 6, 2017 [Page 8] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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]. 8. IANA Considerations This document updates the "Session Description Protocol Parameters" registry as specified in Section 8.2.2 of [RFC4566]. Specifically, Holmberg Expires November 6, 2017 [Page 9] Internet-Draft Exclusive RTP/RTCP Mux May 2017 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-11 o Clarification note added to RFF 5761 update section. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-10 o Changes based on comments from Ekr: o - 'rtcp-mux-only' attribute only defined for SDP offers 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. Holmberg Expires November 6, 2017 [Page 10] Internet-Draft Exclusive RTP/RTCP Mux May 2017 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07 o Comments from Ben Campbell. 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. Holmberg Expires November 6, 2017 [Page 11] Internet-Draft Exclusive RTP/RTCP Mux May 2017 o Updates to RFC 5761 removed. o IANA considerations added. 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, . Holmberg Expires November 6, 2017 [Page 12] Internet-Draft Exclusive RTP/RTCP Mux May 2017 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC8035] Holmberg, C., "Session Description Protocol (SDP) Offer/ Answer Clarifications for RTP/RTCP Multiplexing", RFC 8035, DOI 10.17487/RFC8035, November 2016, . [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 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-36 (work in progress), October 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 Holmberg Expires November 6, 2017 [Page 13] Internet-Draft Exclusive RTP/RTCP Mux May 2017 Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires November 6, 2017 [Page 14] ./draft-ietf-sipcore-rejected-09.txt0000644000764400076440000016265513505503104016623 0ustar iustyiusty SIPCORE E. Burger Internet-Draft Georgetown University Intended status: Standards Track B. Nagda Expires: December 30, 2019 Massachusetts Institute of Technology June 28, 2019 A Session Initiation Protocol (SIP) Response Code for Rejected Calls draft-ietf-sipcore-rejected-09 Abstract This document defines the 608 (Rejected) SIP response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus no one will answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code, which a human at the target User Agent Server indicated the user did not want the call. In some jurisdictions this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked. 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 https://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 30, 2019. Burger & Nagda Expires December 30, 2019 [Page 1] Internet-Draft SIP Response Code for Rejected Calls June 2019 Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8 3.2. JWS Construction . . . . . . . . . . . . . . . . . . . . 9 3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9 3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 10 3.5. Announcement Requirements . . . . . . . . . . . . . . . . 11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 15 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 16 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 18 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 18 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Burger & Nagda Expires December 30, 2019 [Page 2] Internet-Draft SIP Response Code for Rejected Calls June 2019 1. Introduction The IETF has been addressing numerous issues surrounding how to handle unwanted and, depending on the jurisdiction, illegal calls [RFC5039]. STIR [RFC7340] and SHAKEN [SHAKEN] address the cryptographic signing and attestation, respectively, of signaling to ensure the integrity and authenticity of the asserted caller identity. This document describes a new Session Initiation Protocol (SIP) [RFC3261] response code, 608, which allows calling parties to learn that an intermediary rejected their call. As described below, we need a distinct indicator to differentiate between a user rejection and an intermediary's rejection of a call. In some jurisdictions, service providers may not be permitted to block calls, even if unwanted by the user, unless there is an explicit user request. Moreover, users may misidentify the nature of a caller. For example, a legitimate caller may call a user who finds the call to be unwanted. However, instead of marking the call as unwanted, the user may mark the call as illegal. With that information, an analytics engine may determine to block all calls from that source. However, in some jurisdictions blocking calls from that source for other users may not be legal. Likewise, one can envision jurisdictions that allow an operator to block such calls, but only if there is a remediation mechanism in place to address false positives. Some call blocking services may return responses such as 604 (Does Not Exist Anywhere). This might be a strategy to try to get a destination's address removed from a calling database. However, other network elements might also interpret this to mean the user truly does not exist, which might result in the user not being able to receive calls from anyone, even if they wanted to receive the calls. In many jurisdictions, providing such false signaling is also illegal. The 608 response code addresses this need of remediating falsely blocked calls. Specifically, this code informs the SIP User Agent Client (UAC) that an intermediary blocked the call and provides a redress mechanism that allows callers to contact the operator of the intermediary. In the current call handling ecosystem, users can explicitly reject a call or later mark a call as being unwanted by issuing a 607 SIP response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 show the operation of the 607 SIP response code. The User Agent Server (UAS) indicates the call was unwanted. As [RFC8197] explains, not only does the called party desire to reject that call, they can let their Burger & Nagda Expires December 30, 2019 [Page 3] Internet-Draft SIP Response Code for Rejected Calls June 2019 proxy know that they consider future calls from that source unwanted. Upon receipt of the 607 response from the UAS, the proxy may send unwanted call indicators, such as the value of the From header field and other information elements, to a call analytics engine. For various reasons described in [RFC8197], if a network operator receives multiple reports of unwanted calls, that may indicate that the entity placing the calls is likely to be a source of unwanted calls for many people. As such, other customers of the service provider may want the service provider to automatically reject calls on their behalf. There is another value of the 607 rejection code. Presuming the proxy forwards the response code to the User Agent Client (UAC), the calling UAC or intervening proxies will also learn the user is not interested in receiving calls from that sender. +-----------+ | Call | | Analytics | | Engine | +-----------+ ^ | (likely not SIP) | v +-----------+ +-----+ 607 | Called | 607 +-----+ | UAC | <--------- | Party | <-------- | UAS | +-----+ | Proxy | +-----+ +-----------+ Figure 1: Unwanted (607) Call Flow For calls rejected with a 607 from a legitimate caller, receiving a 607 response code can inform the caller to stop attempting to call the user. Moreover, if a legitimate caller believes the user is rejecting their calls in error, they can use other channels to contact the user. For example, if a pharmacy calls a user to let them know their prescription is available for pickup and the user mistakenly thinks the call is unwanted and issues a 607 response code, the pharmacy, having an existing relationship with the customer, can send the user an email or push a note to the pharmacist to ask the customer to consider not rejecting their calls in the future. Many systems that allow the user to mark the call unwanted (e.g., with the 607 response code) also allow the user to change their mind and unmark such calls. This mechanism is relatively easy to Burger & Nagda Expires December 30, 2019 [Page 4] Internet-Draft SIP Response Code for Rejected Calls June 2019 implement as the user usually has a direct relationship with the service provider that is blocking calls. However, things become more complicated if an intermediary, such as a third-party provider of call management services that classifies calls based on the relative likelihood that the call is unwanted, misidentifies the call as unwanted. Figure 3 shows this case. Note that the UAS typically does not receive an INVITE since the called party proxy rejects the call on behalf of the user. In this situation, it would be beneficial for the caller to learn who rejected the call, so they can correct the misidentification. +--------+ +-----------+ | Called | | Call | +-----+ | Party | | Analytics | +-----+ | UAC | | Proxy | | Engine | | UAS | +-----+ +--------+ +-----------+ +-----+ | INVITE | | | | --------------> | Is call OK? | | | |------------------->| | | | | | | | Yes | | | |<-------------------| | | | | | | | INVITE | | | | ------------------------------> | | | | | | | | 607 | | | <------------------------------ | | | | | | | Unwanted call | | | 607 | -----------------> | | | <-------------- | indicators | | | | | | Figure 2: Unwanted (607) Ladder Diagram Burger & Nagda Expires December 30, 2019 [Page 5] Internet-Draft SIP Response Code for Rejected Calls June 2019 +-----------+ | Call | | Analytics | | Engine | +-----------+ ^ | (likely not SIP) | v +-----------+ +-----+ 608 | Called | +-----+ | UAC | <--------- | Party | | UAS | +-----+ | Proxy | +-----+ +-----------+ Figure 3: Rejected (608) Call Flow In this situation, one might consider to have the intermediary use the 607 response code. 607 indicates to the caller the subscriber does not want the call. However, [RFC8197] specifies that one of the uses of 607 is to inform analytics engines that a user (human) has rejected a call. The problem here is that network elements downstream from the intermediary might interpret the 607 as coming from a user (human) who has marked the call as unwanted, as opposed to coming from an algorithm using statistics or machine learning to reject the call. An algorithm can be vulnerable to the base rate fallacy [BaseRate] rejecting the call. In other words, those downstream entities should not rely on another entity 'deciding' the call is unwanted. By distinguishing between a (human) user rejection and an intermediary engine's statistical rejection, a downstream network element that sees a 607 response code can weigh it as a human rejection in its call analytics, versus deciding whether to consider a 608 at all, and if so, weighing it appropriately. It is useful for blocked callers to have a redress mechanism. One can imagine that some jurisdictions will require it. However, we must be mindful that most of the calls that intermediaries block will, in fact, be illegal and eligible for blocking. Thus, providing alternate contact information for a user would be counterproductive to protecting that user from illegal communications. This is another reason we do not propose to simply allow alternate contact information in a 607 response message. Why do we not use the same mechanism an analytics service provider offers their customers? Specifically, why not have the analytics service provider allow the called party to correct a call blocked in error? The reason is while there is an existing relationship between the customer (called party) and the analytics service provider, it is unlikely there is a relationship between the caller and the analytics Burger & Nagda Expires December 30, 2019 [Page 6] Internet-Draft SIP Response Code for Rejected Calls June 2019 service provider. Moreover, there are numerous call blocking providers in the ecosystem. Therefore, we need a mechanism for indicating an intermediary rejected a call that also provides contact information for the operator of that intermediary, without exposing the target user's contact information. The protocol described in this document uses existing SIP protocol mechanisms for specifying the redress mechanism. In the Call-Info header passed back to the UAC, we send additional information specifying a redress address. We choose to encode the redress address using jCard [RFC7095]. As we will see later in this document, this information needs to have its own, application-layer integrity protection. Thus, we use jCard rather than vCard [RFC6350] as we have a marshaling mechanism for creating a JavaScript Object Notation (JSON) [RFC8259] object, such as a jCard, and a standard integrity format for such an object, namely JSON Web Signature (JWS) [RFC7515]. The SIP community is familiar with this concept as it is the mechanism used by STIR [RFC8224]. Integrity protecting the jCard with a cryptographic signature might seem unnecessary at first, but it is essential to preventing potential network attacks. Section 6 describes the attack and why we sign the jCard in more detail. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Protocol Operation This section uses the term 'intermediary' to mean the entity that acts as a SIP User Agent Server (UAS) on behalf of the user in the network, as opposed to the user's UAS (usually, but not necessarily, their phone). The intermediary could be a back-to-back user agent (B2BUA) or a SIP Proxy. Figure 4 shows an overview of the call flow for a rejected call. Burger & Nagda Expires December 30, 2019 [Page 7] Internet-Draft SIP Response Code for Rejected Calls June 2019 +--------+ +-----------+ | Called | | Call | +-----+ | Party | | Analytics | +-----+ | UAC | | Proxy | | Engine | | UAS | +-----+ +--------+ +-----------+ +-----+ | INVITE | | | | --------------> | Information from | | | | -----------------> | | | | INVITE | | | | Reject | | | 608 | <----------------- | | | <-------------- | call | | | | | | Figure 4: Rejected (608) Ladder Diagram 3.1. Intermediary Operation An intermediary MAY issue the 608 response code in a failure response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP [RFC3261] request to indicate that an intermediary rejected the offered communication as unwanted by the user. An intermediary MAY issue the 608 as the value of the "cause" parameter of a SIP reason- value in a Reason header field [RFC3326]. If an intermediary issues a 608 code and there are no indicators the calling party will use the contents of the Call-Info header field for malicious purposes (see Section 6), the intermediary MUST include a Call-Info header field in the response. If there is a Call-Info header field, it MUST have the 'purpose' parameter of 'jwscard'. The value of the Call-Info header field MUST refer to a valid JSON Web Signature (JWS [RFC7515]) encoding of a jCard [RFC7095] object. The following section describes the construction of the JWS. Proxies need to be mindful that a downstream intermediary may reject the attempt with a 608 while other paths may still be in progress. In this situation, the requirements stated in Section 16.7 of [RFC3261] apply. Specifically, the proxy should cancel pending transactions and must not create any new branches. Note this is not a new requirement but simply pointing out the existing 6xx protocol mechanism in SIP. Burger & Nagda Expires December 30, 2019 [Page 8] Internet-Draft SIP Response Code for Rejected Calls June 2019 3.2. JWS Construction The intermediary constructs the JWS of the jCard as follows. 3.2.1. JOSE Header The Javascript Object Signing and Encryption (JOSE) header MUST include the typ, alg, and x5u parameters from JWS [RFC7515]. The typ parameter MUST have the value "vcard+json". Implementations MUST support ES256 as JSON Web Algorithms (JWA [RFC7518]) defines it, and MAY support other registered signature algorithms. Finally, the x5u parameter MUST be a URI that resolves to the public key certificate corresponding to the key used to digitally sign the JWS. 3.2.2. JWT Payload The payload contains two JSON values. The first JSON Web Token (JWT) claim that MUST be present is the iat (issued at) claim [RFC7519]. The "iat" MUST be set to the date and time of the issuance of the 608 response. This mandatory component protects the response from replay attacks. The second JWT claim that MUST be present is the "jcard" claim. The value of the jcard [RFC7095] claim is a JSON array conforming to the JSON jCard data format defined in RFC7095 Section 5.3 describes the registration. In the construction of the jcard claim, the "jcard" MUST include at least one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this specification MUST be prepared to receive a full jCard. Call originators (at the UAC) can use the information returned by the jCard to contact the intermediary that rejected the call to appeal the intermediary's blocking of the call attempt. What the intermediary does if the blocked caller contacts the intermediary is outside the scope of this document. 3.2.3. JWS Signature JWS [RFC7515] specifies the procedure for calculating the signature over the jCard JWT. Section 4 of this document has a detailed example on constructing the JWS, including the signature. 3.3. UAC Operation A UAC conforming to this specification MUST include the sip.608 feature capability indicator in the Feature-Caps header field of the INVITE request. Upon receiving a 608 response, UACs perform normal SIP processing for 6xx responses. Burger & Nagda Expires December 30, 2019 [Page 9] Internet-Draft SIP Response Code for Rejected Calls June 2019 As for the disposition of the jCard itself, the UAC MUST check the "iat" claim in the JWT. As noted in Section 3.2.3, we are concerned about replay attacks. Therefore, the UAC MUST reject jCards that come with an expired "iat". The definition of "expired" is a matter of local policy. A reasonable value would be on the order of a minute due to clock drift and the possibility of the playing of an audio announcement before the delivery of the 608 response. 3.4. Legacy Interoperation If the UAC indicates support for 608 and the intermediary issues a 608, life is good, as the UAC will receive all the information it needs to remediate an erroneous block by an intermediary. However, what if the UAC does not understand 608? For example, how can we support callers from a legacy, non-SIP public switched network connecting to the SIP network via a media gateway? We address this situation by having the first network element that conforms with this specification play an announcement in the media. See Section 3.5 for requirements on the announcement. The simple rule is a network element that inserts the sip.608 feature capability MUST be able to convey at a minimum how to contact the operator of the intermediary that rejected the call attempt. The degenerate case is the intermediary is the only element that understands the semantics of the 608 response code. Obviously, any SIP device will understand that a 608 response code is a 6xx error. However, there are no other elements in the call path that understand the meaning of the value of the Call-Info header field. The intermediary knows this is the case as the INVITE request will not have the sip.608 feature capability. In this case, one can consider the intermediary to be the element 'inserting' a virtual sip.608 feature capability. If the caveats described in Section 3.5 and Section 6 do not hold, the intermediary MUST play the announcement. Now we take the case where a network element that understands the 608 response code receives an INVITE for further processing. A network element conforming with this specification MUST insert the sip.608 feature capability, per the behaviors described in Section 4.2 of [RFC6809]. Do note that even if a network element plays an announcement describing the contents of the 608 response message, the network element MUST forward the 608 response code message as the final response to the INVITE. One aspect of using a feature capability is that only the network elements that will either consume (UAC) or play an announcement Burger & Nagda Expires December 30, 2019 [Page 10] Internet-Draft SIP Response Code for Rejected Calls June 2019 (media gateway, session border controller (SBC [RFC7092]), or proxy) need to understand the sip.608 feature capability. If the other network elements conform to Section 16.6 of [RFC3261], they will pass header fields such as "Feature-Caps: *;+sip.608" unmodified and without need for upgrade. Because the ultimate disposition of the call attempt will be a 600-class response, the network element conveying the announcement in the legacy direction MUST use the 183 Session Progress response to establish the media session. Because of the small chance the UAC is an extremely old legacy device and is using UDP, the UAC MUST include support for 100Rel [RFC3262] in its INVITE and the network element conveying the announcement MUST Require 100Rel in the 183 and the UAC MUST issue a PRACK to which the network element MUST respond 200 OK PRACK. 3.5. Announcement Requirements There are a few requirements on the element that handles the announcement for legacy interoperation. As noted above, the element that inserts the sip.608 feature capability is responsible for conveying the information referenced by the Call-Info header field in the 608 response message. However, this specification does not mandate how to convey that information. Let us take the case where a telecommunications service provider controls the element inserting the sip.608 feature capability. It would be reasonable to expect the service provider would play an announcement in the media path towards the UAC (caller). It is important to note the network element should be mindful of the media type requested by the UAC as it formulates the announcement. For example, it would make sense for an INVITE that only indicated audio codecs in the Session Description Protocol (SDP) [RFC4566] to result in an audio announcement. Likewise, if the INVITE only indicated a real-time text codec [RFC4103] and the network element can render the information in the requested media format, the network element should send the information in a text format. It is also possible for the network element inserting the sip.608 feature capability to be under the control of the same entity that controls the UAC. For example, a large call center might have legacy UACs, but have a modern outbound calling proxy that understands the full semantics of the 608 response code. In this case, it is enough for the outbound calling proxy to digest the Call-Info information and handle the information digitally, rather than 'transcoding' the Call-Info information for presentation to the caller. Burger & Nagda Expires December 30, 2019 [Page 11] Internet-Draft SIP Response Code for Rejected Calls June 2019 4. Examples These examples are not normative, do not include all protocol elements, and may have errors. Review the protocol documents for actual syntax and semantics of the protocol elements. 4.1. Full Exchange Given an INVITE, shamelessly taken from [SHAKEN], with the line breaks in the Identity header field for display purposes only: INVITE sip:+12155550113@tel.one.example.net SIP/2.0 Max-Forwards: 69 Contact: To: From: "Alice" ;tag=614bdb40 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI P-Asserted-Identity: "Alice", CSeq: 2 INVITE Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE, OPTIONS Content-Type: application/sdp Date: Tue, 16 Aug 2016 19:23:38 GMT Feature-Caps: *;+sip.608 Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info= ;alg=ES256 Content-Length: 153 v=0 o=- 13103070023943130 1 IN IP6 2001:db8::177 c=IN IP6 2001:db8::177 t=0 0 m=audio 54242 RTP/AVP 0 a=sendrecv An intermediary could reply: Burger & Nagda Expires December 30, 2019 [Page 12] Internet-Draft SIP Response Code for Rejected Calls June 2019 SIP/2.0 608 Rejected Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1 From: "Alice" ;tag=614bdb40 To: Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI CSeq: 2 INVITE Call-Info: ;purpose=jwscard The location https://block.example.net/complaint-jws resolves to a JWS. One would construct the JWS as follows. The JWS header of this example jCard could be: { "alg":"ES256", "typ":"vcard+json", "x5u":"https://certs.example.net/reject_key.cer" } Now, let us construct a minimal jCard. For this example, the jCard refers the caller to an email address, remediation@blocker.example.net: ["vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Robocall Adjudication"], ["email", {"type":"work"}, "text", "remediation@blocker.example.net"] ] ] With this jCard, we can now construct the JWT: { "iat":1546008698, "jcard":["vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Robocall Adjudication"], ["email", {"type":"work"}, "text", "remediation@blocker.example.net"] ] ] } Burger & Nagda Expires December 30, 2019 [Page 13] Internet-Draft SIP Response Code for Rejected Calls June 2019 To calculate the signature, we need to encode the JSON Object Signing and Encryption (JOSE) header and JWT into base64url. As an implementation note, one can trim whitespace in the JSON objects to save a few bytes. UACs MUST be prepared to receive pretty-printed, compact, or bizarrely formatted JSON. For the purposes of this example, we leave the objects with pretty whitespace. Speaking of pretty vs. machine formatting, these examples have line breaks in the base64url encodings for ease of publication in the RFC format. The specification of base64url allows for these line breaks and the decoded text works just fine. However, those extra line break octets would affect the calculation of the signature. Implementations MUST NOT insert line breaks into the base64url encodings of the JOSE header or JWT. This also means UACs MUST be prepared to receive arbitrarily long octet streams from the URI referenced by the Call- Info SIP header. base64url of JOSE header: eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0= base64url of JWT: eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7 fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 In this case, the object to sign (remembering this is just a single, long line; the line breaks are for ease of review but do not appear in the actual object) is as follows: eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2 ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0 IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 We use the following X.509 PKCS #8-encoded ECDSA key, also shamelessly taken from [SHAKEN]), as an example key for signing the hash of the above text. Do NOT use this key in real life! It is for example purposes only. At the very least, we would strongly recommend encrypting the key at rest. Burger & Nagda Expires December 30, 2019 [Page 14] Internet-Draft SIP Response Code for Rejected Calls June 2019 -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh -----END PRIVATE KEY----- -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== -----END PUBLIC KEY----- The resulting JWS, using the above key on the above object, renders the following ECDSA P-256 SHA-256 digital signature. 7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL 5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag Thus, the JWS stored at https://blocker.example.net/complaints-jws, would contain: eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL 2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6 g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag 4.2. Web Site jCard For an intermediary that provides a Web site for adjudication, the jCard could contain the following. Note we do not show the calculation of the JWS; the URI reference in the Call-Info header field would be to the JWS of the signed jCard. ["vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Robocall Adjudication"], ["url", {"type":"work"}, "text", "https://blocker.example.net/adjudication-form"] ] ] Burger & Nagda Expires December 30, 2019 [Page 15] Internet-Draft SIP Response Code for Rejected Calls June 2019 4.3. Multi-modal jCard For an intermediary that provides a telephone number and a postal address, the jCard could contain the following. Note we do not show the calculation of the JWS; the URI reference in the Call-Info header field would be to the JWS of the signed jCard. ["vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Robocall Adjudication"], ["adr", {"type":"work"}, "text", ["Argument Clinic", "12 Main St","Anytown","AP","000000","Somecountry"] ] ["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"] ] ] Note that it is up to the UAC to decide which jCard contact modality, if any, it will use. 4.4. Legacy Interoperability Figure 5 depicts a call flow illustrating legacy interoperability. In this non-normative example, we see a UAC that does not support the full semantics for 608. However, there is an SBC that does support 608. Per [RFC6809], the SBC can insert "*;+sip.608" into the Feature-Caps header field for the INVITE. When the intermediary, labeled "Called Party Proxy" in the figure, rejects the call, it knows it can simply perform the processing described in this document. Since the intermediary saw the sip.608 feature capability, it knows it does not need to send any media describing whom to contact in the event of an erroneous rejection. For illustrative purposes, the figure shows generic SIP Proxies in the flow. Their presence or absence or the number of proxies is not relevant to the operation of the protocol. They are in the figure to show that proxies that do not understand the sip.608 feature capability can still participate in a network offering 608 services. Burger & Nagda Expires December 30, 2019 [Page 16] Internet-Draft SIP Response Code for Rejected Calls June 2019 +---------+ | Call | |Analytics| | Engine | +--+--+---+ ^ | | | | v +-+--+-+ +---+ +-----+ +---+ +-----+ +-----+ |Called| |UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party | +---+ +-----+ +---+ +-----+ +-----+ |Proxy | | | +------+ | INVITE | | |------------------>| | | | INVITE | | |------------------------------>| | | Feature-Caps: *;+sip.608 | | | | | | 608 Rejected | | |<------------------------------| | 183 | Call-Info: <...> | |<------------------| [path for Call-Info elided | | SDP for media | for illustration purposes]| | | | | PRACK | | |------------------>| | | | | | 200 OK PRACK | | |<------------------| | | | | |<== Announcement ==| | | | | | 608 Rejected | | |<------------------| | | Call-Info: <...> | | | | | Figure 5: Legacy Operation When the SBC receives the 608 response code, it correlates that with the original INVITE from the UAC. The SBC remembers that it inserted the sip.608 feature capability, which means it is responsible for somehow alerting the UAC the call failed and whom to contact. At this point the SBC can play a prompt, either natively or through a mechanism such as NETANN [RFC4240], that sends the relevant information in the appropriate media to the UAC. Since this is a Burger & Nagda Expires December 30, 2019 [Page 17] Internet-Draft SIP Response Code for Rejected Calls June 2019 potentially long transaction and there is a chance the UAC is using an unreliable transport protocol, the UAC will have indicated support for provisional responses, the SBC will indicate it requires a PRACK from the UAC in the 183 response, the UAC will provide the PRACK, and the SBC will acknowledge receipt of the PRACK before playing the announcement. As an example, the SBC could extract the FN and TEL jCard fields and play something like a special information tone (see Telcordia SR-2275 [SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section 7), followed by "Your call has been rejected by ...", followed by a text-to-speech translation of the FN text, followed by "You can reach them on", followed by a text-to-speech translation of the telephone number in the TEL field. Note the SBC also still sends the full 608 response code, including the Call-Info header, towards the UAC. 5. IANA Considerations 5.1. SIP Response Code This document defines a new SIP response code, 608 in the "Response Codes" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry defined in [RFC3261]. Response code: 608 Description: Rejected Reference: [RFCXXXX] 5.2. SIP Feature-Capability Indicator This document defines the feature capability sip.608 in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809]. Name: sip.608 Description: This feature capability indicator, when included in a Feature-Caps header field of an INVITE request, indicates that the entity associated with the indicator will be responsible for indicating to the caller any information contained in the 608 SIP response code, specifically the value referenced by the Call-Info header. Reference: [RFCXXXX] Burger & Nagda Expires December 30, 2019 [Page 18] Internet-Draft SIP Response Code for Rejected Calls June 2019 5.3. JSON Web Token Claim This document defines the new JSON Web Token claim in the "JSON Web Token Claims" sub-registry created by [RFC7519]. Section 3.2.2 defines the syntax. The required information is: Claim Name: jcard Claim Description: jCard data Change Controller: IESG Reference: [RFCXXXX], [RFC7095] 5.4. Call-Info Purpose This document defines the new predefined value "jwscard" for the "purpose" header field parameter of the Call-Info header field. This modifies the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry by adding this RFC as a reference to the line for the header field "Call-Info" and parameter name "purpose": Header Field: Call-Info Parameter Name: purpose Predefined Values: Yes Reference: [RFCXXXX] 6. Security Considerations Intermediary operators need to be mindful to whom they are sending the 608 response. The intermediary could be rejecting a truly malicious caller. This raises two issues. The first is the caller, now alerted an intermediary is automatically rejecting their call attempts, may change their call behavior to defeat call blocking systems. The second, and more significant risk, is that by providing a contact in the Call-Info header field, the intermediary may be giving the malicious caller a vector for attack. In other words, the intermediary will be publishing an address that a malicious actor may use to launch an attack on the intermediary. Because of this, intermediary operators may wish to configure their response to only include a Call-Info header field for INVITE or other signed initiating methods and that pass validation by STIR [RFC8224]. Burger & Nagda Expires December 30, 2019 [Page 19] Internet-Draft SIP Response Code for Rejected Calls June 2019 Another risk is as follows. Consider an attacker that floods a proxy that supports the sip.608 feature. However, the SDP in the INVITE request refers to a victim device. Moreover, the attacker somehow knows there is a 608-aware gateway connecting to the victim who is on a segment that lacks the sip.608 feature capability. Because the mechanism described here can result in sending an audio file to the target of the SDP, an attacker could use the mechanism described by this document as an amplification attack, given a SIP INVITE can be under 1 kilobyte and an audio file can be hundreds of kilobytes. One remediation for this is for devices that insert a sip.608 feature capability to only transmit media to what is highly likely to be the actual source of the call attempt. A method for this is to only play media in response to a STIR-signed INVITE that passes validation. Beyond requiring a valid STIR signature on the INVITE, the intermediary can also use remediation procedures such as doing the connectivity checks specified by Interactive Connectivity Establishment [RFC8445]. If the target did not request the media, the check will fail. Yet another risk is a malicious intermediary that generates a malicious 608 response with a jCard referring to a malicious agent. For example, the recipient of a 608 may receive a TEL URI in the vCard. When the recipient calls that address, the malicious agent could ask for personally identifying information. However, instead of using that information to verify the recipient's identity, they are phishing the information for nefarious ends. A similar scenario can unfold if the malicious agent inserts a URI that points to a phishing or other site. As such, we strongly recommend the recipient validates to whom they are communicating with if asking to adjudicate an erroneously rejected call attempt. Since we may also be concerned about intermediate nodes modifying contact information, we can address both issues with a single solution. The remediation is to require the intermediary to sign the jCard. Signing the jCard provides integrity protection. In addition, one can imagine mechanisms such as used by SHAKEN [SHAKEN]. Similarly, one can imagine an adverse agent that maliciously spoofs a 608 response with a victim's contact address to many active callers, who may then all send redress requests to the specified address (the basis for a denial-of-service attack). The process would occur as follows: (1) a malicious agent senses INVITE requests from a variety of UACs and (2) spoofs 608 responses with an unsigned redress address before the intended receivers can respond, causing (3) the UACs to all contact the redress address at once. The jCard encoding allows the UAC to verify the blocking intermediary's identity before contacting the redress address. Specifically, because the sender signs the jCard, we can cryptographically trace the sender of the jCard. Given the protocol machinery of having a signature, one can Burger & Nagda Expires December 30, 2019 [Page 20] Internet-Draft SIP Response Code for Rejected Calls June 2019 apply local policy to decide whether to believe the sender of the jCard represents the owner of the contact information found in the jCard. This guards against a malicious agent spoofing 608 responses. Specifically, one could use policies around signing certificate issuance as a mechanism for traceback to the entity issuing the jCard. One check could be verifying the identity of the subject of the certificate relates to the To header field of the initial SIP request, similar to validating the intermediary was vouching for the From header field of a SIP request with that identity. Note that we are only protecting against a malicious intermediary and not a hidden intermediary attack (formerly known as a "man in the middle attack"). Thus, we only need to ensure the signature is fresh, which is why we include "iat". For most implementations, we assume that the intermediary has a single set of contact points and will generate the jCard on demand. As such, there is no need to directly correlate HTTPS fetches to specific calls. However, since the intermediary is in control of the jCard and Call-Info response, an intermediary may choose to encode per-call information in the URI returned in a given 608 response. However, if the intermediary does go that route, the intermediary MUST use a non-deterministic URI reference mechanism and be prepared to return dummy responses to URI requests referencing calls that do not exist so that attackers attempting to glean call metadata by guessing URI's (and thus calls) will not get any actionable information from the HTTPS GET. Since the decision of whether to include Call-Info in the 608 response is a matter of policy, one thing to consider is whether a legitimate caller can ascertain whom to contact without including such information in the 608. For example, in some jurisdictions, if only the terminating service provider can be the intermediary, the caller can look up who the terminating service provider is based on the routing information for the dialed number. Thus, the Call-Info jCard could be redundant information. However, the factors going into a particular service provider's or jurisdiction's choice of whether to include Call-Info is outside the scope of this document. 7. Acknowledgements This document liberally lifts from [RFC8197] in its text and structure. However, the mechanism and purpose of 608 is quite different than 607. Any errors are the current editor's and not the editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on improving the draft. Tolga's suggestion to provide a mechanism for legacy interoperability served to expand the draft by 50%. In addition, Tolga came up with the jCard attack. Finally, Christer Burger & Nagda Expires December 30, 2019 [Page 21] Internet-Draft SIP Response Code for Rejected Calls June 2019 Holmberg as always provided a close reading and fixed a SIP feature capability bug found by Yehoshua Gev. Of course, we appreciated the close read and five pages of comments from our estimable Area Director, Adam Roach. In addition, we received valuable comments during IETF Last Call and JWT review from Ines Robles, Mike Jones, and Brian Campbell and IESG review from Alissa Cooper, Eric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry Leiba, and with most glee, Warren Kumari. Finally, Bhavik Nagda provided clarifying edits as well and more especially wrote and tested an implementation of the 608 response code in Kamailio. Code is available at . Grace Chuan from MIT regenerated and verified the JWT while working at the FCC. 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, . [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, . [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, . [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, . [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, November 2012, . Burger & Nagda Expires December 30, 2019 [Page 22] Internet-Draft SIP Response Code for Rejected Calls June 2019 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [BaseRate] Bar-Hillel, M., "The Base-Rate Fallacy in Probability Judgements", 4 1977, < https://apps.dtic.mil/docs/citations/ADA045772>. [ITU.E.180.1998] International Telecommunications Union, "Technical characteristics of tones for the telephone service", ITU Recommendation E.180/Q.35, March 1998. [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, . [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, DOI 10.17487/RFC4240, December 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, January 2008, . Burger & Nagda Expires December 30, 2019 [Page 23] Internet-Draft SIP Response Code for Rejected Calls June 2019 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, . [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, . [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . [RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", RFC 8197, DOI 10.17487/RFC8197, July 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [SHAKEN] Alliance for Telecommunications Industry Solutions (ATIS) and the SIP Forum, "Signature-based Handling of Asserted information using toKENs (SHAKEN)", ATIS 1000074, 1 2017, . [SR-2275] Telcordia, "Bellcore Notes on the Networks", Telcordia SR- 2275, October 2000. Burger & Nagda Expires December 30, 2019 [Page 24] Internet-Draft SIP Response Code for Rejected Calls June 2019 Authors' Addresses Eric W. Burger Georgetown University 37th & O St, NW Washington, DC 20057 USA Email: eburger@standardstrack.com Bhavik Nagda Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 USA Email: nagdab@gmail.com Burger & Nagda Expires December 30, 2019 [Page 25] ./draft-ietf-mmusic-rid-15.txt0000644000764400076440000017101713276676425015460 0ustar iustyiusty Network Working Group A. Roach (Editor) Internet-Draft Mozilla Updates: 4855 (if approved) May 15, 2018 Intended status: Standards Track Expires: November 16, 2018 RTP Payload Format Restrictions draft-ietf-mmusic-rid-15 Abstract In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP Streams within an RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by 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 November 16, 2018. Copyright Notice Copyright (c) 2018 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 Roach (Editor) Expires November 16, 2018 [Page 1] Internet-Draft RTP Restrictions May 2018 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4 5. "a=rid" restrictions . . . . . . . . . . . . . . . . . . . . 6 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 8 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 9 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 9 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 13 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 13 8. Interaction with Other Techniques . . . . . . . . . . . . . . 13 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 14 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 14 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 14 8.2. Interaction with H.264 Format Parameters . . . . . . . . 15 8.2.1. profile-level-id and max-recv-level - Negotiated Sub- Profile . . . . . . . . . . . . . . . . . . . . . . . 16 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 16 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks . . . . . . . . . . . . . . . . . . . . . 16 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 17 8.3. Redundancy Formats and Payload Type Restrictions . . . . 17 9. Format Parameters for Future Payloads . . . . . . . . . . . . 18 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 18 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 20 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 Roach (Editor) Expires November 16, 2018 [Page 2] Internet-Draft RTP Restrictions May 2018 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 15.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Terminology The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP Stream" are used as defined in [RFC7656]. [RFC4566] and [RFC3264] terminology is also used where appropriate. 2. Introduction The Payload Type (PT) field in RTP provides a mapping between the RTP payload format and the associated SDP media description. The SDP rtpmap and/or fmtp attributes are used, for a given PT, to describe the properties of the media that is carried in the RTP payload. Recent advances in standards have given rise to rich multimedia applications requiring support for multiple RTP Streams within an RTP session [I-D.ietf-mmusic-sdp-bundle-negotiation], [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number of codecs. These demands have unearthed challenges inherent with: o The restricted RTP PT space in specifying the various payload configurations, o The codec-specific constructs for the payload formats in SDP, o Missing or underspecified payload format parameters, o Overloading of PTs to indicate not just codec configurations, but individual streams within an RTP session. To expand on these points: [RFC3550] assigns 7 bits for the PT in the RTP header. However, the assignment of static mapping of RTP payload type numbers to payload formats and multiplexing of RTP with other protocols (such as RTCP) could result in a limited number of payload type numbers available for application usage. In scenarios where the number of possible RTP payload configurations exceeds the available PT space within an RTP Session, there is a need for a way to represent the additional restrictions on payload configurations and to effectively map an RTP Stream to its corresponding restrictions. This issue is exacerbated by the increase in techniques - such as simulcast and layered codecs - which introduce additional streams into RTP Sessions. Roach (Editor) Expires November 16, 2018 [Page 3] Internet-Draft RTP Restrictions May 2018 This specification defines a new SDP framework for restricting Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes to restrict payload formats in a codec-agnostic way. This framework can be thought of as a complementary extension to the way the media format parameters are specified in SDP today, via the "a=fmtp" attribute. The additional restrictions on individual streams are indicated with a new "a=rid" ("restriction identifier") SDP attribute. Note that the restrictions communicated via this attribute only serve to further restrict the parameters that are established on a PT format. They do not relax any restrictions imposed by other mechanisms. This specification makes use of the RTP Stream Identifier Source Description (SDES) RTCP item defined in [I-D.ietf-avtext-rid] to provide correlation between the RTP Packets and their format specification in the SDP. As described in Section 6.2.1, this mechanism achieves backwards compatibility via the normal SDP processing rules, which require unknown a= lines to be ignored. This means that implementations need to be prepared to handle successful offers and answers from other implementations that neither indicate nor honor the restrictions requested by this mechanism. Further, as described in Section 6 and its subsections, this mechanism achieves extensibility by: (a) having offerers include all supported restrictions in their offer, and (b) having answerers ignore "a=rid" lines that specify unknown restrictions. 3. Key Words for Requirements 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. SDP "a=rid" Media Level Attribute This section defines new SDP media-level attribute [RFC4566], "a=rid", used to communicate a set of restrictions to be applied to an identified RTP Stream. Roughly speaking, this attribute takes the following form (see Section 10 for a formal definition). a=rid: [pt=;]=... Roach (Editor) Expires November 16, 2018 [Page 4] Internet-Draft RTP Restrictions May 2018 An "a=rid" SDP media attribute specifies restrictions defining a unique RTP payload configuration identified via the "rid-id" field. This value binds the restriction to the RTP Stream identified by its RTP Stream Identifier Source Description (SDES) item [I-D.ietf-avtext-rid]. Implementations that use the "a=rid" parameter in SDP MUST support the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such implementations MUST send that SDES item for all streams in an SDP media description ("m=") that have "a=rid" lines remaining after applying the rules in Section 6 and its subsections. Implementations that use the "a=rid" parameter in SDP and that make use of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or FEC [RFC5109], for any of the source RTP streams that have "a=rid" lines remaining after applying the rules in Section 6 and its subsections, MUST support the RepairedRtpStreamId SDES item described in [I-D.ietf-avtext-rid] for those redundancy RTP streams. RepairedRtpStreamId MUST be used for redundancy RTP streams to which it can be applied. Use of RepairedRtpStreamId is not applicable for redundancy formats that directly associate RTP streams through shared SSRCs (for example [I-D.ietf-payload-flexible-fec-scheme]) or other cases that RepairedRtpStreamId cannot support, such as referencing multiple source streams. RepairedRtpStreamId is used to provide the binding between the redundancy RTP stream and its source RTP stream, by setting the RepairedRtpStreamId value for the redundancy RTP stream to the RtpStreamId value of the source RTP stream. The redundancy RTP stream MAY (but need not) have an "a=rid" line of its own, in which case the RtpStreamId SDES item value will be different from the corresponding source RTP stream. It is important to note that this indirection may result in the temporary inability to correctly associate source and redundancy data when the SSRC associated with the RtpStreamId or RepairedRtpStreamId is dynamically changed during the RTP session. This can be avoided if all RTP packets, source and repair, after the change include their RtpStreamId or RepairedRtpStreamId, respectively. To maximize the probability of reception and utility of redundancy information after such a change, all the source packets referenced by the first several repair packets SHOULD include such information. It is RECOMMENDED that the number of such packets is large enough to give a high probability of actual updated association. Section 4.1.1 of [RFC8285] provides relevant guidance for RTP header extension transmission considerations. Alternatively, to avoid this issue, redundancy mechanisms that directly reference its source data may be used, such as [I-D.ietf-payload-flexible-fec-scheme]. Roach (Editor) Expires November 16, 2018 [Page 5] Internet-Draft RTP Restrictions May 2018 The "direction" field identifies the direction of the RTP Stream packets to which the indicated restrictions are applied. It may be either "send" or "recv". Note that these restriction directions are expressed independently of any "inactive", "sendonly", "recvonly", or "sendrecv" attributes associated with the media section. It is, for example, valid to indicate "recv" restrictions on a "sendonly" stream; those restrictions would apply if, at a future point in time, the stream were changed to "sendrecv" or "recvonly". The optional "pt=" lists one or more PT values that can be used in the associated RTP Stream. If the "a=rid" attribute contains no "pt", then any of the PT values specified in the corresponding "m=" line may be used. The list of zero or more codec-agnostic restrictions (Section 5) describe the restrictions that the corresponding RTP Stream will conform to. This framework MAY be used in combination with the "a=fmtp" SDP attribute for describing the media format parameters for a given RTP Payload Type. In such scenarios, the "a=rid" restrictions (Section 5) further restrict the equivalent "a=fmtp" attributes. A given SDP media description MAY have zero or more "a=rid" lines describing various possible RTP payload configurations. A given "rid-id" MUST NOT be repeated in a given media description ("m=" section). The "a=rid" media attribute MAY be used for any RTP-based media transport. It is not defined for other transports, although other documents may extend its semantics for such transports. Though the restrictions specified by the "rid" restrictions follow a syntax similar to session-level and media-level parameters, they are defined independently. All "rid" restrictions MUST be registered with IANA, using the registry defined in Section 12. Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "rid" attribute. The "a=rid" media attribute is not dependent on charset. 5. "a=rid" restrictions This section defines the "a=rid" restrictions that can be used to restrict the RTP payload encoding format in a codec-agnostic way. The following restrictions are intended to apply to video codecs in a codec-independent fashion. Roach (Editor) Expires November 16, 2018 [Page 6] Internet-Draft RTP Restrictions May 2018 o max-width, for spatial resolution in pixels. In the case that stream orientation signaling is used to modify the intended display orientation, this attribute refers to the width of the stream when a rotation of zero degrees is encoded. o max-height, for spatial resolution in pixels. In the case that stream orientation signaling is used to modify the intended display orientation, this attribute refers to the height of the stream when a rotation of zero degrees is encoded. o max-fps, for frame rate in frames per second. For encoders that do not use a fixed framerate for encoding, this value is used to restrict the minimum amount of time between frames: the time between any two consecutive frames SHOULD NOT be less than 1/max- fps seconds. o max-fs, for frame size in pixels per frame. This is the product of frame width and frame height, in pixels, for rectangular frames. o max-br, for bit rate in bits per second. The restriction applies to the media payload only, and does not include overhead introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The exact means of keeping within this limit are left up to the implementation, and instantaneous excursions outside the limit are permissible. For any given one-second sliding window, however, the total number of bits in the payload portion of RTP SHOULD NOT exceed the value specified in "max-br." o max-pps, for pixel rate in pixels per second. This value SHOULD be handled identically to max-fps, after performing the following conversion: max-fps = max-pps / (width * height). If the stream resolution changes, this value is recalculated. Due to this recalculation, excursions outside the specified maximum are possible near resolution change boundaries. o max-bpp, for maximum number of bits per pixel, calculated as an average of all samples of any given coded picture. This is expressed as a floating point value, with an allowed range of 0.0001 to 48.0. These values MUST NOT be encoded with more than four digits to the right of the decimal point. o depend, to identify other streams that the stream depends on. The value is a comma-separated list of rid-ids. These rid-ids identify RTP streams that this stream depends on in order to allow for proper interpretation. The mechanism defined in this document allows for such dependencies to be expressed only when the streams are in the same media section. Roach (Editor) Expires November 16, 2018 [Page 7] Internet-Draft RTP Restrictions May 2018 All the restrictions are optional and are subject to negotiation based on the SDP Offer/Answer rules described in Section 6. This list is intended to be an initial set of restrictions. Future documents may define additional restrictions; see Section 12.2. While this document does not define restrictions for audio codecs or any media types other than video, there is no reason such restrictions should be precluded from definition and registration by other documents. Section 10 provides formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for each of the "a=rid" restrictions defined in this section. 6. SDP Offer/Answer Procedures This section describes the SDP Offer/Answer [RFC3264] procedures when using this framework. Note that "rid-id" values are only required to be unique within a media section ("m-line"); they do not necessarily need to be unique within an entire RTP session. In traditional usage, each media section is sent on its own unique 5-tuple (that is: combination of sending address, sending port, receiving address, receiving port, and transport protocol), which provides an unambiguous scope. Similarly, when using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP streams uniquely to a single media description. When RID is used with the BUNDLE mechanism, streams will be associated with both MID and RID SDES items. 6.1. Generating the Initial SDP Offer For each RTP media description in the offer, the offerer MAY choose to include one or more "a=rid" lines to specify a configuration profile for the given set of RTP Payload Types. In order to construct a given "a=rid" line, the offerer must follow these steps: 1. It MUST generate a "rid-id" that is unique within a media description 2. It MUST set the direction for the "rid-id" to one of "send" or "recv" 3. It MAY include a listing of SDP media formats (usually corresponding to RTP payload types) allowed to appear in the RTP Stream. Any Payload Types chosen MUST be a valid payload type Roach (Editor) Expires November 16, 2018 [Page 8] Internet-Draft RTP Restrictions May 2018 for the media section (that is, it must be listed on the "m=" line). The order of the listed formats is significant; the alternatives are listed from (left) most preferred to (right) least preferred. When using RID, this preference overrides the normal codec preference as expressed by format type ordering on the "m="-line, using regular SDP rules. 4. The Offerer then chooses zero or more "a=rid" restrictions (Section 5) to be applied to the RTP Stream, and adds them to the "a=rid" line. 5. If the offerer wishes the answerer to have the ability to specify a restriction, but does not wish to set a value itself, it includes the name of the restriction in the "a=rid" line, but without any indicated value. Note: If an "a=fmtp" attribute is also used to provide media-format- specific parameters, then the "a=rid" restrictions will further restrict the equivalent "a=fmtp" parameters for the given Payload Type for the specified RTP Stream. If a given codec would require an "a=fmtp" line when used without "a=rid" then the offer MUST include a valid corresponding "a=fmtp" line even when using "a=rid". 6.2. Answerer processing the SDP Offer 6.2.1. "a=rid"-unaware Answerer If the receiver doesn't support the framework defined in this specification, the entire "a=rid" line is ignored following the standard [RFC3264] Offer/Answer rules. Section 6.1 requires the offer to include a valid "a=fmtp" line for any media formats that otherwise require it (in other words, the "a=rid" line cannot be used to replace "a=fmtp" configuration). As a result, ignoring the "a=rid" line is always guaranteed to result in a valid session description. 6.2.2. "a=rid"-aware Answerer If the answerer supports the "a=rid" attribute, the following verification steps are executed, in order, for each "a=rid" line in a received offer: 1. The answerer ensures that the "a=rid" line is syntactically well formed. In the case of a syntax error, the "a=rid" line is discarded. Roach (Editor) Expires November 16, 2018 [Page 9] Internet-Draft RTP Restrictions May 2018 2. The answerer extracts the rid-id from the "a=rid" line and verifies its uniqueness within a media section. In the case of a duplicate, the entire "a=rid" line, and all "a=rid" lines with rid-ids that duplicate this line, are discarded and MUST NOT be included in the SDP Answer. 3. If the "a=rid" line contains a "pt=", the list of payload types is verified against the list of valid payload types for the media section (that is, those listed on the "m=" line). Any PT missing from the "m=" line is discarded from the set of values in the "pt=". If no values are left in the "pt=" parameter after this processing, then the "a=rid" line is discarded. 4. If the "direction" field is "recv", the answerer ensures that the specified "a=rid" restrictions are supported. In the case of an unsupported restriction, the "a=rid" line is discarded. 5. If the "depend" restriction is included, the answerer MUST make sure that the listed rid-ids unambiguously match the rid-ids in the media description. Any "depend" "a=rid" lines that do not are discarded. 6. The answerer verifies that the restrictions are consistent with at least one of the codecs to be used with the RTP Stream. If the "a=rid" line contains a "pt=", it contains the list of such codecs; otherwise, the list of such codecs is taken from the associated "m=" line. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties for all codecs, then the "a=rid" line is discarded. Note that the answerer does not need to understand every restriction present in a "send" line: if a stream sender restricts the stream in a way that the receiver does not understand, this causes no issues with interoperability. 6.3. Generating the SDP Answer Having performed verification of the SDP offer as described in Section 6.2.2, the answerer shall perform the following steps to generate the SDP answer. For each "a=rid" line that has not been discarded by previous processing: 1. The value of the "direction" field is reversed: "send" is changed to "recv", and "recv" is changed to "send". Roach (Editor) Expires November 16, 2018 [Page 10] Internet-Draft RTP Restrictions May 2018 2. The answerer MAY choose to modify specific "a=rid" restriction values in the answer SDP. In such a case, the modified value MUST be more restrictive than the ones specified in the offer. The answer MUST NOT include any restrictions that were not present in the offer. 3. The answerer MUST NOT modify the "rid-id" present in the offer. 4. If the "a=rid" line contains a "pt=", the answerer is allowed to discard one or more media formats from a given "a=rid" line. If the answerer chooses to discard all the media formats from an "a=rid" line, the answerer MUST discard the entire "a=rid" line. If the offer did not contain a "pt=" for a given "a=rid" line, then the answer MUST NOT contain a "pt=" in the corresponding line. 5. In cases where the answerer is unable to support the payload configuration specified in a given "a=rid" line with a direction of "recv" in the offer, the answerer MUST discard the corresponding "a=rid" line. This includes situations in which the answerer does not understand one or more of the restrictions in an "a=rid" line with a direction of "recv". Note: in the case that the answerer uses different PT values to represent a codec than the offerer did, the "a=rid" values in the answer use the PT values that are present in its answer. 6.4. Offerer Processing of the SDP Answer The offerer SHALL follow these steps when processing the answer: 1. The offerer matches the "a=rid" line in the answer to the "a=rid" line in the offer using the "rid-id". If no matching line can be located in the offer, the "a=rid" line is ignored. 2. If the answer contains any restrictions that were not present in the offer, then the offerer SHALL discard the "a=rid" line. 3. If the restrictions have been changed between the offer and the answer, the offerer MUST ensure that the modifications are more restrictive than they were in the original offer, and that they can be supported; if not, the offerer SHALL discard the "a=rid" line. 4. If the "a=rid" line in the answer contains a "pt=" but the offer did not, the offerer SHALL discard the "a=rid" line. Roach (Editor) Expires November 16, 2018 [Page 11] Internet-Draft RTP Restrictions May 2018 5. If the "a=rid" line in the answer contains a "pt=" and the offer did as well, the offerer verifies that the list of payload types is a subset of those sent in the corresponding "a=rid" line in the offer. Note that this matching must be performed semantically rather than on literal PT values, as the remote end may not be using symmetric PTs. For the purpose of this comparison: for each PT listed on the "a=rid" line in the answer, the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" lines in the answer. It then searches the list of "pt=" values indicated in the offer, and attempts to find one with an equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If all PTs in the answer can be matched, then the "pt=" values pass validation; otherwise, it fails. If this validation fails, the offerer SHALL discard the "a=rid" line. Note that this semantic comparison necessarily requires an understanding of the meaning of codec parameters, rather than a rote byte-wise comparison of their values. 6. If the "a=rid" line contains a "pt=", the offerer verifies that the attribute values provided in the "a=rid" attributes are consistent with the corresponding codecs and their other parameters. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties, then the offerer SHALL discard the "a=rid" line. 7. The offerer verifies that the restrictions are consistent with at least one of the codecs to be used with the RTP Stream. If the "a=rid" line contains a "pt=", it contains the list of such codecs; otherwise, the list of such codecs is taken from the associated "m=" line. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties for all codecs, then the offerer SHALL discard the "a=rid" line. Any "a=rid" line present in the offer that was not matched by step 1 above has been discarded by the answerer, and does not form part of the negotiated restrictions on an RTP Stream. The offerer MAY still apply any restrictions it indicated in an "a=rid" line with a direction field of "send", but it is not required to do so. It is important to note that there are several ways in which an offer can contain a media section with "a=rid" lines, but the corresponding media section in the response does not. This includes situations in which the answerer does not support "a=rid" at all, or does not support the indicated restrictions. Under such circumstances, the offerer MUST be prepared to receive a media stream to which no restrictions have been applied. Roach (Editor) Expires November 16, 2018 [Page 12] Internet-Draft RTP Restrictions May 2018 6.5. Modifying the Session Offers and answers inside an existing session follow the rules for initial session negotiation. Such an offer MAY propose a change in the number of RIDs in use. To avoid race conditions with media, any RIDs with proposed changes SHOULD use a new ID, rather than re-using one from the previous offer/answer exchange. RIDs without proposed changes SHOULD re-use the ID from the previous exchange. 7. Use with Declarative SDP This document does not define the use of RID in declarative SDP. If concrete use cases for RID in declarative SDP use are identified in the future, we expect that additional specifications will address such use. 8. Interaction with Other Techniques Historically, a number of other approaches have been defined that allow restricting media streams via SDP. These include: o Codec-specific configuration set via format parameters ("a=fmtp"); for example, the H.264 "max-fs" format parameter [RFC6184] o Size restrictions imposed by image attribute attributes ("a=imageattr") [RFC6236] When the mechanism described in this document is used in conjunction with these other restricting mechanisms, it is intended to impose additional restrictions beyond those communicated in other techniques. In an offer, this means that "a=rid" lines, when combined with other restrictions on the media stream, are expected to result in a non- empty intersection. For example, if image attributes are used to indicate that a PT has a minimum width of 640, then specification of "max-width=320" in an "a=rid" line that is then applied to that PT is nonsensical. According to the rules of Section 6.2.2, this will result in the corresponding "a=rid" line being ignored by the recipient. In an answer, the "a=rid" lines, when combined with the other restrictions on the media stream, are also expected to result in a non-empty intersection. If the implementation generating an answer wishes to restrict a property of the stream below that which would be allowed by other parameters (e.g., those specified in "a=fmtp" or "a=imageattr"), its only recourse is to discard the "a=rid" line altogether, as described in Section 6.3. If it instead attempts to Roach (Editor) Expires November 16, 2018 [Page 13] Internet-Draft RTP Restrictions May 2018 restrict the stream beyond what is allowed by other mechanisms, then the offerer will ignore the corresponding "a=rid" line, as described in Section 6.4. The following subsections demonstrate these interactions using commonly-used video codecs. These descriptions are illustrative of the interaction principles outlined above, and are not normative. 8.1. Interaction with VP8 Format Parameters [RFC7741] defines two format parameters for the VP8 codec. Both correspond to restrictions on receiver capabilities, and never indicate sending restrictions. 8.1.1. max-fr - Maximum Framerate The VP8 "max-fr" format parameter corresponds to the "max-fps" restriction defined in this specification. If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fps" parameter, then the sent stream will conform to the smaller of the two values. 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks The VP8 "max-fs" format parameter corresponds to the "max-fs" restriction defined in this document, by way of a conversion factor of the number of pixels per macroblock (typically 256). If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fs" parameter, then the sent stream will conform to the smaller of the two values; that is, the number of pixels per frame will not exceed: min(rid_max_fs, fmtp_max_fs * macroblock_size) This fmtp parameter also has bearing on the max-height and max-width parameters. Section 6.1 of [RFC7741] requires that the width and height of the frame in macroblocks are also required to be less than int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a transmitted stream will be limited to: min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) Similarly, the stream's height will be limited to: min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) Roach (Editor) Expires November 16, 2018 [Page 14] Internet-Draft RTP Restrictions May 2018 8.2. Interaction with H.264 Format Parameters [RFC6184] defines format parameters for the H.264 video codec. The majority of these parameters do not correspond to codec-independent restrictions: o deint-buf-cap o in-band-parameter-sets o level-asymmetry-allowed o max-rcmd-nalu-size o max-cpb o max-dpb o packetization-mode o redundant-pic-cap o sar-supported o sar-understood o sprop-deint-buf-req o sprop-init-buf-time o sprop-interleaving-depth o sprop-level-parameter-sets o sprop-max-don-diff o sprop-parameter-sets o use-level-src-parameter-sets Note that the max-cpb and max-dpb format parameters for H.264 correspond to restrictions on the stream, but they are specific to the way the H.264 codec operates, and do not have codec-independent equivalents. The [RFC6184] codec format parameters covered in the following sections correspond to restrictions on receiver capabilities, and never indicate sending restrictions. Roach (Editor) Expires November 16, 2018 [Page 15] Internet-Draft RTP Restrictions May 2018 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile These parameters include a "level" indicator, which acts as an index into Table A-1 of [H264]. This table contains a number of parameters, several of which correspond to the restrictions defined in this document. [RFC6184] also defines format parameters for the H.264 codec that may increase the maximum values indicated by the negotiated level. The following sections describe the interaction between these parameters and the restrictions defined by this document. In all cases, the H.264 parameters being discussed are the maximum of those indicated by [H264] Table A-1 and those indicated in the corresponding "a=fmtp" line. 8.2.2. max-br / MaxBR - Maximum Video Bitrate The H.264 "MaxBR" parameter (and its equivalent "max-br" format parameter) corresponds to the "max-bps" restriction defined in this specification, by way of a conversion factor of 1000 or 1200; see [RFC6184] for details regarding which factor gets used under differing circumstances. If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fps" parameter, then the sent stream will conform to the smaller of the two values - that is: min(rid_max_br, h264_MaxBR * conversion_factor) 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks The H.264 "MaxFs" parameter (and its equivalent "max-fs" format parameter) corresponds roughly to the "max-fs" restriction defined in this document, by way of a conversion factor of 256 (the number of pixels per macroblock). If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fs" parameter, then the sent stream will conform to the smaller of the two values - that is: min(rid_max_fs, h264_MaxFs * 256) 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format parameter) corresponds roughly to the "max-pps" restriction defined in this document, by way of a conversion factor of 256 (the number of pixels per macroblock). Roach (Editor) Expires November 16, 2018 [Page 16] Internet-Draft RTP Restrictions May 2018 If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-pps" parameter, then the sent stream will conform to the smaller of the two values - that is: min(rid_max_pps, h264_MaxMBPS * 256) 8.2.5. max-smbps - Maximum Decoded Picture Buffer The H.264 "max-smbps" format parameter operates the same way as the "max-mpbs" format parameter, under the hypothetical assumption that all macroblocks are static macroblocks. It is handled by applying the conversion factor described in Section 8.1 of [RFC6184], and the result of this conversion is applied as described in Section 8.2.4. 8.3. Redundancy Formats and Payload Type Restrictions Section 4 specifies that redundancy formats using redundancy RTP streams bind the redundancy RTP stream to the source RTP stream with either the RepairedRtpStreamId SDES item, or other mechanisms. However, there exist redundancy RTP payload formats that result in the redundancy being included in the source RTP stream. An example of this is "RTP Payload for Redundant Audio Data" [RFC2198], which encapsulates one source stream with one or more redundancy streams in the same RTP payload. Formats defining the source and redundancy encodings as regular RTP payload types require some consideration for how the "a=rid" restrictions are defined. The "a=rid" line "pt=" parameter can be used to indicate whether the redundancy RTP payload type and/or the individual source RTP payload type(s) are part of the restriction. Example (SDP Excerpt): Roach (Editor) Expires November 16, 2018 [Page 17] Internet-Draft RTP Restrictions May 2018 m=audio 49200 RTP/AVP 97 98 99 100 101 102 a=mid:foo a=rtpmap:97 G711/8000 a=rtpmap:98 LPC/8000 a=rtpmap:99 OPUS/48000/1 a=rtpmap:100 RED/8000/1 a=rtpmap:101 CN/8000 a=rtpmap:102 telephone-event/8000 a=fmtp:99 useinbandfec=1; usedtx=0 a=fmtp:100 97/98 a=fmtp:102 0-15 a=ptime:20 a=maxptime:40 a=rid:5 send pt=99,102;max-br=64000 a=rid:6 send pt=100,97,101,102 The RID with ID=6 restricts the payload types for this RID to 100 (the redundancy format), 97 (G.711), 101 (Comfort Noise) and 102 (DTMF tones). This means that RID 6 can either contain the RED format, encapsulating encodings of the source media stream using payload type 97 and 98, 97 without RED encapsulation, Comfort noise, or DTMF tones. Payload type 98 is not included in the RID, and can thus not be sent except as redundancy information in RED encapsulation. If 97 were to be excluded from the pt parameter, it would instead mean that payload types 97 and 98 are only allowed via RED encapsulation. 9. Format Parameters for Future Payloads Registrations of future RTP payload format specifications that define media types that have parameters matching the RID restrictions specified in this memo SHOULD name those parameters in a manner that matches the names of those RID restrictions, and SHOULD explicitly state what media type parameters are restricted by what RID restrictions. 10. Formal Grammar This section gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar, with the case-sensitive extensions described in [RFC7405], for each of the new media and "a=rid" attributes defined in this document. rid-syntax = %s"a=rid:" rid-id SP rid-dir [ rid-pt-param-list / rid-param-list ] rid-id = 1*(alpha-numeric / "-" / "_") Roach (Editor) Expires November 16, 2018 [Page 18] Internet-Draft RTP Restrictions May 2018 alpha-numeric = < as defined in {{RFC4566}} > rid-dir = %s"send" / %s"recv" rid-pt-param-list = SP rid-fmt-list *(";" rid-param) rid-param-list = SP rid-param *(";" rid-param) rid-fmt-list = %s"pt=" fmt *( "," fmt ) fmt = < as defined in {{RFC4566}} > rid-param = rid-width-param / rid-height-param / rid-fps-param / rid-fs-param / rid-br-param / rid-pps-param / rid-bpp-param / rid-depend-param / rid-param-other rid-width-param = %s"max-width" [ "=" int-param-val ] rid-height-param = %s"max-height" [ "=" int-param-val ] rid-fps-param = %s"max-fps" [ "=" int-param-val ] rid-fs-param = %s"max-fs" [ "=" int-param-val ] rid-br-param = %s"max-br" [ "=" int-param-val ] rid-pps-param = %s"max-pps" [ "=" int-param-val ] rid-bpp-param = %s"max-bpp" [ "=" float-param-val ] rid-depend-param = %s"depend=" rid-list rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] rid-list = rid-id *( "," rid-id ) int-param-val = 1*DIGIT float-param-val = 1*DIGIT "." 1*DIGIT param-val = *( %x20-58 / %x60-7E ) ; Any printable character except semicolon Roach (Editor) Expires November 16, 2018 [Page 19] Internet-Draft RTP Restrictions May 2018 11. SDP Examples Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in simulcast scenarios. 11.1. Many Bundled Streams using Many Codecs In this scenario, the offerer supports the Opus, G.722, G.711 and DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a mixer) is supported (send 1 and receive 7 video streams) by offering 7 video media sections (1 sendrecv at max resolution and 6 recvonly at smaller resolutions), all bundled on the same port, using 3 different resolutions. The resolutions include: o 1 receive stream of 720p resolution is offered for the active speaker. o 2 receive streams of 360p resolution are offered for the prior 2 active speakers. o 4 receive streams of 180p resolution are offered for others in the call. NOTE: The SDP given below skips a few lines to keep the example short and focused, as indicated by either the "..." or the comments inserted. The offer for this scenario is shown below. ... m=audio 10000 RTP/SAVPF 96 9 8 0 123 a=rtpmap:96 OPUS/48000 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:123 telephone-event/8000 a=mid:a1 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtpmap:98 VP8/90000 a=fmtp:98 max-fs=3600; max-fr=30 a=rtpmap:99 VP9/90000 a=fmtp:99 max-fs=3600; max-fr=30 a=rtpmap:100 H264/90000 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 a=rtpmap:101 H264/90000 Roach (Editor) Expires November 16, 2018 [Page 20] Internet-Draft RTP Restrictions May 2018 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 a=rtpmap:102 H264/90000 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 a=rtpmap:103 H264/90000 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 a=rtpmap:104 H264-SVC/90000 a=fmtp:104 profile-level-id=530c1f a=rtpmap:105 H264-SVC/90000 a=fmtp:105 profile-level-id=560c1f a=rtpmap:106 H265/90000 a=fmtp:106 profile-id=1; level-id=93 a=rtpmap:107 H265/90000 a=fmtp:107 profile-id=2; level-id=93 a=sendrecv a=mid:v1 (max resolution) a=rid:1 send max-width=1280;max-height=720;max-fps=30 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v2 (medium resolution) a=rid:3 recv max-width=640;max-height=360;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v3 (medium resolution) a=rid:3 recv max-width=640;max-height=360;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v4 (small resolution) a=rid:4 recv max-width=320;max-height=180;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... ... Roach (Editor) Expires November 16, 2018 [Page 21] Internet-Draft RTP Restrictions May 2018 11.2. Scalable Layers Adding scalable layers to a session within a multiparty conference gives a selective forwarding unit (SFU) further flexibility to selectively forward packets from a source that best match the bandwidth and capabilities of diverse receivers. Scalable encodings have dependencies between layers, unlike independent simulcast streams. RIDs can be used to express these dependencies using the "depend" restriction. In the example below, the highest resolution is offered to be sent as 2 scalable temporal layers (using MRST). See [I-D.ietf-mmusic-sdp-simulcast] for additional detail about simulcast usage. Offer: ... m=audio ...same as previous example ... ... m=video ...same as previous example ... ...same rtpmap/fmtp as previous example ... a=sendrecv a=mid:v1 (max resolution) a=rid:0 send max-width=1280;max-height=720;max-fps=15 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 a=rid:5 send max-width=640;max-height=360;max-fps=15 a=rid:6 send max-width=320;max-height=180;max-fps=15 a=simulcast: send rid=0;1;5;6 recv rid=2 ... ...same m=video sections as previous example for mid:v2-v7... ... 12. IANA Considerations This specification updates [RFC4855] to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to RID restrictions. 12.1. New SDP Media-Level attribute This document defines "rid" as SDP media-level attribute. This attribute must be registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (media level only)". The "rid" attribute is used to identify properties of RTP stream with in an RTP Session. Its format is defined in Section 10. The formal registration information for this attribute follows. Roach (Editor) Expires November 16, 2018 [Page 22] Internet-Draft RTP Restrictions May 2018 Contact name, email address, and telephone number IETF MMUSIC Working Group mmusic@ietf.org +1 510 492 4080 Attribute name (as it will appear in SDP) rid Long-form attribute name in English Restriction Identifier Type of attribute (session level, media level, or both) Media Level Whether the attribute value is subject to the charset attribute The attribute is not dependent on charset. A one-paragraph explanation of the purpose of the attribute The "rid" SDP attribute is used to to unambiguously identify the RTP Streams within an RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. A specification of appropriate attribute values for this attribute Valid values are defined by the ABNF in [RFCXXXXX] Multiplexing (Mux) Category SPECIAL 12.2. Registry for RID-Level Parameters This specification creates a new IANA registry named "rid attribute parameters" within the SDP parameters registry. The "a=rid" restrictions MUST be registered with IANA and documented under the same rules as for SDP session-level and media-level attributes as specified in [RFC4566]. Parameters for "a=rid" lines that modify the nature of encoded media MUST be of the form that the result of applying the modification to the stream results in a stream that still complies with the other Roach (Editor) Expires November 16, 2018 [Page 23] Internet-Draft RTP Restrictions May 2018 parameters that affect the media. In other words, restrictions always have to restrict the definition to be a subset of what is otherwise allowable, and never expand it. New restriction registrations are accepted according to the "Specification Required" policy of [RFC5226]. The registration MUST contain the RID parameter name and a reference to the corresponding specification. The specification itself must contain the following information (not all of which appears in the registry): o restriction name (as it will appear in SDP) o an explanation of the purpose of the restriction o a specification of appropriate attribute values for this restriction o an ABNF definition of the restriction The initial set of "a=rid" restriction names, with definitions in Section 5 of this document, is given below: RID Parameter Name Reference ------------------ --------- max-width [RFCXXXX] max-height [RFCXXXX] max-fps [RFCXXXX] max-fs [RFCXXXX] max-br [RFCXXXX] max-pps [RFCXXXX] max-bpp [RFCXXXX] depend [RFCXXXX] It is conceivable that a future document wants to define a RID-level restrictions that contain string values. These extensions need to take care to conform to the ABNF defined for rid-param-other. In particular, this means that such extensions will need to define escaping mechanisms if they want to allow semicolons, unprintable characters, or byte values greater than 127 in the string. 13. Security Considerations As with most SDP parameters, a failure to provide integrity protection over the "a=rid" attributes provides attackers a way to modify the session in potentially unwanted ways. This could result in an implementation sending greater amounts of data than a recipient Roach (Editor) Expires November 16, 2018 [Page 24] Internet-Draft RTP Restrictions May 2018 wishes to receive. In general, however, since the "a=rid" attribute can only restrict a stream to be a subset of what is otherwise allowable, modification of the value cannot result in a stream that is of higher bandwidth than would be sent to an implementation that does not support this mechanism. The actual identifiers used for RIDs are expected to be opaque. As such, they are not expected to contain information that would be sensitive, were it observed by third-parties. 14. Acknowledgements Many thanks to review from Cullen Jennings, Magnus Westerlund, and Paul Kyzivat. Thanks to Colin Perkins for input on future payload type handing. 15. References 15.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (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, . [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, . [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, . Roach (Editor) Expires November 16, 2018 [Page 25] Internet-Draft RTP Restrictions May 2018 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References [H264] ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services (V9)", February 2014, . [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-51 (work in progress), May 2018. [I-D.ietf-mmusic-sdp-simulcast] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", draft-ietf- mmusic-sdp-simulcast-12 (work in progress), April 2018. [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in progress), March 2018. [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, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . Roach (Editor) Expires November 16, 2018 [Page 26] Internet-Draft RTP Restrictions May 2018 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ RFC6184, 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, . [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, . [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . Appendix A. Contributors The following individuals have contributed significant text to this document. Roach (Editor) Expires November 16, 2018 [Page 27] Internet-Draft RTP Restrictions May 2018 Peter Thatcher Google Email: pthatcher@google.com Mo Zanaty Cisco Systems Email: mzanaty@cisco.com Suhas Nandakumar Cisco Systems Email: snandaku@cisco.com Bo Burman Ericsson Email: bo.burman@ericsson.com Byron Campen Mozilla Email: bcampen@mozilla.com Author's Address Adam Roach Mozilla Email: adam@nostrum.com Roach (Editor) Expires November 16, 2018 [Page 28] ./draft-ietf-rtcweb-rtp-usage-26.txt0000644000764400076440000036701212672545755016606 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-mmusic-sctp-sdp-26.txt0000644000764400076440000015300113076144361016415 0ustar iustyiusty MMUSIC C. Holmberg Internet-Draft Ericsson Intended status: Standards Track R. Shpount Expires: October 22, 2017 TurboBridge S. Loreto G. Camarillo Ericsson April 20, 2017 Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. draft-ietf-mmusic-sctp-sdp-26 Abstract The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. 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 22, 2017. Holmberg, et al. Expires October 22, 2017 [Page 1] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 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 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. SCTP Terminology . . . . . . . . . . . . . . . . . . . . . . 4 4. SDP Media Descriptions . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Protocol Identifiers . . . . . . . . . . . . . . . . . . 5 4.3. Media Format Management . . . . . . . . . . . . . . . . . 5 4.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 4.4.2. SDP Media Description values . . . . . . . . . . . . 6 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 7 6. SDP 'max-message-size' Attribute . . . . . . . . . . . . . . 8 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 9 7. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 9 8. TCP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 10 9. Association And Connection Management . . . . . . . . . . . . 10 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute . . . . 10 9.3. SCTP Association . . . . . . . . . . . . . . . . . . . . 10 9.4. DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP) . . . 11 9.5. TCP Connection (TCP/DTLS/SCTP) . . . . . . . . . . . . . 12 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Generating the Initial SDP Offer . . . . . . . . . . . . 13 10.3. Generating the SDP Answer . . . . . . . . . . . . . . . 13 Holmberg, et al. Expires October 22, 2017 [Page 2] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 10.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 10.5. Modifying the Session . . . . . . . . . . . . . . . . . 15 11. Multihoming Considerations . . . . . . . . . . . . . . . . . 16 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 16 12.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 16 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 17 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15.1. New SDP proto values . . . . . . . . . . . . . . . . . . 19 15.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 15.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 19 15.2.2. max-message-size . . . . . . . . . . . . . . . . . . 19 15.3. association-usage Name Registry . . . . . . . . . . . . 19 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 18.1. Normative References . . . . . . . . . . . . . . . . . . 23 18.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction SDP (Session Description Protocol) [RFC4566] provides a general- purpose format for describing multimedia sessions in announcements or invitations. TCP-Based Media Transport in the Session Description Protocol (SDP) [RFC4145] specifies a general mechanism for describing and establishing TCP [RFC0793] streams. Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in SDP [RFC8122] extends RFC4145 [RFC4145] for describing TCP-based media streams that are protected using TLS. The Stream Control Transmission Protocol (SCTP) [RFC4960] is a reliable transport protocol used to transport data between two endpoints using SCTP associations. [I-D.ietf-tsvwg-sctp-dtls-encaps] specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) [RFC4566] protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism [RFC3264] for negotiating SCTP-over-DTLS associations. Holmberg, et al. Expires October 22, 2017 [Page 3] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: Due to the characteristics of TCP, while multiple SCTP streams can still be used, usage of 'TCP/DTLS/SCTP' will always force ordered and reliable delivery of the SCTP packets, which limits the usage of the SCTP options. Therefore, it is RECOMMENDED that TCP is only used in situations where UDP traffic is blocked. 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. SCTP Terminology SCTP Association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. SCTP Stream: A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. SCTP-over-DTLS: SCTP used on top of DTLS, as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. 4. SDP Media Descriptions 4.1. General This section defines the following new SDP Media Description (m- line) protocol identifiers (proto values) for describing an SCTP association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section also describes how an m- line, associated with the proto values, is created. The following is the format for an m- line, as specified in RFC4566 [RFC4566]: m= ... The 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are similar to both the 'UDP' and 'TCP' proto values in that they only describe the transport-layer protocol and not the upper-layer protocol. Holmberg, et al. Expires October 22, 2017 [Page 4] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are used, the underlying transport protocol is respectively UDP and TCP; SCTP is carried on top of DTLS which is on top of those transport- layer protocols. 4.2. Protocol Identifiers The new proto values are defined as below: o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on top of a DTLS association on top of UDP, as defined in Section 7. o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on top of a DTLS association on top of TCP, as defined in Section 8. 4.3. Media Format Management [RFC4566] defines that specifications defining new proto values must define the rules by which their media format (fmt) namespace is managed. An m- line with a proto value of 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP' always describes a single SCTP association. In addition, such m- line MUST further indicate the application-layer protocol using an 'fmt' identifier. There MUST be exactly one fmt value per m- line associated with the proto values defined in this specification. The 'fmt' namespace associated with those proto values describes the generic application usage of the entire SCTP association, including the associated SCTP streams. When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- line fmt value, identifying the application-layer protocol, MUST be registered by IANA. Section 15.3 defines the IANA registry for the media format namespace. NOTE: A mechanism on how to describe, and manage, individual SCTP streams within an SCTP association, is outside the scope of this specification. [I-D.ietf-mmusic-data-channel-sdpneg] defines a mechanism for negotiating individual SCTP streams used to realize WebRTC data channels [I-D.ietf-rtcweb-data-channel]. 4.4. Syntax Holmberg, et al. Expires October 22, 2017 [Page 5] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 4.4.1. General This section defines the values that can be used within an SDP media description ("m=" line) associated with an SCTP-over-DTLS association. This specification creates an IANA registry for 'association-usage' values. 4.4.2. SDP Media Description values m= line parameter parameter value(s) ------------------------------------------------------------------ : 'application' : 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP' : UDP port number (for 'UDP/DTLS/SCTP') TCP port number (for 'TCP/DTLS/SCTP') : a string denoting the association-usage, limited to the syntax of a 'token' as defined in RFC4566. 4.5. Example m=application 12345 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port:5000 a=max-message-size:100000 NOTE: 'webrtc-datachannel' indicates the WebRTC Data Channel Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol]. 5. SDP 'sctp-port' Attribute 5.1. General This section defines a new SDP media-level attribute, 'sctp-port'. The attribute can be associated with an SDP media description (m- line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value. In that case the m- line port value indicates the port of the underlying transport layer protocol (UDP or TCP), and the 'sctp-port' value indicates the SCTP port. No default value is defined for the SDP sctp-port attribute. Therefore, if the attribute is not present, the associated m- line MUST be considered invalid. Holmberg, et al. Expires October 22, 2017 [Page 6] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: This specification only defines the usage of the SDP 'sctp- port' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. 5.2. Syntax [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] The definition of the SDP 'sctp-port' attribute is: Attribute name: sctp-port Type of attribute: media Mux category: CAUTION Subject to charset: No Purpose: Indicate the SCTP port value associated with the SDP Media Description. Appropriate values: Integer Contact name: Christer Holmberg Contact e-mail: christer.holmberg@ericsson.com Reference: RFCXXXX Syntax: sctp-port-value = 1*5 The SCTP port range is between 0 and 65535 (both included). Leading zeroes MUST NOT be used. Example: a=sctp-port:5000 5.3. Mux Category The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the SDP 'sctp-port' attribute is CAUTION. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. Future extensions, that define how to negotiate multiplexing of multiple SCTP associations of top of a single DTLS association, need to also define the mux rules for the attribute. Holmberg, et al. Expires October 22, 2017 [Page 7] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 6. SDP 'max-message-size' Attribute 6.1. General This section defines a new SDP media-level attribute, 'max-message- size'. The attribute can be associated with an m- line to indicate the maximum SCTP user message size (indicated in bytes) that an SCTP endpoint is willing to receive on the SCTP association associated with the m- line. Different attribute values can be used in each direction. An SCTP endpoint MUST NOT send a SCTP user message with a message size that is larger than the maximum size indicated by the peer, as it cannot be assumed that the peer would accept such message. If the SDP 'max-message-size' attribute contains a maximum message size value of zero, it indicates the SCTP endpoint will handle messages of any size, subject to memory capacity etc. If the SDP 'max-message-size' attribute is not present, the default value is 64K. NOTE: This specification only defines the usage of the SDP 'max- message-size' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. 6.2. Syntax [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] The definition of the SDP 'max-message-size' attribute is: Holmberg, et al. Expires October 22, 2017 [Page 8] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 Attribute name: max-message-size Type of attribute: media Mux category: CAUTION Subject to charset: No Purpose: Indicate the maximum message size (indicated in bytes) that an SCTP endpoint is willing to receive on the SCTP association associated with the SDP Media Description. Appropriate values: Integer Contact name: Christer Holmberg Contact e-mail: christer.holmberg@ericsson.com Reference: RFCXXXX Syntax: max-message-size-value = 1* Leading zeroes MUST NOT be used. Example: a=max-message-size:100000 6.3. Mux Category The mux category for the SDP 'max-message-size' attribute is CAUTION. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. 7. UDP/DTLS/SCTP Transport Realization The UDP/DTLS/SCTP transport is realized as described below: o SCTP on top of DTLS is realized according to the procedures defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and o DTLS on top of UDP is realized according to the procedures in defined in [RFC6347]. NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support the negotiation of a single SCTP association on top of any given DTLS association. Holmberg, et al. Expires October 22, 2017 [Page 9] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 8. TCP/DTLS/SCTP Transport Realization The TCP/DTLS/SCTP transport is realized as described below: o SCTP on top of DTLS is realized according to the procedures defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and o DTLS on top of TCP is realized using the framing method defined in [RFC4571], with DTLS packets being sent and received instead of RTP/RTCP packets using the shim defined in [RFC4571], so that length field defined in [RFC4571] precedes each DTLS message, and SDP signaling according to the procedures defined in this specification. NOTE: TLS on top of TCP, without using the framing method defined in [RFC4571] is outside the scope of this specification. A separate proto value would need to be registered for such transport realization. 9. Association And Connection Management 9.1. General This section describes how to manage an SCTP association, DTLS association and TCP connection using SDP attributes. The SCTP association, the DTLS association and the TCP connection are managed independently from each other. Each can be established and closed without impacting others. The detailed SDP Offer/Answer [RFC3264] procedures for the SDP attributes are described in Section 10. 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute This specification does not define semantics for the SDP direction attributes [RFC4566]. Unless semantics of these attributes for an SCTP association usage have been defined, SDP direction attributes MUST be ignored if present. 9.3. SCTP Association When an SCTP association is established, both SCTP endpoints MUST initiate the SCTP association (i.e. both SCTP endpoints take the 'active' role), and MUST use the same SCTP port as client port and server port (in order to prevent two separate SCTP associations from being established). Holmberg, et al. Expires October 22, 2017 [Page 10] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 As both SCTP endpoints take the 'active' role, the SDP 'setup' attribute [RFC4145] does not apply to SCTP association establishment. However the 'setup' attribute does apply to establishment of the underlying DTLS association and TCP connection. NOTE: The procedure above is different from TCP, where one endpoint takes the 'active' role, the other endpoint takes the 'passive' role, and only the 'active' endpoint initiates the TCP connection [RFC4145]. NOTE: When the SCTP association is established it is assumed that any NAT traversal procedures for the underlying transport protocol (UDP or TCP) have successfully been performed. The SDP 'connection' attribute [RFC4145] does not apply to the SCTP association. In order to trigger the closure of an existing SCTP association, and establishment of a new SCTP association, the SDP 'sctp-port' attribute [Section 5] is used to indicate a new (different than the ones currently used) SCTP port. The existing SCTP association is closed, and the new SCTP association is established, if one or both endpoints signal a new SCTP port. The 'connection' attribute does apply to establishment of underlying TCP connections. Alternatively, an SCTP association can be closed using the SDP 'sctp- port' attribute with a zero attribute value. Later, a new SCTP association can be established using the procedures in this section for establishing an SCTP association. SCTP associations might be closed without SDP signalling, e.g, in case of a failure. The procedures in this section MUST be followed to establish a new SCTP association. This requires a new SDP Offer/ Answer exchange. New (different than the ones currently used) SCTP ports MUST be used by both endpoints. NOTE: Closing and establishing a new SCTP association using the SDP 'sctp-port' attribute will not affect the state of the underlying DTLS association. 9.4. DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP) A DTLS association is managed according to the procedures in [I-D.ietf-mmusic-dtls-sdp]. Hence, the SDP 'setup' attribute is used to negotiate the (D)TLS roles ('client' and 'server') [RFC8122]. NOTE: The SDP 'setup' attribute is used to negotiate both the DTLS roles and the TCP roles (Section 9.5). Holmberg, et al. Expires October 22, 2017 [Page 11] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: As described in [RFC5245], if the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] is used, all ICE candidates associated with a DTLS association are considered part of the same DTLS association. Thus, a switch from one candidate pair to another candidate pair will not trigger the establishment of a new DTLS association. 9.5. TCP Connection (TCP/DTLS/SCTP) The TCP connection is managed according to the procedures in [RFC4145]. Hence, the SDP 'setup' attribute is used to negotiate the TCP roles ('active' and 'passive'), and the SDP 'connection' attribute is used to indicate whether to use an existing TCP connection, or create a new one. The SDP 'setup' attribute 'holdconn' value MUST NOT be used. NOTE: A change of the TCP roles will also trigger a closure of the DTLS association, and establishment of a new DTLS association, according to the procedures in [I-D.ietf-mmusic-dtls-sdp]. NOTE: As specified in [I-D.ietf-mmusic-dtls-sdp], usage of the SDP 'setup' attribute 'holdconn' value is not allowed. Therefore this specification also forbids usage of the attribute value for TCP, as DTLS is transported on top of TCP. 10. SDP Offer/Answer Procedures 10.1. General This section defines the SDP Offer/Answer [RFC3264] procedures for negotiating and establishing an SCTP-over-DTLS association. Unless explicitly stated, the procedures apply to both the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' m- line proto values. Each endpoint MUST associate one or more certificate fingerprints, using the SDP 'fingerprint' attribute with the m- line, following the procedures in [RFC8122]. The authentication certificates are interpreted and validated as defined in [RFC8122]. Self-signed certificates can be used securely, provided that the integrity of the SDP description is assured as defined in [RFC8122]. Each endpoint MUST associate an SDP 'tls-id' attribute with the m- line, following the procedures in [I-D.ietf-mmusic-dtls-sdp]. Holmberg, et al. Expires October 22, 2017 [Page 12] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 10.2. Generating the Initial SDP Offer When the offerer creates an initial offer, the offerer: o MUST associate an SDP setup attribute with the m- line; o MUST associate an SDP 'sctp-port' attribute with the m- line; o MUST, in the case of TCP/DTLS/SCTP, associate an SDP 'connection' attribute, with a 'new' attribute value, with the m- line; and o MAY associate an SDP 'max-message-size' attribute [Section 6] with the m- line. 10.3. Generating the SDP Answer When the answerer receives an offer, which contains an m- line describing an SCTP-over-DTLS association, if the answerer accepts the association, the answerer: o MUST insert a corresponding m- line in the answer, with an m- line proto value [RFC3264] identical to the value in the offer; o MUST associate an SDP 'setup' attribute with the m- line; o MUST associate an SDP 'sctp-port' attribute with the m- line. If the offer contained a new (different than the one currently used) SCTP port value the answerer MUST also associate a new SCTP port value. If the offer contained a zero SCTP port value, or if the answerer does not accept the SCTP association, the answerer MUST also associate a zero SCTP port value; and o MAY associate an SDP 'max-message-size' attribute [Section 6] with the m- line. The attribute value in the answer is independent from the value (if present) in the corresponding m- line of the offer. Once the answerer has sent the answer the answerer: o MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been established, or if an existing TCP connection is to be closed and replaced by a new TCP connection, follow the procedures in [RFC4145] for closing and establishing a TCP connection; o MUST, if a DTLS association has not yet been established, or if an existing DTLS association is to be closed and replaced by a new DTLS association, follow the procedures in Holmberg, et al. Expires October 22, 2017 [Page 13] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 [I-D.ietf-mmusic-dtls-sdp] for closing the currently used, and establishing a new, DTLS association; and o MUST, if an SCTP association has not yet been established, or if an existing SCTP association is to be closed and replaced by a new SCTP association, initiate the closing of the existing SCTP association (if applicable) and establishment of the SCTP association. If the SDP 'sctp-port' attribute in the answer contains a zero attribute value, the answerer MUST NOT establish an SCTP association. If an SCTP association exists, the offerer MUST close it. If the answerer does not accept the m- line in the offer, it MUST assign a zero port value to the corresponding m- line in the answer, following the procedures in [RFC3264]. In addition, the answerer MUST NOT initiate the establishment of a TCP connection, a DTLS association or a DTLS association associated with the m- line. 10.4. Offerer Processing of the SDP Answer Once the offerer has received the answer the offerer: o MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been established, or if an existing TCP connection is to be closed and replaced by a new TCP connection, follow the procedures in [RFC4145] for closing and establishing a TCP connection; o MUST, if a DTLS association has not yet been established, or if an existing DTLS association is to be closed and replaced by a new DTLS association, follow the procedures in [I-D.ietf-mmusic-dtls-sdp] for closing and establishing a DTLS association; and o MUST, if an SCTP association has not yet been established, or if an existing SCTP association is to be closed and replaced by a new SCTP association, initiate the closing of the existing SCTP association (if applicable) and establishment of the SCTP association. If the SDP 'sctp-port' attribute in the answer contains a zero attribute value, the offerer MUST NOT establish an SCTP association. If an SCTP association exists in that case, the offerer MUST close it. If the m- line in the answer contains a zero port value, the offerer MUST NOT initiate the establishment a TCP connection, a DTLS association or an SCTP association associated with the m- line. If a Holmberg, et al. Expires October 22, 2017 [Page 14] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 TCP connection, or a DTLS association or an SCTP association exists in that case, the offerer MUST close it. 10.5. Modifying the Session When an offerer sends an updated offer, in order to modify a previously established SCTP association, it follows the procedures in Section 10.2, with the following exceptions: o If the offerer wants to close an SCTP association, and immediately establish a new SCTP association, the offerer MUST associate an SDP 'sctp-port' attribute with a new (different than the one currently used) attribute value. This will not impact the underlying DTLS association (and TCP connection in case of TCP/DTLS/SCTP). o If the offerer wants to close an SCTP association, without immediately establishing a new SCTP association, the offerer MUST associate an SDP 'sctp-port' attribute with a zero attribute value. This will not impact the underlying DTLS association (and TCP connection in case of TCP/DTLS/SCTP). o If the offerer wants to establish an SCTP association, and another SCTP association was previously closed, the offerer MUST associate an SDP 'sctp-port' attribute with a new attribute value (different than the value associated with the previous SCTP association). If the previous SCTP association was closed successfully following use of an SDP 'sctp-port' attribute with a zero attribute value, the offerer MAY use the same attribute value for the new SCTP association that was used with the previous SCTP association before it was closed. This will not impact the underlying DTLS association (and TCP connection in case of TCP/DTLS/SCTP). o If the offerer wants to close an existing SCTP association, and the underlying DTLS association (and the underlying TCP connection in case of TCP/DTLS/SCTP) it MUST assign a zero port value to the m- line associated with the SCTP and DTLS associations (and TCP connection in case of TCP/DTLS/SCTP), following the procedures in [RFC3264]. o NOTE: This specification does not define a mechanism for explicitly closing a DTLS association while maintaining the overlying SCTP association. However, if a DTLS association is closed and replaced with a new DTLS association, as a result of some other action [I-D.ietf-mmusic-dtls-sdp], the state of the SCTP association is not affected. Holmberg, et al. Expires October 22, 2017 [Page 15] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 The offer follows the procedures in [I-D.ietf-mmusic-dtls-sdp] regarding the DTLS association impacts when modifying a session. In the case of TCP/DTLS/SCTP, the offerer follows the procedures in [RFC4145] regarding the TCP connection impacts when modifying a session. 11. Multihoming Considerations Multihoming is not supported when sending SCTP on top of DTLS, as DTLS does not expose address management of the underlying transport protocols (UDP or TCP) to its upper layer. 12. NAT Considerations 12.1. General When SCTP-over-DTLS is used in NAT environment, it relies on the NAT traversal procedures for the underlying transport protocol (UDP or TCP). 12.2. ICE Considerations When SCTP-over-DTLS is used with UDP based ICE candidates [RFC5245] then the procedures for UDP/DTLS/SCTP [Section 7] are used. When SCTP-over-DTLS is used with TCP based ICE candidates [RFC6544] then the procedures for TCP/DTLS/SCTP [Section 8] are used. In ICE environments, during the nomination process, endpoints go through multiple ICE candidate pairs, until the most preferred candidate pair is found. During the nomination process, data can be sent as soon as the first working candidate pair is found, but the nomination process still continues and selected candidate pairs can still change while data is sent. Furthermore, if endpoints roam between networks, for instance when mobile endpoint switches from mobile connection to WiFi, endpoints will initiate an ICE restart, which will trigger a new nomination process between the new set of candidates and likely result in the new nominated candidate pair. Implementations MUST treat all ICE candidate pairs associated with an SCTP association on top of a DTLS association as part of the same DTLS association. Thus, there will only be one SCTP handshake and one DTLS handshake even if there are multiple valid candidate pairs, and shifting from one candidate pair to another, including switching between UDP to TCP candidate pairs, will not impact the SCTP or DTLS associations. If new candidates are added, they will also be part of the same SCTP and DTLS associations. When transitioning between Holmberg, et al. Expires October 22, 2017 [Page 16] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 candidate pairs, different candidate pairs can be currently active in different directions and implementations MUST be ready to receive data on any of the candidates, even if this means sending and receiving data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time in different directions. In order to maximize the likelihood of interoperability between the endpoints, all ICE enabled SCTP-over-DTLS endpoints SHOULD implement support for UDP/DTLS/SCTP. When an SDP offer or answer is sent with multiple ICE candidates during initial connection negotiation or after ICE restart, UDP based candidates SHOULD be included and default candidate SHOULD be chosen from one of those UDP candidates. The proto value MUST match the transport protocol associated with the default candidate. If UDP transport is used for the default candidate, then 'UDP/DTLS/SCTP' proto value MUST be used. If TCP transport is used for the default candidate, then 'TCP/DTLS/SCTP' proto value MUST be used. Note that under normal circumstances the proto value for offers and answers sent during ICE nomination SHOULD be 'UDP/DTLS/SCTP'. When a subsequent SDP offer or answer is sent after ICE nomination is complete, and does not initiate ICE restart, it will contain only the nominated ICE candidate pair. In this case, the proto value MUST match the transport protocol associated with the nominated ICE candidate pair. If UDP transport is used for the nominated pair, then 'UDP/DTLS/SCTP' proto value MUST be used. If TCP transport is used for the nominated pair, then 'TCP/DTLS/SCTP' proto value MUST be used. Please note that if an endpoint switches between TCP-based and UDP-based candidates during the nomination process the endpoint is not required to send an SDP offer for the sole purpose of keeping the proto value of the associated m- line in sync. NOTE: The text in the paragraph above only applies when the usage of ICE has been negotiated. If ICE is not used, the proto value MUST always reflect the transport protocol used at any given time. 13. Examples 13.1. Establishment of UDP/DTLS/SCTP association Holmberg, et al. Expires October 22, 2017 [Page 17] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 SDP Offer: m=application 54111 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:DB8::A8FD a=tls-id:abc3de65cddef001be82 a=setup:actpass a=sctp-port:5000 a=max-message-size:100000 - The offerer indicates that the usage of the UDP/DTLS/SCTP association will be as defined for the 'webrtc-datachannel' format value. - The offerer UDP port value is 54111. - The offerer SCTP port value is 5000. - The offerer indicates that it can take either the client or the server DTLS role. SDP Answer: m=application 64300 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:DB8::001D a=tls-id:dbc8de77cddef001be90 a=setup:passive a=sctp-port:6000 a=max-message-size:100000 - The answerer UDP port value is 64300. - The answerer SCTP port value is 6000. - The answerer takes the server DTLS role. 14. Security Considerations [RFC4566] defines general SDP security considerations, while [RFC3264], [RFC4145] and [RFC8122] define security considerations when using the SDP offer/answer mechanism to negotiate media streams. [RFC4960] defines general SCTP security considerations and [I-D.ietf-tsvwg-sctp-dtls-encaps] defines security considerations when using SCTP on top of DTLS. This specification does not introduce new security considerations in addition to those defined in the specifications listed above. Holmberg, et al. Expires October 22, 2017 [Page 18] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 15. IANA Considerations 15.1. New SDP proto values [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document updates the "Session Description Protocol (SDP) Parameters" registry, following the procedures in [RFC4566], by adding the following values to the table in the SDP "proto" field registry: +-------+---------------+-----------+ | Type | SDP Name | Reference | +-------+---------------+-----------+ | proto | UDP/DTLS/SCTP | [RFCXXXX] | | proto | TCP/DTLS/SCTP | [RFCXXXX] | +-------+---------------+-----------+ Table 1: SDP "proto" field values 15.2. New SDP Attributes 15.2.1. sctp-port This document defines a new SDP media-level attribute,'sctp-port'. The details of the attribute are defined in Section 5.2. 15.2.2. max-message-size This document defines a new SDP media-level attribute,'max-message- size'. The details of the attribute are defined in Section 6.2. 15.3. association-usage Name Registry [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This specification creates a new IANA registry, following the procedures in [RFC5226], for the namespace associated with the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol identifiers. Each fmt value describes the usage of an entire SCTP association, including all SCTP streams associated with the SCTP association. NOTE: Usage indication of individual SCTP streams is outside the scope of this specification. Holmberg, et al. Expires October 22, 2017 [Page 19] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 The fmt value, "association-usage", used with these "proto" values is required. It is defined in Section 4. As part of this registry, IANA maintains the following information: association-usage name: The identifier of the subprotocol, as will be used as the fmt value. association-usage reference: A reference to the document in which the association-usage is defined. association-usage names are to be subject to the "First Come First Served" IANA registration policy [RFC5226]. IANA is asked to add initial values to the registry. |----------------------------------------------------------| | name | Reference | |----------------------------------------------------------| | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx, | | | RFCXXX | |----------------------------------------------------------| [RFC EDITOR NOTE: Please hold the publication of this draft until draft-ietf-rtcweb-data-protocol has been published as an RFC. Then, replace the reference to draft-ietf-rtcweb-data-protocol with the RFC number.] [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] Figure 1 16. Acknowledgments The authors wish to thank Harald Alvestrand, Randell Jesup, Paul Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen and Ari Keranen for their comments and useful feedback. Ben Campbell provided comments as part of his AD review. Brian Carpenter performed the Gen-ART review. 17. [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-sctp-sdp-25 Holmberg, et al. Expires October 22, 2017 [Page 20] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 o SDP 'dtls-id' attribute re-named to 'tls-id'. Changes from draft-ietf-mmusic-sctp-sdp-24 o Minor editorial fix by Roman. Changes from draft-ietf-mmusic-sctp-sdp-23 o Changes based on IESG review. o - Proto value clarifications. Changes from draft-ietf-mmusic-sctp-sdp-22 o Changes based on Gen-ART review by Brian Carpenter. Changes from draft-ietf-mmusic-sctp-sdp-21 o Changes based on AD review by Ben Campbell. Changes from draft-ietf-mmusic-sctp-sdp-20 o Informative reference to draft-ietf-rtcweb-data-protocol added. Changes from draft-ietf-mmusic-sctp-sdp-19 o Changes based on WG chair comments from Flemming Andreasen. Changes from draft-ietf-mmusic-sctp-sdp-18 o Changes based on WGLC comments from Paul Kyzivat. Changes from draft-ietf-mmusic-sctp-sdp-17 o Removal of 'SCTP'. o Document title changed. o Disallow usage of SDP 'setup' attribute 'holdconn' value. o Roman Shpount added as co-editor. Changes from draft-ietf-mmusic-sctp-sdp-15 o Chapter about SCTP, DTLS and TCP association/connection management modified. o Removal of SCTP/DTLS. Holmberg, et al. Expires October 22, 2017 [Page 21] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 Changes from draft-ietf-mmusic-sctp-sdp-14 o Changes based on WGLC comments from Magnus Westerlund. o - ABNF clarification that token and port are defined in RFC4566. o - Specify 40 as maximum digit character length for the SDP max- message-size value. o - Editorial clarification. o Changes based on discussions at IETF#92. o - Specify that all ICE candidate pairs belong to the same DTLS association. Changes from draft-ietf-mmusic-sctp-sdp-13 o Changes based on comments from Paul Kyzivat. o - Text preventing usage of well-known ports removed. o - Editorial clarification. Changes from draft-ietf-mmusic-sctp-sdp-12 o Mux category rules added for new SDP attributes. o Reference to draft-ietf-mmusic-sdp-mux-attributes added. o Changes based on comments from Roman Shpount: o - Specify that fingerprint or setup roles must not be modified, unless underlying transport protocol is also modified. o Changes based on comments from Ari Keranen: o - Editorial corrections. o Changes based on comments from Flemming Andreasen: o - Clarify that, if UDP/DTLS/SCTP or TCP/DTLS/SCTP is used, the DTLS association is established before the SCTP association. o - Clarify that max-message-size value is given in bytes, and that different values can be used per direction. o - Section on fmtp attribute removed. Holmberg, et al. Expires October 22, 2017 [Page 22] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 o - Editorial corrections. Changes from draft-ietf-mmusic-sctp-sdp-11 o Example added. Changes from draft-ietf-mmusic-sctp-sdp-10 o SDP max-message-size attribute added to IANA considerations. o Changes based on comments from Paul Kyzivat: o - Text about max message size removed from fmtp attribute section. Changes from draft-ietf-mmusic-sctp-sdp-09 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP transports added. Changes from draft-ietf-mmusic-sctp-sdp-08 o Default SCTP port removed: o - Usage of SDP sctp-port attribute mandatory. o SDP max-message-size attribute defined: o - Attribute definition. o - SDP Offer/Answer procedures. o Text about SDP direction attributes added. o Text about TLS role determination added. 18. References 18.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . Holmberg, et al. Expires October 22, 2017 [Page 23] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 [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, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 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, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . Holmberg, et al. Expires October 22, 2017 [Page 24] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 [I-D.ietf-mmusic-dtls-sdp] Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-24 (work in progress), April 2017. [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-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 2016. 18.2. Informative References [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, . [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-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., and J. Marcon, "SDP-based Data Channel Negotiation", draft-ietf-mmusic-data-channel-sdpneg-12 (work in progress), March 2017. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg, et al. Expires October 22, 2017 [Page 25] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 Roman Shpount TurboBridge 4905 Del Ray Avenue, Suite 300 Bethesda, MD 20814 USA Phone: +1 (240) 292-6632 Email: rshpount@turbobridge.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Salvatore.Loreto@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Holmberg, et al. Expires October 22, 2017 [Page 26] ./draft-ietf-pce-stateful-path-protection-11.txt0000644000764400076440000011257213543030425021073 0ustar iustyiusty PCE Working Group H. Ananthakrishnan Internet-Draft Netflix Intended status: Standards Track S. Sivabalan Expires: March 28, 2020 Cisco C. Barth Juniper Networks I. Minei Google, Inc M. Negi Huawei Technologies September 25, 2019 PCEP Extensions for Associating Working and Protection LSPs with Stateful PCE draft-ietf-pce-stateful-path-protection-11 Abstract An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection. 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 https://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 28, 2020. Ananthakrishnan, et al. Expires March 28, 2020 [Page 1] Internet-Draft Stateful PCE LSP Path Protection September 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Path Protection Association Type . . . . . . . . . . . . 5 3.2. Path Protection Association TLV . . . . . . . . . . . . . 6 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7 4.2. PCC-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 4.3. PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 8 4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 10 6.2. Path Protection Association TLV . . . . . . . . . . . . . 10 6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 8.1. Control of Function and Policy . . . . . . . . . . . . . 12 8.2. Information and Data Models . . . . . . . . . . . . . . . 12 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 8.6. Impact On Network Operations . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Ananthakrishnan, et al. Expires March 28, 2020 [Page 2] Internet-Draft Stateful PCE LSP Path Protection September 2019 1. Introduction [RFC5440] describes Path Computation Element Communication Protocol for communication between a Path Computation Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655]. A PCE computes paths for MPLS-TE Label Switched Paths (LSPs) based on various constraints and optimization criteria. Stateful PCE [RFC8231] specifies a set of extensions to PCEP to enable stateful control of paths such as MPLS-TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to affect LSP state synchronization between PCCs and PCEs, delegation of control of LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The focus is on a model where LSPs are configured on the PCC and control over them is delegated to the Stateful PCE. Furthermore, [RFC8281] specifies a mechanism to dynamically instantiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE. Path protection [RFC4427] refers to a paradigm in which the working LSP is protected by one or more protection LSP(s). When the working LSP fails, protection LSP(s) is/are activated. When the working LSPs are computed and controlled by the PCE, there is benefit in a mode of operation where protection LSPs are also computed and controlled by the same PCE. [RFC8051] describes applicability of path protection in PCE deployments. This document specifies a stateful PCEP extension to associate two or more LSPs for the purpose of setting up path protection. The extension defined in this document covers the following scenarios: o A PCC initiates a protection LSP and retains the control of the LSP. The PCC computes the path itself or makes a request for path computation to a PCE. After the path setup, it reports the information and state of the path to the PCE. This includes the association group identifying the working and protection LSPs. This is the passive stateful mode [RFC8051]. o A PCC initiates a protection LSP and delegates the control of the LSP to a stateful PCE. During delegation the association group identifying the working and protection LSPs is included. The PCE computes the path for the protection LSP and updates the PCC with the information about the path as long as it controls the LSP. This is the active stateful mode [RFC8051]. o A protection LSP could be initiated by a stateful PCE, which retains the control of the LSP. The PCE is responsible for Ananthakrishnan, et al. Expires March 28, 2020 [Page 3] Internet-Draft Stateful PCE LSP Path Protection September 2019 computing the path of the LSP and updating to the PCC with the information about the path. This is the PCE-Initiated mode [RFC8281]. Note that a protection LSP can be established (signaled) before the failure (in which case the LSP is said to be in standby mode [RFC4427] or a Primary LSP [RFC4872]) or after failure of the corresponding working LSP (known as a secondary LSP [RFC4872]). Whether to establish it before or after failure is according to operator choice or policy. [I-D.ietf-pce-association-group] introduces a generic mechanism to create a grouping of LSPs, which can then be used to define associations between a set of LSPs. The mechanism is equally applicable to stateful PCE (active and passive modes) and stateless PCE. This document specifies a PCEP extension to associate one working LSP with one or more protection LSPs using the generic association mechanism. This document describes a PCEP extension to associate protection LSPs by creating Path Protection Association Group (PPAG) and encoding this association in PCEP messages for stateful PCEP sessions. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology The following terminologies are used in this document: ERO: Explicit Route Object. LSP: Label Switched Path. PCC: Path Computation Client. PCE: Path Computation Element PCEP: Path Computation Element Communication Protocol. PPAG: Path Protection Association Group. Ananthakrishnan, et al. Expires March 28, 2020 [Page 4] Internet-Draft Stateful PCE LSP Path Protection September 2019 TLV: Type, Length, and Value. 3. PCEP Extensions 3.1. Path Protection Association Type As per [I-D.ietf-pce-association-group], LSPs are not associated by listing the other LSPs with which they interact, but rather by making them belong to an association groups. All LSPs join an association group individually. The generic ASSOCIATION object is used to associate two or more LSPs as specified in [I-D.ietf-pce-association-group]. This document defines a new Association type called "Path Protection Association Type" of value TBD1 and a "Path Protection Association Group" (PPAG). A member LSP of a PPAG can take the role of working or protection LSP. A PPAG can have one working LSP and/or one or more protection LSPs. The source, destination, Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], with description as per [RFC3209]), and Protection Type (PT) (in Path Protection Association TLV) of all LSPs within a PPAG MUST be the same. As per [RFC3209], TE tunnel is used to associate a set of LSPs during reroute or to spread a traffic trunk over multiple paths. The format of the Association object used for PPAG is specified in [I-D.ietf-pce-association-group]. [I-D.ietf-pce-association-group] specifies the mechanism for the capability advertisement of the Association types supported by a PCEP speaker by defining a ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the Association type described in this document (i.e. Path Protection Association Type) MAY be done before using this association, i.e., the PCEP speaker MAY include the Path Protection Association Type (TBD1) in the ASSOC- Type-List TLV before using the PPAG in the PCEP messages. This Association type is dynamic in nature and created by the PCC or PCE for the LSPs belonging to the same TE tunnel (as described in [RFC3209]) originating at the same head node and terminating at the same destination. These associations are conveyed via PCEP messages to the PCEP peer. As per [I-D.ietf-pce-association-group], the association source is set to the local PCEP speaker address that created the association, unless local policy dictates otherwise. Operator-configured Association Range MUST NOT be set for this Association type and MUST be ignored. Ananthakrishnan, et al. Expires March 28, 2020 [Page 5] Internet-Draft Stateful PCE LSP Path Protection September 2019 3.2. Path Protection Association TLV The Path Protection Association TLV is an optional TLV for use in the ASSOCIATION Object with the Path Protection Association Type. The Path Protection Association TLV MUST NOT be present more than once. If it appears more than once, only the first occurrence is processed and any others MUST be ignored. The Path Protection Association TLV follows the PCEP TLV format of [RFC5440]. The type (16 bits) of the TLV is TBD2. The length field (16 bit) has a fixed value of 4. The value comprises of a single field, the Path Protection Association Flags (32 bits), where each bit represents a flag option. The format of the Path Protection Association TLV (Figure 1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD2 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PT | Unassigned Flags |S|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Path Protection Association TLV format Path Protection Association Flags (32 bits) - The following flags are currently defined - Protecting (P): 1 bit - This bit is as defined in Section 14.1 of [RFC4872] to indicate if the LSP is a working (0) or protection (1) LSP. Secondary (S): 1 bit - This bit is as defined in Section 14.1 of [RFC4872] to indicate if the LSP is a primary (0) or secondary (1) LSP. The S flag is ignored if the P flag is not set. Protection Type (PT): 6 bits - This field is as defined in Section 14.1 of [RFC4872] to indicate the LSP protection type in use. Any type already defined or that could be defined in the future for use in the RSVP-TE PROTECTION object is acceptable in this TLV unless explicitly stated otherwise. Ananthakrishnan, et al. Expires March 28, 2020 [Page 6] Internet-Draft Stateful PCE LSP Path Protection September 2019 Unassigned bits are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt. If the TLV is missing in PPAG ASSOCIATION object, it is considered that the LSP is a working LSP (i.e. as if the P bit is unset). 4. Operation An LSP is associated with other LSPs with which it interacts by adding them to a common association group via the ASSOCIATION object. All procedures and error-handling for the ASSOCIATION object is as per [I-D.ietf-pce-association-group]. 4.1. State Synchronization During state synchronization, a PCC reports all the existing LSP states as described in [RFC8231]. The association group membership pertaining to an LSP is also reported as per [I-D.ietf-pce-association-group]. This includes PPAGs. 4.2. PCC-Initiated LSPs A PCC can associate a set of LSPs under its control for path protection purposes. Similarly, the PCC can remove one or more LSPs under its control from the corresponding PPAG. In both cases, the PCC reports the change in association to PCE(s) via Path Computation Report (PCRpt) messages. A PCC can also delegate the working and protection LSPs to an active stateful PCE, where the PCE would control the LSPs. The stateful PCE could update the paths and attributes of the LSPs in the association group via Path Computation Update (PCUpd) message. A PCE could also update the association to the PCC via PCUpd message. These procedures are described in [I-D.ietf-pce-association-group]. It is expected that both working and protection LSPs are delegated together (and to the same PCE) to avoid any race conditions. Refer to [I-D.litkowski-pce-state-sync] for the problem description. 4.3. PCE-Initiated LSPs A PCE can create/update working and protection LSPs independently. As specified in [I-D.ietf-pce-association-group], Association Groups can be created by both the PCE and the PCC. Further, a PCE can remove a protection LSP from a PPAG as specified in [I-D.ietf-pce-association-group]. The PCE uses PCUpd or Path Computation Initiate (PCInitiate) messages to communicate the association information to the PCC. Ananthakrishnan, et al. Expires March 28, 2020 [Page 7] Internet-Draft Stateful PCE LSP Path Protection September 2019 4.4. Session Termination As per [I-D.ietf-pce-association-group] the association information is cleared along with the LSP state information. When a PCEP session is terminated, after expiry of State Timeout Interval at the PCC, the LSP state associated with that PCEP session is reverted to operator- defined default parameters or behaviors as per [RFC8231]. The same procedure is also followed for the association information. On session termination at the PCE, when the LSP state reported by PCC is cleared, the association information is also cleared as per [I-D.ietf-pce-association-group]. Where there are no LSPs in a association group, the association is considered to be deleted. 4.5. Error Handling As per the processing rules specified in section 6.4 of [I-D.ietf-pce-association-group], if a PCEP speaker does not support this Path Protection Association Type, it would return a PCErr message with Error-Type 26 "Association Error" and Error-Value 1 "Association type is not supported". All LSPs (working or protection) within a PPAG MUST belong to the same TE Tunnel (as described in [RFC3209]) and have the same source and destination. If a PCEP speaker attempts to add or update an LSP to a PPAG and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], with description as per [RFC3209]) or source or destination of the LSP is different from the LSP(s) in the PPAG, the PCEP speaker MUST send PCErr with Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] and Error-Value TBD3 (Tunnel ID or End points mismatch for Path Protection Association). In case of Path Protection, LSP-IDENTIFIERS TLV SHOULD be included for all LSPs (including Segment Routing (SR) [I-D.ietf-pce-segment-routing]). If the Protection Type (PT) (in Path Protection Association TLV) is different from the LSPs in the PPAG, the PCEP speaker MUST send PCErr with Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] and Error-Value 6 (Association information mismatch) as per [I-D.ietf-pce-association-group]. When the PCEP peer does not support the protection type set in PPAG, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] and Error-Value TBD5 (Protection type is not supported). A given LSP MAY belong to more than one PPAG. If there is a conflict between any of the two PPAGs, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] and Error-Value 6 (Association information mismatch) as per [I-D.ietf-pce-association-group]. Ananthakrishnan, et al. Expires March 28, 2020 [Page 8] Internet-Draft Stateful PCE LSP Path Protection September 2019 When the protection type is set to 1+1 (i.e., protection type=0x08 or 0x10), there MUST be at maximum, only one working LSP and one protection LSP within a PPAG. If a PCEP speaker attempts to add another working/protection LSP, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add another working/protection LSP for Path Protection Association). When the protection type is set to 1:N (i.e., protection type=0x04), there MUST be at maximum, only one working LSP and number of protection LSPs MUST NOT be more than N within a PPAG. If a PCEP speaker attempts to add another working/protection LSP, the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add another working/protection LSP for Path Protection Association). During the make-before-break (MBB) procedure, two paths will briefly coexist. The error handling related to number of LSPs allowed in a PPAG MUST NOT be applied during MBB. All processing as per [I-D.ietf-pce-association-group] continues to apply. 5. Other Considerations The working and protection LSPs are typically resource disjoint (e.g., node, SRLG disjoint). This ensures that a single failure will not affect both the working and protection LSPs. The disjoint requirement for a group of LSPs is handled via another Association type called "Disjointness Association", as described in [I-D.ietf-pce-association-diversity]. The diversity requirements for the protection LSP are also handled by including both ASSOCIATION objects identifying both the protection association group and the disjoint association group for the group of LSPs. The relationship between the Synchronization VECtor (SVEC) object and the Disjointness Association is described in section 5.3 of [I-D.ietf-pce-association-diversity]. [RFC4872] introduces the concept and mechanisms to support the association of one LSP to another LSP across different RSVP Traffic Engineering (RSVP-TE) sessions using ASSOCIATION and PROTECTION object. The information in the Path Protection Association TLV in PCEP as received from the PCE is used to trigger the signaling of working LSP and protection LSP, with the Path Protection Association Flags mapped to the corresponding fields in the PROTECTION Object in RSVP-TE. Ananthakrishnan, et al. Expires March 28, 2020 [Page 9] Internet-Draft Stateful PCE LSP Path Protection September 2019 6. IANA Considerations [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" through "TBD5" those should be replaced by the values that IANA assigns.] 6.1. Association Type This document defines a new Association type, originally defined in [I-D.ietf-pce-association-group], for path protection. IANA is requested to make the assignment of a new value for the sub-registry "ASSOCIATION Type Field" (request to be created in [I-D.ietf-pce-association-group]), as follows: +----------------------+-------------------------+------------------+ | Association type | Association Name | Reference | | Value | | | +----------------------+-------------------------+------------------+ | TBD1 | Path Protection | This | | | Association | document | +----------------------+-------------------------+------------------+ 6.2. Path Protection Association TLV This document defines a new TLV for carrying additional information of LSPs within a path protection association group. IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows: +---------------+-----------------------------------+---------------+ | TLV Type | TLV Name | Reference | | Value | | | +---------------+-----------------------------------+---------------+ | TBD2 | Path Protection Association Group | This document | | | TLV | | +---------------+-----------------------------------+---------------+ This document requests that a new sub-registry, named "Path protection Association Group TLV Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the Path Protection Association Group TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (count from 0 as the most significant bit) o Name flag Ananthakrishnan, et al. Expires March 28, 2020 [Page 10] Internet-Draft Stateful PCE LSP Path Protection September 2019 o Reference +------------+-----------------------+----------------+ | Bit Number | Name | Reference | +------------+-----------------------+----------------+ | 31 | P - PROTECTION-LSP | This document | | 30 | S - SECONDARY-LSP | This document | | 6-29 | Unassigned | This document | | 0-5 | Protection Type Flags | This document | +------------+-----------------------+----------------+ Table 1: Path Protection Association TLV Flag Field 6.3. PCEP Errors This document defines new Error-Values related to path protection association for Error-type 26 "Association Error" defined in [I-D.ietf-pce-association-group]. IANA is requested to allocate new error values within the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows: +---------+----------+-----------------+----------------------------+ | Error- | Error- | Meaning | Reference | | type | value | | | +---------+----------+-----------------+----------------------------+ | 26 | | Association | [I-D.ietf-pce-association- | | | | Error | group] | | | | | | | | TBD3 | Tunnel ID or | This document | | | | End points | | | | | mismatch for | | | | | Path Protection | | | | | Association | | | | TBD4 | Attempt to add | This document | | | | another working | | | | | /protection LSP | | | | | for Path | | | | | Protection | | | | | Association | | | | TBD5 | Protection type | This document | | | | is not | | | | | supported | | +---------+----------+-----------------+----------------------------+ Ananthakrishnan, et al. Expires March 28, 2020 [Page 11] Internet-Draft Stateful PCE LSP Path Protection September 2019 7. Security Considerations The security considerations described in [RFC8231], [RFC8281], and [RFC5440] apply to the extensions described in this document as well. Additional considerations related to associations where a malicious PCEP speaker could be spoofed and could be used as an attack vector by creating associations as described in [I-D.ietf-pce-association-group]. Adding a spurious protection LSP to the Path Protection Association group could give false sense of network reliability, which leads to issues when the working LSP is down and the protection LSP fails as well. Thus securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in BCP 195 [RFC7525], is RECOMMENDED. 8. Manageability Considerations 8.1. Control of Function and Policy Mechanisms defined in this document do not imply any control or policy requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281]. 8.2. Information and Data Models [RFC7420] describes the PCEP MIB, there are no new MIB Objects for this document. The PCEP YANG module [I-D.ietf-pce-pcep-yang] supports associations. 8.3. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281]. 8.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281]. 8.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. Ananthakrishnan, et al. Expires March 28, 2020 [Page 12] Internet-Draft Stateful PCE LSP Path Protection September 2019 8.6. Impact On Network Operations Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440], [RFC8231], and [RFC8281]. 9. Acknowledgments We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky for their contributions to this document. Thanks to Ines Robles for the RTGDIR review. Thanks to Pete Resnick for the GENART review. Thanks to Donald Eastlake for the SECDIR review. Thanks to Barry Leiba, Benjamin Kaduk, Eric Vyncke, and Roman Danyliw for the IESG review. 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, . [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, . [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . Ananthakrishnan, et al. Expires March 28, 2020 [Page 13] Internet-Draft Stateful PCE LSP Path Protection September 2019 [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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [I-D.ietf-pce-association-group] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships Between Sets of Label Switched Paths (LSPs)", draft-ietf-pce-association-group-10 (work in progress), August 2019. 10.2. Informative References [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, . Ananthakrishnan, et al. Expires March 28, 2020 [Page 14] Internet-Draft Stateful PCE LSP Path Protection September 2019 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . [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, . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep- yang-12 (work in progress), July 2019. [I-D.ietf-pce-association-diversity] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, "Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling", draft- ietf-pce-association-diversity-10 (work in progress), August 2019. [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-16 (work in progress), March 2019. [I-D.litkowski-pce-state-sync] Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Stateful Path Computation Element (PCE) Communication Procedures.", draft-litkowski-pce-state-sync-06 (work in progress), July 2019. Ananthakrishnan, et al. Expires March 28, 2020 [Page 15] Internet-Draft Stateful PCE LSP Path Protection September 2019 Appendix A. Contributor Addresses Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Raveendra Torvi Juniper Networks 1194 N Mathilda Ave, Sunnyvale, CA, 94086 USA EMail: rtorvi@juniper.net Edward Crabbe Individual Contributor EMail: edward.crabbe@gmail.com Authors' Addresses Hariharan Ananthakrishnan Netflix USA Email: hari@netflix.com Siva Sivabalan Cisco 2000 Innovation Drive Kananta, Ontaria K2K 3E8 Canada Email: msiva@cisco.com Ananthakrishnan, et al. Expires March 28, 2020 [Page 16] Internet-Draft Stateful PCE LSP Path Protection September 2019 Colby Barth Juniper Networks 1194 N Mathilda Ave, Sunnyvale, CA, 94086 USA Email: cbarth@juniper.net Ina Minei Google, Inc 1600 Amphitheatre Parkway Mountain View, CA, 94043 USA Email: inaminei@google.com Mahendra Singh Negi Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: mahend.ietf@gmail.com Ananthakrishnan, et al. Expires March 28, 2020 [Page 17] ./draft-ietf-mmusic-sdp-bundle-negotiation-54.txt0000644000764400076440000043254113405035207021237 0ustar iustyiusty MMUSIC Working Group C. Holmberg Internet-Draft Ericsson Updates: 3264,5888,7941 (if approved) H. Alvestrand Intended status: Standards Track Google Expires: June 18, 2019 C. Jennings Cisco December 15, 2018 Negotiating Media Multiplexing Using the Session Description Protocol (SDP) draft-ietf-mmusic-sdp-bundle-negotiation-54.txt Abstract This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification updates RFC 3264, to also allow assigning a zero port value to a "m=" section in cases where the media described by the "m=" section is not disabled or rejected. This specification updates RFC 5888, to also allow an SDP 'group' attribute to contain an identification-tag that identifies a "m=" section with the port set to zero. This specification defines a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that can be used to correlate bundled RTP/RTCP packets with their appropriate "m=" section. This specification updates RFC 7941, by adding an exception, for the MID RTP header extension, to the requirement regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Holmberg, et al. Expires June 18, 2019 [Page 1] Internet-Draft Bundled media December 2018 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, 2019. Copyright Notice Copyright (c) 2018 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. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 Holmberg, et al. Expires June 18, 2019 [Page 2] Internet-Draft Bundled media December 2018 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 10 7.1.1. Connection Data (c=) . . . . . . . . . . . . . . . . 10 7.1.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 11 7.1.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 11 7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12 7.2.1. Suggesting the Offerer tagged 'm=' section . . . . . 13 7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 13 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14 7.3.1. Answerer Selection of tagged 'm=' sections . . . . . 16 7.3.2. Moving A Media Description Out Of A BUNDLE Group . . 16 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 17 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 18 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19 7.5.1. Adding a Media Description to a BUNDLE group . . . . 20 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 9.2. Associating RTP/RTCP Streams with the Correct SDP Media Description . . . . . . . . . . . . . . . . . . . . . . . 24 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 30 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 36 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 36 14.2. New text replacing section 9.2 (3rd paragraph) of RFC 5888 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 15. RTP/RTCP extensions for identification-tag transport . . . . 36 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 38 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38 Holmberg, et al. Expires June 18, 2019 [Page 3] Internet-Draft Bundled media December 2018 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 39 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 40 17. Security Considerations . . . . . . . . . . . . . . . . . . . 40 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 18.1. Example: Tagged m= Section Selections . . . . . . . . . 41 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 43 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 18.5. Example: Offerer Disables a Media Description Within a BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 21.1. Normative References . . . . . . . . . . . . . . . . . . 61 21.2. Informative References . . . . . . . . . . . . . . . . . 64 Appendix A. Design Considerations . . . . . . . . . . . . . . . 65 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 65 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 1. Introduction 1.1. Background When the SDP offer/answer mechanism [RFC3264] is used to negotiate the establishment of multimedia communication sessions, if separate transports (5-tuples) are negotiated for each individual media stream, each transport consumes additional resources (especially when Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is attractive to use a single transport for multiple media streams. 1.2. BUNDLE Mechanism This specification defines a way to use a single transport (BUNDLE transport) for sending and receiving media (bundled media) described by multiple SDP media descriptions ("m=" sections). The address:port combination used by an endpoint for sending and receiving bundled media is referred to as the BUNDLE address:port. The set of SDP attributes that are applied to each "m=" section within a BUNDLE group is referred to as BUNDLE attributes. The same BUNDLE transport Holmberg, et al. Expires June 18, 2019 [Page 4] Internet-Draft Bundled media December 2018 is used for sending and receiving bundled media, which means that the symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is always used for RTP-based bundled media. This specification defines a new SDP Grouping Framework [RFC5888] extension called 'BUNDLE'. The extension can be used with the Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate which "m=" sections will become part of a BUNDLE group. In addition, the offerer and answerer [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE address:port and answerer BUNDLE address:port) and the set of BUNDLE attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) that will be applied to each "m=" section within the BUNDLE group. The use of a BUNDLE transport allows the usage of a single set of Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. A given BUNDLE address:port MUST only be associated with a single BUNDLE group. If an SDP offer or answer contains multiple BUNDLE groups, the procedures in this specification apply to each group independently. All RTP-based bundled media associated with a given BUNDLE group belong to a single RTP session [RFC3550]. The BUNDLE extension is backward compatible. Endpoints that do not support the extension are expected to generate offers and answers without an SDP 'group:BUNDLE' attribute, and are expected to assign a unique address:port to each "m=" section within an offer and answer, according to the procedures in [RFC4566] and [RFC3264]. 1.3. Protocol Extensions In addition to defining the new SDP Grouping Framework extension, this specification defines the following protocol extensions and RFC updates: o The specification defines a new SDP attribute, 'bundle-only', which can be used to request that a specific "m=" section (and the associated media) is used only used if kept within a BUNDLE group. o The specification updates RFC 3264 [RFC3264], to also allow assigning a zero port value to a "m=" section in cases where the media described by the "m=" section is not disabled or rejected. o The specification defines a new RTP Control Protocol (RTCP) [RFC3550] source description (SDES) item, 'MID', and a new RTP SDES header extension that can be used to associate RTP streams with "m=" sections. Holmberg, et al. Expires June 18, 2019 [Page 5] Internet-Draft Bundled media December 2018 o The specification updates [RFC7941], by adding an exception, for the MID RTP header extension, to the requirement regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension. 2. Terminology o "m=" section: SDP bodies contain one or more media descriptions, referred to as "m=" sections. Each "m=" section is represented by an SDP "m=" line, and zero or more SDP attributes associated with the "m=" line. A local address:port combination is assigned to each "m=" section. o 5-tuple: A collection of the following values: source address, source port, destination address, destination port, and transport- layer protocol. o Unique address:port: An address:port combination that is assigned to only one "m=" section in an offer or answer. o Offerer BUNDLE-tag: The first identification-tag in a given SDP 'group:BUNDLE' attribute identification-tag list in an offer. o Answerer BUNDLE-tag: The first identification-tag in a given SDP 'group:BUNDLE' attribute identification-tag list in an answer. o Suggested offerer tagged "m=" section: The bundled "m=" section identified by the offerer BUNDLE-tag in an initial BUNDLE offer, before a BUNDLE group has been negotiated. o Offerer tagged "m=" section: The bundled "m=" section identified by the offerer BUNDLE-tag in a subsequent offer. The "m=" section contains characteristics (offerer BUNDLE address:port and offerer BUNDLE attributes) applied to each "m=" section within the BUNDLE group. o Answerer tagged "m=" section: The bundled "m=" section identified by the answerer BUNDLE-tag in an answer (initial BUNDLE answer or subsequent). The "m=" section contains characteristics (answerer BUNDLE address:port and answerer BUNDLE attributes) applied to each "m=" section within the BUNDLE group. o BUNDLE address:port: An address:port combination that an endpoint uses for sending and receiving bundled media. o Offerer BUNDLE address:port: the address:port combination used by the offerer for sending and receiving media. Holmberg, et al. Expires June 18, 2019 [Page 6] Internet-Draft Bundled media December 2018 o Answerer BUNDLE address:port: the address:port combination used by the answerer for sending and receiving media. o BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes. Once a BUNDLE group has been created, the attribute values apply to each bundled "m=" section within the BUNDLE group. o Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the offerer tagged "m=" section. o Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the answerer tagged "m=" section. o BUNDLE transport: The transport (5-tuple) used by all media described by the "m=" sections within a BUNDLE group. o BUNDLE group: A set of bundled "m=" sections, created using an SDP Offer/Answer exchange, which uses a single BUNDLE transport, and a single set of BUNDLE attributes, for sending and receiving all media (bundled media) described by the set of "m=" sections. The same BUNDLE transport is used for sending and receiving bundled media. o Bundled "m=" section: An "m=" section, whose identification-tag is placed in an SDP 'group:BUNDLE' attribute identification-tag list in an offer or answer. o Bundle-only "m=" section: A bundled "m=" section that contains an SDP 'bundle-only' attribute. o Bundled media: All media associated with a given BUNDLE group. o Initial BUNDLE offer: The first offer, within an SDP session (e.g. a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer indicates that it wants to negotiate a given BUNDLE group. o Initial BUNDLE answer: The answer to an initial BUNDLE offer in which the offerer indicates that it wants to negotiate a BUNDLE group, and where the answerer accepts the creation of the BUNDLE group. The BUNDLE group is created once the answerer sends the initial BUNDLE answer. o Subsequent offer: An offer which contains a BUNDLE group that has been created as part of a previous offer/answer exchange. Holmberg, et al. Expires June 18, 2019 [Page 7] Internet-Draft Bundled media December 2018 o Subsequent answer: An answer to a subsequent offer. o Identification-tag: A unique token value that is used to identify an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section carries the unique identification-tag assigned to that "m=" section. The session-level SDP 'group' attribute [RFC5888] carries a list of identification-tags, identifying the "m=" sections associated with that particular 'group' attribute. 3. Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Applicability Statement The mechanism in this specification only applies to the Session Description Protocol (SDP) [RFC4566], when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope of this document, and is thus undefined. 5. SDP Grouping Framework BUNDLE Extension This section defines a new SDP Grouping Framework [RFC5888] extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP Offer/Answer mechanism to negotiate a set of "m=" sections that will become part of a BUNDLE group. Within a BUNDLE group, each "m=" section uses a BUNDLE transport for sending and receiving bundled media. Each endpoint uses a single address:port combination for sending and receiving the bundled media. The BUNDLE extension is indicated using an SDP 'group' attribute with a semantics value [RFC5888] of "BUNDLE". An identification-tag is assigned to each bundled "m=" section, and each identification-tag is listed in the SDP 'group:BUNDLE' attribute identification-tag list. Each "m=" section whose identification-tag is listed in the identification-tag list is associated with a given BUNDLE group. SDP bodies can contain multiple BUNDLE groups. Any given bundled "m=" section MUST NOT be associated with more than one BUNDLE group at any given time. NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' attribute identification-tag list does not have to be the same as the order in which the "m=" sections occur in the SDP. Holmberg, et al. Expires June 18, 2019 [Page 8] Internet-Draft Bundled media December 2018 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'group:BUNDLE' attribute is 'NORMAL'. Section 7 defines the detailed SDP Offer/Answer procedures for the BUNDLE extension. 6. SDP 'bundle-only' Attribute This section defines a new SDP media-level attribute [RFC4566], 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and hence has no value. In order to ensure that an answerer that does not support the BUNDLE extension always rejects a bundled "m=" section in an offer, the offerer can assign a zero port value to the "m=" section. According to [RFC3264] an answerer will reject such an "m=" section. By including an SDP 'bundle-only' attribute in a bundled "m=" section, the offerer can request that the answerer accepts the "m=" section only if the answerer supports the BUNDLE extension, and if the answerer keeps the "m=" section within the associated BUNDLE group. Name: bundle-only Value: N/A Usage Level: media Charset Dependent: no Example: a=bundle-only Once the offerer tagged "m=" section and the answerer tagged "m=" section have been selected, an offerer and answerer will include an SDP 'bundle-only' attribute in, and assign a zero port value to, every other bundled "m=" section. The usage of the 'bundle-only' attribute is only defined for a bundled "m=" section with a zero port value. Other usage is unspecified. Section 7 defines the detailed SDP Offer/Answer procedures for the 'bundle-only' attribute. Holmberg, et al. Expires June 18, 2019 [Page 9] Internet-Draft Bundled media December 2018 7. SDP Offer/Answer Procedures This section describes the SDP Offer/Answer [RFC3264] procedures for: o Negotiating a BUNDLE group; and o Suggesting and selecting the tagged "m=" sections (offerer tagged "m=" section and answerer tagged "m=" section); and o Adding an "m=" section to a BUNDLE group; and o Moving an "m=" section out of a BUNDLE group; and o Disabling an "m=" section within a BUNDLE group. The generic rules and procedures defined in [RFC3264] and [RFC5888] also apply to the BUNDLE extension. For example, if an offer is rejected by the answerer, the previously negotiated addresses:ports, SDP parameters and characteristics (including those associated with a BUNDLE group) apply. Hence, if an offerer generates an offer in order to negotiate a BUNDLE group, and the answerer rejects the offer, the BUNDLE group is not created. The procedures in this section are independent of the media type or "m=" line proto value assigned to a bundled "m=" section. Section 9 defines additional considerations for RTP based media. Section 6 defines additional considerations for the usage of the SDP 'bundle- only' attribute. Section 10 defines additional considerations for the usage of Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] mechanism. Offers and answers can contain multiple BUNDLE groups. The procedures in this section apply independently to a given BUNDLE group. 7.1. Generic SDP Considerations This section describes generic restrictions associated with the usage of SDP parameters within a BUNDLE group. It also describes how to calculate a value for the whole BUNDLE group, when parameter and attribute values have been assigned to each bundled "m=" section. 7.1.1. Connection Data (c=) The "c=" line nettype value [RFC4566] associated with a bundled "m=" section MUST be 'IN'. Holmberg, et al. Expires June 18, 2019 [Page 10] Internet-Draft Bundled media December 2018 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" section MUST be 'IP4' or 'IP6'. The same value MUST be associated with each "m=" section. NOTE: Extensions to this specification can specify usage of the BUNDLE mechanism for other nettype and addrtype values than the ones listed above. 7.1.2. Bandwidth (b=) An offerer and answerer MUST use the rules and restrictions defined in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP bandwidth (b=) line with bundled "m=" sections. 7.1.3. Attributes (a=) An offerer and answerer MUST include SDP attributes in every bundled "m=" section where applicable, following the normal offer/answer procedures for each attribute, with the following exceptions: o In the initial BUNDLE offer, the offerer MUST NOT include IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) in bundle-only "m=" sections. The offerer MUST include such attributes in all other bundled "m=" sections. In the initial BUNDLE offer each bundled "m=" line can contain a different set of BUNDLE attributes, and attribute values. Once the offerer tagged "m=" section has been selected, the BUNDLE attributes contained in the offerer tagged "m=" section will apply to each bundled "m=" section within the BUNDLE group. o In a subsequent offer, or in an answer (initial of subsequent), the offerer and answerer MUST include IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) only in the tagged "m=" section (offerer tagged "m=" section or answerer tagged "m=" section). The offerer and answerer MUST NOT include such attributes in any other bundled "m=" section. The BUNDLE attributes contained in the tagged "m=" section will apply to each bundled "m=" section within the BUNDLE group. o In an offer (initial BUNDLE offer or subsequent), or in an answer (initial BUNDLE answer or subsequent), the offerer and answerer MUST include SDP attributes of other categories than IDENTICAL and TRANSPORT in each bundled "m=" section that a given attribute applies to. Each bundled "m=" line can contain a different set of such attributes, and attribute values, as such attributes only apply to the given bundled "m=" section in which they are included. Holmberg, et al. Expires June 18, 2019 [Page 11] Internet-Draft Bundled media December 2018 NOTE: A consequence of the rules above is that media-specific IDENTICAL and TRANSPORT multiplexing category SDP attributes which are applicable only to some of the bundled "m=" sections within the BUNDLE group might appear in the tagged "m=" section for which they are not applicable. For instance, the tagged "m=" section might contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section does not describe RTP-based media (but another bundled "m=" section within the BUNDLE group does describe RTP-based media). 7.2. Generating the Initial SDP Offer The procedures in this section apply to the first offer, within an SDP session (e.g. a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer indicates that it wants to negotiate a given BUNDLE group. This could occur in the initial offer, or in a subsequent offer, of the SDP session. When an offerer generates an initial BUNDLE offer, in order to negotiate a BUNDLE group, it MUST: o Assign a unique address:port to each bundled "m=" section, following the procedures in [RFC3264], excluding any bundle-only "m=" sections (see below); and o Pick a bundled "m=" section as the suggested offerer tagged "m=" section [Section 7.2.1]; and o Include SDP attributes in the bundled "m=" sections following the rules in [Section 7.1.3]; and o Include an SDP 'group:BUNDLE' attribute in the offer; and o Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the suggested offerer tagged "m=" section. NOTE: When the offerer assigns unique addresses:ports to multiple bundled "m=" sections, the offerer needs to be prepared to receive bundled media on each unique address:port, until it receives the associated answer and finds out which bundled "m=" section (and associated address:port combination) the answerer has selected as the offerer tagged "m=" section. If the offerer wants to request that the answerer accepts a given bundled "m=" section only if the answerer keeps the "m=" section within the negotiated BUNDLE group, the offerer MUST: Holmberg, et al. Expires June 18, 2019 [Page 12] Internet-Draft Bundled media December 2018 o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m=" section; and o Assign a zero port value to the "m=" section. NOTE: If the offerer assigns a zero port value to a bundled "m=" section, but does not include an SDP 'bundle-only' attribute in the "m=" section, it is an indication that the offerer wants to disable the "m=" section [Section 7.5.3]. [Section 7.2.2] and [Section 18.1] show an example of an initial BUNDLE offer. 7.2.1. Suggesting the Offerer tagged 'm=' section In the initial BUNDLE offer, the bundled "m=" section indicated by the offerer BUNDLE-tag is the suggested offerer tagged "m=" section. The address:port combination associated with the "m=" section will be used by the offerer for sending and receiving bundled media if the answerer selects the "m=" section as the offerer tagged "m=" section [Section 7.3.1]. In addition, if the answerer selects the "m=" section as the offerer tagged "m=" section, the BUNDLE attributes included in the "m=" section will be applied to each "m=" section within the negotiated BUNDLE group. The offerer MUST NOT suggest a bundle-only "m=" section as the offerer tagged "m=" section. It is RECOMMENDED that the suggested offerer tagged "m=" section is a bundled "m=" section that the offerer believes it is unlikely that the answerer will reject, or move out of the BUNDLE group. How such assumption is made is outside the scope of this document. 7.2.2. Example: Initial SDP Offer The example shows an initial BUNDLE offer. The offer includes two "m=" sections in the offer, and suggests that both "m=" sections are included in a BUNDLE group. The audio "m=" section is the suggested offerer tagged "m=" section, indicated by placing the identification- tag associated with the "m=" section (offerer BUNDLE-tag) first in the SDP group:BUNDLE attribute identification-id list. Holmberg, et al. Expires June 18, 2019 [Page 13] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10002 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 7.3. Generating the SDP Answer When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group the following general SDP grouping framework restrictions, defined in [RFC5888], also apply to the BUNDLE group: o The answerer is only allowed to include a BUNDLE group in an initial BUNDLE answer if the offerer requested the BUNDLE group to be created in the corresponding initial BUNDLE offer; and o The answerer is only allowed to include a BUNDLE group in a subsequent answer if the corresponding subsequent offer contains a previously negotiated BUNDLE group; and o The answerer is only allowed to include a bundled "m=" section in an answer if the "m=" section was indicated as bundled in the corresponding offer; and Holmberg, et al. Expires June 18, 2019 [Page 14] Internet-Draft Bundled media December 2018 o The answerer is only allowed to include a bundled "m=" section in the same BUNDLE group as the bundled "m=" line in the corresponding offer. In addition, when an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group, the answerer MUST: o In case of an initial BUNDLE answer, select the offerer tagged "m=" section using the procedures in Section 7.3.1. In case of a subsequent answer, the offerer tagged "m=" section is indicated in the corresponding subsequent offer, and MUST NOT be changed by the answerer; and o Select the answerer tagged "m=" section [Section 7.3.1]; and o Assign the answerer BUNDLE address:port to the answerer tagged "m=" section; and o Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every other bundled "m=" section within the BUNDLE group; and o Include SDP attributes in the bundled "m=" sections following the rules in [Section 7.1.3]; and o Include an SDP 'group:BUNDLE' attribute in the answer; and o Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The answerer BUNDLE-tag indicates the answerer tagged "m=" section [Section 7.3.1]. If the answerer does not want to keep an "m=" section within a BUNDLE group, it MUST: o Move the "m=" section out of the BUNDLE group [Section 7.3.2]; or o Reject the "m=" section [Section 7.3.3]. The answerer can modify the answerer BUNDLE address:port, add and remove SDP attributes, or modify SDP attribute values, in a subsequent answer. Changes to the answerer BUNDLE address:port and the answerer BUNDLE attributes will be applied to each bundled "m=" section within the BUNDLE group. NOTE: If a bundled "m=" section in an offer contains a zero port value, but the "m=" section does not contain an SDP 'bundle-only' Holmberg, et al. Expires June 18, 2019 [Page 15] Internet-Draft Bundled media December 2018 attribute, it is an indication that the offerer wants to disable the "m=" section [Section 7.5.3]. 7.3.1. Answerer Selection of tagged 'm=' sections When the answerer selects the offerer tagged "m=" section, it first checks the suggested offerer tagged "m=" section [Section 7.2.1]. The answerer MUST check whether the "m=" section fulfils the following criteria: o The answerer will not move the "m=" section out of the BUNDLE group [Section 7.3.2]; and o The answerer will not reject the "m=" section [Section 7.3.3]; and o The "m=" section does not contain a zero port value. If all of the criteria above are fulfilled, the answerer MUST select the "m=" section as the offerer tagged "m=" section, and MUST also mark the corresponding "m=" section in the answer as the answerer tagged "m=" section. In the answer the answerer BUNDLE-tag indicates the answerer tagged "m=" section. If one or more of the criteria are not fulfilled, the answerer MUST pick the next identification-tag in the identification-tag list in the offer, and perform the same criteria check for the "m=" section indicated by that identification-tag. If there are no more identification-tags in the identification-tag list, the answerer MUST NOT create the BUNDLE group. Unless the answerer rejects the whole offer, the answerer MUST apply the answerer procedures for moving an "m=" section out of a BUNDLE group [Section 7.3.2] or rejecting an "m=" section within a BUNDLE group [Section 7.3.3] to every bundled "m=" section in the offer when creating the answer. [Section 18.1] shows an example of an offerer BUNDLE address:port selection. [Section 7.3.4] and [Section 18.1] show an example of an answerer tagged "m=" section selection. 7.3.2. Moving A Media Description Out Of A BUNDLE Group When an answerer generates the answer, if the answerer wants to move a bundled "m=" section out of the negotiated BUNDLE group, the answerer MUST first check the following criteria: o In the corresponding offer, the "m=" section is within a previously negotiated BUNDLE group; and Holmberg, et al. Expires June 18, 2019 [Page 16] Internet-Draft Bundled media December 2018 o In the corresponding offer, the "m=" section contains an SDP 'bundle-only' attribute. If either criterium above is fulfilled the answerer can not move the "m=" section out of the BUNDLE group in the answer. The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group [Section 7.3.3], or keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section can not be moved out of the BUNDLE group in an answer. Instead an offer is needed. When the answerer generates an answer, in which it moves a bundled "m=" section out of a BUNDLE group, the answerer: o MUST assign a unique address:port to the "m=" section; and o MUST include any applicable SDP attribute in the "m=" section, using the normal offer/answer procedures for the each Attributes; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group. o MUST NOT include an SDP 'bundle-only' attribute to the "m=" section; and Because an answerer is not allowed to move an "m=" section from one BUNDLE group to another within an answer [Section 7.3], if the answerer wants to move an "m=" section from one BUNDLE group to another it MUST first move the "m=" section out of the current BUNDLE group, and then generate an offer where the "m=" section is added to another BUNDLE group [Section 7.5.1]. 7.3.3. Rejecting a Media Description in a BUNDLE Group When an answerer wants to reject a bundled "m=" section in an answer, it MUST first check the following criterion: o In the corresponding offer, the "m=" section is the offerer tagged "m=" section. If the criterium above is fulfilled the answerer can not reject the "m=" section in the answer. The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group, or Holmberg, et al. Expires June 18, 2019 [Page 17] Internet-Draft Bundled media December 2018 keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is disabled within the BUNDLE group [Section 7.5.3]. When an answerer generates an answer, in which it rejects a bundled "m=" section, the answerer: o MUST assign a zero port value to the "m=" section, according to the procedures in [RFC3264]; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and o MUST NOT include an SDP 'bundle-only' attribute in the "m=" section. 7.3.4. Example: SDP Answer The example below shows an answer, based on the corresponding offer in [Section 7.2.2]. The answerer accepts both bundled "m=" sections within the created BUNDLE group. The audio "m=" section is the answerer tagged "m=" section, indicated by placing the identification-tag associated with the "m=" section (answerer BUNDLE- tag) first in the SDP group;BUNDLE attribute identification-id list. The answerer includes an SDP 'bundle-only' attribute in, and assigns a zero port value to, the video "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 18] Internet-Draft Bundled media December 2018 SDP Answer v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 7.4. Offerer Processing of the SDP Answer When an offerer receives an answer, if the answer contains a BUNDLE group, the offerer MUST check that any bundled "m=" section in the answer was indicated as bundled in the corresponding offer. If there is no mismatch, the offerer MUST apply the properties (BUNDLE address:port, BUNDLE attributes etc) of the offerer tagged "m=" section (selected by the answerer [Section 7.3.1]) to each bundled "m=" section within the BUNDLE group. NOTE: As the answerer might reject one or more bundled "m=" sections in an initial BUNDLE offer, or move a bundled "m=" section out of a BUNDLE group, a given bundled "m=" section in the offer might not be indicated as bundled in the corresponding answer. If the answer does not contain a BUNDLE group, the offerer MUST process the answer as a normal answer. 7.5. Modifying the Session When a BUNDLE group has previously been negotiated, and an offerer generates a subsequent offer, the offerer MUST: Holmberg, et al. Expires June 18, 2019 [Page 19] Internet-Draft Bundled media December 2018 o Pick one bundled "m=" section as the offerer tagged "m=" section. The offerer can either pick the "m=" section that was previously selected by the answerer as the offerer tagged "m=" section, or pick another bundled "m=" section within the BUNDLE group; and o Assign a BUNDLE address:port (previously negotiated or newly suggest) to the offerer tagged "m=" section; and o Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every other bundled "m=" section within the BUNDLE group; and o Include SDP attributes in the bundled "m=" sections following the rules in [Section 7.1.3]; and o Include an SDP 'group:BUNDLE' attribute in the offer; and o Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the offerer tagged "m=" section. The offerer MUST NOT pick a given bundled "m=" section as the offerer tagged "m=" section if: o The offerer wants to move the "m=" section out of the BUNDLE group [Section 7.5.2]; or o The offerer wants to disable the "m=" section [Section 7.5.3]. The offerer can modify the offerer BUNDLE address:port, add and remove SDP attributes, or modify SDP attribute values, in the subsequent offer. Changes to the offerer BUNDLE address:port and the offerer BUNDLE attributes will (if the offer is accepted by the answerer) be applied to each bundled "m=" section within the BUNDLE group. 7.5.1. Adding a Media Description to a BUNDLE group When an offerer generates a subsequent offer, in which it wants to add a bundled "m=" section to a previously negotiated BUNDLE group, the offerer follows the procedures in Section 7.5. The offerer either picks the added "m=" section, or an "m=" section previously added to the BUNDLE group, as the offerer tagged "m=" section. NOTE: As described in Section 7.3.2, the answerer can not move the added "m=" section out of the BUNDLE group in its answer. If the answer wants to move the "m=" section out of the BUNDLE group, it will have to first accept it into the BUNDLE group in the answer, and Holmberg, et al. Expires June 18, 2019 [Page 20] Internet-Draft Bundled media December 2018 then send a subsequent offer where the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. 7.5.2. Moving a Media Description Out of a BUNDLE Group When an offerer generates a subsequent offer, in which it want to remove a bundled "m=" section from a BUNDLE group, the offerer: o MUST assign a unique address:port to the "m=" section; and o MUST include SDP attributes in the "m=" section following the normal offer/answer rules for each attribute; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" section. For the other bundled "m=" sections within the BUNDLE group, the offerer follows the procedures in [Section 7.5]. An offerer MUST NOT move an "m=" section from one BUNDLE group to another within a single offer. If the offerer wants to move an "m=" section from one BUNDLE group to another it MUST first move the BUNDLE group out of the current BUNDLE group, and then generate a second offer where the "m=" section is added to another BUNDLE group [Section 7.5.1]. [Section 18.4] shows an example of an offer for moving an "m=" section out of a BUNDLE group. 7.5.3. Disabling a Media Description in a BUNDLE Group When an offerer generates a subsequent offer, in which it want to disable a bundled "m=" section from a BUNDLE group, the offerer: o MUST assign a zero port value to the "m=" section, following the procedures in [RFC4566]; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 21] Internet-Draft Bundled media December 2018 For the other bundled "m=" sections within the BUNDLE group, the offerer follows the procedures in [Section 7.5]. [Section 18.5] shows an example of an offer and answer for disabling an "m=" section within a BUNDLE group. 8. Protocol Identification Each "m=" section within a BUNDLE group MUST use the same transport- layer protocol. If bundled "m=" sections use different upper-layer protocols on top of the transport-layer protocol, there MUST exist a publicly available specification which describes a mechanism how to associate received data with the correct protocol for this particular protocol combination. In addition, if received data can be associated with more than one bundled "m=" section, there MUST exist a publicly available specification which describes a mechanism for associating the received data with the correct "m=" section. This document describes a mechanism to identify the protocol of received data among the STUN, DTLS and SRTP protocols (in any combination), when UDP is used as transport-layer protocol, but it does not describe how to identify different protocols transported on DTLS. While the mechanism is generally applicable to other protocols and transport-layer protocols, any such use requires further specification around how to multiplex multiple protocols on a given transport-layer protocol, and how to associate received data with the correct protocols. 8.1. STUN, DTLS, SRTP Section 5.1.2 of [RFC5764] describes a mechanism to identify the protocol of a received packet among the STUN, DTLS and SRTP protocols (in any combination). If an offer or answer includes a bundled "m=" section that represents these protocols, the offerer or answerer MUST support the mechanism described in [RFC5764], and no explicit negotiation is required in order to indicate support and usage of the mechanism. [RFC5764] does not describe how to identify different protocols transported on DTLS, only how to identify the DTLS protocol itself. If multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identifying each individual protocol. In addition, if a received DTLS packet can be associated with more than one "m=" section, there MUST exist a specification which describes a mechanism for associating the received DTLS packets with the correct "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 22] Internet-Draft Bundled media December 2018 [Section 9.2] describes how to associate the packets in a received SRTP stream with the correct "m=" section. 9. RTP Considerations 9.1. Single RTP Session All RTP-based media within a single BUNDLE group belong to a single RTP session [RFC3550]. Since a single BUNDLE transport is used for sending and receiving bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for RTP-based bundled media. Since a single RTP session is used for each BUNDLE group, all "m=" sections representing RTP-based media within a BUNDLE group will share a single SSRC numbering space [RFC3550]. The following rules and restrictions apply for a single RTP session: o A specific payload type value can be used in multiple bundled "m=" sections only if each codec associated with the payload type number shares an identical codec configuration [Section 9.1.1]. o The proto value in each bundled RTP-based "m=" section MUST be identical (e.g., RTP/AVPF). o The RTP MID header extension MUST be enabled, by including an SDP 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section in every offer and answer. o A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled "m=" sections. NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC. If transmission of multiple media types are done with time overlap, RTP and RTCP fail to function. Even if done in proper sequence this causes RTP Timestamp rate switching issues [RFC7160]. However, once an SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC can be reused by another source (possibly associated with a different bundled "m=" section) after a delay of 5 RTCP reporting intervals (the delay is to ensure the SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]). Holmberg, et al. Expires June 18, 2019 [Page 23] Internet-Draft Bundled media December 2018 [RFC7657] defines Differentiated Services (Diffserv) considerations for RTP-based bundled media sent using a mixture of Diffserv Codepoints. 9.1.1. Payload Type (PT) Value Reuse Multiple bundled "m=" sections might describe RTP based media. As all RTP based media associated with a BUNDLE group belong to the same RTP session, in order for a given payload type value to be used inside more than one bundled "m=" section, all codecs associated with the payload type number MUST share an identical codec configuration. This means that the codecs MUST share the same media type, encoding name, clock rate and any parameter that can affect the codec configuration and packetization. [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose attribute values are required to be identical for all codecs that use the same payload type value. 9.2. Associating RTP/RTCP Streams with the Correct SDP Media Description As described in [RFC3550], RTP packets are associated with RTP streams [RFC7656]. Each RTP stream is identified by an SSRC value, and each RTP packet includes an SSRC field that is used to associate the packet with the correct RTP stream. RTCP packets also use SSRCs to identify which RTP streams the packet relates to. However, a RTCP packet can contain multiple SSRC fields, in the course of providing feedback or reports on different RTP streams, and therefore can be associated with multiple such streams. In order to be able to process received RTP/RTCP packets correctly, it MUST be possible to associate an RTP stream with the correct "m=" section, as the "m=" section and SDP attributes associated with the "m=" section contains information needed to process the packets. As all RTP streams associated with a BUNDLE group use the same transport for sending and receiving RTP/RTCP packets, the local address:port combination part of the transport cannot be used to associate an RTP stream with the correct "m=" section. In addition, multiple RTP streams might be associated with the same "m=" section. An offerer and answerer can inform each other which SSRC values they will use for an RTP stream by using the SDP 'ssrc' attribute [RFC5576]. However, an offerer will not know which SSRC values the answerer will use until the offerer has received the answer providing that information. Due to this, before the offerer has received the answer, the offerer will not be able to associate an RTP stream with the correct "m=" section using the SSRC value associated with the RTP Holmberg, et al. Expires June 18, 2019 [Page 24] Internet-Draft Bundled media December 2018 stream. In addition, the offerer and answerer may start using new SSRC values mid-session, without informing each other using the SDP 'ssrc' attribute. In order for an offerer and answerer to always be able to associate an RTP stream with the correct "m=" section, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 15, where the offerer and answerer insert the identification- tag associated with an "m=" section (provided by the remote peer) into RTP and RTCP packets associated with a BUNDLE group. When using this mechanism, the mapping from an SSRC to an identification-tag is carried in RTP header extensions or RTCP SDES packets, as specified in Section 15. Since a compound RTCP packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, a single RTCP packet can contain several SSRC to identification-tag mappings. The offerer and answerer maintain tables used for routing that are updated each time an RTP/ RTCP packet contains new information that affects how packets are to be routed. However, some legacy implementations may not include this identification-tag in their RTP and RTCP traffic when using the BUNDLE mechanism, and instead use a payload type based mechanism to associate RTP streams with SDP "m=" sections. In this situation, each "m=" section needs to use unique payload type values, in order for the payload type to be a reliable indicator of the relevant "m=" section for the RTP stream. If an implementation fails to ensure unique payload type values it will be impossible to associate the RTP stream using that payload type value to a particular "m=" section. Note that when using the payload type to associate RTP streams with "m=" sections an RTP stream, identified by its SSRC, will be mapped to an "m=" section when the first packet of that RTP stream is received, and the mapping will not be changed even if the payload type used by that RTP stream changes. In other words, the SSRC cannot "move" to a different "m=" section simply by changing the payload type. Applications can implement RTP stacks in many different ways. The algorithm below details one way that RTP streams can be associated with "m=" sections, but is not meant to be prescriptive about exactly how an RTP stack needs to be implemented. Applications MAY use any algorithm that achieves equivalent results to those described in the algorithm below. To prepare to associate RTP streams with the correct "m=" section, the following steps MUST be followed for each BUNDLE group: Holmberg, et al. Expires June 18, 2019 [Page 25] Internet-Draft Bundled media December 2018 Construct a table mapping MID to "m=" section for each "m=" section in this BUNDLE group. Note that an "m=" section may only have one MID. Construct a table mapping SSRCs of incoming RTP streams to "m=" section for each "m=" section in this BUNDLE group and for each SSRC configured for receiving in that "m=" section. Construct a table mapping the SSRC of each outgoing RTP stream to "m=" section for each "m=" section in this BUNDLE group and for each SSRC configured for sending in that "m=" section. Construct a table mapping payload type to "m=" section for each "m=" section in the BUNDLE group and for each payload type configured for receiving in that "m=" section. If any payload type is configured for receiving in more than one "m=" section in the BUNDLE group, do not include it in the table, as it cannot be used to uniquely identify an "m=" section. Note that for each of these tables, there can only be one mapping for any given key (MID, SSRC, or PT). In other words, the tables are not multimaps. As "m=" sections are added or removed from the BUNDLE groups, or their configurations are changed, the tables above MUST also be updated. When an RTP packet is received, it MUST be delivered to the RTP stream corresponding to its SSRC. That RTP stream MUST then be associated with the correct "m=" section within a BUNDLE group, for additional processing, according to the following steps: If the MID associated with the RTP stream is not in the table mapping MID to "m=" section, then the RTP stream is not decoded and the payload data is discarded. If the packet has a MID, and the packet's extended sequence number is greater than that of the last MID update, as discussed in [RFC7941], Section 4.2.6, update the MID associated with the RTP stream to match the MID carried in the RTP packet, then update the mapping tables to include an entry that maps the SSRC of that RTP stream to the "m=" section for that MID. If the SSRC of the RTP stream is in the incoming SSRC mapping table, check that the payload type used by the RTP stream matches a payload type included on the matching "m=" section. If so, associate the RTP stream with that "m=" section. Otherwise, the RTP stream is not decoded and the payload data is discarded. Holmberg, et al. Expires June 18, 2019 [Page 26] Internet-Draft Bundled media December 2018 If the payload type used by the RTP stream is in the payload type table, update the incoming SSRC mapping table to include an entry that maps the RTP stream's SSRC to the "m=" section for that payload type. Associate the RTP stream with the corresponding "m=" section. Otherwise, mark the RTP stream as not for decoding and discard the payload. If the RTP packet contains one or more contributing source (CSRC) identifiers, then each CSRC is looked up in the incoming SSRC table and a copy of the RTP packet is associated with the corresponding "m=" section for additional processing. For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the packet is processed as usual by the RTP layer, then associated with the appropriate "m=" sections, and processed for the RTP streams represented by those "m=" sections. This routing is type-dependent, as each kind of RTCP packet has its own mechanism for associating it with the relevant RTP streams. RTCP packets that cannot be associated with an appropriate "m=" section MUST still be processed as usual by the RTP layer, updating the metadata associated with the corresponding RTP streams. This situation can occur with certain multiparty RTP topologies, or when RTCP packets are sent containing a subset of the SDES information. Additional rules for processing various types of RTCP packets are explained below. If the RTCP packet is of type SDES, for each chunk in the packet whose SSRC is found in the incoming SSRC table, deliver a copy of the SDES packet to the "m=" section associated with that SSRC. In addition, for any SDES MID items contained in these chunks, if the MID is found in the table mapping MID to "m=" section, update the incoming SSRC table to include an entry that maps the RTP stream associated with the chunk's SSRC to the "m=" section associated with that MID, unless the packet is older than the packet that most recently updated the mapping for this SSRC, as discussed in [RFC7941], Section 4.2.6. Note that if an SDES packet is received as part of a compound RTCP packet, the SSRC to "m=" section mapping might not exist until the SDES packet is handled (e.g., in the case where RTCP for a source is received before any RTP packets). Therefore, it can be beneficial for an implementation to delay RTCP packet routing, such that it either prioritizes processing of the SDES item to generate or update the mapping, or buffers the RTCP information Holmberg, et al. Expires June 18, 2019 [Page 27] Internet-Draft Bundled media December 2018 that needs to be routed until the SDES item(s) has been processed. If the implementation is unable to follow this recommendation, the consequence could be that some RTCP information from this particular RTCP compound packet is not provided to higher layers. The impact from this is likely minor, when this information relates to a future incoming RTP stream. If the RTCP packet is of type BYE, it indicates that the RTP streams referenced in the packet are ending. Therefore, for each SSRC indicated in the packet that is found in the incoming SSRC table, first deliver a copy of the BYE packet to the "m=" section associated with that SSRC, then remove the entry for that SSRC from the incoming SSRC table after an appropriate delay to account for "straggler packets", as specified in [RFC3550], Section 6.2.1. If the RTCP packet is of type SR or RR, for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the SR or RR packet to the "m=" section associated with that SSRC. In addition, if the packet is of type SR, and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the SR packet to the "m=" section associated with that SSRC. If the implementation supports RTCP XR and the packet is of type XR, as defined in [RFC3611], for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC. In addition, if the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC. If the RTCP packet is a feedback message of type RTPFB or PSFB, as defined in [RFC4585], it will contain a media source SSRC, and this SSRC is used for routing certain subtypes of feedback messages. However, several subtypes of PSFB and RTPFB messages include target SSRC(s) in a section called Feedback Control Information (FCI). For these messages, the target SSRC(s) are used for routing. If the RTCP packet is a feedback packet that does not include target SSRCs in its FCI section, and the media source SSRC is found in the outgoing SSRC table, deliver the feedback packet to the "m=" section associated with that SSRC. RTPFB and PSFB types that are handled in this way include: Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). Holmberg, et al. Expires June 18, 2019 [Page 28] Internet-Draft Bundled media December 2018 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). Reference Picture Selection Indication (RPSI): [RFC4585] (PT=PSFB, FMT=3). If the RTCP packet is a feedback message that does include target SSRC(s) in its FCI section, it can either be a request or a notification. Requests reference a RTP stream that is being sent by the message recipient, whereas notifications are responses to an earlier request, and therefore reference a RTP stream that is being received by the message recipient. If the RTCP packet is a feedback request that includes target SSRC(s), for each target SSRC that is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with that SSRC. PSFB and RTPFB types that are handled in this way include: Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, FMT=5). H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, FMT=7). Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] (PT=RTPFB, FMT=3). Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, FMT=10). If the RTCP packet is a feedback notification that includes target SSRC(s), for each target SSRC that is found in the incoming SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with the RTP stream with matching SSRC. PSFB and RTPFB types that are handled in this way include: Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] (PT=PSFB, FMT=6). This message is a notification in response to a prior TSTR. Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] (PT=RTPFB, FMT=4). This message is a notification in response to a prior TMMBR, but can also be sent unsolicited. Holmberg, et al. Expires June 18, 2019 [Page 29] Internet-Draft Bundled media December 2018 If the RTCP packet is of type APP, then it is handled in an application specific manner. If the application does not recognise the APP packet, then it MUST be discarded. 9.3. RTP/RTCP Multiplexing Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP multiplexing [RFC5761] for the RTP-based bundled media (i.e., the same transport will be used for both RTP packets and RTCP packets). In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- only' attribute [I-D.ietf-mmusic-mux-exclusive]. 9.3.1. SDP Offer/Answer Procedures This section describes how an offerer and answerer use the SDP 'rtcp- mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. RTP/RTCP multiplexing only applies to RTP-based media. However, as described in Section 7.1.3, within an offer or answer the SDP 'rtcp- mux' and SDP 'rtcp-mux-only' attributes might be included in a bundled "m=" section for non-RTP-based media (if such "m=" section is the offerer tagged "m=" section or answerer tagged "m=" section). 9.3.1.1. Generating the Initial SDP BUNDLE Offer When an offerer generates an initial BUNDLE offer, if the offer contains one or more bundled "m=" sections for RTP-based media (or, if there is a chance that "m=" sections for RTP-based media will later be added to the BUNDLE group), the offerer MUST include an SDP 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section (excluding any bundle-only "m=" sections). In addition, the offerer MAY include an SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in one or more bundled "m=" sections for RTP-based media. NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute depends on whether the offerer supports fallback to usage of a separate port for RTCP in case the answerer moves one or more "m=" sections for RTP-based media out of the BUNDLE group in the answer. NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' attribute, the offerer can also include an SDP 'rtcp' attribute [RFC3605] in one or more RTP-based bundled "m=" sections in order to provide a fallback port for RTCP, as described in [RFC5761]. However, the fallback port will only be applied to "m=" sections for Holmberg, et al. Expires June 18, 2019 [Page 30] Internet-Draft Bundled media December 2018 RTP-based media that are moved out of the BUNDLE group by the answerer. In the initial BUNDLE offer, the address:port combination for RTCP MUST be unique in each bundled "m=" section for RTP-based media (excluding a bundle-only "m=" section), similar to RTP. 9.3.1.2. Generating the SDP Answer When an answerer generates an answer, if the answerer supports RTP- based media, and if a bundled "m=" section in the corresponding offer contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP multiplexing, even if there currently are no bundled "m=" sections for RTP-based media within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" section, following the procedures for BUNDLE attributes [Section 7.1.3]. In addition, if the "m=" section that is selected as the offerer tagged "m=" section contained an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute in the answerer tagged "m=" section. In an initial BUNDLE offer, if the suggested offerer tagged "m=" section contained an SDP 'rtcp-mux-only' attribute, the "m=" section was for RTP-based media, and the answerer does not accept the "m=" section in the created BUNDLE group, the answerer MUST either move the "m=" section out of the BUNDLE group [Section 7.3.2], include the attribute in the moved "m=" section and enable RTP/RTCP multiplexing for the media associated with the "m=" section, or reject the "m=" section [Section 7.3.3]. The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled "m=" section in the answer. The answerer will use the port value of the tagged offerer "m=" section sending RTP and RTCP packets associated with RTP-based bundled media towards the offerer. If the usage of RTP/RTCP multiplexing within a BUNDLE group has been negotiated in a previous offer/answer exchange, the answerer MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" section . It is not possible to disable RTP/RTCP multiplexing within a BUNDLE group. 9.3.1.3. Offerer Processing of the SDP Answer When an offerer receives an answer, if the answerer has accepted the usage of RTP/RTCP multiplexing [Section 9.3.1.2], the answerer follows the procedures for RTP/RTCP multiplexing defined in [RFC5761]. The offerer will use the port value of the answerer Holmberg, et al. Expires June 18, 2019 [Page 31] Internet-Draft Bundled media December 2018 tagged "m=" section for sending RTP and RTCP packets associated with RTP-based bundled media towards the answerer. NOTE: It is considered a protocol error if the answerer has not accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" sections that the answerer included in the BUNDLE group. 9.3.1.4. Modifying the Session When an offerer generates a subsequent offer, the offerer MUST include an SDP 'rtcp-mux' attribute in the offerer tagged "m=" section, following the procedures for IDENTICAL multiplexing category attributes in Section 7.1.3. 10. ICE Considerations This section describes how to use the BUNDLE grouping extension together with the Interactive Connectivity Establishment (ICE) mechanism [I-D.ietf-ice-rfc5245bis]. The generic procedures for negotiating usage of ICE using SDP, defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE with BUNDLE, with the following exceptions: o When the BUNDLE transport has been established, ICE connectivity checks and keep-alives only need to be performed for the BUNDLE transport, instead of per individual bundled "m=" section within the BUNDLE group. o The generic SDP attribute offer/answer considerations [Section 7.1.3] also apply to ICE-related attributes. Therefore, when an offer sends an initial BUNDLE offer (in order to negotiate a BUNDLE group) the offerer include ICE-related media-level attributes in each bundled "m=" section (excluding any bundle-only "m=" section), and each "m=" section MUST contain unique ICE properties. When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group, and when an offerer sends a subsequent offer that contains a BUNDLE group, ICE-related media-level attributes are only included in the tagged "m=" section (suggested offerer tagged "m=" section or answerer tagged "m=" section), and the ICE properties are applied to each bundled "m=" section within the BUNDLE group. NOTE: Most ICE-related media-level SDP attributes belong to the TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes], and the generic SDP attribute offer/answer considerations for TRANSPORT multiplexing category apply to the attributes. However, in the case of ICE-related attributes, the same considerations also Holmberg, et al. Expires June 18, 2019 [Page 32] Internet-Draft Bundled media December 2018 apply to ICE-related media-level attributes that belong to other multiplexing categories. NOTE: The following ICE-related media-level SDP attributes are defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- pacing'. Initially, before ICE has produced selected candidate pairs that will be used for media, there might be multiple transports established (if multiple candidate pairs are tested). Once ICE has selected candidate pairs, they form the BUNDLE transport. Support and usage of ICE mechanism together with the BUNDLE extension is OPTIONAL, and the procedures in this section only apply when the ICE mechanism is used. Note that applications might mandate usage of the ICE mechanism even if the BUNDLE extension is not used. NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] is used, an offerer and answerer might assign a port value of '9', and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" sections in the initial BUNDLE offer. The offerer and answerer will follow the normal procedures for generating the offers and answers, including picking a bundled "m=" section as the suggested offerer tagged "m=" section, selecting the tagged "m=" sections etc. The only difference is that media can not be sent until one or more candidates have been provided. Once a BUNDLE group has been negotiated, trickled candidates associated with a bundled "m=" section will be applied to all bundled "m=" sections within the BUNDLE group. 11. DTLS Considerations One or more media streams within a BUNDLE group might use the Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order to encrypt the data, or to negotiate encryption keys if another encryption mechanism is used to encrypt media. When DTLS is used within a BUNDLE group, the following rules apply: o There can only be one DTLS association [RFC6347] associated with the BUNDLE group; and o Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for determining which endpoints (the offerer or answerer) become DTLS client and DTLS server; and Holmberg, et al. Expires June 18, 2019 [Page 33] Internet-Draft Bundled media December 2018 o Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for determining whether an offer or answer will trigger the establishment of a new DTLS association, or whether an existing DTLS association will be used; and o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message [RFC5764]. The client MUST include the extension even if the usage of DTLS-SRTP is not negotiated as part of the multimedia session (e.g., SIP session [RFC3261]). NOTE: The inclusion of the 'use_srtp' extension during the initial DTLS handshake ensures that a DTLS renegotiation will not be required in order to include the extension, in case DTLS-SRTP encrypted media is added to the BUNDLE group later during the multimedia session. 12. RTP Header Extensions Consideration When [RFC8285] RTP header extensions are used in the context of this specification, the identifier used for a given extension MUST identify the same extension across all the bundled media descriptions. 13. Update to RFC 3264 This section updates RFC 3264, in order to allow extensions to define the usage of a zero port value in offers and answers for other purposes than removing or disabling media streams. The following sections of RFC 3264 are updated: o Section 5.1 (Unicast Streams). o Section 8.4 (Putting a Unicast Media Stream on Hold). 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the offerer. A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream Holmberg, et al. Expires June 18, 2019 [Page 34] Internet-Draft Bundled media December 2018 (Section 6). Furthermore, existing streams can be terminated by setting the port to zero (Section 8). In general, a port number of zero indicates that the media stream is not wanted. 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the offerer. A port number of zero in the offer by default indicates that the stream is offered but MUST NOT be used, but an extension mechanism might specify different semantics for the usage of a zero port value. Furthermore, existing streams can be terminated by setting the port to zero (Section 8). In general, a port number of zero by default indicates that the media stream is not wanted. 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP is to be sent to the peer. 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, if it would specify that the stream has been disabled. However, an extension mechanism might specify different Holmberg, et al. Expires June 18, 2019 [Page 35] Internet-Draft Bundled media December 2018 semantics of the zero port number usage. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP is to be sent to the peer. 14. Update to RFC 5888 This section updates RFC 5888 [RFC5888]), in order to allow extensions to allow an SDP 'group' attribute containing an identification-tag that identifies a "m=" section with the port set to zero Section 9.2 (Group Value in Answers) of RFC 5888 is updated. 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero. 14.2. New text replacing section 9.2 (3rd paragraph) of RFC 5888 SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero, but an extension mechanism might specify different semantics for including identification-tags that correspond to such "m=" lines. 15. RTP/RTCP extensions for identification-tag transport SDP Offerers and Answerers [RFC3264] can associate identification- tags with "m=" sections within SDP Offers and Answers, using the procedures in [RFC5888]. Each identification-tag uniquely represents an "m=" section. This section defines a new RTCP SDES item [RFC3550], 'MID', which is used to carry identification-tags within RTCP SDES packets. This section also defines a new RTP SDES header extension [RFC7941], which is used to carry the 'MID' RTCP SDES item in RTP packets. The SDES item and RTP SDES header extension make it possible for a receiver to associate each RTP stream with a specific "m=" section, with which the receiver has associated an identification-tag, even if those "m=" sections are part of the same RTP session. The RTP SDES header extension also ensures that the media recipient gets the identification-tag upon receipt of the first decodable media and is able to associate the media with the correct application. A media recipient informs the media sender about the identification- tag associated with an "m=" section through the use of an 'mid' Holmberg, et al. Expires June 18, 2019 [Page 36] Internet-Draft Bundled media December 2018 attribute [RFC5888]. The media sender then inserts the identification-tag in RTCP and RTP packets sent to the media recipient. NOTE: This text above defines how identification-tags are carried in SDP Offers and Answers. The usage of other signaling protocols for carrying identification-tags is not prevented, but the usage of such protocols is outside the scope of this document. [RFC3550] defines general procedures regarding the RTCP transmission interval. The RTCP MID SDES item SHOULD be sent in the first few RTCP packets sent after joining the session, and SHOULD be sent regularly thereafter. The exact number of RTCP packets in which this SDES item is sent is intentionally not specified here, as it will depend on the expected packet loss rate, the RTCP reporting interval, and the allowable overhead. The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD be included in some RTP packets at the start of the session and whenever the SSRC changes. It might also be useful to include the header extension in RTP packets that comprise access points in the media (e.g., with video I-frames). The exact number of RTP packets in which this header extension is sent is intentionally not specified here, as it will depend on expected packet loss rate and loss patterns, the overhead the application can tolerate, and the importance of immediate receipt of the identification-tag. For robustness, endpoints need to be prepared for situations where the reception of the identification-tag is delayed, and SHOULD NOT terminate sessions in such cases, as the identification-tag is likely to arrive soon. 15.1. RTCP MID SDES Item 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MID=TBD | length | identification-tag ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. The identification-tag is not zero terminated. [RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value.] Holmberg, et al. Expires June 18, 2019 [Page 37] Internet-Draft Bundled media December 2018 15.2. RTP SDES Header Extension For MID The payload, containing the identification-tag, of the RTP SDES header extension element can be encoded using either the one-byte or two-byte header [RFC7941]. The identification-tag payload is UTF-8 encoded, as in SDP. The identification-tag is not zero terminated. Note, that the set of header extensions included in the packet needs to be padded to the next 32-bit boundary using zero bytes [RFC8285]. As the identification-tag is included in either an RTCP SDES item or an RTP SDES header extension, or both, there needs to be some consideration about the packet expansion caused by the identification-tag. To avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the header extension's size needs to be taken into account when encoding the media. It is recommended that the identification-tag is kept short. Due to the properties of the RTP header extension mechanism, when using the one-byte header, a tag that is 1-3 bytes will result in a minimal number of 32-bit words used for the RTP SDES header extension, in case no other header extensions are included at the same time. Note, do take into account that some single characters when UTF-8 encoded will result in multiple octets. The identification-tag MUST NOT contain any user information, and applications SHALL avoid generating the identification-tag using a pattern that enables user- or application identification. 16. IANA Considerations 16.1. New 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 MID SDES item to the IANA "RTP SDES item types" registry as follows: Value: TBD Abbrev.: MID Name: Media Identification Reference: RFCXXXX Holmberg, et al. Expires June 18, 2019 [Page 38] Internet-Draft Bundled media December 2018 16.2. New RTP SDES 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, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Description: Media identification Contact: IESG (iesg@ietf.org) Reference: RFCXXXX The SDES item does not reveal privacy information about the users. It is simply used to associate RTP-based media with the correct SDP media description ("m=" section) in the SDP used to negotiate the media. The purpose of the extension is for the offerer to be able to associate received multiplexed RTP-based media before the offerer receives the associated SDP answer. 16.3. New SDP Attribute [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document defines a new SDP media-level attribute, 'bundle-only', according to the following data: Attribute name: bundle-only Type of attribute: media Subject to charset: No Purpose: Request a media description to be accepted in the answer only if kept within a BUNDLE group by the answerer. Appropriate values: N/A Contact name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux category: NORMAL Holmberg, et al. Expires June 18, 2019 [Page 39] Internet-Draft Bundled media December 2018 16.4. New SDP Group Semantics [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" subregistry (under the "Session Description Protocol (SDP) Parameters" registry: Semantics Token Reference ------------------------------------- ------ --------- Media bundling BUNDLE [RFCXXXX] Mux category: NORMAL 17. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information, e.g., RTP streams, flows over the network, with the exception of the usage of the MID SDES item as discussed below. Primarily it changes which addresses and ports, and thus in which (RTP) sessions the information is flowing. This affects the security contexts being used and can cause previously separated information flows to share the same security context. This has very little impact on the performance of the security mechanism of the RTP sessions. In cases where one would have applied different security policies on the different RTP streams being bundled, or where the parties having access to the security contexts would have differed between the RTP streams, additional analysis of the implications are needed before selecting to apply BUNDLE. The identification-tag, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-bundle group counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension. Note that if implementations use different methods for generating identification-tags this could enable fingerprinting of the implementation making it vulnerable to targeted attacks. The identification-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduce from the RTP streams without the MID SDES header Holmberg, et al. Expires June 18, 2019 [Page 40] Internet-Draft Bundled media December 2018 extensions. As the identification-tag is also used to route the media stream to the right application functionality it is important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. Existing SRTP configurations and other security mechanisms protecting the whole RTP/RTCP packets will provide the necessary protection. When the BUNDLE extension is used, the set of configurations of the security mechanism used in all the bundled media descriptions will need to be compatible so that they can be used simultaneously, at least per direction or endpoint. When using SRTP this will be the case, at least for the IETF defined key-management solutions due to their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their classification in [I-D.ietf-mmusic-sdp-mux-attributes]. The security considerations of "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] requires that when RTCP is confidentiality protected, then any SDES RTP header extension carrying an SDES item, such as the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed, there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Therefore, this specification updates RFC 7941 by adding the exception that this requirement MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. 18. Examples 18.1. Example: Tagged m= Section Selections The example below shows: o An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group, and indicates the audio m= section as the suggested offerer tagged "m=" section. o An initial BUNDLE answer, in which the answerer accepts the creation of the BUNDLE group, selects the audio m= section in the offer as the offerer tagged "m=" section, selects the audio "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 41] Internet-Draft Bundled media December 2018 SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10002 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 Holmberg, et al. Expires June 18, 2019 [Page 42] Internet-Draft Bundled media December 2018 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 18.2. Example: BUNDLE Group Rejected The example below shows: o An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group, and indicates the audio m= section as the suggested offerer tagged "m=" section. o An initial BUNDLE answer, in which the answerer rejects the creation of the BUNDLE group, generates a normal answer and assigns a unique address:port to each "m=" section in the answer. Holmberg, et al. Expires June 18, 2019 [Page 43] Internet-Draft Bundled media December 2018 SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10002 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 m=audio 20000 RTP/AVP 0 b=AS:200 a=rtcp-mux a=rtpmap:0 PCMU/8000 m=video 30000 RTP/AVP 32 b=AS:1000 a=rtcp-mux a=rtpmap:32 MPV/90000 Holmberg, et al. Expires June 18, 2019 [Page 44] Internet-Draft Bundled media December 2018 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group The example below shows: o A subsequent offer, in which the offerer adds a new bundled "m=" section (video), indicated by the "zen" identification-tag, to a previously negotiated BUNDLE group, indicates the new "m=" section as the offerer tagged "m=" section and assigns the offerer BUNDLE address:port to that "m=" section. o A subsequent answer, in which the answerer indicates the new video "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE zen foo bar m=audio 0 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=bundle-only a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid Holmberg, et al. Expires June 18, 2019 [Page 45] Internet-Draft Bundled media December 2018 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE zen foo bar m=audio 0 RTP/AVP 0 b=AS:200 a=mid:foo a=bundle-only a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 20000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group The example below shows: o A subsequent offer, in which the offerer removes a "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group, indicates one of the bundled "m=" sections (audio) remaining in the BUNDLE group as the offerer tagged "m=" section and assigns the offerer BUNDLE address:port to that "m=" section. o A subsequent answer, in which the answerer removes the "m=" section from the BUNDLE group, indicates the audio "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 46] Internet-Draft Bundled media December 2018 SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 50000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid Holmberg, et al. Expires June 18, 2019 [Page 47] Internet-Draft Bundled media December 2018 m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 60000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 18.5. Example: Offerer Disables a Media Description Within a BUNDLE Group The example below shows: o A subsequent offer, in which the offerer disables (by assigning a zero port value) a "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group, indicates one of the bundled "m=" sections (audio) remaining active in the BUNDLE group as the offerer tagged "m=" section and assigns the offerer BUNDLE address:port to that "m=" section. o A subsequent answer, in which the answerer disables the "m=" section, indicates the audio "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 c=IN IP6 2001:db8::3 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 Holmberg, et al. Expires June 18, 2019 [Page 48] Internet-Draft Bundled media December 2018 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 31 32 c=IN IP6 2001:db8::3 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 66 a=mid:zen a=rtpmap:66 H261/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 c=IN IP6 2001:db8::1 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 c=IN IP6 2001:db8::1 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 66 a=mid:zen a=rtpmap:66 H261/90000 Holmberg, et al. Expires June 18, 2019 [Page 49] Internet-Draft Bundled media December 2018 19. Acknowledgements The usage of the SDP grouping extension for negotiating bundled media is based on similar alternatives proposed by Harald Alvestrand and Cullen Jennings. The BUNDLE extension described in this document is based on the different alternative proposals, and text (e.g., SDP examples) have been borrowed (and, in some cases, modified) from those alternative proposals. The SDP examples are also modified versions from the ones in the Alvestrand proposal. Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for reading the text, and providing useful feedback. Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus Westerlund for providing the text for the section on RTP/RTCP stream association. Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for providing help and text on the RTP/RTCP procedures. Thanks to Charlie Kaufman for performing the Sec-Dir review. Thanks to Linda Dunbar for performing the Gen-ART review. Thanks to Spotify for providing music for the countless hours of document editing. 20. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51 o Changes based on IESG reviews. o - Clarification of 'initial offer' terminology. o - Merging of tagged m- section selection sections. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 o Changes based on IESG reviews. Holmberg, et al. Expires June 18, 2019 [Page 50] Internet-Draft Bundled media December 2018 o - Adding of tagged m- section concept. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 o Changes based on IESG reviews. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 o Changes based on Sec-Dir review by Charlie Kaufman. o - s/unique address/unique address:port o Changes based on Gen-ART review by Linda Dunbar. o Mux category for group:BUNDLE attribute added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 o Changes based on AD review by Ben Campbell. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 o Pre-RFC5378 disclaimer removed put back. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 o Mux category for SDP 'group:BUNDLE' attribute added. o https://github.com/cdh4u/draft-sdp-bundle/pull/54 o Pre-RFC5378 disclaimer removed. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 o Minor editorial nits based on pull request by Colin P. o https://github.com/cdh4u/draft-sdp-bundle/pull/53 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 o Changes based on WG chairs review. o Text added in order to close GitHub issues by Taylor B. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 o Changes based on final WG review. Holmberg, et al. Expires June 18, 2019 [Page 51] Internet-Draft Bundled media December 2018 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 o Update to section 6 o RFC 3264: o https://github.com/cdh4u/draft-sdp-bundle/pull/47 o Editorial clarification on BUNDLE address selection: o https://github.com/cdh4u/draft-sdp-bundle/pull/46 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 o Editorial changes and technical restrictions in order to make the specification more understandable: o https://github.com/cdh4u/draft-sdp-bundle/pull/45 o - BUNDLE address is only assigned to m- section indicated by BUNDLE-tag. o - bundle-only attribute also used in answers and subsequent offers. o - Answerer cannot reject, or remove, the bundled m- section that contains the BUNDLE address. o - ICE Offer/Answer sections removed, due to duplicated information. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 o Editorial terminology changes. o RFC 5285 reference replaced by reference to RFC 8285. o https://github.com/cdh4u/draft-sdp-bundle/pull/44 o - Clarify that an m- section can not be moved between BUNDLE groups without first moving the m- section out of a BUNDLE group. o https://github.com/cdh4u/draft-sdp-bundle/pull/41 o - Addition of BUNDLE transport concept. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 o Changes to RTP streaming mapping section based on text from Colin Perkins. Holmberg, et al. Expires June 18, 2019 [Page 52] Internet-Draft Bundled media December 2018 o The following GitHub pull requests were merged: o https://github.com/cdh4u/draft-sdp-bundle/pull/34 o - Proposed updates to RTP processing o https://github.com/cdh4u/draft-sdp-bundle/pull/35 o - fixed reference to receiver-id section Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 o The following GitHub pull request was merged: o https://github.com/cdh4u/draft-sdp-bundle/pull/33 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 o The following GitHub pull requests were merged: o https://github.com/cdh4u/draft-sdp-bundle/pull/32 o - extmap handling in BUNDLE. o https://github.com/cdh4u/draft-sdp-bundle/pull/31 o - Additional Acknowledgement text added. o https://github.com/cdh4u/draft-sdp-bundle/pull/30 o - MID SDES item security procedures updated o https://github.com/cdh4u/draft-sdp-bundle/pull/29 o - Appendix B of JSEP moved into BUNDLE. o - Associating RTP/RTCP packets with SDP m- lines. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 o Editorial changes on RTP streaming mapping section based on comments from Colin Perkins. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 o RTP streams, instead of RTP packets, are associated with m- lines. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 Holmberg, et al. Expires June 18, 2019 [Page 53] Internet-Draft Bundled media December 2018 o Editorial changes based on comments from Eric Rescorla and Cullen Jennings: o - Changes regarding usage of RTP/RTCP multiplexing attributes. o - Additional text regarding associating RTP/RTCP packets with SDP m- lines. o - Reference correction. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 o Editorial changes based on comments from Eric Rescorla and Cullen Jennings: o - Justification for mechanism added to Introduction. o - Clarify that the order of m- lines in the group:BUNDLE attribute does not have to be the same as the order in which the m- lines are listed in the SDP. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 o Editorial changes based on GitHub Pull requests by Martin Thomson: o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 o Editorial change based on comment from Diederick Huijbers (9th July 2016). o Changes based on comments from Flemming Andreasen (21st June 2016): o - Mux category for SDP bundle-only attribute added. o - Mux category considerations editorial clarification. o - Editorial changes. o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. o Note whether Design Considerations appendix is to be kept removed: o - Appendix is kept within document. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 Holmberg, et al. Expires June 18, 2019 [Page 54] Internet-Draft Bundled media December 2018 o Indicating in the Abstract and Introduction that the document updates RFC 3264. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 o Change based on WGLC comment from Colin Perkins. o - Clarify that SSRC can be reused by another source after a delay of 5 RTCP reporting intervals. o Change based on WGLC comment from Alissa Cooper. o - IANA registry name fix. o - Additional IANA registration information added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 o - Alignment with exclusive mux procedures. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 o - Yet another terminology change. o - Mux category considerations added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 o - ICE considerations modified: ICE-related SDP attributes only added to the bundled m- line representing the selected BUNDLE address. o - Reference to draft-ietf-mmusic-ice-sip-sdp added. o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- rfc5245bis. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux considerations. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 o - Reference and procedures associated with exclusive RTP/RTCP mux added Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 Holmberg, et al. Expires June 18, 2019 [Page 55] Internet-Draft Bundled media December 2018 o - RTCP-MUX mandatory for bundled RTP m- lines o - Editorial fixes based on comments from Flemming Andreasen Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 o - Correction of Ari's family name o - Editorial fixes based on comments from Thomas Stach o - RTP/RTCP correction based on comment from Magnus Westerlund o -- http://www.ietf.org/mail-archive/web/mmusic/current/ msg14861.html Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 o - Correct based on comment from Paul Kyzivat o -- 'received packets' replaced with 'received data' Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 o - Clarification based on comment from James Guballa o - Clarification based on comment from Flemming Andreasen Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 o - DTLS Considerations section added. o - BUNDLE semantics added to the IANA Considerations o - Changes based on WGLC comments from Adam Roach o -- http://www.ietf.org/mail-archive/web/mmusic/current/ msg14673.html Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 o - Changes based on agreements at IETF#92 o -- BAS Offer removed, based on agreement at IETF#92. o -- Procedures regarding usage of SDP "b=" line is replaced with a reference to to draft-ietf-mmusic-sdp-mux-attributes. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 Holmberg, et al. Expires June 18, 2019 [Page 56] Internet-Draft Bundled media December 2018 o - Editorial changes based on comments from Magnus Westerlund. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 o - Modification of RTP/RTCP multiplexing section, based on comments from Magnus Westerlund. o - Reference updates. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 o - Editorial fix. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 o - Editorial changes. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 o Changes to allow a newly suggested offerer BUNDLE address to be assigned to each bundled m- line. o Changes based on WGLC comments from Paul Kyzivat o - Editorial fixes Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 o Usage of SDP 'extmap' attribute added o SDP 'bundle-only' attribute scoped with "m=" lines with a zero port value o Changes based on WGLC comments from Thomas Stach o - ICE candidates not assigned to bundle-only m- lines with a zero port value o - Editorial changes o Changes based on WGLC comments from Colin Perkins o - Editorial changes: o -- "RTP SDES item" -> "RTCP SDES item" o -- "RTP MID SDES item" -> "RTCP MID SDES item" Holmberg, et al. Expires June 18, 2019 [Page 57] Internet-Draft Bundled media December 2018 o - Changes in section 10.1.1: o -- "SHOULD NOT" -> "MUST NOT" o -- Additional text added to the Note o - Change to section 13.2: o -- Clarify that mid value is not zero terminated o - Change to section 13.3: o -- Clarify that mid value is not zero terminated o -- Clarify padding o Changes based on WGLC comments from Paul Kyzivat o - Editorial changes: o Changes based on WGLC comments from Jonathan Lennox o - Editorial changes: o - Defintion of SDP bundle-only attribute alligned with structure in 4566bis draft Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 o Editorial corrections based on comments from Harald Alvestrand. o Editorial corrections based on comments from Cullen Jennings. o Reference update (RFC 7160). o Clarification about RTCP packet sending when RTP/RTCP multiplexing is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ msg13765.html). o Additional text added to the Security Considerations. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 o SDP bundle-only attribute added to IANA Considerations. o SDES item and RTP header extension added to Abstract and Introduction. Holmberg, et al. Expires June 18, 2019 [Page 58] Internet-Draft Bundled media December 2018 o Modification to text updating section 8.2 of RFC 3264. o Reference corrections. o Editorial corrections. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 o Terminology change: "bundle-only attribute assigned to m= line" to "bundle-only attribute associated with m= line". o Editorial corrections. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 o Editorial corrections. o - "of"->"if" (8.3.2.5). o - "optional"->"OPTIONAL" (9.1). o - Syntax/ABNF for 'bundle-only' attribute added. o - SDP Offer/Answer sections merged. o - 'Request new offerer BUNDLE address' section added Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 o OPEN ISSUE regarding Receiver-ID closed. o - RTP MID SDES Item. o - RTP MID Header Extension. o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers closed. o - Indicating that, when rtcp-mux is used, the answerer MUST NOT include an 'rtcp' attribute in the answer, based on the procedures in section 5.1.3 of RFC 5761. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 o Draft title changed. o Added "SDP" to section names containing "Offer" or "Answer". Holmberg, et al. Expires June 18, 2019 [Page 59] Internet-Draft Bundled media December 2018 o Editorial fixes based on comments from Paul Kyzivat (http://www.ietf.org/mail-archive/web/mmusic/current/ msg13314.html). o Editorial fixed based on comments from Colin Perkins (http://www.ietf.org/mail-archive/web/mmusic/current/ msg13318.html). o - Removed text about extending BUNDLE to allow multiple RTP sessions within a BUNDLE group. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 o Major re-structure of SDP Offer/Answer sections, to align with RFC 3264 structure. o Additional definitions added. o - Shared address. o - Bundled "m=" line. o - Bundle-only "m=" line. o - Offerer suggested BUNDLE mid. o - Answerer selected BUNDLE mid. o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address to multiple "m=" lines until it has received an SDP Answer indicating support of the BUNDLE extension. o Q8 Closed (IETF#88): An Offerer can, before it knows whether the Answerer supports the BUNDLE extension, assign a zero port value to a 'bundle-only' "m=" line. o SDP 'bundle-only' attribute section added. o Connection data nettype/addrtype restrictions added. o RFC 3264 update section added. o Indicating that a specific payload type value can be used in multiple "m=" lines, if the value represents the same codec configuration in each "m=" line. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 Holmberg, et al. Expires June 18, 2019 [Page 60] Internet-Draft Bundled media December 2018 o Updated Offerer procedures (http://www.ietf.org/mail- archive/web/mmusic/current/msg12293.html). o Updated Answerer procedures (http://www.ietf.org/mail- archive/web/mmusic/current/msg12333.html). o Usage of SDP 'bundle-only' attribute added. o Reference to Trickle ICE document added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 o Mechanism modified, to be based on usage of SDP Offers with both different and identical port number values, depending on whether it is known if the remote endpoint supports the extension. o Cullen Jennings added as co-author. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 o No changes. New version due to expiration. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 o No changes. New version due to expiration. Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 o Draft name changed. o Harald Alvestrand added as co-author. o "Multiplex" terminology changed to "bundle". o Added text about single versus multiple RTP Sessions. o Added reference to RFC 3550. 21. References 21.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, . Holmberg, et al. Expires June 18, 2019 [Page 61] Internet-Draft Bundled media December 2018 [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, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 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, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, . [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, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . Holmberg, et al. Expires June 18, 2019 [Page 62] Internet-Draft Bundled media December 2018 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . [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-20 (work in progress), March 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 2016. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-12 (work in progress), May 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in progress), April 2018. [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Trickle ICE", draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), February 2018. Holmberg, et al. Expires June 18, 2019 [Page 63] Internet-Draft Bundled media December 2018 21.2. Informative References [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, . [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, . [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, . [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, . [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, . [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, . [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, . Holmberg, et al. Expires June 18, 2019 [Page 64] Internet-Draft Bundled media December 2018 [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-21 (work in progress), April 2018. [I-D.ietf-avtext-lrr] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Message", draft-ietf-avtext-lrr-07 (work in progress), July 2017. Appendix A. Design Considerations One of the main issues regarding the BUNDLE grouping extensions has been whether, in SDP Offers and SDP Answers, the same port value can be inserted in "m=" lines associated with a BUNDLE group, as the purpose of the extension is to negotiate the usage of a single transport for media specified by the "m=" sections. Issues with both approaches, discussed in the Appendix have been raised. The outcome was to specify a mechanism which uses SDP Offers with both different and identical port values. Below are the primary issues that have been considered when defining the "BUNDLE" grouping extension: o 1) Interoperability with existing UAs. o 2) Interoperability with intermediary Back to Back User Agent (B2BUA) and proxy entities. o 3) Time to gather, and the number of, ICE candidates. o 4) Different error scenarios, and when they occur. o 5) SDP Offer/Answer impacts, including usage of port number value zero. A.1. UA Interoperability Consider the following SDP Offer/Answer exchange, where Alice sends an SDP Offer to Bob: Holmberg, et al. Expires June 18, 2019 [Page 65] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 10000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 10002 RTP/AVP 97 a=rtpmap:97 H261/90000 SDP Answer v=0 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 20000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 20002 RTP/AVP 97 a=rtpmap:97 H261/90000 RFC 4961 specifies a way of doing symmetric RTP but that is a later extension to RTP and Bob can not assume that Alice supports RFC 4961. This means that Alice may be sending RTP from a different port than 10000 or 10002 - some implementations simply send the RTP from an ephemeral port. When Bob's endpoint receives an RTP packet, the only way that Bob knows if the packet is to be passed to the video or audio codec is by looking at the port it was received on. This led some SDP implementations to use the fact that each "m=" section had a different port number to use that port number as an index to find the correct m line in the SDP. As a result, some implementations that do support symmetric RTP and ICE still use an SDP data structure where SDP with "m=" sections with the same port such as: Holmberg, et al. Expires June 18, 2019 [Page 66] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 10000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 98 a=rtpmap:98 H261/90000 will result in the second "m=" section being considered an SDP error because it has the same port as the first line. A.2. Usage of Port Number Value Zero In an SDP Offer or SDP Answer, the media specified by an "m=" section can be disabled/rejected by setting the port number value to zero. This is different from e.g., using the SDP direction attributes, where RTCP traffic will continue even if the SDP "inactive" attribute is indicated for the associated "m=" section. If each "m=" section associated with a BUNDLE group would contain different port values, and one of those port values would be used for a BUNDLE address:port associated with the BUNDLE group, problems would occur if an endpoint wants to disable/reject the "m=" section associated with that port, by setting the port value to zero. After that, no "m=" section would contain the port value which is used for the BUNDLE address:port. In addition, it is unclear what would happen to the ICE candidates associated with the "m=" section, as they are also used for the BUNDLE address:port. A.3. B2BUA And Proxy Interoperability Some back to back user agents may be configured in a mode where if the incoming call leg contains an SDP attribute the B2BUA does not understand, the B2BUA still generates that SDP attribute in the Offer for the outgoing call leg. Consider a B2BUA that did not understand the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. Further assume that the B2BUA was configured to tear down any call where it did not see any RTCP for 5 minutes. In this case, if the B2BUA received an Offer like: Holmberg, et al. Expires June 18, 2019 [Page 67] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtcp:53020 It would be looking for RTCP on port 49171 but would not see any because the RTCP would be on port 53020 and after five minutes, it would tear down the call. Similarly, a B2BUA that did not understand BUNDLE yet put BUNDLE in its offer may be looking for media on the wrong port and tear down the call. It is worth noting that a B2BUA that generated an Offer with capabilities it does not understand is not compliant with the specifications. A.3.1. Traffic Policing Sometimes intermediaries do not act as B2BUAs, in the sense that they don't modify SDP bodies, nor do they terminate SIP dialogs. Still, however, they may use SDP information (e.g., IP address and port) in order to control traffic gating functions, and to set traffic policing rules. There might be rules which will trigger a session to be terminated in case media is not sent or received on the ports retrieved from the SDP. This typically occurs once the session is already established and ongoing. A.3.2. Bandwidth Allocation Sometimes intermediaries do not act as B2BUAs, in the sense that they don't modify SDP bodies, nor do they terminate SIP dialogs. Still, however, they may use SDP information (e.g., codecs and media types) in order to control bandwidth allocation functions. The bandwidth allocation is done per "m=" section, which means that it might not be enough if media specified by all "m=" sections try to use that bandwidth. That may either simply lead to bad user experience, or to termination of the call. A.4. Candidate Gathering When using ICE, a candidate needs to be gathered for each port. This takes approximately 20 ms extra for each extra "m=" section due to the NAT pacing requirements. All of this gathering can be overlapped Holmberg, et al. Expires June 18, 2019 [Page 68] Internet-Draft Bundled media December 2018 with other things while e.g., a web-page is loading to minimize the impact. If the client only wants to generate TURN or STUN ICE candidates for one of the "m=" lines and then use trickle ICE [I-D.ietf-ice-trickle] to get the non host ICE candidates for the rest of the "m=" sections, it MAY do that and will not need any additional gathering time. Some people have suggested a TURN extension to get a bunch of TURN allocations at once. This would only provide a single STUN result so in cases where the other end did not support BUNDLE, it may cause more use of the TURN server but would be quick in the cases where both sides supported BUNDLE and would fall back to a successful call in the other cases. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Harald Tveit Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada Email: fluffy@iii.ca Holmberg, et al. Expires June 18, 2019 [Page 69] ./draft-ietf-rmcat-cc-requirements-09.txt0000644000764400076440000007113312442534420017600 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-mmusic-sdp-mux-attributes-17.txt0000644000764400076440000071135413245463173020457 0ustar iustyiusty Network Working Group S. Nandakumar Internet-Draft Cisco Intended status: Standards Track February 28, 2018 Expires: September 1, 2018 A Framework for SDP Attributes when Multiplexing draft-ietf-mmusic-sdp-mux-attributes-17 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 September 1, 2018. Copyright Notice Copyright (c) 2018 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 September 1, 2018 [Page 1] Internet-Draft SDP Attribute Multiplexing February 2018 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 . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Category: TRANSPORT . . . . . . . . . . . . . . . . . . . 9 4.6. Category: INHERIT . . . . . . . . . . . . . . . . . . . . 10 4.7. Category: IDENTICAL-PER-PT . . . . . . . . . . . . . . . 11 4.8. Category: SPECIAL . . . . . . . . . . . . . . . . . . . . 12 4.9. Category: TBD . . . . . . . . . . . . . . . . . . . . . . 12 5. Analysis of Existing Attributes . . . . . . . . . . . . . . . 12 5.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 13 5.2. RFC4585: RTP/AVPF . . . . . . . . . . . . . . . . . . . . 14 5.3. RFC5761: Multiplexing RTP and RTCP . . . . . . . . . . . 15 5.4. RFC3312: Integration of Resource Management and SIP . . . 15 5.5. RFC4574: SDP Label Attribute . . . . . . . . . . . . . . 16 5.6. RFC5432: QOS Mechanism Selection in SDP . . . . . . . . . 16 5.7. RFC4568: SDP Security Descriptions . . . . . . . . . . . 17 5.8. RFC5762: RTP over DCCP . . . . . . . . . . . . . . . . . 17 5.9. RFC6773: DCCP-UDP Encapsulation . . . . . . . . . . . . . 18 5.10. RFC5506: Reduced-Size RTCP in RTP Profile . . . . . . . . 19 5.11. RFC6787: Media Resource Control Protocol Version 2 . . . 19 5.12. RFC5245: ICE . . . . . . . . . . . . . . . . . . . . . . 20 5.13. RFC5285: RTP Header Extensions . . . . . . . . . . . . . 21 5.14. RFC3605: RTCP attribute in SDP . . . . . . . . . . . . . 22 5.15. RFC5576: Source-Specific SDP Attributes . . . . . . . . . 22 5.16. RFC7273: RTP Clock Source Signalling . . . . . . . . . . 23 5.17. RFC6236: Image Attributes in SDP . . . . . . . . . . . . 24 5.18. RFC7197: Duplication Delay Attribute in SDP . . . . . . . 25 5.19. RFC7266: RTCP XR Blocks for MOS Metric Reporting . . . . 25 5.20. RFC6285: Rapid Acquisition of Multicast RTP Sessions . . 25 5.21. RFC6230: Media Control Channel Framework . . . . . . . . 26 5.22. RFC6364: SDP Elements for FEC Framework . . . . . . . . . 26 5.23. RFC4796: Content Attribute . . . . . . . . . . . . . . . 27 5.24. RFC3407: SDP Simple Capability Declaration . . . . . . . 27 5.25. RFC6284: Port Mapping between Unicast and Multicast RTP Sessions . . . . . . . . . . . . . . . . . . . . . . . . 28 5.26. RFC6714: MSRP-CEMA . . . . . . . . . . . . . . . . . . . 29 5.27. RFC4583: SDP Format for BFCP Streams . . . . . . . . . . 29 Nandakumar Expires September 1, 2018 [Page 2] Internet-Draft SDP Attribute Multiplexing February 2018 5.28. RFC5547: SDP Offer/Answer for File Transfer . . . . . . . 30 5.29. RFC6849: SDP and RTP Media Loopback Extension . . . . . . 30 5.30. RFC5760: RTCP with Unicast Feedback . . . . . . . . . . . 31 5.31. RFC3611: RTCP XR . . . . . . . . . . . . . . . . . . . . 31 5.32. RFC5939: SDP Capability Negotiation . . . . . . . . . . . 32 5.33. RFC6871: SDP Media Capabilities Negotiation . . . . . . . 32 5.34. RFC7006: Miscellaneous Capabilities Negotiation SDP . . . 33 5.35. RFC4567: Key Management Extensions for SDP and RTSP . . . 34 5.36. RFC4572: Comedia over TLS in SDP . . . . . . . . . . . . 35 5.37. RFC4570: SDP Source Filters . . . . . . . . . . . . . . . 35 5.38. RFC6128: RTCP Port for Multicast Sessions . . . . . . . . 36 5.39. RFC6189: ZRTP . . . . . . . . . . . . . . . . . . . . . . 36 5.40. RFC4145: Connection-Oriented Media . . . . . . . . . . . 37 5.41. RFC6947: The SDP altc Attribute . . . . . . . . . . . . . 37 5.42. RFC7195: SDP Extension for Circuit Switched Bearers in PSTN . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.43. RFC7272: IDMS Using the RTP Control Protocol (RTCP) . . . 38 5.44. RFC5159: Open Mobile Alliance (OMA) Broadcast (BCAST) SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 39 5.45. RFC6193: Media Description for IKE in SDP . . . . . . . . 39 5.46. RFC2326: Real Time Streaming Protocol . . . . . . . . . . 40 5.47. RFC6064: SDP and RTSP Extensions for 3GPP . . . . . . . . 41 5.48. RFC3108: ATM SDP . . . . . . . . . . . . . . . . . . . . 43 5.49. 3GPP TS 26.114 . . . . . . . . . . . . . . . . . . . . . 45 5.50. 3GPP TS 183.063 . . . . . . . . . . . . . . . . . . . . . 46 5.51. 3GPP TS 24.182 . . . . . . . . . . . . . . . . . . . . . 46 5.52. 3GPP TS 24.183 . . . . . . . . . . . . . . . . . . . . . 47 5.53. 3GPP TS 24.229 . . . . . . . . . . . . . . . . . . . . . 47 5.54. ITU T.38 . . . . . . . . . . . . . . . . . . . . . . . . 48 5.55. ITU-T Q.1970 . . . . . . . . . . . . . . . . . . . . . . 50 5.56. ITU-T H.248.15 . . . . . . . . . . . . . . . . . . . . . 50 5.57. RFC4975: The Message Session Relay Protocol . . . . . . . 51 5.58. Historical Attributes . . . . . . . . . . . . . . . . . . 52 6. bwtype Attribute Analysis . . . . . . . . . . . . . . . . . . 52 6.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 53 6.2. RFC3556: SDP Bandwidth Modifiers for RTCP Bandwidth . . . 53 6.3. RFC3890: Bandwidth Modifier for SDP . . . . . . . . . . . 54 7. rtcp-fb Attribute Analysis . . . . . . . . . . . . . . . . . 54 7.1. RFC4585: RTP/AVPF . . . . . . . . . . . . . . . . . . . . 54 7.2. RFC5104: Codec Control Messages in AVPF . . . . . . . . . 55 7.3. RFC6285: Unicast-Based Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . . . . . . . . . . . . . . . . 56 7.4. RFC6679: ECN for RTP over UDP/IP . . . . . . . . . . . . 56 7.5. RFC6642: Third-Party Loss Report . . . . . . . . . . . . 57 7.6. RFC5104: Codec Control Messages in AVPF . . . . . . . . . 58 8. group Attribute Analysis . . . . . . . . . . . . . . . . . . 58 8.1. RFC5888: SDP Grouping Framework . . . . . . . . . . . . . 58 8.2. RFC3524: Mapping Media Streams to Resource Nandakumar Expires September 1, 2018 [Page 3] Internet-Draft SDP Attribute Multiplexing February 2018 Reservation Flows . . . . . . . . . . . . . . . . . . . . 59 8.3. RFC4091: ANAT Semantics . . . . . . . . . . . . . . . . . 59 8.4. RFC5956: FEC Grouping Semantics in SDP . . . . . . . . . 59 8.5. RFC5583: Signaling Media Decoding Dependency in SDP . . . 60 8.6. RFC7104: Duplication Grouping Semantics in the SDP . . . 60 9. ssrc-group Attribute Analysis . . . . . . . . . . . . . . . . 61 9.1. RFC5576: Source-Specific SDP Attributes . . . . . . . . . 61 9.2. RFC7104: Duplication Grouping Semantics in the SDP . . . 61 10. QoS Mechanism Token Analysis . . . . . . . . . . . . . . . . 62 10.1. RFC5432: QoS Mechanism Selection in SDP . . . . . . . . 62 11. k= Attribute Analysis . . . . . . . . . . . . . . . . . . . . 62 11.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 63 12. content Attribute Analysis . . . . . . . . . . . . . . . . . 63 12.1. RFC4796 . . . . . . . . . . . . . . . . . . . . . . . . 63 13. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 64 13.1. RFC5109: RTP Payload Format for Generic FEC . . . . . . 64 14. Multiplexing Considerations for Encapsulating Attributes . . 64 14.1. RFC3407: cpar Attribute Analysis . . . . . . . . . . . . 65 14.2. RFC5939 Analysis . . . . . . . . . . . . . . . . . . . . 65 14.2.1. Recommendation: Procedures for Potential Configuration Pairing . . . . . . . . . . . . . . . 66 14.2.1.1. Example: Transport Capability Multiplexing . . . 67 14.2.1.2. Example: Attribute Capability Multiplexing . . . 68 14.3. RFC6871 Analysis . . . . . . . . . . . . . . . . . . . . 69 14.3.1. Recommendation: Dealing with Payload Type Numbers . 69 14.3.1.1. Example: Attribute Capability Under Shared Payload Type . . . . . . . . . . . . . . . . . . 69 14.3.2. Recommendation: Dealing with Latent Configurations . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 15.1. New 'Multiplexing Categories' subregistry . . . . . . . 71 15.2. 'Mux Category' column for subregistries . . . . . . . . 72 15.2.1. Table: SDP bwtype . . . . . . . . . . . . . . . . . 72 15.2.2. Table: att-field (session level) . . . . . . . . . . 72 15.2.3. Table: att-field (both session and media level) . . 73 15.2.4. Table: att-field (media level only) . . . . . . . . 75 15.2.5. Table: att-field (source level) . . . . . . . . . . 78 15.2.6. Table: content SDP Parameters . . . . . . . . . . . 79 15.2.7. Table: Semantics for the 'group' SDP Attribute . . . 79 15.2.8. Table: 'rtcp-fb' Attribute Values . . . . . . . . . 80 15.2.9. Table: 'ack' and 'nack' Attribute Values . . . . . . 80 15.2.10. Table: 'depend' SDP Attribute Values . . . . . . . . 80 15.2.11. Table: 'cs-correlation' Attribute Values . . . . . . 81 15.2.12. Table: Semantics for the 'ssrc-group' SDP Attribute 81 15.2.13. Table: SDP/RTSP key management protocol identifiers 81 15.2.14. Table: Codec Control Messages . . . . . . . . . . . 82 15.2.15. Table: QoS Mechanism Tokens . . . . . . . . . . . . 82 15.2.16. Table: SDP Capability Negotiation Option Tags . . . 82 15.2.17. Table: Timestamp Reference Clock Source Parameters . 83 Nandakumar Expires September 1, 2018 [Page 4] Internet-Draft SDP Attribute Multiplexing February 2018 15.2.18. Table: Media Clock Source Parameters . . . . . . . . 83 16. Security Considerations . . . . . . . . . . . . . . . . . . . 84 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 84 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 19.1. Normative References . . . . . . . . . . . . . . . . . . 88 19.2. Informative References . . . . . . . . . . . . . . . . . 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 97 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 September 1, 2018 [Page 5] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 6] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 7] Internet-Draft SDP Attribute Multiplexing February 2018 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 Note: Eventhough IDENTICAL attributes must be repeated across all media descriptions under multiplexing, they might not always be explicitly encoded across all media descriptions. [I-D.ietf-mmusic-sdp-bundle-negotiation] defines rules for when attributes and their values are implicitly applied to media description. Nandakumar Expires September 1, 2018 [Page 8] Internet-Draft SDP Attribute Multiplexing February 2018 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 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. Nandakumar Expires September 1, 2018 [Page 9] Internet-Draft SDP Attribute Multiplexing February 2018 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 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). Nandakumar Expires September 1, 2018 [Page 10] Internet-Draft SDP Attribute Multiplexing February 2018 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. 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). Nandakumar Expires September 1, 2018 [Page 11] Internet-Draft SDP Attribute Multiplexing February 2018 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. 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 Nandakumar Expires September 1, 2018 [Page 12] Internet-Draft SDP Attribute Multiplexing February 2018 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 | | | | | configuration | | | | | | | | | orient | Not Impacted | M | NORMAL | | | | | | | framerate | The attribute value | M | IDENTICAL-PER- | | | MUST be same for a | | PT | | | given codec | | | | | configuration | | | | | | | | | quality | Not Impacted | M | NORMAL | Nandakumar Expires September 1, 2018 [Page 13] Internet-Draft SDP Attribute Multiplexing February 2018 | | | | | | 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 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. Nandakumar Expires September 1, 2018 [Page 14] Internet-Draft SDP Attribute Multiplexing February 2018 +---------+------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +---------+------------------------------+-------+------------------+ | rtcp- | Since RTCP feedback | M | IDENTICAL-PER- | | fb | attributes are Payload Type | | PT | | | (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- | RTP and RTCP Multiplexing affects | M | IDENTICAL | | mux | 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 September 1, 2018 [Page 15] Internet-Draft SDP Attribute Multiplexing February 2018 +-------+-----------------------+-------+--------------+ | 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 September 1, 2018 [Page 16] Internet-Draft SDP Attribute Multiplexing February 2018 +----------------+-----------------------+-------+--------------+ | 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 September 1, 2018 [Page 17] Internet-Draft SDP Attribute Multiplexing February 2018 +-------------------+--------------------------+---------+----------+ | Name | Notes | Current | Mux | | | | | Category | +-------------------+--------------------------+---------+----------+ | dccp-service- | If RFC6773 is not being | M | CAUTION | | code | 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- | Multiplexing is not recommended | M | CAUTION | | port | 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 September 1, 2018 [Page 18] Internet-Draft SDP Attribute Multiplexing February 2018 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- | Reduced size RTCP affects the | M | IDENTICAL | | rsize | 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 September 1, 2018 [Page 19] Internet-Draft SDP Attribute Multiplexing February 2018 +-----------+---------------+-------+--------------+ | 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 September 1, 2018 [Page 20] Internet-Draft SDP Attribute Multiplexing February 2018 +-------------------+---------------------------+-------+-----------+ | 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 one | B | TRANSPORT | | | that corresponds to the | | | | | "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | candidate | ice candidate MUST be the | M | TRANSPORT | | | one that corresponds to | | | | | the "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | remote- | ice remote candidate MUST | M | TRANSPORT | | candidates | 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 extensions in use in a session are signaled in the setup information for that session. Nandakumar Expires September 1, 2018 [Page 21] Internet-Draft SDP Attribute Multiplexing February 2018 +--------+---------------------------------------+-------+----------+ | 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 September 1, 2018 [Page 22] Internet-Draft SDP Attribute Multiplexing February 2018 +---------------+------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +---------------+------------------------+-------+------------------+ | ssrc | Refer to Notes below | M | NORMAL | | | | | | | ssrc-group | Refer to Section 9 for | M | NORMAL | | | specific analysis of | | | | | the grouping | | | | | semantics | | | | | | | | | cname | Not Impacted | SR | NORMAL | | | | | | | previous- | Refer to notes below | SR | NORMAL | | ssrc | | | | | | | | | | fmtp | The attribute value | SR | IDENTICAL-PER- | | | MUST be same for a | | PT | | | 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 September 1, 2018 [Page 23] Internet-Draft SDP Attribute Multiplexing February 2018 +--------------------+---------------+-------+--------------+ | 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 September 1, 2018 [Page 24] Internet-Draft SDP Attribute Multiplexing February 2018 +-----------+----------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +-----------+----------------------------+-------+------------------+ | imageattr | The attribute value MUST | M | IDENTICAL-PER- | | | be same for a given codec | | PT | | | 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 September 1, 2018 [Page 25] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 26] Internet-Draft SDP Attribute Multiplexing February 2018 +-----------------+------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+------------------------------+-------+----------+ | fec-source- | Refer to the document | M | SPECIAL | | flow | defining specific FEC | | | | | Scheme | | | | | | | | | fec-repair- | Refer to the document | M | SPECIAL | | flow | 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 September 1, 2018 [Page 27] Internet-Draft SDP Attribute Multiplexing February 2018 +----------+------------------------+-------+--------------+ | 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- | Not recommended, if port | M | CAUTION | | req | mapping is required by the | | | | | application | | | | | | | | +-----------------+------------------------------+-------+----------+ 5.25 RFC6284 Attribute Analysis Nandakumar Expires September 1, 2018 [Page 28] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 29] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 30] Internet-Draft SDP Attribute Multiplexing February 2018 +--------------------+-------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +--------------------+-------------------+-------+------------------+ | loopback rtp-pkt- | The attribute | M | IDENTICAL-PER- | | loopback | value MUST be | | PT | | | same for a given | | | | | codec | | | | | configuration | | | | | | | | | loopback rtp- | The attribute | M | IDENTICAL-PER- | | media-loopback | value MUST be | | PT | | | 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- | The attribute MUST be reported | M | IDENTICAL | | unicast | 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 September 1, 2018 [Page 31] Internet-Draft SDP Attribute Multiplexing February 2018 +----------+---------------+-------+--------------+ | 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 September 1, 2018 [Page 32] Internet-Draft SDP Attribute Multiplexing February 2018 +---------+-----------------------+-------+-------------------+ | 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 September 1, 2018 [Page 33] Internet-Draft SDP Attribute Multiplexing February 2018 +---------+-------------------------------------+-------+-----------+ | 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 be | B | IDENTICAL | | | 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- | Key management protocol MUST be | B | IDENTICAL | | mgmt | 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 September 1, 2018 [Page 34] Internet-Draft SDP Attribute Multiplexing February 2018 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- | The attribute MUST be | B | IDENTICAL | | filter | repeated across all "m=" | | | | | lines multiplexed | | | | | | | | +---------------+-------------------------------+-------+-----------+ 5.37 RFC4570 Attribute Analysis Nandakumar Expires September 1, 2018 [Page 35] Internet-Draft SDP Attribute Multiplexing February 2018 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- | Multicast RTCP port MUST be | B | IDENTICAL | | rtcp | 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- | zrtp-hash attribute MUST be the | M | TRANSPORT | | hash | one that corresponds to the "m=" | | | | | line chosen for setting up the | | | | | underlying transport flow | | | | | | | | +-----------+-----------------------------------+-------+-----------+ 5.39 RFC6189 Attribute Analysis Nandakumar Expires September 1, 2018 [Page 36] Internet-Draft SDP Attribute Multiplexing February 2018 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 the | B | TRANSPORT | | | one that corresponds to the "m=" | | | | | line chosen for setting up the | | | | | underlying transport flow. | | | | | | | | | connection | The connection attribute MUST be | B | TRANSPORT | | | 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 September 1, 2018 [Page 37] Internet-Draft SDP Attribute Multiplexing February 2018 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- | Refer to notes | M | TBD | | correlation:callerid | below | | | | | | | | | cs-correlation:uuie | Refer to notes | M | TBD | | | below | | | | | | | | | cs-correlation:dtmf | Refer to notes | M | TBD | | | below | | | | | | | | | cs- | Refer to notes | M | TBD | | correlation:external | 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 September 1, 2018 [Page 38] Internet-Draft SDP Attribute Multiplexing February 2018 +------------+---------------+-------+--------------+ | 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 September 1, 2018 [Page 39] Internet-Draft SDP Attribute Multiplexing February 2018 +------------------+-----------------------------+-------+----------+ | 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- | Unlikely to use IKE in the | B | CAUTION | | udpencap | 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 September 1, 2018 [Page 40] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 41] Internet-Draft SDP Attribute Multiplexing February 2018 | | | | | | 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 September 1, 2018 [Page 42] Internet-Draft SDP Attribute Multiplexing February 2018 | | | | | | 3GPP-QoE-Metrics:Buffer | Refer to | M | CAUTION | | Status | 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 | | | below | | | Nandakumar Expires September 1, 2018 [Page 43] Internet-Draft SDP Attribute Multiplexing February 2018 | 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 | | | below | | | Nandakumar Expires September 1, 2018 [Page 44] Internet-Draft SDP Attribute Multiplexing February 2018 | 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 September 1, 2018 [Page 45] Internet-Draft SDP Attribute Multiplexing February 2018 +---------------------+--------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +---------------------+--------------------------+-------+----------+ | 3gpp_sync_info | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem | | | | | | | | | 3gpp_MaxRecvSDUSize | Usage defined for the IP | M | NORMAL | | | 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 September 1, 2018 [Page 46] Internet-Draft SDP Attribute Multiplexing February 2018 +------------+----------------------------------+-------+-----------+ | 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 September 1, 2018 [Page 47] Internet-Draft SDP Attribute Multiplexing February 2018 +-----------------+-----------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+-----------------------------+-------+-----------+ | secondary- | secondary-realm MUST be | M | TRANSPORT | | realm | 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. Nandakumar Expires September 1, 2018 [Page 48] Internet-Draft SDP Attribute Multiplexing February 2018 +-----------------------+--------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-----------------------+--------------------+-------+--------------+ | T38FaxVersion | Refer to notes | M | TBD | | | below | | | | | | | | | T38MaxBitRate | Refer to notes | M | TBD | | | below | | | | | | | | | 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 Nandakumar Expires September 1, 2018 [Page 49] Internet-Draft SDP Attribute Multiplexing February 2018 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. 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 September 1, 2018 [Page 50] Internet-Draft SDP Attribute Multiplexing February 2018 +----------+-------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +----------+-------------------------------------+-------+----------+ | h248item | It is only applicable for signaling | B | SPECIAL | | | 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 September 1, 2018 [Page 51] Internet-Draft SDP Attribute Multiplexing February 2018 +----------------------+---------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------------------+---------------------+-------+--------------+ | accept-types | Refer to notes | M | TBD | | | below | | | | | | | | | accept-wrapped- | Refer to notes | M | TBD | | types | 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 September 1, 2018 [Page 52] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 53] Internet-Draft SDP Attribute Multiplexing February 2018 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 defined | B | SPECIAL | | | 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 September 1, 2018 [Page 54] Internet-Draft SDP Attribute Multiplexing February 2018 +---------+------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +---------+------------------------------+-------+------------------+ | ack | The attribute value MUST be | M | IDENTICAL-PER- | | rpsi | same for a given codec | | PT | | | configuration | | | | | | | | | ack | Feedback parameters MUST be | M | SPECIAL | | app | handled in the app specific | | | | | way when multiplexed | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | pli | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | sli | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | rpsi | same for a given codec | | PT | | | configuration | | | | | | | | | nack | Feedback parameters MUST be | M | SPECIAL | | app | handled in the app specific | | | | | way when multiplexed | | | | | | | | | trr- | The attribute value MUST be | M | IDENTICAL-PER- | | int | same for a given codec | | PT | | | 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 September 1, 2018 [Page 55] Internet-Draft SDP Attribute Multiplexing February 2018 +------+---------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +------+---------------------------------+-------+------------------+ | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | | same for a given codec | | PT | | | 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- | | rai | same for a given codec | | PT | | | 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 September 1, 2018 [Page 56] Internet-Draft SDP Attribute Multiplexing February 2018 +-----------------+-----------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+-----------------------------+-------+-----------+ | ecn-capable- | ECN markup are enabled at | M | IDENTICAL | | rtp | the RTP session level | | | | | | | | | nack ecn | This attribute enables ECN | M | IDENTICAL | | | 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- | | tllei | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | pslei | same for a given codec | | PT | | | configuration | | | | | | | | +---------+------------------------------+-------+------------------+ 7.5 RFC6642 Attribute Analysis Nandakumar Expires September 1, 2018 [Page 57] Internet-Draft SDP Attribute Multiplexing February 2018 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- | | fir | same for a given codec | | PT | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | tmmbr | same for a given codec | | PT | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | tstr | same for a given codec | | PT | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | vbcm | same for a given codec | | PT | | | 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 September 1, 2018 [Page 58] Internet-Draft SDP Attribute Multiplexing February 2018 +------------+---------------+-------+--------------+ | 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 September 1, 2018 [Page 59] Internet-Draft SDP Attribute Multiplexing February 2018 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 | The attribute value MUST | M | IDENTICAL-PER- | | lay | be same for a given codec | | PT | | | configuration | | | | | | | | | depend | The attribute value MUST | M | IDENTICAL-PER- | | mdc | be same for a given codec | | PT | | | 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 September 1, 2018 [Page 60] Internet-Draft SDP Attribute Multiplexing February 2018 +------------+---------------+-------+--------------+ | 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 September 1, 2018 [Page 61] Internet-Draft SDP Attribute Multiplexing February 2018 +-----------------+---------------+-------+--------------+ | 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 September 1, 2018 [Page 62] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 63] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 64] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 65] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 66] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 67] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 68] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 69] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 70] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 71] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 72] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 73] Internet-Draft SDP Attribute Multiplexing February 2018 +-------------------------+-------------------+ | 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 September 1, 2018 [Page 74] Internet-Draft SDP Attribute Multiplexing February 2018 | 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 September 1, 2018 [Page 75] Internet-Draft SDP Attribute Multiplexing February 2018 | 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 September 1, 2018 [Page 76] Internet-Draft SDP Attribute Multiplexing February 2018 | 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 September 1, 2018 [Page 77] Internet-Draft SDP Attribute Multiplexing February 2018 | 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 September 1, 2018 [Page 78] Internet-Draft SDP Attribute Multiplexing February 2018 +----------------+-------------------+ | 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 September 1, 2018 [Page 79] Internet-Draft SDP Attribute Multiplexing February 2018 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 September 1, 2018 [Page 80] Internet-Draft SDP Attribute Multiplexing February 2018 +-------+-------------------+ | 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 September 1, 2018 [Page 81] Internet-Draft SDP Attribute Multiplexing February 2018 +------------+--------------+ | 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 September 1, 2018 [Page 82] Internet-Draft SDP Attribute Multiplexing February 2018 +------------+--------------+ | 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 September 1, 2018 [Page 83] Internet-Draft SDP Attribute Multiplexing February 2018 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-16 Nandakumar Expires September 1, 2018 [Page 84] Internet-Draft SDP Attribute Multiplexing February 2018 o Added a clarification note on when to encode IDENTICAL attributes as suggested by Christer. Changes draft-ietf-mmusic-sdp-mux-attributes-15 o Updated Mux category for floorctrl to TBD 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 Nandakumar Expires September 1, 2018 [Page 85] Internet-Draft SDP Attribute Multiplexing February 2018 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 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. Nandakumar Expires September 1, 2018 [Page 86] Internet-Draft SDP Attribute Multiplexing February 2018 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. 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 Nandakumar Expires September 1, 2018 [Page 87] Internet-Draft SDP Attribute Multiplexing February 2018 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 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-48 (work in progress), January 2018. [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", 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] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", draft-ietf-mmusic- rfc4566bis-25 (work in progress), February 2018. Nandakumar Expires September 1, 2018 [Page 88] Internet-Draft SDP Attribute Multiplexing February 2018 [IANA] "Session Description Protocol (SDP) Parameters", . [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, . Nandakumar Expires September 1, 2018 [Page 89] Internet-Draft SDP Attribute Multiplexing February 2018 [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, . [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, . Nandakumar Expires September 1, 2018 [Page 90] Internet-Draft SDP Attribute Multiplexing February 2018 [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, . [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, . Nandakumar Expires September 1, 2018 [Page 91] Internet-Draft SDP Attribute Multiplexing February 2018 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, DOI 10.17487/RFC4796, February 2007, . [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, . Nandakumar Expires September 1, 2018 [Page 92] Internet-Draft SDP Attribute Multiplexing February 2018 [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, . [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, . Nandakumar Expires September 1, 2018 [Page 93] Internet-Draft SDP Attribute Multiplexing February 2018 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, . [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, . Nandakumar Expires September 1, 2018 [Page 94] Internet-Draft SDP Attribute Multiplexing February 2018 [RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, DOI 10.17487/RFC6364, October 2011, . [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, . Nandakumar Expires September 1, 2018 [Page 95] Internet-Draft SDP Attribute Multiplexing February 2018 [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, . [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", . Nandakumar Expires September 1, 2018 [Page 96] Internet-Draft SDP Attribute Multiplexing February 2018 Author's Address Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: snandaku@cisco.com Nandakumar Expires September 1, 2018 [Page 97] ./draft-ietf-rmcat-coupled-cc-09.txt0000644000764400076440000015201713527514705016522 0ustar iustyiusty RTP Media Congestion Avoidance Techniques (rmcat) S. Islam Internet-Draft M. Welzl Intended status: Experimental S. Gjessing Expires: February 23, 2020 University of Oslo August 22, 2019 Coupled congestion control for RTP media draft-ietf-rmcat-coupled-cc-09 Abstract When multiple congestion controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm, and provides suggestions on how to apply it to other congestion control 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 https://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 23, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Islam, et al. Expires February 23, 2020 [Page 1] Internet-Draft Coupled congestion control for RTP media August 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architectural overview . . . . . . . . . . . . . . . . . . . 5 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . 9 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 10 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. General recommendations . . . . . . . . . . . . . . . . . 11 7. Expected feedback from experiments . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Application to GCC . . . . . . . . . . . . . . . . . 16 Appendix B. Scheduling . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Example algorithm - Passive FSE . . . . . . . . . . 16 C.1. Example operation (passive) . . . . . . . . . . . . . . . 19 Appendix D. Change log . . . . . . . . . . . . . . . . . . . . . 23 D.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . 23 D.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 23 D.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 23 D.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 23 D.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 24 D.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 24 D.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 24 D.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . 24 D.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 24 D.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 24 D.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 24 D.2.5. Changes from -03 to -04 . . . . . . . . . . . . . . . 24 D.2.6. Changes from -04 to -05 . . . . . . . . . . . . . . . 25 D.2.7. Changes from -05 to -06 . . . . . . . . . . . . . . . 25 Islam, et al. Expires February 23, 2020 [Page 2] Internet-Draft Coupled congestion control for RTP media August 2019 D.2.8. Changes from -06 to -07 . . . . . . . . . . . . . . . 25 D.2.9. Changes from -07 to -08 . . . . . . . . . . . . . . . 25 D.2.10. Changes from -08 to -09 . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction When there is enough data to send, a congestion controller attempts to increase its sending rate until the path's capacity has been reached. Some controllers detect path capacity by increasing the sending rate further, until packets are ECN-marked [RFC8087] or dropped, and then decreasing the sending rate until that stops happening. This process inevitably creates undesirable queuing delay when multiple congestion-controlled connections traverse the same network bottleneck, and each connection overshoots the path capacity as it determines its sending rate. The Congestion Manager (CM) [RFC3124] couples flows by providing a single congestion controller. It is hard to implement because it requires an additional congestion controller and removes all per- connection congestion control functionality, which is quite a significant change to existing RTP based applications. This document presents a method to combine the behavior of congestion control mechanisms that is easier to implement than the Congestion Manager [RFC3124] and also requires less significant changes to existing RTP based applications. It attempts to roughly approximate the CM behavior by sharing information between existing congestion controllers. It is able to honor user-specified priorities, which is required by rtcweb [I-D.ietf-rtcweb-overview] [RFC7478]. The described mechanisms are believed safe to use, but are experimental and are presented for wider review and operational evaluation. 2. Definitions 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]. Available Bandwidth: The available bandwidth is the nominal link capacity minus the amount of traffic that traversed the link during a certain time interval, divided by that time interval. Bottleneck: The first link with the smallest available bandwidth along the path between a sender and receiver. Islam, et al. Expires February 23, 2020 [Page 3] Internet-Draft Coupled congestion control for RTP media August 2019 Flow: A flow is the entity that congestion control is operating on. It could, for example, be a transport layer connection, or an RTP stream [RFC7656], whether or not this RTP stream is multiplexed onto an RTP session with other RTP streams. Flow Group Identifier (FGI): A unique identifier for each subset of flows that is limited by a common bottleneck. Flow State Exchange (FSE): The entity that maintains information that is exchanged between flows. Flow Group (FG): A group of flows having the same FGI. Shared Bottleneck Detection (SBD): The entity that determines which flows traverse the same bottleneck in the network, or the process of doing so. 3. Limitations Sender-side only: Shared bottlenecks can exist when multiple flows originate from the same sender, or when flows from different senders reach the same receiver (see [RFC8382], section 3). Coupled congestion control as described here only supports the former case, not the latter, as it operates inside a single host on the sender side. Shared bottlenecks do not change quickly: As per the definition above, a bottleneck depends on cross traffic, and since such traffic can heavily fluctuate, bottlenecks can change at a high frequency (e.g., there can be oscillation between two or more links). This means that, when flows are partially routed along different paths, they may quickly change between sharing and not sharing a bottleneck. For simplicity, here it is assumed that a shared bottleneck is valid for a time interval that is significantly longer than the interval at which congestion controllers operate. Note that, for the only SBD mechanism defined in this document (multiplexing on the same five-tuple), the notion of a shared bottleneck stays correct even in the presence of fast traffic fluctuations: since all flows that are assumed to share a bottleneck are routed in the same way, if the bottleneck changes, it will still be shared. Islam, et al. Expires February 23, 2020 [Page 4] Internet-Draft Coupled congestion control for RTP media August 2019 4. Architectural overview Figure 1 shows the elements of the architecture for coupled congestion control: the Flow State Exchange (FSE), Shared Bottleneck Detection (SBD) and Flows. The FSE is a storage element that can be implemented in two ways: active and passive. In the active version, it initiates communication with flows and SBD. However, in the passive version, it does not actively initiate communication with flows and SBD; its only active role is internal state maintenance (e.g., an implementation could use soft state to remove a flow's data after long periods of inactivity). Every time a flow's congestion control mechanism would normally update its sending rate, the flow instead updates information in the FSE and performs a query on the FSE, leading to a sending rate that can be different from what the congestion controller originally determined. Using information about/from the currently active flows, SBD updates the FSE with the correct Flow Group Identifiers (FGIs). This document describes both active and passive versions. While the passive algorithm works better for congestion controls with RTT- independent convergence, it can still produce oscillations on short time scales. The passive algorithm, described in Appendix C, is therefore considered as highly experimental and not safe to deploy outside of testbed environments. Figure 2 shows the interaction between flows and the FSE, using the variable names defined in Section 5.2. ------- <--- Flow 1 | FSE | <--- Flow 2 .. ------- <--- .. Flow N ^ | | ------- | | SBD | <-------| ------- Figure 1: Coupled congestion control architecture Islam, et al. Expires February 23, 2020 [Page 5] Internet-Draft Coupled congestion control for RTP media August 2019 Flow#1(cc) FSE Flow#2(cc) ---------- --- ---------- #1 JOIN ----register--> REGISTER REGISTER <--register-- JOIN #1 #2 CC_R(1) ----UPDATE----> UPDATE (in) #3 NEW RATE <---FSE_R(1)-- UPDATE (out) --FSE_R(2)-> #3 NEW RATE Figure 2: Flow-FSE interaction Since everything shown in Figure 1 is assumed to operate on a single host (the sender) only, this document only describes aspects that have an influence on the resulting on-the-wire behavior. It does not, for instance, define how many bits must be used to represent FGIs, or in which way the entities communicate. Implementations can take various forms: for instance, all the elements in the figure could be implemented within a single application, thereby operating on flows generated by that application only. Another alternative could be to implement both the FSE and SBD together in a separate process which different applications communicate with via some form of Inter-Process Communication (IPC). Such an implementation would extend the scope to flows generated by multiple applications. The FSE and SBD could also be included in the Operating System kernel. However, only one type of coupling algorithm should be used for all flows. Combinations of multiple algorithms at different aggregation levels (e.g., the Operating System coupling application aggregates with one algorithm, and applications coupling their flows with another) have not been tested and are therefore not recommended. 5. Roles This section gives an overview of the roles of the elements of coupled congestion control, and provides an example of how coupled congestion control can operate. 5.1. SBD SBD uses knowledge about the flows to determine which flows belong in the same Flow Group (FG), and assigns FGIs accordingly. This knowledge can be derived in three basic ways: 1. From multiplexing: it can be based on the simple assumption that packets sharing the same five-tuple (IP source and destination Islam, et al. Expires February 23, 2020 [Page 6] Internet-Draft Coupled congestion control for RTP media August 2019 address, protocol, and transport layer port number pair) and having the same values for the Differentiated Services Code Point (DSCP) and the ECN field in the IP header are typically treated in the same way along the path. This method is the only one specified in this document: SBD MAY consider all flows that use the same five-tuple, DSCP and ECN field value to belong to the same FG. This classification applies to certain tunnels, or RTP flows that are multiplexed over one transport (cf. [transport-multiplex]). Such multiplexing is also a recommended usage of RTP in rtcweb [rtcweb-rtp-usage]. 2. Via configuration: e.g. by assuming that a common wireless uplink is also a shared bottleneck. 3. From measurements: e.g. by considering correlations among measured delay and loss as an indication of a shared bottleneck. The methods above have some essential trade-offs: e.g., multiplexing is a completely reliable measure, however it is limited in scope to two end points (i.e., it cannot be applied to couple congestion controllers of one sender talking to multiple receivers). A measurement-based SBD mechanism is described in [RFC8382]. Measurements can never be 100% reliable, in particular because they are based on the past but applying coupled congestion control means to make an assumption about the future; it is therefore recommended to implement cautionary measures, e.g. by disabling coupled congestion control if enabling it causes a significant increase in delay and/or packet loss. Measurements also take time, which entails a certain delay for turning on coupling (refer to [RFC8382] for details). Using system configuration to decide about shared bottlenecks can be more efficient (faster to obtain) than using measurements, but it relies on assumptions about the network environment. 5.2. FSE The FSE contains a list of all flows that have registered with it. For each flow, it stores the following: o a unique flow number f to identify the flow. o the FGI of the FG that it belongs to (based on the definitions in this document, a flow has only one bottleneck, and can therefore be in only one FG). o a priority P(f), which is a positive number, greater than zero. o The rate used by the flow in bits per second, FSE_R(f). Islam, et al. Expires February 23, 2020 [Page 7] Internet-Draft Coupled congestion control for RTP media August 2019 o The desired rate DR(f) of flow f. This can be smaller than FSE_R(f) if the application feeding into the flow has less data to send than FSE_R(f) would allow, or if a maximum value is imposed on the rate. In the absence of such limits DR(f) must be set to the sending rate provided by the congestion control module of flow f. Note that the absolute range of priorities does not matter: the algorithm works with a flow's priority portion of the sum of all priority values. For example, if there are two flows, flow 1 with priority 1 and flow 2 with priority 2, the sum of the priorities is 3. Then, flow 1 will be assigned 1/3 of the aggregate sending rate and flow 2 will be assigned 2/3 of the aggregate sending rate. Priorities can be mapped to the "very-low", "low", "medium" or "high" priority levels described in [I-D.ietf-rtcweb-transports] by simply using the values 1, 2, 4 and 8, respectively. In the FSE, each FG contains one static variable S_CR which is the sum of the calculated rates of all flows in the same FG. This value is used to calculate the sending rate. The information listed here is enough to implement the sample flow algorithm given below. FSE implementations could easily be extended to store, e.g., a flow's current sending rate for statistics gathering or future potential optimizations. 5.3. Flows Flows register themselves with SBD and FSE when they start, deregister from the FSE when they stop, and carry out an UPDATE function call every time their congestion controller calculates a new sending rate. Via UPDATE, they provide the newly calculated rate and optionally (if the algorithm supports it) the desired rate. The desired rate is less than the calculated rate in case of application- limited flows; otherwise, it is the same as the calculated rate. Below, two example algorithms are described. While other algorithms could be used instead, the same algorithm must be applied to all flows. Names of variables used in the algorithms are explained below. o CC_R(f) - The rate received from the congestion controller of flow f when it calls UPDATE. o FSE_R(f) - The rate calculated by the FSE for flow f. o DR(f) - The desired rate of flow f. Islam, et al. Expires February 23, 2020 [Page 8] Internet-Draft Coupled congestion control for RTP media August 2019 o S_CR - The sum of the calculated rates of all flows in the same FG; this value is used to calculate the sending rate. o FG - A group of flows having the same FGI, and hence sharing the same bottleneck. o P(f) - The priority of flow f which is received from the flow's congestion controller; the FSE uses this variable for calculating FSE_R(f). o S_P - The sum of all the priorities. o TLO - The total leftover rate: the sum of rates that could not be assigned to flows that were limited by their desired rate. o AR - The aggregate rate that is assigned to flows that are not limited by their desired rate. 5.3.1. Example algorithm 1 - Active FSE This algorithm was designed to be the simplest possible method to assign rates according to the priorities of flows. Simulations results in [fse] indicate that it does however not significantly reduce queuing delay and packet loss. (1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) is initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR. (2) When a flow f stops or pauses, its entry is removed from the list. (3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), the flow calls UPDATE, which carries out the tasks listed below to derive the new sending rates for all the flows in the FG. A flow's UPDATE function uses three local (i.e. per-flow) temporary variables: S_P, TLO and AR. (a) It updates S_CR. S_CR = S_CR + CC_R(f) - FSE_R(f) (b) It calculates the sum of all the priorities, S_P, and initializes FSE_R. Islam, et al. Expires February 23, 2020 [Page 9] Internet-Draft Coupled congestion control for RTP media August 2019 S_P = 0 for all flows i in FG do S_P = S_P + P(i) FSE_R(i) = 0 end for (c) It distributes S_CR among all flows, ensuring that each flow's desired rate is not exceeded. TLO = S_CR while(TLO-AR>0 and S_P>0) AR = 0 for all flows i in FG do if FSE_R[i] < DR[i] then if TLO * P[i] / S_P >= DR[i] then TLO = TLO - DR[i] FSE_R[i] = DR[i] S_P = S_P - P[i] else FSE_R[i] = TLO * P[i] / S_P AR = AR + TLO * P[i] / S_P end if end if end for end while (d) It distributes FSE_R to all the flows. for all flows i in FG do send FSE_R(i) to the flow i end for 5.3.2. Example algorithm 2 - Conservative Active FSE This algorithm changes algorithm 1 to conservatively emulate the behavior of a single flow by proportionally reducing the aggregate rate on congestion. Simulations results in [fse] indicate that it can significantly reduce queuing delay and packet loss. Step (a) of the UPDATE function is changed as described below. This also introduces a local variable DELTA, which is used to calculate the difference between CC_R(f) and the previously stored FSE_R(f). To prevent flows from either ignoring congestion or overreacting, a timer keeps them from changing their rates immediately after the common rate reduction that follows a congestion event. This timer is set to 2 RTTs of the flow that experienced congestion because it is Islam, et al. Expires February 23, 2020 [Page 10] Internet-Draft Coupled congestion control for RTP media August 2019 assumed that a congestion event can persist for up to one RTT of that flow, with another RTT added to compensate for fluctuations in the measured RTT value. (a) It updates S_CR based on DELTA. if Timer has expired or was not set then DELTA = CC_R(f) - FSE_R(f) if DELTA < 0 then // Reduce S_CR proportionally S_CR = S_CR * CC_R(f) / FSE_R(f) Set Timer for 2 RTTs else S_CR = S_CR + DELTA end if end if 6. Application This section specifies how the FSE can be applied to specific congestion control mechanisms and makes general recommendations that facilitate applying the FSE to future congestion controls. 6.1. NADA Network-Assisted Dynamic Adapation (NADA) [I-D.ietf-rmcat-nada] is a congestion control scheme for rtcweb. It calculates a reference rate r_ref upon receiving an acknowledgment, and then, based on the reference rate, it calculates a video target rate r_vin and a sending rate for the flows, r_send. When applying the FSE to NADA, the UPDATE function call described in Section 5.3 gives the FSE NADA's reference rate r_ref. The recommended algorithm for NADA is the Active FSE in Section 5.3.1. In step 3 (c), when the FSE_R(i) is "sent" to the flow i, this means updating r_ref(r_vin and r_send) of flow i with the value of FSE_R(i). 6.2. General recommendations This section provides general advice for applying the FSE to congestion control mechanisms. Receiver-side calculations: When receiver-side calculations make assumptions about the rate of the sender, the calculations need to be synchronized or the receiver needs to be updated accordingly. This applies to TFRC [RFC5348], for example, where simulations showed somewhat less Islam, et al. Expires February 23, 2020 [Page 11] Internet-Draft Coupled congestion control for RTP media August 2019 favorable results when using the FSE without a receiver-side change [fse]. Stateful algorithms: When a congestion control algorithm is stateful (e.g., TCP, with Slow Start, Congestion Avoidance and Fast Recovery), these states should be carefully considered such that the overall state of the aggregate flow is correct. This may require sharing more information in the UPDATE call. Rate jumps: The FSE-based coupling algorithms can let a flow quickly increase its rate to its fair share, e.g. when a new flow joins or after a quiescent period. In case of window-based congestion controls, this may produce a burst which should be mitigated in some way. An example of how this could be done without using a timer is presented in [anrw2016], using TCP as an example. 7. Expected feedback from experiments The algorithm described in this memo has so far been evaluated using simulations covering all the tests for more than one flow from [I-D.ietf-rmcat-eval-test] (see [IETF-93], [IETF-94]). Experiments should confirm these results using at least the NADA congestion control algorithm with real-life code (e.g., browsers communicating over an emulated network covering the conditions in [I-D.ietf-rmcat-eval-test]. The tests with real-life code should be repeated afterwards in real network environments and monitored. Experiments should investigate cases where the media coder's output rate is below the rate that is calculated by the coupling algorithm (FSE_R(i) in algorithms 1 and 2, section 5.3). Implementers and testers are invited to document their findings in an Internet draft. 8. Acknowledgements This document has benefitted from discussions with and feedback from Andreas Petlund, Anna Brunstrom, Colin Perkins, David Hayes, David Ros (who also gave the FSE its name), Ingemar Johansson, Karen Nielsen, Kristian Hiorth, Mirja Kuehlewind, Martin Stiemerling, Spencer Dawkins, Varun Singh, Xiaoqing Zhu, and Zaheduzzaman Sarker. The authors would like to especially thank Xiaoqing Zhu and Stefan Holmer for helping with NADA and GCC, and Anna Brunstrom as well as Julius Flohr for helping us correct the active algorithm for the case of application-limited flows. Islam, et al. Expires February 23, 2020 [Page 12] Internet-Draft Coupled congestion control for RTP media August 2019 This work was partially funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). 9. IANA Considerations This memo includes no request to IANA. 10. Security Considerations In scenarios where the architecture described in this document is applied across applications, various cheating possibilities arise: e.g., supporting wrong values for the calculated rate, the desired rate, or the priority of a flow. In the worst case, such cheating could either prevent other flows from sending or make them send at a rate that is unreasonably large. The end result would be unfair behavior at the network bottleneck, akin to what could be achieved with any UDP based application. Hence, since this is no worse than UDP in general, there seems to be no significant harm in using this in the absence of UDP rate limiters. In the case of a single-user system, it should also be in the interest of any application programmer to give the user the best possible experience by using reasonable flow priorities or even letting the user choose them. In a multi-user system, this interest may not be given, and one could imagine the worst case of an "arms race" situation, where applications end up setting their priorities to the maximum value. If all applications do this, the end result is a fair allocation in which the priority mechanism is implicitly eliminated, and no major harm is done. Implementers should also be aware of the Security Considerations sections of [RFC3124], [RFC5348], and [RFC7478]. 11. References 11.1. Normative References [I-D.ietf-rmcat-nada] Zhu, X., *, R., Ramalho, M., Cruz, S., Jones, P., Fu, J., and S. D'Aronco, "NADA: A Unified Congestion Control Scheme for Real-Time Media", draft-ietf-rmcat-nada-11 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Islam, et al. Expires February 23, 2020 [Page 13] Internet-Draft Coupled congestion control for RTP media August 2019 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, DOI 10.17487/RFC3124, June 2001, . [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, . 11.2. Informative References [anrw2016] Islam, S. and M. Welzl, "Start Me Up:Determining and Sharing TCP's Initial Congestion Window", ACM, IRTF, ISOC Applied Networking Research Workshop 2016 (ANRW 2016) , 2016. [fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi, "Coupled Congestion Control for RTP Media", ACM SIGCOMM Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR 44(4) 2014; extended version available as a technical report from http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf , 2014. [fse-noms] Islam, S., Welzl, M., Hayes, D., and S. Gjessing, "Managing Real-Time Media Flows through a Flow State Exchange", IEEE NOMS 2016, Istanbul, Turkey , 2016. [I-D.ietf-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- eval-test-10 (work in progress), May 2019. [I-D.ietf-rmcat-gcc] Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real- Time Communication", draft-ietf-rmcat-gcc-02 (work in progress), July 2016. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-19 (work in progress), November 2017. Islam, et al. Expires February 23, 2020 [Page 14] Internet-Draft Coupled congestion control for RTP media August 2019 [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", Internet-draft draft-ietf-rtcweb-transports-17.txt, October 2016. [IETF-93] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled Congestion Control for RTP Media", July 2015, . [IETF-94] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled Congestion Control for RTP Media", November 2015, . [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 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, . [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, . [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, "Shared Bottleneck Detection for Coupled Congestion Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, June 2018, . [rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Internet-draft draft-ietf-rtcweb-rtp-usage-26.txt, March 2016. [transport-multiplex] Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Single Lower-Layer Transport", Internet-draft draft- westerlund-avtcore-transport-multiplexing-07.txt, October 2013. Islam, et al. Expires February 23, 2020 [Page 15] Internet-Draft Coupled congestion control for RTP media August 2019 Appendix A. Application to GCC Google Congestion Control (GCC) [I-D.ietf-rmcat-gcc] is another congestion control scheme for RTP flows that is under development. GCC is not yet finalised, but at the time of this writing, the rate control of GCC employs two parts: controlling the bandwidth estimate based on delay, and controlling the bandwidth estimate based on loss. Both are designed to estimate the available bandwidth, A_hat. When applying the FSE to GCC, the UPDATE function call described in Section 5.3 gives the FSE GCC's estimate of available bandwidth A_hat. The recommended algorithm for GCC is the Active FSE in Section 5.3.1. In step 3 (c), when the FSE_R(i) is "sent" to the flow i, this means updating A_hat of flow i with the value of FSE_R(i). Appendix B. Scheduling When flows originate from the same host, it would be possible to use only one single sender-side congestion controller which determines the overall allowed sending rate, and then use a local scheduler to assign a proportion of this rate to each RTP session. This way, priorities could also be implemented as a function of the scheduler. The Congestion Manager (CM) [RFC3124] also uses such a scheduling function. Appendix C. Example algorithm - Passive FSE Active algorithms calculate the rates for all the flows in the FG and actively distribute them. In a passive algorithm, UPDATE returns a rate that should be used instead of the rate that the congestion controller has determined. This can make a passive algorithm easier to implement; however, when round-trip times of flows are unequal, shorter-RTT flows may (depending on the congestion control algorithm) update and react to the overall FSE state more often than longer-RTT flows, which can produce unwanted side effects. This problem is more significant when the congestion control convergence depends on the RTT. While the passive algorithm works better for congestion controls with RTT-independent convergence, it can still produce oscillations on short time scales. The algorithm described below is therefore considered as highly experimental and not safe to deploy outside of testbed environments. Results of a simplified passive FSE algorithm with both NADA and GCC can be found in [fse-noms]. In the passive version of the FSE, TLO (the Total Leftover Rate) is a static variable per FG which is initialized to 0. Additionally, S_CR is limited to increase or decrease as conservatively as a flow's congestion controller decides in order to prohibit sudden rate jumps. Islam, et al. Expires February 23, 2020 [Page 16] Internet-Draft Coupled congestion control for RTP media August 2019 (1) When a flow f starts, it registers itself with SBD and the FSE. FSE_R(f) and DR(f) are initialized with the congestion controller's initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R(f) to S_CR. (2) When a flow f stops or pauses, it sets its DR(f) to 0 and sets P(f) to -1. (3) Every time the congestion controller of the flow f determines a new sending rate CC_R(f), assuming the flow's new desired rate new_DR(f) to be "infinity" in case of a bulk data transfer with an unknown maximum rate, the flow calls UPDATE, which carries out the tasks listed below to derive the flow's new sending rate, Rate(f). A flow's UPDATE function uses a few local (i.e. per-flow) temporary variables, which are all initialized to 0: DELTA, new_S_CR and S_P. (a) For all the flows in its FG (including itself), it calculates the sum of all the calculated rates, new_S_CR. Then it calculates DELTA: the difference between FSE_R(f) and CC_R(f). for all flows i in FG do new_S_CR = new_S_CR + FSE_R(i) end for DELTA = CC_R(f) - FSE_R(f) (b) It updates S_CR, FSE_R(f) and DR(f). FSE_R(f) = CC_R(f) if DELTA > 0 then // the flow's rate has increased S_CR = S_CR + DELTA else if DELTA < 0 then S_CR = new_S_CR + DELTA end if DR(f) = min(new_DR(f),FSE_R(f)) (c) It calculates the leftover rate TLO, removes the terminated flows from the FSE and calculates the sum of all the priorities, S_P. Islam, et al. Expires February 23, 2020 [Page 17] Internet-Draft Coupled congestion control for RTP media August 2019 for all flows i in FG do if P(i)<0 then delete flow else S_P = S_P + P(i) end if end for if DR(f) < FSE_R(f) then TLO = TLO + (P(f)/S_P) * S_CR - DR(f)) end if (d) It calculates the sending rate, Rate(f). Rate(f) = min(new_DR(f), (P(f)*S_CR)/S_P + TLO) if Rate(f) != new_DR(f) and TLO > 0 then TLO = 0 // f has 'taken' TLO end if (e) It updates DR(f) and FSE_R(f) with Rate(f). if Rate(f) > DR(f) then DR(f) = Rate(f) end if FSE_R(f) = Rate(f) The goals of the flow algorithm are to achieve prioritization, improve network utilization in the face of application-limited flows, and impose limits on the increase behavior such that the negative impact of multiple flows trying to increase their rate together is minimized. It does that by assigning a flow a sending rate that may not be what the flow's congestion controller expected. It therefore builds on the assumption that no significant inefficiencies arise from temporary application-limited behavior or from quickly jumping to a rate that is higher than the congestion controller intended. How problematic these issues really are depends on the controllers in use and requires careful per-controller experimentation. The coupled congestion control mechanism described here also does not require all controllers to be equal; effects of heterogeneous controllers, or homogeneous controllers being in different states, are also subject to experimentation. This algorithm gives all the leftover rate of application-limited flows to the first flow that updates its sending rate, provided that this flow needs it all (otherwise, its own leftover rate can be taken by the next flow that updates its rate). Other policies could be Islam, et al. Expires February 23, 2020 [Page 18] Internet-Draft Coupled congestion control for RTP media August 2019 applied, e.g. to divide the leftover rate of a flow equally among all other flows in the FGI. C.1. Example operation (passive) In order to illustrate the operation of the passive coupled congestion control algorithm, this section presents a toy example of two flows that use it. Let us assume that both flows traverse a common 10 Mbit/s bottleneck and use a simplistic congestion controller that starts out with 1 Mbit/s, increases its rate by 1 Mbit/s in the absence of congestion and decreases it by 2 Mbit/s in the presence of congestion. For simplicity, flows are assumed to always operate in a round-robin fashion. Rate numbers below without units are assumed to be in Mbit/s. For illustration purposes, the actual sending rate is also shown for every flow in FSE diagrams even though it is not really stored in the FSE. Flow #1 begins. It is a bulk data transfer and considers itself to have top priority. This is the FSE after the flow algorithm's step 1: ---------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 1 | 1 | 1 | ---------------------------------------- S_CR = 1, TLO = 0 Its congestion controller gradually increases its rate. Eventually, at some point, the FSE should look like this: ----------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 10 | 10 | 10 | ----------------------------------------- S_CR = 10, TLO = 0 Now another flow joins. It is also a bulk data transfer, and has a lower priority (0.5): Islam, et al. Expires February 23, 2020 [Page 19] Internet-Draft Coupled congestion control for RTP media August 2019 ------------------------------------------ | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 10 | 10 | 10 | | 2 | 1 | 0.5 | 1 | 1 | 1 | ------------------------------------------ S_CR = 11, TLO = 0 Now assume that the first flow updates its rate to 8, because the total sending rate of 11 exceeds the total capacity. Let us take a closer look at what happens in step 3 of the flow algorithm. CC_R(1) = 8. new_DR(1) = infinity. 3 a) new_S_CR = 11; DELTA = 8 - 10 = -2. 3 b) FSE_R(1) = 8. DELTA is negative, hence S_CR = 9; DR(1) = 8. 3 c) S_P = 1.5. 3 d) new sending rate Rate(1) = min(infinity, 1/1.5 * 9 + 0) = 6. 3 e) FSE_R(1) = 6. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 6 | 8 | 6 | | 2 | 1 | 0.5 | 1 | 1 | 1 | ------------------------------------------- S_CR = 9, TLO = 0 The effect is that flow #1 is sending with 6 Mbit/s instead of the 8 Mbit/s that the congestion controller derived. Let us now assume that flow #2 updates its rate. Its congestion controller detects that the network is not fully saturated (the actual total sending rate is 6+1=7) and increases its rate. Islam, et al. Expires February 23, 2020 [Page 20] Internet-Draft Coupled congestion control for RTP media August 2019 CC_R(2) = 2. new_DR(2) = infinity. 3 a) new_S_CR = 7; DELTA = 2 - 1 = 1. 3 b) FSE_R(2) = 2. DELTA is positive, hence S_CR = 9 + 1 = 10; DR(2) = 2. 3 c) S_P = 1.5. 3 d) Rate(2) = min(infinity, 0.5/1.5 * 10 + 0) = 3.33. 3 e) DR(2) = FSE_R(2) = 3.33. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 6 | 8 | 6 | | 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 | ------------------------------------------- S_CR = 10, TLO = 0 The effect is that flow #2 is now sending with 3.33 Mbit/s, which is close to half of the rate of flow #1 and leads to a total utilization of 6(#1) + 3.33(#2) = 9.33 Mbit/s. Flow #2's congestion controller has increased its rate faster than the controller actually expected. Now, flow #1 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate. Additionally, the application feeding into flow #1 limits the flow's sending rate to at most 2 Mbit/s. CC_R(1) = 7. new_DR(1) = 2. 3 a) new_S_CR = 9.33; DELTA = 1. 3 b) FSE_R(1) = 7, DELTA is positive, hence S_CR = 10 + 1 = 11; DR(1) = min(2, 7) = 2. 3 c) S_P = 1.5; DR(1) < FSE_R(1), hence TLO = 1/1.5 * 11 - 2 = 5.33. 3 d) Rate(1) = min(2, 1/1.5 * 11 + 5.33) = 2. 3 e) FSE_R(1) = 2. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 2 | 2 | 2 | | 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 | ------------------------------------------- S_CR = 11, TLO = 5.33 Islam, et al. Expires February 23, 2020 [Page 21] Internet-Draft Coupled congestion control for RTP media August 2019 Now, the total rate of the two flows is 2 + 3.33 = 5.33 Mbit/s, i.e. the network is significantly underutilized due to the limitation of flow #1. Flow #2 updates its rate. Its congestion controller detects that the network is not fully saturated and increases its rate. CC_R(2) = 4.33. new_DR(2) = infinity. 3 a) new_S_CR = 5.33; DELTA = 1. 3 b) FSE_R(2) = 4.33. DELTA is positive, hence S_CR = 12; DR(2) = 4.33. 3 c) S_P = 1.5. 3 d) Rate(2) = min(infinity, 0.5/1.5 * 12 + 5.33 ) = 9.33. 3 e) FSE_R(2) = 9.33, DR(2) = 9.33. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 1 | 1 | 1 | 2 | 2 | 2 | | 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 | ------------------------------------------- S_CR = 12, TLO = 0 Now, the total rate of the two flows is 2 + 9.33 = 11.33 Mbit/s. Finally, flow #1 terminates. It sets P(1) to -1 and DR(1) to 0. Let us assume that it terminated late enough for flow #2 to still experience the network in a congested state, i.e. flow #2 decreases its rate in the next iteration. Islam, et al. Expires February 23, 2020 [Page 22] Internet-Draft Coupled congestion control for RTP media August 2019 CC_R(2) = 7.33. new_DR(2) = infinity. 3 a) new_S_CR = 11.33; DELTA = -2. 3 b) FSE_R(2) = 7.33. DELTA is negative, hence S_CR = 9.33; DR(2) = 7.33. 3 c) Flow 1 has P(1) = -1, hence it is deleted from the FSE. S_P = 0.5. 3 d) Rate(2) = min(infinity, 0.5/0.5*9.33 + 0) = 9.33. 3 e) FSE_R(2) = DR(2) = 9.33. The resulting FSE looks as follows: ------------------------------------------- | # | FGI | P | FSE_R | DR | Rate | | | | | | | | | 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 | ------------------------------------------- S_CR = 9.33, TLO = 0 Appendix D. Change log D.1. draft-welzl-rmcat-coupled-cc D.1.1. Changes from -00 to -01 o Added change log. o Updated the example algorithm and its operation. D.1.2. Changes from -01 to -02 o Included an active version of the algorithm which is simpler. o Replaced "greedy flow" with "bulk data transfer" and "non-greedy" with "application-limited". o Updated new_CR to CC_R, and CR to FSE_R for better understanding. D.1.3. Changes from -02 to -03 o Included an active conservative version of the algorithm which reduces queue growth and packet loss; added a reference to a technical report that shows these benefits with simulations. o Moved the passive variant of the algorithm to appendix. Islam, et al. Expires February 23, 2020 [Page 23] Internet-Draft Coupled congestion control for RTP media August 2019 D.1.4. Changes from -03 to -04 o Extended SBD section. o Added a note about window-based controllers. D.1.5. Changes from -04 to -05 o Added a section about applying the FSE to specific congestion control algorithms, with a subsection specifying its use with NADA. D.2. draft-ietf-rmcat-coupled-cc D.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 o Moved scheduling section to the appendix. D.2.2. Changes from -00 to -01 o Included how to apply the algorithm to GCC. o Updated variable names of NADA to be in line with the latest version. o Added a reference to [I-D.ietf-rtcweb-transports] to make a connection to the prioritization text there. D.2.3. Changes from -01 to -02 o Minor changes. o Moved references of NADA and GCC from informative to normative. o Added a reference for the passive variant of the algorithm. D.2.4. Changes from -02 to -03 o Minor changes. o Added a section about expected feedback from experiments. D.2.5. Changes from -03 to -04 o Described the names of variables used in the algorithms. o Added a diagram to illustrate the interaction between flows and the FSE. Islam, et al. Expires February 23, 2020 [Page 24] Internet-Draft Coupled congestion control for RTP media August 2019 o Added text on the trade-off of using the configuration based approach. o Minor changes to enhance the readability. D.2.6. Changes from -04 to -05 o Changed several occurrences of "NADA and GCC" to "NADA", including the abstract. o Moved the application to GCC to an appendix, and made the GCC reference informative. o Provided a few more general recommendations on applying the coupling algorithm. D.2.7. Changes from -05 to -06 o Incorporated comments by Colin Perkins. D.2.8. Changes from -06 to -07 o Addressed OPSDIR, SECDIR, GENART, AD and IESG comments. D.2.9. Changes from -07 to -08 o Updated the algorithms in section 5 to support application-limited flows. Moved definition of Desired Rate from appendix to section 5. Updated references. D.2.10. Changes from -08 to -09 o Minor improvement of the algorithms in section 5. Authors' Addresses Safiqul Islam University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 84 08 37 Email: safiquli@ifi.uio.no Islam, et al. Expires February 23, 2020 [Page 25] Internet-Draft Coupled congestion control for RTP media August 2019 Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Stein Gjessing University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 44 Email: steing@ifi.uio.no Islam, et al. Expires February 23, 2020 [Page 26] ./draft-ietf-mmusic-sdp-simulcast-14.txt0000644000764400076440000027150513437433163017461 0ustar iustyiusty Network Working Group B. Burman Internet-Draft M. Westerlund Intended status: Standards Track Ericsson Expires: September 6, 2019 S. Nandakumar M. Zanaty Cisco March 5, 2019 Using Simulcast in SDP and RTP Sessions draft-ietf-mmusic-sdp-simulcast-14 Abstract In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. 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 https://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 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Burman, et al. Expires September 6, 2019 [Page 1] Internet-Draft Simulcast March 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 6 3.2. Application Specific Media Source Handling . . . . . . . 7 3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Detailed Description . . . . . . . . . . . . . . . . . . . . 10 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10 5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 5.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13 5.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 13 5.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 14 5.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 5.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 15 5.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16 5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 5.6.3. Simulcast and Redundancy . . . . . . . . . . . . . . 21 6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Outgoing from Endpoint with Media Source . . . . . . . . 23 6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 23 6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 24 6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 26 6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 27 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 28 8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 Burman, et al. Expires September 6, 2019 [Page 2] Internet-Draft Simulcast March 2019 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Changes From Earlier Versions . . . . . . . . . . . 35 B.1. Modifications Between WG Version -13 and -14 . . . . . . 35 B.2. Modifications Between WG Version -12 and -13 . . . . . . 36 B.3. Modifications Between WG Version -11 and -12 . . . . . . 36 B.4. Modifications Between WG Version -10 and -11 . . . . . . 36 B.5. Modifications Between WG Version -09 and -10 . . . . . . 37 B.6. Modifications Between WG Version -08 and -09 . . . . . . 37 B.7. Modifications Between WG Version -07 and -08 . . . . . . 37 B.8. Modifications Between WG Version -06 and -07 . . . . . . 38 B.9. Modifications Between WG Version -05 and -06 . . . . . . 38 B.10. Modifications Between WG Version -04 and -05 . . . . . . 38 B.11. Modifications Between WG Version -03 and -04 . . . . . . 39 B.12. Modifications Between WG Version -02 and -03 . . . . . . 39 B.13. Modifications Between WG Version -01 and -02 . . . . . . 40 B.14. Modifications Between WG Version -00 and -01 . . . . . . 40 B.15. Modifications Between Individual Version -00 and WG Version -00 . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction Most of today's multiparty video conference solutions make use of centralized servers to reduce the bandwidth and CPU consumption in the endpoints. Those servers receive RTP streams from each participant and send some suitable set of possibly modified RTP streams to the rest of the participants, which usually have heterogeneous capabilities (screen size, CPU, bandwidth, codec, etc). One of the biggest issues is how to perform RTP stream adaptation to different participants' constraints with the minimum possible impact on both video quality and server performance. Simulcast is defined in this memo as the act of simultaneously sending multiple different encoded streams of the same media source, e.g. the same video source encoded with different video encoder types or image resolutions. This can be done in several ways and for different purposes. This document focuses on the case where it is desirable to provide a media source as multiple encoded streams over RTP [RFC3550] towards an intermediary so that the intermediary can provide the wanted functionality by selecting which RTP stream(s) to forward to other participants in the session, and more specifically how the identification and grouping of the involved RTP streams are done. Burman, et al. Expires September 6, 2019 [Page 3] Internet-Draft Simulcast March 2019 The intended scope of the defined mechanism is to support negotiation and usage of simulcast when using SDP offer/answer and media transport over RTP. The media transport topologies considered are point to point RTP sessions as well as centralized multi-party RTP sessions, where a media sender will provide the simulcasted streams to an RTP middlebox or endpoint, and middleboxes may further distribute the simulcast streams to other middleboxes or endpoints. Simulcast could, as part of a distributed multi-party scenario, be used point-to-point between middleboxes. Usage of multicast or broadcast transport is out of scope and left for future extensions. This document describes a few scenarios that motivate the use of simulcast, and also defines the needed RTP/RTCP and SDP signaling for it. 2. Definitions 2.1. Terminology This document makes use of the terminology defined in RTP Taxonomy [RFC7656], and RTP Topologies [RFC7667]. The following terms are especially noted or here defined: RTP Mixer: An RTP middle node, defined in [RFC7667] (Section 3.6 to 3.9). RTP Session: An association among a group of participants communicating with RTP, as defined in [RFC3550] and amended by [RFC7656]. RTP Stream: A stream of RTP packets containing media data, as defined in [RFC7656]. RTP Switch: A common short term for the terms "switching RTP mixer", "source projecting middlebox", and "video switching MCU" as discussed in [RFC7667]. Simulcast Stream: One encoded stream or dependent stream from a set of concurrently transmitted encoded streams and optional dependent streams, all sharing a common media source, as defined in [RFC7656]. For example, HD and thumbnail video simulcast versions of a single media source sent concurrently as separate RTP Streams. Simulcast Format: Different formats of a simulcast stream serve the same purpose as alternative RTP payload types in non-simulcast SDP: to allow multiple alternative media formats for a given RTP stream. As for multiple RTP payload types on the m-line in offer/ Burman, et al. Expires September 6, 2019 [Page 4] Internet-Draft Simulcast March 2019 answer [RFC3264], any one of the negotiated alternative formats can be used in a single RTP stream at a given point in time, but not more than one (based on RTP timestamp). What format is used can change dynamically from one RTP packet to another. 2.2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Use Cases The use cases of simulcast described in this document relate to a multi-party communication session where one or more central nodes are used to adapt the view of the communication session towards individual participants, and facilitate the media transport between participants. Thus, these cases target the RTP Mixer type of topology. There are two principal approaches for an RTP Mixer to provide this adapted view of the communication session to each receiving participant: o Transcoding (decoding and re-encoding) received RTP streams with characteristics adapted to each receiving participant. This often include mixing or composition of media sources from multiple participants into a mixed media source originated by the RTP Mixer. The main advantage of this approach is that it achieves close to optimal adaptation to individual receiving participants. The main disadvantages are that it can be very computationally expensive to the RTP Mixer, typically degrades media Quality of Experience (QoE) such as end-to-end delay for the receiving participants, and requires RTP Mixer access to media content. o Switching a subset of all received RTP streams or sub-streams to each receiving participant, where the used subset is typically specific to each receiving participant. The main advantages of this approach are that it is computationally cheap to the RTP Mixer, has very limited impact on media QoE, and does not require RTP Mixer (full) access to media content. The main disadvantage is that it can be difficult to combine a subset of received RTP streams into a perfect fit to the resource situation of a receiving participant. It is also a disadvantage that sending multiple RTP streams consumes more network resources from the sending participant to the RTP Mixer. Burman, et al. Expires September 6, 2019 [Page 5] Internet-Draft Simulcast March 2019 The use of simulcast relates to the latter approach, where it is more important to reduce the load on the RTP Mixer and/or minimize QoE impact than to achieve an optimal adaptation of resource usage. 3.1. Reaching a Diverse Set of Receivers The media sources provided by a sending participant potentially need to reach several receiving participants that differ in terms of available resources. The receiver resources that typically differ include, but are not limited to: Codec: This includes codec type (such as RTP payload format MIME type) and can include codec configuration. A couple of codec resources that differ only in codec configuration will be "different" if they are somehow not "compatible", like if they differ in video codec profile, or the transport packetization configuration. Sampling: This relates to how the media source is sampled, in spatial as well as in temporal domain. For video streams, spatial sampling affects image resolution and temporal sampling affects video frame rate. For audio, spatial sampling relates to the number of audio channels and temporal sampling affects audio bandwidth. This may be used to suit different rendering capabilities or needs at the receiving endpoints. Bitrate: This relates to the number of bits sent per second to transmit the media source as an RTP stream, which typically also affects the QoE for the receiving user. Letting the sending participant create a simulcast of a few differently configured RTP streams per media source can be a good tradeoff when using an RTP switch as middlebox, instead of sending a single RTP stream and using an RTP mixer to create individual transcodings to each receiving participant. This requires that the receiving participants can be categorized in terms of available resources and that the sending participant can choose a matching configuration for a single RTP stream per category and media source. For example, a set of receiving participants differ only in screen resolution; some are able to display video with at most 360p resolution and some support 720p resolution. A sending participant can then reach all receivers with best possible resolution by creating a simulcast of RTP streams with 360p and 720p resolution for each sent video media source. Burman, et al. Expires September 6, 2019 [Page 6] Internet-Draft Simulcast March 2019 The maximum number of simulcasted RTP streams that can be sent is mainly limited by the amount of processing and uplink network resources available to the sending participant. 3.2. Application Specific Media Source Handling The application logic that controls the communication session may include special handling of some media sources. It is, for example, commonly the case that the media from a sending participant is not sent back to itself. It is also common that a currently active speaker participant is shown in larger size or higher quality than other participants (the sampling or bitrate aspects of Section 3.1) in a receiving client. Many conferencing systems do not send the active speaker's media back to the sender itself, which means there is some other participant's media that instead is forwarded to the active speaker; typically the previous active speaker. This way, the previously active speaker is needed both in larger size (to current active speaker) and in small size (to the rest of the participants), which can be solved with a simulcast from the previously active speaker to the RTP switch. 3.3. Receiver Media Source Preferences The application logic that controls the communication session may allow receiving participants to state preferences on the characteristics of the RTP stream they like to receive, for example in terms of the aspects listed in Section 3.1. Sending a simulcast of RTP streams is one way of accommodating receivers with conflicting or otherwise incompatible preferences. 4. Overview This memo defines SDP [RFC4566] signaling that covers the above described simulcast use cases and functionalities. A number of requirements for such signaling are elaborated in Appendix A. The RID mechanism, as defined in [I-D.ietf-mmusic-rid], enables an SDP offerer or answerer to specify a number of different RTP stream restrictions for a rid-id by using the "a=rid" line. Examples of such restrictions are maximum bitrate, maximum spatial video resolution (width and height), maximum video framerate, etc. Each rid-id may also be restricted to use only a subset of the RTP payload types in the associated SDP media description. Those RTP payload types can have their own configurations and parameters affecting what can be sent or received, using the "a=fmtp" line as well as other SDP attributes. Burman, et al. Expires September 6, 2019 [Page 7] Internet-Draft Simulcast March 2019 A new SDP media level attribute "a=simulcast" is defined. The attribute describes, independently for send and receive directions, the number of simulcast RTP streams as well as potential alternative formats for each simulcast RTP stream. Each simulcast RTP stream, including alternatives, is identified using the RID identifier (rid- id), defined in [I-D.ietf-mmusic-rid]. a=simulcast:send 1;2,3 recv 4 If the above line is included in an SDP offer, the "send" part indicates the offerer's capability and proposal to send two simulcast RTP streams. Each simulcast stream is described by one or more RTP stream identifiers (rid-id), each group of rid-ids for a simulcast stream is separated by a semicolon (";"). When a simulcast stream has multiple rid-ids that are separated by a comma (","), they describe alternative representations for that particular simulcast RTP stream. Thus, the above "send" part is interpreted as an intention to send two simulcast RTP streams. The first simulcast RTP stream is identified and restricted according to rid-id 1. The second simulcast RTP stream can be sent as two alternatives, identified and restricted according to rid-ids 2 and 3. The "recv" part of the above line indicates that the offerer desires to receive a single RTP stream (no simulcast) according to rid-id 4. A more complete example SDP offer media description is provided below: m=video 49300 RTP/AVP 97 98 99 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=rtpmap:99 VP8/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=fmtp:99 max-fs=240; max-fr=30 a=rid:1 send pt=97;max-width=1280;max-height=720 a=rid:2 send pt=98;max-width=320;max-height=180 a=rid:3 send pt=99;max-width=320;max-height=180 a=rid:4 recv pt=97 a=simulcast:send 1;2,3 recv 4 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 1: Example Simulcast Media Description in Offer The above SDP media description can be interpreted at a high level to say that the offerer is capable of sending two simulcast RTP streams, one H.264 encoded stream in up to 720p resolution, and one additional stream encoded as either H.264 or VP8 with a maximum resolution of Burman, et al. Expires September 6, 2019 [Page 8] Internet-Draft Simulcast March 2019 320x180 pixels. The offerer can receive one H.264 stream with maximum 720p resolution. The receiver of this SDP offer can generate an SDP answer that indicates what it accepts. It uses the "a=simulcast" attribute to indicate simulcast capability and specify what simulcast RTP streams and alternatives to receive and/or send. An example of such answering "a=simulcast" attribute, corresponding to the above offer, is: a=simulcast:recv 1;2 send 4 With this SDP answer, the answerer indicates in the "recv" part that it wants to receive the two simulcast RTP streams. It has removed an alternative that it doesn't support (rid-id 3). The send part confirms to the offerer that it will receive one stream for this media source according to rid-id 4. The corresponding, more complete example SDP answer media description could look like: m=video 49674 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=rid:1 recv pt=97;max-width=1280;max-height=720 a=rid:2 recv pt=98;max-width=320;max-height=180 a=rid:4 send pt=97 a=simulcast:recv 1;2 send 4 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 2: Example Simulcast Media Description in Answer It is assumed that a single SDP media description is used to describe a single media source. This is aligned with the concepts defined in [RFC7656] and will work in a WebRTC context, both with and without BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping of media descriptions. To summarize, the "a=simulcast" line describes send and receive direction simulcast streams separately. Each direction can in turn describe one or more simulcast streams, separated by semicolon. The identifiers describing simulcast streams on the "a=simulcast" line are rid-id, as defined by "a=rid" lines in [I-D.ietf-mmusic-rid]. Each simulcast stream can be offered as a list of alternative rid-id, with each alternative separated by comma (not in the examples above). A detailed specification can be found in Section 5 and more detailed examples are outlined in Section 5.6. Burman, et al. Expires September 6, 2019 [Page 9] Internet-Draft Simulcast March 2019 5. Detailed Description This section further details the overview above (Section 4). First, formal syntax is provided (Section 5.1), followed by the rest of the SDP attribute definition in Section 5.2. Relating Simulcast Streams (Section 5.5) provides the definition of the RTP/RTCP mechanisms used. The section is concluded with a number of examples. 5.1. Simulcast Attribute This document defines a new SDP media-level "a=simulcast" attribute, with value according to the following ABNF [RFC5234] syntax and its update for Case-Sensitive String Support in ABNF [RFC7405]: sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] ) sc-send = %s"send" SP sc-str-list sc-recv = %s"recv" SP sc-str-list sc-str-list = sc-alt-list *( ";" sc-alt-list ) sc-alt-list = sc-id *( "," sc-id ) sc-id-paused = "~" sc-id = [sc-id-paused] rid-id ; SP defined in [RFC5234] ; rid-id defined in [I-D.ietf-mmusic-rid] Figure 3: ABNF for Simulcast Value Note to RFC Editor: Replace "I-D.ietf-mmusic-rid" in the above figure with RFC number of draft-ietf-mmusic-rid before publication of this document. The "a=simulcast" attribute has a parameter in the form of one or two simulcast stream descriptions, each consisting of a direction ("send" or "recv"), followed by a list of one or more simulcast streams. Each simulcast stream consists of one or more alternative simulcast formats. Each simulcast format is identified by a simulcast stream identifier (rid-id). The rid-id MUST have the form of an RTP stream identifier, as described by RTP Payload Format Restrictions [I-D.ietf-mmusic-rid]. In the list of simulcast streams, each simulcast stream is separated by a semicolon (";"). Each simulcast stream can in turn be offered in one or more alternative formats, represented by rid-ids, separated by a comma (","). Each rid-id can also be specified as initially paused [RFC7728], indicated by prepending a "~" to the rid-id. The reason to allow separate initial pause states for each rid-id is that pause capability can be specified individually for each RTP payload type referenced by an rid-id. Since pause capability specified via the "a=rtcp-fb" attribute applies only to specified payload types and Burman, et al. Expires September 6, 2019 [Page 10] Internet-Draft Simulcast March 2019 rid-id specified by "a=rid" can refer to multiple different payload types, it is unfeasible to pause streams with rid-id where any of the related RTP payload type(s) do not have pause capability. 5.2. Simulcast Capability Simulcast capability is expressed through a new media level SDP attribute, "a=simulcast" (Section 5.1). The use of this attribute at the session level is undefined. Implementations of this specification MUST NOT use it at the session level and MUST ignore it if received at the session level. Extensions to this specification may define such session level usage. Each SDP media description MUST contain at most one "a=simulcast" line. There are separate and independent sets of simulcast streams in send and receive directions. When listing multiple directions, each direction MUST NOT occur more than once on the same line. Simulcast streams using undefined rid-id MUST NOT be used as valid simulcast streams by an RTP stream receiver. The direction for an rid-id MUST be aligned with the direction specified for the corresponding RTP stream identifier on the "a=rid" line. The listed number of simulcast streams for a direction sets a limit to the number of supported simulcast streams in that direction. The order of the listed simulcast streams in the "send" direction suggests a proposed order of preference, in decreasing order: the rid-id listed first is the most preferred and subsequent streams have progressively lower preference. The order of the listed rid-id in the "recv" direction expresses which simulcast streams that are preferred, with the leftmost being most preferred. This can be of importance if the number of actually sent simulcast streams have to be reduced for some reason. rid-id that have explicit dependencies [RFC5583] [I-D.ietf-mmusic-rid] to other rid-id (even in the same media description) MAY be used. Use of more than a single, alternative simulcast format for a simulcast stream MAY be specified as part of the attribute parameters by expressing the simulcast stream as a comma-separated list of alternative rid-id. The order of the rid-id alternatives within a simulcast stream is significant; the rid-id alternatives are listed from (left) most preferred to (right) least preferred. For the use of simulcast, this overrides the normal codec preference as expressed by format type ordering on the "m=" line, using regular SDP rules. This is to enable a separation of general codec preferences and simulcast stream configuration preferences. However, the choice of Burman, et al. Expires September 6, 2019 [Page 11] Internet-Draft Simulcast March 2019 which alternative to use per simulcast stream is independent, and there is currently no mechanism to align the choice between alternative rid-ids between different simulcast streams. A simulcast stream can use a codec defined such that the same RTP SSRC can change RTP payload type multiple times during a session, possibly even on a per-packet basis. A typical example can be a speech codec that makes use of Comfort Noise [RFC3389] and/or DTMF [RFC4733] formats. If RTP stream pause/resume [RFC7728] is supported, any rid-id MAY be prefixed by a "~" character to indicate that the corresponding simulcast stream is initially paused already from start of the RTP session. In this case, support for RTP stream pause/resume MUST also be included under the same "m=" line where "a=simulcast" is included. All RTP payload types related to such an initially paused simulcast stream MUST be listed in the SDP as pause/resume capable as specified by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb". An initially paused simulcast stream in "send" direction for the endpoint sending the SDP MUST be considered equivalent to an unsolicited locally paused stream, and be handled accordingly. Initially paused simulcast streams are resumed as described by the RTP pause/resume specification. An RTP stream receiver that wishes to resume an unsolicited locally paused stream needs to know the SSRC of that stream. The SSRC of an initially paused simulcast stream can be obtained from an RTP stream sender RTCP Sender Report (SR) including both the desired SSRC as "SSRC of sender", and the rid-id value in an RtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. If the endpoint sending the SDP includes an "recv" direction simulcast stream that is initially paused, then the remote RTP sender receiving the SDP SHOULD put its RTP stream in a unsolicited locally paused state. The simulcast stream sender does not put the stream in the locally paused state if there are other RTP stream receivers in the session that do not mark the simulcast stream as initially paused. However, in centralized conferencing the RTP sender usually does not see the SDP signalling from RTP receivers and cannot make this determination. The reason to require an initially paused "recv" stream to be considered locally paused by the remote RTP sender, instead of making it equivalent to implicitly sending a pause request, is because the pausing RTP sender cannot know which receiving SSRC owns the restriction when Temporary Maximum Media Stream Bit Rate Request (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification (TMMBN) are used for pause/resume signaling (Section 5.6 of [RFC7728]) since the RTP receiver's SSRC in send direction is sometimes not yet known. Burman, et al. Expires September 6, 2019 [Page 12] Internet-Draft Simulcast March 2019 Use of the redundant audio data [RFC2198] format could be seen as a form of simulcast for loss protection purposes, but is not considered conflicting with the mechanisms described in this memo and MAY therefore be used as any other format. In this case the "red" format, rather than the carried formats, SHOULD be the one to list as a simulcast stream on the "a=simulcast" line. The media formats and corresponding characteristics of simulcast streams SHOULD be chosen such that they are different, e.g. as different SDP formats with differing "a=rtpmap" and/or "a=fmtp" lines, or as differently defined RTP payload format restrictions. If this difference is not required, it is RECOMMENDED to use RTP duplication [RFC7104] procedures instead of simulcast. To avoid complications in implementations, a single rid-id MUST NOT occur more than once per "a=simulcast" line. Note that this does not eliminate use of simulcast as an RTP duplication mechanism, since it is possible to define multiple different rid-id that are effectively equivalent. 5.3. Offer/Answer Use Note: The inclusion of "a=simulcast" or the use of simulcast does not change any of the interpretation or Offer/Answer procedures for other SDP attributes, like "a=fmtp" or "a=rid". 5.3.1. Generating the Initial SDP Offer An offerer wanting to use simulcast for a media description SHALL include one "a=simulcast" attribute in that media description in the offer. An offerer listing a set of receive simulcast streams and/or alternative formats as rid-id in the offer MUST be prepared to receive RTP streams for any of those simulcast streams and/or alternative formats from the answerer. 5.3.2. Creating the SDP Answer An answerer that does not understand the concept of simulcast will also not know the attribute and will remove it in the SDP answer, as defined in existing SDP Offer/Answer [RFC3264] procedures. Since SDP session level simulcast is undefined in this memo, an answerer that receives an offer with the "a=simulcast" attribute on SDP session level SHALL remove it in the answer. An answerer that understands the attribute but receives multiple "a=simulcast" attributes in the same media description SHALL disable use of simulcast by removing all "a=simulcast" lines for that media description in the answer. An answerer that does understand the attribute and that wants to support simulcast in an indicated direction SHALL reverse Burman, et al. Expires September 6, 2019 [Page 13] Internet-Draft Simulcast March 2019 directionality of the unidirectional direction parameters; "send" becomes "recv" and vice versa, and include it in the answer. An answerer that receives an offer with simulcast containing an "a=simulcast" attribute listing alternative rid-id MAY keep all the alternative rid-id in the answer, but it MAY also choose to remove any non-desirable alternative rid-id in the answer. The answerer MUST NOT add any alternative rid-id in send direction in the answer that were not present in the offer receive direction. The answerer MUST be prepared to receive any of the receive direction rid-id alternatives and MAY send any of the send direction alternatives that are part of the answer. An answerer that receives an offer with simulcast that lists a number of simulcast streams, MAY reduce the number of simulcast streams in the answer, but MUST NOT add simulcast streams. An answerer that receives an offer without RTP stream pause/resume capability MUST NOT mark any simulcast streams as initially paused in the answer. An RTP stream pause/resume capable answerer that receives an offer with RTP stream pause/resume capability MAY mark any rid-id that refer to pause/resume capable formats as initially paused in the answer. An answerer that receives indication in an offer of an rid-id being initially paused SHOULD mark that rid-id as initially paused also in the answer, regardless of direction, unless it has good reason for the rid-id not being initially paused. One reason to remove an initial pause in the answer compared to the offer could, for example, be that all receive direction simulcast streams for a media source the answerer accepts in the answer would otherwise be paused. 5.3.3. Offerer Processing the SDP Answer An offerer that receives an answer without "a=simulcast" MUST NOT use simulcast towards the answerer. An offerer that receives an answer with "a=simulcast" without any rid-id in a specified direction MUST NOT use simulcast in that direction. An offerer that receives an answer where some rid-id alternatives are kept MUST be prepared to receive any of the kept send direction rid- id alternatives, and MAY send any of the kept receive direction rid- id alternatives. An offerer that receives an answer where some of the rid-id are removed compared to the offer MAY release the corresponding resources Burman, et al. Expires September 6, 2019 [Page 14] Internet-Draft Simulcast March 2019 (codec, transport, etc) in its receive direction and MUST NOT send any RTP packets corresponding to the removed rid-id. An offerer that offered some of its rid-id as initially paused and that receives an answer that does not indicate RTP stream pause/ resume capability, MUST NOT initially pause any simulcast streams. An offerer with RTP stream pause/resume capability that receives an answer where some rid-id are marked as initially paused, SHOULD initially pause those RTP streams regardless if they were marked as initially paused also in the offer, unless it has good reason for those RTP streams not being initially paused. One such reason could, for example, be that the answerer would otherwise initially not receive any media of that type at all. 5.3.4. Modifying the Session Offers inside an existing session follow the same rules as for initial SDP offer, with these additions: 1. rid-id marked as initially paused in the offerer's send direction SHALL reflect the offerer's opinion of the current pause state at the time of creating the offer. This is purely informational, and RTP stream pause/resume [RFC7728] signaling in the ongoing session SHALL take precedence in case of any conflict or ambiguity. 2. rid-id marked as initially paused in the offerer's receive direction SHALL (as in an initial offer) reflect the offerer's desired rid-id pause state. Except for the case where the offerer already paused the corresponding RTP stream through RTP stream pause/resume [RFC7728] signaling , this is identical to the conditions at an initial offer. Creation of SDP answers and processing of SDP answers inside an existing session follow the same rules as described above for initial SDP offer/answer. Session modification restrictions in section 6.5 of RTP payload format restrictions [I-D.ietf-mmusic-rid] also apply. 5.4. Use with Declarative SDP This document does not define the use of "a=simulcast" in declarative SDP, partly motivated by use of the simulcast format identification [I-D.ietf-mmusic-rid] not being defined for use in declarative SDP. If concrete use cases for simulcast in declarative SDP are identified Burman, et al. Expires September 6, 2019 [Page 15] Internet-Draft Simulcast March 2019 in the future, the authors of this memo expect that additional specifications will address such use. 5.5. Relating Simulcast Streams Simulcast RTP streams MUST be related on RTP level through RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP "a=simulcast" attribute (Section 5.2) parameters. This is sufficient as long as there is only a single media source per SDP media description. When using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media descriptions jointly specify a single RTP session, the SDES MID identification mechanism in BUNDLE allows relating RTP streams back to individual media descriptions, after which the above described RtpStreamId relations can be used. Use of the RTP header extension [RFC8285] for both MID and RtpStreamId identifications can be important to ensure rapid initial reception, required to correctly interpret and process the RTP streams. Implementers of this specification MUST support the RTCP source description (SDES) item method and SHOULD support RTP header extension method to signal RtpStreamId on RTP level. NOTE: For the case where it is clear from SDP that RTP PT uniquely maps to corresponding RtpStreamId, an RTP receiver can use RTP PT to relate simulcast streams. This can sometimes enable decoding even in advance to receiving RtpStreamId information in RTCP SDES and/or RTP header extensions. RTP streams MUST only use a single alternative rid-id at a time (based on RTP timestamps), but MAY change format (and rid-id) on a per-RTP packet basis. This corresponds to the existing (non- simulcast) SDP offer/answer case when multiple formats are included on the "m=" line in the SDP answer, enabling per-RTP packet change of RTP payload type. 5.6. Signaling Examples These examples describe a client to video conference service, using a centralized media topology with an RTP mixer. Burman, et al. Expires September 6, 2019 [Page 16] Internet-Draft Simulcast March 2019 +---+ +-----------+ +---+ | A |<---->| |<---->| B | +---+ | | +---+ | Mixer | +---+ | | +---+ | F |<---->| |<---->| J | +---+ +-----------+ +---+ Figure 4: Four-party Mixer-based Conference 5.6.1. Single-Source Client Alice is calling in to the mixer with a simulcast-enabled client capable of a single media source per media type. The client can send a simulcast of 2 video resolutions and frame rates: HD 1280x720p 30fps and thumbnail 320x180p 15fps. This is defined below using the "imageattr" [RFC6236]. In this example, only the "pt" "a=rid" parameter is used, effectively achieving a 1:1 mapping between RtpStreamId and media formats (RTP payload types), to describe simulcast stream formats. Alice's Offer: v=0 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 s=Simulcast Enabled Client c=IN IP4 192.0.2.156 t=0 0 m=audio 49200 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49300 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:1 send pt=97 a=rid:2 send pt=98 a=rid:3 recv pt=97 a=simulcast:send 1;2 recv 3 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 5: Single-Source Simulcast Offer The only thing in the SDP that indicates simulcast capability is the line in the video media description containing the "simulcast" attribute. The included "a=fmtp" and "a=imageattr" parameters indicates that sent simulcast streams can differ in video resolution. The RTP header extension for RtpStreamId is offered to avoid issues Burman, et al. Expires September 6, 2019 [Page 17] Internet-Draft Simulcast March 2019 with the initial binding between RTP streams (SSRCs) and the RtpStreamId identifying the simulcast stream and its format. The Answer from the server indicates that it too is simulcast capable. Should it not have been simulcast capable, the "a=simulcast" line would not have been present and communication would have started with the media negotiated in the SDP. Also the usage of the RtpStreamId RTP header extension is accepted. v=0 o=server 823479283 1209384938 IN IP4 192.0.2.2 s=Answer to Simulcast Enabled Client c=IN IP4 192.0.2.43 t=0 0 m=audio 49672 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49674 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:1 recv pt=97 a=rid:2 recv pt=98 a=rid:3 send pt=97 a=simulcast:recv 1;2 send 3 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 6: Single-Source Simulcast Answer Since the server is the simulcast media receiver, it reverses the direction of the "simulcast" and "rid" attribute parameters. 5.6.2. Multi-Source Client Fred is calling in to the same conference as in the example above with a two-camera, two-display system, thus capable of handling two separate media sources in each direction, where each media source is simulcast-enabled in the send direction. Fred's client is restricted to a single media source per media description. The first two simulcast streams for the first media source use different codecs, H264-SVC [RFC6190] and H264 [RFC6184]. These two simulcast streams also have a temporal dependency. Two different video codecs, VP8 [RFC7741] and H264, are offered as alternatives for the third simulcast stream for the first media source. Only the Burman, et al. Expires September 6, 2019 [Page 18] Internet-Draft Simulcast March 2019 highest fidelity simulcast stream is sent from start, the lower fidelity streams being initially paused. The second media source is offered with three different simulcast streams. All video streams of this second media source are loss protected by RTP retransmission [RFC4588]. Also here, all but the highest fidelity simulcast stream are initially paused. Note that the lower resolution is more prioritized than the medium resolution simulcast stream. Fred's client is also using BUNDLE to send all RTP streams from all media descriptions in the same RTP session on a single media transport. Although using many different simulcast streams in this example, the use of RtpStreamId as simulcast stream identification enables use of a low number of RTP payload types. Note that the use of both BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and "a=rid" [I-D.ietf-mmusic-rid] recommends using the RTP header extension [RFC8285] for carrying these RTP stream identification fields, which is consequently also included in the SDP. Note also that for "a=rid", the corresponding RtpStreamId SDES attribute RTP header extension is named rtp-stream-id [I-D.ietf-avtext-rid]. Burman, et al. Expires September 6, 2019 [Page 19] Internet-Draft Simulcast March 2019 v=0 o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d s=Offer from Simulcast Enabled Multi-Source Client c=IN IP6 2001:db8::c000:27d t=0 0 a=group:BUNDLE foo bar zen m=audio 49200 RTP/AVP 99 a=mid:foo a=rtpmap:99 G722/8000 m=video 49600 RTP/AVPF 100 101 103 a=mid:bar a=rtpmap:100 H264-SVC/90000 a=rtpmap:101 H264/90000 a=rtpmap:103 VP8/90000 a=fmtp:100 profile-level-id=42400d;max-fs=3600;max-mbps=216000; \ mst-mode=NI-TC a=fmtp:101 profile-level-id=42c00d;max-fs=3600;max-mbps=108000 a=fmtp:103 max-fs=900; max-fr=30 a=rid:1 send pt=100;max-width=1280;max-height=720;max-fps=60;depend=2 a=rid:2 send pt=101;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=101;max-width=640;max-height=360 a=rid:4 send pt=103;max-width=640;max-height=360 a=depend:100 lay bar:101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:* ccm pause nowait a=simulcast:send 1;2;~4,3 m=video 49602 RTP/AVPF 96 104 a=mid:zen a=rtpmap:96 VP8/90000 a=fmtp:96 max-fs=3600; max-fr=30 a=rtpmap:104 rtx/90000 a=fmtp:104 apt=96;rtx-time=200 a=rid:1 send max-fs=921600;max-fps=30 a=rid:2 send max-fs=614400;max-fps=15 a=rid:3 send max-fs=230400;max-fps=30 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=rtcp-fb:* ccm pause nowait a=simulcast:send 1;~3;~2 Figure 7: Fred's Multi-Source Simulcast Offer Burman, et al. Expires September 6, 2019 [Page 20] Internet-Draft Simulcast March 2019 5.6.3. Simulcast and Redundancy The example in this section looks at applying simulcast with audio and video redundancy formats. The audio media description uses codec and bitrate restrictions, combining it with RTP Payload for Redundant Audio Data [RFC2198] for enhanced packet loss resilience. The video media description applies both resolution and bitrate restrictions, combining it with FEC in the form of Flexible FEC [I-D.ietf-payload-flexible-fec-scheme] and RTP Retransmission [RFC4588]. The audio source is offered to be sent as two simulcast streams. The first simulcast stream is encoded with Opus, restricted to 50 kbps (rid-id=5), and the second simulcast stream is encoded either with G.711 (rid-id=7) or with G.711 combined with LPC for redundancy (rid- id=6). In this example, stand-alone LPC is not offered as an possible payload type for the second simulcast stream's RID, which could e.g. be motivated by not providing sufficient quality. The video source is offered to be sent as two simulcast streams, both with two alternative simulcast formats. Redundancy and repair are offered in the form of both Flexible FEC and RTP Retransmission. The Flexible FEC is not bound to any particular RTP streams and is therefore possible to use across all RTP streams that are being sent as part of this media description. Burman, et al. Expires September 6, 2019 [Page 21] Internet-Draft Simulcast March 2019 v=0 o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d s=Offer from Simulcast Enabled Client using Redundancy c=IN IP6 2001:db8::c000:27d t=0 0 a=group:BUNDLE foo bar m=audio 49200 RTP/AVP 97 98 99 100 101 102 a=mid:foo a=rtpmap:97 G711/8000 a=rtpmap:98 LPC/8000 a=rtpmap:99 OPUS/48000/1 a=rtpmap:100 RED/8000/1 a=rtpmap:101 CN/8000 a=rtpmap:102 telephone-event/8000 a=fmtp:99 useinbandfec=1;usedtx=0 a=fmtp:100 97/98 a=fmtp:102 0-15 a=ptime:20 a=maxptime:40 a=rid:1 send pt=99,102;max-br=64000 a=rid:2 send pt=100,97,101,102 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=simulcast:send 1;2 m=video 49600 RTP/AVPF 103 104 105 106 107 a=mid:bar a=rtpmap:103 H264/90000 a=rtpmap:104 VP8/90000 a=rtpmap:105 rtx/90000 a=rtpmap:106 rtx/90000 a=rtpmap:107 flexfec/90000 a=fmtp:103 profile-level-id=42c00d;max-fs=3600;max-mbps=108000 a=fmtp:104 max-fs=3600; max-fr=30 a=fmtp:105 apt=103;rtx-time=200 a=fmtp:106 apt=104;rtx-time=200 a=fmtp:107 repair-window=2000 a=rid:1 send pt=103;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=104;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=103;max-width=640;max-height=360;max-br=300000 a=rid:4 send pt=104;max-width=640;max-height=360;max-br=300000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=rtcp-fb:* ccm pause nowait a=simulcast:send 1,2;3,4 Figure 8: Simulcast and Redundancy Example Burman, et al. Expires September 6, 2019 [Page 22] Internet-Draft Simulcast March 2019 6. RTP Aspects This section discusses what the different entities in a simulcast media path can expect to happen on RTP level. This is explored from source to sink by starting in an endpoint with a media source that is simulcasted to an RTP middlebox. That RTP middlebox sends media sources both to other RTP middleboxes (cascaded middleboxes), as well as selecting some simulcast format of the media source and sending it to receiving endpoints. Different types of RTP middleboxes and their usage of the different simulcast formats results in several different behaviors. 6.1. Outgoing from Endpoint with Media Source The most straightforward simulcast case is the RTP streams being emitted from the endpoint that originates a media source. When simulcast has been negotiated in the sending direction, the endpoint can transmit up to the number of RTP streams needed for the negotiated simulcast streams for that media source. Each RTP stream (SSRC) is identified by associating (Section 5.5) it with an RtpStreamId SDES item, transmitted in RTCP and possibly also as an RTP header extension. In cases where multiple media sources have been negotiated for the same RTP session and thus BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] is used, also the MID SDES item will be sent similarly to the RtpStreamId. Each RTP stream might not be continuously transmitted due to any of the following reasons; temporarily paused using Pause/Resume [RFC7728], sender side application logic temporarily pausing it, or lack of network resources to transmit this simulcast stream. However, all simulcast streams that have been negotiated have active and maintained SSRC (at least in regular RTCP reports), even if no RTP packets are currently transmitted. The relation between an RTP Stream (SSRC) and a particular simulcast stream is not expected to change, except in exceptional situations such as SSRC collisions. At SSRC changes, the usage of MID and RtpStreamId should enable the receiver to correctly identify the RTP streams even after an SSRC change. 6.2. RTP Middlebox to Receiver RTP streams in a multi-party RTP session can be used in multiple different ways, when the session utilizes simulcast at least on the media source to middlebox legs. This is to a large degree due to the different RTP middlebox behaviors, but also the needs of the application. This text assumes that the RTP middlebox will select a media source and choose which simulcast stream for that media source to deliver to a specific receiver. In many cases, at most one Burman, et al. Expires September 6, 2019 [Page 23] Internet-Draft Simulcast March 2019 simulcast stream per media source will be forwarded to a particular receiver at any instant in time, even if the selected simulcast stream may vary. For cases where this does not hold due to application needs, then the RTP stream aspects will fall under the middlebox to middlebox case Section 6.3. The selection of which simulcast streams to forward towards the receiver, is application specific. However, in conferencing applications, active speaker selection is common. In case the number of media sources possible to forward, N, is less than the total amount of media sources available in an multi-media session, the current and previous speakers (up to N in total) are often the ones forwarded. To avoid the need for media specific processing to determine the current speaker(s) in the RTP middlebox, the endpoint providing a media source may include meta data, such as the RTP Header Extension for Client-to-Mixer Audio Level Indication [RFC6464]. The possibilities for stream switching are media type specific, but for media types with significant interframe dependencies in the encoding, like most video coding, the switching needs to be made at suitable switching points in the media stream that breaks or otherwise deals with the dependency structure. Even if switching points can be included periodically, it is common to use mechanisms like Full Intra Requests [RFC5104] to request switching points from the endpoint performing the encoding of the media source. Inclusion of the RtpStreamId SDES item for an SSRC in the middlebox to receiver direction should only occur when use of RtpStreamId has been negotiated in that direction. It is worth noting that one can signal multiple RtpStreamIds when simulcast signalling indicates only a single simulcast stream, allowing one to use all of the RtpStreamIds as alternatives for that simulcast stream. One reason for including the RtpStreamId in the middlebox to receiver direction for an RTP stream is to let the receiver know which restrictions apply to the currently delivered RTP stream. In case the RtpStreamId is negotiated to be used, it is important to remember that the used identifiers will be specific to each signalling session. Even if the central entity can attempt to coordinate, it is likely that the RtpStreamIds need to be translated to the leg specific values. The below cases will have as base line that RtpStreamId is not used in the mixer to receiver direction. 6.2.1. Media-Switching Mixer This section discusses the behavior in cases where the RTP middlebox behaves like the Media-Switching Mixer (Section 3.6.2) in RTP Topologies [RFC7667]. The fundamental aspect here is that the media Burman, et al. Expires September 6, 2019 [Page 24] Internet-Draft Simulcast March 2019 sources delivered from the middlebox will be the mixer's conceptual or functional ones. For example, one media source may be the main speaker in high resolution video, while a number of other media sources are thumbnails of each participant. The above results in that the RTP stream produced by the mixer is one that switches between a number of received incoming RTP streams for different media sources and in different simulcast versions. The mixer selects the media source to be sent as one of the RTP streams, and then selects among the available simulcast streams for the most appropriate one. The selection criteria include available bandwidth on the mixer to receiver path and restrictions based on the functional usage of the RTP stream delivered to the receiver. As an example of the latter, it is unnecessary to forward a full HD video to a receiver if the display area is just a thumbnail. Thus, restrictions may exist to not allow some simulcast streams to be forwarded for some of the mixer's media sources. This will result in a single RTP stream being used for each of the RTP mixer's media sources. This RTP stream is at any point in time a selection of one particular RTP stream arriving to the mixer, where the RTP header field values are rewritten to provide a consistent, single RTP stream. If the RTP mixer doesn't receive any incoming stream matched to this media source, the SSRC will not transmit, but be kept alive using RTCP. The SSRC and thus RTP stream for the mixer's media source is expected to be long term stable. It will only be changed by signalling or other disruptive events. Note that although the above talks about a single RTP stream, there can in some cases be multiple RTP streams carrying the selected simulcast stream for the originating media source, including redundancy or other auxiliary RTP streams. The mixer may communicate the identity of the originating media source to the receiver by including the CSRC field with the originating media source's SSRC value. Note that due to the possibility that the RTP mixer switches between simulcast versions of the media source, the CSRC value may change, even if the media source is kept the same. It is important to note that any MID SDES item from the originating media source needs to be removed and not be associated with the RTP stream's SSRC. That is, there is nothing in the signalling between the mixer and the receiver that is structured around the originating media sources, only the mixer's media sources. If they would be associated with the SSRC, the receiver would likely believe that there has been an SSRC collision, and that the RTP stream is spurious as it doesn't carry the identifiers used to relate it to the correct context. However, this is not true for CSRC values, as long as they Burman, et al. Expires September 6, 2019 [Page 25] Internet-Draft Simulcast March 2019 are never used as SSRC. In these cases one could provide CNAME and MID as SDES items. A receiver could use this to determine which CSRC values that are associated with the same originating media source. If RtpStreamIds are used in the scenario described by this section, it should be noted that the RtpStreamId on a particular SSRC will change based on the actual simulcast stream selected for switching. These RtpStreamId identifiers will be local to this leg's signalling context. In addition, the defined RtpStreamIds and their parameters need to cover all the media sources and simulcast streams received by the RTP mixer that can be switched into this media source, sent by the RTP mixer. 6.2.2. Selective Forwarding Middlebox This section discusses the behavior in cases where the RTP middlebox behaves like the Selective Forwarding Middlebox (Section 3.7) in RTP Topologies [RFC7667]. Applications for this type of RTP middlebox results in that each originating media source will have a corresponding media source on the leg between the middlebox and the receiver. A Selective Forwarding Middlebox (SFM) could go as far as exposing all the simulcast streams for an media source, however this section will focus on having a single simulcast stream that can contain any of the simulcast formats. This section will assume that the SFM projection mechanism works on media source level, and maps one of the media source's simulcast streams onto one RTP stream from the SFM to the receiver. This usage will result in that the individual RTP stream(s) for one media source can switch between being active to paused, based on the subset of media sources the SFM wants to provide the receiver for the moment. With SFMs there exist no reasons to use CSRC to indicate the originating stream, as there is a one to one media source mapping. If the application requires knowing the simulcast version received to function well, then RtpStreamId should be negotiated on the SFM to receiver leg. Which simulcast stream that is being forwarded is not made explicit unless RtpStreamId is used on the leg. Any MID SDES items being sent by the SFM to the receiver are only those agreed between the SFM and the receiver, and no MID values from the originating side of the SFM are to be forwarded. A SFM could expose corresponding RTP streams for all the media sources and their simulcast streams, and then for any media source that is to be provided forward one selected simulcast stream. However, this is not recommended as it would unnecessarily increase the number of RTP streams and require the receiver to timely detect switching between simulcast streams. The above usage requires the Burman, et al. Expires September 6, 2019 [Page 26] Internet-Draft Simulcast March 2019 same SFM functionality for switching, while avoiding the uncertainties of timely detecting that a RTP stream ends. The benefit would be that the received simulcast stream would be implicitly provided by which RTP stream would be active for a media source. However, using RtpStreamId to make this explicit also exposes which alternative format is used. The conclusion is that using one RTP stream per simulcast stream is unnecessary. The issue with timely detecting end of streams, independent if they are stopped temporarily or long term, is that there is no explicit indication that the transmission has intentionally been stopped. The RTCP based Pause and Resume mechanism [RFC7728] includes a PAUSED indication that provides the last RTP sequence number transmitted prior to the pause. Due to usage, the timeliness of this solution depends on when delivery using RTCP can occur in relation to the transmission of the last RTP packet. If no explicit information is provided at all, then detection based on non increasing RTCP SR field values and timers need to be used to determine pause in RTP packet delivery. This results in that one can usually not determine when the last RTP packet arrives (if it arrives) that this will be the last. That it was the last is something that one learns later. 6.3. RTP Middlebox to RTP Middlebox This relates to the transmission of simulcast streams between RTP middleboxes or other usages where one wants to enable the delivery of multiple simultaneous simulcast streams per media source, but the transmitting entity is not the originating endpoint. For a particular direction between middlebox A and B, this looks very similar to the originating to middlebox case on a media source basis. However, in this case there is usually multiple media sources, originating from multiple endpoints. This can create situations where limitations in the number of simultaneously received media streams can arise, for example due to limitation in network bandwidth. In this case, a subset of not only the simulcast streams, but also media sources can be selected. This results in that individual RTP streams can be become paused at any point and later being resumed based on various criteria. The MIDs used between A and B are the ones agreed between these two identities in signalling. The RtpStreamId values will also be provided to ensure explicit information about which simulcast stream they are. The RTP stream to MID and RtpStreamId associations should here be long term stable. Burman, et al. Expires September 6, 2019 [Page 27] Internet-Draft Simulcast March 2019 7. Network Aspects Simulcast is in this memo defined as the act of sending multiple alternative encoded streams of the same underlying media source. When transmitting multiple independent streams that originate from the same source, it could potentially be done in several different ways using RTP. A general discussion on considerations for use of the different RTP multiplexing alternatives can be found in Guidelines for Multiplexing in RTP [I-D.ietf-avtcore-multiplex-guidelines]. Discussion and clarification on how to handle multiple streams in an RTP session can be found in [RFC8108]. The network aspects that are relevant for simulcast are: Quality of Service: When using simulcast it might be of interest to prioritize a particular simulcast stream, rather than applying equal treatment to all streams. For example, lower bitrate streams may be prioritized over higher bitrate streams to minimize congestion or packet losses in the low bitrate streams. Thus, there is a benefit to use a simulcast solution with good QoS support. NAT/FW Traversal: Using multiple RTP sessions incurs more cost for NAT/FW traversal unless they can re-use the same transport flow, which can be achieved by Multiplexing Negotiation Using SDP Port Numbers [I-D.ietf-mmusic-sdp-bundle-negotiation]. 7.1. Bitrate Adaptation Use of multiple simulcast streams can require a significant amount of network resources. The aggregate bandwidth for all simulcast streams for a media source (and thus SDP media description) is bounded by any SDP "b=" line applicable to that media source. It is assumed that a suitable congestion control mechanism is used by the application to ensure that it doesn't cause persistent congestion. If the amount of available network resources varies during an RTP session such that it does not match what is negotiated in SDP, the bitrate used by the different simulcast streams may have to be reduced dynamically. When a simulcasting media source uses a single media transport for all of the simulcast streams, it is likely that a joint congestion control across all simulcast streams is used for that media source. What simulcast streams to prioritize when allocating available bitrate among the simulcast streams in such adaptation SHOULD be taken from the simulcast stream order on the "a=simulcast" line and ordering of alternative simulcast formats Section 5.2. Simulcast streams that have pause/resume capability and that would be given such low bitrate Burman, et al. Expires September 6, 2019 [Page 28] Internet-Draft Simulcast March 2019 by the adaptation process that they are considered not really useful can be temporarily paused until the limiting condition clears. 8. Limitation The chosen approach has a limitation that relates to the use of a single RTP session for all simulcast formats of a media source, which comes from sending all simulcast streams related to a media source under the same SDP media description. It is not possible to use different simulcast streams on different media transports, limiting the possibilities to apply different QoS to different simulcast streams. When using unicast, QoS mechanisms based on individual packet marking are feasible, since they do not require separation of simulcast streams into different RTP sessions to apply different QoS. It is also not possible to separate different simulcast streams into different multicast groups to allow a multicast receiver to pick the stream it wants, rather than receive all of them. In this case, the only reasonable implementation is to use different RTP sessions for each multicast group so that reporting and other RTCP functions operate as intended. Such simulcast usage in multicast context is out of scope for the current document and would require additional specification. 9. IANA Considerations This document requests to register a new media-level SDP attribute, "simulcast", in the "att-field (media level only)" registry within the SDP parameters registry, according to the procedures of [RFC4566] and [I-D.ietf-mmusic-sdp-mux-attributes]. Contact name, email: The IESG (iesg@ietf.org) Attribute name: simulcast Long-form attribute name: Simulcast stream description Charset dependent: No Attribute value: sc-value; see Section 5.1 of RFC XXXX. Purpose: Signals simulcast capability for a set of RTP streams MUX category: NORMAL Burman, et al. Expires September 6, 2019 [Page 29] Internet-Draft Simulcast March 2019 Note to RFC Editor: Please replace "RFC XXXX" with the assigned number of this RFC. 10. Security Considerations The simulcast capability, configuration attributes, and parameters are vulnerable to attacks in signaling. A false inclusion of the "a=simulcast" attribute may result in simultaneous transmission of multiple RTP streams that would otherwise not be generated. The impact is limited by the media description joint bandwidth, shared by all simulcast streams irrespective of their number. There may however be a large number of unwanted RTP streams that will impact the share of bandwidth allocated for the originally wanted RTP stream. A hostile removal of the "a=simulcast" attribute will result in simulcast not being used. Neither of the above will likely have any major consequences and can be mitigated by signaling that is at least integrity and source authenticated to prevent an attacker to change it. Security considerations related to the use of "a=rid" and the RtpStreamId SDES item is covered in [I-D.ietf-mmusic-rid] and [I-D.ietf-avtext-rid]. There are no additional security concerns related to their use in this specification. 11. Contributors Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have contributed with important material to the first versions of this document. Robert Hansen and Cullen Jennings, from Cisco, Peter Thatcher, from Google, and Adam Roach, from Mozilla, contributed significantly to subsequent versions. 12. Acknowledgements The authors would like to thank Bernard Aboba, Thomas Belling, Roni Even, Adam Roach, Inaki Baz Castillo, Paul Kyzivat, and Arun Arunachalam for the feedback they provided during the development of this document. 13. References Burman, et al. Expires September 6, 2019 [Page 30] Internet-Draft Simulcast March 2019 13.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. [I-D.ietf-mmusic-rid] Roach, A., "RTP Payload Format Restrictions", draft-ietf- mmusic-rid-15 (work in progress), May 2018. [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-54 (work in progress), December 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [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, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, February 2016, . Burman, et al. Expires September 6, 2019 [Page 31] Internet-Draft Simulcast March 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., and R. Even, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft- ietf-avtcore-multiplex-guidelines-08 (work in progress), December 2018. [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-17 (work in progress), February 2019. [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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 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, . Burman, et al. Expires September 6, 2019 [Page 32] Internet-Draft Simulcast March 2019 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, . [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, . [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, . [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, . [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, . [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, DOI 10.17487/RFC7104, January 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, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Burman, et al. Expires September 6, 2019 [Page 33] Internet-Draft Simulcast March 2019 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . Appendix A. Requirements The following requirements are met by the defined solution to support the use cases (Section 3): REQ-1: Identification: REQ-1.1: It must be possible to identify a set of simulcasted RTP streams as originating from the same media source in SDP signaling. REQ-1.2: An RTP endpoint must be capable of identifying the simulcast stream a received RTP stream is associated with, knowing the content of the SDP signalling. REQ-2: Transport usage. The solution must work when using: REQ-2.1: Legacy SDP with separate media transports per SDP media description. REQ-2.2: Bundled [I-D.ietf-mmusic-sdp-bundle-negotiation] SDP media descriptions. REQ-3: Capability negotiation. It must be possible that: REQ-3.1: Sender can express capability of sending simulcast. REQ-3.2: Receiver can express capability of receiving simulcast. REQ-3.3: Sender can express maximum number of simulcast streams that can be provided. Burman, et al. Expires September 6, 2019 [Page 34] Internet-Draft Simulcast March 2019 REQ-3.4: Receiver can express maximum number of simulcast streams that can be received. REQ-3.5: Sender can detail the characteristics of the simulcast streams that can be provided. REQ-3.6: Receiver can detail the characteristics of the simulcast streams that it prefers to receive. REQ-4: Distinguishing features. It must be possible to have different simulcast streams use different codec parameters, as can be expressed by SDP format values and RTP payload types. REQ-5: Compatibility. It must be possible to use simulcast in combination with other RTP mechanisms that generate additional RTP streams: REQ-5.1: RTP Retransmission [RFC4588]. REQ-5.2: RTP Forward Error Correction [RFC5109]. REQ-5.3: Related payload types such as audio Comfort Noise and/or DTMF. REQ-5.4: A single simulcast stream can consist of multiple RTP streams, to support codecs where a dependent stream is dependent on a set of encoded and dependent streams, each potentially carried in their own RTP stream. REQ-6: Interoperability. The solution must be possible to use in: REQ-6.1: Interworking with non-simulcast legacy clients using a single media source per media type. REQ-6.2: WebRTC environment with a single media source per SDP media description. Appendix B. Changes From Earlier Versions NOTE TO RFC EDITOR: Please remove this section prior to publication. B.1. Modifications Between WG Version -13 and -14 o c= and t= line order corrected in SDP examples Burman, et al. Expires September 6, 2019 [Page 35] Internet-Draft Simulcast March 2019 B.2. Modifications Between WG Version -12 and -13 o Examples corrected to follow RID ABNF o Example Figure 7 now comments on priority for second media source. o Clarified a SHOULD limitation. o Added urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id in examples with RTX. o ABNF now uses RFC 7405 to indicate case sensitivity o Various minor editorials and nits. B.3. Modifications Between WG Version -11 and -12 o Modified Normative statement regarding RTP stream duplication in Section 5.2. o Clarified assumption about use of congestion control by applications. o Changed to use RFC 8174 boilerplate instead of RFC 2119. o Clarified explanation of syntax for simulcast attribute in Section 4. o Editorial clarification in Section 5.2 and 5.3.2. o Various minor editorials and nits. B.4. Modifications Between WG Version -10 and -11 o Added new SDP example section on Simulcast and Redundancy, including both RED (RFC2198), RTP RTX (RFC4588), and FEC (draft- ietf-payload-flexible-fec-scheme). o Removed restriction that "related" payload formats in an RTP stream (such as CN and DTMF) must not have their own rid-id, since there is no reason to forbid this and corresponding clarification is made in draft-ietf-mmusic-rid. o Removed any mention of source-specific signaling and the reference to RFC5576, since draft-ietf-mmusic-rid is not defined for source- specific signaling. Burman, et al. Expires September 6, 2019 [Page 36] Internet-Draft Simulcast March 2019 o Changed some SDP examples to use a=rid restrictions instead of a=imageattr. o Changed reference from the obsoleted RFC 5285 to RFC 8285. B.5. Modifications Between WG Version -09 and -10 o Amended overview section with a bit more explanation on the examples, and added an rid-id alternative for one of the streams. o Removed SCID also from the Terminology section, which was forgotten in -09 when changing SCID to rid-id. B.6. Modifications Between WG Version -08 and -09 o Changed SCID to rid-id, to align with ietf-draft-mmusic-rid naming. o Changed Overview to be based on examples and shortened it. o Changed semantics of initially paused rid-id in modified SDP offers from requiring it to follow actual RFC 7728 pause state to an informational offerer's opinion at the time of offer creation, not in any way overriding or amending RFC 7728 signaling. o Replaced text on ignoring all but the first of multiple "a=simulcast" lines in a media description with mandating that at most one "a=simulcast" line is included. o Clarified with a note that, for the case it is clear from the SDP that RTP PT uniquely maps to RtpStreamId, an RTP receiver can use RTP PT to relate simulcast streams. o Moved Section 4 Requirements to become Appendix A. o Editorial corrections and clarifications. B.7. Modifications Between WG Version -07 and -08 o Correcting syntax of SDP examples in section 6.6.1, as found by Inaki Baz Castillo. o Changing ABNF to only define the sc-value, not the SDP attribute itself, as suggested by Paul Kyzivat. o Changing I-D reference to newly published RFC 8108. o Adding list of modifications between -06 and -07. Burman, et al. Expires September 6, 2019 [Page 37] Internet-Draft Simulcast March 2019 B.8. Modifications Between WG Version -06 and -07 o A scope clarification, as result of the discussion with Roni Even. o A reformulation of the identification requirements for simulcast stream. o Correcting the statement related to source specific signalling (RFC 5576) to address Roni Even's comment. o Update of the last paragraph in Section 6.2 regarding simulcast stream differences as well as forbidding multiple instances of the same SCID within a single a=simulcast line. o Removal of note in Section 6.4 as result of issue raised by Roni Even. o Use of "m=" has been changed to media description and a few other editorial improvements and clarifications. B.9. Modifications Between WG Version -05 and -06 o Added section on RTP Aspects o Added a requirement (5-4) on that capability exchange must be capable of handling multi RTP stream cases. o Added extmap attribute also on first signalling example as it is a recommended to use mechanism. o Clarified the definition of the simulcast attribute and how simulcast streams relates to simulcast formats and SCIDs. o Updated References list and moved around some references between informative and normative categories. o Editorial improvements and corrections. B.10. Modifications Between WG Version -04 and -05 o Aligned with recent changes in draft-ietf-mmusic-rid and draft- ietf-avtext-rid. o Modified the SDP offer/answer section to follow the generally accepted structure, also adding a brief text on modifying the session that is aligned with draft-ietf-mmusic-rid. Burman, et al. Expires September 6, 2019 [Page 38] Internet-Draft Simulcast March 2019 o Improved text around simulcast stream identification (as opposed to the simulcast stream itself) to consistently use the acronym SCID and defined that in the Terminology section. o Changed references for RTP-level pause/resume and VP8 payload format that are now published as RFC. o Improved IANA registration text. o Removed unused reference to draft-ietf-payload-flexible-fec- scheme. o Editorial improvements and corrections. B.11. Modifications Between WG Version -03 and -04 o Changed to only use RID identification, as was consensus during IETF 94. o ABNF improvements. o Clarified offer-answer rules for initially paused streams. o Changed references for RTP topologies and RTP taxonomy documents that are now published as RFC. o Added reference to the new RID draft in AVTEXT. o Re-structured section 6 to provide an easy reference by the updated IANA section. o Added a sub-section 7.1 with a discussion of bitrate adaptation. o Editorial improvements. B.12. Modifications Between WG Version -02 and -03 o Removed text on multicast / broadcast from use cases, since it is not supported by the solution. o Removed explicit references to unified plan draft. o Added possibility to initiate simulcast streams in paused mode. o Enabled an offerer to offer multiple stream identification (pt or rid) methods and have the answerer choose which to use. o Added a preference indication also in send direction offers. Burman, et al. Expires September 6, 2019 [Page 39] Internet-Draft Simulcast March 2019 o Added a section on limitations of the current proposal, including identification method specific limitations. B.13. Modifications Between WG Version -01 and -02 o Relying on the new RID solution for codec constraints and configuration identification. This has resulted in changes in syntax to identify if pt or RID is used to describe the simulcast stream. o Renamed simulcast version and simulcast version alternative to simulcast stream and simulcast format respectively, and improved definitions for them. o Clarification that it is possible to switch between simulcast version alternatives, but that only a single one be used at any point in time. o Changed the definition so that ordering of simulcast formats for a specific simulcast stream do have a preference order. B.14. Modifications Between WG Version -00 and -01 o No changes. Only preventing expiry. B.15. Modifications Between Individual Version -00 and WG Version -00 o Added this appendix. Authors' Addresses Bo Burman Ericsson Gronlandsgatan 31 SE-164 60 Stockholm Sweden Email: bo.burman@ericsson.com Magnus Westerlund Ericsson Torshamnsgatan 23 SE-164 83 Stockholm Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Burman, et al. Expires September 6, 2019 [Page 40] Internet-Draft Simulcast March 2019 Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: snandaku@cisco.com Mo Zanaty Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: mzanaty@cisco.com Burman, et al. Expires September 6, 2019 [Page 41] ./draft-ietf-rtcweb-security-12.txt0000644000764400076440000020011213507676213016514 0ustar iustyiusty RTC-Web E. Rescorla Internet-Draft RTFM, Inc. Intended status: Standards Track July 5, 2019 Expires: January 6, 2020 Security Considerations for WebRTC draft-ietf-rtcweb-security-12 Abstract WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. 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 https://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 6, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Rescorla Expires January 6, 2020 [Page 1] Internet-Draft WebRTC Security July 2019 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Browser Threat Model . . . . . . . . . . . . . . . . . . 4 3.1. Access to Local Resources . . . . . . . . . . . . . . . . 5 3.2. Same-Origin Policy . . . . . . . . . . . . . . . . . . . 5 3.3. Bypassing SOP: CORS, WebSockets, and consent to communicate . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security for WebRTC Applications . . . . . . . . . . . . . . 7 4.1. Access to Local Devices . . . . . . . . . . . . . . . . . 7 4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 8 4.1.2. Calling Scenarios and User Expectations . . . . . . . 8 4.1.2.1. Dedicated Calling Services . . . . . . . . . . . 9 4.1.2.2. Calling the Site You're On . . . . . . . . . . . 9 4.1.3. Origin-Based Security . . . . . . . . . . . . . . . . 10 4.1.4. Security Properties of the Calling Page . . . . . . . 11 4.2. Communications Consent Verification . . . . . . . . . . . 12 4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 14 4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15 4.3. Communications Security . . . . . . . . . . . . . . . . . 15 4.3.1. Protecting Against Retrospective Compromise . . . . . 16 4.3.2. Protecting Against During-Call Attack . . . . . . . . 17 4.3.2.1. Key Continuity . . . . . . . . . . . . . . . . . 17 4.3.2.2. Short Authentication Strings . . . . . . . . . . 18 4.3.2.3. Third Party Identity . . . . . . . . . . . . . . 19 4.3.2.4. Page Access to Media . . . . . . . . . . . . . . 19 4.3.3. Malicious Peers . . . . . . . . . . . . . . . . . . . 20 4.4. Privacy Considerations . . . . . . . . . . . . . . . . . 20 4.4.1. Correlation of Anonymous Calls . . . . . . . . . . . 21 4.4.2. Browser Fingerprinting . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 Rescorla Expires January 6, 2020 [Page 2] Internet-Draft WebRTC Security July 2019 8. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The Real-Time Communications on the Web (RTCWEB) working group has standardized protocols for real-time communications between Web browsers, generally called "WebRTC" [I-D.ietf-rtcweb-overview]. The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems, (e.g., SIP-based [RFC3261] soft phones) WebRTC communications are directly controlled by some Web server. A simple case is shown below. +----------------+ | | | Web Server | | | +----------------+ ^ ^ / \ HTTP / \ HTTP or / \ or WebSockets / \ WebSockets v v JS API JS API +-----------+ +-----------+ | | Media | | | Browser |<---------->| Browser | | | | | +-----------+ +-----------+ Alice Bob Figure 1: A simple WebRTC system In the system shown in Figure 1, Alice and Bob both have WebRTC- enabled browsers and they visit some Web server which operates a calling service. Each of their browsers exposes standardized JavaScript calling APIs (implemented as browser built-ins) which are used by the Web server to set up a call between Alice and Bob. The Web server also serves as the signaling channel to transport control messages between the browsers. While this system is topologically similar to a conventional SIP-based system (with the Web server acting as the signaling service and browsers acting as softphones), Rescorla Expires January 6, 2020 [Page 3] Internet-Draft WebRTC Security July 2019 control has moved to the central Web server; the browser simply provides API points that are used by the calling service. As with any Web application, the Web server can move logic between the server and JavaScript in the browser, but regardless of where the code is executing, it is ultimately under control of the server. It should be immediately apparent that this type of system poses new security challenges beyond those of a conventional VoIP system. In particular, it needs to contend with malicious calling services. For example, if the calling service can cause the browser to make a call at any time to any callee of its choice, then this facility can be used to bug a user's computer without their knowledge, simply by placing a call to some recording service. More subtly, if the exposed APIs allow the server to instruct the browser to send arbitrary content, then they can be used to bypass firewalls or mount denial of service attacks. Any successful system will need to be resistant to this and other attacks. A companion document [I-D.ietf-rtcweb-security-arch] describes a security architecture intended to address the issues raised in this document. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The Browser Threat Model The security requirements for WebRTC follow directly from the requirement that the browser's job is to protect the user. Huang et al. [huang-w2sp] summarize the core browser security guarantee as: Users can safely visit arbitrary web sites and execute scripts provided by those sites. It is important to realize that this includes sites hosting arbitrary malicious scripts. The motivation for this requirement is simple: it is trivial for attackers to divert users to sites of their choice. For instance, an attacker can purchase display advertisements which direct the user (either automatically or via user clicking) to their site, at which point the browser will execute the attacker's scripts. Thus, it is important that it be safe to view arbitrarily malicious pages. Of course, browsers inevitably have bugs which cause them to fall short of this goal, but any new WebRTC functionality must be Rescorla Expires January 6, 2020 [Page 4] Internet-Draft WebRTC Security July 2019 designed with the intent to meet this standard. The remainder of this section provides more background on the existing Web security model. In this model, then, the browser acts as a Trusted Coomputing Base (TCB) both from the user's perspective and to some extent from the server's. While HTML and JavaScript (JS) provided by the server can cause the browser to execute a variety of actions, those scripts operate in a sandbox that isolates them both from the user's computer and from each other, as detailed below. Conventionally, we refer to either web attackers, who are able to induce you to visit their sites but do not control the network, and network attackers, who are able to control your network. Network attackers correspond to the [RFC3552] "Internet Threat Model". Note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker. 3.1. Access to Local Resources While the browser has access to local resources such as keying material, files, the camera, and the microphone, it strictly limits or forbids web servers from accessing those same resources. For instance, while it is possible to produce an HTML form which will allow file upload, a script cannot do so without user consent and in fact cannot even suggest a specific file (e.g., /etc/passwd); the user must explicitly select the file and consent to its upload. [Note: in many cases browsers are explicitly designed to avoid dialogs with the semantics of "click here to bypass security checks", as extensive research [cranor-wolf] shows that users are prone to consent under such circumstances.] Similarly, while Flash programs (SWFs) [SWF] can access the camera and microphone, they explicitly require that the user consent to that access. In addition, some resources simply cannot be accessed from the browser at all. For instance, there is no real way to run specific executables directly from a script (though the user can of course be induced to download executable files and run them). 3.2. Same-Origin Policy Many other resources are accessible but isolated. For instance, while scripts are allowed to make HTTP requests via the XMLHttpRequest() API (see [XmlHttpRequest]) those requests are not Rescorla Expires January 6, 2020 [Page 5] Internet-Draft WebRTC Security July 2019 allowed to be made to any server, but rather solely to the same ORIGIN from whence the script came [RFC6454] (although CORS [CORS] and WebSockets [RFC6455] provide an escape hatch from this restriction, as described below.) This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks on server B via the user's browser, which protects both the user (e.g., from misuse of his credentials) and the server B (e.g., from DoS attack). More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes. While there are techniques to allow them to interact, those interactions generally must be mutually consensual (by each site) and are limited to certain channels. For instance, multiple pages/browser panes from the same origin can read each other's JS variables, but pages from the different origins--or even iframes from different origins on the same page--cannot. 3.3. Bypassing SOP: CORS, WebSockets, and consent to communicate While SOP serves an important security function, it also makes it inconvenient to write certain classes of applications. In particular, mash-ups, in which a script from origin A uses resources from origin B, can only be achieved via a certain amount of hackery. The W3C Cross-Origin Resource Sharing (CORS) spec [CORS] is a response to this demand. In CORS, when a script from origin A executes what would otherwise be a forbidden cross-origin request, the browser instead contacts the target server to determine whether it is willing to allow cross-origin requests from A. If it is so willing, the browser then allows the request. This consent verification process is designed to safely allow cross-origin requests. While CORS is designed to allow cross-origin HTTP requests, WebSockets [RFC6455] allows cross-origin establishment of transparent channels. Once a WebSockets connection has been established from a script to a site, the script can exchange any traffic it likes without being required to frame it as a series of HTTP request/ response transactions. As with CORS, a WebSockets transaction starts with a consent verification stage to avoid allowing scripts to simply send arbitrary data to another origin. While consent verification is conceptually simple--just do a handshake before you start exchanging the real data--experience has shown that designing a correct consent verification system is difficult. In particular, Huang et al. [huang-w2sp] have shown vulnerabilities in the existing Java and Flash consent verification techniques and in a simplified version of the WebSockets handshake. In particular, it is important to be wary of CROSS-PROTOCOL attacks in which the attacking script generates traffic which is acceptable Rescorla Expires January 6, 2020 [Page 6] Internet-Draft WebRTC Security July 2019 to some non-Web protocol state machine. In order to resist this form of attack, WebSockets incorporates a masking technique intended to randomize the bits on the wire, thus making it more difficult to generate traffic which resembles a given protocol. 4. Security for WebRTC Applications 4.1. Access to Local Devices As discussed in Section 1, allowing arbitrary sites to initiate calls violates the core Web security guarantee; without some access restrictions on local devices, any malicious site could simply bug a user. At minimum, then, it MUST NOT be possible for arbitrary sites to initiate calls to arbitrary locations without user consent. This immediately raises the question, however, of what should be the scope of user consent. In order for the user to make an intelligent decision about whether to allow a call (and hence his camera and microphone input to be routed somewhere), he must understand either who is requesting access, where the media is going, or both. As detailed below, there are two basic conceptual models: 1. You are sending your media to entity A because you want to talk to Entity A (e.g., your mother). 2. Entity A (e.g., a calling service) asks to access the user's devices with the assurance that it will transfer the media to entity B (e.g., your mother) In either case, identity is at the heart of any consent decision. Moreover, the identity of the party the browser is connecting to is all that the browser can meaningfully enforce; if you are calling A, A can simply forward the media to C. Similarly, if you authorize A to place a call to B, A can call C instead. In either cases, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes. The target of the media can of course advertise a security/privacy policy, but this is not something that the browser can enforce. Even so, there are a variety of different consent scenarios that motivate different technical consent mechanisms. We discuss these mechanisms in the sections below. It's important to understand that consent to access local devices is largely orthogonal to consent to transmit various kinds of data over the network (see Section 4.2). Consent for device access is largely a matter of protecting the user's privacy from malicious sites. By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network. Thus, we Rescorla Expires January 6, 2020 [Page 7] Internet-Draft WebRTC Security July 2019 need to ensure communications consent even if the site is not able to access the camera and microphone at all (hence WebSockets's consent mechanism) and similarly we need to be concerned with the site accessing the user's camera and microphone even if the data is to be sent back to the site via conventional HTTP-based network mechanisms such as HTTP POST. 4.1.1. Threats from Screen Sharing In addition to camera and microphone access, there has been demand for screen and/or application sharing functionality. Unfortunately, the security implications of this functionality are much harder for users to intuitively analyze than for camera and microphone access. (See http://lists.w3.org/Archives/Public/public- webrtc/2013Mar/0024.html for a full analysis.) The most obvious threats are simply those of "oversharing". I.e., the user may believe they are sharing a window when in fact they are sharing an application, or may forget they are sharing their whole screen, icons, notifications, and all. This is already an issue with existing screen sharing technologies and is made somewhat worse if a partially trusted site is responsible for asking for the resource to be shared rather than having the user propose it. A less obvious threat involves the impact of screen sharing on the Web security model. A key part of the Same-Origin Policy is that HTML or JS from site A can reference content from site B and cause the browser to load it, but (unless explicitly permitted) cannot see the result. However, if a web application from a site is screen sharing the browser, then this violates that invariant, with serious security consequences. For example, an attacker site might request screen sharing and then briefly open up a new Window to the user's bank or webmail account, using screen sharing to read the resulting displayed content. A more sophisticated attack would be open up a source view window to a site and use the screen sharing result to view anti cross-site request forgery tokens. These threats suggest that screen/application sharing might need a higher level of user consent than access to the camera or microphone. 4.1.2. Calling Scenarios and User Expectations While a large number of possible calling scenarios are possible, the scenarios discussed in this section illustrate many of the difficulties of identifying the relevant scope of consent. Rescorla Expires January 6, 2020 [Page 8] Internet-Draft WebRTC Security July 2019 4.1.2.1. Dedicated Calling Services The first scenario we consider is a dedicated calling service. In this case, the user has a relationship with a calling site and repeatedly makes calls on it. It is likely that rather than having to give permission for each call that the user will want to give the calling service long-term access to the camera and microphone. This is a natural fit for a long-term consent mechanism (e.g., installing an app store "application" to indicate permission for the calling service.) A variant of the dedicated calling service is a gaming site (e.g., a poker site) which hosts a dedicated calling service to allow players to call each other. With any kind of service where the user may use the same service to talk to many different people, there is a question about whether the user can know who they are talking to. If I grant permission to calling service A to make calls on my behalf, then I am implicitly granting it permission to bug my computer whenever it wants. This suggests another consent model in which a site is authorized to make calls but only to certain target entities (identified via media-plane cryptographic mechanisms as described in Section 4.3.2 and especially Section 4.3.2.3.) Note that the question of consent here is related to but distinct from the question of peer identity: I might be willing to allow a calling site to in general initiate calls on my behalf but still have some calls via that site where I can be sure that the site is not listening in. 4.1.2.2. Calling the Site You're On Another simple scenario is calling the site you're actually visiting. The paradigmatic case here is the "click here to talk to a representative" windows that appear on many shopping sites. In this case, the user's expectation is that they are calling the site they're actually visiting. However, it is unlikely that they want to provide a general consent to such a site; just because I want some information on a car doesn't mean that I want the car manufacturer to be able to activate my microphone whenever they please. Thus, this suggests the need for a second consent mechanism where I only grant consent for the duration of a given call. As described in Section 3.1, great care must be taken in the design of this interface to avoid the users just clicking through. Note also that the user interface chrome, which is the representation through which the user interacts with the user agent itself, must clearly display elements showing that the call is continuing in order to avoid attacks where the calling site just leaves it up indefinitely but shows a Web UI that implies otherwise. Rescorla Expires January 6, 2020 [Page 9] Internet-Draft WebRTC Security July 2019 4.1.3. Origin-Based Security Now that we have described the calling scenarios, we can start to reason about the security requirements. As discussed in Section 3.2, the basic unit of Web sandboxing is the origin, and so it is natural to scope consent to origin. Specifically, a script from origin A MUST only be allowed to initiate communications (and hence to access camera and microphone) if the user has specifically authorized access for that origin. It is of course technically possible to have coarser-scoped permissions, but because the Web model is scoped to origin, this creates a difficult mismatch. Arguably, origin is not fine-grained enough. Consider the situation where Alice visits a site and authorizes it to make a single call. If consent is expressed solely in terms of origin, then at any future visit to that site (including one induced via mash-up or ad network), the site can bug Alice's computer, use the computer to place bogus calls, etc. While in principle Alice could grant and then revoke the privilege, in practice privileges accumulate; if we are concerned about this attack, something else is needed. There are a number of potential countermeasures to this sort of issue. Individual Consent Ask the user for permission for each call. Callee-oriented Consent Only allow calls to a given user. Cryptographic Consent Only allow calls to a given set of peer keying material or to a cryptographically established identity. Unfortunately, none of these approaches is satisfactory for all cases. As discussed above, individual consent puts the user's approval in the UI flow for every call. Not only does this quickly become annoying but it can train the user to simply click "OK", at which point the consent becomes useless. Thus, while it may be necessary to have individual consent in some case, this is not a suitable solution for (for instance) the calling service case. Where Rescorla Expires January 6, 2020 [Page 10] Internet-Draft WebRTC Security July 2019 necessary, in-flow user interfaces must be carefully designed to avoid the risk of the user blindly clicking through. The other two options are designed to restrict calls to a given target. Callee-oriented consent provided by the calling site would not work well because a malicious site can claim that the user is calling any user of his choice. One fix for this is to tie calls to a cryptographically-established identity. While not suitable for all cases, this approach may be useful for some. If we consider the case of advertising, it's not particularly convenient to require the advertiser to instantiate an iframe on the hosting site just to get permission; a more convenient approach is to cryptographically tie the advertiser's certificate to the communication directly. We're still tying permissions to origin here, but to the media origin (and- or destination) rather than to the Web origin. [I-D.ietf-rtcweb-security-arch] describes mechanisms which facilitate this sort of consent. Another case where media-level cryptographic identity makes sense is when a user really does not trust the calling site. For instance, I might be worried that the calling service will attempt to bug my computer, but I also want to be able to conveniently call my friends. If consent is tied to particular communications endpoints, then my risk is limited. Naturally, it is somewhat challenging to design UI primitives which express this sort of policy. The problem becomes even more challenging in multi-user calling cases. 4.1.4. Security Properties of the Calling Page Origin-based security is intended to secure against web attackers. However, we must also consider the case of network attackers. Consider the case where I have granted permission to a calling service by an origin that has the HTTP scheme, e.g., http://calling- service.example.com. If I ever use my computer on an unsecured network (e.g., a hotspot or if my own home wireless network is insecure), and browse any HTTP site, then an attacker can bug my computer. The attack proceeds like this: 1. I connect to http://anything.example.org/. Note that this site is unaffiliated with the calling service. 2. The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com 3. The attacker forges the response from http://calling- service.example.com/ to inject JS to initiate a call to himself. Rescorla Expires January 6, 2020 [Page 11] Internet-Draft WebRTC Security July 2019 Note that this attack does not depend on the media being insecure. Because the call is to the attacker, it is also encrypted to him. Moreover, it need not be executed immediately; the attacker can "infect" the origin semi-permanently (e.g., with a web worker or a popped-up window that is hidden under the main window.) and thus be able to bug me long after I have left the infected network. This risk is created by allowing calls at all from a page fetched over HTTP. Even if calls are only possible from HTTPS [RFC2818] sites, if those sites include active content (e.g., JavaScript) from an untrusted site, that JavaScript is executed in the security context of the page [finer-grained]. This could lead to compromise of a call even if the parent page is safe. Note: this issue is not restricted to PAGES which contain untrusted content. If any page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi- permanently. 4.2. Communications Consent Verification As discussed in Section 3.3, allowing web applications unrestricted network access via the browser introduces the risk of using the browser as an attack platform against machines which would not otherwise be accessible to the malicious site, for instance because they are topologically restricted (e.g., behind a firewall or NAT). In order to prevent this form of attack as well as cross-protocol attacks it is important to require that the target of traffic explicitly consent to receiving the traffic in question. Until that consent has been verified for a given endpoint, traffic other than the consent handshake MUST NOT be sent to that endpoint. Note that consent verification is not sufficient to prevent overuse of network resources. Because WebRTC allows for a Web site to create data flows between two browser instances without user consent, it is possible for a malicious site to chew up a significant amount of a user's bandwidth without incurring significant costs to himself by setting up such a channel to another user. However, as a practical matter there are a large number of Web sites which can act as data sources, so an attacker can at least use downlink bandwidth with existing Web APIs. However, this potential DoS vector reinforces the need for adequate congestion control for WebRTC protocols to ensure that they play fair with other demands on the user's bandwidth. Rescorla Expires January 6, 2020 [Page 12] Internet-Draft WebRTC Security July 2019 4.2.1. ICE Verifying receiver consent requires some sort of explicit handshake, but conveniently we already need one in order to do NAT hole- punching. Interactive Connectivity Establishment (ICE) [RFC8445] includes a handshake designed to verify that the receiving element wishes to receive traffic from the sender. It is important to remember here that the site initiating ICE is presumed malicious; in order for the handshake to be secure the receiving element MUST demonstrate receipt/knowledge of some value not available to the site (thus preventing the site from forging responses). In order to achieve this objective with ICE, the STUN transaction IDs must be generated by the browser and MUST NOT be made available to the initiating script, even via a diagnostic interface. Verifying receiver consent also requires verifying the receiver wants to receive traffic from a particular sender, and at this time; for example a malicious site may simply attempt ICE to known servers that are using ICE for other sessions. ICE provides this verification as well, by using the STUN credentials as a form of per-session shared secret. Those credentials are known to the Web application, but would need to also be known and used by the STUN-receiving element to be useful. There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it. Because ICE keepalives are indications, they will not work here. [RFC7675] describes the mechanism for providing consent freshness. 4.2.2. Masking Once consent is verified, there still is some concern about misinterpretation attacks as described by Huang et al.[huang-w2sp]. Where TCP is used the risk is substantial due to the potential presence of transparent proxies and therefore if TCP is to be used, then WebSockets style masking MUST be employed. Since DTLS (with the anti-chosen plaintext mechanisms required by TLS 1.1) does not allow the attacker to generate predictable ciphertext, there is no need for masking of protocols running over DTLS (e.g. SCTP over DTLS, UDP over DTLS, etc.). Note that in principle an attacker could exert some control over SRTP packets by using a combination of the WebAudio API and extremely tight timing control. The primary risk here seems to be carriage of SRTP over TURN TCP. However, as SRTP packets have an extremely characteristic packet header it seems unlikely that any but the most aggressive intermediaries would be confused into thinking that another application layer protocol was in use. Rescorla Expires January 6, 2020 [Page 13] Internet-Draft WebRTC Security July 2019 4.2.3. Backward Compatibility A requirement to use ICE limits compatibility with legacy non-ICE clients. It seems unsafe to completely remove the requirement for some check. All proposed checks have the common feature that the browser sends some message to the candidate traffic recipient and refuses to send other traffic until that message has been replied to. The message/reply pair must be generated in such a way that an attacker who controls the Web application cannot forge them, generally by having the message contain some secret value that must be incorporated (e.g., echoed, hashed into, etc.). Non-ICE candidates for this role (in cases where the legacy endpoint has a public address) include: o STUN checks without using ICE (i.e., the non-RTC-web endpoint sets up a STUN responder.) o Use of RTCP as an implicit reachability check. In the RTCP approach, the WebRTC endpoint is allowed to send a limited number of RTP packets prior to receiving consent. This allows a short window of attack. In addition, some legacy endpoints do not support RTCP, so this is a much more expensive solution for such endpoints, for which it would likely be easier to implement ICE. For these two reasons, an RTCP-based approach does not seem to address the security issue satisfactorily. In the STUN approach, the WebRTC endpoint is able to verify that the recipient is running some kind of STUN endpoint but unless the STUN responder is integrated with the ICE username/password establishment system, the WebRTC endpoint cannot verify that the recipient consents to this particular call. This may be an issue if existing STUN servers are operated at addresses that are not able to handle bandwidth-based attacks. Thus, this approach does not seem satisfactory either. If the systems are tightly integrated (i.e., the STUN endpoint responds with responses authenticated with ICE credentials) then this issue does not exist. However, such a design is very close to an ICE-Lite implementation (indeed, arguably is one). An intermediate approach would be to have a STUN extension that indicated that one was responding to WebRTC checks but not computing integrity checks based on the ICE credentials. This would allow the use of standalone STUN servers without the risk of confusing them with legacy STUN servers. If a non-ICE legacy solution is needed, then this is probably the best choice. Rescorla Expires January 6, 2020 [Page 14] Internet-Draft WebRTC Security July 2019 Once initial consent is verified, we also need to verify continuing consent, in order to avoid attacks where two people briefly share an IP (e.g., behind a NAT in an Internet cafe) and the attacker arranges for a large, unstoppable, traffic flow to the network and then leaves. The appropriate technologies here are fairly similar to those for initial consent, though are perhaps weaker since the threats are less severe. 4.2.4. IP Location Privacy Note that as soon as the callee sends their ICE candidates, the caller learns the callee's IP addresses. The callee's server reflexive address reveals a lot of information about the callee's location. In order to avoid tracking, implementations may wish to suppress the start of ICE negotiation until the callee has answered. In addition, either side may wish to hide their location from the other side entirely by forcing all traffic through a TURN server. In ordinary operation, the site learns the browser's IP address, though it may be hidden via mechanisms like Tor [http://www.torproject.org] or a VPN. However, because sites can cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address. Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. See [I-D.ietf-rtcweb-ip-handling] for additional information. 4.3. Communications Security Finally, we consider a problem familiar from the SIP world: communications security. For obvious reasons, it MUST be possible for the communicating parties to establish a channel which is secure against both message recovery and message modification. (See [RFC5479] for more details.) This service must be provided for both data and voice/video. Ideally the same security mechanisms would be used for both types of content. Technology for providing this service (for instance, SRTP [RFC3711], DTLS [RFC6347] and DTLS-SRTP [RFC5763]) is well understood. However, we must examine this technology in the WebRTC context, where the threat model is somewhat different. In general, it is important to understand that unlike a conventional SIP proxy, the calling service (i.e., the Web server) controls not only the channel between the communicating endpoints but also the application running on the user's browser. While in principle it is possible for the browser to cut the calling service out of the loop Rescorla Expires January 6, 2020 [Page 15] Internet-Draft WebRTC Security July 2019 and directly present trusted information (and perhaps get consent), practice in modern browsers is to avoid this whenever possible. "In- flow" modal dialogs which require the user to consent to specific actions are particularly disfavored as human factors research indicates that unless they are made extremely invasive, users simply agree to them without actually consciously giving consent. [abarth-rtcweb]. Thus, nearly all the UI will necessarily be rendered by the browser but under control of the calling service. This likely includes the peer's identity information, which, after all, is only meaningful in the context of some calling service. This limitation does not mean that preventing attack by the calling service is completely hopeless. However, we need to distinguish between two classes of attack: Retrospective compromise of calling service. The calling service is non-malicious during a call but subsequently is compromised and wishes to attack an older call (often called a "passive attack") During-call attack by calling service. The calling service is compromised during the call it wishes to attack (often called an "active attack"). Providing security against the former type of attack is practical using the techniques discussed in Section 4.3.1. However, it is extremely difficult to prevent a trusted but malicious calling service from actively attacking a user's calls, either by mounting a Man-in-the-Middle (MITM) attack or by diverting them entirely. (Note that this attack applies equally to a network attacker if communications to the calling service are not secured.) We discuss some potential approaches and why they are likely to be impractical in Section 4.3.2. 4.3.1. Protecting Against Retrospective Compromise In a retrospective attack, the calling service was uncompromised during the call, but that an attacker subsequently wants to recover the content of the call. We assume that the attacker has access to the protected media stream as well as having full control of the calling service. If the calling service has access to the traffic keying material (as in SDES [RFC4568]), then retrospective attack is trivial. This form Rescorla Expires January 6, 2020 [Page 16] Internet-Draft WebRTC Security July 2019 of attack is particularly serious in the Web context because it is standard practice in Web services to run extensive logging and monitoring. Thus, it is highly likely that if the traffic key is part of any HTTP request it will be logged somewhere and thus subject to subsequent compromise. It is this consideration that makes an automatic, public key-based key exchange mechanism imperative for WebRTC (this is a good idea for any communications security system) and this mechanism SHOULD provide perfect forward secrecy (PFS). The signaling channel/calling service can be used to authenticate this mechanism. In addition, if end-to-end keying is in used, the system MUST NOT provide any APIs to extract either long-term keying material or to directly access any stored traffic keys. Otherwise, an attacker who subsequently compromised the calling service might be able to use those APIs to recover the traffic keys and thus compromise the traffic. 4.3.2. Protecting Against During-Call Attack Protecting against attacks during a call is a more difficult proposition. Even if the calling service cannot directly access keying material (as recommended in the previous section), it can simply mount a man-in-the-middle attack on the connection, telling Alice that she is calling Bob and Bob that he is calling Alice, while in fact the calling service is acting as a calling bridge and capturing all the traffic. Protecting against this form of attack requires positive authentication of the remote endpoint such as explicit out-of-band key verification (e.g., by a fingerprint) or a third-party identity service as described in [I-D.ietf-rtcweb-security-arch]. 4.3.2.1. Key Continuity One natural approach is to use "key continuity". While a malicious calling service can present any identity it chooses to the user, it cannot produce a private key that maps to a given public key. Thus, it is possible for the browser to note a given user's public key and generate an alarm whenever that user's key changes. SSH [RFC4251] uses a similar technique. (Note that the need to avoid explicit user consent on every call precludes the browser requiring an immediate manual check of the peer's key). Unfortunately, this sort of key continuity mechanism is far less useful in the WebRTC context. First, much of the virtue of WebRTC (and any Web application) is that it is not bound to particular piece of client software. Thus, it will be not only possible but routine for a user to use multiple browsers on different computers which will Rescorla Expires January 6, 2020 [Page 17] Internet-Draft WebRTC Security July 2019 of course have different keying material (SACRED [RFC3760] notwithstanding.) Thus, users will frequently be alerted to key mismatches which are in fact completely legitimate, with the result that they are trained to simply click through them. As it is known that users routinely will click through far more dire warnings [cranor-wolf], it seems extremely unlikely that any key continuity mechanism will be effective rather than simply annoying. Moreover, it is trivial to bypass even this kind of mechanism. Recall that unlike the case of SSH, the browser never directly gets the peer's identity from the user. Rather, it is provided by the calling service. Even enabling a mechanism of this type would require an API to allow the calling service to tell the browser "this is a call to user X". All the calling service needs to do to avoid triggering a key continuity warning is to tell the browser that "this is a call to user Y" where Y is confusable with X. Even if the user actually checks the other side's name (which all available evidence indicates is unlikely), this would require (a) the browser to use the trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. 4.3.2.2. Short Authentication Strings ZRTP [RFC6189] uses a "short authentication string" (SAS) which is derived from the key agreement protocol. This SAS is designed to be compared by the users (e.g., read aloud over the voice channel or transmitted via an out of band channel) and if confirmed by both sides precludes MITM attack. The intention is that the SAS is used once and then key continuity (though a different mechanism from that discussed above) is used thereafter. Unfortunately, the SAS does not offer a practical solution to the problem of a compromised calling service. "Voice conversion" systems, which modify voice from one speaker to make it sound like another, are an active area of research. These systems are already good enough to fool both automatic recognition systems [farus-conversion] and humans [kain-conversion] in many cases, and are of course likely to improve in future, especially in an environment where the user just wants to get on with the phone call. Thus, even if SAS is effective today, it is likely not to be so for much longer. Additionally, it is unclear that users will actually use an SAS. As discussed above, the browser UI constraints preclude requiring the SAS exchange prior to completing the call and so it must be voluntary; at most the browser will provide some UI indicator that the SAS has not yet been checked. However, it is well-known that Rescorla Expires January 6, 2020 [Page 18] Internet-Draft WebRTC Security July 2019 when faced with optional security mechanisms, many users simply ignore them [whitten-johnny]. Once users have checked the SAS once, key continuity is required to avoid them needing to check it on every call. However, this is problematic for reasons indicated in Section 4.3.2.1. In principle it is of course possible to render a different UI element to indicate that calls are using an unauthenticated set of keying material (recall that the attacker can just present a slightly different name so that the attack shows the same UI as a call to a new device or to someone you haven't called before) but as a practical matter, users simply ignore such indicators even in the rather more dire case of mixed content warnings. 4.3.2.3. Third Party Identity The conventional approach to providing communications identity has of course been to have some third party identity system (e.g., PKI) to authenticate the endpoints. Such mechanisms have proven to be too cumbersome for use by typical users (and nearly too cumbersome for administrators). However, a new generation of Web-based identity providers (BrowserID, Federated Google Login, Facebook Connect, OAuth [RFC6749], OpenID [OpenID], WebFinger [RFC7033]), has recently been developed and use Web technologies to provide lightweight (from the user's perspective) third-party authenticated transactions. It is possible to use systems of this type to authenticate WebRTC calls, linking them to existing user notions of identity (e.g., Facebook adjacencies). Specifically, the third-party identity system is used to bind the user's identity to cryptographic keying material which is then used to authenticate the calling endpoints. Calls which are authenticated in this fashion are naturally resistant even to active MITM attack by the calling site. Note that there is one special case in which PKI-style certificates do provide a practical solution: calls from end-users to large sites. For instance, if you are making a call to Amazon.com, then Amazon can easily get a certificate to authenticate their media traffic, just as they get one to authenticate their Web traffic. This does not provide additional security value in cases in which the calling site and the media peer are one in the same, but might be useful in cases in which third parties (e.g., ad networks or retailers) arrange for calls but do not participate in them. 4.3.2.4. Page Access to Media Identifying the identity of the far media endpoint is a necessary but not sufficient condition for providing media security. In WebRTC, media flows are rendered into HTML5 MediaStreams which can be Rescorla Expires January 6, 2020 [Page 19] Internet-Draft WebRTC Security July 2019 manipulated by the calling site. Obviously, if the site can modify or view the media, then the user is not getting the level of assurance they would expect from being able to authenticate their peer. In many cases, this is acceptable because the user values site-based special effects over complete security from the site. However, there are also cases where users wish to know that the site cannot interfere. In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams. This verification must be possible both from the local side and the remote side. I.e., users must be able to verify that the person called has engaged a secure media mode (see Section 4.3.3). In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the previous sections. It should be noted that the use of this secure media mode is left to the discretion of the site. When such a mode is engaged, the browser will need to provide indicia to the user that the associated media has been authenticated as coming from the identified user. This allows WebRTC services that wish to claim end-to-end security to do so in a way that can be easily verified by the user. This model requires that the remote party's browser be included in the TCB, as described in Section 3. 4.3.3. Malicious Peers One class of attack that we do not generally try to prevent is malicious peers. For instance, no matter what confidentiality measures you employ the person you are talking to might record the call and publish it on the Internet. Similarly, we do not attempt to prevent them from using voice or video processing technology from hiding or changing their appearance. While technologies (DRM, etc.) do exist to attempt to address these issues, they are generally not compatible with open systems and WebRTC does not address them. Similarly, we make no attempt to prevent prank calling or other unwanted calls. In general, this is in the scope of the calling site, though because WebRTC does offer some forms of strong authentication, that may be useful as part of a defense against such attacks. 4.4. Privacy Considerations Rescorla Expires January 6, 2020 [Page 20] Internet-Draft WebRTC Security July 2019 4.4.1. Correlation of Anonymous Calls While persistent endpoint identifiers can be a useful security feature (see Section 4.3.2.1) they can also represent a privacy threat in settings where the user wishes to be anonymous. WebRTC provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to [RFC6222] rather than the privacy preserving mode of [RFC7022]). In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies). Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers. In addition, IP addresses can be a source of call linkage [I-D.ietf-rtcweb-ip-handling]. 4.4.2. Browser Fingerprinting Any new set of API features adds a risk of browser fingerprinting, and WebRTC is no exception. Specifically, sites can use the presence or absence of specific devices as a browser fingerprint. In general, the API needs to be balanced between functionality and the incremental fingerprint risk. See [Fingerprinting]. 5. Security Considerations This entire document is about security. 6. Acknowledgements Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan Johnston, Hadriel Kaplan (S 4.2.1), Matthew Kaufman, Martin Thomson, Magnus Westerlund. 7. IANA Considerations There are no IANA considerations. 8. Changes Since -04 o Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG o Removed discussion of the IFRAMEd advertisement case, since we decided not to treat it specially. o Added a privacy section considerations section. Rescorla Expires January 6, 2020 [Page 21] Internet-Draft WebRTC Security July 2019 o Significant edits to the SAS section to reflect Alan Johnston's comments. o Added some discussion if IP location privacy and Tor. o Updated the "communications consent" section to reflrect draft- ietf. o Added a section about "malicious peers". o Added a section describing screen sharing threats. o Assorted editorial changes. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [abarth-rtcweb] Barth, A., "Prompting the user is security failure", RTC- Web Workshop, September 2010. [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", January 2014. [cranor-wolf] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. cranor, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", Proceedings of the 18th USENIX Security Symposium, 2009, August 2009. [farus-conversion] Farrus, M., Erro, D., and J. Hernando, "Speaker Recognition Robustness to Voice Conversion", January 2008. Rescorla Expires January 6, 2020 [Page 22] Internet-Draft WebRTC Security July 2019 [finer-grained] Barth, A. and C. Jackson, "Beware of Finer-Grained Origins", W2SP, 2008, July 2008. [Fingerprinting] "Fingerprinting Guidance for Web Specification Authors (Draft)", November 2013. [huang-w2sp] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. Jackson, "Talking to Yourself for Fun and Profit", W2SP, 2011, May 2011. [I-D.ietf-rtcweb-ip-handling] Uberti, J., "WebRTC IP Address Handling Requirements", draft-ietf-rtcweb-ip-handling-12 (work in progress), July 2019. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-19 (work in progress), November 2017. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [kain-conversion] Kain, A. and M. Macon, "Design and Evaluation of a Voice Conversion Algorithm based on Spectral Envelope Mapping and Residual Prediction", Proceedings of ICASSP, May 2001, May 2001. [OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [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, . Rescorla Expires January 6, 2020 [Page 23] Internet-Draft WebRTC Security July 2019 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, 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, . [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 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, . [RFC5479] Wing, D., Ed., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, DOI 10.17487/RFC5479, April 2009, . [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, . [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, . [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, DOI 10.17487/RFC6222, April 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Rescorla Expires January 6, 2020 [Page 24] Internet-Draft WebRTC Security July 2019 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [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, . [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, . [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, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [SWF] "SWF File Format Specification Version 19", April 2013. [whitten-johnny] Whitten, A. and J. Tygar, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", Proceedings of the 8th USENIX Security Symposium, 1999, August 1999. [XmlHttpRequest] van Kesteren, A., "XMLHttpRequesti Level 2", January 2012. Author's Address Rescorla Expires January 6, 2020 [Page 25] Internet-Draft WebRTC Security July 2019 Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 678 2350 Email: ekr@rtfm.com Rescorla Expires January 6, 2020 [Page 26] ./draft-ietf-mmusic-sdp-uks-07.txt0000644000764400076440000013445613523403303016251 0ustar iustyiusty Network Working Group M. Thomson Internet-Draft E. Rescorla Updates: 8122 (if approved) Mozilla Intended status: Standards Track August 09, 2019 Expires: February 10, 2020 Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP) draft-ietf-mmusic-sdp-uks-07 Abstract This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be mislead about the identity of a communicating peer. Mitigation techniques are defined that implementations of RFC 8122 are encouraged to deploy. 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 https://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 10, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Thomson & Rescorla Expires February 10, 2020 [Page 1] Internet-Draft SDP UKS August 2019 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. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3 2.1. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 2.2. Interactions with Key Continuity . . . . . . . . . . . . 5 2.3. Third-Party Call Control . . . . . . . . . . . . . . . . 5 3. Unknown Key-Share with Identity Bindings . . . . . . . . . . 6 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8 3.2.1. Calculating external_id_hash for WebRTC Identity . . 9 3.2.2. Calculating external_id_hash for PASSPoRT . . . . . . 10 4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 10 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Unique Session Identity Solution . . . . . . . . . . . . 12 4.3. The external_session_id TLS Extension . . . . . . . . . . 13 5. Session Concatenation . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The use of Transport Layer Security (TLS) [TLS13] with the Session Description Protocol (SDP) [SDP] is defined in [FINGERPRINT]. Further use with Datagram Transport Layer Security (DTLS) [DTLS] and the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as DTLS-SRTP [DTLS-SRTP]. In these specifications, key agreement is performed using TLS or DTLS, with authentication being tied back to the session description (or SDP) through the use of certificate fingerprints. Communication peers check that a hash, or fingerprint, provided in the SDP matches the certificate that is used in the TLS or DTLS handshake. WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity [SIP-ID] both provide a mechanism that binds an external identity to the certificate fingerprints from a session description. However, Thomson & Rescorla Expires February 10, 2020 [Page 2] Internet-Draft SDP UKS August 2019 this binding is not integrity-protected and therefore vulnerable to an identity misbinding attack - or unknown key-share (UKS) attack - where the attacker binds their identity to the fingerprint of another entity. A successful attack leads to the creation of sessions where peers are confused about the identity of the participants. This document describes a TLS extension that can be used in combination with these identity bindings to prevent this attack. A similar attack is possible with the use of certificate fingerprints alone. Though attacks in this setting are likely infeasible in existing deployments due to the narrow conditions necessary (see Section 2.1), this document also describes mitigations for this attack. The mechanisms defined in this document are intended to strengthen the protocol by preventing the use of unknown key shares in combination with other protocol or implementation vulnerabilities. RFC 8122 [FINGERPRINT] is updated by this document to recommend the use of these mechanisms. This document assumes that signaling is integrity protected. However, as Section 7 of [FINGERPRINT] explains, many deployments that use SDP do not guarantee integrity of session signaling and so are vulnerable to other attacks. [FINGERPRINT] offers key continuity mechanisms as a potential means of reducing exposure to attack in the absence of integrity protection. Section 2.2 provides some analysis of the effect of key continuity in relation to the described attacks. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Unknown Key-Share Attack In an unknown key-share attack [UKS], a malicious participant in a protocol claims to control a key that is in reality controlled by some other actor. This arises when the identity associated with a key is not properly bound to the key. An endpoint that can acquire the certificate fingerprint of another entity can advertise that fingerprint as their own in SDP. An attacker can use a copy of that fingerprint to cause a victim to communicate with another unaware victim, even though it believes that it is communicating with the attacker. Thomson & Rescorla Expires February 10, 2020 [Page 3] Internet-Draft SDP UKS August 2019 When the identity of communicating peers is established by higher- layer signaling constructs, such as those in SIP identity [SIP-ID] or WebRTC [WEBRTC-SEC], this allows an attacker to bind their own identity to a session with any other entity. The attacker obtains an identity assertion for an identity it controls, but binds that to the fingerprint of one peer. The attacker is then able to cause a TLS connection to be established where two victim endpoints communicate. The victim that has its fingerprint copied by the attack correctly believes that it is communicating with the other victim; however, the other victim incorrectly believes that it is communicating with the attacker. An unknown key-share attack does not result in the attacker having access to any confidential information exchanged between victims. However, the failure in mutual authentication can enable other attacks. A victim might send information to the wrong entity as a result. Where information is interpreted in context, misrepresenting that context could lead to the information being misinterpreted. A similar attack can be mounted based solely on the SDP "fingerprint" attribute [FINGERPRINT] without compromising the integrity of the signaling channel. This attack is an aspect of SDP-based protocols that the technique known as third-party call control (3PCC) [RFC3725] relies on. 3PCC exploits the potential for the identity of a signaling peer to be different than the media peer, allowing the media peer to be selected by the signaling peer. Section 2.3 describes the consequences of the mitigations described here for systems that use 3PCC. 2.1. Limits on Attack Feasibility The use of TLS with SDP depends on the integrity of session signaling. Assuming signaling integrity limits the capabilities of an attacker in several ways. In particular: 1. An attacker can only modify the parts of the session signaling that they are responsible for producing, namely their own offers and answers. 2. No entity will successfully establish a session with a peer unless they are willing to participate in a session with that peer. The combination of these two constraints make the spectrum of possible attacks quite limited. An attacker is only able to switch its own certificate fingerprint for a valid certificate that is Thomson & Rescorla Expires February 10, 2020 [Page 4] Internet-Draft SDP UKS August 2019 acceptable to its peer. Attacks therefore rely on joining two separate sessions into a single session. Section 4 describes an attack on SDP signaling under these constraints. Systems that rely on strong identity bindings, such as those defined in [WEBRTC] or [SIP-ID], have a different threat model, which admits the possibility of attack by an entity with access to the signaling channel. Attacks under these conditions are more feasible as an attacker is assumed to be able to both observe and modify signaling messages. Section 3 describes an attack that assumes this threat model. 2.2. Interactions with Key Continuity Systems that use key continuity (as defined in Section 15.1 of [ZRTP] or as recommended in Section 7 of [FINGERPRINT]) might be able to detect an unknown key-share attack if a session with either the attacker or the genuine peer (i.e., the victim whose fingerprint was copied by an attacker) was established in the past. Whether this is possible depends on how key continuity is implemented. Implementations that maintain a single database of identities with an index on peer keys could discover that the identity saved for the peer key does not match the claimed identity. Such an implementation could notice the disparity between the actual keys (those copied from a victim) and the expected keys (those of the attacker). In comparison, implementations that first match based on peer identity could treat an unknown key-share attack as though their peer had used a newly-configured device. The apparent addition of a new device could generate user-visible notices (e.g., "Mallory appears to have a new device"). However, such an event is not always considered alarming; some implementations might silently save a new key. 2.3. Third-Party Call Control Third-party call control (3PCC) [RFC3725] is a technique where a signaling peer establishes a call that is terminated by a different entity. An unknown key-share attack is very similar in effect to some 3PCC practices, so use of 3PCC could appear to be an attack. However, 3PCC that follows RFC 3725 guidance is unaffected, and peers that are aware of changes made by a 3PCC controller can correctly distinguish actions of a 3PCC controller from attack. 3PCC as described in RFC 3725 is incompatible with SIP identity [SIP-ID] as SIP Identity relies on creating a binding between SIP requests and SDP. The controller is the only entity that generates SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use Thomson & Rescorla Expires February 10, 2020 [Page 5] Internet-Draft SDP UKS August 2019 of the "fingerprint" attribute without additional bindings or WebRTC identity [WEBRTC-SEC] is possible. The attack mitigation mechanisms described in this document will prevent the use of 3PCC if peers have different views of the involved identities, or the value of SDP "tls-id" attributes. For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of the signaling so that they can correctly generate and check the TLS extensions. For a connection to be successfully established, a 3PCC controller needs to either forward SDP without modification, or to avoid modifications to "fingerprint", "tls-id", and "identity" attributes. A controller that follows the best practices in RFC 3725 is expected to forward SDP without modification, thus ensuring the integrity of these attributes. 3. Unknown Key-Share with Identity Bindings The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) and the SIP PASSPoRT used in SIP identity ([SIP-ID], [PASSPoRT]) are bound to the certificate fingerprint of an endpoint. An attacker can cause an identity binding to be created that binds an identity they control to the fingerprint of a first victim. An attacker can thereby cause a second victim to believe that they are communicating with an attacker-controlled identity, when they are really talking to the first victim. The attacker does this by creating an identity assertion that covers a certificate fingerprint of the first victim. A variation on the same technique can be used to cause both victims to both believe they are talking to the attacker when they are talking to each other. In this case, the attacker performs the identity misbinding once for each victim. The problem might appear to be caused by the fact that the authority that certifies the identity binding is not required to verify that the entity requesting the binding controls the keys associated with the fingerprints. SIP and WebRTC identity providers are not required to perform this validation. However, validation of keys by the identity provider is not relevant because verifying control of the associated keys is not a necessary condition for a secure protocol, nor would it be sufficient to prevent attack [SIGMA]. A simple solution to this problem is suggested by [SIGMA]. The identity of endpoints is included under a message authentication code (MAC) during the cryptographic handshake. Endpoints then validate that their peer has provided an identity that matches their Thomson & Rescorla Expires February 10, 2020 [Page 6] Internet-Draft SDP UKS August 2019 expectations. In TLS, the Finished message provides a MAC over the entire handshake, so that including the identity in a TLS extension is sufficient to implement this solution. Rather than include a complete identity binding - which could be sizeable - a collision- and pre-image-resistant hash of the binding is included in a TLS extension as described in Section 3.2. Endpoints then need only validate that the extension contains a hash of the identity binding they received in signaling. If the identity binding is successfully validated, the identity of a peer is verified and bound to the session. This form of unknown key-share attack is possible without compromising signaling integrity, unless the defenses described in Section 4 are used. In order to prevent both forms of attack, endpoints MUST use the "external_session_id" extension (see Section 4.3) in addition to the "external_id_hash" (Section 3.2) so that two calls between the same parties can't be altered by an attacker. 3.1. Example In the example shown in Figure 1, it is assumed that the attacker also controls the signaling channel. Mallory (the attacker) presents two victims, Norma and Patsy, with two separate sessions. In the first session, Norma is presented with the option to communicate with Mallory; a second session with Norma is presented to Patsy. Norma Mallory Patsy (fp=N) ----- (fp=P) | | | |<---- Signaling1 ------>| | | Norma=N Mallory=P | | | |<---- Signaling2 ------>| | | Norma=N Patsy=P | | | |<=================DTLS (fp=N,P)=================>| | | (peer = Mallory!) (peer = Norma) Figure 1: Example Attack on Identity Bindings The attack requires that Mallory obtain an identity binding for her own identity with the fingerprints presented by Patsy (P), which Mallory might have obtained previously. This false binding is then presented to Norma (Signaling1 in the figure). Thomson & Rescorla Expires February 10, 2020 [Page 7] Internet-Draft SDP UKS August 2019 Patsy could be similarly duped, but in this example, a correct binding between Norma's identity and fingerprint (N) is faithfully presented by Mallory. This session (Signaling2 in the figure) can be entirely legitimate. A DTLS session is established directly between Norma and Patsy. In order for this to happen Mallory can substitute transport-level information in both sessions to facilitate this, though this is not necessary if Mallory is on the network path between Norma and Patsy. As a result, Patsy correctly believes that she is communicating with Norma. However, Norma incorrectly believes she is talking to Mallory. As stated in Section 2, Mallory cannot access media, but Norma might send information to Patsy that is Norma might not intend or that Patsy might misinterpret. 3.2. The external_id_hash TLS Extension The "external_id_hash" TLS extension carries a hash of the identity assertion that the endpoint sending the extension has asserted to its peer. Both peers include a hash of their own identity assertion. The "extension_data" for the "external_id_hash" extension contains a "ExternalIdentityHash" struct, described below using the syntax defined in Section 3 of [TLS13]: struct { opaque binding_hash<0..32>; } ExternalIdentityHash; Where an identity assertion has been asserted by a peer, this extension includes a SHA-256 hash of the assertion. An empty value is used to indicate support for the extension. Note: For both types of identity assertion, if SHA-256 should prove to be inadequate at some point in the future (see [AGILITY]), a new TLS extension can be defined that uses a different hash function. Identity bindings might be provided by only one peer. An endpoint that does not produce an identity binding MUST generate an empty "external_id_hash" extension in its ClientHello or - if a client provides the extension - in ServerHello or EncryptedExtensions. An empty extension has a zero-length binding_hash field. A peer that receives an "external_id_hash" extension that does not match the value of the identity binding from its peer MUST immediately fail the TLS handshake with a illegal_parameter alert. Thomson & Rescorla Expires February 10, 2020 [Page 8] Internet-Draft SDP UKS August 2019 The absence of an identity binding does not relax this requirement; if a peer provided no identity binding, a zero-length extension MUST be present to be considered valid. Implementations written prior to the definition of the extensions in this document will not support this extension for some time. A peer that receives an identity binding but does not receive an "external_id_hash" extension MAY accept a TLS connection rather than fail a connection where the extension is absent. Any validation performed of the "external_id_hash" extension is done in addition to the validation required by [FINGERPRINT] and any identity assertion definition. An "external_id_hash" extension that is any length other than 0 or 32 is invalid and MUST cause the receiving endpoint to generate a fatal "decode_error" alert. In TLS 1.3, an "external_id_hash" extension sent by a server MUST be sent in the EncryptedExtensions message. 3.2.1. Calculating external_id_hash for WebRTC Identity A WebRTC identity assertion (Section 7 of [WEBRTC-SEC]) is provided as a JSON [JSON] object that is encoded into a JSON text. The JSON text is encoded using UTF-8 [UTF8] as described by Section 8.1 of [JSON]. The content of the "external_id_hash" extension is produced by hashing the resulting octets with SHA-256 [SHA]. This produces the 32 octets of the "binding_hash" parameter, which is the sole contents of the extension. The SDP "identity" attribute includes the base64 [BASE64] encoding of the UTF-8 encoding of the same JSON text. The "external_id_hash" extension is validated by performing base64 decoding on the value of the SDP "identity" attribute, hashing the resulting octets using SHA- 256, and comparing the results with the content of the extension. In pseudocode form, using the "identity-assertion-value" field from the "identity" attribute grammar as defined in [WEBRTC-SEC]: "external_id_hash = SHA-256(b64decode(identity-assertion-value)) " Note: The base64 of the SDP "identity" attribute is decoded to avoid capturing variations in padding. The base64-decoded identity assertion could include leading or trailing whitespace octets. WebRTC identity assertions are not canonicalized; all octets are hashed. Thomson & Rescorla Expires February 10, 2020 [Page 9] Internet-Draft SDP UKS August 2019 3.2.2. Calculating external_id_hash for PASSPoRT Where the compact form of PASSPoRT [PASSPoRT] is used, it MUST be expanded into the full form. The base64 encoding used in the SIP Identity (or 'y') header field MUST be decoded then used as input to SHA-256. This produces the 32 octet "binding_hash" value used for creating or validating the extension. In pseudocode, using the "signed-identity-digest" field from the "Identity" grammar defined [SIP-ID]: "external_id_hash = SHA-256(b64decode(signed-identity-digest)) " 4. Unknown Key-Share with Fingerprints An attack on DTLS-SRTP is possible because the identity of peers involved is not established prior to establishing the call. Endpoints use certificate fingerprints as a proxy for authentication, but as long as fingerprints are used in multiple calls, they are vulnerable to attack. Even if the integrity of session signaling can be relied upon, an attacker might still be able to create a session where there is confusion about the communicating endpoints by substituting the fingerprint of a communicating endpoint. An endpoint that is configured to reuse a certificate can be attacked if it is willing to initiate two calls at the same time, one of which is with an attacker. The attacker can arrange for the victim to incorrectly believe that it is calling the attacker when it is in fact calling a second party. The second party correctly believes that it is talking to the victim. As with the attack on identity bindings, this can be used to cause two victims to both believe they are talking to the attacker when they are talking to each other. 4.1. Example To mount this attack, two sessions need to be created with the same endpoint at almost precisely the same time. One of those sessions is initiated with the attacker, the second session is created toward another honest endpoint. The attacker convinces the first endpoint that their session with the attacker has been successfully established, but media is exchanged with the other honest endpoint. The attacker permits the session with the other honest endpoint to complete only to the extent necessary to convince the other honest endpoint to participate in the attacked session. Thomson & Rescorla Expires February 10, 2020 [Page 10] Internet-Draft SDP UKS August 2019 In addition to the constraints described in Section 2.1, the attacker in this example also needs the ability to view and drop packets between victims. That is, the attacker is on-path for media. The attack shown in Figure 2 depends on a somewhat implausible set of conditions. It is intended to demonstrate what sort of attack is possible and what conditions are necessary to exploit this weakness in the protocol. Norma Mallory Patsy (fp=N) ----- (fp=P) | | | +---Signaling1 (fp=N)--->| | +-----Signaling2 (fp=N)------------------------>| |<-------------------------Signaling2 (fp=P)----+ |<---Signaling1 (fp=P)---+ | | | | |=======DTLS1=======>(Forward)======DTLS1======>| |<======DTLS2========(Forward)<=====DTLS2=======| |=======Media1======>(Forward)======Media1=====>| |<======Media2=======(Forward)<=====Media2======| | | | |=======DTLS2========>(Drop) | | | | Figure 2: Example Attack Scenario using Fingerprints In this scenario, there are two sessions initiated at the same time by Norma. Signaling is shown with single lines ('-'), DTLS and media with double lines ('='). The first session is established with Mallory, who falsely uses Patsy's certificate fingerprint (denoted with 'fp=P'). A second session is initiated between Norma and Patsy. Signaling for both sessions is permitted to complete. Once signaling is complete on the first session, a DTLS connection is established. Ostensibly, this connection is between Mallory and Norma but Mallory forwards DTLS and media packets sent to her by Norma to Patsy. These packets are denoted 'DTLS1' because Norma associates these with the first signaling session ('signaling1'). Mallory also intercepts packets from Patsy and forwards those to Norma at the transport address that Norma associates with Mallory. These packets are denoted 'DTLS2' to indicate that Patsy associates these with the second signaling session ('signaling2'), however Norma will interpret these as being associated with the first signaling session ('signaling1'). Thomson & Rescorla Expires February 10, 2020 [Page 11] Internet-Draft SDP UKS August 2019 The second signaling exchange - 'signaling2', between Norma and Patsy - is permitted to continue to the point where Patsy believes that it has succeeded. This ensures that Patsy believes that she is communicating with Norma. In the end, Norma believes that she is communicating with Mallory, when she is really communicating with Patsy. Just like the example in Section 3.1, Mallory cannot access media, but Norma might send information to Patsy that is Norma might not intend or that Patsy might misinterpret. Though Patsy needs to believe that the second signaling session has been successfully established, Mallory has no real interest in seeing that session also be established. Mallory only needs to ensure that Patsy maintains the active session and does not abandon the session prematurely. For this reason, it might be necessary to permit the signaling from Patsy to reach Norma to allow Patsy to receive a call setup completion signal, such as a SIP ACK. Once the second session is established, Mallory might cause DTLS packets sent by Norma to Patsy to be dropped. However, if Mallory allows DTLS packets to pass, it is likely that Patsy will discard them as Patsy will already have a successful DTLS connection established. For the attacked session to be sustained beyond the point that Norma detects errors in the second session, Mallory also needs to block any signaling that Norma might send to Patsy asking for the call to be abandoned. Otherwise, Patsy might receive a notice that the call is failed and thereby abort the call. This attack creates an asymmetry in the beliefs about the identity of peers. However, this attack is only possible if the victim (Norma) is willing to conduct two sessions nearly simultaneously, if the attacker (Mallory) is on the network path between the victims, and if the same certificate - and therefore SDP "fingerprint" attribute value - is used by Norma for both sessions. Where ICE [ICE] is used, Mallory also needs to ensure that connectivity checks between Patsy and Norma succeed, either by forwarding checks or answering and generating the necessary messages. 4.2. Unique Session Identity Solution The solution to this problem is to assign a new identifier to communicating peers. Each endpoint assigns their peer a unique identifier during call signaling. The peer echoes that identifier in the TLS handshake, binding that identity into the session. Including this new identity in the TLS handshake means that it will be covered by the TLS Finished message, which is necessary to authenticate it (see [SIGMA]). Thomson & Rescorla Expires February 10, 2020 [Page 12] Internet-Draft SDP UKS August 2019 Successful validation that the identifier matches the expected value means that the connection corresponds to the signaled session and is therefore established between the correct two endpoints. This solution relies on the unique identifier given to DTLS sessions using the SDP "tls-id" attribute [DTLS-SDP]. This field is already required to be unique. Thus, no two offers or answers from the same client will have the same value. A new "external_session_id" extension is added to the TLS or DTLS handshake for connections that are established as part of the same call or real-time session. This carries the value of the "tls-id" attribute and provides integrity protection for its exchange as part of the TLS or DTLS handshake. 4.3. The external_session_id TLS Extension The "external_session_id" TLS extension carries the unique identifier that an endpoint selects. When used with SDP, the value MUST include the "tls-id" attribute from the SDP that the endpoint generated when negotiating the session. This document only defines use of this extension for SDP; other methods of external session negotiation can use this extension to include a unique session identifier. The "extension_data" for the "external_session_id" extension contains an ExternalSessionId struct, described below using the syntax defined in [TLS13]: struct { opaque session_id<20..255>; } ExternalSessionId; For SDP, the "session_id" field of the extension includes the value of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the "tls-id-value" ABNF production). The value of the "tls-id" attribute is encoded using ASCII [ASCII]. Where RTP and RTCP [RTP] are not multiplexed, it is possible that the two separate DTLS connections carrying RTP and RTCP can be switched. This is considered benign since these protocols are designed to be distinguishable as SRTP [SRTP] provides key separation. Using RTP/ RTCP multiplexing [RTCP-MUX] further avoids this problem. The "external_session_id" extension is included in a ClientHello and - if the extension is present in the ClientHello - either ServerHello (for TLS and DTLS versions less than 1.3) or EncryptedExtensions (for TLS 1.3). Thomson & Rescorla Expires February 10, 2020 [Page 13] Internet-Draft SDP UKS August 2019 Endpoints MUST check that the "session_id" parameter in the extension that they receive includes the "tls-id" attribute value that they received in their peer's session description. Endpoints can perform string comparison by ASCII decoding the TLS extension value and comparing it to the SDP attribute value, or compare the encoded TLS extension octets with the encoded SDP attribute value. An endpoint that receives a "external_session_id" extension that is not identical to the value that it expects MUST abort the connection with a fatal "illegal_parameter" alert. Any validation performed of the "external_session_id" extension is done in addition to the validation required by [FINGERPRINT]. An endpoint that is communicating with a peer that does not support this extension will receive a ClientHello, ServerHello or EncryptedExtensions that does not include this extension. An endpoint MAY choose to continue a session without this extension in order to interoperate with peers that do not implement this specification. In TLS 1.3, an "external_session_id" extension sent by a server MUST be sent in the EncryptedExtensions message. This defense is not effective if an attacker can rewrite "tls-id" values in signaling. Only the mechanism in "external_id_hash" is able to defend against an attacker that can compromise session integrity. 5. Session Concatenation Use of session identifiers does not prevent an attacker from establishing two concurrent sessions with different peers and forwarding signaling from those peers to each other. Concatenating two signaling sessions in this way creates two signaling sessions, with two session identifiers, but only the TLS connections from a single session are established as a result. In doing so, the attacker creates a situation where both peers believe that they are talking to the attacker when they are talking to each other. In the absence of any higher-level concept of peer identity, the use of session identifiers does not prevent session concatenation if the attacker is able to copy the session identifier from one signaling session to another. This kind of attack is prevented by systems that enable peer authentication such as WebRTC identity [WEBRTC-SEC] or SIP identity [SIP-ID]. However, session concatenation remains possible at higher layers: an attacker can establish two independent sessions and simply forward any data it receives from one into the other. Thomson & Rescorla Expires February 10, 2020 [Page 14] Internet-Draft SDP UKS August 2019 Use of the "external_session_id" does not guarantee that the identity of the peer at the TLS layer is the same as the identity of the signaling peer. The advantage an attacker gains by concatenating sessions is limited unless data is exchanged on the assumption that signaling and TLS peers are the same. If a secondary protocol uses the signaling channel with the assumption that the signaling and TLS peers are the same then that protocol is vulnerable to attack. A signaling system that can defend against session concatenation, while out of scope for this document, requires that the signaling layer is authenticated and bound to any TLS connections. It is important to note that multiple connections can be created within the same signaling session. An attacker might concatenate only part of a session, choosing to terminate some connections (and optionally forward data) while arranging to have peers interact directly for other connections. It is even possible to have different peers interact for each connection. This means that the actual identity of the peer for one connection might differ from the peer on another connection. Critically, information about the identity of TLS peers provides no assurances about the identity of signaling peers and do not transfer between TLS connections in the same session. Information extracted from a TLS connection therefore MUST NOT be used in a secondary protocol outside of that connection if that protocol assumes that the signaling protocol has the same peers. Similarly, security-sensitive information from one TLS connection MUST NOT be used in other TLS connections even if they are established as a result of the same signaling session. 6. Security Considerations The mitigations in this document, when combined with identity assertions, ensure that there is no opportunity to misrepresent the identity of TLS peers. This assurance is provided even if an attacker can modify signaling messages. Without identity assertions, the mitigations in this document prevent the session splicing attack described in Section 4. Defense against session concatenation (Section 5) additionally requires protocol peers are not able to claim the certificate fingerprints of other entities. 7. IANA Considerations This document registers two extensions in the TLS "ExtensionType Values" registry established in [TLS13]: Thomson & Rescorla Expires February 10, 2020 [Page 15] Internet-Draft SDP UKS August 2019 o The "external_id_hash" extension defined in Section 3.2 has been assigned a code point of TBD; it is recommended and is marked as "CH, EE" in TLS 1.3. o The "external_session_id" extension defined in Section 4.3 has been assigned a code point of TBD; it is recommended and is marked as "CH, EE" in TLS 1.3. 8. References 8.1. Normative References [ASCII] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, . [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [DTLS-SDP] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 2017. [DTLS-SRTP] 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, . [FINGERPRINT] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . Thomson & Rescorla Expires February 10, 2020 [Page 16] Internet-Draft SDP UKS August 2019 [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [PASSPoRT] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [SIP-ID] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [SRTP] 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, . [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . Thomson & Rescorla Expires February 10, 2020 [Page 17] Internet-Draft SDP UKS August 2019 [WEBRTC-SEC] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-20 (work in progress), July 2019. 8.2. Informative References [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, . [RTCP-MUX] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RTP] 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, . [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to authenticated Diffie-Hellman and its use in the IKE protocols", Annual International Cryptology Conference, Springer, pp. 400-425 , 2003. [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol", Lecture Notes in Computer Science 1560, Springer, pp. 154-170 , 1999. [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Editor's Draft , November 2018. Thomson & Rescorla Expires February 10, 2020 [Page 18] Internet-Draft SDP UKS August 2019 [ZRTP] 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, . Appendix A. Acknowledgements This problem would not have been discovered if it weren't for discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A solution similar to the one presented here was first proposed by Karthik Bhargavan who provided valuable input on this document. Thyla van der Merwe assisted with a formal model of the solution. Adam Roach and Paul E. Jones provided significant review and input. Authors' Addresses Martin Thomson Mozilla Email: mt@lowentropy.net Eric Rescorla Mozilla Email: ekr@rftm.com Thomson & Rescorla Expires February 10, 2020 [Page 19] ./draft-ietf-rmcat-eval-test-10.txt0000644000764400076440000020615613471550563016404 0ustar iustyiusty Network Working Group Z. Sarker Internet-Draft Ericsson AB Intended status: Informational V. Singh Expires: November 24, 2019 callstats.io X. Zhu M. Ramalho Cisco Systems May 23, 2019 Test Cases for Evaluating RMCAT Proposals draft-ietf-rmcat-eval-test-10 Abstract The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment. 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 https://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, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Sarker, et al. Expires November 24, 2019 [Page 1] Internet-Draft Test Scenarios for RMCAT May 2019 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. Structure of Test cases . . . . . . . . . . . . . . . . . . . 3 4. Recommended Evaluation Settings . . . . . . . . . . . . . . . 8 4.1. Evaluation metrics . . . . . . . . . . . . . . . . . . . 8 4.2. Path characteristics . . . . . . . . . . . . . . . . . . 8 4.3. Media source . . . . . . . . . . . . . . . . . . . . . . 9 5. Basic Test Cases . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Variable Available Capacity with a Single Flow . . . . . 10 5.2. Variable Available Capacity with Multiple Flows . . . . . 13 5.3. Congested Feedback Link with Bi-directional Media Flows . 14 5.4. Competing Media Flows with same Congestion Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Round Trip Time Fairness . . . . . . . . . . . . . . . . 19 5.6. Media Flow Competing with a Long TCP Flow . . . . . . . . 21 5.7. Media Flow Competing with Short TCP Flows . . . . . . . . 23 5.8. Media Pause and Resume . . . . . . . . . . . . . . . . . 25 6. Other potential test cases . . . . . . . . . . . . . . . . . 27 6.1. Media Flows with Priority . . . . . . . . . . . . . . . . 27 6.2. Explicit Congestion Notification Usage . . . . . . . . . 27 6.3. Multiple Bottlenecks . . . . . . . . . . . . . . . . . . 28 7. Wireless Access Links . . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction This memo describes a set of test cases for evaluating congestion control algorithm proposals in controlled environments for real-time interactive media. It is based on the guidelines enumerated in [I-D.ietf-rmcat-eval-criteria] and the requirements discussed in [I-D.ietf-rmcat-cc-requirements]. The test cases cover basic usage scenarios and are described using a common structure, which allows for additional test cases to be added to those described herein to accommodate other topologies and/or the modelling of different path characteristics. The described test cases in this memo should be Sarker, et al. Expires November 24, 2019 [Page 2] Internet-Draft Test Scenarios for RMCAT May 2019 used to evaluate any proposed congestion control algorithm for real- time interactive media. 2. Terminology The terminology defined in RTP [RFC3550], RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], RTCP Extended Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) [RFC4585], and Support for Reduced-Size RTCP [RFC5506] apply. 3. Structure of Test cases All the test cases in this document follow a basic structure allowing implementers to describe a new test scenario without repeatedly explaining common attributes. The structure includes a general description section that describes the test case and its motivation. Additionally the test case defines a set of attributes that characterize the testbed, for example, the network path between communicating peers and the diverse traffic sources. o Define the test case: * General description: describes the motivation and the goals of the test case. * Expected behavior: describes the desired rate adaptation behavior. * Define a list of metrics to evaluate the desired behavior: this indicates the minimum set of metrics (e.g., link utilization, media sending rate) that a proposed algorithm needs to measure to validate the expected rate adaptation behavior. It should also indicate the time granularity (e.g., averaged over 10ms, 100ms, or 1s) for measuring certain metrics. Typical measurement interval is 200ms. o Define testbed topology: every test case needs to define an evaluation testbed topology. Figure 1 shows such an evaluation topology. In this evaluation topology, S1..Sn are traffic sources. These sources generate media traffic and use the congestion control algorithm(s) under investigation. R1..Rn are the corresponding receivers. A test case can have one or more such traffic sources (S) and their corresponding receivers (R). The path from the source to destination is denoted as "forward" and the path from a destination to a source is denoted as "backward". The following basic structure of the test case has been described from the perspective of media generating endpoints Sarker, et al. Expires November 24, 2019 [Page 3] Internet-Draft Test Scenarios for RMCAT May 2019 attached on the left-hand side of Figure 1. In this setup, the media flows are transported in forward direction and corresponding feedback/control messages are transported in the backward direction. However, it is also possible to set up the test with media in both forward and backward directions. In that case, unless otherwise specified by the test case, it is expected that the backward path does not introduce any congestion related impairments and has enough capacity to accommodate both media and feedback/control messages. It should be noted that depending on the test cases it is possible to have different path characteristics in either of the directions. +---+ +---+ |S1 |====== \ Forward --> / =======|R1 | +---+ \\ // +---+ \\ // +---+ +-----+ +-----+ +---+ |S2 |=======| A |------------------------------>| B |=======|R2 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ (...) // \\ (...) // <-- Backward \\ +---+ // \\ +---+ |Sn |====== / \ ======|Rn | +---+ +---+ Figure 1: Example of A Testbed Topology In a testbed environment with real equipments, there may exist a significant amount of unwanted traffic on the portions of the network path between the endpoints. Some of this traffic may be generated by other processes on the endpoints themselves (e.g., discovery protocols) or by other endpoints not presently under test. Such unwanted traffic should be removed or avoided to the greatest extent possible. o Define testbed attributes: * Duration: defines the duration of the test in seconds. * Path characteristics: defines the end-to-end transport level path characteristics of the testbed for a particular test case. Two sets of attributes describe the path characteristics, one for the forward path and the other for the backward path. The path characteristics for a particular path direction is applicable to all the Sources "S" sending traffic on that path. If only one attribute is specified, it is used for both path Sarker, et al. Expires November 24, 2019 [Page 4] Internet-Draft Test Scenarios for RMCAT May 2019 directions, however, unless specified the reverse path has no capacity restrictions and no path loss. + Path direction: forward or backward. + Minimum bottleneck-link capacity: defines minimum capacity of the end-to-end path + Reference bottleneck capacity: defines a reference value for the bottleneck capacity for test cases with time-varying bottleneck capacities. All bottleneck capacities will be specified as a ratio with respect to the reference capacity value. + One-way propagation delay: describes the end-to-end latency along the path when network queues are empty, i.e., the time it takes for a packet to go from the sender to the receiver without encountering any queuing delay. + Maximum end-to-end jitter: defines the maximum jitter that can be observed along the path. + Bottleneck queue type: for example, "tail drop" [RFC7567], Flow Queue -CoDel (FQ-CoDel)[RFC8290], or Proportional Integral controller Enhanced (PIE)[RFC8033]. + Bottleneck queue size: defines the size of queue in terms of queuing time when the queue is full (in milliseconds). + Path loss ratio: characterizes the non-congested, additive, losses to be generated on the end-to-end path. This must describe the loss pattern or loss model used to generate the losses. * Application-related: defines the traffic source behavior for implementing the test case + Media traffic Source: defines the characteristics of the media sources. When using more than one media source, the different attributes are enumerated separately for each different media source. - Media type: Video/Voice - Media flow direction: forward, backward or both. - Number of media sources: defines the total number of media sources Sarker, et al. Expires November 24, 2019 [Page 5] Internet-Draft Test Scenarios for RMCAT May 2019 - Media codec: Constant Bit Rate (CBR) or Variable Bit Rate (VBR) - Media source behavior: describes the media encoder behavior. It defines the main parameters that affect the adaptation behavior. This may include but is not limited to: o Adaptability: describes the adaptation options. For example, in the case of video it defines the following ranges of adaptation: bit rate, frame rate, video resolution. Similarly, in the case of voice, it defines the range of bit rate adaptation, the sampling rate variation, and the variation in packetization interval. o Output variation : for a VBR encoder it defines the encoder output variation from the average target rate over a particular measurement interval. For example, on average the encoder output may vary between 5% to 15% above or below the average target bit rate when measured over a 100 ms time window. The time interval over which the variation is specified must be provided. o Responsiveness to a new bit rate request: the lag in time between a new bit rate request from the congestion control algorithm and actual rate changes in encoder output. Depending on the encoder, this value may be specified in absolute time (e.g. 10ms to 1000ms) or other appropriate metric (e.g. next frame interval time). More detailed discussions on expected media source behavior, including those from synthetic video traffic sources, is at [I-D.ietf-rmcat-video-traffic-model]. - Media content: describes the chosen video scenario. For example, video test sequences are available at: [xiph-seq] and [HEVC-seq]. Different video scenarios give different distribution of video frames produced by the video encoder. Hence, it is important to specify the media content used in a particular test. If a synthetic video traffic souce [I-D.ietf-rmcat-video-traffic-model] is used, then the synthetic video traffic source needs to configure according to the characteristics of the media content specified. Sarker, et al. Expires November 24, 2019 [Page 6] Internet-Draft Test Scenarios for RMCAT May 2019 - Media timeline: describes the point when the media source is introduced and removed from the testbed. For example, the media source may start transmitting immediately when the test case begins, or after a few seconds. - Startup behavior: the media starts at a defined bit rate, which may be the minimum, maximum bit rate, or a value in between (in Kbps). + Competing traffic source: describes the characteristics of the competing traffic source, the different types of competing flows are enumerated in [I-D.ietf-rmcat-eval-criteria]. - Traffic direction: forward, backward or both. - Type of sources: defines the types of competing traffic sources. Types of competing traffic flows are listed in [I-D.ietf-rmcat-eval-criteria]. For example, the number of TCP flows connected to a web browser, the mean size and distribution of the content downloaded. - Number of sources: defines the total number of competing sources of each media type per traffic direction. - Congestion control: enumerates the congestion control used by each type of competing traffic. - Traffic timeline: describes when the competing traffic starts and ends in the test case. * Additional attributes: describes attributes essential for implementing a test case which are not included in the above structure. These attributes must be well defined, so that the other implementers of that particular test case are able to implement it easily. Any attribute can have a set of values (enclosed within "[]"). Each member value of such a set must be treated as different value for the same attribute. It is desired to run separate tests for each such attribute value. The test cases described in this document follow the above structure. Sarker, et al. Expires November 24, 2019 [Page 7] Internet-Draft Test Scenarios for RMCAT May 2019 4. Recommended Evaluation Settings This section describes recommended test case settings and could be overwritten by the respective test cases. 4.1. Evaluation metrics To evaluate the performance of the candidate algorithms the implementers must log enough information to visualize the following metrics at a fine enough time granularity: 1. Flow level: A. End-to-end delay for the congestion controlled media flow(s). For example - end-to-end delay observed on IP packet level, video frame level. B. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations. C. Packet losses observed at the receiving endpoint. D. Feedback message overhead. E. Convergence time - time to reach steady state for the congestion controlled media flow(s). Each occurrence of convergence during the test period need to be presented. 2. Transport level: A. Bandwidth utilization. B. Queue length (milliseconds at specified path capacity). 4.2. Path characteristics Each path between a sender and receiver as described in Figure 1 have the following characteristics unless otherwise specified in the test case. o Path direction: forward and backward. o Reference bottleneck capacity: 1Mbps. o One-Way propagation delay: 50ms. Implementers are encouraged to run the experiment with additional propagation delays mentioned in [I-D.ietf-rmcat-eval-criteria] Sarker, et al. Expires November 24, 2019 [Page 8] Internet-Draft Test Scenarios for RMCAT May 2019 o Maximum end-to-end jitter: 30ms. Jitter models are described in [I-D.ietf-rmcat-eval-criteria] o Bottleneck queue type: "tail drop". Implementers are encouraged to run the experiment with other AQM schemes, such as FQ-CoDel and PIE. o Bottleneck queue size: 300ms. o Path loss ratio: 0%. Examples of additional network parameters are discussed in [I-D.ietf-rmcat-eval-criteria]. For test cases involving time-varying bottleneck capacity, all capacity values are specified as a ratio with respect to a reference capacity value, so as to allow flexible scaling of capacity values along with media source rate range. There exist two different mechanisms for inducing path capacity variation: a) by explicitly modifying the value of physical link capacity; or b) by introducing background non-adaptive UDP traffic with time-varying traffic rate. Implementers are encouraged to run the experiments with both mechanisms for test cases specified in Section 5.1, Section 5.2, and Section 5.3. 4.3. Media source Unless otherwise specified, each test case will include one or more media sources as described below. o Media type: Video * Media codec: VBR * Media source behavior: + Adaptability: - Bit rate range: 150 Kbps - 1.5 Mbps. In real-life applications the bit rate range can vary a lot depending on the provided service, for example, the maximum bit rate can be up to 4Mbps. However, for running tests to evaluate the congestion control algorithms it is more important to have a look at how they are reacting to certain amount of bandwidth change. Also it is possible that the media traffic generator used in a particular simulator or testbed is not capable of generating higher bit rate. Hence we have selected a suitable bit rate Sarker, et al. Expires November 24, 2019 [Page 9] Internet-Draft Test Scenarios for RMCAT May 2019 range typical of consumer-grade video conferencing applications in designing the test case. If a different bit rate range is used in the test cases, then the end- to-end path capacity values will also need to be scaled accordingly. - Frame resolution: 144p - 720p (or 1080p). This resolution range is selected based on the bit rate range. If a different bit rate range is used in the test cases then the frame resolution range also need to be selected suitably. - Frame rate: 10fps - 30fps. This frame rate range is selected based on the bit rate range. If a different bit rate range is used in the test cases then the frame rate range also need to be adjusted suitably. + Variation from target bit rate: +/-5%. Unless otherwise specified in the test case(s), bit rate variation should be calculated over one (1) second period of time. + Responsiveness to new bit rate request: 100ms * Media content: The media content should represent a typical video conversational scenario with head and shoulder movement. We recommend to use Foreman video sequence[xiph-seq]. * Media startup behavior: 150Kbps. It should be noted that applications can use smart ways to select an optimal startup bit rate value for a certain network condition. In such cases the candidate proposals may show the effectiveness of such smart approach as an additional information for the evaluation process. o Media type: Audio * Media codec: CBR * Media bit rate: 20Kbps 5. Basic Test Cases 5.1. Variable Available Capacity with a Single Flow In this test case the minimum bottleneck-link capacity between the two endpoints varies over time. This test is designed to measure the responsiveness of the candidate algorithm. This test tries to address the requirements in [I-D.ietf-rmcat-cc-requirements], which Sarker, et al. Expires November 24, 2019 [Page 10] Internet-Draft Test Scenarios for RMCAT May 2019 requires the algorithm to adapt the flow(s) and provide lower end-to- end latency when there exists: o an intermediate bottleneck o change in available capacity (e.g., due to interface change, routing change, abrupt arrival/departure of background non- adaptive traffic). o maximum media bit rate is greater than link capacity. In this case, when the application tries to ramp up to its maximum bit rate, since the link capacity is limited to a value lower, the congestion control scheme is expected to stabilize the sending bit rate close to the available bottleneck capacity. It should be noted that the exact variation in available capacity due to any of the above depends on the underlying technologies. Hence, we describe a set of known factors, which may be extended to devise a more specific test case targeting certain behaviors in a certain network environment. Expected behavior: the candidate algorithm is expected to detect the path capacity constraint, converge to the bottleneck link's capacity and adapt the flow to avoid unwanted media rate oscillation when the sending bit rate is approaching the bottleneck link's capacity. Such oscillations might occur when the media flow(s) attempts to reach its maximum bit rate but overshoots the usage of the available bottleneck capacity then to rectify, it reduces the bit rate and starts to ramp up again. Evaluation metrics : as described in Section 4.1. Testbed topology: One media source S1 is connected to the corresponding R1. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Forward --> +---+ +-----+ +-----+ +---+ |S1 |=======| A |------------------------------>| B |=======|R1 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ <-- Backward Figure 2: Testbed Topology for Limited Link Capacity Testbed attributes: Sarker, et al. Expires November 24, 2019 [Page 11] Internet-Draft Test Scenarios for RMCAT May 2019 o Test duration: 100s o Path characteristics: as described in Section 4.2 o Application-related: * Media Traffic: + Media type: Video - Media direction: forward. - Number of media sources: one (1) - Media timeline: o Start time: 0s. o End time: 99s. + Media type: Audio - Media direction: forward. - Number of media sources: one (1) - Media timeline: o Start time: 0s. o End time: 99s. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: * One-way propagation delay: [ 50 ms, 100 ms]. on the forward path direction * This test uses bottleneck path capacity variation as listed in Table 1 * When using background non-adaptive UDP traffic to induce time- varying bottleneck , the physical path capacity remains at 4Mbps and the UDP traffic source rate changes over time as (4 - Sarker, et al. Expires November 24, 2019 [Page 12] Internet-Draft Test Scenarios for RMCAT May 2019 (Y x r)), where r is the Reference bottleneck capacity in Mbps and Y is the path capacity ratio specified in Table 1 +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Forward | 0s | 1.0 | | Two | Forward | 40s | 2.5 | | Three | Forward | 60s | 0.6 | | Four | Forward | 80s | 1.0 | +--------------------+--------------+-----------+-------------------+ Table 1: Path capacity variation pattern for forward direction 5.2. Variable Available Capacity with Multiple Flows This test case is similar to Section 5.1. However in addition this test will also consider persistent network load due to competing traffic. Expected behavior: the candidate algorithm is expected to detect the variation in available capacity and adapt the media stream(s) accordingly. The flows stabilize around their maximum bit rate as the maximum link capacity is large enough to accommodate the flows. When the available capacity drops, the flows adapt by decreasing their sending bit rate, and when congestion disappears, the flows are again expected to ramp up. Evaluation metrics : as described in Section 4.1. Testbed Topology: Two (2) media sources S1 and S2 are connected to their corresponding destinations R1 and R2. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Sarker, et al. Expires November 24, 2019 [Page 13] Internet-Draft Test Scenarios for RMCAT May 2019 +---+ +---+ |S1 |===== \ / =======|R1 | +---+ \\ Forward --> // +---+ \\ // +-----+ +-----+ | A |------------------------------>| B | | |<------------------------------| | +-----+ +-----+ // \\ // <-- Backward \\ +---+ // \\ +---+ |S2 |====== / \ ======|R2 | +---+ +---+ Figure 3: Testbed Topology for Variable Available Capacity Testbed attributes: Testbed attributes are similar as described in Section 5.1 except the test specific capacity variation setup. Test Specific Information: This test uses path capacity variation as listed in Table 2 with a corresponding end time of 125 seconds. The reference bottleneck capacity is 2Mbps. When using background non- adaptive UDP traffic to induce time-varying bottleneck for congestion controlled media flows, the physical path capacity is 4Mbps and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity in Mbps and Y is the path capacity ratio specified in Table 2. +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Forward | 0s | 2.0 | | Two | Forward | 25s | 1.0 | | Three | Forward | 50s | 1.75 | | Four | Forward | 75s | 0.5 | | Five | Forward | 100s | 1.0 | +--------------------+--------------+-----------+-------------------+ Table 2: Path capacity variation pattern for forward direction 5.3. Congested Feedback Link with Bi-directional Media Flows Real-time interactive media uses RTP hence it is assumed that RTCP, RTP header extension or such would be used by the congestion control algorithm in the backchannel. Due to the asymmetric nature of the Sarker, et al. Expires November 24, 2019 [Page 14] Internet-Draft Test Scenarios for RMCAT May 2019 link between communicating peers it is possible for a participating peer to not receive such feedback information due to an impaired or congested backchannel (even when the forward channel might not be impaired). This test case is designed to observe the candidate congestion control behavior in such an event. Expected behavior: It is expected that the candidate algorithms are able to cope with the lack of feedback information and adapt to minimize the performance degradation of media flows in the forward channel. It should be noted that for this test case: logs are compared with the reference case, i.e, when the backward channel has no impairments. Evaluation metrics : as described in Section 4.1. Testbed topology: One (1) media source S1 is connected to corresponding R1, but both endpoints are additionally receiving and sending data, respectively. The media traffic (S1->R1) is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Likewise media traffic (S2->R2) is transported over the backward path and corresponding feedback/control traffic is transported over the forward path. +---+ +---+ |S1 |===== \ Forward --> / =======|R1 | +---+ \\ // +---+ \\ // +-----+ +-----+ | A |------------------------------>| B | | |<------------------------------| | +-----+ +-----+ // \\ // <-- Backward \\ +---+ // \\ +---+ |R2 |===== / \ ======|S2 | +---+ +---+ Figure 4: Testbed Topology for Congested Feedback Link Testbed attributes: o Test duration: 100s o Path characteristics: Sarker, et al. Expires November 24, 2019 [Page 15] Internet-Draft Test Scenarios for RMCAT May 2019 * Reference bottleneck capacity: 1Mbps. o Application-related: * Media Source: + Media type: Video - Media direction: forward and backward - Number of media sources: two (2) - Media timeline: o Start time: 0s. o End time: 99s. + Media type: Audio - Media direction: forward and backward - Number of media sources: two (2) - Media timeline: o Start time: 0s. o End time: 99s. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: this test uses path capacity variations to create congested feedback link. Table 3 lists the variation patterns applied to the forward path and Table 4 lists the variation patterns applied to the backward path. When using background non-adaptive UDP traffic to induce time-varying bottleneck for congestion controlled media flows, the physical path capacity is 4Mbps for both directions and the UDP traffic source rate changes over time as (4-x)Mbps in each direction, where x is the bottleneck capacity specified in Table 4. Sarker, et al. Expires November 24, 2019 [Page 16] Internet-Draft Test Scenarios for RMCAT May 2019 +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Forward | 0s | 2.0 | | Two | Forward | 20s | 1.0 | | Three | Forward | 40s | 0.5 | | Four | Forward | 60s | 2.0 | +--------------------+--------------+-----------+-------------------+ Table 3: Path capacity variation pattern for forward direction +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Backward | 0s | 2.0 | | Two | Backward | 35s | 0.8 | | Three | Backward | 70s | 2.0 | +--------------------+--------------+-----------+-------------------+ Table 4: Path capacity variation pattern for backward direction 5.4. Competing Media Flows with same Congestion Control Algorithm In this test case, more than one media flow share the bottleneck link and each of them uses the same congestion control algorithm. This is a typical scenario where a real-time interactive application sends more than one media flow to the same destination and these flows are multiplexed over the same port. In such a scenario it is likely that the flows will be routed via the same path and need to share the available bandwidth amongst themselves. For the sake of simplicity it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows individually. While this appears to be a variant of the test case defined in Section 5.2, it focuses on the capacity sharing aspect of the candidate algorithm. The previous test case, on the other hand, measures adaptability, stability, and responsiveness of the candidate algorithm. Expected behavior: It is expected that the competing flows will converge to an optimum bit rate to accommodate all the flows with minimum possible latency and loss. Specifically, the test introduces three media flows at different time instances, when the second flow appears there should still be room to accommodate another flow on the bottleneck link. Lastly, when the third flow appears the bottleneck link should be saturated. Sarker, et al. Expires November 24, 2019 [Page 17] Internet-Draft Test Scenarios for RMCAT May 2019 Evaluation metrics : as described in Section 4.1. Testbed topology: Three media sources S1, S2, S3 are connected to R1, R2, R3 respectively. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. +---+ +---+ |S1 |===== \ Forward --> / =======|R1 | +---+ \\ // +---+ \\ // +---+ +-----+ +-----+ +---+ |S2 |=======| A |------------------------------>| B |=======|R2 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ // <-- Backward \\ +---+ // \\ +---+ |S3 |===== / \ ======|R3 | +---+ +---+ Figure 5: Testbed Topology for Multiple congestion controlled media Flows Testbed attributes: o Test duration: 120s o Path characteristics: * Reference bottleneck capacity: 3.5Mbps * Path capacity ratio: 1.0 o Application-related: * Media Source: + Media type: Video - Media direction: forward. - Number of media sources: three (3) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. + Media type: Audio Sarker, et al. Expires November 24, 2019 [Page 18] Internet-Draft Test Scenarios for RMCAT May 2019 - Media direction: forward. - Number of media sources: three (3) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: Table 5 defines the media timeline for both media type. +---------+------------+------------+----------+ | Flow ID | Media type | Start time | End time | +---------+------------+------------+----------+ | 1 | Video | 0s | 119s | | 2 | Video | 20s | 119s | | 3 | Video | 40s | 119s | | 4 | Audio | 0s | 119s | | 5 | Audio | 20s | 119s | | 6 | Audio | 40s | 119s | +---------+------------+------------+----------+ Table 5: Media Timeline for Video and Audio media sources 5.5. Round Trip Time Fairness In this test case, multiple media flows share the bottleneck link, but the one-way propagation delay for each flow is different. For the sake of simplicity it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows. While this appears to be a variant of test case 5.2, it focuses on the capacity sharing aspect of the candidate algorithm under different RTTs. Expected behavior: It is expected that the competing flows will converge to bit rates to accommodate all the flows with minimum possible latency and loss. The effectiveness of the algorithm depends on how fast and fairly the competing flows converge to their steady states irrespective of the RTT observed. Evaluation metrics : as described in Section 4.1. Testbed Topology: Five (5) media sources S1,S2,..,S5 are connected to their corresponding media sinks R1,R2,..,R5. The media traffic is transported over the forward path and corresponding feedback/control Sarker, et al. Expires November 24, 2019 [Page 19] Internet-Draft Test Scenarios for RMCAT May 2019 traffic is transported over the backward path. The topology is the same as in Section 5.4. Testbed attributes: o Test duration: 300s o Path characteristics: * Reference bottleneck capacity: 4Mbps * Path capacity ratio: 1.0 * One-Way propagation delay for each flow: 10ms for S1-R1, 25ms for S2-R2, 50ms for S3-R3, 100ms for S4-R4, and 150ms S5-R5. o Application-related: * Media Source: + Media type: Video - Media direction: forward - Number of media sources: five (5) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. + Media type: Audio - Media direction: forward. - Number of media sources: five (5) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: Table 6 defines the media timeline for both media type. Sarker, et al. Expires November 24, 2019 [Page 20] Internet-Draft Test Scenarios for RMCAT May 2019 +---------+------------+------------+----------+ | Flow IF | Media type | Start time | End time | +---------+------------+------------+----------+ | 1 | Video | 0s | 299s | | 2 | Video | 10s | 299s | | 3 | Video | 20s | 299s | | 4 | Video | 30s | 299s | | 5 | Video | 40s | 299s | | 6 | Audio | 0 | 299s | | 7 | Audio | 10s | 299s | | 8 | Audio | 20s | 299s | | 9 | Audio | 30s | 299s | | 10 | Audio | 40s | 299s | +---------+------------+------------+----------+ Table 6: Media Timeline for Video and Audio media sources 5.6. Media Flow Competing with a Long TCP Flow In this test case, one or more media flows share the bottleneck link with at least one long lived TCP flow. Long lived TCP flows download data throughout the session and are expected to have infinite amount of data to send and receive. This is a scenario where a multimedia application co-exists with a large file download. The test case measures the adaptivity of the candidate algorithm to competing traffic. It addresses the requirement 3 in [I-D.ietf-rmcat-cc-requirements]. Expected behavior: depending on the convergence observed in test case 5.1 and 5.2, the candidate algorithm may be able to avoid congestion collapse. In the worst case, the media stream will fall to the minimum media bit rate. Evaluation metrics : following metrics in addition to as described in Section 4.1. 1. Flow level: A. TCP throughput. B. Loss for the TCP flow Testbed topology: One (1) media source S1 is connected to the corresponding media sink, R1. In addition, there is a long-live TCP flow sharing the same bottleneck link. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. The TCP traffic goes Sarker, et al. Expires November 24, 2019 [Page 21] Internet-Draft Test Scenarios for RMCAT May 2019 over the forward path from, S_tcp with acknowledgment packets go over the backward path from, R_tcp. +--+ +--+ |S1|===== \ Forward --> / =====|R1| +--+ \\ // +--+ \\ // +-----+ +-----+ | A |---------------------------->| B | | |<----------------------------| | +-----+ +-----+ // <-- Backward \\ +-----+ // \\ +-----+ |S_tcp|=== / \ ===|R_tcp| +-----+ +-----+ Figure 6: Testbed Topology for TCP vs congestion controlled media Flows Testbed attributes: o Test duration: 120s o Path characteristics: * Reference bottleneck capacity: 2Mbps * Path capacity ratio: 1.0 * Bottleneck queue size: [300ms, 1000ms] o Application-related: * Media Source: + Media type: Video - Media direction: forward - Number of media sources: one (1) - Media timeline: o Start time: 5s. o End time: 119s. + Media type: Audio Sarker, et al. Expires November 24, 2019 [Page 22] Internet-Draft Test Scenarios for RMCAT May 2019 - Media direction: forward - Number of media sources: one (1) - Media timeline: o Start time: 5s. o End time: 119s. * Additionally, implementers are encouraged to run the experiment with multiple media sources. * Competing traffic: + Number and Types of sources : one (1) and long-lived TCP + Traffic direction : forward + Congestion control: default TCP congestion control[RFC5681]. Implementers are also encouraged to run the experiment with alternative TCP congestion control algorithm. + Traffic timeline: - Start time: 0s. - End time: 119s. o Test Specific Information: none 5.7. Media Flow Competing with Short TCP Flows In this test case, one or more congestion controlled media flow shares the bottleneck link with multiple short-lived TCP flows. Short-lived TCP flows resemble the on/off pattern observed in the web traffic, wherein clients (for example, browsers) connect to a server and download a resource (typically a web page, few images, text files, etc.) using several TCP connections. This scenario shows the performance of a multimedia application when several browser windows are active. The test case measures the adaptivity of the candidate algorithm to competing web traffic, it addresses the requirements 1.E in [I-D.ietf-rmcat-cc-requirements]. Depending on the number of short TCP flows, the cross-traffic either appears as a short burst flow or resembles a long TCP flow. The intention of this test is to observe the impact of short-term burst on the behavior of the candidate algorithm. Sarker, et al. Expires November 24, 2019 [Page 23] Internet-Draft Test Scenarios for RMCAT May 2019 Expected behavior: The candidate algorithm is expected to avoid flow starvation during the presence of short and bursty competing TCP flows, streaming at least at the minimum media bit rate. After competing TCP flows terminate, the media streams are expected to be robust enough to eventually recover to previous steady state behavior, and at the very least, avoid persistent starvation. Evaluation metrics : following metrics in addition to as described in Section 4.1. 1. Flow level: A. Variation in the sending rate of the TCP flow. B. TCP throughput. Testbed topology: The topology described here is same as the one described in Figure 6. Testbed attributes: o Test duration: 300s o Path characteristics: * Reference bottleneck capacity: 2.0Mbps * Path capacity ratio: 1.0 o Application-related: * Media source: + Media type: Video - Media direction: forward - Number of media sources: two (2) - Media timeline: o Start time: 5s. o End time: 299s. + Media type: Audio - Media direction: forward Sarker, et al. Expires November 24, 2019 [Page 24] Internet-Draft Test Scenarios for RMCAT May 2019 - Number of media sources: two (2) - Media timeline: o Start time: 5s. o End time: 299s. * Competing traffic: + Number and Types of sources : ten (10), short-lived TCP flows. + Traffic direction : forward + Congestion algorithm: default TCP Congestion control [RFC5681]. Implementers are also encouraged to run the experiment with alternative TCP congestion control algorithm. + Traffic timeline: each short TCP flow is modeled as a sequence of file downloads interleaved with idle periods. Not all short TCP flows start at the same time, 2 of them start in the ON state while rest of the 8 flows start in an OFF state. For description of short TCP flow model see test specific information below. o Test Specific Information: * Short-TCP traffic model: The short TCP model to be used in this test is described in [I-D.ietf-rmcat-eval-criteria]. 5.8. Media Pause and Resume In this test case, more than one real-time interactive media flows share the link bandwidth and all flows reach to a steady state by utilizing the link capacity in an optimum way. At this stage one of the media flows is paused for a moment. This event will result in more available bandwidth for the rest of the flows as they are on a shared link. When the paused media flow resumes it would no longer have the same bandwidth share on the link. It has to make its way through the other existing flows in the link to achieve a fair share of the link capacity. This test case is important specially for real-time interactive media which consists of more than one media flows and can pause/resume media flows at any point of time during the session. This test case directly addresses the requirement number 5 in [I-D.ietf-rmcat-cc-requirements]. One can think it as a variation of test case defined in Section 5.4. However, it is Sarker, et al. Expires November 24, 2019 [Page 25] Internet-Draft Test Scenarios for RMCAT May 2019 different as the candidate algorithms can use different strategies to increase its efficiency, for example in terms of fairness, convergence time, reduce oscillation etc, by capitalizing the fact that they have previous information of the link. Expected behavior: During the period where the third stream is paused, the two remaining flows are expected to increase their rates and reach the maximum media bit rate. When the third stream resumes, all three flows are expected to converge to the same original fair share of rates prior to the media pause/resume event. Evaluation metrics : following metrics in addition to as described in Section 4.1. 1. Flow level: A. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations. Testbed Topology: Same as test case defined in Section 5.4 Testbed attributes: The general description of the testbed parameters are same as Section 5.4 with changes in the test specific setup as below- o Other test specific setup: * Media flow timeline: + Flow ID: one (1) + Start time: 0s + Flow duration: 119s + Pause time: not required + Resume time: not required * Media flow timeline: + Flow ID: two (2) + Start time: 0s + Flow duration: 119s + Pause time: at 40s Sarker, et al. Expires November 24, 2019 [Page 26] Internet-Draft Test Scenarios for RMCAT May 2019 + Resume time: at 60s * Media flow timeline: + Flow ID: three (3) + Start time: 0s + Flow duration:119s + Pause time: not required + Resume time: not required 6. Other potential test cases It has been noticed that there are other interesting test cases besides the basic test cases listed above. In many aspects, these additional test cases can help further evaluation of the candidate algorithm. They are listed as below. 6.1. Media Flows with Priority In this test case media flows will have different priority levels. This will be an extension of Section 5.4 where the same test will be run with different priority levels imposed on each of the media flows. For example, the first flow (S1) is assigned a priority of 2 whereas the remaining two flows (S2 and S3) are assigned a priority of 1. The candidate algorithm must reflect the relative priorities assigned to each media flow. In this case, the first flow (S1) must arrive at a steady-state rate approximately twice of that of the other two flows (S2 and S3). The candidate algorithm can use a coupled congestion control mechanism [I-D.ietf-rmcat-coupled-cc] or use a weighted priority scheduler for the bandwidth distribution according to the respective media flow priority or use. 6.2. Explicit Congestion Notification Usage This test case requires to run all the basic test cases with the availability of Explicit Congestion Notification (ECN) [RFC6679] feature enabled. The goal of this test is to exhibit that the candidate algorithms do not fail when ECN signals are available. With ECN signals enabled the algorithms are expected to perform better than their delay-based variants. Sarker, et al. Expires November 24, 2019 [Page 27] Internet-Draft Test Scenarios for RMCAT May 2019 6.3. Multiple Bottlenecks In this test case one congestion controlled media flow, S1->R1, traverses a path with multiple bottlenecks. As illustrated in Figure 7, the first flow (S1->R1) competes with the second congestion controlled media flow (S2->R2) over the link between A and B which is close to the sender side; again, that flow (S1->R1) competes with the third congestion controlled media flow (S3->R3) over the link between C and D which is close to the receiver side. The goal of this test is to ensure that the candidate algorithms work properly in the presence of multiple bottleneck links on the end to end path. Expected behavior: The candidate algorithm is expected to achieve full utilization at both bottleneck links without starving any of the three congestion controlled media flows and ensuring fair share of the available bandwidth at each bottlenecks. Forward ----> +---+ +---+ +---+ +---+ |S2 | |R2 | |S3 | |R3 | +---+ +---+ +---+ +---+ | | | | | | | | +---+ +-----+ +-----+ +-----+ +-----+ +---+ |S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 | +---+ | |<------| |<-----| |<----| | +---+ +-----+ +-----+ +-----+ +-----+ 1st 2nd Bottleneck (A->B) Bottleneck (C->D) <------ Backward Figure 7: Testbed Topology for Multiple Bottlenecks Testbed topology: Three media sources S1, S2, and S3 are connected to respective destinations R1, R2, and R3. For all three flows the media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Testbed attributes: Sarker, et al. Expires November 24, 2019 [Page 28] Internet-Draft Test Scenarios for RMCAT May 2019 o Test duration: 300s o Path characteristics: * Reference bottleneck capacity: 2Mbps. * Path capacity ratio between A and B: 1.0 * Path capacity ratio between B and C: 4.0. * Path capacity ratio between C and D: 0.75. * One-Way propagation delay: 1. Between S1 and R1: 100ms 2. Between S2 and R2: 40ms 3. Between S3 and R3: 40ms o Application-related: * Media Source: + Media type: Video - Media direction: Forward - Number of media sources: Three (3) - Media timeline: o Start time: 0s. o End time: 299s. + Media type: Audio - Media direction: Forward - Number of media sources: Three (3) - Media timeline: o Start time: 0s. o End time: 299s. Sarker, et al. Expires November 24, 2019 [Page 29] Internet-Draft Test Scenarios for RMCAT May 2019 * Competing traffic: + Number of sources : Zero (0) 7. Wireless Access Links Additional wireless network (both cellular network and WiFi network) specific test cases are defined in [I-D.ietf-rmcat-wireless-tests]. 8. Security Considerations The security considerations in [I-D.ietf-rmcat-eval-criteria] and the relevant congestion control algorithms apply. The principles for congestion control are described in [RFC2914], and in particular any new method must implement safeguards to avoid congestion collapse of the Internet. The evaluation of the test cases are intended to be run in a controlled lab environment. Hence, the applications, simulators and network nodes ought to be well-behaved and should not impact the desired results. Moreover, proper measures must be taken to avoid leaking non-responsive traffic from unproven congestion avoidance techniques onto the open Internet. 9. IANA Considerations There are no IANA impacts in this memo. 10. Acknowledgements Much of this document is derived from previous work on congestion control at the IETF. The content and concepts within this document are a product of the discussion carried out in the Design Team. 11. References 11.1. Normative References [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. Sarker, et al. Expires November 24, 2019 [Page 30] Internet-Draft Test Scenarios for RMCAT May 2019 [I-D.ietf-rmcat-eval-criteria] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion Control for Interactive Real-time Media", draft-ietf- rmcat-eval-criteria-08 (work in progress), November 2018. [I-D.ietf-rmcat-video-traffic-model] Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models for RTP Congestion Control Evaluations", draft-ietf-rmcat- video-traffic-model-07 (work in progress), February 2019. [I-D.ietf-rmcat-wireless-tests] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real- Time Media over Wireless Networks", draft-ietf-rmcat- wireless-tests-06 (work in progress), December 2018. [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, . [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, . Sarker, et al. Expires November 24, 2019 [Page 31] Internet-Draft Test Scenarios for RMCAT May 2019 [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, . 11.2. Informative References [HEVC-seq] HEVC, "Test Sequences", http://www.netlab.tkk.fi/~varun/test_sequences/ . [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-08 (work in progress), January 2019. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, . [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm", RFC 8290, DOI 10.17487/RFC8290, January 2018, . [xiph-seq] Xiph.org, "Video Test Media", http://media.xiph.org/video/derf/ . Authors' Addresses Sarker, et al. Expires November 24, 2019 [Page 32] Internet-Draft Test Scenarios for RMCAT May 2019 Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 Stockholm, SE 164 83 Sweden Phone: +46 10 717 37 43 Email: zaheduzzaman.sarker@ericsson.com Varun Singh Nemu Dialogue Systems Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland Email: varun.singh@iki.fi URI: http://www.callstats.io/ Xiaoqing Zhu Cisco Systems 12515 Research Blvd Austing, TX 78759 USA Email: xiaoqzhu@cisco.com Michael A. Ramalho Cisco Systems, Inc. 6310 Watercrest Way Unit 203 Lakewood Ranch, FL 34202-5211 USA Phone: +1 919 476 2038 Email: mramalho@cisco.com Sarker, et al. Expires November 24, 2019 [Page 33] ./draft-ietf-mmusic-trickle-ice-sip-18.txt0000644000764400076440000030670513313411660017651 0ustar iustyiusty Network Working Group E. Ivov Internet-Draft Jitsi Intended status: Standards Track T. Stach Expires: December 24, 2018 Unaffiliated E. Marocco Telecom Italia C. Holmberg Ericsson June 22, 2018 A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) draft-ietf-mmusic-trickle-ice-sip-18 Abstract The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new SDP 'end-of- candidates' attribute and a new SIP Option Tag 'trickle-ice' are defined. 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 https://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." Ivov, et al. Expires December 24, 2018 [Page 1] Internet-Draft Trickle ICE for SIP June 2018 This Internet-Draft will expire on December 24, 2018. Copyright Notice Copyright (c) 2018 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 (https://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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7 4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 9 4.1.3. Sending the Initial Answer . . . . . . . . . . . . . 9 4.1.4. Receiving the Initial Answer . . . . . . . . . . . . 10 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery . . . . . . . . . . . . . . . . 11 4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery . . . . . . . . . . . . . . . . 12 4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 16 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 20 5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 20 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU) . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 21 6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 23 7. Considerations for Media Multiplexing . . . . . . . . . . . . 26 8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 28 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 29 Ivov, et al. Expires December 24, 2018 [Page 2] Internet-Draft Trickle ICE for SIP June 2018 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 29 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 29 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32 10.2. Overall Description . . . . . . . . . . . . . . . . . . 33 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 34 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 34 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 34 10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34 10.10. Info Package Security Considerations . . . . . . . . . . 35 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 16.1. Normative References . . . . . . . . . . . . . . . . . . 43 16.2. Informative References . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction The Interactive Connectivity Establishment (ICE) protocol [I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address Translator (NAT) traversal that consists of three main phases. During the first phase an agent gathers a set of candidate transport addresses (source IP address, port and transport protocol). This is followed by a second phase where these candidates are sent to a remote agent within the Session Description Protocol (SDP) body of a SIP message. At the remote agent the gathering procedure is repeated and candidates are sent to the first agent. Once the candidate information is available, a third phase starts in parallel where connectivity between all candidates in both sets is checked (connectivity checks). Once these phases have been completed, and only then, both agents can begin communication. According to [I-D.ietf-ice-rfc5245bis] the three phases above happen consecutively, in a blocking way, which can introduce undesirable setup delay during session establishment. The Trickle ICE extension Ivov, et al. Expires December 24, 2018 [Page 3] Internet-Draft Trickle ICE for SIP June 2018 [I-D.ietf-ice-trickle] defines generic semantics required for these ICE phases to happen in a parallel, non-blocking way and hence speed up session establishment. This specification defines a usage of Trickle ICE with the Session Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates are to be exchanged incrementally using SIP INFO requests [RFC6086] and how the Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) depending on their expectations for support of Trickle ICE by a remote agent. This document defines a new Info Package as specified in [RFC6086] for use with Trickle ICE together with the corresponding media type, SDP attribute and SIP option tag. 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 [RFC2119], [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification makes use of terminology defined by the protocol for Interactive Connectivity Establishment in [I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension [I-D.ietf-ice-trickle]. It is assumed that the reader is familiar with the terminology from both documents. [I-D.ietf-ice-rfc5245bis] also describes how ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol [RFC5389] and its extension Traversal Using Relay NAT (TURN) [RFC5766]. 3. Protocol Overview When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE candidates are exchanged solely via SDP Offer/Answer as per [RFC3264]. This specification defines an additional mechanism where candidates can be exchanged using SIP INFO messages and a newly defined Info Package [RFC6086]. This allows ICE candidates also to be sent in parallel to an ongoing Offer/Answer negotiation and/or after the completion of the Offer/Answer negotiation. Typically, in cases where Trickle ICE is fully supported, the Offerer sends an INVITE request containing a subset of candidates. Once an early dialog is established the Offerer can continue sending candidates in INFO requests within that dialog. Ivov, et al. Expires December 24, 2018 [Page 4] Internet-Draft Trickle ICE for SIP June 2018 Similarly, an Answerer can send ICE candidates using INFO requests within the dialog established by its 18x provisional response. Figure 1 shows such a sample exchange: STUN/Turn STUN/TURN Servers Alice Bob Servers | | | | | STUN Bi.Req. | INVITE (Offer) | | |<--------------|------------------------>| | | | 183 (Answer) | TURN Alloc Req | | STUN Bi.Resp. |<------------------------|--------------->| |-------------->| INFO/OK (SRFLX Cand.) | | | |------------------------>| TURN Alloc Resp| | | INFO/OK (Relay Cand.) |<---------------| | |<------------------------| | | | | | | | More Cands & ConnChecks| | | |<=======================>| | | | | | | | 200 OK | | | |<------------------------| | | | ACK | | | |------------------------>| | | | | | | |<===== MEDIA FLOWS =====>| | | | | | Note: SRFLX denotes server-reflexive candidates Figure 1: Sample Trickle ICE scenario with SIP 3.1. Discovery issues In order to benefit from Trickle ICE's full potential and reduce session establishment latency to a minimum, Trickle ICE agents need to generate SDP Offers and Answers that contain incomplete, potentially empty sets of candidates. Such Offers and Answers can only be handled meaningfully by agents that actually support incremental candidate provisioning, which implies the need to confirm such support before using it. Contrary to other protocols, where "in advance" capability discovery is widely implemented, the mechanisms that allow this for SIP (i.e., a combination of UA Capabilities [RFC3840] and Globally Routable User Agent URIs (GRUU) [RFC5627]) have only seen low levels of adoption. This presents an issue for Trickle ICE implementations as SIP UAs do not have an obvious means of verifying that their peer will support incremental candidate provisioning. Ivov, et al. Expires December 24, 2018 [Page 5] Internet-Draft Trickle ICE for SIP June 2018 The Half Trickle mode of operation defined in the Trickle ICE specification [I-D.ietf-ice-trickle] provides one way around this, by requiring the first Offer to contain a complete set of local ICE candidates and only using incremental provisioning of remote candidates for the rest of the session. While using Half Trickle does provide a working solution it also comes at the price of increased latency. Section 5 therefore makes several alternative suggestions that enable SIP UAs to engage in Full Trickle right from their first Offer: Section 5.1 discusses the use of on-line provisioning as a means of allowing use of Trickle ICE for all endpoints in controlled environments. Section 5.2 describes anticipatory discovery for implementations that actually do support GRUU and UA Capabilities and Section 5.3 discusses the implementation and use of Half Trickle by SIP UAs where none of the above are an option. 3.2. Relationship with the Offer/Answer Model From the perspective of SIP middle boxes and proxies the Offer/Answer exchange for Trickle ICE looks partly similar to the Offer/Answer exchange for regular ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. However, in order to have the full picture of the candidate exchange, the newly introduced INFO messages need to be considered as well. Ivov, et al. Expires December 24, 2018 [Page 6] Internet-Draft Trickle ICE for SIP June 2018 +-------------------------------+ +-------------------------------+ | Alice +--------------+ | | +--------------+ Bob | | | Offer/Answer | | | | Offer/Answer | | | +--------+ | Module | | | | Module | +--------+ | | | ICE | +--------------+ | | +--------------+ | ICE | | | | Module | | | | | | Module | | | +--------+ | | | | +--------+ | +-------------------------------+ +-------------------------------+ | | | | | | INVITE (Offer) | | | |--------------------->| | | | 183 (Answer) | | | |<---------------------| | | | | | | | | SIP INFO (more candidates) | |----------------------------------------------------->| | SIP INFO (more candidates) | |<-----------------------------------------------------| | | | STUN Binding Requests/Responses | |----------------------------------------------------->| | STUN Binding Requests/Responses | |<-----------------------------------------------------| | | Figure 2: Distinguishing between Trickle ICE and traditional signaling. From an architectural viewpoint, as displayed in Figure 2, exchanging candidates through SIP INFO requests could be represented as signaling between ICE modules and not between Offer/Answer modules of SIP User Agents. Then, such INFO requests do not impact the state of the Offer/Answer transaction other than providing additional candidates. Consequently, INFO requests are not considered Offers or Answers. Nevertheless, candidates that have been exchanged using INFO requests SHALL be included in subsequent Offers or Answers. The version number in the "o=" line of that subsequent Offer needs to be incremented by 1 per the rules in [RFC3264]. 4. Incremental Signaling of ICE candidates Trickle ICE Agents will exchange ICE descriptions compliant to [I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO request bodies. This requires the following SIP-specific extensions: Ivov, et al. Expires December 24, 2018 [Page 7] Internet-Draft Trickle ICE for SIP June 2018 1. Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag 'trickle-ice' in a SIP Supported: header field within all SIP INVITE requests and responses. 2. Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option 'trickle' within all SDP Offers and Answers in accordance to [I-D.ietf-ice-trickle]. 3. Trickle ICE Agents MAY include any number of ICE candidates, i.e. from zero to the complete set of candidates, in their initial Offer or Answer. If the complete candidate set is included already in the initial Offer, this is called Half-Trickle. 4. Trickle ICE Agents MAY exchange additional ICE candidates using INFO requests within an existing INVITE dialog usage (including an early dialog) as specified in [RFC6086]. The INFO requests carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be prepared to receive INFO requests within that same dialog usage, containing additional candidates and/or an indication that trickling of such candidates has ended. 5. Trickle ICE Agents MAY exchange additional ICE candidates before the Answerer has sent the Answer provided that an invite dialog usage is established at both Trickle ICE Agents. Note that in case of forking multiple early dialogs may exist. The following sections provide further details on how Trickle ICE Agents perform the initial Offer/Answer exchange (Section 4.1), perform subsequent Offer/Answer exchanges (Section 4.2) and establish the INVITE dialog usage (Section 4.3) such that they can incrementally trickle candidates (Section 4.4). 4.1. Initial Offer/Answer Exchange 4.1.1. Sending the Initial Offer If the Offerer includes candidates in its initial Offer, it MUST encode these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp]. If the Offerer wants to send its initial Offer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value '9' for these media descriptions. If the Offerer does not want to include the host IP address in the corresponding c-line, e.g. due to privacy reasons, it SHOULD include a default address in the c-line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent ::. Ivov, et al. Expires December 24, 2018 [Page 8] Internet-Draft Trickle ICE for SIP June 2018 In this case, the Offerer obviously cannot know the RTCP transport address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. This avoids potential ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. If the Offerer wants to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in the initial Offer. In any case, the Offerer MUST include the attribute "a=ice- options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST include in each "m="-line a "a=mid:" attribute in accordance to [RFC5888]. The "a=mid:" attribute identifies the "m="-line to which a candidate belongs and helps in case of multiple "m="-lines, when candidates gathering could occur in a order different from the order of the "m="-lines. 4.1.2. Receiving the Initial Offer If the initial Offer included candidates, the Answerer uses these candidates to start ICE processing as specified in [I-D.ietf-ice-trickle]. If the initial Offer included the attribute a=ice-options:trickle, the Answerer MUST be prepared for receiving trickled candidates later on. In case of a "m/c=" line with default values none of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]). 4.1.3. Sending the Initial Answer If the Answerer includes candidates in its initial Answer, it MUST encode these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp]. If the Answerer wants to send its initial Answer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value '9' for these media descriptions. If the Answerer does not want to include the host IP address in the corresponding c-line, e.g. due to privacy reasons, it SHOULD include a default address in the c-line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent ::. Ivov, et al. Expires December 24, 2018 [Page 9] Internet-Draft Trickle ICE for SIP June 2018 In this case, the Answerer obviously cannot know the RTCP transport address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. This avoids potential ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will include the "a=rtcp-mux" attribute in the initial Answer. In any case, the Answerer MUST include the attribute "a=ice- options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST include in each "m="-line a "a=mid:" attribute in accordance to [RFC5888]. 4.1.4. Receiving the Initial Answer If the initial Answer included candidates, the Offerer uses these candidates to start ICE processing as specified in [I-D.ietf-ice-trickle]. In case of a "m/c=" line with default values none of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]). 4.2. Subsequent Offer/Answer Exchanges Subsequent Offer/Answer exchanges are handled as for regular ICE (see section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]). If an Offer or Answer needs to be sent while the ICE agents are in the middle of trickling section 3.2 of [I-D.ietf-mmusic-ice-sip-sdp]) applies. This means that an ICE agent includes candidate attributes for all local candidates it had trickled previously for a specific media stream. [RFC EDITOR NOTE: The section 3.2 in above sentence is correct for version 20 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] 4.3. Establishing the Dialog In order to be able to start trickling, the following two conditions need to be satisfied at the SIP UAs: o Trickle ICE support at the peer agent MUST be confirmed. o A dialog MUST have been created between the peers. Ivov, et al. Expires December 24, 2018 [Page 10] Internet-Draft Trickle ICE for SIP June 2018 Section 5 discusses in detail the various options for satisfying the first of the above conditions. Regardless of those mechanisms, however, agents are certain to have a clear understanding of whether their peers support trickle ICE once an Offer and an Answer have been exchanged, which also allows for ICE processing to commence (see Figure 3). 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (Answer) | |<------------------------| | PRACK/OK | |------------------------>| | | +----------------------------------------+ |Alice and Bob know that both can trickle| |and know that the dialog is in the early| |state. Send INFO! | +----------------------------------------+ | | | INFO/OK (+SRFLX Cand.) | |------------------------>| | INFO/OK (+SRFLX Cand.) | |<------------------------| | | Note: SRFLX denotes server-reflexive candidates Figure 3: SIP Offerer can freely trickle as soon as it receives an Answer. As shown in Figure 3 satisfying both conditions is relatively trivial for ICE Agents that have sent an Offer in an INVITE and that have received an Answer in a reliable provisional response. It is guaranteed to have confirmed support for Trickle ICE at the Answerer (or lack thereof) and to have fully initialized the SIP dialog at both ends. Offerers and Answerers (after receipt of the PRACK request) in the above situation can therefore freely commence trickling within the newly established dialog. Ivov, et al. Expires December 24, 2018 [Page 11] Internet-Draft Trickle ICE for SIP June 2018 4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery The situation is a bit more delicate for agents that have received an Offer in an INVITE request and have sent an Answer in an unreliable provisional response because, once the response has been sent, the Answerer does not know when or if it has been received (Figure 4). Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (Answer) | |<------------------------| | | | +----------------------+ | |Bob: I don't know if | | |Alice got my 183 or if| | |her dialog is already | | |in the early state. | | | Can I send INFO??? | | +----------------------+ | | Figure 4: A SIP UA that sent an Answer in an unreliable provisional response does not know if it was received and if the dialog at the side of the Offerer has entered the early state In order to clear this ambiguity as soon as possible, the Answerer needs to retransmit the provisional response with the exponential back-off timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request carrying a 'trickle-ice' Info Package body, on receipt of any other in-dialog request from the offerer or on transmission of the Answer in a 2xx response. The offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. Using the INFO request for dialog confirmation is similar to the procedure described in section 6.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is replaced by the INFO request. [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] The Offerer MUST send a Trickle ICE INFO request as soon as it receives an SDP Answer in an unreliable provisional response. This INFO request MUST repeat the candidates that were already provided in Ivov, et al. Expires December 24, 2018 [Page 12] Internet-Draft Trickle ICE for SIP June 2018 the Offer (as would be the case when Half Trickle is performed or when new candidates have not been learned since then). The first case could happen when Half Trickle is used and all candidate are already in the initial offer. The second case could happen when Full Trickle is used and the offerer is currently gathering additional candidates, but did not yet get them. Also, if the initial Offer did not contain any candidates, depending on how the Offerer gathers its candidates and how long it takes to do so, this INFO could still contain no candidates. When Full Trickle is used and if newly learned candidates are available, the Offerer SHOULD also deliver these candidates in said INFO request, unless it wants to hold back some candidates in reserve, e.g. in case that these candidates are expensive to use and would only be trickled if all other candidates failed. The Offerer SHOULD include an end-of-candidates attribute in case candidate discovery has ended in the mean time and no further candidates are to be trickled. As soon as an Answerer has received such an INFO request, the Answerer has an indication that a dialog is established at both ends and can begin trickling (Figure 5). Note: The +SRFLX in Figure 5 indicates that additionally newly learned server-reflexive candidates are included. Ivov, et al. Expires December 24, 2018 [Page 13] Internet-Draft Trickle ICE for SIP June 2018 Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (Answer) | |<------------------------| | INFO/OK (+SRFLX Cand.) | |------------------------>| | | | +----------------------+ | |Bob: Now I know Alice| | | is ready. Send INFO! | | +----------------------+ | INFO/OK (+SRFLX Cand.) | |<------------------------| | | | 200/ACK (Answer) | |<------------------------| Note: SRFLX denotes server-reflexive candidates Figure 5: A SIP UA that received an INFO request after sending an unreliable provisional response knows that the dialog at the side of the receiver has entered the early state When sending the Answer in the 200 OK response to the INVITE request, the Answerer needs to repeat exactly the same Answer that was previously sent in the unreliable provisional response in order to fulfill the corresponding requirements in [RFC3264]. Thus, the Offerer needs to be prepared for receiving a different number of candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response. 4.3.3. Initiating Trickle ICE without an SDP Answer The ability to convey arbitrary candidates in INFO message bodies allows ICE Agents to initiate trickling without actually sending an Answer. Trickle ICE Agents can therefore respond to an INVITE request with provisional responses without an SDP Answer [RFC3261]. Such provisional responses serve for establishing an early dialog. Agents that choose to establish the dialog in this way, MUST retransmit these responses with the exponential back-off timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request carrying a 'trickle-ice' Info Package body, on receipt any in-dialog request from the offerer or on transmission of Ivov, et al. Expires December 24, 2018 [Page 14] Internet-Draft Trickle ICE for SIP June 2018 the Answer in a 2xx response. The offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. This is again similar to the procedure described in section 6.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet provided. [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] Note: The +SRFLX in Figure 6 indicates that additionally newly learned server-reflexive candidates are included. Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (-) | |<------------------------| | INFO/OK (SRFLX Cand.) | |------------------------>| | | | +----------------------+ | |Bob: Now I know again| | | that Alice is ready. | | | Send INFO! | | +----------------------+ | INFO/OK (SRFLX Cand.) | |<------------------------| | 183 (Answer) opt. | |<------------------------| | INFO/OK (SRFLX Cand.) | |<------------------------| | 200/ACK (Answer) | |<------------------------| Note: SRFLX denotes server-reflexive candidates Figure 6: A SIP UA sends an unreliable provisional response without an Answer for establishing an early dialog When sending the Answer, the agent MUST repeat all currently known and used candidates, if any, and MAY include all newly gathered candidates since the last INFO request was sent. However, if that Answer was already sent in a unreliable provisional response, the Answerers MUST repeat exactly the same Answer in the 200 OK response Ivov, et al. Expires December 24, 2018 [Page 15] Internet-Draft Trickle ICE for SIP June 2018 to the INVITE request in order to fulfill the corresponding requirements in [RFC3264]. In case that trickling continued, an Offerer needs to be prepared for receiving fewer candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response. 4.4. Delivering Candidates in INFO Requests Whenever new ICE candidates become available for sending, agents encode them in "a=candidate:" attributes as described by [I-D.ietf-mmusic-ice-sip-sdp]. For example: a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host The use of SIP INFO requests happens within the context of the Info Package as defined Section 10. The Media Type [RFC6838] for their payload MUST be set to 'application/trickle-ice-sdpfrag' as defined in Section 9. The Info request body adheres to the grammar as specified in Section 9.2. Since neither the "a=candidate:" nor the "a=end-of-candidates" attributes contain information that would allow correlating them to a specific "m=" line, this is handled through the use of pseudo "m=" lines. Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in [RFC4566] and are linked to the corresponding "m=" line in the SDP Offer or Answer via the identification tag in a "a=mid:" attribute [RFC5888]. A pseudo "m=" line does not provide semantics other than indicating to which "m=" line a candidate belongs. Consequently, the receiving agent MUST ignore any remaining content of the pseudo "m=" line, which is not defined in this document. This guarantees that the 'application/trickle-ice-sdpfrag' bodies do not interfere with the Offer/Answer procedures as specified in [RFC3264]. When sending the INFO request, the agent MAY, if already known to the agent, include the same content into the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer. However, since Trickle-ICE might be decoupled from the Offer/Answer negotiation this content might be unknown to the agent. In this case, the agent MUST include the following default values. o The media field is set to 'audio'. o The port value is set to '9'. Ivov, et al. Expires December 24, 2018 [Page 16] Internet-Draft Trickle ICE for SIP June 2018 o The proto value is set to 'RTP/AVP'. o The fmt field MUST appear only once and is set to '0' Agents MUST include a pseudo "m=" line and an identification tag in a "a=mid:" attribute for every "m=" line whose candidate list they intend to update. Such "a=mid:" attributes MUST immediately precede the list of candidates for that specific "m=" line. All "a=candidate:" or "a=end-of-candidates" attributes following an "a=mid:" attribute, up until (and excluding) the next occurrence of a pseudo "m=" line, pertain to the "m=" line identified by that identification tag. Note, that there is no requirement that the Info request body contains as many pseudo m= lines as the Offer/Answer contains m=lines, nor that the pseudo m= lines be in the same order as the m=lines that they pertain to. The correspondence can be made via the "a=mid:" attributes since candidates are grouped in sections headed by "pseudo" m=lines. These sections contain "a=mid:" attribute values which point back to the true m=line. An "a=end-of-candidates" attribute, preceding the first pseudo "m=" line, indicates the end of all trickling from that agent, as opposed to end of trickling for a specific "m=" line, which would be indicated by a media level "a=end-of-candidates" attribute. Refer to Figure 7 for an example of the INFO request content. The use of pseudo "m=" lines allows for a structure similar to the one in SDP Offers and Answers where separate media-level and session- level sections can be distinguished. In the current case, lines preceding the first pseudo "m=" line are considered to be session- level. Lines appearing in between or after pseudo "m=" lines will be interpreted as media-level. Note that while this specification uses the "a=mid:" attribute from [RFC5888], it does not define any grouping semantics. All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" attributes that allow mapping them to a specific ICE generation. An agent MUST discard any received INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not match those of the current ICE Negotiation Session. The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also Ivov, et al. Expires December 24, 2018 [Page 17] Internet-Draft Trickle ICE for SIP June 2018 appear at the beginning of all INFO request payloads, i.e. preceding the first pseudo "m=" line. If they were originally exchanged as media level attributes, potentially overriding session-level values, then they will also be included in INFO request payloads following the corresponding pseudo "m=" lines. Note that [I-D.ietf-ice-trickle] requires that when candidates are trickled, each candidate must be delivered to the receiving Trickle ICE implementation not more than once and in the same order as it was conveyed. If the signaling protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. This requirement is fulfilled as follows. Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer it MUST include all currently known and used local candidates in every INFO request. I.e. the agent MUST repeat in the INFO request body all candidates that were previously sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in the same order as they were sent before. In other words, the sequence of a previously sent list of candidates MUST NOT change in subsequent INFO requests and newly gathered candidates MUST be added at the end of that list. Although repeating all candidates creates some overhead, it also allows easier handling of problems that could arise from unreliable transports, like e.g. loss of messages and reordering, which can be detected through the CSeq: header field in the INFO request. In addition, an ICE agent needs to adhere to section 17 of [I-D.ietf-ice-trickle] on preserving candidate order while trickling. When receiving INFO requests carrying any candidates, agents MUST therefore first identify and discard the attribute lines containing candidates they have already received in previous INFO requests or in the Offer/Answer exchange preceding them. Such candidates are considered to be equal if their IP address port, transport and component ID are the same. After identifying and discarding the known candidates, the agents MUST forward the actually new candidates to the ICE Agents in the same order as they were received in the INFO request body. The ICE Agents will then process the new candidates according to the rules described in [I-D.ietf-ice-trickle]. Receiving an "a=end-of-candidates" attribute in an INFO request body - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - is an indication from the peer agent that it will not send any further candidates. When included at session level, i.e. before any pseudo "m=" line, this indication applies to Ivov, et al. Expires December 24, 2018 [Page 18] Internet-Draft Trickle ICE for SIP June 2018 the whole session; when included at media level the indication applies only to the corresponding "m=" line. Handling of such end- of-candidates indications is defined in [I-D.ietf-ice-trickle]. The example in Figure 7 shows the content of a candidate delivering INFO request. In the example the "a=end-of-candidates" attributes indicate that the candidate gathering is finished and that no further INFO requests follow. INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 862 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:1 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx raddr 192.0.2.1 rport 8998 a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx raddr 192.0.2.1 rport 8998 a=end-of-candidates m=audio 9 RTP/AVP 0 a=mid:2 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx raddr 192.0.2.1 rport 9998 a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx raddr 192.0.2.1 rport 9998 a=end-of-candidates Note: In a real INFO request there will be no line breaks in the a=candidate: attributes Figure 7: An Example for the Content of an INFO Request Ivov, et al. Expires December 24, 2018 [Page 19] Internet-Draft Trickle ICE for SIP June 2018 5. Initial Discovery of Trickle ICE Support SIP User Agents (UAs) that support and intend to use trickle ICE are required by [I-D.ietf-ice-trickle] to indicate that in their Offers and Answers using the attribute "a=ice-options:trickle" and MUST include the SIP option-tag "trickle-ice" in a SIP Supported: or Require: header field. This makes discovery fairly straightforward for Answerers or for cases where Offers need to be generated within existing dialogs (i.e., when sending UPDATE or re-INVITE requests). In both scenarios prior SDP bodies will have provided the necessary information. Obviously, such information is not available at the time a first Offer is being constructed and it is therefore impossible for ICE Agents to determine support for incremental provisioning that way. The following options are suggested as ways of addressing this issue. 5.1. Provisioning Support for Trickle ICE In certain situations it may be possible for integrators deploying Trickle ICE to know in advance that some or all endpoints reachable from within the deployment will support Trickle ICE. This is the case, for example, if Session Border Controllers (SBC) with support for this specification are used to connect to UAs that do not support Trickle ICE. While the exact mechanism for allowing such provisioning is out of scope here, this specification encourages trickle ICE implementations to allow the option in the way they find most appropriate. However, an Offerer assuming Trickle ICE support MUST include a SIP Require: trickle-ice header field. That way, if the provisioned assumption of Trickle ICE support ends up being incorrect, the failure is (a) operationally easy to track down, and (b) recoverable by the client, i.e., they can re-send the request without the SIP Require: header field and without the assumption of Trickle ICE support. 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU) [RFC3840] provides a way for SIP User Agents to query for support of specific capabilities using, among others, OPTIONS requests. Support for GRUU according to [RFC5627] on the other hand allows SIP requests to be addressed to specific UAs (as opposed to arbitrary instances of an address of record). Combining the two and using the "trickle-ice" option tag defined in Section 10.6 provides SIP UAs with a way of learning the capabilities of specific SIP UA instances and then Ivov, et al. Expires December 24, 2018 [Page 20] Internet-Draft Trickle ICE for SIP June 2018 addressing them directly with INVITE requests that require Trickle ICE support. Such learning of capabilities may happen in different ways. One option for a SIP UA is to learn the GRUU instance ID of a peer through presence and then to query its capabilities with an OPTIONS request. Alternatively, it can also just send an OPTIONS request to the Address of Record (AOR) it intends to contact and then inspect the returned response(s) for support of both GRUU and Trickle ICE (Figure 8). It is noted that using the GRUU means that the INVITE request can go only to that particular device. This prevents the use of forking for that request. Alice Bob | | | OPTIONS sip:b1@example.com SIP/2.0 | |-------------------------------------------------->| | | | 200 OK | | Contact: sip:b1@example.com;gr=hha9s8d-999a | | ;audio;video|;trickle-ice;... | |<--------------------------------------------------| | | | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | | Supported: trickle-ice | | (Offer) | |-------------------------------------------------->| | | | 183 (Answer) | |<--------------------------------------------------| | INFO/OK (Trickling) | |<------------------------------------------------->| | | | ... | | | Figure 8: Trickle ICE support discovery with OPTIONS and GRUU Confirming support for Trickle ICE through [RFC3840] gives SIP UAs the options to engage in Full Trickle negotiation (as opposed to the more lengthy Half Trickle) from the very first Offer they send. 5.3. Fall-back to Half Trickle In cases where none of the other mechanisms in this section are acceptable, SIP UAs should use the Half Trickle mode defined in [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions Ivov, et al. Expires December 24, 2018 [Page 21] Internet-Draft Trickle ICE for SIP June 2018 the same way they would when using ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually sending an Offer, agents first gather ICE candidates in a blocking way and then send them all in that Offer. The blocking nature of the process implies that some amount of latency will be accumulated and it is advised that agents try to anticipate it where possible, for example, when user actions indicate a high likelihood for an imminent call (e.g., activity on a keypad or a phone going off-hook). Using Half Trickle results in Offers that are compatible with both ICE SIP endpoints and legacy [RFC3264] endpoints. Ivov, et al. Expires December 24, 2018 [Page 22] Internet-Draft Trickle ICE for SIP June 2018 STUN/Turn STUN/TURN Servers Alice Bob Servers | | | | |<--------------| | | | | | | | | | | | Candidate | | | | | | | | | | | | Discovery | | | | | | | | | | | |-------------->| INVITE (Offer) | | | |---------------------------->| | | | 183 (Answer) |-------------->| | |<----------------------------| | | | INFO (repeated candidates) | | | |---------------------------->| | | | | | | | INFO (more candidates) | Candidate | | |<----------------------------| | | | Connectivity Checks | | | |<===========================>| Discovery | | | INFO (more candidates) | | | |<----------------------------| | | | Connectivity Checks |<--------------| | |<===========================>| | | | | | | | 200 OK | | | |<----------------------------| | | | | | | |<======= MEDIA FLOWS =======>| | | | | | Figure 9: Example - A typical (Half) Trickle ICE exchange with SIP It is worth reminding that once a single Offer or Answer had been exchanged within a specific dialog, support for Trickle ICE will have been determined. No further use of Half Trickle will therefore be necessary within that same dialog and all subsequent exchanges can use the Full Trickle mode of operation. 6. Considerations for RTP and RTCP Multiplexing The following consideration describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing RTCP candidates. Ivov, et al. Expires December 24, 2018 [Page 23] Internet-Draft Trickle ICE for SIP June 2018 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing [RFC5761] is already considered in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in [RFC5761] itself. These considerations are still valid for Trickle ICE, however, trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing. [RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct for version 17 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" and the "a=rtcp-mux" attributes. While a Half Trickle Offerer has to send an Offer compliant to [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for all components, the flexibility of a Full Trickle Offerer allows to send only RTP candidates (component 1) in the initial Offer assuming that RTCP multiplexing is supported by the Answerer. A Full Trickle Offerer would need to start gathering and trickling RTCP candidates (component 2) only after having received an indication in the Answer that the Answerer unexpectedly does not support RTCP multiplexing. A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in the application/trickle-ice-sdpfrag body if it supports and uses RTP and RTCP multiplexing. The Trickle Answerer needs to follow the guidance on the usage of the "a=rtcp" attribute as given in [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses RTP and RTCP multiplexing. The Offerer can use this information e.g. for stopping gathering of RTCP candidates and/or for freeing corresponding resources. This behavior is illustrated by the following example Offer that indicates support for RTP and RTCP multiplexing. Ivov, et al. Expires December 24, 2018 [Page 24] Internet-Draft Trickle ICE for SIP June 2018 v=0 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com s= c=IN IP6 2001:db8:a0b:12f0::3 t=0 0 a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-ufrag:Yhh8 m=audio 5000 RTP/AVP 0 a=mid:1 a=rtcp-mux a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host Once the dialog is established as described in section Section 4.3 the Answerer sends the following INFO request. INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 161 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:1 a=rtcp-mux a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host This INFO request indicates that the Answerer supports and uses RTP and RTCP multiplexing as well. It allows the Offerer to omit gathering of RTCP candidates or releasing already gathered RTCP candidates. If the INFO request did not contain the a=rtcp-mux attribute, the Offerer has to gather RTCP candidates unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for RTP and RTCP multiplexing. In case the Offerer had sent RTCP candidates in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even in case that support for RTCP multiplexing was confirmed by the Answerer and the Offerer has released its RTCP candidates. Ivov, et al. Expires December 24, 2018 [Page 25] Internet-Draft Trickle ICE for SIP June 2018 7. Considerations for Media Multiplexing The following considerations describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing candidates in case of Media Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed that the reader is familiar with [I-D.ietf-mmusic-sdp-bundle-negotiation]. ICE candidate exchange is already considered in section 11 of [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are still valid for Trickle ICE, however, trickling provides more flexibility for the sequence of candidate exchange, especially in Full Trickle mode. Except for bundle-only "m=" lines, a Half Trickle Offerer has to send an Offer with candidates for all bundled "m=" lines. The additional flexibility, however, allows a Full Trickle Offerer to initially send only candidates for the "m=" line with the suggested Offerer BUNDLE address. On receipt of the Answer, the Offerer will detect if BUNDLE is supported by the Answerer and if the suggested Offerer BUNDLE address was selected. In this case, the Offerer does not need to trickle further candidates for the remaining "m=" lines in a bundle. However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates for the remaining "m=" lines as necessary. If the Answerer selects an Offerer BUNDLE address different from the suggested Offerer BUNDLE address, the Full Trickle Offerer needs to gather and trickle candidates for the "m=" line that carries the selected Offerer BUNDLE address. A Trickle Answerer SHOULD include an "a=group:BUNDLE" attribute [I-D.ietf-mmusic-sdp-bundle-negotiation] at session level in the application/trickle-ice-sdpfrag body if it supports and uses bundling. When doing so, the Answerer MUST include all identification-tags in the same order that is used or will be used in the Answer. Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses bundling. The Offerer can use this information e.g. for stopping the gathering of candidates for the remaining "m=" lines in a bundle and/or for freeing corresponding resources. This behaviour is illustrated by the following example Offer that indicates support for Media Multiplexing. Ivov, et al. Expires December 24, 2018 [Page 26] Internet-Draft Trickle ICE for SIP June 2018 In case the Offerer had sent already candidates for "m="-lines in a bundle in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even in case that support for bundling was confirmed by the Answerer and the Offerer has released no longer needed candidates. v=0 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com s= c=IN IP6 2001:db8:a0b:12f0::3 t=0 0 a=group:BUNDLE foo bar a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-ufrag:Yhh8 m=audio 10000 RTP/AVP 0 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host m=video 10002 RTP/AVP 31 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid The example Offer indicates support for RTP and RTCP multiplexing and contains a "a=candidate:" attribute only for the "m="-line with the suggested Offerer bundle address. Once the dialog is established as described in Section 4.3 the Answerer sends the following INFO request. Ivov, et al. Expires December 24, 2018 [Page 27] Internet-Draft Trickle ICE for SIP June 2018 INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 219 a=group:BUNDLE foo bar a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:foo a=rtcp-mux a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host This INFO request indicates that the Answerer supports and uses Media Multiplexing as well. Note that the Answerer only includes a single pseudo "m="-line since candidates matching those from the second "m="-line in the offer are not needed from the Answerer. The INFO request also indicates that the Answerer accepted the suggested Offerer Bundle Address. This allows the Offerer to omit gathering of RTP and RTCP candidates for the other "m=" lines or releasing already gathered candidates. If the INFO request did not contain the a=group:BUNDLE attribute, the Offerer has to gather RTP and RTCP candidates for the other "m=" lines unless it wants to wait until receipt of an Answer that eventually confirms support or non- support for Media Multiplexing. Independent of using Full Trickle or Half Trickle mode, the rules from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and Answerer, when putting attributes as specified in Section 9.2 in the application/trickle-ice-sdpfrag body. 8. SDP 'end-of-candidates' Attribute 8.1. Definition This section defines a new SDP media-level and session-level attribute [RFC4566] 'end-of-candidates'. 'end-of-candidates' is a property attribute [RFC4566], and hence has no value. By including this attribute in an Offer or Answer the sending agent indicates that it will not trickle further candidates. When included at session level this indication applies to the whole session, when included at media level the indication applies only to the corresponding media description. Ivov, et al. Expires December 24, 2018 [Page 28] Internet-Draft Trickle ICE for SIP June 2018 Name: end-of-candidates Value: N/A Usage Level: media and session-level Charset Dependent: no Mux Category: IDENTICAL Example: a=end-of-candidates 8.2. Offer/Answer Procedures The Offerer or Answerer MAY include an "a=end-of-candidates" attribute in case candidate discovery has ended and no further candidates are to be trickled. The Offerer or Answerer MUST provide the "a=end-of-candidates" attribute together with the "a=ice-ufrag" and "a=ice-pwd" attributes of the current ICE generation as required by [I-D.ietf-ice-trickle]. When included at session level this indication applies to the whole session; when included at media level the indication applies only to the corresponding media description. Receipt of an "a=end-of-candidates" attribute at an Offerer or Answerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - indicates that gathering of candidates has ended at the peer, either for the session or only for the corresponding media description as specified above. The receiving agent forwards an end-of-candidates indication to the ICE Agent, which in turn acts as specified in [I-D.ietf-ice-trickle]. 9. Content Type 'application/trickle-ice-sdpfrag' 9.1. Overall Description A application/trickle-ice-sdpfrag body is used exclusively by the 'trickle-ice' Info Package. Other SDP related applications need to define their own media type. The INFO request body uses a subset of the possible SDP lines as defined by the grammar defined in [RFC4566]. A valid body uses only pseudo "m=" lines and certain attributes that are needed and/or useful for trickling candidates. The content adheres to the following grammar. 9.2. Grammar The grammar of an 'application/trickle-ice-sdpfrag' body is based on the following ABNF [RFC5234]. It specifies the subset of existing SDP attributes, that is needed or useful for trickling candidates. Ivov, et al. Expires December 24, 2018 [Page 29] Internet-Draft Trickle ICE for SIP June 2018 The grammar uses the indicator for case-sensitivity %s as defined in [RFC7405], but also imports grammars for other SDP attributes that precede the production of [RFC7405]. A sender SHOULD use lower-case for attributes from such earlier grammars, but a receiver MUST treat them case-insensitively. Ivov, et al. Expires December 24, 2018 [Page 30] Internet-Draft Trickle ICE for SIP June 2018 ; Syntax trickle-ice-sdpfrag = session-level-fields pseudo-media-descriptions session-level-fields = *(session-level-field CRLF) session-level-field = ice-lite-attribute / ice-pwd-attribute / ice-ufrag-attribute / ice-options-attribute / ice-pacing-attribute / end-of-candidates-attribute / bundle-group-attribute / extension-attribute-fields ; for future extensions ice-lite-attribute = %s"a" "=" ice-lite ice-pwd-attribute = %s"a" "=" ice-pwd-att ice-ufrag-attribute = %s"a" "=" ice-ufrag-att ice-pacing-attribute = %s"a" "=" ice-pacing-att ice-options-attribute = %s"a" "=" ice-options end-of-candidates-attribute = %s"a" "=" end-of-candidates end-of-candidates = %s"end-of-candidates" bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics *(SP identification-tag) bundle-semantics = "BUNDLE" extension-attribute-fields = attribute-fields pseudo-media-descriptions = *( media-field trickle-ice-attribute-fields ) trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF) trickle-ice-attribute-field = mid-attribute / candidate-attributes / ice-pwd-attribute / ice-ufrag-attribute / remote-candidate-attribute / end-of-candidates-attribute / rtcp-attribute / rtcp-mux-attribute / rtcp-mux-only-attribute / extension-attribute-fields ; for future extensions rtcp-attribute = %s"a" "=" %s"rtcp" rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux" rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only" candidate-attributes = %s"a" "=" candidate-attribute remote-candidate-attribute = %s"a" "=" remote-candidate-att Ivov, et al. Expires December 24, 2018 [Page 31] Internet-Draft Trickle ICE for SIP June 2018 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- pacing-att, ice-options, candidate-attribute remote-candidate-att from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal grammar in their corresponding RFC and are reproduced here. The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also appear at the beginning of all INFO request payloads, i.e. preceding all pseudo "m=" lines. If they were originally exchanged as media level attributes, potentially overriding session-level values, then they will also be included in INFO request payloads following the corresponding pseudo "m=" lines. An Agent MUST ignore any received unknown extension-attribute-fields. 10. Info Package 10.1. Rationale - Why INFO? The decision to use SIP INFO requests as a candidate transport method is based primarily on their lightweight nature. Once a dialog has been established, INFO requests can be exchanged both ways with no restrictions on timing and frequency and no risk of collision. A critical fact is that the sending of Trickle ICE candidates in one direction is entirely uncoupled from sending candidates in the other direction. Thus, the sending of candidates in each direction can be done by a stream of INFO requests that is not correlated with the stream of INFO requests in the other direction. And since each INFO request cumulatively includes the contents of all previous INFO requests in that direction, ordering between INFO requests need not be preserved. All of this permits using largely-independent INFO requests. Contrarily, UPDATE or other offer/answer mechanisms assume that the messages in each direction are tightly coupled with messages in the other direction. Using Offer/Answer and UPDATE requests [RFC3311] would introduce the following complications: Blocking of messages: [RFC3264] defines Offer/Answer as a strictly sequential mechanism. There can only be a maximum of one active exchange at any point of time. Both sides cannot simultaneously send Offers nor can they generate multiple Offers prior to Ivov, et al. Expires December 24, 2018 [Page 32] Internet-Draft Trickle ICE for SIP June 2018 receiving an Answer. Using UPDATE requests for candidate transport would therefore imply the implementation of a candidate pool at every agent where candidates can be stored until it is once again that agent's "turn" to emit an Answer or a new Offer. Such an approach would introduce non-negligible complexity for no additional value. Elevated risk of glare: The sequential nature of Offer/Answer also makes it impossible for both sides to send Offers simultaneously. What's worse is that there are no mechanisms in SIP to actually prevent that. [RFC3261], where the situation of Offers crossing on the wire is described as "glare", only defines a procedure for addressing the issue after it has occurred. According to that procedure both Offers are invalidated and both sides need to retry the negotiation after a period between 0 and 4 seconds. The high likelihood for glare to occur and the average two second back-off intervals implies that the duration of Trickle ICE processing would not only fail to improve but actually exceed those of regular ICE. INFO messages decouple the exchange of candidates from the Offer/ Answer negotiation and are subject to none of the glare issues described above, which makes them a very convenient and lightweight mechanism for asynchronous delivery of candidates. Using in-dialog INFO messages also provides a way of guaranteeing that candidates are delivered end-to-end, between the same entities that are actually in the process of initiating a session. Out-of- dialog alternatives would have implied requiring support for Globally Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low adoption levels, would have constituted too strong of a constraint to the adoption of Trickle ICE. 10.2. Overall Description This specification defines an Info Package for use by SIP User Agents implementing Trickle ICE. INFO requests carry ICE candidates discovered after the peer user agents have confirmed mutual support for Trickle ICE. 10.3. Applicability The purpose of the ICE protocol is to establish a media path in the presence of NAT and firewalls. The candidates are transported in INFO requests and are part of this establishment. Candidates sent by a Trickle ICE Agent after the Offer, follow the same signaling path and reach the same entity as the Offer itself. Ivov, et al. Expires December 24, 2018 [Page 33] Internet-Draft Trickle ICE for SIP June 2018 While it is true that GRUUs can be used to achieve this, one of the goals of this specification is to allow operation of Trickle ICE in as many environments as possible including those without GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not satisfy this goal. 10.4. Info Package Name This document defines a SIP Info Package as per [RFC6086]. The Info Package token name for this package is "trickle-ice" 10.5. Info Package Parameters This document does not define any Info Package parameters. 10.6. SIP Option Tags [RFC6086] allows Info Package specifications to define SIP option- tags. This specification extends the option-tag construct of the SIP grammar as follows: option-tag /= "trickle-ice" SIP entities that support this specification MUST place the 'trickle- ice' option-tag in a SIP Supported: or Require: header field within all SIP INVITE requests and responses. When responding to, or generating a SIP OPTIONS request a SIP entity MUST also include the 'trickle-ice' option-tag in a SIP Supported: or Require: header field. 10.7. Info Request Body Parts Entities implementing this specification MUST include a payload of type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in SIP INFO requests. The payload is used to convey SDP-encoded ICE candidates. 10.8. Info Package Usage Restrictions This document does not define any Info Package Usage Restrictions. 10.9. Rate of INFO Requests Given that IP addresses may be gathered rapidly a Trickle ICE Agent with many network interfaces might create a high rate of INFO requests if every newly detected candidate is trickled individually without aggregation. An implementation MUST aggregate ICE candidates Ivov, et al. Expires December 24, 2018 [Page 34] Internet-Draft Trickle ICE for SIP June 2018 in case that an unreliable transport protocol such as UDP is used. A Trickle ICE agent MUST NOT have more than one INFO request pending at any one time. When INFO messages are sent over an unreliable transport, they are retransmitted according to the rules specified in [RFC3261] section 17.1.2.1." If the INFO requests are sent on top of TCP, which is probably the standard way, this is not an issue for the network anymore, but it can remain one for SIP proxies and other intermediaries forwarding the SIP INFO messages. Also, an endpoint may not be able to tell that it has congestion controlled transport all the way. 10.10. Info Package Security Considerations See Section 13 11. Deployment Considerations Trickle ICE uses two mechanisms for exchange of candidate information. This imposes new requirements to certain middleboxes that are used in some networks, e.g. for monitoring purposes. While the first mechanism, SDP Offers and Answers, is already used by regular ICE and is assumed to be supported, the second mechanism, INFO request bodies, needs to be considered by such middleboxes as well when trickle ICE is used. Such middleboxes need to make sure that they remain in the signaling path of the INFO requests and need to understand the INFO request body. 12. IANA Considerations [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. ] 12.1. SDP 'end-of-candidates' Attribute This section defines a new SDP media-level and session-level attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a property attribute [RFC4566] , and hence has no value. Ivov, et al. Expires December 24, 2018 [Page 35] Internet-Draft Trickle ICE for SIP June 2018 Name: end-of-candidates Value: N/A Usage Level: media and session Charset Dependent: no Purpose: The sender indicates that it will not trickle further ICE candidates. O/A Procedures: RFCXXX defines the detailed SDP Offer/Answer procedures for the 'end-of-candidates' attribute. Mux Category: IDENTICAL Reference: RFCXXXX Example: a=end-of-candidates 12.2. Media Type 'application/trickle-ice-sdpfrag' This document defines a new Media Type 'application/trickle-ice- sdpfrag' in accordance with [RFC6838]. Type name: application Subtype name: trickle-ice-sdpfrag Required parameters: None. Optional parameters: None. Encoding considerations: The media contents follow the same rules as SDP, except as noted in this document. The media contents are text, with the grammar specified in Section 9.2. Although the initially defined content of a trickle-ice-sdpfrag body does only include ASCII characters, UTF-8 encoded content might be introduced via extension attributes. The "a=charset:" Ivov, et al. Expires December 24, 2018 [Page 36] Internet-Draft Trickle ICE for SIP June 2018 attribute may be used to signal the presence of other character sets in certain parts of a trickle-ice-sdpfrag body (see [RFC4566]). Arbitrary binary content cannot be directly represented in SDP or a trickle-ice-sdpfrag body. Security considerations: See [RFC4566] and RFCXXXX Interoperability considerations: See RFCXXXX Published specification: See RFCXXXX Applications which use this Media Type: Trickle-ICE Fragment identifier considerations: N/A 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: The IESG (iesg@ietf.org) Ivov, et al. Expires December 24, 2018 [Page 37] Internet-Draft Trickle ICE for SIP June 2018 Intended usage: Trickle-ICE for SIP as specified in RFCXXXX. Restrictions on usage: N/A Author/Change controller: The IESG (iesg@ietf.org) Provisional registration? (standards tree only): N/A 12.3. SIP Info Package 'trickle-ice' This document defines a new SIP Info Package named 'trickle-ice' and updates the Info Packages Registry with the following entry. +-------------+-----------+ | Name | Reference | +-------------+-----------+ | trickle-ice | [RFCXXXX] | | | | +-------------+-----------+ 12.4. SIP Option Tag 'trickle-ice' This specification registers a new SIP option tag 'trickle-ice' as per the guidelines in Section 27.1 of [RFC3261] and updates the "Option Tags" section of the SIP Parameter Registry with the following entry: +-------------+-------------------------------------+-----------+ | Name | Description | Reference | +-------------+-------------------------------------+-----------+ | trickle-ice | This option tag is used to indicate | [RFCXXXX] | | | that a UA supports and understands | | | | Trickle-ICE. | | +-------------+-------------------------------------+-----------+ 13. Security Considerations The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies Ivov, et al. Expires December 24, 2018 [Page 38] Internet-Draft Trickle ICE for SIP June 2018 how the above specifications are used together for trickling candidates and does not create additional security risks. The new Info Package 'trickle-ice' and the new Media Type 'application/trickle-ice-sdpfrag' do not introduce additional security considerations when used in the context of Trickle ICE. Both are not intended to be used for other applications, so any security considerations for its use in other contexts is out of the scope of this document 14. Acknowledgements The authors like to thank Flemming Andreasen, Ayush Jain, Paul Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin Thomson for reviewing and/or making various suggestions for improvements and optimizations. The authors also like to thank Flemming Andreasen for shepherding this document and Ben Campbell for his AD review and suggestions. In addition, the author like to thank Benjamin Kaduk, Adam Roach, Mirja Kuehlewind and Eric Rescorla for their comments and/or text proposals for improving the document during IESG review. Many thanks to Dale Worley for Gen-Art review and proposed enhancements for several sections. Many thanks to Joerg Ott for TSV-Art review and suggested improvements. The authors thank Shawn Emery for Security Directorate review. 15. Change Log [RFC EDITOR NOTE: Please remove this section when publishing]. Changes from draft-ietf-mmusic-trickle-ice-sip-01 o Editorial Clean up o IANA Consideration added o Security Consideration added o RTCP and BUNDLE Consideration added with rules for including "a=rtcp-mux" and "a=group: BUNDLLE" attributes o 3PCC Consideration added Ivov, et al. Expires December 24, 2018 [Page 39] Internet-Draft Trickle ICE for SIP June 2018 o Clarified that 18x w/o answer is sufficient to create a dialog that allows for trickling to start o Added remaining Info Package definition sections as outlined in section 10 of [RFC6086] o Added definition of application/sdpfrag making draft-ivov-mmusic- sdpfrag obsolete o Added pseudo m-lines as additional separator in sdpfrag bodies for Trickle ICE o Added ABNF for sdp-frag bodies and Trickle-ICE package Changes from draft-ietf-mmusic-trickle-ice-sip-02 o Removed definition of application/sdpfrag o Replaced with new type application/trickle-ice-sdpfrag o RTCP and BUNDLE Consideration enhanced with some examples o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to normative reference o Removed reference to 4566bis o Addressed review comment from Simon Perreault Changes from draft-ietf-mmusic-trickle-ice-sip-03 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and draft-ietf-mmusic-ice-sip-sdp o Corrected Figure 10, credits to Ayush Jain for finding the bug o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- ice-sip-sdp o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for the application/trickle-ice-sdpfrag body Changes from draft-ietf-mmusic-trickle-ice-sip-04 o considered comments from Christer Holmberg Ivov, et al. Expires December 24, 2018 [Page 40] Internet-Draft Trickle ICE for SIP June 2018 o corrected grammar for INFO package, such that ice-ufrag/pwd are also allowed on media-level as specified in [I-D.ietf-mmusic-ice-sip-sdp] o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] o Added formal definition for the end-of-candidates attribute Changes from draft-ietf-mmusic-trickle-ice-sip-05 o considered further comments from Christer Holmberg o editorial comments on section 3 addressed o moved section 3.1 to section 10.1 and applied some edits o replaced the term "previously sent candidates" with "currently known and used candidates". Changes from draft-ietf-mmusic-trickle-ice-sip-06 o editorial fixes o additional text on the content of the INFO messages. o recommendation on what to do if a previously sent candidate is unexpectedly missing in a subsequent INFO o terminology alignment with draft-ietf-ice-trickle-07 Changes from draft-ietf-mmusic-trickle-ice-sip-07 o editorial fixes o clarification on ordering of candidates for alignment with draft- ietf-ice-trickle-12 o O/A procedures for end-of-candidates attribute described here after corresponding procedures have been removed from draft-ietf- ice-trickle-11 o using IPv6 addresses in examples Changes from draft-ietf-mmusic-trickle-ice-sip-08 o editorial fixes/clarification based on Flemmings review Ivov, et al. Expires December 24, 2018 [Page 41] Internet-Draft Trickle ICE for SIP June 2018 o Description of Trickle specifics in O/A procedures for initial O/A exchange and specification of ICE mismatch exception Changes from draft-ietf-mmusic-trickle-ice-sip-09 o editorial fixes/correction of references o adding missing Ref to RFC3605 in section 6, 5th para o replaced remaining IPv4 adresses with IPv6 o Added text for handling a=rtcp in case of default RTP address 0.0.0.0:9 based on comment from Roman Shpount. Changes from draft-ietf-mmusic-trickle-ice-sip-10 o editorial fixes due to idnits output Changes from draft-ietf-mmusic-trickle-ice-sip-11 o addressing comments from Ben Campell's AD review and Christer's review o Numerous editorial improvements/corrections o Added [RFC8174] boiler plate and adapted usage of normative language o Clarified terminology ICE modules .vs. ICE agent o Added more detailed OA procedures o Corrected default values in m-line and usage of "a=mid:" attribute explicitly mentioned for offer/answer o Removed explicit mentioning of XMPP o Added Deployment Considerations section o Fixed ref for rfc5245bis Changes from draft-ietf-mmusic-trickle-ice-sip-12 o addressing comments from Gen-Art review, TSV-Art review and Security Directorate review o Numerous editorial improvements/corrections/clarifications Ivov, et al. Expires December 24, 2018 [Page 42] Internet-Draft Trickle ICE for SIP June 2018 Changes from draft-ietf-mmusic-trickle-ice-sip-13 o added expansions for SDP,GRUU, AOR, STUN, TURN o some editorial corrections Changes from draft-ietf-mmusic-trickle-ice-sip-14 Addressing comments from IESG review o Clarification/enhancement in section 5 and Fig. 10 based on comments from Benjamin Kaduk o Clarification on sequence for sending candidates, definition of pseudo m-lines, usage of a=mid attribute, usage of INFO as ACK for receipt of 18x based on comments from Eric Rescorla o Removal of 3PCC Section 3.4, removal of NATted IPv6 addresses, adding more flexibility to in the grammar, explicit mentioning of Require: header field, usage of Require: header field in case of provisioning, text on repetition of candidates in case of RTCP mux and Bundle, various other editorial improvements/corrections based on comments from Adam Roach o Modified text on rate limitation of INFO requests based on comments of Mirja Kuehlewind, Adam Roach and Roman Shpount o some editorial corrections Changes from draft-ietf-mmusic-trickle-ice-sip-15 o Corrections in section 7 on Media Multiplexing Changes from draft-ietf-mmusic-trickle-ice-sip-16 o some editorial corrections Changes from draft-ietf-mmusic-trickle-ice-sip-16 o Changed IPv6 candidate example from srflx to host 16. References 16.1. Normative References Ivov, et al. Expires December 24, 2018 [Page 43] Internet-Draft Trickle ICE for SIP June 2018 [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-20 (work in progress), March 2018. [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-21 (work in progress), April 2018. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in progress), April 2018. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-12 (work in progress), May 2017. [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-52 (work in progress), May 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [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, . Ivov, et al. Expires December 24, 2018 [Page 44] Internet-Draft Trickle ICE for SIP June 2018 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, DOI 10.17487/RFC6086, January 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, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . Ivov, et al. Expires December 24, 2018 [Page 45] Internet-Draft Trickle ICE for SIP June 2018 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 16.2. Informative References [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, . [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, . [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, . [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, DOI 10.17487/RFC5766, April 2010, . Authors' Addresses Ivov, et al. Expires December 24, 2018 [Page 46] Internet-Draft Trickle ICE for SIP June 2018 Emil Ivov Jitsi Strasbourg 67000 France Phone: +33 6 72 81 15 55 Email: emcho@jitsi.org Thomas Stach Unaffiliated Vienna 1130 Austria Email: thomass.stach@gmail.com Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy Email: enrico.marocco@telecomitalia.it Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Ivov, et al. Expires December 24, 2018 [Page 47] ./draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt0000644000764400076440000023653313543033021021432 0ustar iustyiusty PCE Working Group D. Dhody, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track R. Gandhi, Ed. Expires: March 29, 2020 Cisco Systems, Inc. U. Palle R. Singh Individual Contributor L. Fang Expedia, Inc. September 26, 2019 PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE draft-ietf-pce-stateful-pce-auto-bandwidth-12 Abstract 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. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) using PCEP. The automatic bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for automatic bandwidth adjustment when employing an Active Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs. 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 https://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." Dhody, et al. Expires March 29, 2020 [Page 1] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Conventions Used in This Document . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements for PCEP Extensions . . . . . . . . . . . . . . . 7 4. Architectural Overview . . . . . . . . . . . . . . . . . . . . 8 4.1. Auto-Bandwidth Overview . . . . . . . . . . . . . . . . . 8 4.2. Auto-bandwidth Theory of Operation . . . . . . . . . . . . 9 4.3. Scaling Considerations . . . . . . . . . . . . . . . . . . 10 5. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Capability Advertisement . . . . . . . . . . . . . . . . . 10 5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV . . . . . . . . . . . . 11 5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV . . . . . . . . . . . . . . 12 5.2.1. Sample-Interval sub-TLV . . . . . . . . . . . . . . . 13 5.2.2. Adjustment Intervals . . . . . . . . . . . . . . . . . 14 5.2.2.1. Adjustment-Interval sub-TLV . . . . . . . . . . . 14 5.2.2.2. Down-Adjustment-Interval sub-TLV . . . . . . . . . 14 5.2.3. Adjustment Thresholds . . . . . . . . . . . . . . . . 15 5.2.3.1. Adjustment-Threshold sub-TLV . . . . . . . . . . . 15 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV . . . . . 16 5.2.3.3. Down-Adjustment-Threshold sub-TLV . . . . . . . . 17 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV . . . 18 5.2.4. Minimum and Maximum Bandwidth Values . . . . . . . . . 19 5.2.4.1. Minimum-Bandwidth sub-TLV . . . . . . . . . . . . 19 5.2.4.2. Maximum-Bandwidth sub-TLV . . . . . . . . . . . . 19 5.2.5. Overflow and Underflow Conditions . . . . . . . . . . 20 5.2.5.1. Overflow-Threshold sub-TLV . . . . . . . . . . . . 20 Dhody, et al. Expires March 29, 2020 [Page 2] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 5.2.5.2. Overflow-Threshold-Percentage sub-TLV . . . . . . 21 5.2.5.3. Underflow-Threshold sub-TLV . . . . . . . . . . . 22 5.2.5.4. Underflow-Threshold-Percentage sub-TLV . . . . . . 23 5.3. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 24 5.4. The PCInitiate Message . . . . . . . . . . . . . . . . . . 24 5.5. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24 5.6. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 24 5.7. The PCNtf Message . . . . . . . . . . . . . . . . . . . . 25 6. Manageability Considerations . . . . . . . . . . . . . . . . . 26 6.1. Control of Function and Policy . . . . . . . . . . . . . . 26 6.2. Information and Data Models . . . . . . . . . . . . . . . 26 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 27 6.6. Impact On Network Operations . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 28 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field . . . . . . . . . 28 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV . . . . . . . . . . . . 29 8.4. Error Object . . . . . . . . . . . . . . . . . . . . . . . 29 8.5. Notification Object . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction [RFC5440] describes the Path Computation Element Protocol (PCEP) as a communication mechanism between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCE and PCE, that enables computation of Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs). [RFC8231] specifies extensions to PCEP to enable stateful control of MPLS TE LSPs. It describes two mode of operations - Passive stateful PCE and Active stateful PCE. Further, [RFC8281] describes the setup, maintenance and teardown of PCE-Initiated LSPs for the stateful PCE model. In this document, the focus is on Active stateful PCE where the LSPs are controlled by the PCE. Dhody, et al. Expires March 29, 2020 [Page 3] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 Over time, based on the varying traffic pattern, an LSP established with a certain bandwidth may require adjustment of the bandwidth reserved in the network dynamically. The head-end Label Switch Router (LSR) monitors the actual bandwidth demand of the established LSP and periodically computes new bandwidth. The head-end LSR adjusts the bandwidth reservation of the LSP based on the computed bandwidth automatically. This feature, when available in the head- end Label Switching Router (LSR) implementation, is common referred to as Auto-Bandwidth. The Auto-Bandwidth feature is described in detail in Section 4 of this document. In the model considered in this document, the PCC (head-end of the LSP) collects the traffic rate samples flowing through the LSP and calculates the new adjusted bandwidth. The PCC reports the calculated bandwidth to be adjusted to the PCE. This is similar to the Passive stateful PCE model: while the Passive stateful PCE uses a path request/reply mechanism, the Active stateful PCE uses a report/update mechanism. In case of PCE-Initiated LSP, the PCC is requested during the LSP initiation to monitor and calculate the new adjusted bandwidth. [RFC8051] describes the use-case for Auto- Bandwidth adjustment for Passive and Active stateful PCE. Another approach would be to send the measured values itself to the PCE, which is considered out of scope for this document. This document defines the PCEP extensions needed to support an Auto- Bandwidth feature in an Active stateful PCE model where the LSP bandwidth to be adjusted is calculated on the PCC (head-end of the LSP). The use of PCE to calculate the bandwidth to be adjusted is out of scope of this document. 2. Conventions Used in This Document 2.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Abbreviations PCC: Path Computation Client. PCE: Path Computation Element. Dhody, et al. Expires March 29, 2020 [Page 4] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 PCEP: Path Computation Element Communication Protocol. TE LSP: Traffic Engineering Label Switched Path. 2.3. Terminology The reader is assumed to be familiar with the terminology defined in [RFC5440], [RFC8231], and [RFC8281]. In this document, the PCC is considered to be the head end LSR of the LSP. Other types of PCC are not in scope. The following auto-bandwidth terminology is defined in this document. Maximum Average Bandwidth (MaxAvgBw): The maximum average bandwidth represents the current 'measured' traffic bandwidth demand of the LSP during a time interval. This is the maximum value of the traffic bandwidth rate samples (Bandwidth-Samples) in a given time interval. Adjusted Bandwidth: This is the Auto-Bandwidth 'computed' bandwidth that is used to adjust the bandwidth reservation of the LSP. Sample-Interval: The periodic time interval at which the measured traffic rate of the LSP is collected as a Bandwidth-Sample. Bandwidth-Sample: The bandwidth sample of the measured traffic rate of the LSP collected at every Sample-Interval. Maximum-Bandwidth: The maximum bandwidth that can be reserved for the LSP. Minimum-Bandwidth: The minimum bandwidth that can be reserved for the LSP. Up-Adjustment-Interval: The periodic time interval at which the bandwidth adjustment should be made using the MaxAvgBw, when MaxAvgBw is greater than the current bandwidth reservation of the LSP. Down-Adjustment-Interval: The periodic time interval at which the bandwidth adjustment should be made using the MaxAvgBw, when MaxAvgBw is less than the current bandwidth reservation of the LSP. Up-Adjustment-Threshold: This parameter is used to decide when the LSP bandwidth should be adjusted. If the percentage or absolute Dhody, et al. Expires March 29, 2020 [Page 5] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the LSP bandwidth is adjusted (upsized) to the current bandwidth demand (Adjusted Bandwidth) at the Up-Adjustment-Interval expiry. Down-Adjustment-Threshold: This parameter is used to decide when the LSP bandwidth should be adjusted. If the percentage or absolute difference between the current bandwidth reservation and the current MaxAvgBw is greater than or equal to the threshold value, the LSP bandwidth is adjusted (downsized) to the current bandwidth demand (Adjusted Bandwidth) at the Down-Adjustment-Interval expiry. Overflow-Count: This parameter is used to decide when the LSP bandwidth should be adjusted when there is a sudden increase in traffic demand. This value indicates how many times, consecutively, the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP needs to be greater than or equal to the Overflow-Threshold value in order to meet the overflow condition. Overflow-Threshold: This parameter is used to decide when the LSP bandwidth should be adjusted when there is a sudden increase in traffic demand. If the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP is greater than or equal to the threshold value, the overflow condition is said to be met. The LSP bandwidth is adjusted to the current bandwidth demand bypassing the Up-Adjustment-Interval if the overflow condition is met consecutively for the Overflow- Count. The Overflow-Threshold needs to be greater than or equal to the Up-Adjustment-Threshold. Underflow-Count: This parameter is used to decide when the LSP bandwidth should be adjusted when there is a sudden decrease in traffic demand. This value indicates how many times consecutively, the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP needs to be greater than or equal to the Underflow-Threshold value in order to meet the underflow condition. Underflow-Threshold: This parameter is used to decide when the LSP bandwidth should be adjusted when there is a sudden decrease in traffic demand. If the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP is greater than or equal to the threshold value, the underflow condition is said to be met. The LSP bandwidth is adjusted to the current bandwidth demand bypassing the Down-Adjustment-Interval if the underflow condition is met consecutively for the Underflow- Dhody, et al. Expires March 29, 2020 [Page 6] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 Count. The Underflow-Threshold needs to be greater than or equal to the Down-Adjustment-Threshold. Minimum-Threshold: When percentage-based thresholds are in use, they are accompanied by this minimum threshold, which is used to enforce that the magnitude of deviation of calculated LSP bandwidth to be adjusted from the current bandwidth reservations exceeds a specific non-percentage-based criterion (represented as an absolute bandwidth value) before any adjustments are made. This serves to suppress unnecessary auto-bandwidth adjustments and re- signaling of the LSP at low bandwidth values. 3. Requirements for PCEP Extensions The PCEP extensions required for auto-bandwidth are summarized in the following table as well as in Figure 1. +---------------------------------+---------------------------------+ | PCC Initiated | PCE Initiated | +---------------------------------+---------------------------------+ | | | | PCC monitors the traffic | At the time of initiation, | | and reports the calculated | PCE request PCC to monitor | | bandwidth to be adjusted | the traffic and report the | | to the PCE. | calculated bandwidth to be | | | adjusted to the PCE. | | | | | Extension is needed for PCC | Extension is needed for PCE | | to pass on the adjustment | to pass on the adjustment | | parameters at the time of | parameters at the time of | | LSP Delegation. | LSP Initiation. | | | | +---------------------------------+---------------------------------+ Table 1: Requirements for Auto-Bandwidth PCEP extensions ---------- | | | PCE | | | ---------- | ^ AUTO-BANDWIDTH CAPABILITY | | AUTO-BANDWIDTH CAPABILITY | | AUTO-BANDWIDTH ATTRIBUTES | | AUTO-BANDWIDTH ATTRIBUTES | | (For Delegated LSPs) | | Dhody, et al. Expires March 29, 2020 [Page 7] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 | | REQUESTED BANDWIDTH v | ---------- | | | PCC | | | ---------- Figure 1: Overview of Auto-Bandwidth PCEP extensions A PCEP speaker supporting this document must have a mechanism to advertise the automatic bandwidth adjustment capability for both PCC- Initiated and PCE-Initiated LSPs. Auto-bandwidth deployment considerations for PCEP extensions are summarized below: o It is necessary to identify and inform the PCC which LSPs have enabled the Auto-Bandwidth feature. Not all LSPs in some deployments would like their bandwidth to be dependent on the real-time bandwidth usage; for some LSPs leaving the bandwidth constant as set by the operator is preferred. o In addition, an operator should be able to specify the auto- bandwidth adjustment parameters (i.e. configuration knobs) to control this feature (e.g. minimum/ maximum bandwidth range). The PCC should be informed about these adjustment parameters. 4. Architectural Overview 4.1. Auto-Bandwidth Overview The Auto-Bandwidth feature allows automatic and dynamic adjustment of the reserved bandwidth of an LSP over time (i.e., without network operator intervention) to accommodate the varying traffic demand of the LSP. If the traffic flowing through the LSP is lower than the configured or current reserved bandwidth of the LSP, the extra bandwidth is being reserved needlessly and being wasted. Conversely, if the actual traffic flowing through the LSP is higher than the configured or current reserved bandwidth of the LSP, it can potentially cause congestion or packet loss in the network. The initial LSP bandwidth can be set to an arbitrary value (including zero). In practice, it can be set to an expected value based on design and planning. The head-end Label Switch Router (LSR) monitors the actual traffic flowing through the LSP and uses that information to adjust the bandwidth reservation of the LSP in the network. Dhody, et al. Expires March 29, 2020 [Page 8] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 Bandwidth adjustment must not cause disruption to the traffic flow carried by the LSP. One way to achieve this is to use the make-before-break signaling method [RFC3209]. 4.2. Auto-bandwidth Theory of Operation This section describes the Auto-Bandwidth feature in a general way. When the Auto-Bandwidth feature is enabled, the measured traffic rate is periodically sampled at each Sample-Interval by the PCC, when the PCC is the head-end node of the LSP. The sample interval can be configured by an operator, with a default value of 5 minutes. A very low Sample-Interval could have some undesirable interactions with transport protocols (see Section 6.6). The traffic rate samples are accumulated over the Adjustment-Interval period (in the Up or Down direction). The period can be configured by an operator, with a default value of 24 hours. The PCC in-charge of calculating the bandwidth to be adjusted can decide to adjust the bandwidth of the LSP to the highest traffic rate sample (MaxAvgBw) amongst the set of bandwidth samples collected over the Adjustment-Interval period (in the Up or Down direction) depending on the operator policy. Note that the highest traffic rate sample could be higher or lower than the current LSP bandwidth. Only if the difference between the current bandwidth demand (MaxAvgBw) and the current bandwidth reservation is greater than or equal to the Adjustment-Threshold the LSP bandwidth is adjusted (upsized) to the current bandwidth demand (MaxAvgBw). The Adjustment-Threshold could be an absolute value or a percentage. The threshold can be configured by an operator, with a default value of 5 percentage. Similarly, if the difference between the current bandwidth reservation and the current bandwidth demand (MaxAvgBw) is greater than or equal to the Down-Adjustment-Threshold (percentage or absolute value), the LSP bandwidth is adjusted (downsized) to the current bandwidth demand (MaxAvgBw). Some LSPs are less eventful while other LSPs may encounter a lot of changes in the traffic pattern. The thresholds and intervals for bandwidth adjustment are configured based on the traffic pattern of the LSP. In order to avoid frequent re-signaling, an operator may set a longer adjustment-interval value (Up and/or Down). However, a longer Adjustment-Interval can result in an undesirable effect of masking sudden changes in traffic demands of an LSP. To avoid this, the Auto-Bandwidth feature may prematurely expire the adjustment interval and adjust the LSP bandwidth to accommodate the sudden bursts of increase in traffic demand as an overflow condition or decrease in traffic demand as an underflow condition. An operator needs to Dhody, et al. Expires March 29, 2020 [Page 9] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 configure appropriate values for the Overflow-Threshold and/or Underflow-Threshold parameters and they do not have default values defined in this document. All thresholds in this document could be represented in both absolute value and percentage, and could be used together. This is provided to accommodate the cases where the LSP bandwidth reservation may become very large or very small over time. For example, an operator may use the percentage threshold to handle small to large bandwidth values and absolute values to handle very large bandwidth values. The auto-bandwidth adjustment is made when either one of the two thresholds, the absolute or percentage, is crossed. When using the (adjustment/overflow/underflow) percentage thresholds, if the LSP bandwidth changes rapidly at very low values, it may trigger frequent auto-bandwidth adjustments due to the crossing of the percentage thresholds. This can lead to unnecessary re-signaling of the LSPs in the network. This is suppressed by setting the minimum-threshold parameters along with the percentage thresholds. The auto-bandwidth adjustment is only made if the LSP bandwidth crosses both the percentage threshold and the minimum-threshold parameters. 4.3. Scaling Considerations It should be noted that any bandwidth change requires re-signaling of an LSP, which can further trigger preemption of lower priority LSPs in the network. When deployed under scale, this can lead to a signaling churn in the network. The Auto-bandwidth application algorithm is thus advised to take this into consideration before adjusting the LSP bandwidth. Operators are advised to set the values of various auto-bandwidth adjustment parameters appropriate for the deployed LSP scale. If a PCE gets overwhelmed, it can notify the PCC to temporarily suspend the reporting of the new LSP bandwidth to be adjusted (see Section 5.7 of this document). Similarly, if a PCC gets overwhelmed due to signaling churn, it can notify the PCE to temporarily suspend new LSP setup requests (see Section 5.7 of this document). 5. PCEP Extensions 5.1. Capability Advertisement During PCEP Initialization Phase, PCEP speakers (PCE or PCC) advertise their support of Automatic Bandwidth adjustment feature. A Dhody, et al. Expires March 29, 2020 [Page 10] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 PCEP speaker includes the AUTO-BANDWIDTH-CAPABILITY TLV, in the OPEN Object to advertise its support for PCEP Auto-Bandwidth extensions. The presence of the AUTO-BANDWIDTH-CAPABILITY TLV in the OPEN Object indicates that the Automatic Bandwidth feature is supported as described in this document. o The PCEP protocol extensions for Auto-Bandwidth adjustments MUST NOT be used if one or both PCEP speakers have not included the AUTO-BANDWIDTH-CAPABILITY TLV in their respective OPEN message. o A PCEP speaker that does not recognize the extensions defined in this document would simply ignore the TLVs as per [RFC5440]. o If a PCEP speaker that supports the extensions defined in this document but did not advertise this capability, then upon receipt of AUTO-BANDWIDTH-ATTRIBUTES TLV in the LSP Attributes (LSPA) object, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD4 (Auto-Bandwidth capability was not advertised) and ignore the AUTO-BANDWIDTH-ATTRIBUTES TLV. 5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV The AUTO-BANDWIDTH-CAPABILITY TLV is an optional TLV for use in the OPEN Object for Automatic Bandwidth Adjustment via PCEP capability advertisement. Its format is shown in the following figure: 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=TBD2 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AUTO-BANDWIDTH-CAPABILITY TLV format The Type of the TLV is (TBD2) and it has a fixed Length of 4 octets. The value comprises a single field - Flags (32 bits). No flags are defined for this TLV in this document. Unassigned bits are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt. Advertisement of the AUTO-BANDWIDTH-CAPABILITY TLV implies support of auto-bandwidth adjustment, as well as the objects, TLVs and procedures defined in this document. Dhody, et al. Expires March 29, 2020 [Page 11] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV The AUTO-BANDWIDTH-ATTRIBUTES TLV provides the 'configurable knobs' of the feature and it can be included as an optional TLV in the LSPA Object (as described in [RFC5440]). For PCE-Initiated LSP [RFC8281], this TLV is included in the LSPA Object with the PCInitiate message. For the PCC-Initiated delegated LSPs, this TLV is carried in the PCRpt message in LSPA Object. This TLV is also carried in the LSPA object with the PCUpd message to direct the PCC (LSP head-end) to make updates to auto-bandwidth attributes such as Adjustment-Interval. The TLV is encoded in all PCEP messages for the LSP while the auto- bandwidth adjustment feature is enabled, the absence of the TLV indicates the PCEP speaker wishes to disable the feature. This TLV includes multiple AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs. The AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs are included if there is a change since the last information sent in the PCEP message. The default values for missing sub-TLVs apply for the first PCEP message for the LSP. The format of the AUTO-BANDWIDTH-ATTRIBUTES TLV is shown in the following figure: 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=TBD1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // sub-TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AUTO-BANDWIDTH-ATTRIBUTES TLV format Type: TBD1 Length: The Length field defines the length of the value portion in octets as per [RFC5440]. Value: This comprises one or more sub-TLVs. Following sub-TLVs are defined in this document: Type Len Name ------------------------------------------------------------------- Dhody, et al. Expires March 29, 2020 [Page 12] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 1 4 Sample-Interval sub-TLV 2 4 Adjustment-Interval sub-TLV 3 4 Down-Adjustment-Interval sub-TLV 4 4 Adjustment-Threshold sub-TLV 5 8 Adjustment-Threshold-Percentage sub-TLV 6 4 Down-Adjustment-Threshold sub-TLV 7 8 Down-Adjustment-Threshold-Percentage sub-TLV 8 4 Minimum-Bandwidth sub-TLV 9 4 Maximum-Bandwidth sub-TLV 10 8 Overflow-Threshold sub-TLV 11 8 Overflow-Threshold-Percentage sub-TLV 12 8 Underflow-Threshold sub-TLV 13 8 Underflow-Threshold-Percentage sub-TLV Future specifications can define additional sub-TLVs. The sub-TLVs are encoded to inform the PCEP peer of the various sampling and adjustment parameters. In case of a missing sub-TLV, as per the local policy, either the default value (as specified in this document) or some other operator configured value is used. All sub-TLVs are optional and any unrecognized sub-TLV MUST be ignored. If a sub-TLV of the same type appears more than once, only the first occurrence is processed and all others MUST be ignored. The following sub-sections describe the sub-TLVs which are currently defined to be carried within the AUTO-BANDWIDTH-ATTRIBUTES TLV. 5.2.1. Sample-Interval sub-TLV The Sample-Interval sub-TLV specifies a time interval in seconds at which traffic samples are collected at the PCC. 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 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sample-Interval sub-TLV format The Type is 1, Length is 4 octets, and the value comprises of - o Sample-Interval: The 4-octet time interval for bandwidth sample collection. The valid range is from 1 to 604800 (7 days), in seconds. The default value is 300 seconds. Due care needs to be Dhody, et al. Expires March 29, 2020 [Page 13] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 taken in case of a very low Sample-Interval, as it can have some undesirable interactions with transport protocols (see Section 6.6). The sample-interval parameter MUST NOT be greater than the (down) adjustment-interval. In case of an invalid value, the Sub- TLV MUST be ignored and the previous value is maintained. 5.2.2. Adjustment Intervals The sub-TLVs in this section are encoded to inform the PCEP peer the adjustment interval parameters. The Adjustment-Interval sub-TLV specifies the time interval for both upward (Up-Adjustment-Interval) and downward (Down-Adjustment-Interval) trends. An implementation MAY require to set a different adjustment interval values for when the bandwidth usage trend is downwards from when it is moving upwards. In that case, the operator could use the Down-Adjustment-Interval sub- TLV which overrides the Adjustment-Interval value for Down- Adjustment-Interval. 5.2.2.1. Adjustment-Interval sub-TLV The Adjustment-Interval sub-TLV specifies a time interval in seconds at which bandwidth adjustment should be made in upward or downward direction. This sub-TLV specify the value for Up-Adjustment-Interval and Down-Adjustment-Interval when they are the same and the Down- Adjustment-Interval sub-TLV is not included. 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=2 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjustment-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adjustment-Interval sub-TLV format The Type is 2, Length is 4 octets, and the value comprises of - o Adjustment-Interval: The 4-octet time interval for bandwidth adjustments. The valid range is from 1 to 604800 (7 days), in seconds. The default value is 86400 seconds (1 day). The adjustment-interval parameter MUST NOT be less than the sample-interval, otherwise the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.2.2. Down-Adjustment-Interval sub-TLV The Down-Adjustment-Interval sub-TLV specifies a time interval in Dhody, et al. Expires March 29, 2020 [Page 14] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 seconds at which bandwidth adjustment should be made when MaxAvgBw is less than the current bandwidth reservation of the LSP. This parameter overrides the Adjustment-Interval for the downward trend. This sub-TLV is used only when there is a need for different adjustment intervals in the upward and downward directions. 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=3 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Down-Adjustment-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Down-Adjustment-Interval sub-TLV format The Type is 3, Length is 4 octets, and the value comprises of - o Down-Adjustment-Interval: The 4-octet time interval for downward bandwidth adjustments. The valid range is from 1 to 604800 (7 days), in seconds. The default value equals the adjustment- interval. The down-adjustment-interval parameter MUST NOT be less than the sample-interval, otherwise the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.3. Adjustment Thresholds The sub-TLVs in this section are encoded to inform the PCEP peer of the adjustment threshold parameters. An implementation MAY include both sub-TLVs for the absolute value and the percentage, in which case the bandwidth is adjusted when either of the adjustment threshold conditions are met. The Adjustment-Threshold sub-TLV specifies the threshold for both upward (Up-Adjustment-Threshold) and downward (Down-Adjustment-Threshold) trend. If the operator would like to use a different adjustment threshold during the downward trend, the Down-Adjustment-Threshold sub-TLV is included. Similarly, the Adjustment-Threshold-Percentage sub-TLV specifies the threshold percentage for both upward and downward trend. If the operator would like to use a different adjustment threshold percentage during the downward trend, the Down-Adjustment-Threshold-Percentage sub-TLV is included. It is worth noting that regardless of how the threshold are set, the adjustment will not be made until at least one sample- interval simply because no sample will be made on which to base a comparison with a threshold. 5.2.3.1. Adjustment-Threshold sub-TLV Dhody, et al. Expires March 29, 2020 [Page 15] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 The Adjustment-Threshold sub-TLV is used to decide when the LSP bandwidth should be adjusted in upward or downward direction. This sub-TLV specify the absolute value for Up-Adjustment-Threshold and Down-Adjustment-Threshold when they are the same and the Down- Adjustment-Threshold sub-TLV is not included. 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=4 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjustment-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adjustment-Threshold sub-TLV format The Type is 4, Length is 4 octets, and the value comprises of - o Adjustment-Threshold: The absolute Adjustment-Threshold bandwidth difference value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The default adjustment-threshold value is not set. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. If the modulus of difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV The Adjustment-Threshold-Percentage sub-TLV is used to decide when the LSP bandwidth should be adjusted in upward or downward direction. This sub-TLV specify the percentage value for Up-Adjustment-Threshold and Down-Adjustment-Threshold when they are the same and the Down- Adjustment-Threshold-Percentage sub-TLV is not included. 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=5 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Percentage | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Threshold | Dhody, et al. Expires March 29, 2020 [Page 16] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adjustment-Threshold-Percentage sub-TLV format The Type is 5, Length is 8 octets, and the value comprises of - o Reserved: MUST be set to zero on transmission and MUST be ignored on receipt. o Percentage: The Adjustment-Threshold value (7 bits), encoded in percentage (an integer from 1 to 100). The value 0 is considered to be invalid. The default value is 5 percent. o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The increase or decrease of the LSP bandwidth MUST be at least or above the minimum-threshold before the bandwidth adjustment is made. The default value is 0. If the percentage absolute difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold percentage, and the difference in the bandwidth is at least or above the Minimum-Threshold, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.3.3. Down-Adjustment-Threshold sub-TLV The Down-Adjustment-Threshold sub-TLV is used to decide when the LSP bandwidth should be adjusted when MaxAvgBw is lesser than the current bandwidth reservation. This parameter overrides the Adjustment- Threshold for the downward trend. This sub-TLV is used only when there is a need for different threshold in the upward and downward directions. 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=6 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Down-Adjustment-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Down-Adjustment-Threshold sub-TLV format The Type is 6, Length is 4 octets, and the value comprises of - Dhody, et al. Expires March 29, 2020 [Page 17] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 o Down-Adjustment-Threshold: The absolute Down-Adjustment-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The default value equals the adjustment-threshold. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. If the difference between current bandwidth reservation and the current MaxAvgBw is greater than or equal to the threshold value, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV The Down-Adjustment-Threshold-Percentage sub-TLV is used to decide when the LSP bandwidth should be adjusted when MaxAvgBw is lesser than the current bandwidth reservation. This parameter overrides the Adjustment-Threshold-Percentage for the downward trend. This sub-TLV is used only when there is a need for different threshold percentage in the upward and downward directions. 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=7 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Percentage | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Down-Adjustment-Threshold-Percentage sub-TLV format The Type is 7, Length is 8 octets, and the value comprises of - o Reserved: MUST be set to zero on transmission and MUST be ignored on receipt. o Percentage: The Down-Adjustment-Threshold value (7 bits), encoded in percentage (an integer from 1 to 100). The value 0 is considered to be invalid. The default value equals the adjustment-threshold-percentage. o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The decrease of the LSP bandwidth MUST be at least or above the minimum-threshold before the Dhody, et al. Expires March 29, 2020 [Page 18] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 bandwidth adjustment is made. The default value equals the minimum-threshold for the adjustment-threshold-percentage. If the percentage difference between the current bandwidth reservation and the current MaxAvgBw is greater than or equal to the threshold percentage, and the difference in the bandwidth is at least or above the Minimum-Threshold, the LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.4. Minimum and Maximum Bandwidth Values 5.2.4.1. Minimum-Bandwidth sub-TLV The Minimum-Bandwidth sub-TLV specify the minimum bandwidth allowed for the LSP, and is expressed in bytes per second. The LSP bandwidth cannot be adjusted below the minimum bandwidth value. 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=8 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Minimum-Bandwidth sub-TLV format The Type is 8, Length is 4 octets, and the value comprises of - o Minimum-Bandwidth: The 4-octet bandwidth value encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The default minimum-bandwidth value is set to 0. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.4.2. Maximum-Bandwidth sub-TLV The Maximum-Bandwidth sub-TLV specify the maximum bandwidth allowed for the LSP, and is expressed in bytes per second. The LSP bandwidth cannot be adjusted above the maximum bandwidth value. 0 1 2 3 Dhody, et al. Expires March 29, 2020 [Page 19] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 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=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum-Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum-Bandwidth sub-TLV format The Type is 9, Length is 4 octets, and the value comprises of - o Maximum-Bandwidth: The 4-octet bandwidth value encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The default maximum-bandwidth value is not set. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.5. Overflow and Underflow Conditions The sub-TLVs in this section are encoded to inform the PCEP peer the overflow and underflow threshold parameters. An implementation MAY include sub-TLVs for an absolute value and/or a percentage for the threshold, in which case the bandwidth is immediately adjusted when either of the threshold conditions is met consecutively for the given count (as long as the difference in the bandwidth is at least or above the Minimum-Threshold). By default, the threshold values for overflow and underflow conditions are not set. 5.2.5.1. Overflow-Threshold sub-TLV The Overflow-Threshold sub-TLV is used to decide if the LSP bandwidth should be adjusted immediately. 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=10 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Overflow-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Overflow-Threshold sub-TLV format Dhody, et al. Expires March 29, 2020 [Page 20] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 The Type is 10, Length is 8 octets, and the value comprises of - o Reserved: MUST be set to zero on transmission and MUST be ignored on receipt. o Count: The Overflow-Count value (5 bits), encoded in integer. The value 0 is considered to be invalid. The number of consecutive samples for which the overflow condition MUST be met for the LSP bandwidth to be immediately adjusted to the current bandwidth demand, bypassing the (up) adjustment-interval. o Overflow-Threshold: The absolute Overflow-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. If the difference of the current MaxAvgBw from the current bandwidth reservation is greater than or equal to the threshold value, the overflow condition is met. In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.5.2. Overflow-Threshold-Percentage sub-TLV The Overflow-Threshold-Percentage sub-TLV is used to decide if the LSP bandwidth should be adjusted immediately. 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=11 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Percentage | Reserved | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Overflow-Threshold-Percentage sub-TLV format The Type is 11, Length is 8 octets, and the value comprises of - o Percentage: The Overflow-Threshold value (7 bits), encoded in percentage (an integer from 1 to 100). The value 0 is considered to be invalid. If the percentage increase of the current MaxAvgBw from the current bandwidth reservation is greater than or equal to the threshold percentage, the overflow condition is met. o Reserved: MUST be set to zero on transmission and MUST be ignored Dhody, et al. Expires March 29, 2020 [Page 21] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 on receipt. o Count: The Overflow-Count value (5 bits), encoded in integer. The value 0 is considered to be invalid. The number of consecutive samples for which the overflow condition MUST be met for the LSP bandwidth to be immediately adjusted to the current bandwidth demand, bypassing the (up) adjustment-interval. o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The increase of the LSP bandwidth MUST be at least or above the minimum-threshold before the bandwidth adjustment is made. In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.5.3. Underflow-Threshold sub-TLV The Underflow-Threshold sub-TLV is used to decide if the LSP bandwidth should be adjusted immediately. 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=12 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Underflow-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Underflow-Threshold sub-TLV format The Type is 12, Length is 8 octets, and the value comprises of - o Reserved: MUST be set to zero on transmission and MUST be ignored on receipt. o Count: The Underflow-Count value (5 bits), encoded in integer. The value 0 is considered to be invalid. The number of consecutive samples for which the underflow condition MUST be met for the LSP bandwidth to be immediately adjusted to the current bandwidth demand, bypassing the down-adjustment-interval. o Underflow-Threshold: The absolute Underflow-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. Refer to Section Dhody, et al. Expires March 29, 2020 [Page 22] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 3.1.2 of [RFC3471] for a table of commonly used values. If the difference of the current MaxAvgBw from the current bandwidth reservation is greater than or equal to the threshold value, the underflow condition is met. In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.2.5.4. Underflow-Threshold-Percentage sub-TLV The Underflow-Threshold-Percentage sub-TLV is used to decide if the LSP bandwidth should be adjusted immediately. 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=13 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Percentage | Reserved | Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Underflow-Threshold-Percentage sub-TLV format The Type is 13, Length is 8 octets, and the value comprises of - o Percentage: The Underflow-Threshold value (7 bits), encoded in percentage (an integer from 1 to 100). The value 0 is considered to be invalid. If the percentage decrease of the current MaxAvgBw from the current bandwidth reservation is greater than or equal to the threshold percentage, the underflow condition is met. o Reserved: MUST be set to zero on transmission and MUST be ignored on receipt. o Count: The Underflow-Count value (5 bits), encoded in integer. The value 0 is considered to be invalid. The number of consecutive samples for which the underflow condition MUST be met for the LSP bandwidth to be immediately adjusted to the current bandwidth demand, bypassing the down-adjustment-interval. o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. The decrease of the LSP bandwidth MUST be at least or above the minimum-threshold before the bandwidth adjustment is made. Dhody, et al. Expires March 29, 2020 [Page 23] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 In case of an invalid value, the Sub-TLV MUST be ignored and the previous value is maintained. 5.3. BANDWIDTH Object As per [RFC5440], the BANDWIDTH object (Object-Class value 5) is defined with two Object-Type values as following: o Requested Bandwidth: BANDWIDTH Object-Type value is 1. o Re-optimization Bandwidth: Bandwidth of an existing TE LSP for which a re-optimization is requested. BANDWIDTH Object-Type value is 2. The PCC reports the calculated bandwidth to be adjusted (MaxAvgBw) to the Stateful PCE using the existing 'Requested Bandwidth' with BANDWIDTH Object-Type as 1. The reporting of the 're-optimization bandwidth' with BANDWIDTH Object-Type as 2 is not required as the Stateful PCE is aware of the existing LSP bandwidth. 5.4. The PCInitiate Message A PCInitiate message is a PCEP message sent by a PCE to a PCC to trigger LSP instantiation or deletion [RFC8281]. For the PCE-Initiated LSP with Auto-Bandwidth feature enabled, AUTO- BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the PCInitiate message. The Routing Backus-Naur Format (RBNF) definition of the PCInitiate message [RFC8281] is unchanged by this document. 5.5. The PCUpd Message A PCUpd message is a PCEP message sent by a PCE to a PCC to update the LSP parameters [RFC8231]. For PCE-Initiated LSPs with Auto-Bandwidth feature enabled, AUTO- BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the PCUpd message. The PCE can send this TLV to direct the PCC to change the auto-bandwidth parameters. The RBNF definition of the PCUpd message [RFC8231] is unchanged by this document. 5.6. The PCRpt Message The PCRpt message [RFC8231] is a PCEP message sent by a PCC to a PCE Dhody, et al. Expires March 29, 2020 [Page 24] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 to report the status of one or more LSPs. For PCE-Initiated LSPs [RFC8281], the PCC creates the LSP using the attributes communicated by the PCE, and using the local values for the unspecified parameters. After the successful instantiation of the LSP, PCC automatically delegates the LSP to the PCE and generates a PCRpt message to provide the status report for the LSP. For both PCE-Initiated and PCC-Initiated LSPs, when the LSP is delegated to a PCE for the very first time as well as after the successful delegation, the BANDWIDTH object of type 1 is used to specify the requested bandwidth in the PCRpt message. The RBNF definition of the PCRpt message [RFC8231] is unchanged by this document. 5.7. The PCNtf Message As per [RFC5440], the PCEP Notification message (PCNtf) can be sent by a PCEP speaker to notify its peer of a specific event. A PCEP speaker (PCE or PCC) SHOULD notify its PCEP peer (PCC or PCE) when it is in overwhelmed state due to the auto-bandwidth feature. An implementation needs to make an attempt to send this notification (when overwhelmed by auto-bandwidth adjustments) unless sending this notification would only serve to increase the load further. Note that when the notification is not received the PCEP speaker would continue to request bandwidth adjustments even when they could not be handled in a timely fashion. Upon receipt of auto-bandwidth overwhelm notification, the peer SHOULD NOT send any PCEP messages related to auto-bandwidth adjustment. If a PCEP message related to auto-bandwidth adjustment is received during in overwhelmed state, it MUST be ignored. o When a PCEP speaker is overwhelmed, it SHOULD notify its peer by sending a PCNtf message with Notification-Type = TBD3 (Auto- bandwidth Overwhelm State) and Notification-Value = 1 (Entering auto-bandwidth overwhelm state). Optionally, OVERLOADED-DURATION TLV [RFC5440] MAY be included that specifies the time period during which no further PCEP messages related to auto-bandwidth adjustment should be sent. o When the PCEP speaker is no longer in the overwhelm state and is available to process the auto-bandwidth adjustments, it SHOULD notify its peers by sending a PCNtf message with Notification Type = TBD3 (Auto-bandwidth Overwhelm State) and Notification Value = 2 (Clearing auto-bandwidth overwhelm state). A PCEP speaker SHOULD Dhody, et al. Expires March 29, 2020 [Page 25] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 send such notification to all peers to with a Notification message (Notification-Type=TBD3, Notification-Value=1) was sent earlier unless an OVERLOADED-DURATION TLV was included and the PCEP speakers wishes for the peer to wait for the expiration of that period of time before receiving further PCEP messages related to auto-bandwidth adjustment. When Auto-Bandwidth feature is deployed, a PCE can send this notification to PCC when a PCC is reporting frequent auto-bandwidth adjustments. If a PCC is overwhelmed with re-signaling, it can also notify the PCE to not adjust the LSP bandwidth while in overwhelm state. Some dampening notification procedure (as per [RFC5440]) to avoid oscillations of the overwhelm state is RECOMMENDED. On receipt of an auto-bandwidth overwhelm notification from the PCE, a PCC should consider the impact on the entire network. Moving the delegations of auto-bandwidth enabled LSP to another PCE could cause further overloading. 6. Manageability Considerations 6.1. Control of Function and Policy The Auto-Bandwidth feature SHOULD be controlled per LSP (at PCC (head-end of the LSP) or PCE) and the values for auto-bandwidth parameters e.g. sample-interval, adjustment-interval (up/down), minimum-bandwidth, maximum-bandwidth, adjustment-threshold (up/down) SHOULD be configurable by an operator. The Maximum-Bandwidth (and Minimum-Bandwidth) should be set to acceptable limit to avoid impact on the rest of the MPLS-TE domain. The operator should make sure that the Overflow-Threshold is greater than or at least equal to the Up-Adjustment-Threshold. And similarly, make sure that the Underflow-Threshold is greater than or at least equal to the Down-Adjustment-Threshold. 6.2. Information and Data Models A MIB module for gathering operational information about PCEP is defined in [RFC7420]. Additionally, the YANG module defined in [I-D.ietf-pce-pcep-yang] provides for both configuration of PCEP as well as operational management. These could be enhanced to provide controls and indicators for support of auto-bandwidth feature. Support for various configuration knobs as well as counters of messages sent/received containing the TLVs defined in this document Dhody, et al. Expires March 29, 2020 [Page 26] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 could be added. 6.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]. 6.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]. In case of an invalid value, the Sub-TLV would get ignored and the previous value would be maintained. In such case the implementation SHOULD log the event. 6.5. Requirements On Other Protocols The mechanisms defined in this document do not add any new requirements on other protocols. 6.6. Impact On Network Operations In order to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit to be placed on the number of LSPs that can be enabled with auto-bandwidth feature. For each LSP enabled with auto-bandwidth feature there is an extra load on PCC, as it needs to monitor the traffic and report the calculated bandwidth to be adjusted to the PCE. The PCE further re-compute paths based on the requested bandwidth and update the path to the PCC, which in turns triggers the re-signaling of the path. All these steps adds extra load and churn in the network and thus operator needs to take due care while enabling this features on a number of LSPs. An implementation MAY allow a limit to be placed on the rate of auto- bandwidth related messages sent by a PCEP speaker and received by a peer. An implementation SHOULD also allow sending a notification when a PCEP speaker is overwhelmed or the rate of messages reach a threshold. Due care is required by the operator if a Sample-Interval value significantly smaller than the default (5 minute) is used, as a small Sample-Interval values, e.g., 1 minute or less, could cause undesirable interactions with transport protocols. These undesirable interactions result from providing insufficient time for transport protocol reactions to a prior bandwidth adjustment to settle out Dhody, et al. Expires March 29, 2020 [Page 27] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 before bandwidth samples are taken for the next bandwidth adjustment. 7. Security Considerations This document defines AUTO-BANDWIDTH-CAPABILITY TLV and AUTO- BANDWIDTH-ATTRIBUTES sub-TLVs which do not add any substantial new security concerns beyond those already discussed in [RFC8231] and [RFC8281] for stateful PCE operations. As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in BCP 195 [RFC7525] (unless explicitly set aside in [RFC8253]). Incorrect auto-bandwidth parameters in the AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs could have an adverse effect on the LSP as well as on the network. 8. IANA Considerations 8.1. PCEP TLV Type Indicators This document defines the following new PCEP TLVs; IANA is requested to make the following allocations from the "PCEP TLV Type Indicators" sub-registry of the PCEP Numbers registry, as follows: Value Name Reference ----------------------------------------------------------------- TBD2 AUTO-BANDWIDTH-CAPABILITY [This document] TBD1 AUTO-BANDWIDTH-ATTRIBUTES [This document] 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field IANA is requested to create a sub-registry to manage the Flag field of the AUTO-BANDWIDTH-CAPABILITY TLV within the "Path Computation Element Protocol (PCEP) Numbers" registry. New bit numbers are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The initial contents of the sub-registry are empty, with all bits Dhody, et al. Expires March 29, 2020 [Page 28] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 marked unassigned 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs. IANA is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the type indicator space for sub-TLVs of the AUTO-BANDWIDTH-ATTRIBUTES TLV. The valid range of values in the registry is 0-65535. IANA is requested to initialize the registry with the following values. All other values in the registry should be marked as "Unassigned". IANA is requested to set the registration procedure for this registry to read as follows: 0-65503 IETF Review 65504-65535 Experimental Use This document defines the following types: Type Name Reference ----------------------------------------------------------------- 0 Reserved [This document] 1 Sample-Interval sub-TLV [This document] 2 Adjustment-Interval sub-TLV [This document] 3 Down-Adjustment-Interval sub-TLV [This document] 4 Adjustment-Threshold sub-TLV [This document] 5 Adjustment-Threshold-Percentage sub-TLV [This document] 6 Down-Adjustment-Threshold sub-TLV [This document] 7 Down-Adjustment-Threshold-Percentage sub-TLV [This document] 8 Minimum-Bandwidth sub-TLV [This document] 9 Maximum-Bandwidth sub-TLV [This document] 10 Overflow-Threshold sub-TLV [This document] 11 Overflow-Threshold-Percentage sub-TLV [This document] 12 Underflow-Threshold sub-TLV [This document] 13 Underflow-Threshold-Percentage sub-TLV [This document] 14- Unassigned [This document] 65503 8.4. Error Object This document defines a new Error-Value for PCErr message of Error- Type 19 (Invalid Operation) [RFC8231]. IANA is requested to allocate new error-value within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry, as follows: Error-Type Meaning & error values Reference Dhody, et al. Expires March 29, 2020 [Page 29] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 ----------------------------------------------------------------- 19 Invalid Operations Error-Value = TBD4: [This document] Auto-Bandwidth Capability was not Advertised 8.5. Notification Object IANA is requested to allocate new Notification Type and Notification Values within the "Notification Object" sub-registry of the PCEP Numbers registry, as follows: Type Meaning Reference ----------------------------------------------------------------- TBD3 Auto-Bandwidth Overwhelm State [This document] Notification-value=1: Entering Auto-Bandwidth overwhelm state Notification-value=2: Clearing Auto-Bandwidth overwhelm state Dhody, et al. Expires March 29, 2020 [Page 30] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [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. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8253] Lopez, D., Dios, O., Wu, W., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, October 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985. 9.2. Informative References Dhody, et al. Expires March 29, 2020 [Page 31] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 [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, . [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [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, December 2014. [RFC8051] Zhang, X. and I. Minei, "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, January 2017. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang (work in progress). Dhody, et al. Expires March 29, 2020 [Page 32] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 Acknowledgments Authors would like to thank Robert Varga, Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika, JP Vasseur, Himanshu Shah, Jonathan Hardwick and Adrian Farrel for their useful comments and suggestions. Thanks to Daniel Franke, Joe Clarke, David Black, and Erik Kline for the directorate reviews. Thanks to Mirja Kuhlewind, Barry Leiba, Benjamin Kaduk, and Roman Danyliw for the IESG review. Contributors' Addresses He Zekun Tencent Holdings Ltd, Shenzhen P.R.China Email: kinghe@tencent.com Xian Zhang Huawei Technologies Research Area F3-1B, Huawei Industrial Base, Shenzhen, 518129 China Phone: +86-755-28972645 Email: zhang.xian@huawei.com Young Lee SKKU Email: younglee.tx@gmail.com Dhody, et al. Expires March 29, 2020 [Page 33] Internet-Draft Auto-Bandwidth with Stateful PCE September 26, 2019 Authors' Addresses Dhruv Dhody (editor) Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Udayasree Palle Individual Contributor Email: udayasreereddy@gmail.com Ravi Singh Individual Contributor Email: ravi.singh.ietf@gmail.com Luyuan Fang Expedia, Inc. USA Email: luyuanf@gmail.com Dhody, et al. Expires March 29, 2020 [Page 34] ./draft-ietf-mpls-egress-protection-framework-07.txt0000644000764400076440000022141713520316533022007 0ustar iustyiusty Internet Engineering Task Force Yimin Shen Internet-Draft Minto Jeyananth Intended status: Standards Track Juniper Networks Expires: February 1, 2020 Bruno Decraene Orange Hannes Gredler RtBrick Inc Carsten Michel Deutsche Telekom Huaimo Chen Huawei Technologies Co., Ltd. July 31, 2019 MPLS Egress Protection Framework draft-ietf-mpls-egress-protection-framework-07 Abstract This document specifies a fast reroute framework for protecting IP/ MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of point of local repair (PLR), protector, and backup egress router, and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR, and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control plane protocols converge on the topology changes due to the egress failure. 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 https://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 1, 2020. Yimin Shen, et al. Expires February 1, 2020 [Page 1] Internet-Draft MPLS Egress Protection Framework July 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Specification of Requirements . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 5.2. Egress node failure and detection . . . . . . . . . . . . 8 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 5.5. Egress-protected tunnel and service . . . . . . . . . . . 11 5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 5.7. Context ID, context label, and context-based forwarding . 12 5.8. Advertisement and path resolution for context ID . . . . 13 5.9. Egress-protection bypass tunnel establishment . . . . . . 15 5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16 5.11. Service label distribution from egress router to protector . . . . . . . . . . . . . . . . . . . . . . . . 16 5.12. Centralized protector mode . . . . . . . . . . . . . . . 17 6. Egress link protection . . . . . . . . . . . . . . . . . . . 19 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Operational Considerations . . . . . . . . . . . . . . . . . 22 9. General context-based forwarding . . . . . . . . . . . . . . 23 10. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23 10.1. Egress node protection . . . . . . . . . . . . . . . . . 25 10.2. Egress link protection . . . . . . . . . . . . . . . . . 25 10.3. Global repair . . . . . . . . . . . . . . . . . . . . . 26 10.4. Other modes of VPN label allocation . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 Yimin Shen, et al. Expires February 1, 2020 [Page 2] Internet-Draft MPLS Egress Protection Framework July 2019 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction In MPLS networks, label switched paths (LSPs) are widely used as transport tunnels to carry IP and MPLS services across MPLS domains. Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, hierarchical LSPs, and others. In general, a tunnel may carry multiple services of one or multiple types, if the tunnel satisfies both individual and aggregate requirements (e.g., CoS, QoS) of these services. The egress router of the tunnel hosts the service instances of the services. An MPLS service instance forwards service packets via an egress link to the service destination, based on a service label. An IP service instance does the same based on a service IP address. The egress link is often called a PE-CE (provider edge - customer edge) link or attachment circuit (AC). Today, local-repair-based fast reroute mechanisms ([RFC4090], [RFC5286], [RFC7490], and [RFC7812]) have been widely deployed to protect MPLS tunnels against transit link/node failures, with traffic restoration time in the order of tens of milliseconds. Local repair refers to the scenario where the router upstream to an anticipated failure, a.k.a. PLR (point of local repair), pre-establishes a bypass tunnel to the router downstream of the failure, a.k.a. MP (merge point), pre-installs the forwarding state of the bypass tunnel in the data plane, and uses a rapid mechanism (e.g., link layer OAM, BFD, and others) to locally detect the failure in the data plane. When the failure occurs, the PLR reroutes traffic through the bypass tunnel to the MP, allowing the traffic to continue to flow to the tunnel's egress router. This document specifies a fast reroute framework for egress node and egress link protection. Similar to transit link/node protection, this framework also relies on a PLR to perform local failure detection and local repair. In egress node protection, the PLR is the penultimate-hop router of a tunnel. In egress link protection, the PLR is the egress router of the tunnel. The framework further uses a so-called "protector" to serve as the tailend of a bypass tunnel. The protector is a router that hosts "protection service instances" and has its own connectivity or paths to service destinations. When a PLR does local repair, the protector performs "context label switching" for rerouted MPLS service packets and "context IP forwarding" for rerouted IP service packets, to allow the service packets to continue to reach the service destinations. Yimin Shen, et al. Expires February 1, 2020 [Page 3] Internet-Draft MPLS Egress Protection Framework July 2019 This framework considers an egress node failure as a failure of a tunnel, and a failure of all the services carried by the tunnel, as service packets can no longer reach the service instances on the egress router. Therefore, the framework addresses egress node protection at both tunnel level and service level simultaneously. Likewise, the framework considers an egress link failure as a failure of all the services traversing the link, and addresses egress link protection at the service level. This framework requires that the destination (a CE or site) of a service MUST be dual-homed or have dual paths to an MPLS network, via two MPLS edge routers. One of the routers is the egress router of the service's transport tunnel, and the other is a backup egress router which hosts a "backup service instance". In the "co-located" protector mode in this document, the backup egress router serves as the protector, and hence the backup service instance acts as the protection service instance. In the "centralized" protector mode (Section 5.12), the protector and the backup egress router are decoupled, and the protection service instance and the backup service instance are hosted separately by the two routers. The framework is described by mainly referring to P2P (point-to- point) tunnels. However, it is equally applicable to P2MP (point-to- multipoint), MP2P (multipoint-to-point), and MP2MP (multipoint-to- multipoint) tunnels, as the sub-LSPs of these tunnels can be viewed as P2P tunnels. The framework is a multi-service and multi-transport framework. It assumes a generic model where each service is comprised of a common set of components, including a service instance, a service label, a service label distribution protocol, and an MPLS transport tunnel. The framework also assumes the service label to be downstream assigned, i.e., assigned by an egress router. Therefore, the framework is generally applicable to most existing and future services. However, there are services with certain modes, where a protector is unable to pre-establish forwarding state for egress protection, or a PLR is not allowed to reroute traffic to other routers in order to avoid traffic duplication, e.g., the broadcast, multicast, and unknown unicast traffic in VPLS and EVPN. These cases are left for future study. Services which use upstream-assigned service labels are also out of scope of this document and left for future study. The framework does not require extensions for the existing signaling and label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS tunnels. It assumes transport tunnels and bypass tunnels to be established by using the generic procedures provided by the protocols. On the other hand, it does not preclude extensions to the Yimin Shen, et al. Expires February 1, 2020 [Page 4] Internet-Draft MPLS Egress Protection Framework July 2019 protocols which may facilitate the procedures. One example of such extension is [RFC8400]. The framework does see the need for extensions of IGPs and service label distribution protocols in some procedures, particularly for supporting protection establishment and context label switching. This document provides guidelines for these extensions, but leaves the specific details to separate documents. The framework is intended to complement control-plane convergence and global repair. Control-plane convergence relies on control protocols to react on the topology changes due to a failure. Global repair relies an ingress router to remotely detect a failure and switch traffic to an alternative path. An example of global repair is the BGP Prefix Independent Convergence mechanism [BGP-PIC] for BGP established services. Compared with these mechanisms, this framework is considered as faster in traffic restoration, due to the nature of local failure detection and local repair. It is RECOMMENDED that the framework be used in conjunction with control-plane convergence or global repair, in order to take the advantages of both approaches. That is, the framework provides fast and temporary repair, while control-plane convergence or global repair provides ultimate and permanent repair. 2. 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] and [RFC8174]. 3. Terminology Egress router - A router at the egress endpoint of a tunnel. It hosts service instances for all the services carried by the tunnel, and has connectivity with the destinations of the services. Egress node failure - A failure of an egress router. Egress link failure - A failure of the egress link (e.g., PE-CE link, attachment circuit) of a service. Egress failure - An egress node failure or an egress link failure. Egress-protected tunnel - A tunnel whose egress router is protected by a mechanism according to this framework. The egress router is hence called a protected egress router. Yimin Shen, et al. Expires February 1, 2020 [Page 5] Internet-Draft MPLS Egress Protection Framework July 2019 Egress-protected service - An IP or MPLS service which is carried by an egress-protected tunnel, and hence protected by a mechanism according to this framework. Backup egress router - Given an egress-protected tunnel and its egress router, this is another router which has connectivity with all or a subset of the destinations of the egress-protected services carried by the egress-protected tunnel. Backup service instance - A service instance which is hosted by a backup egress router, and corresponding to an egress-protected service on a protected egress router. Protector - A role acted by a router as an alternate of a protected egress router, to handle service packets in the event of an egress failure. A protector may be physically co-located with or decoupled from a backup egress router, depending on the co-located or centralized protector mode. Protection service instance - A service instance hosted by a protector, corresponding to the service instance of an egress- protected service on a protected egress router. A protection service instance is a backup service instance, if the protector is co-located with a backup egress router. PLR - A router at the point of local repair. In egress node protection, it is the penultimate-hop router on an egress-protected tunnel. In egress link protection, it is the egress router of the egress-protected tunnel. Protected egress {E, P} - A virtual node consisting of an ordered pair of egress router E and protector P. It serves as the virtual destination of an egress-protected tunnel, and as the virtual location of the egress-protected services carried by the tunnel. Context identifier (ID) - A globally unique IP address assigned to a protected egress {E, P}. Context label - A non-reserved label assigned to a context ID by a protector. Egress-protection bypass tunnel - A tunnel used to reroute service packets around an egress failure. Co-located protector mode - The scenario where a protector and a backup egress router are co-located as one router, and hence each backup service instance serves as a protection service instance. Yimin Shen, et al. Expires February 1, 2020 [Page 6] Internet-Draft MPLS Egress Protection Framework July 2019 Centralized protector mode - The scenario where a protector is a dedicated router, and is decoupled from backup egress routers. Context label switching - Label switching performed by a protector, in the label space of an egress router indicated by a context label. Context IP forwarding - IP forwarding performed by a protector, in the IP address space of an egress router indicated by a context label. 4. Requirements This document considers the following as the design requirements of this egress protection framework. o The framework must support P2P tunnels. It should equally support P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P tunnel. o The framework must support multi-service and multi-transport networks. It must accommodate existing and future signaling and label-distribution protocols of tunnels and bypass tunnels, including RSVP, LDP, BGP, IGP, segment routing, and others. It must also accommodate existing and future IP/MPLS services, including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and others. It MUST provide a general solution for networks where different types of services and tunnels co-exist. o The framework must consider minimizing disruption during deployment. It should only involve routers close to egress, and be transparent to ingress routers and other transit routers. o In egress node protection, for scalability and performance reasons, a PLR must be agnostic to services and service labels. It must maintain bypass tunnels and bypass forwarding state on a per-transport-tunnel basis, rather than on a per-service- destination or per-service-label basis. It should also support bypass tunnel sharing between transport tunnels. o A PLR must be able to use its local visibility or information of routing or TE topology to compute or resolve a path for a bypass tunnel. o A protector must be able to perform context label switching for rerouted MPLS service packets, based on service label(s) assigned by an egress router. It must be able to perform context IP forwarding for rerouted IP service packets, in the public or private IP address space used by an egress router. Yimin Shen, et al. Expires February 1, 2020 [Page 7] Internet-Draft MPLS Egress Protection Framework July 2019 o The framework must be able to work seamlessly with transit link/ node protection mechanisms to achieve end-to-end coverage. o The framework must be able to work in conjunction with global repair and control plane convergence. 5. Egress node protection 5.1. Reference topology This document refers to the following topology when describing the procedures of egress node protection. services 1, ..., N =====================================> tunnel I ------ R1 ------- PLR --------------- E ---- ingress penultimate-hop egress \ | . (primary \ | . service \ | . instances) \ | . \ | . \ service | . destinations | . / (CEs, sites) | . / | . bypass / | . tunnel / | . / | ............... / R2 --------------- P ---- protector (protection service instances) Figure 1 5.2. Egress node failure and detection An egress node failure refers to the failure of an MPLS tunnel's egress router. At the service level, it is also a service instance failure for each IP/MPLS service carried by the tunnel. An egress node failure can be detected by an adjacent router (i.e., PLR in this framework) through a node liveness detection mechanism, Yimin Shen, et al. Expires February 1, 2020 [Page 8] Internet-Draft MPLS Egress Protection Framework July 2019 or a mechanism based on a collective failure of all the links to that node. The mechanisms MUST be reasonably fast, i.e., faster than control plane failure detection and remote failure detection. Otherwise, local repair will not be able to provide much benefit compared to control plane convergence or global repair. In general, the speed, accuracy, and reliability of a failure detection mechanism are the key factors to decide its applicability in egress node protection. This document provides the following guidelines for network operators to choose a proper type of protection on a PLR. o If the PLR has a mechanism to detect and differentiate a link failure (of the link between the PLR and the egress node) and an egress node failure, it SHOULD set up both link protection and egress node protection, and trigger one and only one protection upon a corresponding failure. o If the PLR has a fast mechanism to detect a link failure and an egress node failure, but cannot distinguish them; or, if the PLR has a fast mechanism to detect a link failure only, but not an egress node failure, the PLR has two options: 1. It MAY set up link protection only, and leave the egress node failure to be handled by global repair and control plane convergence. 2. It MAY set up egress node protection only, and treat a link failure as a trigger for the egress node protection. The assumption is that treating a link failure as an egress node failure MUST NOT have a negative impact on services. Otherwise, it SHOULD adopt the previous option. 5.3. Protector and PLR A router is assigned to the "protector" role to protect a tunnel and the services carried by the tunnel against an egress node failure. The protector is responsible for hosting a protection service instance for each protected service, serving as the tailend of a bypass tunnel, and performing context label switching and/or context IP forwarding for rerouted service packets. A tunnel is protected by only one protector. Multiple tunnels to a given egress router may be protected by a common protector or different protectors. A protector may protect multiple tunnels with a common egress router or different egress routers. For each tunnel, its penultimate-hop router acts as a PLR. The PLR pre-establishes a bypass tunnel to the protector, and pre-installs bypass forwarding state in the data plane. Upon detection of an Yimin Shen, et al. Expires February 1, 2020 [Page 9] Internet-Draft MPLS Egress Protection Framework July 2019 egress node failure, the PLR reroutes all the service packets received on the tunnel though the bypass tunnel to the protector. For MPLS service packets, the PLR keeps service labels intact in the packets. The protector in turn forwards the service packets towards the ultimate service destinations. Specifically, it performs context label switching for MPLS service packets, based on the service labels assigned by the protected egress router; it performs context IP forwarding for IP service packets, based on their destination addresses. The protector MUST have its own connectivity with each service destination, via a direct link or a multi-hop path, which MUST NOT traverse the protected egress router or be affected by the egress node failure. This also means that each service destination MUST be dual-homed or have dual paths to the egress router and a backup egress router which may serve as the protector. Each protection service instance on the protector relies on such connectivity to set up forwarding state for context label switching and context IP forwarding. 5.4. Protected egress This document introduces the notion of "protected egress" as a virtual node consisting of the egress router E of a tunnel and a protector P. It is denoted by an ordered pair of {E, P}, indicating the primary-and-protector relationship between the two routers. It serves as the virtual destination of the tunnel, and the virtual location of service instances for the services carried by the tunnel. The tunnel and services are considered as being "associated" with the protected egress {E, P}. A given egress router E may be the tailend of multiple tunnels. In general, the tunnels may be protected by multiple protectors, e.g., P1, P2, and so on, with each Pi protecting a subset of the tunnels. Thus, these routers form multiple protected egresses, i.e., {E, P1}, {E, P2}, and so on. Each tunnel is associated with one and only one protected egress {E, Pi}. All the services carried by the tunnel are then automatically associated with the protected egress {E, Pi}. Conversely, a service associated with a protected egress {E, Pi} MUST be carried by a tunnel associated with the protected egress {E, Pi}. This mapping MUST be ensured by the ingress router of the tunnel and the service (Section 5.5). Two routers X and Y may be protectors for each other. In this case, they form two distinct protected egresses {X, Y} and {Y, X}. Yimin Shen, et al. Expires February 1, 2020 [Page 10] Internet-Draft MPLS Egress Protection Framework July 2019 5.5. Egress-protected tunnel and service A tunnel, which is associated with a protected egress {E, P}, is called an egress-protected tunnel. It is associated with one and only one protected egress {E, P}. Multiple egress-protected tunnels may be associated with a given protected egress {E, P}. In this case, they share the common egress router and protector, but may or may not share a common ingress router, or a common PLR (i.e., penultimate-hop router). An egress-protected tunnel is considered as logically "destined" for its protected egress {E, P}. Its path MUST be resolved and established with E as the physical tailend. A service, which is associated with a protected egress {E, P}, is called an egress-protected service. The egress router E hosts the primary instance of the service, and the protector P hosts the protection instance of the service. An egress-protected service is associated with one and only one protected egress {E, P}. Multiple egress-protected services may be associated with a given protected egress {E, P}. In this case, these services share the common egress router and protector, but may or may not be carried by a common egress-protected tunnel or a common ingress router. An egress-protected service MUST be mapped to an egress-protected tunnel by its ingress router, based on the common protected egress {E, P} of the service and the tunnel. This is achieved by introducing the notion of "context ID" for protected egress {E, P}, as described in (Section 5.7). 5.6. Egress-protection bypass tunnel An egress-protected tunnel destined for a protected egress {E, P} MUST have a bypass tunnel from its PLR to the protector P. This bypass tunnel is called an egress-protection bypass tunnel. The bypass tunnel is considered as logically "destined" for the protected egress {E, P}. Due to its bypass nature, it MUST be established with P as the physical tailend and E as the node to avoid. The bypass tunnel MUST have the property that it MUST NOT be affected by the topology change caused by an egress node failure. An egress-protection bypass tunnel is associated with one and only one protected egress {E, P}. A PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}. Yimin Shen, et al. Expires February 1, 2020 [Page 11] Internet-Draft MPLS Egress Protection Framework July 2019 5.7. Context ID, context label, and context-based forwarding In this framework, a globally unique IPv4 or IPv6 address is assigned to a protected egress {E, P} as the identifier of the protected egress {E, P}. It is called a "context ID" due to its specific usage in context label switching and context IP forwarding on the protector. It is an IP address that is logically owned by both the egress router and the protector. For the egress router, it indicates the protector. For the protector, it indicates the egress router, particularly the egress router's forwarding context. For other routers in the network, it is an address reachable via both the egress router and the protector (Section 5.8), similar to an anycast address. The main purpose of a context ID is to coordinate ingress router, egress router, PLR and protector to establish egress protection. The procedures are described below, given an egress-protected service associated with a protected egress {E, P} with context ID. o If the service is an MPLS service, when E distributes a service label binding message to the ingress router, E attaches the context ID to the message. If the service is an IP service, when E advertises the service destination address to the ingress router, E attaches the context ID to the advertisement message. How the context ID is encoded in the messages is a choice of the service protocol. A protocol extension of a "context ID" object may be needed, if there is no existing mechanism for this purpose. o The ingress router uses the service's context ID as the destination to establish or resolve an egress-protected tunnel. The ingress router then maps the service to the tunnel for transportation. The semantics of the context ID is transparent to the ingress router. The ingress router only treats the context ID as an IP address of E, in the same manner as establishing or resolving a regular transport tunnel. o The context ID is conveyed to the PLR by the signaling protocol of the egress-protected tunnel, or learned by the PLR via an IGP (i.e., OSPF or ISIS) or a topology-driven label distribution protocol (e.g., LDP). The PLR uses the context ID as destination to establish or resolve an egress-protection bypass tunnel to P while avoiding E. o P maintains a dedicated label space and a dedicated IP address space for E. They are referred to as "E's label space" and "E's IP address space", respectively. P uses the context ID to identify the label space and IP address space. Yimin Shen, et al. Expires February 1, 2020 [Page 12] Internet-Draft MPLS Egress Protection Framework July 2019 o If the service is an MPLS service, E also distributes the service label binding message to P. This is the same label binding message that E advertises to the ingress router, which includes the context ID. Based on the context ID, P installs the service label in an MPLS forwarding table corresponding to E's label space. If the service is an IP service, P installs an IP route in an IP forwarding table corresponding to E's IP address space. In either case, the protection service instance on P constructs forwarding state for the label route or IP route based on P's own connectivity with the service's destination. o P assigns a non-reserved label to the context ID. In the data plane, this label represents the context ID and indicates E's label space and IP address space. Therefore, it is called a "context label". o The PLR may establish the egress-protection bypass tunnel to P in several manners. If the bypass tunnel is established by RSVP, the PLR signals the bypass tunnel with the context ID as destination, and P binds the context label to the bypass tunnel. If the bypass tunnel is established by LDP, P advertises the context label for the context ID as an IP prefix FEC. If the bypass tunnel is established by the PLR in a hierarchical manner, the PLR treats the context label as a one-hop LSP over a regular bypass tunnel to P (e.g., a bypass tunnel to P's loopback IP address). If the bypass tunnel is constructed by using segment routing, the bypass tunnel is represented by a stack of SID labels with the context label as the inner-most SID label (Section 5.9). In any case, the bypass tunnel is a ultimate-hop-popping (UHP) tunnel whose incoming label on P is the context label. o During local repair, all the service packets received by P on the bypass tunnel have the context label as the top label. P first pops the context label. For an MPLS service packet, P further looks up the service label in E's label space indicated by the context label. Such kind of forwarding is called context label switching. For an IP service packet, P looks up the IP destination address in E's IP address space indicated by the context label. Such kind of forwarding is called context IP forwarding. 5.8. Advertisement and path resolution for context ID Path resolution and computation for a context ID are done on ingress routers for egress-protected tunnels, and on PLRs for egress- protection bypass tunnels. Given a protected egress {E, P} and its context ID, E and P MUST coordinate on the reachability of the context ID in the routing domain and the TE domain. The context ID Yimin Shen, et al. Expires February 1, 2020 [Page 13] Internet-Draft MPLS Egress Protection Framework July 2019 MUST be advertised in such a manner that all egress-protected tunnels MUST have E as tailend, and all egress-protection bypass tunnels MUST have P as tailend while avoiding E. This document suggests three approaches: 1. The first approach is called "proxy mode". It requires E and P, but not the PLR, to have the knowledge of the egress protection schema. E and P advertise the context ID as a virtual proxy node (i.e., a logical node) connected to the two routers, with the link between the proxy node and E having more preferable IGP and TE metrics than the link between the proxy node and P. Therefore, all egress-protected tunnels destined for the context ID will automatically follow the IGP or TE paths to E. Each PLR will no longer view itself as a penultimate-hop, but rather two hops away from the proxy node, via E. The PLR will be able to find a bypass path via P to the proxy node, while the bypass tunnel is actually be terminated by P. 2. The second approach is called "alias mode". It requires P and the PLR, but not E, to have the knowledge of the egress protection schema. E simply advertises the context ID as an IP address. P advertises the context ID and the context label by using a "context ID label binding" advertisement. In both routing domain and TE domain, the context ID is only reachable via E. Therefore, all egress-protected tunnels destined for the context ID will have E as tailend. Based on the "context ID label binding" advertisement, the PLR can establish an egress- protection bypass tunnel in several manners (Section 5.9). The "context ID label binding" advertisement is defined as IGP mirroring context segment in [RFC8402] and [SR-ISIS]. These IGP extensions are generic in nature, and hence can be used for egress protection purposes. It is RECOMMENDED that a similar advertisement be defined for OSPF as well. 3. The third approach is called "stub link mode". In this mode, both E and P advertise the context ID as a link to a stub network, essentially modelling the context ID as an anycast IP address owned by the two routers. E, P and the PLR do not need to have the knowledge of the egress protection schema. The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the anycast IP address performed by the ingress routers and PLR. Therefore, care MUST be taken for the applicability of this approach to a network. This framework considers the above approaches as technically equal, and the feasibility of each approach in a given network as dependent Yimin Shen, et al. Expires February 1, 2020 [Page 14] Internet-Draft MPLS Egress Protection Framework July 2019 on the topology, manageability, and available protocols of the network. For a given context ID, all relevant routers, including primary PE, protector, and PLR, MUST support and agree on the chosen approach. The coordination between these routers can be achieved by configuration. In a scenario where an egress-protected tunnel is an inter-area or inter-AS tunnel, its associated context ID MUST be propagated by IGP or BGP from the original area or AS to the area or AS of the ingress router. The propagation process of the context ID SHOULD be the same as that of an IP address in an inter-area or inter-AS environment. 5.9. Egress-protection bypass tunnel establishment A PLR MUST know the context ID of a protected egress {E, P} in order to establish an egress-protection bypass tunnel. The information is obtained from the signaling or label distribution protocol of the egress-protected tunnel. The PLR may or may not need to have the knowledge of the egress protection schema. All it does is to set up a bypass tunnel to a context ID while avoiding the next-hop router (i.e., egress router). This is achievable by using a constraint- based computation algorithm similar to those commonly used for traffic engineering paths and loop-free alternate (LFA) paths. Since the context ID is advertised in the routing domain and the TE domain by IGP according to Section 5.8, the PLR is able to resolve or establish such a bypass path with the protector as tailend. In the case of proxy mode, the PLR may do so in the same manner as transit node protection. An egress-protection bypass tunnel may be established via several methods: (1) It may be established by a signaling protocol (e.g., RSVP), with the context ID as destination. The protector binds the context label to the bypass tunnel. (2) It may be formed by a topology driven protocol (e.g., LDP with various LFA mechanisms). The protector advertises the context ID as an IP prefix FEC, with the context label bound to it. (3) It may be constructed as a hierarchical tunnel. When the protector uses the alias mode (Section 5.8), the PLR will have the knowledge of the context ID, context label, and protector (i.e., the advertiser). The PLR can then establish the bypass tunnel in a hierarchical manner, with the context label as a one-hop LSP over a regular bypass tunnel to the protector's IP address (e.g., loopback address). This regular bypass tunnel may be established by RSVP, LDP, segment routing, or another protocol. Yimin Shen, et al. Expires February 1, 2020 [Page 15] Internet-Draft MPLS Egress Protection Framework July 2019 5.10. Local repair on PLR In this framework, a PLR is agnostic to services and service labels. This obviates the need to maintain bypass forwarding state on a per- service basis, and allows bypass tunnel sharing between egress- protected tunnels. The PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}. During local repair, the PLR reroutes all service packets received on the egress-protected tunnels to the egress-protection bypass tunnel. Service labels remain intact in MPLS service packets. Label operation performed by the PLR depends on the bypass tunnel's characteristics. If the bypass tunnel is a single level tunnel, the rerouting will involve swapping the incoming label of an egress- protected tunnel to the outgoing label of the bypass tunnel. If the bypass tunnel is a hierarchical tunnel, the rerouting will involve swapping the incoming label of an egress-protected tunnel to a context label, and pushing the outgoing label of a regular bypass tunnel. If the bypass tunnel is constructed by segment routing, the rerouting will involve swapping the incoming label of an egress- protected tunnel to a context label, and pushing the stack of SID labels of the bypass tunnel. 5.11. Service label distribution from egress router to protector When a protector receives a rerouted MPLS service packet, it performs context label switching based on the packet's service label which is assigned by the corresponding egress router. In order to achieve this, the protector MUST maintain the labels of egress-protected services in dedicated label spaces on a per protected egress {E, P} basis, i.e., one label space for each egress router that it protects. Also, there MUST be a service label distribution protocol session between each egress router and the protector. Through this protocol, the protector learns the label binding of each egress-protected service. This is the same label binding that the egress router advertises to the service's ingress router, which includes a context ID. The corresponding protection service instance on the protector recognizes the service, and resolves forwarding state based on its own connectivity with the service's destination. It then installs the service label with the forwarding state in the label space of the egress router, which is indicated by the context ID (i.e., context label). Different service protocols may use different mechanisms for such kind of label distribution. Specific extensions may be needed on a per-protocol basis or per-service-type basis. The details of the Yimin Shen, et al. Expires February 1, 2020 [Page 16] Internet-Draft MPLS Egress Protection Framework July 2019 extensions should be specified in separate documents. As an example, [RFC8104] specifies the LDP extensions for pseudowire services. 5.12. Centralized protector mode In this framework, it is assumed that the service destination of an egress-protected service MUST be dual-homed to two edge routers of an MPLS network. One of them is the protected egress router, and the other is a backup egress router. So far in this document, the discussion has been focusing on the scenario where a protector and a backup egress router are co-located as one router. Therefore, the number of protectors in a network is equal to the number of backup egress routers. As another scenario, a network may assign a small number of routers to serve as dedicated protectors, each protecting a subset of egress routers. These protectors are called centralized protectors. Topologically, a centralized protector may be decoupled from all backup egress routers, or it may be co-located with one backup egress router while decoupled from the other backup egress routers. The procedures in this section assume that a protector and a backup egress router are decoupled. Yimin Shen, et al. Expires February 1, 2020 [Page 17] Internet-Draft MPLS Egress Protection Framework July 2019 services 1, ..., N =====================================> tunnel I ------ R1 ------- PLR --------------- E ---- ingress penultimate-hop egress \ | . (primary \ | . service \ | . instances) \ | . \ | . bypass \ service R2 . tunnel destinations | . / (CEs, sites) | . / | . / | . / | . tunnel / | =============> / P ---------------- E' --- protector backup egress (protection (backup service service instances) instances) Figure 2 Like a co-located protector, a centralized protector hosts protection service instances, receives rerouted service packets from PLRs, and performs context label switching and/or context IP forwarding. For each service, instead of sending service packets directly to the service destination, the protector MUST send them via another transport tunnel to the corresponding backup service instance on a backup egress router. The backup service instance in turn forwards the service packets to the service destination. Specifically, if the service is an MPLS service, the protector MUST swap the service label in each received service packet to the label of the backup service advertised by the backup egress router, and then push the label (or label stack) of the transport tunnel. In order for a centralized protector to map an egress-protected MPLS service to a service hosted on a backup egress router, there MUST be a service label distribution protocol session between the backup egress router and the protector. Through this session, the backup egress router advertises the service label of the backup service, attached with the FEC of the egress-protected service and the context ID of the protected egress {E, P}. Based on this information, the protector associates the egress-protected service with the backup service, resolves or establishes a transport tunnel to the backup Yimin Shen, et al. Expires February 1, 2020 [Page 18] Internet-Draft MPLS Egress Protection Framework July 2019 egress router, and sets up forwarding state for the label of the egress-protected service in the label space of the egress router. The service label which the backup egress router advertises to the protector can be the same as the label which the backup egress router advertises to the ingress router(s), if and only if the forwarding state of the label does not direct service packets towards the protected egress router. Otherwise, the label MUST NOT be used for egress protection, because it would create a loop for the service packets. In this case, the backup egress router MUST advertise a unique service label for egress protection, and set up the forwarding state of the label to use the backup egress router's own connectivity with the service destination. 6. Egress link protection Egress link protection is achievable through procedures similar to that of egress node protection. In normal situations, an egress router forwards service packets to a service destination based on a service label, whose forwarding state points to an egress link. In egress link protection, the egress router acts as the PLR, and performs local failure detection and local repair. Specifically, the egress router pre-establishes an egress-protection bypass tunnel to a protector, and sets up the bypass forwarding state for the service label to point to the bypass tunnel. During local repair, the egress router reroutes service packets via the bypass tunnel to the protector. The protector in turn forwards the packets to the service destination (in the co-located protector mode, as shown in Figure 3), or forwards the packets to a backup egress router (in the centralized protector mode, as shown in Figure 4). Yimin Shen, et al. Expires February 1, 2020 [Page 19] Internet-Draft MPLS Egress Protection Framework July 2019 service =====================================> tunnel I ------ R1 ------- R2 --------------- E ---- ingress | ............. egress \ | . PLR \ | . (primary \ | . service \ | . instance) \ | . \ | . bypass service | . tunnel destination | . / (CE, site) | . / | . / | . / | . / | ............... / R3 --------------- P ---- protector (protection service instance) Figure 3 Yimin Shen, et al. Expires February 1, 2020 [Page 20] Internet-Draft MPLS Egress Protection Framework July 2019 service =====================================> tunnel I ------ R1 ------- R2 --------------- E ---- ingress | ............. egress \ | . PLR \ | . (primary \ | . service \ | . instance) \ | . \ | . bypass service | . tunnel destination | . / (CE, site) | . / | . / | . / | . tunnel / | =============> / R3 --------------- P ---- protector backup egress (protection (backup service service instance) instance) Figure 4 There are two approaches to set up the bypass forwarding state on the egress router, depending on whether the egress router knows the service label allocated by the backup egress router. The difference is that one approach requires the protector to perform context label switching, and the other one does not. Both approaches are equally supported by this framework. (1) The first approach applies when the egress router does not know the service label allocated by the backup egress router. In this case, the egress router sets up the bypass forwarding state as a label push with the outgoing label of the egress-protection bypass tunnel. Rerouted packets will have the egress router's service label intact. Therefore, the protector MUST perform context label switching, and the bypass tunnel MUST be destined for the context ID of the protected egress {E, P} and established as described in Section 5.9. This approach is consistent with egress node protection. Hence, a protector can serve in egress node protection and egress link protection in a consistent manner, and both the co-located protector mode and the centralized protector mode are supported (Figure 3 and Figure 4). Yimin Shen, et al. Expires February 1, 2020 [Page 21] Internet-Draft MPLS Egress Protection Framework July 2019 (2) The second approach applies when the egress router knows the service label allocated by the backup egress router, via a label distribution protocol session. In this case, the backup egress router serves as the protector for egress link protection, regardless of the protector of egress node protection, which will be the same router in the co-located protector mode but a different router in the centralized protector mode. The egress router sets up the bypass forwarding state as a label swap from the incoming service label to the service label of the backup egress router (i.e., protector), followed by a push with the outgoing label (or label stack) of the egress link protection bypass tunnel. The bypass tunnel is a regular tunnel destined for an IP address of the protector, instead of the context ID of the protected egress {E, P}. The protector simply forwards rerouted service packets based on its own service label, rather than performing context label switching. In this approach, only the co-located protector mode is applicable. Note that for a bidirectional service, the physical link of an egress link may carry service traffic bi-directionally. Therefore, an egress link failure may simultaneously be an ingress link failure for the traffic in the opposite direction. Protection for ingress link failure SHOULD be provided by a separate mechanism, and hence is out of the scope of this document. 7. Global repair This framework provides a fast but temporary repair for egress node and egress link failures. For permanent repair, the services affected by a failure SHOULD be moved to an alternative tunnel, or replaced by alternative services, which are fully functional. This is referred to as global repair. Possible triggers of global repair include control plane notifications of tunnel status and service status, end-to-end OAM and fault detection at tunnel and service level, and others. The alternative tunnel and services may be pre- established in standby state, or dynamically established as a result of the triggers or network protocol convergence. 8. Operational Considerations When a PLR performs local repair, the router SHOULD generate an alert for the event. The alert may be logged locally for tracking purposes, or it may be sent to the operator at a management station. The communication channel and protocol between the PLR and the management station may vary depending on networks, and are out of the scope of this document. Yimin Shen, et al. Expires February 1, 2020 [Page 22] Internet-Draft MPLS Egress Protection Framework July 2019 9. General context-based forwarding So far, this document has been focusing on the cases where service packets are MPLS or IP packets and protectors perform context label switching or context IP forwarding. Although this should cover most common services, it is worth mentioning that the framework is also applicable to services or sub-modes of services where service packets are layer-2 packets or encapsulated in non-IP/MPLS formats. The only specific in these cases is that a protector MUST perform context- based forwarding based on the layer-2 table or corresponding lookup table which is indicated by a context ID (i.e., context label). 10. Example: Layer-3 VPN egress protection This section shows an example of egress protection for layer-3 IPv4 and IPv6 VPNs. ---------- R1 ----------- PE2 - / (PLR) (PLR) \ ( ) / | | ( ) ( ) / | | ( ) ( site 1 )-- PE1 < | R3 ( site 2 ) ( ) \ | | ( ) ( ) \ | | ( ) \ | | / ---------- R2 ----------- PE3 - (protector) Figure 5 In this example, the core network is IPv4 and MPLS. Both of the IPv4 VPN and the IPv6 VPN consist of site 1 and site 2. Site 1 is connected to PE1, and site 2 is dual-homed to PE2 and PE3. Site 1 includes an IPv4 subnet 203.0.113.64/26 and an IPv6 subnet 2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.113.128/26 and an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site 2, and PE3 is the backup PE. Each of PE1, PE2 and PE3 hosts an IPv4 VPN instance and an IPv6 VPN instance. The PEs use BGP to exchange VPN prefixes and VPN labels between each other. In the core network, R1 and R2 are transit routers, OSPF is used as the routing protocol, and RSVP-TE as the tunnel signaling protocol. Using the framework in this document, the network assigns PE3 to be the protector of PE2 to protect the VPN traffic in the direction from site 1 to site 2. This is the co-located protector mode. PE2 and Yimin Shen, et al. Expires February 1, 2020 [Page 23] Internet-Draft MPLS Egress Protection Framework July 2019 PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 is assigned to the protected egress {PE2, PE3}. (If the core network is IPv6, the context ID would be an IPv6 address.) The IPv4 and IPv6 VPN instances on PE3 serve as protection instances for the corresponding VPN instances on PE2. On PE3, a context label 100 is assigned to the context ID, and a label table pe2.mpls is created to represent PE2's label space. PE3 installs label 100 in its MPLS forwarding table, with nexthop pointing to the label table pe2.mpls. PE2 and PE3 are coordinated to use the proxy mode to advertise the context ID in the routing domain and the TE domain. PE2 uses per-VRF label allocation mode for both of its IPv4 and IPv6 VPN instances. It assigns label 9000 to the IPv4 VRF, and label 9001 to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2 advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP. Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP. PE3 also uses per-VRF VPN label allocation mode for both of its IPv4 and IPv6 VPN instances. It assigns label 10000 to the IPv4 VRF, and label 10001 to the IPv6 VRF. For the prefix 203.0.113.128/26 in site 2, PE3 advertises it with label 10000 and NEXT_HOP as itself to PE1 and PE2 via BGP. For the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and PE2 via BGP. Upon receipt of the above BGP advertisements from PE2, PE1 uses the context ID 198.51.100.1 as destination to compute a path for an egress-protected tunnel. The resultant path is PE1->R1->PE2. PE1 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 as destination, and with the "node protection desired" flag set in the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64 to the tunnel, and installs a route for each prefix in the corresponding IPv4 or IPv6 VRF. The nexthop of the route 203.0.113.128/26 is a push of the VPN label 9000, followed by a push of the outgoing label of the egress-protected tunnel. The nexthop of the route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed by a push of the outgoing label of the egress-protected tunnel. Upon receipt of the above BGP advertisements from PE2, PE3 recognizes the context ID 198.51.100.1 in the NEXT_HOP attribute, and installs a route for label 9000 and a route for label 9001 in the label table pe2.mpls. PE3 sets the nexthop of the route 9000 to the IPv4 protection VRF, and the nexthop of the route 9001 to the IPv6 protection VRF. The IPv4 protection VRF contains the routes to the IPv4 prefixes in site 2. The IPv6 protection VRF contains the routes Yimin Shen, et al. Expires February 1, 2020 [Page 24] Internet-Draft MPLS Egress Protection Framework July 2019 to the IPv6 prefixes in site 2. The nexthops of these routes must be based on PE3's connectivity with site 2, even if the connectivity may not have the best metrics (e.g., MED, local preference, etc.) to be used in PE3's own VRF. The nexthops must not use any path traversing PE2. Note that the protection VRFs are a logical concept, and they may simply be PE3's own VRFs if they satisfies the requirement. 10.1. Egress node protection R1, i.e., the penultimate-hop router of the egress-protected tunnel, serves as the PLR for egress node protection. Based on the "node protection desired" flag and the destination address (i.e., context ID 198.51.100.1) of the tunnel, R1 computes a bypass path to 198.51.100.1 while avoiding PE2. The resultant bypass path is R1->R2->PE3. R1 then signals the path (i.e., egress-protection bypass tunnel), with 198.51.100.1 as destination. Upon receipt of an RSVP Path message of the egress-protection bypass tunnel, PE3 recognizes the context ID 198.51.100.1 as the destination, and responds with the context label 100 in an RSVP Resv message. After the egress-protection bypass tunnel comes up, R1 installs a bypass nexthop for the egress-protected tunnel. The bypass nexthop is a label swap from the incoming label of the egress-protected tunnel to the outgoing label of the egress-protection bypass tunnel. When R1 detects a failure of PE2, it will invoke the above bypass nexthop to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypass tunnel as outer label, and the IPv4 VPN label 9000 as inner label. Each IPv6 VPN packets will have the label of the bypass tunnel as outer label, and the IPv6 VPN label 9001 as inner label. When the packets arrive at PE3, they will have the context label 100 as outer label, and the VPN label 9000 or 9001 as inner label. The context label will first be popped, and then the VPN label will be looked up in the label table pe2.mpls. The lookup will cause the VPN label to be popped, and the IPv4 and IPv6 packets to be forwarded to site 2 based on the IPv4 and IPv6 protection VRFs, respectively. 10.2. Egress link protection PE2 serves as the PLR for egress link protection. It has already learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence it uses the approach (2) described in Section 6 to set up bypass forwarding state. It signals an egress-protection bypass tunnel to PE3, by using the path PE2->R3->PE3, and PE3's IP address as destination. After the bypass tunnel comes up, PE2 installs a bypass Yimin Shen, et al. Expires February 1, 2020 [Page 25] Internet-Draft MPLS Egress Protection Framework July 2019 nexthop for the IPv4 VPN label 9000, and a bypass nexthop for the IPv6 VPN label 9001. For label 9000, the bypass nexthop is a label swap to label 10000, followed by a label push with the outgoing label of the bypass tunnel. For label 9001, the bypass nexthop is a label swap to label 10001, followed by a label push with the outgoing label of the bypass tunnel. When PE2 detects a failure of the egress link, it will invoke the above bypass nexthop to reroute VPN packets. Each IPv4 VPN packet will have the label of the bypass tunnel as outer label, and label 10000 as inner label. Each IPv6 VPN packet will have the label of the bypass tunnel as outer label, and label 10001 as inner label. When the packets arrive at PE3, the VPN label 10000 or 10001 will be popped, and the exposed IPv4 and IPv6 packets will be forwarded based on PE3's IPv4 and IPv6 VRFs, respectively. 10.3. Global repair Eventually, global repair will take effect, as control plane protocols converge on the new topology. PE1 will choose PE3 as a new entrance to site 2. Before that happens, the VPN traffic has been protected by the above local repair. 10.4. Other modes of VPN label allocation It is also possible that PE2 may use per-route or per-interface VPN label allocation mode. In either case, PE3 will have multiple VPN label routes in the pe2.mpls table, corresponding to the VPN labels advertised by PE2. PE3 forwards rerouted packets by popping a VPN label and performing an IP lookup in the corresponding protection VRF. PE3's forwarding behavior is consistent with the above case where PE2 uses per-VRF VPN label allocation mode. PE3 does not need to know PE2's VPN label allocation mode, or construct a specific nexthop for each VPN label route in the pe2.mpls table. 11. IANA Considerations This document has no request for new IANA allocation. 12. Security Considerations The framework in this document involves rerouting traffic around an egress node or link failure, via a bypass path from a PLR to a protector, and ultimately to a backup egress router. The forwarding performed by the routers in the data plane is anticipated, as part of the planning of egress protection. Yimin Shen, et al. Expires February 1, 2020 [Page 26] Internet-Draft MPLS Egress Protection Framework July 2019 Control plane protocols MAY be used to facilitate the provisioning of the egress protection on the routers. In particular, the framework requires a service label distribution protocol between an egress router and a protector over a secure session. The security properties of this provisioning and label distribution depend entirely on the underlying protocol chosen to implement these activities . Their associated security considerations apply. This framework introduces no new security requirements or guarantees relative to these activities. Also, the PLR, protector, and backup egress router are located close to the protected egress router, and normally in the same administrative domain. If they are not in the same administrative domain, a certain level of trust MUST be established between them in order for the protocols to run securely across the domain boundary. The basis of this trust is the security model of the protocols (as described above), and further security considerations for inter- domain scenarios should be addressed by the protocols as a common requirement. Security attacks may sometimes come from a customer domain. Such kind of attacks are not introduced by the framework in this document, and may occur regardless of the existence of egress protection. In one possible case, the egress link between an egress router and a CE could become a point of attack. An attacker that gains control of the CE might use it to simulate link failures and trigger constant and cascading activities in the network. If egress link protection is in place, egress link protection activities may also be triggered. As a general solution to defeat the attack, a damping mechanism SHOULD be used by the egress router to promptly suppress the services associated with the link or CE. The egress router would stop advertising the services, essentially detaching them from the network and eliminating the effect of the simulated link failures. From the above perspectives, this framework does not introduce any new security threat to networks. 13. Acknowledgements This document leverages work done by Yakov Rekhter, Kevin Wang and Zhaohui Zhang on MPLS egress protection. Thanks to Alexander Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, Roman Danyliw, and Yuanlong Jiang for their valuable comments that helped to shape this document and improve its clarity. Yimin Shen, et al. Expires February 1, 2020 [Page 27] Internet-Draft MPLS Egress Protection Framework July 2019 14. References 14.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment- routing-extensions (work in progress), 2017. 14.2. Informative References [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, . [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, . [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, . Yimin Shen, et al. Expires February 1, 2020 [Page 28] Internet-Draft MPLS Egress Protection Framework July 2019 [RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "Pseudowire (PW) Endpoint Fast Failure Protection", RFC 8104, DOI 10.17487/RFC8104, March 2017, . [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, "Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 2018, . [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix Independent Convergence", draft-ietf-rtgwg-bgp-pic-09.txt (work in progress), 2017. Authors' Addresses Yimin Shen Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Phone: +1 9785890722 Email: yshen@juniper.net Minto Jeyananth Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 USA Phone: +1 4089367563 Email: minto@juniper.net Bruno Decraene Orange Email: bruno.decraene@orange.com Hannes Gredler RtBrick Inc Email: hannes@rtbrick.com Yimin Shen, et al. Expires February 1, 2020 [Page 29] Internet-Draft MPLS Egress Protection Framework July 2019 Carsten Michel Deutsche Telekom Email: c.michel@telekom.de Huaimo Chen Huawei Technologies Co., Ltd. Email: huaimo.chen@huawei.com Yimin Shen, et al. Expires February 1, 2020 [Page 30] ./draft-ietf-pce-wson-rwa-ext-17.txt0000644000764400076440000017212213436312402016503 0ustar iustyiustyNetwork Working Group Y. Lee, Ed. Internet Draft Huawei Technologies Intended status: Standard Track R. Casellas, Ed. Expires: September 1, 2019 CTTC March 1, 2019 PCEP Extension for WSON Routing and Wavelength Assignment draft-ietf-pce-wson-rwa-ext-17 Abstract This document provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Path 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 path computation. 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 Lee & Casellas Expires September 2019 [Page 1] Internet-Draft PCEP Extension for WSON RWA March 2019 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2019. Copyright Notice Copyright (c) 2019 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. Terminology....................................................3 2. Requirements Language..........................................3 3. Introduction...................................................3 4. Encoding of a RWA Path Request.................................6 4.1. Wavelength Assignment (WA) Object.........................7 4.2. Wavelength Selection TLV..................................9 4.3. Wavelength Restriction Constraint TLV.....................9 4.3.1. Link Identifier Field...............................12 4.3.2. Wavelength Restriction Field........................14 4.4. Signal Processing Capability Restrictions................15 4.4.1. Signal Processing Exclusion.........................16 4.4.2. Signal Processing Inclusion.........................18 5. Encoding of a RWA Path Reply..................................19 5.1. Wavelength Allocation TLV................................19 5.2. Error Indicator..........................................20 5.3. NO-PATH Indicator........................................21 6. Manageability Considerations..................................22 6.1. Control of Function and Policy...........................22 6.2. Liveness Detection and Monitoring........................22 6.3. Verifying Correct Operation..............................22 6.4. Requirements on Other Protocols and Functional Components22 6.5. Impact on Network Operation..............................23 Lee & Casellas Expires September 2019 [Page 2] Internet-Draft PCEP Extension for WSON RWA March 2019 7. Security Considerations.......................................23 8. IANA Considerations...........................................23 8.1. New PCEP Object: Wavelength Assignment Object............23 8.2. WA Object Flag Field.....................................23 8.3. New PCEP TLV: Wavelength Selection TLV...................24 8.4. New PCEP TLV: Wavelength Restriction Constraint TLV......24 8.5. Wavelength Restriction Constraint TLV Action Values......25 8.6. New PCEP TLV: Wavelength Allocation TLV..................25 8.7. Wavelength Allocation TLV Flag Field.....................25 8.8. New PCEP TLV: Optical Interface Class List TLV...........26 8.9. New PCEP TLV: Client Signal TLV..........................26 8.10. New No-Path Reasons.....................................27 8.11. New Error-Types and Error-Values........................27 8.12. New Subobjects for the Exclude Route Object.............28 8.13. New Subobjects for the Include Route Object.............28 8.14. Request for Updated Note for LMP TE Link Object Class Type ..............................................................28 9. Acknowledgments...............................................29 10. References...................................................29 10.1. Normative References....................................29 10.2. Informative References..................................30 11. Contributors.................................................32 Authors' Addresses...............................................33 1. Terminology This document uses the terminology defined in [RFC4655], and [RFC5440]. 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Introduction [RFC5440] 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 Lee & Casellas Expires September 2019 [Page 3] Internet-Draft PCEP Extension for WSON RWA March 2019 context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. A PCC is said to be any network component that makes such a request and may be, for instance, an Optical Switching Element within a Wavelength Division Multiplexing (WDM) network. The PCE, itself, can be located anywhere within the network, and may be within an optical switching element, a Network Management System (NMS) or Operational Support System (OSS), or may be an independent network server. This document provides the PCEP extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON) based on the requirements specified in [RFC6163] and [RFC7449]. WSON refers to WDM based optical networks in which switching is performed selectively based on the wavelength of an optical signal. The devices used in WSONs that are able to switch signals based on signal wavelength are known as Lambda Switch Capable (LSC). WSONs can be transparent or translucent. A transparent optical network is made up of optical devices that can switch but not convert from one wavelength to another, all within the optical domain. On the other hand, translucent networks include 3R regenerators (Re- amplification, Re-shaping, Re-timing) that are sparsely placed. The main function of the 3R regenerators is to convert one optical wavelength to another. A Lambda Switch Capable (LSC) Label Switched Path (LSP) may span one or several transparent segments, which are delimited by 3R regenerators typically with electronic regenerator and optional wavelength conversion. Each transparent segment or path in WSON is referred to as an optical path. An optical path may span multiple fiber links and the path should be assigned the same wavelength for each link. In such case, the optical path is said to satisfy the wavelength-continuity constraint. Figure 1 illustrates the relationship between a LSC LSP and transparent segments (optical paths). Lee & Casellas Expires September 2019 [Page 4] Internet-Draft PCEP Extension for WSON RWA March 2019 +---+ +-----+ +-----+ +-----+ +-----+ | |I1 | | | | | | I2| | | |o------| |-------[(3R) ]------| |--------o| | | | | | | | | | | | +---+ +-----+ +-----+ +-----+ +-----+ (X LSC) (LSC LSC) (LSC LSC) (LSC X) <-------> <-------> <-----> <-------> <-----------------------><----------------------> Transparent Segment Transparent Segment <-------------------------------------------------> LSC LSP Figure 1 Illustration of a LSC LSP and transparent segments Note that two transparent segments within a WSON LSP do not need to operate on the same wavelength (due to the wavelength conversion capabilities). Two optical channels that share a common fiber link cannot be assigned the same wavelength; Otherwise, the two signals would interfere with each other. Note that advanced additional multiplexing techniques such as polarization based multiplexing are not addressed in this document since the physical layer aspects are not currently standardized. Therefore, assigning the proper wavelength on a path is an essential requirement in the optical path computation process. When a switching node has the ability to perform wavelength conversion, the wavelength-continuity constraint can be relaxed, and a LSC Label Switched Path (LSP) may use different wavelengths on different links along its route from origin to destination. It is, however, to be noted that wavelength converters may be limited due to their relatively high cost, while the number of WDM channels that can be supported in a fiber is also limited. As a WSON can be composed of network nodes that cannot perform wavelength conversion, nodes with limited wavelength conversion, and nodes with full wavelength conversion abilities, wavelength assignment is an additional routing constraint to be considered in all optical path computation. For example (see Figure 1), within a translucent WSON, a LSC LSP may be established between interfaces I1 and I2, spanning 2 transparent segments (optical paths) where the wavelength continuity constraint applies (i.e. the same unique wavelength must be assigned to the LSP at each TE link of the segment). If the LSC LSP induced a Forwarding Adjacency / TE link, the switching capabilities of the TE link would Lee & Casellas Expires September 2019 [Page 5] Internet-Draft PCEP Extension for WSON RWA March 2019 be (X X) where X refers to the switching capability of I1 and I2. For example, X can be Packet Switch Capable (PSC), Time Division Multiplexing (TDM), etc. This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for generic properties such as label, label-set and label assignment noting that wavelength is a type of label. Wavelength restrictions and constraints are also formulated in terms of labels per [RFC7579]. The optical modulation properties, which are also referred to as signal compatibility, are already considered in signaling in [RFC7581] and [RFC7688]. In order to improve the signal quality and limit some optical effects several advanced modulation processing capabilities are used by the mechanisms specified in this document. These modulation capabilities contribute not only to optical signal quality checks but also constrain the selection of sender and receiver, as they should have matching signal processing capabilities. This document includes signal compatibility constraints as part of RWA path computation. That is, the signal processing capabilities (e.g., modulation and Forward Error Correction (FEC)) indicated by means of optical interface class (OIC) must be compatible between the sender and the receiver of the optical path across all optical elements. This document, however, does not address optical impairments as part of RWA path computation. See [RFC6566] for the framework for optical impairments. 4. Encoding of a RWA Path Request Figure 2 shows one typical PCE based implementation, which is referred to as the Combined Process (R&WA). With this architecture, the two processes of routing and wavelength assignment are accessed via a single PCE. This architecture is the base architecture specified in [RFC6163] and the PCEP extensions that are specified in this document are based on this architecture. Lee & Casellas Expires September 2019 [Page 6] Internet-Draft PCEP Extension for WSON RWA March 2019 +----------------------------+ +-----+ | +-------+ +--+ | | | | |Routing| |WA| | | PCC |<----->| +-------+ +--+ | | | | | +-----+ | PCE | +----------------------------+ Figure 2 Combined Process (R&WA) architecture 4.1. Wavelength Assignment (WA) Object Wavelength allocation can be performed by the PCE by different means: (a) By means of Explicit Label Control [RFC3471] where the PCE allocates which label to use for each interface/node along the path. The allocated labels MAY appear after an interface route subobject. (b) By means of a Label Set where the PCE provides a range of potential labels to allocate by each node along the path. Option (b) allows distributed label allocation (performed during signaling) to complete wavelength assignment. Additionally, given a range of potential labels to allocate, a PC Request SHOULD convey the heuristic / mechanism used for the allocation. The format of a PCReq message per [RFC5440] after incorporating the Wavelength Assignment (WA) object is as follows: ::= [] Where: ::=[] ::= Lee & Casellas Expires September 2019 [Page 7] Internet-Draft PCEP Extension for WSON RWA March 2019 [other optional objects...] If the WA object is present in the request, it MUST be encoded after the END-POINTS object as defined in [PCEP-GMPLS]. The WA Object is mandatory in this document. Orderings for the other optional objects are irrelevant. WA Object-Class is (TBD1) (To be assigned by IANA). WA Object-Type is 1. The format of the WA 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 | Flags |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 WA Object o Reserved (16 bits): Reserved for future use and SHOULD be zeroed and ignored on receipt. o Flags (16 bits) One flag bit is allocated as follows: Lee & Casellas Expires September 2019 [Page 8] Internet-Draft PCEP Extension for WSON RWA March 2019 - M (Mode - 1 bit): M bit is used to indicate the mode of wavelength assignment. When M bit is set to 1, this indicates that the label assigned by the PCE must be explicit. That is, the selected way to convey the allocated wavelength is by means of Explicit Label Control for each hop of a computed LSP. Otherwise (M bit is set to 0), the label assigned by the PCE need not be explicit (i.e., it can be suggested in the form of label set objects in the corresponding response, to allow distributed WA. If M is 0, the PCE MUST return a Label Set Field as described in Section 2.6 of [RFC7579] in the response. See Section 5 of this document for the encoding discussion of a Label Set Field in a PCRep message. All unused flags SHOULD be zeroed. IANA is to create a new registry to manage the Flag field of the WA object. o TLVs (variable). In the TLVs field, the following two TLVs are defined. At least one TLV MUST be present. - Wavelength Selection TLV: A TLV of type (TBD2) with fixed length of 32 bits indicating the wavelength selection. See Section 4.2 for details. - Wavelength Restriction Constraint TLV: A TLV of type (TBD3) with variable length indicating wavelength restrictions. See Section 4.3 for details. 4.2. Wavelength Selection TLV The Wavelength Selection TLV is used to indicate the wavelength selection constraint in regard to the order of wavelength assignment to be returned by the PCE. This TLV is only applied when M bit is set in the WA Object specified in Section 4.1. This TLV MUST NOT be used when the M bit is cleared. The encoding of this TLV is specified as the Wavelength Selection Sub-TLV in Section 4.2.2 of [RFC7689]. IANA is to allocate a new TLV type, Wavelength Selection TLV type (TBD2). 4.3. Wavelength Restriction Constraint TLV For any request that contains a wavelength assignment, the requester (PCC) MUST specify a restriction on the wavelengths to be used. This restriction is to be interpreted by the PCE as a constraint on the tuning ability of the origination laser transmitter or on any other Lee & Casellas Expires September 2019 [Page 9] Internet-Draft PCEP Extension for WSON RWA March 2019 maintenance related constraints. Note that if the LSP LSC spans different segments, the PCE must have mechanisms to know the tunability restrictions of the involved wavelength converters / regenerators, e.g. by means of the Traffic Engineering Database (TED) either via IGP or Network Management System (NMS). Even if the PCE knows the tunability of the transmitter, the PCC must be able to apply additional constraints to the request. The format of the Wavelength Restriction Constraint TLV is as follows: ::= ( )... Where ::= [] See Section 4.3.1. for the encoding of the Link Identifiers Field. These fields (i.e., , and , etc.) MAY appear together more than once to be able to specify multiple actions and their restrictions. IANA is to allocate a new TLV type, Wavelength Restriction Constraint TLV type (TBD3). The TLV data 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifiers Field | // . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Restriction Field | // . . . . // Lee & Casellas Expires September 2019 [Page 10] Internet-Draft PCEP Extension for WSON RWA March 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ . . . . ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifiers Field | // . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength Restriction Field | // . . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Wavelength Restriction Constraint TLV Encoding o Action (8 bits): o 0 - Inclusive List indicates that one or more link identifiers are included in the Link Set. Each identifies a separate link that is part of the set. o 1 - Inclusive Range indicates that the Link Set defines a range of links. It contains two link identifiers. The first identifier indicates the start of the range (inclusive). The second identifier indicates the end of the range (inclusive). All links with numeric values between the bounds are considered to be part of the set. A value of zero in either position indicates that there is no bound on the corresponding portion of the range. o 2-255 - For future use IANA is to create a new registry to manage the Action values of the Wavelength Restriction Constraint TLV. If PCE receives an unrecognized Action value, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) and an Error-value (Error-value=3). See Section 5.2 for details. Lee & Casellas Expires September 2019 [Page 11] Internet-Draft PCEP Extension for WSON RWA March 2019 Note that "links" are assumed to be bidirectional. o Count (8 bits): The number of the link identifiers Note that a PCC MAY add a Wavelength restriction that applies to all links by setting the Count field to zero and specifying just a set of wavelengths. Note that all link identifiers in the same list MUST be of the same type. o Reserved (16 bits): Reserved for future use and SHOULD be zeroed and ignored on receipt. o Link Identifiers: Identifies each link ID for which restriction is applied. The length is dependent on the link format and the Count field. See Section 4.3.1. for Link Identifier encoding. o Wavelength Restriction: See Section 4.3.2. for the Wavelength Restriction Field encoding. Various encoding errors are possible with this TLV (e.g., not exactly two link identifiers with the range case, unknown identifier types, no matching link for a given identifier, etc.). To indicate errors associated with this encoding, a PCEP speaker MUST send a PCErr message with Error-Type=TBD8 and Error-value=3. See Section 5.1 for the details. 4.3.1. Link Identifier Field The link identifier field can be an IPv4 [RFC3630], IPv6 [RFC5329] or unnumbered interface ID [RFC4203]. ::= | | The encoding of each case is as follows: Lee & Casellas Expires September 2019 [Page 12] Internet-Draft PCEP Extension for WSON RWA March 2019 IPv4 Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Reserved (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Reserved (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unnumbered Interface ID Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Reserved (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Node ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type (8 bits): It indicates the type of the link identifier. Lee & Casellas Expires September 2019 [Page 13] Internet-Draft PCEP Extension for WSON RWA March 2019 o Reserved (24 bits): Reserved for future use and SHOULD be zeroed and ignored on receipt. o Link Identifier: When Type field is 1, 4-bytes IPv4 address is encoded; when Type field is 2, 16-bytes IPv6 address is encoded; when Type field is 3, a tuple of 4-bytes TE node ID and 4-bytes interface ID is encoded. The Type field is extensible and matches to the IANA registry created for Link Management Protocol (LMP) [RFC4204] for "TE Link Object Class Type name space": https://www.iana.org/assignments/lmp- parameters/lmp-parameters.xhtml#lmp-parameters-15. See Section 8.14 for the request to update the introductory text of the aforementioned registry to note that the values have additional usage for the Link Identifier Type field. 4.3.2. Wavelength Restriction Field The Wavelength Restriction Field of the Wavelength Restriction Constraint TLV is encoded as a Label Set field as specified in Section 2.6 in [RFC7579] with base label encoded as a 32 bit LSC label, defined in [RFC6205]. The Label Set format is repeated here for convenience, with the base label internal structure included. See [RFC6205] for a description of Grid, C.S, Identifier and n, as well as [RFC7579] for the details of each action. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action| Num Labels | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S | Identifier | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional fields as necessary per action | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action (4 bits): 0 - Inclusive List Lee & Casellas Expires September 2019 [Page 14] Internet-Draft PCEP Extension for WSON RWA March 2019 1 - Exclusive List 2 - Inclusive Range 3 - Exclusive Range 4 - Bitmap Set Num Labels (12 bits): It is generally the number of labels. It has a specific meaning depending on the action value. Length (16 bits): It is the length in bytes of the entire Wavelength Restriction field. Identifier (9 bits): The Identifier is always set to 0. If PCC receives the value of the identifier other than 0, it will ignore. See Sections 2.6.1 - 2.6.3 of [RFC7579] for details on additional field discussion for each action. 4.4. Signal Processing Capability Restrictions Path computation for WSON includes checking of signal processing capabilities at each interface against requested capability; the PCE MUST have mechanisms to know the signal processing capabilities at each interface, e.g. by means of the Traffic Engineering Database (TED) either via IGP or Network Management System (NMS). Moreover, a PCC should be able to indicate additional restrictions to signal processing compatibility, either on the endpoint or any given link. The supported signal processing capabilities considered in the RWA Information Model [RFC7446] are: o Optical Interface Class List o Bit Rate o Client Signal The Bit Rate restriction is already expressed in [PCEP-GMPLS] in the BANDWIDTH object. Lee & Casellas Expires September 2019 [Page 15] Internet-Draft PCEP Extension for WSON RWA March 2019 In order to support the Optical Interface Class information and the Client Signal information new TLVs are introduced as endpoint- restriction in the END-POINTS type Generalized endpoint: o Client Signal TLV o Optical Interface Class List TLV The END-POINTS type generalized endpoint is extended as follows: ::= ::= [] ::= (| [] []) Where ::= [] [] The Wavelength Restriction Constraint TLV is defined in Section 4.3. A new TLV for the Optical Interface Class List TLV (TBD5) is defined, and the encoding of the value part of the Optical Interface Class List TLV is described in Section 4.1 of [RFC7581]. A new TLV for the Client Signal Information TLV (TBD6) is defined, and the encoding of the value part of the Client Signal Information TLV is described in Section 4.2 of [RFC7581]. 4.4.1. Signal Processing Exclusion The PCC/PCE should be able to exclude particular types of signal processing along the path in order to handle client restriction or multi-domain path computation. [RFC5440] defines how Exclude Route Object (XRO) subobject is used. In this draft, we add two new XRO Signal Processing Exclusion Subobjects. Lee & Casellas Expires September 2019 [Page 16] Internet-Draft PCEP Extension for WSON RWA March 2019 The first XRO subobject type (TBD9) is the Optical Interface Class List Field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type=TBD9 | Length | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optical Interface Class List // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Optical Interface Class List XRO Subobject Refer to [RFC5521] for the definition of X, Length and Attribute. Type (7 bits): The Type of the Signaling Processing Exclusion Field. The TLV Type value (TBD9) is to be assigned by the IANA for the Optical Interface Class List XRO Subobject Type. Reserved bits (8 bits) are for future use and SHOULD be zeroed and ignored on receipt. The Attribute field (8 bits): [RFC5521] defines several Attribute values; the only permitted Attribute values for this field are 0 (Interface) or 1 (Node). The Optical Interface Class List is encoded as described in Section 4.1 of [RFC7581]. The second XRO subobject type (TBD10) is the Client Signal Information 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type=TBD10 | Length | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Client Signal Information // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee & Casellas Expires September 2019 [Page 17] Internet-Draft PCEP Extension for WSON RWA March 2019 Figure 6 Client Signal Information XRO Subobject Refer to [RFC5521] for the definition of X, Length and Attribute. Type (7 bits): The Type of the Signaling Processing Exclusion Field. The TLV Type value (TBD10) is to be assigned by the IANA for the Client Signal Information XRO Subobject Type. Reserved bits (8 bits) are for future use and SHOULD be zeroed and ignored on receipt. The Attribute field (8 bits): [RFC5521] defines several Attribute values; the only permitted Attribute values for this field are 0 (Interface) or 1 (Node). The Client Signal Information is encoded as described in Section 4.2 of [RFC7581]. The XRO needs to support the new Signaling Processing Exclusion XRO Subobject types: Type XRO Subobject Type TBD9 Optical Interface Class List TBD10 Client Signal Information 4.4.2. Signal Processing Inclusion Similar to the XRO subobject, the PCC/PCE should be able to include particular types of signal processing along the path in order to handle client restriction or multi-domain path computation. [RFC5440] defines how Include Route Object (IRO) subobject is used. In this draft, we add two new Signal Processing Inclusion Subobjects. The IRO needs to support the new IRO Subobject types (TBD11 and TBD12) for the PCEP IRO object [RFC5440]: Type IRO Subobject Type Lee & Casellas Expires September 2019 [Page 18] Internet-Draft PCEP Extension for WSON RWA March 2019 TBD11 Optical Interface Class List TBD12 Client Signal Information The encoding of the Signal Processing Inclusion subobjects is similar to Section 4.4.1 where the 'X' field is replaced with 'L' field, all the other fields remains the same. The 'L' field is described in [RFC3209]. 5. Encoding of a RWA Path Reply This section provides the encoding of a RWA Path Reply for wavelength allocation request as discussed in Section 4. 5.1. Wavelength Allocation TLV Recall that wavelength allocation can be performed by the PCE by different means: (a) By means of Explicit Label Control (ELC) where the PCE allocates which label to use for each interface/node along the path. (b) By means of a Label Set where the PCE provides a range of potential labels to allocate by each node along the path. Option (b) allows distributed label allocation (performed during signaling) to complete wavelength allocation. The Wavelength Allocation TLV type is TBD4 (See Section 8.4). Note that this TLV is used for both (a) and (b). The TLV data 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flag |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Field | // . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Allocated Wavelength(s) | // . . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee & Casellas Expires September 2019 [Page 19] Internet-Draft PCEP Extension for WSON RWA March 2019 Figure 7 Wavelength Allocation TLV Encoding o Reserved (16 bits): Reserved for future use. o Flags (16 bits) One flag bit is allocated as follows: . M (Mode): 1 bit - 0 indicates the allocation is under Explicit Label Control. - 1 indicates the allocation is expressed in Label Sets. IANA is to create a new registry to manage the Flag field (TBD14) of the Wavelength Allocation TLV. Note that all link identifiers in the same list must be of the same type. o Link Identifier: Identifies the interface to which assignment wavelength(s) is applied. See Section 4.3.1. for Link Identifier encoding. o Allocated Wavelength(s): Indicates the allocated wavelength(s) to be associated with the Link Identifier. See Section 4.3.2 for encoding details. This TLV is carried in a PCRep message as an attribute TLV [RFC5420] in the Hop Attribute Subobjects [RFC7570] in the ERO [RFC5440]. 5.2. Error Indicator To indicate errors associated with the RWA request, a new Error Type (TBD8) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR Object: A new Error-Type (TBD8) and subsequent error-values are defined as follows: Lee & Casellas Expires September 2019 [Page 20] Internet-Draft PCEP Extension for WSON RWA March 2019 o Error-Type=TBD8; Error-value=1: if a PCE receives a RWA request and the PCE is not capable of processing the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) and an Error-value (Error- value=1). The PCE stops processing the request. The corresponding RWA request MUST be cancelled at the PCC. o Error-Type=TBD8; Error-value=2: if a PCE receives a RWA request and the PCE is not capable of RWA computation, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD8) and an Error-value (Error-value=2). The PCE stops processing the request. The corresponding RWA computation MUST be cancelled at the PCC. o Error-Type=TBD8; Error-value=3: if a PCE receives a RWA request and there are syntactical encoding errors (e.g., not exactly two link identifiers with the range case, unknown identifier types, no matching link for a given identifier, unknown Action value, etc.), the PCE MUST send a PCErr message with a PCEP- ERROR Object (Error-Type=TBD8) and an Error-value (Error- value=3). 5.3. NO-PATH Indicator To communicate the reason(s) for not being able to find RWA for the path request, the NO-PATH object can be used in the corresponding response. The format of the NO-PATH object body is defined in [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide additional information about why a path computation has failed. One new bit flag is defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object. o Bit TBD7: When set, the PCE indicates no feasible route was found that meets all the constraints (e.g., wavelength restriction, signal compatibility, etc.) associated with RWA. Lee & Casellas Expires September 2019 [Page 21] Internet-Draft PCEP Extension for WSON RWA March 2019 6. Manageability Considerations Manageability of WSON Routing and Wavelength Assignment (RWA) with PCE must address the following considerations: 6.1. Control of Function and Policy In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuration of the following PCEP session parameters on a PCC: o The ability to send a WSON RWA request. In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuration of the following PCEP session parameters on a PCE: o The support for WSON RWA. o A set of WSON RWA specific policies (authorized sender, request rate limiter, etc). These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in, or may apply to a specific session with a given PCEP peer or a specific group of sessions with a specific group of PCEP peers. 6.2. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in section 8.3 of [RFC5440]. 6.3. Verifying Correct Operation Mechanisms defined in this document do not imply any new verification requirements in addition to those already listed in section 8.4 of [RFC5440] 6.4. Requirements on Other Protocols and Functional Components The PCEP Link-State mechanism [PCEP-LS] may be used to advertise WSON RWA path computation capabilities to PCCs. Lee & Casellas Expires September 2019 [Page 22] Internet-Draft PCEP Extension for WSON RWA March 2019 6.5. Impact on Network Operation Mechanisms defined in this document do not imply any new network operation requirements in addition to those already listed in section 8.6 of [RFC5440]. 7. Security Considerations The security considerations discussed in [RFC5440] are relevant for this document, this document does not introduce any new security issues. If an operator wishes to keep private the information distributed by WSON, PCEPS [RFC8253] SHOULD be used. 8. IANA Considerations IANA maintains a registry of PCEP parameters. IANA has made allocations from the sub-registries as described in the following sections. 8.1. New PCEP Object: Wavelength Assignment Object As described in Section 4.1, a new PCEP Object is defined to carry wavelength assignment related constraints. IANA is to allocate the following from "PCEP Objects" sub-registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): Object Class Name Object Reference Value Type --------------------------------------------------------- TBD1 WA 1: Wavelength Assignment [This.I-D] 8.2. WA Object Flag Field As described in Section 4.1, IANA is to create a registry to manage the Flag field of the WA object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: Lee & Casellas Expires September 2019 [Page 23] Internet-Draft PCEP Extension for WSON RWA March 2019 o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following values are defined in this document: One bit is defined for the WA Object flag in this document: Codespace of the Flag field (WA Object) Bit Description Reference ------------------------------------------------- 0-14 Unassigned [This.I-D] 15 Explicit Label Control [This.I-D] 8.3. New PCEP TLV: Wavelength Selection TLV As described in Sections 4.2, a new PCEP TLV is defined to indicate wavelength selection constraints. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD2 Wavelength Selection [This.I-D] 8.4. New PCEP TLV: Wavelength Restriction Constraint TLV As described in Sections 4.3, a new PCEP TLV is defined to indicate wavelength restriction constraints. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD3 Wavelength Restriction [This.I-D] Lee & Casellas Expires September 2019 [Page 24] Internet-Draft PCEP Extension for WSON RWA March 2019 Constraint 8.5. Wavelength Restriction Constraint TLV Action Values As described in Section 4.3, IANA is to allocate a new registry to manage the Action values of the Action field in the Wavelength Restriction Constraint TLV. New values are assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities: value, meaning, and defining RFC. The following values are defined in this document: Value Meaning Reference --------------------------------------------------------- 0 Inclusive List [This.I-D] 1 Inclusive Range [This.I-D] 2-255 Reserved [This.I-D] 8.6. New PCEP TLV: Wavelength Allocation TLV As described in Section 5.1, a new PCEP TLV is defined to indicate the allocation of wavelength(s) by the PCE in response to a request by the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD4 Wavelength Allocation [This.I-D] 8.7. Wavelength Allocation TLV Flag Field As described in Section 5.1, IANA is to allocate a registry to manage the Flag field of the Wavelength Allocation TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) Lee & Casellas Expires September 2019 [Page 25] Internet-Draft PCEP Extension for WSON RWA March 2019 o Capability description o Defining RFC One bit is defined for the Wavelength Allocation flag in this - document: Codespace of the Flag field (Wavelength Allocation TLV) Bit Description Reference ------------------------------------------------- 0-14 Unassigned [This.I-D] 15 Wavelength Allocation Mode [This.I-D] 8.8. New PCEP TLV: Optical Interface Class List TLV As described in Section 4.4, a new PCEP TLV is defined to indicate the optical interface class list. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD5 Optical Interface [This.I-D] Class List 8.9. New PCEP TLV: Client Signal TLV As described in Section 4.4, a new PCEP TLV is defined to indicate the client signal information. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- Lee & Casellas Expires September 2019 [Page 26] Internet-Draft PCEP Extension for WSON RWA March 2019 TBD6 Client Signal Information [This.I-D] 8.10. New No-Path Reasons As described in Section 5.3, a new bit flag are defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object. This flag, when set, indicates that no feasible route was found that meets all the RWA constraints (e.g., wavelength restriction, signal compatibility, etc.) associated with a RWA path computation request. IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR TLV Flag Field" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- tlv). Bit Description Reference ----------------------------------------------------- TBD7 No RWA constraints met [This.I-D] 8.11. New Error-Types and Error-Values As described in Section 5.2, new PCEP error codes are defined for WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object Error Types and Values" sub-registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). Error- Meaning Error-Value Reference Type --------------------------------------------------------------- TBD8 WSON RWA Error 0: Unassigned [This.I-D] 1: Insufficient [This.I-D] Memory 2: RWA computation [This.I-D] Not supported Lee & Casellas Expires September 2019 [Page 27] Internet-Draft PCEP Extension for WSON RWA March 2019 3: Syntactical [This.I-D] Encoding error 4-255: Unassigned [This.I-D] 8.12. New Subobjects for the Exclude Route Object As described in Section 4.4.1, the "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Exclude Route Object (XRO). IANA is requested to add further subobjects that can be carried in the XRO as follows: Subobject Type Reference ---------------------------------------------------------- TBD9 Optical Interface Class List [This.I-D] TBD10 Client Signal Information [This.I-D] 8.13. New Subobjects for the Include Route Object As described in Section 4.4.2, the "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Include Route Object (IRO). IANA is requested to add further subobjects that can be carried in the IRO as follows: Subobject Type Reference ---------------------------------------------------------- TBD11 Optical Interface Class List [This.I-D] TBD12 Client Signal Information [This.I-D] 8.14. Request for Updated Note for LMP TE Link Object Class Type As discussed in Section 4.3.1, the registry created for Link Management Protocol (LMP) [RFC4204] for "TE Link Object Class Type name space": https://www.iana.org/assignments/lmp-parameters/lmp- parameters.xhtml#lmp-parameters-15 is requested for the updated Lee & Casellas Expires September 2019 [Page 28] Internet-Draft PCEP Extension for WSON RWA March 2019 introductory note that the values have additional usage for the Link Identifier Type field. 9. Acknowledgments The authors would like to thank Adrian Farrel, Julien Meuric, Dhruv Dhody and Benjamin Kaduk for many helpful comments that greatly improved the contents of this draft. 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. [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC5329] A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008. [RFC5440] JP. Vasseur, Ed., JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- Switching Capable Label Switching Routers", RFC 6205, January, 2011. [RFC7570] C. Margaria, et al., "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, July 2015. [RFC7579] G. Bernstein and Y. Lee, "General Network Element Constraint Encoding for GMPLS Controlled Networks", RFC 7579, June 2015. Lee & Casellas Expires September 2019 [Page 29] Internet-Draft PCEP Extension for WSON RWA March 2019 [RFC7581] G. Bernstein and Y. Lee, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", RFC7581, June 2015. [RFC7689] Bernstein et al., "Signaling Extensions for Wavelength Switched Optical Networks", RFC 7689, November 2015. [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, November 2015. [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017. [RFC8253] D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, October 2017. [PCEP-GMPLS] C. Margaria, et al., "PCEP extensions for GMPLS", draft-ietf-pce-gmpls-pcep-extensions, work in progress. 10.2. Informative References [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471. January 2003. [RFC4203] K. Kompella, Ed., Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4655] A. Farrel, JP. Vasseur, G. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC5420, February 2009. Lee & Casellas Expires September 2019 [Page 30] Internet-Draft PCEP Extension for WSON RWA March 2019 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol", RFC 5440, March 2009.[RFC5521] Oki, E, T. Takeda, and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009. [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", RFC 6163, March 2011. [RFC6566] Lee, Y. and Berstein, G. (Editors), "A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments", RFC 6566, March 2012. [RFC7446] Y. Lee, G. Bernstein, (Editors), "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, February 2015. [RFC7449] Y. Lee, G. Bernstein, (Editors), "Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment", RFC 7449, February 2015. [PCEP-LS] Y. Lee, et al., "PCEP Extension for Distribution of Link- State and TE information for Optical Networks", draft-lee- pce-pcep-ls-optical, work in progress. [RFC8126] M. Cotton, B. Leiba, T,.Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, June 2017. Lee & Casellas Expires September 2019 [Page 31] Internet-Draft PCEP Extension for WSON RWA March 2019 11. Contributors Fatai Zhang Huawei Technologies Email: zhangfatai@huawei.com Cyril Margaria Nokia Siemens Networks St Martin Strasse 76 Munich, 81541 Germany Phone: +49 89 5159 16934 Email: cyril.margaria@nsn.com Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo C/ Emilio Vargas 6 Madrid, 28043 Spain Phone: +34 91 3374013 Email: ogondio@tid.es Greg Bernstein Grotto Networking Fremont, CA, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Lee & Casellas Expires September 2019 [Page 32] Internet-Draft PCEP Extension for WSON RWA March 2019 Authors' Addresses Young Lee, Editor Huawei Technologies 5700 Tennyson Parkway Suite 600 Plano, TX 75024, USA Email: leeyoung@huawei.com Ramon Casellas, Editor CTTC PMT Ed B4 Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) Spain Phone: (34) 936452916 Email: ramon.casellas@cttc.es Lee & Casellas Expires September 2019 [Page 33] ./draft-ietf-mpls-rfc8287-len-clarification-04.txt0000644000764400076440000003123513523137465021026 0ustar iustyiusty Network Work group N. Nainar Internet-Draft C. Pignataro Updates: 8287 (if approved) Cisco Systems, Inc. Intended status: Standards Track F. Iqbal Expires: February 9, 2020 Individual A. Vainshtein ECI Telecom August 8, 2019 RFC8287 Sub-TLV Length Clarification draft-ietf-mpls-rfc8287-len-clarification-04 Abstract RFC8287 defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. RFC8287 proposes 3 Target FEC Stack Sub-TLVs. While the standard defines the format and procedure to handle those Sub-TLVs, it does not sufficiently clarify how the length of the Segment ID Sub-TLVs should be computed to include in the Length field of the Sub-TLVs which may result in interoperability issues. This document updates RFC8287 by clarifying the length of each Segment ID Sub-TLVs defined in RFC8287. 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 https://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, 2020. Nainar, et al. Expires February 9, 2020 [Page 1] Internet-Draft RFC8287 Sub-TLV Length Clarification August 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 4. Length field clarification for Segment ID Sub-TLVs . . . . . 3 4.1. IPv4 IGP-Prefix Segment ID Sub-TLV . . . . . . . . . . . 3 4.2. IPv6 IGP-Prefix Segment ID Sub-TLV . . . . . . . . . . . 3 4.3. IGP-Adjacency Segment ID Sub-TLV . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. [RFC8287] proposes 3 Target FEC Stack Sub-TLVs. While the standard defines the format and procedure to handle those Sub-TLVs, it does not sufficiently clarify how the length of the Segment ID Sub-TLVs should be computed to include in the Length field of the Sub-TLVs which may result in interoperability issues. This document updates [RFC8287] by clarifying the length of each Segment ID Sub-TLVs defined in [RFC8287]. Nainar, et al. Expires February 9, 2020 [Page 2] Internet-Draft RFC8287 Sub-TLV Length Clarification August 2019 2. Terminology This document uses the terminologies defined in [RFC8402], [RFC8029], [RFC8287] and so the readers are expected to be familiar with the same. 3. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Length field clarification for Segment ID Sub-TLVs Section 5 of [RFC8287] defines 3 different Segment ID Sub-TLVs that will be included in Target FEC Stack TLV defined in [RFC8029]. The length of each Sub-TLVs MUST be calculated as defined in this section. The TLVs representation defined in section 5.1, 5.2 and 5.3 of [RFC8287] are updated to clarify the length calculation as shown in section 4.1, 4.2 and 4.3 respectively. The updated TLV representation contain explicitly defined length. 4.1. IPv4 IGP-Prefix Segment ID Sub-TLV The Sub-TLV length for IPv4 IGP-Prefix Segment ID MUST be set to 8 as shown in the below TLV 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 = 34 (IPv4 IGP-Prefix SID)| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix Length | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2. IPv6 IGP-Prefix Segment ID Sub-TLV The Sub-TLV length for IPv6 IGP-Prefix Segment ID MUST be set to 20 as shown in the below TLV format: Nainar, et al. Expires February 9, 2020 [Page 3] Internet-Draft RFC8287 Sub-TLV Length Clarification August 2019 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 = 35 (IPv6 IGP-Prefix SID)| Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | IPv6 Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix Length | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3. IGP-Adjacency Segment ID Sub-TLV The Sub-TLV length for IGP-Adjacency Segment ID varies depending on the Adjacency Type and Protocol. In any of the allowed combination of Adjacency Type and Protocol, the sub-TLV length MUST be calculated by including 2 octets of Reserved field. Table 1 below list the length for different combinations of Adj.Type and Protocol. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Length for Adj.Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Parallel | IPv4 | IPv6 | Unnumbered| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF | 20 | 20 | 44 | 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISIS | 24 | 24 | 48 | 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Any | 20 | 20 | 44 | 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table 1. IGP-Adjacency SID Length Comparison For example, when the Adj. Type is set to Parallel Adjacency and the Protocol is set to 0, the Sub-TLV will be as below: Nainar, et al. Expires February 9, 2020 [Page 4] Internet-Draft RFC8287 Sub-TLV Length Clarification August 2019 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 = 36 (IGP-Adjacency SID) | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adj. Type = 1 | Protocol = 0 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Node Identifier (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Node Identifier (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. IANA Considerations This document does not introduce any IANA consideration. 6. Security Considerations This document updates [RFC8287] and does not introduce any additional security considerations. 7. Contributors The below individuals contributed to this document: Zafar Ali, Cisco Systems, Inc. 8. Acknowledgement The authors would like to thank Michael Gorokhovsky and Manohar Doppalapudi for investigating the interop issue during EANTC test. 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, . [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, . Nainar, et al. Expires February 9, 2020 [Page 5] Internet-Draft RFC8287 Sub-TLV Length Clarification August 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . Authors' Addresses Nagendra Kumar Nainar Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: naikumar@cisco.com Carlos Pignataro Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709 US Email: cpignata@cisco.com Faisal Iqbal Individual Canada Email: faisal.iqbal@msn.com Alexander Vainshtein ECI Telecom Israel Email: vainshtein.alex@gmail.com Nainar, et al. Expires February 9, 2020 [Page 6] ./draft-ietf-rmcat-nada-13.txt0000644000764400076440000020732313534502367015402 0ustar iustyiusty Network Working Group X. Zhu Internet-Draft R. Pan Intended status: Experimental M. Ramalho Expires: March 8, 2020 S. Mena Cisco Systems September 5, 2019 NADA: A Unified Congestion Control Scheme for Real-Time Media draft-ietf-rmcat-nada-13 Abstract This document describes NADA (network-assisted dynamic adaptation), a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. 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 https://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 8, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Zhu, et al. Expires March 8, 2020 [Page 1] Internet-Draft NADA September 2019 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. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10 5. Practical Implementation of NADA . . . . . . . . . . . . . . 13 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 13 5.1.1. Estimation of one-way delay and queuing delay . . . . 13 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 13 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 14 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 14 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 15 5.2.2. Adjusting video target rate and sending rate . . . . 16 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 16 6. Discussions and Further Investigations . . . . . . . . . . . 17 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 17 6.2. Method for delay, loss, and marking ratio estimation . . 18 6.3. Impact of parameter values . . . . . . . . . . . . . . . 18 6.4. Sender-based vs. receiver-based calculation . . . . . . . 20 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 20 7. Reference Implementations . . . . . . . . . . . . . . . . . . 20 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Network Node Operations . . . . . . . . . . . . . . 26 A.1. Default behavior of drop tail queues . . . . . . . . . . 27 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 27 A.3. Random Early Marking with Virtual Queues . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Zhu, et al. Expires March 8, 2020 [Page 2] Internet-Draft NADA September 2019 1. Introduction Interactive real-time media applications introduce a unique set of challenges for congestion control. Unlike TCP, the mechanism used for real-time media needs to adapt quickly to instantaneous bandwidth changes, accommodate fluctuations in the output of video encoder rate control, and cause low queuing delay over the network. An ideal scheme should also make effective use of all types of congestion signals, including packet loss, queuing delay, and explicit congestion notification (ECN) [RFC3168] markings. The requirements for the congestion control algorithm are outlined in [I-D.ietf-rmcat-cc-requirements]. It highlights that the desired congestion control scheme should avoid flow starvation and attain a reasonable fair share of bandwidth when competing against other flows, adapt quickly, and operate in a stable manner. This document describes an experimental congestion control scheme called network-assisted dynamic adaptation (NADA). The design of NADA benefits from explicit congestion control signals (e.g., ECN markings) from the network, yet also operates when only implicit congestion indicators (delay and/or loss) are available. Such a unified sender behavior distinguishes NADA from other congestion control schemes for real-time media. In addition, its core congestion control algorithm is designed to guarantee stability for path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms with default parameter choices). It further supports weighted bandwidth sharing among competing video flows with different priorities. The signaling mechanism consists of standard RTP timestamp [RFC3550] and RTCP feedback reports. The definition of the desired RTCP feedback message is described in detail in [I-D.ietf-avtcore-cc-feedback-message] so as to support the successful operation of several congestion control schemes for real- time interactive media. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. System Overview Figure 1 shows the end-to-end system for real-time media transport that NADA operates in. Note that there also exist network nodes along the reverse (potentially uncongested) path that the RTCP Zhu, et al. Expires March 8, 2020 [Page 3] Internet-Draft NADA September 2019 feedback reports traverse. Those network nodes are not shown in the figure for sake of brevity. +---------+ r_vin +--------+ +--------+ +----------+ | Media |<--------| RTP | |Network | | RTP | | Encoder |========>| Sender |=======>| Node |====>| Receiver | +---------+ r_vout +--------+ r_send +--------+ +----------+ /|\ | | | +---------------------------------+ RTCP Feedback Report Figure 1: System Overview o Media encoder with rate control capabilities. It encodes raw media (audio and video) frames into a compressed bitstream which is later packetized into RTP packets. As discussed in [RFC8593], the actual output rate from the encoder r_vout may fluctuate around the target r_vin. Furthermore, it is possible that the encoder can only react to bit rate changes at rather coarse time intervals, e.g., once every 0.5 seconds. o RTP sender: responsible for calculating the NADA reference rate based on network congestion indicators (delay, loss, or ECN marking reports from the receiver), for updating the video encoder with a new target rate r_vin, and for regulating the actual sending rate r_send accordingly. The RTP sender also generates a sending timestamp for each outgoing packet. o RTP receiver: responsible for measuring and estimating end-to-end delay (based on sender timestamp), packet loss (based on RTP sequence number), ECN marking ratios (based on [RFC6679]), and receiving rate (r_recv) of the flow. It calculates the aggregated congestion signal (x_curr) that accounts for queuing delay, ECN markings, and packet losses. The receiver also determines the mode for sender rate adaptation (rmode) based on whether the flow has encountered any standing non-zero congestion. The receiver sends periodic RTCP reports back to the sender, containing values of x_curr, rmode, and r_recv. o Network node with several modes of operation. The system can work with the default behavior of a simple drop tail queue. It can also benefit from advanced AQM features such as PIE [RFC8033], FQ- CoDel [RFC8290], ECN marking based on RED [RFC7567], and PCN marking using a token bucket algorithm ([RFC6660]). Note that network node operation is out of control for the design of NADA. Zhu, et al. Expires March 8, 2020 [Page 4] Internet-Draft NADA September 2019 4. Core Congestion Control Algorithm Like TCP-Friendly Rate Control (TFRC)[Floyd-CCR00] [RFC5348], NADA is a rate-based congestion control algorithm. In its simplest form, the sender reacts to the collection of network congestion indicators in the form of an aggregated congestion signal, and operates in one of two modes: o Accelerated ramp-up: when the bottleneck is deemed to be underutilized, the rate increases multiplicatively with respect to the rate of previously successful transmissions. The rate increase multiplier (gamma) is calculated based on observed round- trip-time and target feedback interval, so as to limit self- inflicted queuing delay. o Gradual rate update: in the presence of non-zero aggregate congestion signal, the sending rate is adjusted in reaction to both its value (x_curr) and its change in value (x_diff). This section introduces the list of mathematical notations and describes the core congestion control algorithm at the sender and receiver, respectively. Additional details on recommended practical implementations are described in Section 5.1 and Section 5.2. 4.1. Mathematical Notations This section summarizes the list of variables and parameters used in the NADA algorithm. Figure 3 also includes the default values for choosing the algorithm parameters either to represent a typical setting in practical applications or based on theoretical and simulation studies. See Section 6.3 for some of the discussions on the impact of parameter values. Additional studies in real-world settings suggested in Section 8 could gather further insight on how to choose and adapt these parameter values in practical deployment. Zhu, et al. Expires March 8, 2020 [Page 5] Internet-Draft NADA September 2019 +--------------+-------------------------------------------------+ | Notation | Variable Name | +--------------+-------------------------------------------------+ | t_curr | Current timestamp | | t_last | Last time sending/receiving a feedback | | delta | Observed interval between current and previous | | | feedback reports: delta = t_curr-t_last | | r_ref | Reference rate based on network congestion | | r_send | Sending rate | | r_recv | Receiving rate | | r_vin | Target rate for video encoder | | r_vout | Output rate from video encoder | | d_base | Estimated baseline delay | | d_fwd | Measured and filtered one-way delay | | d_queue | Estimated queuing delay | | d_tilde | Equivalent delay after non-linear warping | | p_mark | Estimated packet ECN marking ratio | | p_loss | Estimated packet loss ratio | | x_curr | Aggregate congestion signal | | x_prev | Previous value of aggregate congestion signal | | x_diff | Change in aggregate congestion signal w.r.t. | | | its previous value: x_diff = x_curr - x_prev | | rmode | Rate update mode: (0 = accelerated ramp-up; | | | 1 = gradual update) | | gamma | Rate increase multiplier in accelerated ramp-up | | | mode | | loss_int | Measured average loss interval in packet count | | loss_exp | Threshold value for setting the last observed | | | packet loss to expiration | | rtt | Estimated round-trip-time at sender | | buffer_len | Rate shaping buffer occupancy measured in bytes | +--------------+-------------------------------------------------+ Figure 2: List of variables. +--------------+----------------------------------+----------------+ | Notation | Parameter Name | Default Value | +--------------+----------------------------------+----------------+ | PRIO | Weight of priority of the flow | 1.0 | RMIN | Minimum rate of application | 150Kbps | | | supported by media encoder | | | RMAX | Maximum rate of application | 1.5Mbps | | | supported by media encoder | | | XREF | Reference congestion level | 10ms | | KAPPA | Scaling parameter for gradual | 0.5 | | | rate update calculation | | | ETA | Scaling parameter for gradual | 2.0 | | | rate update calculation | | Zhu, et al. Expires March 8, 2020 [Page 6] Internet-Draft NADA September 2019 | TAU | Upper bound of RTT in gradual | 500ms | | | rate update calculation | | | DELTA | Target feedback interval | 100ms | +..............+..................................+................+ | LOGWIN | Observation window in time for | 500ms | | | calculating packet summary | | | | statistics at receiver | | | QEPS | Threshold for determining queuing| 10ms | | | delay build up at receiver | | | DFILT | Bound on filtering delay | 120ms | | GAMMA_MAX | Upper bound on rate increase | 0.5 | | | ratio for accelerated ramp-up | | | QBOUND | Upper bound on self-inflicted | 50ms | | | queuing delay during ramp up | | +..............+..................................+................+ | MULTILOSS | Multiplier for self-scaling the | 7.0 | | | expiration threshold of the last | | | | observed loss (loss_exp) based on| | | | measured average loss interval | | | | (loss_int) | | | QTH | Delay threshold for invoking | 50ms | | | non-linear warping | | | LAMBDA | Scaling parameter in the | 0.5 | | | exponent of non-linear warping | | +..............+..................................+................+ | PLRREF | Reference packet loss ratio | 0.01 | | PMRREF | Reference packet marking ratio | 0.01 | | DLOSS | Reference delay penalty for loss | 10ms | | | when packet loss ratio is at | | | | PLRREF | | | DMARK | Reference delay penalty for ECN | 2ms | | | marking when packet marking | | | | is at PMRREF | | +..............+..................................+................+ | FPS | Frame rate of incoming video | 30 | | BETA_S | Scaling parameter for modulating | 0.1 | | | outgoing sending rate | | | BETA_V | Scaling parameter for modulating | 0.1 | | | video encoder target rate | | | ALPHA | Smoothing factor in exponential | 0.1 | | | smoothing of packet loss and | | | | marking ratios | +--------------+----------------------------------+----------------+ Figure 3: List of algorithm parameters and their default values. Zhu, et al. Expires March 8, 2020 [Page 7] Internet-Draft NADA September 2019 4.2. Receiver-Side Algorithm The receiver-side algorithm can be outlined as below: On initialization: set d_base = +INFINITY set p_loss = 0 set p_mark = 0 set r_recv = 0 set both t_last and t_curr as current time in milliseconds On receiving a media packet: obtain current timestamp t_curr from system clock obtain from packet header sending time stamp t_sent obtain one-way delay measurement: d_fwd = t_curr - t_sent update baseline delay: d_base = min(d_base, d_fwd) update queuing delay: d_queue = d_fwd - d_base update packet loss ratio estimate p_loss update packet marking ratio estimate p_mark update measurement of receiving rate r_recv On time to send a new feedback report (t_curr - t_last > DELTA): calculate non-linear warping of delay d_tilde if packet loss exists calculate current aggregate congestion signal x_curr determine mode of rate adaptation for sender: rmode send feedback containing values of: rmode, x_curr, and r_recv update t_last = t_curr In order for a delay-based flow to hold its ground when competing against loss-based flows (e.g., loss-based TCP), it is important to distinguish between different levels of observed queuing delay. For instance, over wired connections, a moderate queuing delay value on the order of tens of milliseconds is likely self-inflicted or induced by other delay-based flows, whereas a high queuing delay value of several hundreds of milliseconds may indicate the presence of a loss- based flow that does not refrain from increased delay. If the last observed packet loss is within the expiration window of loss_exp (measured in terms of packet counts), the estimated queuing delay follows a non-linear warping: Zhu, et al. Expires March 8, 2020 [Page 8] Internet-Draft NADA September 2019 / d_queue, if d_queue |||||||||=================> +----------+ -----------+ RTP packets Rate Shaping Buffer Figure 4: NADA Sender Structure 5.2.1. Rate shaping buffer The operation of the live video encoder is out of the scope of the design for the congestion control scheme in NADA. Instead, its behavior is treated as a black box. A rate shaping buffer is employed to absorb any instantaneous mismatch between encoder rate output r_vout and regulated sending rate r_send. Its current level of occupancy is measured in bytes and is denoted as buffer_len. A large rate shaping buffer contributes to higher end-to-end delay, which may harm the performance of real-time media communications. Therefore, the sender has a strong incentive to prevent the rate shaping buffer from building up. The mechanisms adopted are: o To deplete the rate shaping buffer faster by increasing the sending rate r_send; and o To limit incoming packets of the rate shaping buffer by reducing the video encoder target rate r_vin. Zhu, et al. Expires March 8, 2020 [Page 15] Internet-Draft NADA September 2019 5.2.2. Adjusting video target rate and sending rate If the level of occupancy in the rate shaping buffer is accessible at the sender, such information can be leveraged to further adjust the target rate of the live video encoder r_vin as well as the actual sending rate r_send. The purpose of such adjustments is to mitigate the additional latencies introduced by the rate shaping buffer. The amount of rate adjustment can be calculated as follows: r_diff_v = min(0.05*r_ref, BETA_V*8*buffer_len*FPS). (11) r_diff_s = min(0.05*r_ref, BETA_S*8*buffer_len*FPS). (12) r_vin = max(RMIN, r_ref - r_diff_v). (13) r_send = min(RMAX, r_ref + r_diff_s). (14) In (11) and (12), the amount of adjustment is calculated as proportional to the size of the rate shaping buffer but is bounded by 5% of the reference rate r_ref calculated from network congestion feedback alone. This ensures that the adjustment introduced by the rate shaping buffer will not counteract with the core congestion control process. Equations (13) and (14) indicate the influence of the rate shaping buffer. A large rate shaping buffer nudges the encoder target rate slightly below -- and the sending rate slightly above -- the reference rate r_ref. The final video target rate (r_vin) and sending rate (r_send) are further bounded within the original range of [RMIN, RMAX]. Intuitively, the amount of extra rate offset needed to completely drain the rate shaping buffer within the duration of a single video frame is given by 8*buffer_len*FPS, where FPS stands for the reference frame rate of the video. The scaling parameters BETA_V and BETA_S can be tuned to balance between the competing goals of maintaining a small rate shaping buffer and deviating from the reference rate point. Empirical observations show that the rate shaping buffer for a responsive live video encoder typically stays empty and only occasionally holds a large frame (e.g., when an intra- frame is produced) in transit. Therefore, the rate adjustment introduced by this mechanism is expected to be minor. For instance, a rate shaping buffer of 2000 Bytes will lead to a rate adjustment of 48Kbps given the recommended scaling parameters of BETA_V = 0.1 and BETA_S = 0.1 and reference frame rate of FPS = 30. 5.3. Feedback Message Requirements The following list of information is required for NADA congestion control to function properly: Zhu, et al. Expires March 8, 2020 [Page 16] Internet-Draft NADA September 2019 o Recommended rate adaptation mode (rmode): a 1-bit flag indicating whether the sender should operate in accelerated ramp-up mode (rmode=0) or gradual update mode (rmode=1). o Aggregated congestion signal (x_curr): the most recently updated value, calculated by the receiver according to Section 4.2. This information can be expressed with a unit of 100 microsecond (i.e., 1/10 of a millisecond) in 15 bits. This allows a maximum value of x_curr at approximately 3.27 second. o Receiving rate (r_recv): the most recently measured receiving rate according to Section 5.1.3. This information is expressed with a unit of bits per second (bps) in 32 bits (unsigned int). This allows a maximum rate of approximately 4.3Gbps, approximately 1000 times of the streaming rate of a typical high-definition (HD) video conferencing session today. This field can be expanded further by a few more bytes, in case an even higher rate need to be specified. The above list of information can be accommodated by 48 bits, or 6 bytes, in total. They can be either included in the feedback report from the receiver, or, in the case where all receiver-side calculations are moved to the sender, derived from per-packet information from the feedback message as defined in [I-D.ietf-avtcore-cc-feedback-message]. Choice of the feedback message interval DELTA is discussed in Section 6.3. A target feedback interval of DELTA=100ms is recommended. 6. Discussions and Further Investigations This section discussed the various design choices made by NADA, potential alternative variants of its implementation, and guidelines on how the key algorithm parameters can be chosen. Section 8 recommends additional experimental setups to further explore these topics. 6.1. Choice of delay metrics The current design works with relative one-way-delay (OWD) as the main indication of congestion. The value of the relative OWD is obtained by maintaining the minimum value of observed OWD over a relatively long time horizon and subtract that out from the observed absolute OWD value. Such an approach cancels out the fixed difference between the sender and receiver clocks. It has been widely adopted by other delay-based congestion control approaches such as [RFC6817]. As discussed in [RFC6817], the time horizon for tracking the minimum OWD needs to be chosen with care: it must be long enough for an opportunity to observe the minimum OWD with zero Zhu, et al. Expires March 8, 2020 [Page 17] Internet-Draft NADA September 2019 standing queue along the path, and sufficiently short so as to timely reflect "true" changes in minimum OWD introduced by route changes and other rare events and to mitigate the cumulative impact of clock rate skew over time. The potential drawback in relying on relative OWD as the congestion signal is that when multiple flows share the same bottleneck, the flow arriving late at the network experiencing a non-empty queue may mistakenly consider the standing queuing delay as part of the fixed path propagation delay. This will lead to slightly unfair bandwidth sharing among the flows. Alternatively, one could move the per-packet statistical handling to the sender instead and use relative round-trip-time (RTT) in lieu of relative OWD, assuming that per-packet acknowledgments are available. The main drawback of RTT-based approach is the noise in the measured delay in the reverse direction. Note that the choice of either delay metric (relative OWD vs. RTT) involves no change in the proposed rate adaptation algorithm. Therefore, comparing the pros and cons regarding which delay metric to adopt can be kept as an orthogonal direction of investigation. 6.2. Method for delay, loss, and marking ratio estimation Like other delay-based congestion control schemes, performance of NADA depends on the accuracy of its delay measurement and estimation module. Appendix A in [RFC6817] provides an extensive discussion on this aspect. The current recommended practice of applying minimum filter with a window size of 15 samples suffices in guarding against processing delay outliers observed in wired connections. For wireless connections with a higher packet delay variation (PDV), more sophisticated techniques on de-noising, outlier rejection, and trend analysis may be needed. More sophisticated methods in packet loss ratio calculation, such as that adopted by [Floyd-CCR00], will likely be beneficial. These alternatives are part of the experiments this document proposes. 6.3. Impact of parameter values In the gradual rate update mode, the parameter TAU indicates the upper bound of round-trip-time (RTT) in feedback control loop. Typically, the observed feedback interval delta is close to the target feedback interval DELTA, and the relative ratio of delta/TAU versus ETA dictates the relative strength of influence from the Zhu, et al. Expires March 8, 2020 [Page 18] Internet-Draft NADA September 2019 aggregate congestion signal offset term (x_offset) versus its recent change (x_diff), respectively. These two terms are analogous to the integral and proportional terms in a proportional-integral (PI) controller. The recommended choice of TAU=500ms, DELTA=100ms and ETA = 2.0 corresponds to a relative ratio of 1:10 between the gains of the integral and proportional terms. Consequently, the rate adaptation is mostly driven by the change in the congestion signal with a long-term shift towards its equilibrium value driven by the offset term. Finally, the scaling parameter KAPPA determines the overall speed of the adaptation and needs to strike a balance between responsiveness and stability. The choice of the target feedback interval DELTA needs to strike the right balance between timely feedback and low RTCP feedback message counts. A target feedback interval of DELTA=100ms is recommended, corresponding to a feedback bandwidth of 16Kbps with 200 bytes per feedback message --- approximately 1.6% overhead for a 1Mbps flow. Furthermore, both simulation studies and frequency-domain analysis in [IETF-95] have established that a feedback interval below 250ms (i.e., more frequently than 4 feedback messages per second) will not break up the feedback control loop of NADA congestion control. In calculating the non-linear warping of delay in (1), the current design uses fixed values of QTH for determining whether to perform the non-linear warping). Its value should be carefully tuned for different operational environments (e.g., over wired vs. wireless connections), so as to avoid the potential risk of prematurely discounting the congestion signal level. It is possible to adapt its value based on past observed patterns of queuing delay in the presence of packet losses. It needs to be noted that the non-linear warping mechanism may lead to multiple NADA streams stuck in loss- based mode when competing against each other. In calculating the aggregate congestion signal x_curr, the choice of DMARK and DLOSS influence the steady-state packet loss/marking ratio experienced by the flow at a given available bandwidth. Higher values of DMARK and DLOSS result in lower steady-state loss/marking ratios, but are more susceptible to the impact of individual packet loss/marking events. While the value of DMARK and DLOSS are fixed and predetermined in the current design, this document also encourages further explorations of a scheme for automatically tuning these values based on desired bandwidth sharing behavior in the presence of other competing loss-based flows (e.g., loss-based TCP). Zhu, et al. Expires March 8, 2020 [Page 19] Internet-Draft NADA September 2019 6.4. Sender-based vs. receiver-based calculation In the current design, the aggregated congestion signal x_curr is calculated at the receiver, keeping the sender operation completely independent of the form of actual network congestion indications (delay, loss, or marking) in use. Alternatively, one can shift receiver-side calculations to the sender, whereby the receiver simply reports on per-packet information via periodic feedback messages as defined in [I-D.ietf-avtcore-cc-feedback-message]. Such an approach enables interoperability amongst senders operating on different congestion control schemes, but requires slightly higher overhead in the feedback messages. See additional discussions in [I-D.ietf-avtcore-cc-feedback-message] regarding the desired format of the feedback messages and the recommended feedback intervals. 6.5. Incremental deployment One nice property of NADA is the consistent video endpoint behavior irrespective of network node variations. This facilitates gradual, incremental adoption of the scheme. Initially, the proposed congestion control mechanism can be implemented without any explicit support from the network, and relies solely on observed relative one-way delay measurements and packet loss ratios as implicit congestion signals. When ECN is enabled at the network nodes with RED-based marking, the receiver can fold its observations of ECN markings into the calculation of the equivalent delay. The sender can react to these explicit congestion signals without any modification. Ultimately, networks equipped with proactive marking based on token bucket level metering can reap the additional benefits of zero standing queues and lower end-to-end delay and work seamlessly with existing senders and receivers. 7. Reference Implementations The NADA scheme has been implemented in both [ns-2] and [ns-3] simulation platforms. The implementation in ns-2 hosts the calculations as described in Section 4.2 at the receiver side, whereas the implementation in ns-3 hosts these receiver-side calculations at the sender for the sake of interoperability. Extensive ns-2 simulation evaluations of an earlier version of the draft are documented in [Zhu-PV13]. An open source implementation of NADA as part of a ns-3 module is available at [ns3-rmcat]. Zhu, et al. Expires March 8, 2020 [Page 20] Internet-Draft NADA September 2019 Evaluation results of the current draft based on ns-3 are presented in [IETF-90] and [IETF-91] for wired test cases as documented in [I-D.ietf-rmcat-eval-test]. Evaluation results of NADA over WiFi- based test cases as defined in [I-D.ietf-rmcat-wireless-tests] are presented in [IETF-93]. These simulation-based evaluations have shown that NADA flows can obtain their fair share of bandwidth when competing against each other. They typically adapt fast in reaction to the arrival and departure of other flows, and can sustain a reasonable throughput when competing against loss-based TCP flows. [IETF-90] describes the implementation and evaluation of NADA in a lab setting. Preliminary evaluation results of NADA in single-flow and multi-flow test scenarios have been presented in [IETF-91]. A reference implementation of NADA has been carried out by modifying the WebRTC module embedded in the Mozilla open source browser. Presentations from [IETF-103] and [IETF-105] document real-world evaluations of the modified browser driven by NADA. The experimental setting involve remote connections with endpoints over either home or enterprise wireless networks. These evaluations validate the effectiveness of NADA flows in recovering quickly from throughput drops caused by intermittent delay spikes over the last-hop wireless connections. 8. Suggested Experiments NADA has been extensively evaluated under various test scenarios, including the collection of test cases specified by [I-D.ietf-rmcat-eval-test] and the subset of WiFi-based test cases in [I-D.ietf-rmcat-wireless-tests]. Additional evaluations have been carried out to characterize how NADA interacts with various active queue management (AQM) schemes such as RED, CoDel, and PIE. Most of these evaluations have been carried out in simulators. A few key test cases have been evaluated in lab environments with implementations embedded in video conferencing clients. It is strongly recommended to carry out implementation and experimentation of NADA in real-world settings. Such exercise will provide insights on how to choose or automatically adapt the values of the key algorithm parameters (see list in Figure 3) as discussed in Section 6. Additional experiments are suggested for the following scenarios and preferably over real-world networks: o Experiments reflecting the setup of a typical WAN connection. o Experiments with ECN marking capability turned on at the network for existing test cases. Zhu, et al. Expires March 8, 2020 [Page 21] Internet-Draft NADA September 2019 o Experiments with multiple NADA streams bearing different user- specified priorities. o Experiments with additional access technologies, especially over cellular networks such as 3G/LTE. o Experiments with various media source contents, including audio only, audio and video, and application content sharing (e.g., slide shows). 9. IANA Considerations This document makes no request of IANA. 10. Security Considerations The rate adaptation mechanism in NADA relies on feedback from the receiver. As such, it is vulnerable to attacks where feedback messages are hijacked, replaced, or intentionally injected with misleading information resulting in denial of service, similar to those that can affect TCP. It is therefore RECOMMENDED that the RTCP feedback message is at least integrity checked. In addition, [I-D.ietf-avtcore-cc-feedback-message] discusses the potential risk of a receiver providing misleading congestion feedback information and the mechanisms for mitigating such risks. The modification of sending rate based on send-side rate shaping buffer may lead to temporary excessive congestion over the network in the presence of a unresponsive video encoder. However, this effect can be mitigated by limiting the amount of rate modification introduced by the rate shaping buffer, bounding the size of the rate shaping buffer at the sender, and maintaining a maximum allowed sending rate by NADA. 11. Acknowledgments The authors would like to thank Randell Jesup, Luca De Cicco, Piers O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede Nielsen, Julius Flohr, Roland Bless, Andreas Smas, and Martin Stiemerling for their valuable review comments and helpful input to this specification. 12. Contributors The following individuals have contributed to the implementation and evaluation of the proposed scheme, and therefore have helped to validate and substantially improve this specification. Zhu, et al. Expires March 8, 2020 [Page 22] Internet-Draft NADA September 2019 Paul E. Jones of Cisco Systems implemented an early version of the NADA congestion control scheme and helped with its lab-based testbed evaluations. Jiantao Fu of Cisco Systems helped with the implementation and extensive evaluation of NADA both in Mozilla web browsers and in earlier simulation-based evaluation efforts. Stefano D'Aronco of ETH Zurich (previously at Ecole Polytechnique Federale de Lausanne when contributing to this work) helped with implementation and evaluation of an early version of NADA in [ns-3]. Charles Ganzhorn contributed to the testbed-based evaluation of NADA during an early stage of its development. 13. References 13.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, . [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, . [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, . [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, . Zhu, et al. Expires March 8, 2020 [Page 23] Internet-Draft NADA September 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [Budzisz-TON11] Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and R. Shorten, "On the Fair Coexistence of Loss- and Delay- Based TCP", IEEE/ACM Transactions on Networking vol. 19, no. 6, pp. 1811-1824, December 2011. [Floyd-CCR00] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "Equation-based Congestion Control for Unicast Applications", ACM SIGCOMM Computer Communications Review vol. 30, no. 4, pp. 43-56, October 2000. [I-D.ietf-avtcore-cc-feedback-message] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Control Protocol (RTCP) Feedback for Congestion Control", draft-ietf-avtcore-cc-feedback-message-04 (work in progress), July 2019. [I-D.ietf-rmcat-cc-codec-interactions] Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "Congestion Control and Codec interactions in RTP Applications", draft-ietf-rmcat-cc-codec-interactions-02 (work in progress), March 2016. [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. [I-D.ietf-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- eval-test-10 (work in progress), May 2019. [I-D.ietf-rmcat-wireless-tests] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real- Time Media over Wireless Networks", draft-ietf-rmcat- wireless-tests-08 (work in progress), July 2019. Zhu, et al. Expires March 8, 2020 [Page 24] Internet-Draft NADA September 2019 [IETF-103] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, J., and S. D'Aronco, "NADA Implementation in Mozilla Browser", November 2018, . [IETF-105] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, J., and S. D'Aronco, "NADA Implementation in Mozilla Browser and Draft Update", July 2019, . [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, "NADA Update: Algorithm, Implementation, and Test Case Evalua6on Results", July 2014, . [IETF-91] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., Jones, P., and S. D'Aronco, "NADA Algorithm Update and Test Case Evaluations", November 2014, . [IETF-93] Zhu, X., Pan, R., Ramalho, M., Mena, S., Ganzhorn, C., Jones, P., D'Aronco, S., and J. Fu, "Updates on NADA", July 2015, . [IETF-95] Zhu, X., Pan, R., Ramalho, M., Mena, S., Jones, P., Fu, J., D'Aronco, S., and C. Ganzhorn, "Updates on NADA: Stability Analysis and Impact of Feedback Intervals", April 2016, . [ns-2] "The Network Simulator - ns-2", . [ns-3] "The Network Simulator - ns-3", . [ns3-rmcat] Fu, J., Mena, S., and X. Zhu, "NS3 open source module of IETF RMCAT congestion control protocols", November 2017, . Zhu, et al. Expires March 8, 2020 [Page 25] Internet-Draft NADA September 2019 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, . [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 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, . [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, . [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm", RFC 8290, DOI 10.17487/RFC8290, January 2018, . [RFC8593] Zhu, X., Mena, S., and Z. Sarker, "Video Traffic Models for RTP Congestion Control Evaluations", RFC 8593, DOI 10.17487/RFC8593, May 2019, . [Zhu-PV13] Zhu, X. and R. Pan, "NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Video", in Proc. IEEE International Packet Video Workshop (PV'13) San Jose, CA, USA, December 2013. Appendix A. Network Node Operations NADA can work with different network queue management schemes and does not assume any specific network node operation. As an example, this appendix describes three variants of queue management behavior Zhu, et al. Expires March 8, 2020 [Page 26] Internet-Draft NADA September 2019 at the network node, leading to either implicit or explicit congestion signals. It needs to be acknowledged that NADA has not yet been tested with non-probabilistic ECN marking behaviors. In all three flavors described below, the network queue operates with the simple first-in-first-out (FIFO) principle. There is no need to maintain per-flow state. The system can scale easily with a large number of video flows and at high link capacity. A.1. Default behavior of drop tail queues In a conventional network with drop tail or RED queues, congestion is inferred from the estimation of end-to-end delay and/or packet loss. Packet drops at the queue are detected at the receiver, and contributes to the calculation of the aggregated congestion signal x_curr. No special action is required at network node. A.2. RED-based ECN marking In this mode, the network node randomly marks the ECN field in the IP packet header following the Random Early Detection (RED) algorithm [RFC7567]. Calculation of the marking probability involves the following steps: on packet arrival: update smoothed queue size q_avg as: q_avg = w*q + (1-w)*q_avg. calculate marking probability p as: / 0, if q < q_lo; | | q_avg - q_lo p= < p_max*--------------, if q_lo <= q < q_hi; | q_hi - q_lo | \ p = 1, if q >= q_hi. Here, q_lo and q_hi corresponds to the low and high thresholds of queue occupancy. The maximum marking probability is p_max. The ECN markings events will contribute to the calculation of an equivalent delay x_curr at the receiver. No changes are required at the sender. Zhu, et al. Expires March 8, 2020 [Page 27] Internet-Draft NADA September 2019 A.3. Random Early Marking with Virtual Queues Advanced network nodes may support random early marking based on a token bucket algorithm originally designed for Pre-Congestion Notification (PCN) [RFC6660]. The early congestion notification (ECN) bit in the IP header of packets are marked randomly. The marking probability is calculated based on a token-bucket algorithm originally designed for the Pre-Congestion Notification (PCN) [RFC6660]. The target link utilization is set as 90%; the marking probability is designed to grow linearly with the token bucket size when it varies between 1/3 and 2/3 of the full token bucket limit. Calculation of the marking probability involves the following steps: upon packet arrival: meter packet against token bucket (r,b); update token level b_tk; calculate the marking probability as: / 0, if b-b_tk < b_lo; | | b-b_tk-b_lo p = < p_max* --------------, if b_lo<= b-b_tk =b_hi. Here, the token bucket lower and upper limits are denoted by b_lo and b_hi, respectively. The parameter b indicates the size of the token bucket. The parameter r is chosen to be below capacity, resulting in slight under-utilization of the link. The maximum marking probability is p_max. The ECN markings events will contribute to the calculation of an equivalent delay x_curr at the receiver. No changes are required at the sender. The virtual queuing mechanism from the PCN-based marking algorithm will lead to additional benefits such as zero standing queues. Authors' Addresses Zhu, et al. Expires March 8, 2020 [Page 28] Internet-Draft NADA September 2019 Xiaoqing Zhu Cisco Systems 12515 Research Blvd., Building 4 Austin, TX 78759 USA Email: xiaoqzhu@cisco.com Rong Pan * * Pending affiliation change. Email: rong.pan@gmail.com Michael A. Ramalho Cisco Systems, Inc. 8000 Hawkins Road Sarasota, FL 34241 USA Phone: +1 919 476 2038 Email: mar42@cornell.edu Sergio Mena de la Cruz Cisco Systems EPFL, Quartier de l'Innovation, Batiment E Ecublens, Vaud 1015 Switzerland Email: semena@cisco.com Zhu, et al. Expires March 8, 2020 [Page 29] ./draft-ietf-mpls-spring-entropy-label-12.txt0000644000764400076440000017075613323057036020423 0ustar iustyiusty Network Working Group S. Kini Internet-Draft Intended status: Standards Track K. Kompella Expires: January 17, 2019 Juniper S. Sivabalan Cisco S. Litkowski Orange R. Shakir Google J. Tantsura July 16, 2018 Entropy label for SPRING tunnels draft-ietf-mpls-spring-entropy-label-12 Abstract Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to Segment Routing 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 https://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 17, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Kini, et al. Expires January 17, 2019 [Page 1] Internet-Draft Entropy Labels for SPRING tunnels July 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4 3. Use-case requiring multipath load-balancing . . . . . . . . . 5 4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 6 5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 8 6. LSP stitching using the Binding-SID . . . . . . . . . . . . . 10 7. Insertion of entropy labels for SPRING path . . . . . . . . . 11 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1.1. Example 1 where the ingress node has a sufficient MSD 12 7.1.2. Example 2 where the ingress node does not have a sufficient MSD . . . . . . . . . . . . . . . . . . . 13 7.2. Considerations for the placement of entropy labels . . . 14 7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 15 7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 16 7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 16 7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 17 7.2.2.3. Adjacency-SID representing a single IP link . . . 17 7.2.2.4. Adjacency-SID representing a single link within an L2 bundle . . . . . . . . . . . . . . . . . . 17 7.2.2.5. Adjacency-SID representing an L2 bundle . . . . . 17 7.2.3. Maximizing number of LSRs that will load-balance . . 18 7.2.4. Preference for a part of the path . . . . . . . . . . 18 7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 18 8. A simple example algorithm . . . . . . . . . . . . . . . . . 18 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 19 10. Options considered . . . . . . . . . . . . . . . . . . . . . 20 10.1. Single EL at the bottom of the stack . . . . . . . . . . 20 10.2. An EL per segment in the stack . . . . . . . . . . . . . 20 10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 21 10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 21 10.5. ELs at readable label stack depths . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 Kini, et al. Expires January 17, 2019 [Page 2] Internet-Draft Entropy Labels for SPRING tunnels July 2018 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Segment Routing [I-D.ietf-spring-segment-routing] is based on source routed tunnels to steer a packet along a particular path. This path is encoded as an ordered list of segments. When applied to the MPLS dataplane [I-D.ietf-spring-segment-routing-mpls], each segment is an LSP (Label Switched Path) with an associated MPLS label value. Hence, label stacking is used to represent the ordered list of segments and the label stack associated with an SR tunnel can be seen as nested LSPs (LSP hierarchy) in the MPLS architecture. Using label stacking to encode the list of segments has implications on the label stack depth. Traffic load-balancing over ECMP (Equal Cost Multi Path) or LAGs (Link Aggregation Groups) is usually based on a hashing function. The local node which performs the load-balancing is required to read some header fields in the incoming packets and then computes a hash based on those fields. The result of the hash is finally mapped to a list of outgoing nexthops. The hashing technique is required to perform a per-flow load-balancing and thus prevents packet misordering. For IP traffic, the usual fields that are hashed are the source address, the destination address, the protocol type, and, if provided by the upper layer, the source port and destination port. The MPLS architecture brings some challenges when an LSR tries to look up at header fields. An LSR (Label Switching Router) needs be able to look up at header fields that are beyond the MPLS label stack while the MPLS header does not provide any information about the upper layer protocol. An LSR must perform a deeper inspection compared to an ingress router which could be challenging for some hardware. Entropy label (EL) [RFC6790] is a technique used in the MPLS data plane to provide entropy for load-balancing. The idea behind the entropy label is that the ingress router computes a hash based on several fields from a given packet and places the result in an additional label, named "entropy label". Then, this entropy label can be used as part of the hash keys used by an LSR. Using the entropy label as part of the hash keys reduces the need for deep packet inspection in the LSR while keeping a good level of entropy in the load-balancing. When the entropy label is used, the keys used in the hashing functions are still a local configuration matter and an LSR may use solely the entropy label or a combination of multiple fields from the incoming packet. Kini, et al. Expires January 17, 2019 [Page 3] Internet-Draft Entropy Labels for SPRING tunnels July 2018 When using LSP hierarchies, there are implications on how [RFC6790] should be applied. The current document addresses the case where a hierarchy is created at a single LSR as required by Segment Routing. A use-case requiring load-balancing with SR is given in Section 3. A recommended solution is described in Section 7 keeping in consideration the limitations of implementations when applying [RFC6790] to deeper label stacks. Options that were considered to arrive at the recommended solution are documented for historical purposes in Section 10. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Abbreviations and Terminology Adj-SID - Adjacency Segment Identifier ECMP - Equal Cost Multi Path EL - Entropy Label ELI - Entropy Label Indicator ELC - Entropy Label Capability ERLD - Entropy Readable Label Depth FEC - Forwarding Equivalent Class LAG - Link Aggregation Group LSP - Label Switched Path LSR - Label Switching Router MPLS - Multiprotocol Label Switching MSD - Maximum SID Depth Node-SID - Node Segment Identifier OAM - Operation, Administration and Maintenance Kini, et al. Expires January 17, 2019 [Page 4] Internet-Draft Entropy Labels for SPRING tunnels July 2018 RLD - Readable Label Depth SID - Segment Identifier SPT - Shortest Path Tree SR - Segment Routing SRGB - Segment Routing Global Block VPN - Virtual Private Network 3. Use-case requiring multipath load-balancing +------+ | | +-------| P3 |-----+ | +-----| |---+ | L3| |L4 +------+ L1| |L2 +----+ | | | | +--| P4 |--+ +-----+ +-----+ +-----+ | +----+ | +-----+ | S |-----| P1 |------------| P2 |--+ +--| D | | | | | | |--+ +--| | +-----+ +-----+ +-----+ | +----+ | +-----+ +--| P5 |--+ +----+ S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs, L1,L2,L3,L4=Links Figure 1: Traffic engineering use-case Traffic-engineering is one of the applications of MPLS and is also a requirement for Segment Routing [RFC7855]. Consider the topology shown in Figure 1. The LSR S requires data to be sent to LSR D along a traffic-engineered path that goes over the link L1. Good load- balancing is also required across equal cost paths (including parallel links). To steer traffic along a path that crosses link L1, the label stack that LSR S creates consists of a label to the Node- SID of LSR P3, stacked over the label for the Adj-SID (Adjacency Segment Identifier) of link L1 and that in turn is stacked over the label to the Node-SID of LSR D. For simplicity lets assume that all LSRs use the same label space for Segment Routing (as a reminder, it is called the SRGB, Segment Routing Global Block). Let L_N-Px denote the label to be used to reach the Node-SID of LSR Px. Let L_A-Ln denote the label used for the Adj-SID for link Ln. In our example, the LSR S must use the label stack . However, to achieve a good load-balancing over the equal cost paths P2-P4-D, Kini, et al. Expires January 17, 2019 [Page 5] Internet-Draft Entropy Labels for SPRING tunnels July 2018 P2-P5-D and the parallel links L3 and L4, a mechanism such as entropy labels [RFC6790] should be adapted for Segment Routing. Indeed, the SPRING architecture with the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) uses nested MPLS LSPs composing the source routed label stack. An MPLS node may have limitations in the number of labels it can push. It may also have a limitation in the number of labels it can inspect when looking for hash keys during load-balancing. While the entropy label is normally inserted at the bottom of the transport tunnel, this may prevent an LSR from taking into account the EL in its load-balancing function if the EL is too deep in the stack. In a Segment Routing environment, it is important to define the considerations that needs to be taken into account when inserting an EL. Multiple ways to apply entropy labels were considered and are documented in Section 10 along with their trade-offs. A recommended solution is described in Section 7. 4. Entropy Readable Label Depth The Entropy Readable Label Depth (ERLD) is defined as the number of labels a router can both: a. Read in an MPLS packet received on its incoming interface(s) (starting from the top of the stack). b. Use in its load-balancing function. The ERLD means that the router will perform load-balancing using the EL label if the EL is placed within the first ERLD labels. A router capable of reading N labels but not using an EL located within those N labels MUST consider its ERLD to be 0. In a distributed switching architecture, each linecard may have a different capability in terms of ERLD. For simplicity, an implementation MAY use the minimum ERLD of all linecards as the ERLD value for the system. There may also be a case where a router has a fast switching path (handled by an ASIC or network processor) and a slow switching path (handled by a CPU) with a different ERLD for each switching path. Again, for simplicity's sake, an implementation MAY use the minimum ERLD as the ERLD value for the system. The drawback of using a single ERLD for a system lower than the capability of one or more specific component is that it may increase the number of ELI/ELs inserted. This leads to an increase of the Kini, et al. Expires January 17, 2019 [Page 6] Internet-Draft Entropy Labels for SPRING tunnels July 2018 label stack size and may have an impact on the capability of the ingress node to push this label stack. Examples: | Payload | +----------+ | Payload | | EL | P7 +----------+ +----------+ | Payload | | EL | | ELI | +----------+ +----------+ +----------+ | Payload | | EL | | ELI | | Label 50 | +----------+ +----------+ +----------+ +----------+ | Payload | | EL | | ELI | | Label 40 | | Label 40 | +----------+ +----------+ +----------+ +----------+ +----------+ | EL | | ELI | | Label 30 | | Label 30 | | Label 30 | +----------+ +----------+ +----------+ +----------+ +----------+ | ELI | | Label 20 | | Label 20 | | Label 20 | | Label 20 | +----------+ +----------+ +----------+ +----------+ +----------+ | Label 16 | | Label 16 | | Label 16 | | Label 16 | | Label 16 | P1 +----------+ +----------+ +----------+ +----------+ +----------+ Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Figure 2: Label stacks with ELI/EL In Figure 2, we consider the displayed packets received on a router interface. We consider also a single ERLD value for the router. o If the router has an ERLD of 3, it will be able to load-balance Packet 1 displayed in Figure 2 using the EL as part of the load- balancing keys. The ERLD value of 3 means that the router can read and take into account the entropy label for load-balancing if it is placed between position 1 (top of the MPLS label stack) and position 3. o If the router has an ERLD of 5, it will be able to load-balance Packets 1 to 3 in Figure 2 using the EL as part of the load- balancing keys. Packets 4 and 5 have the EL placed at a position greater than 5, so the router is not able to read it and use as part of the load-balancing keys. o If the router has an ERLD of 10, it will be able to load-balance all the packets displayed in Figure 2 using the EL as part of the load-balancing keys. To allow an efficient load-balancing based on entropy labels, a router running SPRING SHOULD advertise its ERLD (or ERLDs), so all the other SPRING routers in the network are aware of its capability. Kini, et al. Expires January 17, 2019 [Page 7] Internet-Draft Entropy Labels for SPRING tunnels July 2018 How this advertisement is done is outside the scope of this document (see Section 7.2.1 for potential approaches). To advertise an ERLD value, a SPRING router: o MUST be entropy label capable and, as a consequence, MUST apply the dataplane procedures defined in [RFC6790]. o MUST be able to read an ELI/EL which is located within its ERLD value. o MUST take into account an EL within the first ERLD labels in its load-balancing function. 5. Maximum SID Depth The Maximum SID Depth defines the maximum number of labels that a particular node can impose on a packet. This can include any kind of labels (service, entropy, transport...). In an MPLS network, the MSD is a limit of the head-end of an SR tunnel or a Binding-SID anchor node that performs imposition of additional labels on an existing label stack. Depending on the number of MPLS operations (POP, SWAP...) to be performed before the PUSH, the MSD can vary due to hardware or software limitations. As for the ERLD, different MSD limits can exist within a single node based on the linecard types used in a distributed switching system. Thus, the MSD is a per link and/or per node property. An external controller can be used to program a label stack on a particular node. This node SHOULD advertise its MSD to the controller in order to let the controller know the maximum label stack depth of the path computed that is supported on the head-end. How this advertisement is done is outside the scope of this document ([I-D.ietf-isis-segment-routing-msd], [I-D.ietf-isis-segment-routing-msd] and [I-D.ietf-idr-bgp-ls-segment-routing-msd] provide examples of advertisement of MSD). As the controller does not have the knowledge of the entire label stack to be pushed by the node, in addition to the MSD value, the node SHOULD advertise the type of the MSD. For instance, the MSD value can represent the limit for pushing transport labels only while in reality the node can push an additional service label. As another example, the MSD value can represent the full limit of the node including all label types (transport, service, entropy...). This gives the ability for the controller to program a label stack while leaving room for the local node to add more labels (e.g., service, entropy,...) without reaching the hardware/software Kini, et al. Expires January 17, 2019 [Page 8] Internet-Draft Entropy Labels for SPRING tunnels July 2018 limit. If the node does not provide the meaning of the MSD value, the controller could program an LSP using a number of labels equal to the full limit of the node. When receiving this label stack from the controller, the ingress node may not be able to add any service (L2VPN, L3VPN, EVPN...) label on top of this label stack. The consequence could be for the ingress node to drop service packets that should have been forwarded over the LSP. P7 ---- P8 ---- P9 / \ PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 | \ | ----> P10 \ | IP Pkt | \ | P11 --- P12 --- P13 100 10000 Figure 3 In Figure 3, an IP packet comes into the MPLS network at PE1. All metrics are considered equal to 1 except P12-P13 which is 10000 and P11-P12 which is 100. PE1 wants to steer the traffic using a SPRING path to PE2 along PE1->P1->P7->P8->P9->P4->P5->P10->P11->P12->P13->PE2. By using Adj- SIDs only, PE1 (acting as an I-LSR) will be required to push 10 labels on the IP packet received and thus requires an MSD of 10. If the IP packet should be carried over an MPLS service like a regular layer 3 VPN, an additional service label should be imposed, requiring an MSD of 11 for PE1. In addition, if PE1 wants to insert an ELI/EL for load-balancing purpose, PE1 will need to push 13 labels on the IP packet requiring an MSD of 13. In the SPRING architecture, Node-SIDs or Binding-SIDs can be used to reduce the label stack size. As an example, to steer the traffic on the same path as before, PE1 could use the following label stack: . In this example we consider a combination of Node-SIDs and a Binding-SID advertised by P5 that will stitch the traffic along the path P10->P11->P12->P13. The instruction associated with the Binding-SID at P5 is thus to swap Binding_P5 to Adj_P12-P13 and then push . P5 acts as a stitching node that pushes additional labels on an existing label stack, P5's MSD needs also to be taken into account and may limit the number of labels that can be imposed. Kini, et al. Expires January 17, 2019 [Page 9] Internet-Draft Entropy Labels for SPRING tunnels July 2018 6. LSP stitching using the Binding-SID The Binding-SID allows binding a segment identifier to an existing LSP. As examples, the Binding-SID can represent an RSVP-TE tunnel, an LDP path (through the mapping server advertisement), or a SPRING path. Each tail-end router of an MPLS LSP associated with a Binding- SID has its own entropy label capability. The entropy label capability of the associated LSP is advertised in the control plane protocol used to signal the LSP. In Figure 4, we consider that: o P6, PE2, P10, P11, P12, P13 are pure LDP routers. o PE1, P1, P2, P3, P4, P7, P8, P9 are pure SPRING routers. o P5 is running SPRING and LDP. o P5 acts as a mapping server and advertises Prefix SIDs for the LDP FECs: an index value of 20 is used for PE2. o All SPRING routers use an SRGB of [1000, 1999]. o P6 advertises label 20 for the PE2 FEC. o Traffic from PE1 to PE2 uses the shortest path. PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2 --> +----+ +----+ +----+ +----+ IP Pkt | IP | | IP | | IP | | IP | +----+ +----+ +----+ +----+ |1020| |1020| | 20 | +----+ +----+ +----+ SPRING LDP In terms of packet forwarding, by learning the mapping-server advertisement from P5, PE1 imposes a label 1020 to an IP packet destined to PE2. SPRING routers along the shortest path to PE2 will switch the traffic until it reaches P5. P5 will perform the LSP stitching by swapping the SPRING label 1020 to the LDP label 20 advertised by the nexthop P6. P6 will finally forward the packet using the LDP label towards PE2. PE1 cannot push an ELI/EL for the Binding-SID without knowing that the tail-end of the LSP associated with the binding (PE2) is entropy label capable. Kini, et al. Expires January 17, 2019 [Page 10] Internet-Draft Entropy Labels for SPRING tunnels July 2018 To accommodate the mix of signaling protocols involved during the stitching, the entropy label capability SHOULD be propagated between the signaling domains. Each Binding-SID SHOULD have its own entropy label capability that MUST be inherited from the entropy label capability of the associated LSP. If the router advertising the Binding-SID does not know the ELC state of the target FEC, it MUST NOT set the ELC for the Binding-SID. An ingress node MUST NOT push an ELI/EL associated with a Binding-SID unless this Binding-SID has the entropy label capability. How the entropy label capability is advertised for a Binding-SID is outside the scope of this document (see Section 7.2.1 for potential approaches). In our example, if PE2 is LDP entropy label capable, it will add the entropy label capability in its LDP advertisement. When P5 receives the FEC/label binding for PE2, it learns about the ELC and can set the ELC in the mapping server advertisement. Thus PE1 learns about the ELC of PE2 and may push an ELI/EL associated with the Binding- SID. The proposed solution only works if the SPRING router advertising the Binding-SID is also performing the dataplane LSP stitching. In our example, if the mapping server function is hosted on P8 instead of P5, P8 does not know about the ELC state of PE2's LDP FEC. As a consequence, it does not set the ELC for the associated Binding-SID. 7. Insertion of entropy labels for SPRING path 7.1. Overview The solution described in this section follows the dataplane processing defined in [RFC6790]. Within a SPRING path, a node may be ingress, egress, transit (regarding the entropy label processing described in [RFC6790]), or it can be any combination of those. For example: o The ingress node of a SPRING domain can be an ingress node from an entropy label perspective. o Any LSR terminating a segment of the SPRING path is an egress node (because it terminates the segment) but can also be a transit node if the SPRING path is not terminated because there is a subsequent SPRING MPLS label in the stack. o Any LSR processing a Binding-SID may be a transit node and an ingress node (because it may push additional labels when processing the Binding-SID). Kini, et al. Expires January 17, 2019 [Page 11] Internet-Draft Entropy Labels for SPRING tunnels July 2018 As described earlier, an LSR may have a limitation (the ERLD) on the depth of the label stack that it can read and process in order to do multipath load-balancing based on entropy labels. If an EL does not occur within the ERLD of an LSR in the label stack of an MPLS packet that it receives, then it would lead to poor load- balancing at that LSR. Hence an ELI/EL pair must be within the ERLD of the LSR in order for the LSR to use the EL during load-balancing. Adding a single ELI/EL pair for the entire SPRING path can also lead to poor load-balancing as well because the ELI/EL may not occur within the ERLD of some LSR on the path (if too deep) or may not be present in the stack when it reaches some LSRs (if it is too shallow). In order for the EL to occur within the ERLD of LSRs along the path corresponding to a SPRING label stack, multiple pairs MAY be inserted in this label stack. The insertion of an ELI/EL MUST occur only with a SPRING label advertised by an LSR that advertised an ERLD (the LSR is entropy label capable) or with a SPRING label associated with a Binding-SID that has the ELC set. The ELs among multiple pairs inserted in the stack MAY be the same or different. The LSR that inserts pairs can have limitations on the number of such pairs that it can insert and also the depth at which it can insert them. If, due to limitations, the inserted ELs are at positions such that an LSR along the path receives an MPLS packet without an EL in the label stack within that LSR's ERLD, then the load-balancing performed by that LSR would be poor. An implementation MAY consider multiple criteria when inserting pairs. 7.1.1. Example 1 where the ingress node has a sufficient MSD ECMP LAG LAG PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 Figure 5 In Figure 5, PE1 wants to forward some MPLS VPN traffic over an explicit path to PE2 resulting in the following label stack to be pushed onto the received IP header: . PE1 is limited Kini, et al. Expires January 17, 2019 [Page 12] Internet-Draft Entropy Labels for SPRING tunnels July 2018 to push a maximum of 11 labels (MSD=11). P2, P3 and P6 have an ERLD of 3 while others have an ERLD of 10. PE1 can only add two ELI/EL pairs in the label stack due to its MSD limitation. It should insert them strategically to benefit load- balancing along the longest part of the path. PE1 can take into account multiple parameters when inserting ELs, as examples: o The ERLD value advertised by transit nodes. o The requirement of load-balancing for a particular label value. o Any service provider preference: favor beginning of the path or end of the path. In Figure 5, a good strategy may be to use the following stack . The original stack requests P2 to forward based on a L3 adjacency set that will require load-balancing. Therefore it is important to ensure that P2 can load-balance correctly. As P2 has a limited ERLD of 3, an ELI/EL must be inserted just after the label that P2 will use to forward. On the path to PE2, P3 has also a limited ERLD, but P3 will forward based on a regular adjacency segment that may not require load-balancing. Therefore it does not seem important to ensure that P3 can do load- balancing despite its limited ERLD. The next nodes along the forwarding path have a high ERLD that does not cause any issue, except P6. Moreover, P6 is using some LAGs to PE2 and so is expected to load-balance. It becomes important to insert a new ELI/EL just after the P6 forwarding label. In the case above, the ingress node had a sufficient MSD to ensure end-to-end load-balancing taking into the path attributes. However, there might be cases where the ingress node may not have the necessary label imposition capacity. 7.1.2. Example 2 where the ingress node does not have a sufficient MSD ECMP LAG ECMP ECMP PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- P7 --- P8 --- PE2 Figure 6 Kini, et al. Expires January 17, 2019 [Page 13] Internet-Draft Entropy Labels for SPRING tunnels July 2018 In Figure 6, PE1 wants to forward MPLS VPN traffic over an explicit path to PE2 resulting in the following label stack to be pushed onto the IP header: . PE1 is limited to push a maximum of 11 labels. P2, P3 and P6 have an ERLD of 3 while others have an ERLD of 15. Using a similar strategy as the previous case may lead to a dilemma, as PE1 can only push a single ELI/EL while we may need a minimum of three to load-balance the end-to-end path. An optimized stack that would enable end-to-end load-balancing may be: . A decision needs to be taken to favor some part of the path for load- balancing considering that load-balancing may not work on the other parts. A service provider may decide to place the ELI/EL after the P6 forwarding label as it will allow P4 and P6 to load-balance. Placing the ELI/EL at bottom of the stack is also a possibility enabling load-balancing for P4 and P8. 7.2. Considerations for the placement of entropy labels The sample cases described in the previous section showed that ELI/EL placement when the maximum number of labels to be pushed is limited is not an easy decision and multiple criteria may be taken into account. This section describes some considerations that an implementation MAY take into account when placing ELI/ELs. This list of criteria is not considered exhaustive and an implementation MAY take into account additional criteria or tie-breakers that are not documented here. As the insertion of ELI/ELs is performed by the ingress node, having ingress nodes that do not use the same criteria does not cause an interoperability issue. However, from a network design and operation perspective, it is better to have all ingress routers using the same criteria. An implementation SHOULD try to maximize the possibility of load- balancing along the path by inserting an ELI/EL where multiple equal cost paths are available and minimize the number of ELI/ELs that need to be inserted. In case of a trade-off, an implementation SHOULD provide flexibility to the operator to select the criteria to be considered when placing ELI/ELs or specify a sub-objective for optimization. Kini, et al. Expires January 17, 2019 [Page 14] Internet-Draft Entropy Labels for SPRING tunnels July 2018 2 2 PE1 -- P1 -- P2 --P3 --- P4 --- P5 -- ... -- P8 -- P9 -- PE2 | | P3'--- P4'--- P5' Figure 7 Figure 7 will be used as reference in the following subsections. All metrics are equal to 1, except P3-P4 and P4-P5 which have a metric 2. We consider the MSD of nodes to be the full limit of label imposition (including service labels, entropy labels and transport labels). 7.2.1. ERLD value As mentioned in Section 7.1, the ERLD value is an important parameter to consider when inserting an ELI/EL. If an ELI/EL does not fall within the ERLD of a node on the path, the node will not be able to load-balance the traffic efficiently. The ERLD value can be advertised via protocols and those extensions are described in separate documents (for instance, [I-D.ietf-isis-mpls-elc] and [I-D.ietf-ospf-mpls-elc]). Let's consider a path from PE1 to PE2 using the following stack pushed by PE1: . Using the ERLD as an input parameter can help to minimize the number of required ELI/EL pairs to be inserted. An ERLD value must be retrieved for each SPRING label in the label stack. For a label bound to an adjacency segment, the ERLD is the ERLD of the node that has advertised the adjacency segment. In the example above, the ERLD associated with Adj_P1P2 would be the ERLD of router P1 as P1 will perform the forwarding based on the Adj_P1P2 label. For a label bound to a node segment, multiple strategies MAY be implemented. An implementation MAY try to evaluate the minimum ERLD value along the node segment path. If an implementation cannot find the minimum ERLD along the path of the segment or does not support the computation of the minimum ERLD, it SHOULD instead use the ERLD of the tail-end node. Using the ERLD of the tail-end of the node segment mimics the behavior of [RFC6790] where the ingress takes only care of the egress of the LSP. In the example above, if the implementation supports computation of minimum ERLD along the path, the ERLD associated with label Node_P9 would be the minimum ERLD between nodes {P2,P3,P4 ..., P8}. If the implementation does not support the computation of minimum ERLD, it will consider the ERLD of P9 (tail-end node of Node_P9 SID). While providing the more optimal Kini, et al. Expires January 17, 2019 [Page 15] Internet-Draft Entropy Labels for SPRING tunnels July 2018 ELI/EL placement, evaluating the minimum ERLD increases the complexity of ELI/EL insertion. As the path to the Node-SID may change over time, a recomputation of the minimum ERLD is required for each topology change. This recomputation may require the positions of the ELI/ELs to change. For a label bound to a binding segment, if the binding segment describes a path, an implementation MAY also try to evaluate the minimum ERLD along this path. If the implementation cannot find the minimum ERLD along the path of the segment or does not support this evaluation, it SHOULD instead use the ERLD of the node advertising the Binding-SID. As for the node segment, evaluating the minimum ERLD adds complexity in the ELI/EL insertion process. 7.2.2. Segment type Depending on the type of segment a particular label is bound to, an implementation can deduce that this particular label will be subject to load-balancing on the path. 7.2.2.1. Node-SID An MPLS label bound to a Node-SID represents a path that may cross multiple hops. Load-balancing may be needed on the node starting this path but also on any node along the path. In Figure 7, let's consider a path from PE1 to PE2 using the following stack pushed by PE1: . If, for example, PE1 is limited to push 6 labels, it can add a single ELI/EL within the label stack. An operator may want to favor a placement that would allow load-balancing along the Node-SID path. In Figure 7, P3 which is along the Node-SID path requires load- balancing between two equal-cost paths. An implementation MAY try to evaluate if load-balancing is really required within a node segment path. This could be done by running an additional SPT (Shortest Path Tree) computation and analysing of the node segment path to prevent a node segment that does not really require load-balancing from being preferred when placing ELI/ELs. Such inspection may be time consuming for implementations and without a 100% guarantee, as a node segment path may use LAGs that are invisible to the IP topology. As a simpler approach, an implementation MAY consider that a label bound to a Node-SID will be subject to load-balancing and requires an ELI/EL. Kini, et al. Expires January 17, 2019 [Page 16] Internet-Draft Entropy Labels for SPRING tunnels July 2018 7.2.2.2. Adjacency-set SID An adjacency-set is an Adj-SID that refers to a set of adjacencies. When an adjacency-set segment is used within a label stack, an implementation can deduce that load-balancing is expected at the node that advertised this adjacency segment. An implementation MAY favor the insertion of an ELI/EL after the Adj-SID representing an adjacency-set. 7.2.2.3. Adjacency-SID representing a single IP link When an adjacency segment representing a single IP link is used within a label stack, an implementation can deduce that load- balancing may not be expected at the node that advertised this adjacency segment. An implementation MAY NOT place an ELI/EL after a regular Adj-SID in order to favor the insertion of ELI/ELs following other segments. Readers should note that an adjacency segment representing a single IP link may require load-balancing. This is the case when a LAG (L2 bundle) is implemented between two IP nodes and the L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are not implemented. In such a case, it could be useful to insert an ELI/EL in a readable position for the LSR advertising the label associated with the adjacency segment. To communicate the requirement for load-balancing for a particular Adjacency-SID to ingress nodes, a user can enforce the use of the L2 bundle SR extensions defined in [I-D.ietf-isis-l2bundles] or can declare the single adjacency as an adjacency-set. 7.2.2.4. Adjacency-SID representing a single link within an L2 bundle When the L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, adjacency segments may be advertised for each member of the bundle. In this case, an implementation can deduce that load-balancing is not expected on the LSR advertising this segment and MAY NOT insert an ELI/EL after the corresponding label. 7.2.2.5. Adjacency-SID representing an L2 bundle When the L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, an adjacency segment may be advertised to represent the bundle. In this case, an implementation can deduce that load-balancing is expected on the LSR advertising this segment and MAY insert an ELI/EL after the corresponding label. Kini, et al. Expires January 17, 2019 [Page 17] Internet-Draft Entropy Labels for SPRING tunnels July 2018 7.2.3. Maximizing number of LSRs that will load-balance When placing ELI/ELs, an implementation MAY optimize the number of LSRs that both need to load-balance (i.e., have ECMP paths) and that will be able to perform load-balancing (i.e., the EL label is within their ERLD). Let's consider a path from PE1 to PE2 using the following stack pushed by PE1: . All routers have an ERLD of 10, except P1 and P2 which have an ERLD of 4. PE1 is able to push 6 labels, so only a single ELI/EL can be added. In the example above, adding an ELI/EL after Adj_P1P2 will only allow load-balancing at P1 while inserting it after Adj_PE2P9, will allow load-balancing at P2,P3 ... P9 and maximizing the number of LSRs that can perform load-balancing. 7.2.4. Preference for a part of the path An implementation MAY allow the user to favor a part of the end-to- end path when the number of ELI/ELs that can be pushed is not enough to cover the entire path. As an example, a service provider may want to favor load-balancing at the beginning of the path or at the end of path, so the implementation favors putting the ELI/ELs near the top or near of the bottom of the stack. 7.2.5. Combining criteria An implementation MAY combine multiple criteria to determine the best ELI/ELs placement. However, combining too many criteria could lead to implementation complexity and high resource consumption. Each time the network topology changes, a new evaluation of the ELI/EL placement will be necessary for each impacted LSPs. 8. A simple example algorithm A simple implementation might take into account the ERLD when placing ELI/EL while trying to minimize the number of ELI/ELs inserted and trying to maximize the number of LSRs that can load-balance. The example algorithm is based on the following considerations: o An LSR that can insert a limited number of pairs should insert such pairs deeper in the stack. o An LSR should try to insert pairs at positions to maximize the number of transit LSRs for which the EL occurs within the ERLD of those LSRs. Kini, et al. Expires January 17, 2019 [Page 18] Internet-Draft Entropy Labels for SPRING tunnels July 2018 o An LSR should try to insert the minimum number of such pairs while trying to satisfy the above criteria. The pseudocode of the example algorithm is shown below. Initialize the current EL insertion point to the bottom-most label in the stack that is EL-capable while (local-node can push more pairs OR insertion point is not above label stack) { insert an pair below current insertion point move new insertion point up from current insertion point until ((last inserted EL is below the ERLD) AND (ERLD > 2) AND (new insertion point is EL-capable)) set current insertion point to new insertion point } Figure 8: Example algorithm to insert pairs in a label stack When this algorithm is applied to the example described in Section 3, it will result in ELs being inserted in two positions, one after the label L_N-D and another after L_N-P3. Thus, the resulting label stack would be 9. Deployment Considerations As long as LSR node dataplane capabilities are limited (number of labels that can be pushed, or number of labels that can be inspected), hop-by-hop load-balancing of SPRING encapsulated flows will require trade-offs. The entropy label is still a good and usable solution as it allows load-balancing without having to perform deep packet inspection on each LSR: it does not seem reasonable to have an LSR inspecting UDP ports within a GRE tunnel carried over a 15 label SPRING tunnel. Due to the limited capacity of reading a deep stack of MPLS labels, multiple ELI/ELs may be required within the stack which directly impacts the capacity of the head-end to push a deep stack: each ELI/ EL inserted requires two additional labels to be pushed. Placement strategies of ELI/ELs are required to find the best trade- off. Multiple criteria could be taken into account and some level of customization (by the user) is required to accommodate different deployments. Since analyzing the path of each destination to determine the best ELI/EL placement may be time consuming for the control plane, we encourage implementations to find the best trade- Kini, et al. Expires January 17, 2019 [Page 19] Internet-Draft Entropy Labels for SPRING tunnels July 2018 off between simplicity, resource consumption, and load-balancing efficiency. In the future, hardware and software capacity may increase dataplane capabilities and may remove some of these limitations, increasing load-balancing capability using entropy labels. 10. Options considered Different options that were considered to arrive at the recommended solution are documented in this section. These options are detailed here only for historical purposes. 10.1. Single EL at the bottom of the stack In this option, a single EL is used for the entire label stack. The source LSR S encodes the entropy label at the bottom of the label stack. In the example described in Section 3, it will result in the label stack at LSR S to look like . Note that the notation in [RFC6790] is used to describe the label stack. An issue with this approach is that as the label stack grows due an increase in the number of SIDs, the EL goes correspondingly deeper in the label stack. Hence, transit LSRs have to access a larger number of bytes in the packet header when making forwarding decisions. In the example described in Section 3, if we consider that the LSR P1 has an ERLD of 3, P1 would load-balance traffic poorly on the parallel links L3 and L4 since the EL is below the ERLD of P1. A load-balanced network design using this approach must ensure that all intermediate LSRs have the capability to read the maximum label stack depth as required for the application that uses source routed stacking. This option was rejected since there exist a number of hardware implementations which have a low maximum readable label depth. Choosing this option can lead to a loss of load-balancing using EL in a significant part of the network when that is a critical requirement in a service-provider network. 10.2. An EL per segment in the stack In this option, each segment/label in the stack can be given its own EL. When load-balancing is required to direct traffic on a segment, the source LSR pushes an before pushing the label associated to this segment . In the example described in Section 3, the source LSR S encoded label stack would be where all the ELs can be the same. Accessing the EL at an intermediate LSR is independent of the depth of the label Kini, et al. Expires January 17, 2019 [Page 20] Internet-Draft Entropy Labels for SPRING tunnels July 2018 stack and hence independent of the specific application that uses source routed tunnels with label stacking. A drawback is that the depth of the label stack grows significantly, almost 3 times as the number of labels in the label stack. The network design should ensure that source LSRs have the capability to push such a deep label stack. Also, the bandwidth overhead and potential MTU issues of deep label stacks should be considered in the network design. This option was rejected due to the existence of hardware implementations that can push a limited number of labels on the label stack. Choosing this option would result in a hardware requirement to push two additional labels per tunnel label. Hence it would restrict the number of tunnels that can be stacked in a LSP and hence constrain the types of LSPs that can be created. This was considered unacceptable. 10.3. A re-usable EL for a stack of tunnels In this option an LSR that terminates a tunnel re-uses the EL of the terminated tunnel for the next inner tunnel. It does this by storing the EL from the outer tunnel when that tunnel is terminated and re- inserting it below the next inner tunnel label during the label swap operation. The LSR that stacks tunnels should insert an EL below the outermost tunnel. It should not insert ELs for any inner tunnels. Also, the penultimate hop LSR of a segment must not pop the ELI and EL even though they are exposed as the top labels since the terminating LSR of that segment would re-use the EL for the next segment. In Section 3 above, the source LSR S encoded label stack would be . At P1, the outgoing label stack would be after it has load-balanced to one of the links L3 or L4. At P3 the outgoing label stack would be . At P2, the outgoing label stack would be and it would load-balance to one of the nexthop LSRs P4 or P5. Accessing the EL at an intermediate LSR (e.g., P1) is independent of the depth of the label stack and hence independent of the specific use-case to which the label stack is applied. This option was rejected due to the significant change in label swap operations that would be required for existing hardware. 10.4. EL at top of stack A slight variant of the re-usable EL option is to keep the EL at the top of the stack rather than below the tunnel label. In this case, each LSR that is not terminating a segment should continue to keep the received EL at the top of the stack when forwarding the packet Kini, et al. Expires January 17, 2019 [Page 21] Internet-Draft Entropy Labels for SPRING tunnels July 2018 along the segment. An LSR that terminates a segment should use the EL from the terminated segment at the top of the stack when forwarding onto the next segment. This option was rejected due to the significant change in label swap operations that would be required for existing hardware. 10.5. ELs at readable label stack depths In this option the source LSR inserts ELs for tunnels in the label stack at depths such that each LSR along the path that must load balance is able to access at least one EL. Note that the source LSR may have to insert multiple ELs in the label stack at different depths for this to work since intermediate LSRs may have differing capabilities in accessing the depth of a label stack. The label stack depth access value of intermediate LSRs must be known to create such a label stack. How this value is determined is outside the scope of this document. This value can be advertised using a protocol such as an IGP. Applying this method to the example in Section 3 above, if LSR P1 needs to have the EL within a depth of 4, then the source LSR S encoded label stack would be where all the ELs would typically have the same value. In the case where the ERLD has different values along the path and the LSR that is inserting pairs has no limit on how many pairs it can insert, and it knows the appropriate positions in the stack where they should be inserted, this option is the same as the recommended solution in Section 7. Note that a refinement of this solution which balances the number of pushed labels against the desired entropy is the solution described in Section 7. 11. Acknowledgements The authors would like to thank John Drake, Loa Andersson, Curtis Villamizar, Greg Mirsky, Markus Jork, Kamran Raza, Carlos Pignataro, Bruno Decraene, Chris Bowers, Nobo Akiya, Daniele Ceccarelli and Joe Clarke for their review comments and suggestions. 12. Contributors Kini, et al. Expires January 17, 2019 [Page 22] Internet-Draft Entropy Labels for SPRING tunnels July 2018 Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Wim Hendrickx Nokia Email: wim.henderickx@nokia.com Gunter Van De Velde Nokia Email: gunter.van_de_velde@nokia.com Acee Lindem Cisco Email: acee@cisco.com 13. IANA Considerations This memo includes no request to IANA. Note to RFC Editor: Remove this section before publication. 14. Security Considerations Compared to [RFC6790], this document introduces the notion of ERLD, MSD and may require an ingress node to push multiple ELI/EL. These changes does not introduce any new security considerations beyond those already listed in [RFC6790]. 15. References 15.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, . Kini, et al. Expires January 17, 2019 [Page 23] Internet-Draft Entropy Labels for SPRING tunnels July 2018 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-14 (work in progress), June 2018. 15.2. Informative References [I-D.ietf-isis-mpls-elc] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. Litkowski, "Signaling Entropy Label Capability and Readable Label-stack Depth Using IS-IS", draft-ietf-isis- mpls-elc-03 (work in progress), January 2018. [I-D.ietf-ospf-mpls-elc] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. Litkowski, "Signaling Entropy Label Capability and Readable Label-stack Depth Using OSPF", draft-ietf-ospf- mpls-elc-05 (work in progress), January 2018. [I-D.ietf-isis-l2bundles] Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising L2 Bundle Member Link Attributes in IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), May 2017. [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . Kini, et al. Expires January 17, 2019 [Page 24] Internet-Draft Entropy Labels for SPRING tunnels July 2018 [I-D.ietf-isis-segment-routing-msd] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling MSD (Maximum SID Depth) using IS-IS", draft- ietf-isis-segment-routing-msd-12 (work in progress), May 2018. [I-D.ietf-ospf-segment-routing-msd] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling MSD (Maximum SID Depth) using OSPF", draft- ietf-ospf-segment-routing-msd-14 (work in progress), May 2018. [I-D.ietf-idr-bgp-ls-segment-routing-msd] Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, "Signaling Maximum SID Depth using Border Gateway Protocol Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 (work in progress), October 2017. Authors' Addresses Sriganesh Kini EMail: sriganeshkini@gmail.com Kireeti Kompella Juniper EMail: kireeti@juniper.net Siva Sivabalan Cisco EMail: msiva@cisco.com Stephane Litkowski Orange EMail: stephane.litkowski@orange.com Rob Shakir Google EMail: rjs@rob.sh Kini, et al. Expires January 17, 2019 [Page 25] Internet-Draft Entropy Labels for SPRING tunnels July 2018 Jeff Tantsura EMail: jefftant@gmail.com Kini, et al. Expires January 17, 2019 [Page 26] ./draft-ietf-rtcweb-security-arch-20.txt0000644000764400076440000031012313515346343017427 0ustar iustyiusty RTCWEB E. Rescorla Internet-Draft RTFM, Inc. Intended status: Standards Track July 21, 2019 Expires: January 22, 2020 WebRTC Security Architecture draft-ietf-rtcweb-security-arch-20 Abstract This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". 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 https://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 22, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Rescorla Expires January 22, 2020 [Page 1] Internet-Draft WebRTC Sec. Arch. July 2019 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8 4.2. Media Consent Verification . . . . . . . . . . . . . . . 10 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11 4.4. Communications and Consent Freshness . . . . . . . . . . 11 5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12 5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13 5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13 5.1.2. Generating of SDP Answer . . . . . . . . . . . . . . 14 5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14 5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14 6. Detailed Technical Description . . . . . . . . . . . . . . . 14 6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14 6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15 6.3. Communications Consent . . . . . . . . . . . . . . . . . 17 6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17 6.5. Communications Security . . . . . . . . . . . . . . . . . 18 7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20 7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 23 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions . . . . . . . . . . . . . . . . . . . . . . 24 7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25 7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26 7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27 7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 28 7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 28 7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 29 Rescorla Expires January 22, 2020 [Page 2] Internet-Draft WebRTC Sec. Arch. July 2019 8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29 8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9.1. Communications Security . . . . . . . . . . . . . . . . . 31 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33 9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 34 9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 34 9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34 9.4.3. Privacy of IdP-generated identities and the hosting site . . . . . . . . . . . . . . . . . . . . . . . . 35 9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 35 9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35 9.4.5. Web Security Feature Interactions . . . . . . . . . . 35 9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 36 9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 36 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 37 12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 37 12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37 12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37 12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 38 12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 13.2. Informative References . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The Real-Time Communications on the Web (RTCWEB) working group standardized protocols for real-time communications between Web browsers, generally called "WebRTC" [I-D.ietf-rtcweb-overview]. The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems, (e.g., SIP-based [RFC3261] soft phones) WebRTC communications are directly controlled by some Web server, via a JavaScript (JS) API as shown in Figure 1. Rescorla Expires January 22, 2020 [Page 3] Internet-Draft WebRTC Sec. Arch. July 2019 +----------------+ | | | Web Server | | | +----------------+ ^ ^ / \ HTTP / \ HTTP / \ / \ v v JS API JS API +-----------+ +-----------+ | | Media | | | Browser |<---------->| Browser | | | | | +-----------+ +-----------+ Figure 1: A simple WebRTC system A more complicated system might allow for interdomain calling, as shown in Figure 2. The protocol to be used between the domains is not standardized by WebRTC, but given the installed base and the form of the WebRTC API is likely to be something SDP-based like SIP or something like Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. +--------------+ +--------------+ | | SIP,XMPP,...| | | Web Server |<----------->| Web Server | | | | | +--------------+ +--------------+ ^ ^ | | HTTP | | HTTP | | v v JS API JS API +-----------+ +-----------+ | | Media | | | Browser |<---------------->| Browser | | | | | +-----------+ +-----------+ Figure 2: A multidomain WebRTC system This system presents a number of new security challenges, which are analyzed in [I-D.ietf-rtcweb-security]. This document describes a Rescorla Expires January 22, 2020 [Page 4] Internet-Draft WebRTC Sec. Arch. July 2019 security architecture for WebRTC which addresses the threats and requirements described in that document. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Trust Model The basic assumption of this architecture is that network resources exist in a hierarchy of trust, rooted in the browser, which serves as the user's Trusted Computing Base (TCB). Any security property which the user wishes to have enforced must be ultimately guaranteed by the browser (or transitively by some property the browser verifies). Conversely, if the browser is compromised, then no security guarantees are possible. Note that there are cases (e.g., Internet kiosks) where the user can't really trust the browser that much. In these cases, the level of security provided is limited by how much they trust the browser. Optimally, we would not rely on trust in any entities other than the browser. However, this is unfortunately not possible if we wish to have a functional system. Other network elements fall into two categories: those which can be authenticated by the browser and thus can be granted permissions to access sensitive resources, and those which cannot be authenticated and thus are untrusted. 3.1. Authenticated Entities There are two major classes of authenticated entities in the system: o Calling services: Web sites whose origin we can verify (optimally via HTTPS, but in some cases because we are on a topologically restricted network, such as behind a firewall, and can infer authentication from firewall behavior). o Other users: WebRTC peers whose origin we can verify cryptographically (optimally via DTLS-SRTP). Note that merely being authenticated does not make these entities trusted. For instance, just because we can verify that https://www.example.org/ is owned by Dr. Evil does not mean that we can trust Dr. Evil to access our camera and microphone. However, it gives the user an opportunity to determine whether he wishes to trust Rescorla Expires January 22, 2020 [Page 5] Internet-Draft WebRTC Sec. Arch. July 2019 Dr. Evil or not; after all, if he desires to contact Dr. Evil (perhaps to arrange for ransom payment), it's safe to temporarily give him access to the camera and microphone for the purpose of the call, but he doesn't want Dr. Evil to be able to access his camera and microphone other than during the call. The point here is that we must first identify other elements before we can determine whether and how much to trust them. Additionally, sometimes we need to identify the communicating peer before we know what policies to apply. 3.2. Unauthenticated Entities Other than the above entities, we are not generally able to identify other network elements, thus we cannot trust them. This does not mean that it is not possible to have any interaction with them, but it means that we must assume that they will behave maliciously and design a system which is secure even if they do so. 4. Overview This section describes a typical WebRTC session and shows how the various security elements interact and what guarantees are provided to the user. The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and media privacy with the minimal level of trust in the calling service. Simpler versions with lower levels of security are also possible and are noted in the text where applicable. It's also important to recognize the tension between security (or performance) and privacy. The example shown here is aimed towards settings where we are more concerned about secure calling than about privacy, but as we shall see, there are settings where one might wish to make different tradeoffs--this architecture is still compatible with those settings. For the purposes of this example, we assume the topology shown in the figures below. This topology is derived from the topology shown in Figure 1, but separates Alice and Bob's identities from the process of signaling. Specifically, Alice and Bob have relationships with some Identity Provider (IdP) that supports a protocol (such as OpenID Connect) that can be used to demonstrate their identity to other parties. For instance, Alice might have an account with a social network which she can then use to authenticate to other web sites without explicitly having an account with those sites; this is a fairly conventional pattern on the Web. Section 7.1 provides an overview of Identity Providers and the relevant terminology. Alice and Bob might have relationships with different IdPs as well. This separation of identity provision and signaling isn't particularly important in "closed world" cases where Alice and Bob Rescorla Expires January 22, 2020 [Page 6] Internet-Draft WebRTC Sec. Arch. July 2019 are users on the same social network and have identities based on that domain (Figure 3). However, there are important settings where that is not the case, such as federation (calls from one domain to another; Figure 4) and calling on untrusted sites, such as where two users who have a relationship via a given social network want to call each other on another, untrusted, site, such as a poker site. Note that the servers themselves are also authenticated by an external identity service, the SSL/TLS certificate infrastructure (not shown). As is conventional in the Web, all identities are ultimately rooted in that system. For instance, when an IdP makes an identity assertion, the Relying Party consuming that assertion is able to verify because it is able to connect to the IdP via HTTPS. +----------------+ | | | Signaling | | Server | | | +----------------+ ^ ^ / \ HTTPS / \ HTTPS / \ / \ v v JS API JS API +-----------+ +-----------+ | | Media | | Alice | Browser |<---------->| Browser | Bob | | (DTLS+SRTP)| | +-----------+ +-----------+ ^ ^--+ +--^ ^ | | | | v | | v +-----------+ | | +-----------+ | |<--------+ | | | IdP1 | | | IdP2 | | | +------->| | +-----------+ +-----------+ Figure 3: A call with IdP-based identity Figure 4 shows essentially the same calling scenario but with a call between two separate domains (i.e., a federated case), as in Figure 2. As mentioned above, the domains communicate by some unspecified protocol and providing separate signaling and identity Rescorla Expires January 22, 2020 [Page 7] Internet-Draft WebRTC Sec. Arch. July 2019 allows for calls to be authenticated regardless of the details of the inter-domain protocol. +----------------+ Unspecified +----------------+ | | protocol | | | Signaling |<----------------->| Signaling | | Server | (SIP, XMPP, ...) | Server | | | | | +----------------+ +----------------+ ^ ^ | | HTTPS | | HTTPS | | | | v v JS API JS API +-----------+ +-----------+ | | Media | | Alice | Browser |<--------------------------->| Browser | Bob | | DTLS+SRTP | | +-----------+ +-----------+ ^ ^--+ +--^ ^ | | | | v | | v +-----------+ | | +-----------+ | |<-------------------------+ | | | IdP1 | | | IdP2 | | | +------------------------>| | +-----------+ +-----------+ Figure 4: A federated call with IdP-based identity 4.1. Initial Signaling For simplicity, assume the topology in Figure 3. Alice and Bob are both users of a common calling service; they both have approved the calling service to make calls (we defer the discussion of device access permissions until later). They are both connected to the calling service via HTTPS and so know the origin with some level of confidence. They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the Web environment (with technologies such as Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service. In this example, we show Alice and Bob using a separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all. Rescorla Expires January 22, 2020 [Page 8] Internet-Draft WebRTC Sec. Arch. July 2019 Alice is logged onto the calling service and decides to call Bob. She can see from the calling service that he is online and the calling service presents a JS UI in the form of a button next to Bob's name which says "Call". Alice clicks the button, which initiates a JS callback that instantiates a PeerConnection object. This does not require a security check: JS from any origin is allowed to get this far. Once the PeerConnection is created, the calling service JS needs to set up some media. Because this is an audio/video call, it creates a MediaStream with two MediaStreamTracks, one connected to an audio input and one connected to a video input. At this point the first security check is required: untrusted origins are not allowed to access the camera and microphone, so the browser prompts Alice for permission. In the current W3C API, once some streams have been added, Alice's browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep] containing: o Media channel information o Interactive Connectivity Establishment (ICE) [RFC8445] candidates o A fingerprint attribute binding the communication to a key pair [RFC5763]. Note that this key may simply be ephemerally generated for this call or specific to this domain, and Alice may have a large number of such keys. Prior to sending out the signaling message, the PeerConnection code contacts the identity service and obtains an assertion binding Alice's identity to her fingerprint. The exact details depend on the identity service (though as discussed in Section 7 PeerConnection can be agnostic to them), but for now it's easiest to think of as an OAuth token. The assertion may bind other information to the identity besides the fingerprint, but at minimum it needs to bind the fingerprint. This message is sent to the signaling server, e.g., by XMLHttpRequest [XmlHttpRequest] or by WebSockets [RFC6455], over TLS [RFC5246]. The signaling server processes the message from Alice's browser, determines that this is a call to Bob and sends a signaling message to Bob's browser (again, the format is currently undefined). The JS on Bob's browser processes it, and alerts Bob to the incoming call and to Alice's identity. In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no specific knowledge of the IdP) to verify the assertion. It is also Rescorla Expires January 22, 2020 [Page 9] Internet-Draft WebRTC Sec. Arch. July 2019 possible to have IdPs with which the browser has a specific trustrelationship, as described in Section 7.1. This allows the browser to display a trusted element in the browser chrome indicating that a call is coming in from Alice. If Alice is in Bob's address book, then this interface might also include her real name, a picture, etc. The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI. If Bob agrees a PeerConnection is instantiated with the message from Alice's side. Then, a similar process occurs as on Alice's browser: Bob's browser prompts him for device permission, the media streams are created, and a return signaling message containing media information, ICE candidates, and a fingerprint is sent back to Alice via the signaling service. If Bob has a relationship with an IdP, the message will also come with an identity assertion. At this point, Alice and Bob each know that the other party wants to have a secure call with them. Based purely on the interface provided by the signaling server, they know that the signaling server claims that the call is from Alice to Bob. This level of security is provided merely by having the fingerprint in the message and having that message received securely from the signaling server. Because the far end sent an identity assertion along with their message, they know that this is verifiable from the IdP as well. Note that if the call is federated, as shown in Figure 4 then Alice is able to verify Bob's identity in a way that is not mediated by either her signaling server or Bob's. Rather, she verifies it directly with Bob's IdP. Of course, the call works perfectly well if either Alice or Bob doesn't have a relationship with an IdP; they just get a lower level of assurance. I.e., they simply have whatever information their calling site claims about the caller/callee's identity. Moreover, Alice might wish to make an anonymous call through an anonymous calling site, in which case she would of course just not provide any identity assertion and the calling site would mask her identity from Bob. 4.2. Media Consent Verification As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media consent verification is provided via ICE. Thus, Alice and Bob perform ICE checks with each other. At the completion of these checks, they are ready to send non-ICE data. At this point, Alice knows that (a) Bob (assuming he is verified via his IdP) or someone else who the signaling service is claiming is Bob is willing to exchange traffic with her and (b) that either Bob is at Rescorla Expires January 22, 2020 [Page 10] Internet-Draft WebRTC Sec. Arch. July 2019 the IP address which she has verified via ICE or there is an attacker who is on-path to that IP address detouring the traffic. Note that it is not possible for an attacker who is on-path between Alice and Bob but not attached to the signaling service to spoof these checks because they do not have the ICE credentials. Bob has the same security guarantees with respect to Alice. 4.3. DTLS Handshake Once the requisite ICE checks have completed, Alice and Bob can set up a secure channel or channels. This is performed via DTLS [RFC6347] and DTLS-SRTP [RFC5763] keying for SRTP [RFC3711] for the media channel and SCTP over DTLS [RFC8261] for data channels. Specifically, Alice and Bob perform a DTLS handshake on every component which has been established by ICE. The total number of channels depends on the amount of muxing; in the most likely case we are using both RTP/RTCP mux and muxing multiple media streams on the same channel, in which case there is only one DTLS handshake. Once the DTLS handshake has completed, the keys are exported [RFC5705] and used to key SRTP for the media channels. At this point, Alice and Bob know that they share a set of secure data and/or media channels with keys which are not known to any third-party attacker. If Alice and Bob authenticated via their IdPs, then they also know that the signaling service is not mounting a man- in-the-middle attack on their traffic. Even if they do not use an IdP, as long as they have minimal trust in the signaling service not to perform a man-in-the-middle attack, they know that their communications are secure against the signaling service as well (i.e., that the signaling service cannot mount a passive attack on the communications). 4.4. Communications and Consent Freshness From a security perspective, everything from here on in is a little anticlimactic: Alice and Bob exchange data protected by the keys negotiated by DTLS. Because of the security guarantees discussed in the previous sections, they know that the communications are encrypted and authenticated. The one remaining security property we need to establish is "consent freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline. ICE specifies periodic STUN keepalives but only if media is not flowing. Because the consent issue is more difficult here, we require WebRTC implementations to periodically send keepalives. As described in Section 5.3, these keepalives MUST be based on the consent freshness Rescorla Expires January 22, 2020 [Page 11] Internet-Draft WebRTC Sec. Arch. July 2019 mechanism specified in [RFC7675]. If a keepalive fails and no new ICE channels can be established, then the session is terminated. 5. SDP Identity Attribute The SDP 'identity' attribute is a session-level attribute that is used by an endpoint to convey its identity assertion to its peer. The identity assertion value is encoded as Base-64, as described in Section 4 of [RFC4648]. The procedures in this section are based on the assumption that the identity assertion of an endpoint is bound to the fingerprints of the endpoint. This does not preclude the definition of alternative means of binding an assertion to the endpoint, but such means are outside the scope of this specification. The semantics of multiple 'identity' attributes within an offer or answer are undefined. Implementations SHOULD only include a single 'identity' attribute in an offer or answer and relying parties MAY elect to ignore all but the first 'identity' attribute. Name: identity Value: identity-assertion Usage Level: session Charset Dependent: no Default Value: N/A Name: identity Rescorla Expires January 22, 2020 [Page 12] Internet-Draft WebRTC Sec. Arch. July 2019 Syntax: identity-assertion = identity-assertion-value *(SP identity-extension) identity-assertion-value = base64 identity-extension = extension-name [ "=" extension-value ] extension-name = token extension-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff) ; byte-string from [RFC4566] Example: a=identity:\ eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\ aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line, the carriage return that follows, and whitespace shall be ignored. This specification does not define any extensions for the attribute. The identity-assertion value is a JSON [RFC8259] encoded string. The JSON object contains two keys: "assertion" and "idp". The "assertion" key value contains an opaque string that is consumed by the IdP. The "idp" key value contains a dictionary with one or two further values that identify the IdP. See Section 7.6 for more details. 5.1. Offer/Answer Considerations This section defines the SDP Offer/Answer [RFC3264] considerations for the SDP 'identity' attribute. Within this section, 'initial offer' refers to the first offer in the SDP session that contains an SDP "identity" attribute. 5.1.1. Generating the Initial SDP Offer When an offerer sends an offer, in order to provide its identity assertion to the peer, it includes an 'identity' attribute in the offer. In addition, the offerer includes one or more SDP Rescorla Expires January 22, 2020 [Page 13] Internet-Draft WebRTC Sec. Arch. July 2019 'fingerprint' attributes. The 'identity' attribute MUST be bound to all the 'fingerprint' attributes in the session description. 5.1.2. Generating of SDP Answer If the answerer elects to include an 'identity' attribute, it follows the same steps as those in Section 5.1.1. The answerer can choose to include or omit an 'identity' attribute independently, regardless of whether the offerer did so. 5.1.3. Processing an SDP Offer or Answer When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute information to contact the IdP and verify the identity of the peer. If the identity requires a third-party IdP as described in Section 7.1 then that IdP will need to have been specifically configured. If the identity verification fails, the answerer MUST discard the offer or answer as malformed. 5.1.4. Modifying the Session When modifying a session, if the set of fingerprints is unchanged, then the sender MAY send the same 'identity' attribute. In this case, the established identity MUST be applied to existing DTLS connections as well as new connections established using one of those fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1 requires that each media section use the same set of fingerprints for every media section. If a new identity attribute is received, then the receiver MUST apply that identity to all existing connections. If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all. Because a change in fingerprints also causes a new DTLS connection to be established, the receiver MUST discard all previously established identities. 6. Detailed Technical Description 6.1. Origin and Web Security Issues The basic unit of permissions for WebRTC is the origin [RFC6454]. Because the security of the origin depends on being able to authenticate content from that origin, the origin can only be securely established if data is transferred over HTTPS [RFC2818]. Thus, clients MUST treat HTTP and HTTPS origins as different permissions domains. Note: this follows directly from the origin security model and is stated here merely for clarity. Rescorla Expires January 22, 2020 [Page 14] Internet-Draft WebRTC Sec. Arch. July 2019 Many web browsers currently forbid by default any active mixed content on HTTPS pages. That is, when JavaScript is loaded from an HTTP origin onto an HTTPS page, an error is displayed and the HTTP content is not executed unless the user overrides the error. Any browser which enforces such a policy will also not permit access to WebRTC functionality from mixed content pages (because they never display mixed content). Browsers which allow active mixed content MUST nevertheless disable WebRTC functionality in mixed content settings. Note that it is possible for a page which was not mixed content to become mixed content during the duration of the call. The major risk here is that the newly arrived insecure JS might redirect media to a location controlled by the attacker. Implementations MUST either choose to terminate the call or display a warning at that point. Also note that the security architecture depends on the keying material not being available to move between origins. But, it is assumed that the identity assertion can be passed to anyone that the page cares to. 6.2. Device Permissions Model Implementations MUST obtain explicit user consent prior to providing access to the camera and/or microphone. Implementations MUST at minimum support the following two permissions models for HTTPS origins. o Requests for one-time camera/microphone access. o Requests for permanent access. Because HTTP origins cannot be securely established against network attackers, implementations MUST refuse all permissions grants for HTTP origins. In addition, they SHOULD support requests for access that promise that media from this grant will be sent to a single communicating peer (obviously there could be other requests for other peers), eE.g., "Call customerservice@example.org". The semantics of this request are that the media stream from the camera and microphone will only be routed through a connection which has been cryptographically verified (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP handshake) as being associated with the stated identity. Note that it is unlikely that browsers would have X.509 certificates, but servers might. Browsers servicing such requests SHOULD clearly indicate that identity to the user when asking for permission. The idea behind this type of permissions is that a user might have a Rescorla Expires January 22, 2020 [Page 15] Internet-Draft WebRTC Sec. Arch. July 2019 fairly narrow list of peers he is willing to communicate with, e.g., "my mother" rather than "anyone on Facebook". Narrow permissions grants allow the browser to do that enforcement. API Requirement: The API MUST provide a mechanism for the requesting JS to relinquish the ability to see or modify the media (e.g., via MediaStream.record()). Combined with secure authentication of the communicating peer, this allows a user to be sure that the calling site is not accessing or modifying their conversion. UI Requirement: The UI MUST clearly indicate when the user's camera and microphone are in use. This indication MUST NOT be suppressable by the JS and MUST clearly indicate how to terminate device access, and provide a UI means to immediately stop camera/ microphone input without the JS being able to prevent it. UI Requirement: If the UI indication of camera/microphone use are displayed in the browser such that minimizing the browser window would hide the indication, or the JS creating an overlapping window would hide the indication, then the browser SHOULD stop camera and microphone input when the indication is hidden. [Note: this may not be necessary in systems that are non-windows-based but that have good notifications support, such as phones.] o Browsers MUST NOT permit permanent screen or application sharing permissions to be installed as a response to a JS request for permissions. Instead, they must require some other user action such as a permissions setting or an application install experience to grant permission to a site. o Browsers MUST provide a separate dialog request for screen/ application sharing permissions even if the media request is made at the same time as camera and microphone. o The browser MUST indicate any windows which are currently being shared in some unambiguous way. Windows which are not visible MUST NOT be shared even if the application is being shared. If the screen is being shared, then that MUST be indicated. Browsers MAY permit the formation of data channels without any direct user approval. Because sites can always tunnel data through the server, further restrictions on the data channel do not provide any additional security. (See Section 6.3 for a related issue). Implementations which support some form of direct user authentication SHOULD also provide a policy by which a user can authorize calls only to specific communicating peers. Specifically, the implementation SHOULD provide the following interfaces/controls: Rescorla Expires January 22, 2020 [Page 16] Internet-Draft WebRTC Sec. Arch. July 2019 o Allow future calls to this verified user. o Allow future calls to any verified user who is in my system address book (this only works with address book integration, of course). Implementations SHOULD also provide a different user interface indication when calls are in progress to users whose identities are directly verifiable. Section 6.5 provides more on this. 6.3. Communications Consent Browser client implementations of WebRTC MUST implement ICE. Server gateway implementations which operate only at public IP addresses MUST implement either full ICE or ICE-Lite [RFC8445]. Browser implementations MUST verify reachability via ICE prior to sending any non-ICE packets to a given destination. Implementations MUST NOT provide the ICE transaction ID to JavaScript during the lifetime of the transaction (i.e., during the period when the ICE stack would accept a new response for that transaction). The JS MUST NOT be permitted to control the local ufrag and password, though it of course knows it. While continuing consent is required, the ICE [RFC8445]; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient. The current WG consensus is to use ICE Binding Requests for continuing consent freshness. ICE already requires that implementations respond to such requests, so this approach is maximally compatible. A separate document will profile the ICE timers to be used; see [RFC7675]. 6.4. IP Location Privacy A side effect of the default ICE behavior is that the peer learns one's IP address, which leaks large amounts of location information. This has negative privacy consequences in some circumstances. The API requirements in this section are intended to mitigate this issue. Note that these requirements are not intended to protect the user's IP address from a malicious site. In general, the site will learn at least a user's server reflexive address from any HTTP transaction. Rather, these requirements are intended to allow a site to cooperate with the user to hide the user's IP address from the other side of the call. Hiding the user's IP address from the server requires some sort of explicit privacy preserving mechanism on the client (e.g., Tor Browser [https://www.torproject.org/projects/torbrowser.html.en]) and is out of scope for this specification. Rescorla Expires January 22, 2020 [Page 17] Internet-Draft WebRTC Sec. Arch. July 2019 API Requirement: The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call [note: determining when the call has been answered is a question for the JS.] This enables a user to prevent a peer from learning their IP address if they elect not to answer a call and also from learning whether the user is online. API Requirement: The API MUST provide a mechanism for the calling application JS to indicate that only TURN candidates are to be used. This prevents the peer from learning one's IP address at all. This mechanism MUST also permit suppression of the related address field, since that leaks local addresses. API Requirement: The API MUST provide a mechanism for the calling application to reconfigure an existing call to add non-TURN candidates. Taken together, this and the previous requirement allow ICE negotiation to start immediately on incoming call notification, thus reducing post-dial delay, but also to avoid disclosing the user's IP address until they have decided to answer. They also allow users to completely hide their IP address for the duration of the call. Finally, they allow a mechanism for the user to optimize performance by reconfiguring to allow non- TURN candidates during an active call if the user decides they no longer need to hide their IP address Note that some enterprises may operate proxies and/or NATs designed to hide internal IP addresses from the outside world. WebRTC provides no explicit mechanism to allow this function. Either such enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or the JS, or there needs to be browser support to set the "TURN-only" policy regardless of the site's preferences. 6.5. Communications Security Implementations MUST support SRTP [RFC3711]. Implementations MUST support DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST support SCTP over DTLS [RFC8261]. All media channels MUST be secured via SRTP and SRTCP. Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP MUST be offered for every media channel. WebRTC implementations MUST NOT offer SDP Security Descriptions [RFC4568] or select it if offered. A SRTP MKI MUST NOT be used. All data channels MUST be secured via DTLS. Rescorla Expires January 22, 2020 [Page 18] Internet-Draft WebRTC Sec. Arch. July 2019 All Implementations MUST support DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve [FIPS186]. Earlier drafts of this specification required DTLS 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this writing some implementations do not support DTLS 1.2; endpoints which support only DTLS 1.2 might encounter interoperability issues. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. Implementations MUST favor cipher suites which support (Perfect Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. Endpoints MUST NOT implement TLS False Start [RFC7918]. API Requirement: The API MUST generate a new authentication key pair for every new call by default. This is intended to allow for unlinkability. API Requirement: The API MUST provide a means to reuse a key pair for calls. This can be used to enable key continuity-based authentication, and could be used to amortize key generation costs. API Requirement: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain the negotiated keying material. This requirement preserves the end-to-end security of the media. UI Requirements: A user-oriented client MUST provide an "inspector" interface which allows the user to determine the security characteristics of the media. The following properties SHOULD be displayed "up-front" in the browser chrome, i.e., without requiring the user to ask for them: * A client MUST provide a user interface through which a user may determine the security characteristics for currently-displayed audio and video stream(s) Rescorla Expires January 22, 2020 [Page 19] Internet-Draft WebRTC Sec. Arch. July 2019 * A client MUST provide a user interface through which a user may determine the security characteristics for transmissions of their microphone audio and camera video. * If the far endpoint was directly verified, either via a third- party verifiable X.509 certificate or via a Web IdP mechanism (see Section 7) the "security characteristics" MUST include the verified information. X.509 identities and Web IdP identities have similar semantics and should be displayed in a similar way. The following properties are more likely to require some "drill- down" from the user: * The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) * The "security characteristics" MUST indicate whether PFS is provided. * The "security characteristics" MUST include some mechanism to allow an out-of-band verification of the peer, such as a certificate fingerprint or a Short Authentication String (SAS). These are compared by the peers to authenticate one another. 7. Web-Based Peer Authentication In a number of cases, it is desirable for the endpoint (i.e., the browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are connected. For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side. Alternately, they may be making a call on a site which they minimally trust (such as a poker site) but to someone who has an identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed. While the details vary, what these technologies share is that they have a Web-based (i.e., HTTP/HTTPS) identity provider which attests to Alice's identity. For instance, if Alice has an account at example.org, Alice could use the example.org identity provider to prove to others that Alice is alice@example.org. The development of these technologies allows us Rescorla Expires January 22, 2020 [Page 20] Internet-Draft WebRTC Sec. Arch. July 2019 to separate calling from identity provision: Alice could call you on a poker site but identify herself as alice@example.org. Whatever the underlying technology, the general principle is that the party which is being authenticated is NOT the signaling site but rather the user (and their browser). Similarly, the relying party is the browser and not the signaling site. Thus, the browser MUST generate the input to the IdP assertion process and display the results of the verification process to the user in a way which cannot be imitated by the calling site. The mechanisms defined in this document do not require the browser to implement any particular identity protocol or to support any particular IdP. Instead, this document provides a generic interface which any IdP can implement. Thus, new IdPs and protocols can be introduced without change to either the browser or the calling service. This avoids the need to make a commitment to any particular identity protocol, although browsers may opt to directly implement some identity protocols in order to provide superior performance or UI properties. 7.1. Trust Relationships: IdPs, APs, and RPs Any federated identity protocol has three major participants: Authenticating Party (AP): The entity which is trying to establish its identity. Identity Provider (IdP): The entity which is vouching for the AP's identity. Relying Party (RP): The entity which is trying to verify the AP's identity. The AP and the IdP have an account relationship of some kind: the AP registers with the IdP and is able to subsequently authenticate directly to the IdP (e.g., with a password). This means that the browser must somehow know which IdP(s) the user has an account relationship with. This can either be something that the user configures into the browser or that is configured at the calling site and then provided to the PeerConnection by the Web application at the calling site. The use case for having this information configured into the browser is that the user may "log into" the browser to bind it to some identity. This is becoming common in new browsers. Rescorla Expires January 22, 2020 [Page 21] Internet-Draft WebRTC Sec. Arch. July 2019 However, it should also be possible for the IdP information to simply be provided by the calling application. At a high level there are two kinds of IdPs: Authoritative: IdPs which have verifiable control of some section of the identity space. For instance, in the realm of e-mail, the operator of "example.com" has complete control of the namespace ending in "@example.com". Thus, "alice@example.com" is whoever the operator says it is. Examples of systems with authoritative identity providers include DNSSEC, RFC 4474, and Facebook Connect (Facebook identities only make sense within the context of the Facebook system). Third-Party: IdPs which don't have control of their section of the identity space but instead verify user's identities via some unspecified mechanism and then attest to it. Because the IdP doesn't actually control the namespace, RPs need to trust that the IdP is correctly verifying AP identities, and there can potentially be multiple IdPs attesting to the same section of the identity space. Probably the best-known example of a third-party identity provider is SSL/TLS certificates, where there are a large number of CAs all of whom can attest to any domain name. If an AP is authenticating via an authoritative IdP, then the RP does not need to explicitly configure trust in the IdP at all. The identity mechanism can directly verify that the IdP indeed made the relevant identity assertion (a function provided by the mechanisms in this document), and any assertion it makes about an identity for which it is authoritative is directly verifiable. Note that this does not mean that the IdP might not lie, but that is a trustworthiness judgement that the user can make at the time he looks at the identity. By contrast, if an AP is authenticating via a third-party IdP, the RP needs to explicitly trust that IdP (hence the need for an explicit trust anchor list in PKI-based SSL/TLS clients). The list of trustable IdPs needs to be configured directly into the browser, either by the user or potentially by the browser manufacturer. This is a significant advantage of authoritative IdPs and implies that if third-party IdPs are to be supported, the potential number needs to be fairly small. Rescorla Expires January 22, 2020 [Page 22] Internet-Draft WebRTC Sec. Arch. July 2019 7.2. Overview of Operation In order to provide security without trusting the calling site, the PeerConnection component of the browser must interact directly with the IdP. The details of the mechanism are described in the W3C API specification, but the general idea is that the PeerConnection component downloads JS from a specific location on the IdP dictated by the IdP domain name. That JS (the "IdP proxy") runs in an isolated security context within the browser and the PeerConnection talks to it via a secure message passing channel. Note that there are two logically separate functions here: o Identity assertion generation. o Identity assertion verification. The same IdP JS "endpoint" is used for both functions but of course a given IdP might behave differently and load new JS to perform one function or the other. +--------------------------------------+ | Browser | | | | +----------------------------------+ | | | https://calling-site.example.com | | | | | | | | Calling JS Code | | | | ^ | | | +---------------|------------------+ | | | API Calls | | v | | PeerConnection | | ^ | | | API Calls | | +-----------|-------------+ | +---------------+ | | v | | | | | | IdP Proxy |<-------->| Identity | | | | | | Provider | | | https://idp.example.org | | | | | +-------------------------+ | +---------------+ | | +--------------------------------------+ When the PeerConnection object wants to interact with the IdP, the sequence of events is as follows: Rescorla Expires January 22, 2020 [Page 23] Internet-Draft WebRTC Sec. Arch. July 2019 1. The browser (the PeerConnection component) instantiates an IdP proxy. This allows the IdP to load whatever JS is necessary into the proxy. The resulting code runs in the IdP's security context. 2. The IdP registers an object with the browser that conforms to the API defined in [webrtc-api]. 3. The browser invokes methods on the object registered by the IdP proxy to create or verify identity assertions. This approach allows us to decouple the browser from any particular identity provider; the browser need only know how to load the IdP's JavaScript--the location of which is determined based on the IdP's identity--and to call the generic API for requesting and verifying identity assertions. The IdP provides whatever logic is necessary to bridge the generic protocol to the IdP's specific requirements. Thus, a single browser can support any number of identity protocols, including being forward compatible with IdPs which did not exist at the time the browser was written. 7.3. Items for Standardization There are two parts to this work: o The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for carrying assertions in JSEP messages. This is specified in Section 7.4. o The interface to the IdP, which is defined in the companion W3C WebRTC API specification [webrtc-api]. The WebRTC API specification also defines JavaScript interfaces that the calling application can use to specify which IdP to use. That API also provides access to the assertion-generation capability and the status of the validation process. 7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions An identity assertion binds the user's identity (as asserted by the IdP) to the SDP offer/answer exchange and specifically to the media. In order to achieve this, the PeerConnection must provide the DTLS- SRTP fingerprint to be bound to the identity. This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: Rescorla Expires January 22, 2020 [Page 24] Internet-Draft WebRTC Sec. Arch. July 2019 { "fingerprint": [ { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" } ] } The "fingerprint" value is an array of objects. Each object in the array contains "algorithm" and "digest" values, which correspond directly to the algorithm and digest values in the "fingerprint" attribute of the SDP [RFC8122]. This object is encoded in a JSON [RFC8259] string for passing to the IdP. The identity assertion returned by the IdP, which is encoded in the "identity" attribute, is a JSON object that is encoded as described in Section 7.4.1. This structure does not need to be interpreted by the IdP or the IdP proxy. It is consumed solely by the RP's browser. The IdP merely treats it as an opaque value to be attested to. Thus, new parameters can be added to the assertion without modifying the IdP. 7.4.1. Carrying Identity Assertions Once an IdP has generated an assertion (see Section 7.6), it is attached to the SDP offer/answer message. This is done by adding a new 'identity' attribute to the SDP. The sole contents of this value is the identity assertion. The identity assertion produced by the IdP is encoded into a UTF-8 JSON text, then Base64-encoded [RFC4648] to produce this string. For example: Rescorla Expires January 22, 2020 [Page 25] Internet-Draft WebRTC Sec. Arch. July 2019 v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=fingerprint:sha-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=identity:\ eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\ aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 a=... t=0 0 m=audio 6056 RTP/SAVP 0 a=sendrecv ... Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line, the carriage return that follows, and whitespace shall be ignored. The 'identity' attribute attests to all "fingerprint" attributes in the session description. It is therefore a session-level attribute. Multiple "fingerprint" values can be used to offer alternative certificates for a peer. The "identity" attribute MUST include all fingerprint values that are included in "fingerprint" attributes of the session description. The RP browser MUST verify that the in-use certificate for a DTLS connection is in the set of fingerprints returned from the IdP when verifying an assertion. 7.5. Determining the IdP URI In order to ensure that the IdP is under control of the domain owner rather than someone who merely has an account on the domain owner's server (e.g., in shared hosting scenarios), the IdP JavaScript is hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values: Authority: The authority [RFC3986] at which the IdP's service is hosted. protocol: The specific IdP protocol which the IdP is using. This is a completely opaque IdP-specific string, but allows an IdP to implement two protocols in parallel. This value may be the empty Rescorla Expires January 22, 2020 [Page 26] Internet-Draft WebRTC Sec. Arch. July 2019 string. If no value for protocol is provided, a value of "default" is used. Each IdP MUST serve its initial entry page (i.e., the one loaded by the IdP proxy) from a well-known URI [RFC5785]. The well-known URI for an IdP proxy is formed from the following URI components: 1. The scheme, "https:". An IdP MUST be loaded using HTTPS [RFC2818]. 2. The authority [RFC3986]. As noted above, the authority MAY contain a non-default port number or userinfo sub-component. Both are removed when determining if an asserted identity matches the name of the IdP. 3. The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol. Note that the separator characters '/' (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, lest an attacker be able to direct requests outside of the controlled "/.well-known/" prefix. Query and fragment values MAY be used by including '?' or '#' characters. For example, for the IdP "identity.example.com" and the protocol "example", the URL would be: https://identity.example.com/.well-known/idp-proxy/example The IdP MAY redirect requests to this URL, but they MUST retain the "https" scheme. This changes the effective origin of the IdP, but not the domain of the identities that the IdP is permitted to assert and validate. I.e., the IdP is still regarded as authoritative for the original domain. 7.5.1. Authenticating Party How an AP determines the appropriate IdP domain is out of scope of this specification. In general, however, the AP has some actual account relationship with the IdP, as this identity is what the IdP is attesting to. Thus, the AP somehow supplies the IdP information to the browser. Some potential mechanisms include: o Provided by the user directly. o Selected from some set of IdPs known to the calling site. E.g., a button that shows "Authenticate via Facebook Connect" Rescorla Expires January 22, 2020 [Page 27] Internet-Draft WebRTC Sec. Arch. July 2019 7.5.2. Relying Party Unlike the AP, the RP need not have any particular relationship with the IdP. Rather, it needs to be able to process whatever assertion is provided by the AP. As the assertion contains the IdP's identity in the "idp" field of the JSON-encoded object (see Section 7.6), the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction. Authoritative assertions need only be verifiable. Third-party assertions also MUST be verified against local policy, as described in Section 8.1. 7.6. Requesting Assertions The input to identity assertion is the JSON-encoded object described in Section 7.4 that contains the set of certificate fingerprints the browser intends to use. This string is treated as opaque from the perspective of the IdP. The browser also identifies the origin that the PeerConnection is run in, which allows the IdP to make decisions based on who is requesting the assertion. An application can optionally provide a user identifier hint when specifying an IdP. This value is a hint that the IdP can use to select amongst multiple identities, or to avoid providing assertions for unwanted identities. The "username" is a string that has no meaning to any entity other than the IdP, it can contain any data the IdP needs in order to correctly generate an assertion. An identity assertion that is successfully provided by the IdP consists of the following information: idp: The domain name of an IdP and the protocol string. This MAY identify a different IdP or protocol from the one that generated the assertion. assertion: An opaque value containing the assertion itself. This is only interpretable by the identified IdP or the IdP code running in the client. Figure 5 shows an example assertion formatted as JSON. In this case, the message has presumably been digitally signed/MACed in some way that the IdP can later verify it, but this is an implementation detail and out of scope of this document. Rescorla Expires January 22, 2020 [Page 28] Internet-Draft WebRTC Sec. Arch. July 2019 { "idp":{ "domain": "example.org", "protocol": "bogus" }, "assertion": "{\"identity\":\"bob@example.org\", \"contents\":\"abcdefghijklmnopqrstuvwyz\", \"signature\":\"010203040506\"}" } Figure 5: Example assertion For use in signaling, the assertion is serialized into JSON, Base64-encoded [RFC4648], and used as the value of the "identity" attribute. IdPs SHOULD ensure that any assertions they generate cannot be interpreted in a different context. E.g., they should use a distinct format or have separate cryptographic keys for assertion generation and other purposes. Line breaks are inserted solely for readability. 7.7. Managing User Login In order to generate an identity assertion, the IdP needs proof of the user's identity. It is common practice to authenticate users (using passwords or multi-factor authentication), then use Cookies [RFC6265] or HTTP authentication [RFC7617] for subsequent exchanges. The IdP proxy is able to access cookies, HTTP authentication or other persistent session data because it operates in the security context of the IdP origin. Therefore, if a user is logged in, the IdP could have all the information needed to generate an assertion. An IdP proxy is unable to generate an assertion if the user is not logged in, or the IdP wants to interact with the user to acquire more information before generating the assertion. If the IdP wants to interact with the user before generating an assertion, the IdP proxy can fail to generate an assertion and instead indicate a URL where login should proceed. The application can then load the provided URL to enable the user to enter credentials. The communication between the application and the IdP is described in [webrtc-api]. 8. Verifying Assertions The input to identity validation is the assertion string taken from a decoded 'identity' attribute. Rescorla Expires January 22, 2020 [Page 29] Internet-Draft WebRTC Sec. Arch. July 2019 The IdP proxy verifies the assertion. Depending on the identity protocol, the proxy might contact the IdP server or other servers. For instance, an OAuth-based protocol will likely require using the IdP as an oracle, whereas with a signature-based scheme might be able to verify the assertion without contacting the IdP, provided that it has cached the relevant public key. Regardless of the mechanism, if verification succeeds, a successful response from the IdP proxy consists of the following information: identity: The identity of the AP from the IdP's perspective. Details of this are provided in Section 8.1. contents: The original unmodified string provided by the AP as input to the assertion generation process. Figure 6 shows an example response, which is JSON-formatted. { "identity": "bob@example.org", "contents": "{\"fingerprint\":[ ... ]}" } Figure 6: Example verification result 8.1. Identity Formats The identity provided from the IdP to the RP browser MUST consist of a string representing the user's identity. This string is in the form "@", where "user" consists of any character, and domain is aninternationalized domain name [RFC5890] encoded as a sequence of U-labels. The PeerConnection API MUST check this string as follows: 1. If the "domain" portion of the string is equal to the domain name of the IdP proxy, then the assertion is valid, as the IdP is authoritative for this domain. Comparison of domain names is done using the label equivalence rule defined in Section 2.3.2.4 of [RFC5890]. 2. If the "domain" portion of the string is not equal to the domain name of the IdP proxy, then the PeerConnection object MUST reject the assertion unless both: 1. the IdP domain is trusted as an acceptable third-party IdP; and Rescorla Expires January 22, 2020 [Page 30] Internet-Draft WebRTC Sec. Arch. July 2019 2. local policy is configured to trust this IdP domain for the domain portion of the identity string. Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT be percent-encoded. For example, with a "user" of "user@133" and a "domain" of "identity.example.com", the resulting string will be encoded as "user%40133@identity.example.com". Implementations are cautioned to take care when displaying user identities containing escaped "@" characters. If such characters are unescaped prior to display, implementations MUST distinguish between the domain of the IdP proxy and any domain that might be implied by the portion of the "" portion that appears after the escaped "@" sign. 9. Security Considerations Much of the security analysis of this problem is contained in [I-D.ietf-rtcweb-security] or in the discussion of the particular issues above. In order to avoid repetition, this section focuses on (a) residual threats that are not addressed by this document and (b) threats produced by failure/misbehavior of one of the components in the system. 9.1. Communications Security IF HTTPS is not used to secure communications to the signaling server, and the identity mechanism used in Section 7 is not used, then any on-path attacker can replace the DTLS-SRTP fingerprints in the handshake and thus substitute its own identity for that of either endpoint. Even if HTTPS is used, the signaling server can potentially mount a man-in-the-middle attack unless implementations have some mechanism for independently verifying keys. The UI requirements in Section 6.5 are designed to provide such a mechanism for motivated/security conscious users, but are not suitable for general use. The identity service mechanisms in Section 7 are more suitable for general use. Note, however, that a malicious signaling service can strip off any such identity assertions, though it cannot forge new ones. Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on the security of the third party--this is of course also true of the user's connection to the Web site itself. Users who wish to assure themselves of security against a malicious identity provider can only do so by verifying Rescorla Expires January 22, 2020 [Page 31] Internet-Draft WebRTC Sec. Arch. July 2019 peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band. In order to protect against malicious content JavaScript, that JavaScript MUST NOT be allowed to have direct access to---or perform computations with---DTLS keys. For instance, if content JS were able to compute digital signatures, then it would be possible for content JS to get an identity assertion for a browser's generated key and then use that assertion plus a signature by the key to authenticate a call protected under an ephemeral Diffie-Hellman (DH) key controlled by the content JS, thus violating the security guarantees otherwise provided by the IdP mechanism. Note that it is not sufficient merely to deny the content JS direct access to the keys, as some have suggested doing with the WebCrypto API [webcrypto]. The JS must also not be allowed to perform operations that would be valid for a DTLS endpoint. By far the safest approach is simply to deny the ability to perform any operations that depend on secret information associated with the key. Operations that depend on public information, such as exporting the public key are of course safe. 9.2. Privacy The requirements in this document are intended to allow: o Users to participate in calls without revealing their location. o Potential callees to avoid revealing their location and even presence status prior to agreeing to answer a call. However, these privacy protections come at a performance cost in terms of using TURN relays and, in the latter case, delaying ICE. Sites SHOULD make users aware of these tradeoffs. Note that the protections provided here assume a non-malicious calling service. As the calling service always knows the users status and (absent the use of a technology like Tor) their IP address, they can violate the users privacy at will. Users who wish privacy against the calling sites they are using must use separate privacy enhancing technologies such as Tor. Combined WebRTC/Tor implementations SHOULD arrange to route the media as well as the signaling through Tor. Currently this will produce very suboptimal performance. Additionally, any identifier which persists across multiple calls is potentially a problem for privacy, especially for anonymous calling services. Such services SHOULD instruct the browser to use separate DTLS keys for each call and also to use TURN throughout the call. Otherwise, the other side will learn linkable information that would Rescorla Expires January 22, 2020 [Page 32] Internet-Draft WebRTC Sec. Arch. July 2019 allow them to correlate the browser across multiple calls. Additionally, browsers SHOULD implement the privacy-preserving CNAME generation mode of [RFC7022]. 9.3. Denial of Service The consent mechanisms described in this document are intended to mitigate denial of service attacks in which an attacker uses clients to send large amounts of traffic to a victim without the consent of the victim. While these mechanisms are sufficient to protect victims who have not implemented WebRTC at all, WebRTC implementations need to be more careful. Consider the case of a call center which accepts calls via WebRTC. An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center. Note that this requires user consent in many cases but because the data channel does not need consent, he can use that directly. Since ICE will complete, browsers can then be induced to send large amounts of data to the victim call center if it supports the data channel at all. Preventing this attack requires that automated WebRTC implementations implement sensible flow control and have the ability to triage out (i.e., stop responding to ICE probes on) calls which are behaving badly, and especially to be prepared to remotely throttle the data channel in the absence of plausible audio and video (which the attacker cannot control). Another related attack is for the signaling service to swap the ICE candidates for the audio and video streams, thus forcing a browser to send video to the sink that the other victim expects will contain audio (perhaps it is only expecting audio!) potentially causing overload. Muxing multiple media flows over a single transport makes it harder to individually suppress a single flow by denying ICE keepalives. Either media-level (RTCP) mechanisms must be used or the implementation must deny responses entirely, thus terminating the call. Yet another attack, suggested by Magnus Westerlund, is for the attacker to cross-connect offers and answers as follows. It induces the victim to make a call and then uses its control of other users browsers to get them to attempt a call to someone. It then translates their offers into apparent answers to the victim, which looks like large-scale parallel forking. The victim still responds to ICE responses and now the browsers all try to send media to the victim. Implementations can defend themselves from this attack by only responding to ICE Binding Requests for a limited number of remote ufrags (this is the reason for the requirement that the JS not be able to control the ufrag and password). Rescorla Expires January 22, 2020 [Page 33] Internet-Draft WebRTC Sec. Arch. July 2019 [I-D.ietf-rtcweb-rtp-usage] Section 13 documents a number of potential RTCP-based DoS attacks and countermeasures. Note that attacks based on confusing one end or the other about consent are possible even in the face of the third-party identity mechanism as long as major parts of the signaling messages are not signed. On the other hand, signing the entire message severely restricts the capabilities of the calling application, so there are difficult tradeoffs here. 9.4. IdP Authentication Mechanism This mechanism relies for its security on the IdP and on the PeerConnection correctly enforcing the security invariants described above. At a high level, the IdP is attesting that the user identified in the assertion wishes to be associated with the assertion. Thus, it must not be possible for arbitrary third parties to get assertions tied to a user or to produce assertions that RPs will accept. 9.4.1. PeerConnection Origin Check Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by the browser, so nothing stops a Web attacker from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature over his own keys rather than those generated in the browser. However, that proxy would be in the attacker's origin, not the IdP's origin. Only the browser itself can instantiate a context that (a) is in the IdP's origin and (b) exposes the correct API surface. Thus, the IdP proxy on the sender's side MUST ensure that it is running in the IdP's origin prior to issuing assertions. Note that this check only asserts that the browser (or some other entity with access to the user's authentication data) attests to the request and hence to the fingerprint. It does not demonstrate that the browser has access to the associated private key, and therefore an attacker can attach their own identity to another party's keying material, thus making a call which comes from Alice appear to come from the attacker. See [I-D.ietf-mmusic-sdp-uks] for defenses against this form of attack. 9.4.2. IdP Well-known URI As described in Section 7.5 the IdP proxy HTML/JS landing page is located at a well-known URI based on the IdP's domain name. This requirement prevents an attacker who can write some resources at the IdP (e.g., on one's Facebook wall) from being able to impersonate the IdP. Rescorla Expires January 22, 2020 [Page 34] Internet-Draft WebRTC Sec. Arch. July 2019 9.4.3. Privacy of IdP-generated identities and the hosting site Depending on the structure of the IdP's assertions, the calling site may learn the user's identity from the perspective of the IdP. In many cases this is not an issue because the user is authenticating to the site via the IdP in any case, for instance when the user has logged in with Facebook Connect and is then authenticating their call with a Facebook identity. However, in other case, the user may not have already revealed their identity to the site. In general, IdPs SHOULD either verify that the user is willing to have their identity revealed to the site (e.g., through the usual IdP permissions dialog) or arrange that the identity information is only available to known RPs (e.g., social graph adjacencies) but not to the calling site. The "domain" field of the assertion request can be used to check that the user has agreed to disclose their identity to the calling site; because it is supplied by the PeerConnection it can be trusted to be correct. 9.4.4. Security of Third-Party IdPs As discussed above, each third-party IdP represents a new universal trust point and therefore the number of these IdPs needs to be quite limited. Most IdPs, even those which issue unqualified identities such as Facebook, can be recast as authoritative IdPs (e.g., 123456@facebook.com). However, in such cases, the user interface implications are not entirely desirable. One intermediate approach is to have special (potentially user configurable) UI for large authoritative IdPs, thus allowing the user to instantly grasp that the call is being authenticated by Facebook, Google, etc. 9.4.4.1. Confusable Characters Because a broad range of characters are permitted in identity strings, it may be possible for attackers to craft identities which are confusable with other identities (see [RFC6943] for more on this topic). This is a problem with any identifier space of this type (e.g., e-mail addresses). Those minting identifers should avoid mixed scripts and similar confusable characters. Those presenting these identifiers to a user should consider highlighting cases of mixed script usage (see [RFC5890], section 4.4). Other best practices are still in development. 9.4.5. Web Security Feature Interactions A number of optional Web security features have the potential to cause issues for this mechanism, as discussed below. Rescorla Expires January 22, 2020 [Page 35] Internet-Draft WebRTC Sec. Arch. July 2019 9.4.5.1. Popup Blocking When popup blocking is in use, the IdP proxy is unable to generate popup windows, dialogs or any other form of user interactions. This prevents the IdP proxy from being used to circumvent user interaction. The "LOGINNEEDED" message allows the IdP proxy to inform the calling site of a need for user login, providing the information necessary to satisfy this requirement without resorting to direct user interaction from the IdP proxy itself. 9.4.5.2. Third Party Cookies Some browsers allow users to block third party cookies (cookies associated with origins other than the top level page) for privacy reasons. Any IdP which uses cookies to persist logins will be broken by third-party cookie blocking. One option is to accept this as a limitation; another is to have the PeerConnection object disable third-party cookie blocking for the IdP proxy. 10. IANA Considerations This specification defines the "identity" SDP attribute per the procedures of Section 8.2.4 of [RFC4566]. The required information for the registration is included here: Contact Name: IESG (iesg@ietf.org) Attribute Name: identity Long Form: identity Type of Attribute: session-level Charset Considerations: This attribute is not subject to the charset attribute. Purpose: This attribute carries an identity assertion, binding an identity to the transport-level security session. Appropriate Values: See Section 5 of RFCXXXX [[Editor Note: This document.]] Mux Category: NORMAL. This section reqisters the "idp-proxy" well-known URI from [RFC5785]. URI suffix: idp-proxy Rescorla Expires January 22, 2020 [Page 36] Internet-Draft WebRTC Sec. Arch. July 2019 Change controller: IETF 11. Acknowledgements Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin Thomson, Magnus Westerland. Matthew Kaufman provided the UI material in Section 6.5. Christer Holmberg provided the initial version of Section 5.1. 12. Changes [RFC Editor: Please remove this section prior to publication.] 12.1. Changes since -15 Rewrite the Identity section in more conventional offer/answer format. Clarify rules on changing identities. 12.2. Changes since -11 Update discussion of IdP security model Replace "domain name" with RFC 3986 Authority Clean up discussion of how to generate IdP URI. Remove obsolete text about null cipher suites. Remove obsolete appendixes about older IdP systems Require support for ECDSA, PFS, and AEAD 12.3. Changes since -10 Update cipher suite profiles. Rework IdP interaction based on implementation experience in Firefox. 12.4. Changes since -06 Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG Forbade use in mixed content as discussed in Orlando. Rescorla Expires January 22, 2020 [Page 37] Internet-Draft WebRTC Sec. Arch. July 2019 Added a requirement to surface NULL ciphers to the top-level. Tried to clarify SRTP versus DTLS-SRTP. Added a section on screen sharing permissions. Assorted editorial work. 12.5. Changes since -05 The following changes have been made since the -05 draft. o Response to comments from Richard Barnes o More explanation of the IdP security properties and the federation use case. o Editorial cleanup. 12.6. Changes since -03 Version -04 was a version control mistake. Please ignore. The following changes have been made since the -04 draft. o Move origin check from IdP to RP per discussion in YVR. o Clarified treatment of X.509-level identities. o Editorial cleanup. 12.7. Changes since -03 12.8. Changes since -02 The following changes have been made since the -02 draft. o Forbid persistent HTTP permissions. o Clarified the text in S 5.4 to clearly refer to requirements on the API to provide functionality to the site. o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp o Retarget the continuing consent section to assume Binding Requests o Added some more privacy and linkage text in various places. Rescorla Expires January 22, 2020 [Page 38] Internet-Draft WebRTC Sec. Arch. July 2019 o Editorial improvements 13. References 13.1. Normative References [FIPS186] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 2013. [I-D.ietf-mmusic-sdp-uks] Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-06 (work in progress), July 2019. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "JavaScript Session Establishment Protocol", draft-ietf-rtcweb-jsep-26 (work in progress), February 2019. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-19 (work in progress), November 2017. [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-26 (work in progress), March 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-12 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . Rescorla Expires January 22, 2020 [Page 39] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [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, . [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, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [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, . [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, . Rescorla Expires January 22, 2020 [Page 40] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [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, . [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, . [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Rescorla Expires January 22, 2020 [Page 41] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [webcrypto] editors, W., "Web Cryptography API", June 2013. Available at http://www.w3.org/TR/WebCryptoAPI/ [webrtc-api] editors, W., "WebRTC 1.0: Real-time Communication Between Browsers", October 2011. Available at http://dev.w3.org/2011/webrtc/editor/ webrtc.html 13.2. Informative References [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, . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . Rescorla Expires January 22, 2020 [Page 42] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, . [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, . [XmlHttpRequest] van Kesteren, A., "XMLHttpRequest Level 2", January 2012. Author's Address Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 678 2350 Email: ekr@rtfm.com Rescorla Expires January 22, 2020 [Page 43] ./draft-ietf-mpls-sr-over-ip-07.txt0000644000764400076440000012426513501460177016351 0ustar iustyiusty Network Working Group X. Xu Internet-Draft Alibaba, Inc Intended status: Standards Track S. Bryant Expires: December 18, 2019 Huawei A. Farrel Old Dog Consulting S. Hassan Cisco W. Henderickx Nokia Z. Li Huawei June 16, 2019 SR-MPLS over IP draft-ietf-mpls-sr-over-ip-07 Abstract MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS can be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations. This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP as defined in RFC 7510. 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 https://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." Xu, et al. Expires December 18, 2019 [Page 1] Internet-Draft SR-MPLS over IP June 2019 This Internet-Draft will expire on December 18, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 3.1.1. FIB Construction Example . . . . . . . . . . . . . . 6 3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 8 3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 9 3.2.2. Packet Forwarding without Penultimate Hop Popping . . 10 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls] is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS uses an MPLS label stack to encode a source routing instruction set. This can be used to realize a source routing mechanism that can operate across MPLS, IPv4, and IPv6 data planes. This approach makes no changes to SR-MPLS specifications and Xu, et al. Expires December 18, 2019 [Page 2] Internet-Draft SR-MPLS over IP June 2019 allows interworking with SR-MPLS implementations. More specifically, the source routing instruction set information contained in a source routed packet could be uniformly encoded as an MPLS label stack no matter whether the underlay is IPv4, IPv6 (including Segment Routing for IPv6 (SRv6) [RFC8354]), or MPLS. This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP [RFC7510]. Section 2 describes various use cases for the tunneling SR-MPLS over IP. Section 3 describes a typical application scenario and how the packet forwarding happens. 1.1. Terminology This memo makes use of the terms defined in [RFC3031] and [I-D.ietf-spring-segment-routing-mpls]. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Use Cases Tunneling SR-MPLS using IPv4 and/or IPv6 (including SRv6) tunnels is useful at least in the use cases listed below. In all cases, this can be enabled using an IP tunneling mechanism such as MPLS-in-UDP as described in [RFC7510]. The tunnel selected MUST have its remote end point (destination) address equal to the address of the next SR-MPLS capable node identified as being on the SR path (i.e., the egress of the active segment). The local end point (source) address is set to an address of the encapsulating node. [RFC7510] gives further advice on how to set the source address if the UDP zero-checksum mode is used with MPLS-in-UDP. Using UDP as the encapsulation may be particularly beneficial because it is agnostic of the underlying transport. o Incremental deployment of the SR-MPLS technology may be facilitated by tunneling SR-MPLS packets across parts of a network that are not SR-MPLS as shown in Figure 1. This demonstrates how islands of SR-MPLS may be connected across a legacy network. It may be particularly useful for joining sites (such as data centers). Xu, et al. Expires December 18, 2019 [Page 3] Internet-Draft SR-MPLS over IP June 2019 ________________________ _______ ( ) _______ ( ) ( IP Network ) ( ) ( SR-MPLS ) ( ) ( SR-MPLS ) ( Network ) ( ) ( Network ) ( -------- -------- ) ( | Border | SR-in-UDP Tunnel | Border | ) ( | Router |========================| Router | ) ( | R1 | | R2 | ) ( -------- -------- ) ( ) ( ) ( ) ( ) ( ) ( ) (_______) ( ) (_______) (________________________) Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites o If encoding of entropy ([RFC6790] is desired, IP tunneling mechanisms that allow encoding of entropy, such as MPLS-in-UDP encapsulation [RFC7510] where the source port of the UDP header is used as an entropy field, may be used to maximize the utilization of ECMP and/or LAG, especially when it is difficult to make use of the entropy label mechanism. This is to be contrasted with [RFC4023] where MPLS-in-IP does not provide for an entropy mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) for more discussion about using entropy labels in SR-MPLS. o Tunneling MPLS over IP provides a technology that enables SR in an IPv4 and/or IPv6 network where the routers do not support SRv6 capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS forwarding is not an option. This is shown in Figure 2. Xu, et al. Expires December 18, 2019 [Page 4] Internet-Draft SR-MPLS over IP June 2019 __________________________________ __( IP Network )__ __( )__ ( -- -- -- ) -------- -- -- |SR| -- |SR| -- |SR| -- -------- | Ingress| |IR| |IR| | | |IR| | | |IR| | | |IR| | Egress | --->| Router |===========| |======| |======| |======| Router |---> | SR | | | | | | | | | | | | | | | | | | SR | -------- -- -- | | -- | | -- | | -- -------- (__ -- -- -- __) (__ __) (__________________________________) Key: IR : IP-only Router SR : SR-MPLS-capable Router == : SR-MPLS in UDP Tunnel Figure 2: SR-MPLS Enabled Within an IP Network 3. Procedures of SR-MPLS over IP This section describes the construction of forwarding information base (FIB) entries and the forwarding behavior that allow the deployment of SR-MPLS when some routers in the network are IP only (i.e., do not support SR-MPLS). Note that the examples in Section 3.1.1 and Section 3.2 assume that OSPF or ISIS is enabled: in fact, other mechanisms of discovery and advertisement could be used including other routing protocols (such as BGP) or a central controller. 3.1. Forwarding Entry Construction This sub-section describes the how to construct the forwarding information base (FIB) entry on an SR-MPLS-capable router when some or all of the next-hops along the shortest path towards a prefix Segment Identifier (prefix-SID) are IP-only routers. Section 3.1.1 provides a concrete example of how the process applies when using OSPF or ISIS. Consider router A that receives a labeled packet with top label L(E) that corresponds to the prefix-SID SID(E) of prefix P(E) advertised by router E. Suppose the i-th next-hop router (termed NHi) along the shortest path from router A toward SID(E) is not SR-MPLS capable while both routers A and E are SR-MPLS capable. The following processing steps apply: Xu, et al. Expires December 18, 2019 [Page 5] Internet-Draft SR-MPLS over IP June 2019 o Router E is SR-MPLS capable, so it advertises a Segment Routing Global Block (SRGB). The SRGB is defined in [RFC8402]. There are a number of ways that the advertisement can be achieved including IGPs, BGP, configuration/management protocols. For example, see [I-D.ietf-bess-datacenter-gateway]. o When Router E advertises the prefix-SID SID(E) of prefix P(E) it MUST also advertise the encapsulation endpoint and the tunnel type of any tunnel used to reach E. This information is flooded domain wide. o If A and E are in different routing domains then the information MUST be flooded into both domains. How this is achieved depends on the advertisement mechanism being used. The objective is that router A knows the characteristics of router E that originated the advertisement of SID(E). o Router A programs the FIB entry for prefix P(E) corresponding to the SID(E) according to whether a pop or swap action is advertised for the prefix. The resulting action may be: * pop the top label * swap the top label to a value equal to SID(E) plus the lower bound of the SRGB of E Once constructed, the FIB can be used by a router to tell it how to process packets. It encapsulates the packets according to the appropriate encapsulation advertised for the segment and then it sends the packets towards the next hop NHi. 3.1.1. FIB Construction Example This section is non-normative and provides a worked example of how a FIB might be constructed using OSPF and ISIS extensions. It is based on the process described in Section 3.1. o Router E is SR-MPLS capable, so it advertises a Segment Routing Global Block (SRGB) using [I-D.ietf-ospf-segment-routing-extensions] or [I-D.ietf-isis-segment-routing-extensions]. o When Router E advertises the prefix-SID SID(E) of prefix P(E) it also advertises the encapsulation endpoint and the tunnel type of any tunnel used to reach E using [I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-ospf-encapsulation-cap]. Xu, et al. Expires December 18, 2019 [Page 6] Internet-Draft SR-MPLS over IP June 2019 o If A and E are in different domains then the information is flooded into both domains and any intervening domains. * The OSPF Tunnel Encapsulation TLV [I-D.ietf-ospf-encapsulation-cap] or the ISIS Tunnel Encapsulation sub-TLV [I-D.ietf-isis-encapsulation-cap] is flooded domain-wide. * The OSPF SID/label range TLV [I-D.ietf-ospf-segment-routing-extensions] or the ISIS SR- Capabilities Sub-TLV [I-D.ietf-isis-segment-routing-extensions] is advertised domain-wide so that router A knows the characteristics of router E. * When router E advertises the prefix P(E): + If router E is running ISIS it uses the extended reachability TLV (TLVs 135, 235, 236, 237) and associates the IPv4/IPv6 or IPv4/IPv6 source router ID sub-TLV(s) [RFC7794]. + If router E is running OSPF it uses the OSPFv2 Extended Prefix Opaque LSA [RFC7684] and sets the flooding scope to AS-wide. * If router E is running ISIS and advertises the ISIS capability TLV (TLV 242) [RFC7981], it sets the "router-ID" field to a valid value or includes an IPV6 TE router-ID sub-TLV (TLV 12), or does both. The "S" bit (flooding scope) of the ISIS capability TLV (TLV 242) is set to "1" . o Router A programs the FIB entry for prefix P(E) corresponding to the SID(E) according to whether a pop or swap action is advertised for the prefix as follows: * If the NP flag in OSPF or the P flag in ISIS is clear: pop the top label * If the NP flag in OSPF or the P flag in ISIS is set: swap the top label to a value equal to SID(E) plus the lower bound of the SRGB of E When forwarding the packet according to the constructed FIB entry the router encapsulates the packet according to the encapsulation as advertised using the mechanisms described in [I-D.ietf-isis-encapsulation-cap] or Xu, et al. Expires December 18, 2019 [Page 7] Internet-Draft SR-MPLS over IP June 2019 [I-D.ietf-ospf-encapsulation-cap]). It then sends the packets towards the next hop NHi. Note that [RFC7510] specifies the use of port number 6635 to indicate that the payload of a UDP packet is MPLS, and port number 6636 for MPLS-in-UDP utilizing DTLS. However, [I-D.ietf-isis-encapsulation-cap] and [I-D.ietf-ospf-encapsulation-cap] provide dynamic protocol mechanisms to configure the use any Dynamic Port for a tunnel that uses UDP encapsulation. Nothing in this document prevents the use of an IGP or any other mechanism to negotiate the use of a Dynamic Port when UDP encapsulation is used for SR-MPLS, but if no such mechanism is used then the port numbers specified in [RFC7510] are used. 3.2. Packet Forwarding Procedures [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- in-UDP. This approach is applicable where IP-based encapsulation for MPLS is required and further fine-grained load balancing of MPLS packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link Aggregation Groups (LAGs) is also required. This section provides details about the forwarding procedure when UDP encapsulation is adopted for SR-MPLS over IP. Other encapsulation and tunnelling mechanisms can be applied using similar techniques, but for clarity this section uses UDP encapsulation as the exemplar. Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes may be "legacy routers" that cannot handle SR-MPLS packets but can forward IP packets. An SR-MPLS-capable node MAY advertise its capabilities using the IGP as described in Section 3. There are six types of node in an SR-MPLS domain: o Domain ingress nodes that receive packets and encapsulate them for transmission across the domain. Those packets may be any payload protocol including native IP packets or packets that are already MPLS encapsulated. o Legacy transit nodes that are IP routers but that are not SR-MPLS capable (i.e., are not able to perform segment routing). o Transit nodes that are SR-MPLS capable but that are not identified by a SID in the SID stack. o Transit nodes that are SR-MPLS capable and need to perform SR-MPLS routing because they are identified by a SID in the SID stack. Xu, et al. Expires December 18, 2019 [Page 8] Internet-Draft SR-MPLS over IP June 2019 o The penultimate SR-MPLS capable node on the path that processes the last SID on the stack on behalf of the domain egress node. o The domain egress node that forwards the payload packet for ultimate delivery. 3.2.1. Packet Forwarding with Penultimate Hop Popping The description in this section assumes that the label associated with each prefix-SID is advertised by the owner of the prefix-SID as a Penultimate Hop Popping (PHP) label. That is, if one of the IGP flooding mechanisms is used, the NP flag in OSPF or the P flag in ISIS associated with the prefix-SID is not set. +-----+ +-----+ +-----+ +-----+ +-----+ | A +-------+ B +-------+ C +-------+ D +-------+ H | +-----+ +--+--+ +--+--+ +--+--+ +-----+ | | | | | | +--+--+ +--+--+ +--+--+ | E +-------+ F +-------+ G | +-----+ +-----+ +-----+ +--------+ |IP(A->E)| +--------+ +--------+ +--------+ | UDP | |IP(E->G)| |IP(G->H)| +--------+ +--------+ +--------+ | L(G) | | UDP | | UDP | +--------+ +--------+ +--------+ | L(H) | | L(H) | |Exp Null| +--------+ +--------+ +--------+ | Packet | ---> | Packet | ---> | Packet | +--------+ +--------+ +--------+ Figure 3: Packet Forwarding Example with PHP In the example shown in Figure 3, assume that routers A, E, G and H are SR-MPLS-capable while the remaining routers (B, C, D and F) are only capable of forwarding IP packets. Routers A, E, G, and H advertise their Segment Routing related information, such as via IS- IS or OSPF. Now assume that router A (the Domain ingress) wants to send a packet to router H (the Domain egress) via the explicit path {E->G->H}. Router A will impose an MPLS label stack on the packet that corresponds to that explicit path. Since the next hop toward router Xu, et al. Expires December 18, 2019 [Page 9] Internet-Draft SR-MPLS over IP June 2019 E is only IP-capable (B is a legacy transit node), router A replaces the top label (that indicated router E) with a UDP-based tunnel for MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the packet. In other words, router A pops the top label and then encapsulates the MPLS packet in a UDP tunnel to router E. When the IP-encapsulated MPLS packet arrives at router E (which is an SR-MPLS-capable transit node), router E strips the IP-based tunnel header and then processes the decapsulated MPLS packet. The top label indicates that the packet must be forwarded toward router G. Since the next hop toward router G is only IP-capable, router E replaces the current top label with an MPLS-over-UDP tunnel toward router G and sends it out. That is, router E pops the top label and then encapsulates the MPLS packet in a UDP tunnel to router G. When the packet arrives at router G, router G will strip the IP-based tunnel header and then process the decapsulated MPLS packet. The top label indicates that the packet must be forwarded toward router H. Since the next hop toward router H is only IP-capable (D is a legacy transit router), router G would replace the current top label with an MPLS-over-UDP tunnel toward router H and send it out. However, since router G reaches the bottom of the label stack (G is the penultimate SR-MPLS capable node on the path) this would leave the original packet that router A wanted to send to router H encapsulated in UDP as if it was MPLS (i.e., with a UDP header and destination port indicating MPLS) even though the original packet could have been any protocol. That is, the final SR-MPLS has been popped exposing the payload packet. To handle this, when a router (here it is router G) pops the final SR-MPLS label, it inserts an explicit null label [RFC3032] before encapsulating the packet in an MPLS-over-UDP tunnel toward router H and sending it out. That is, router G pops the top label, discovers it has reached the bottom of stack, pushes an explicit null label, and then encapsulates the MPLS packet in a UDP tunnel to router H. 3.2.2. Packet Forwarding without Penultimate Hop Popping Figure 4 demonstrates the packet walk in the case where the label associated with each prefix-SID advertised by the owner of the prefix-SID is not a Penultimate Hop Popping (PHP) label (e.g., the the NP flag in OSPF or the P flag in ISIS associated with the prefix- SID is set). Apart from the PHP function the roles of the routers is unchanged from Section 3.2.1. Xu, et al. Expires December 18, 2019 [Page 10] Internet-Draft SR-MPLS over IP June 2019 +-----+ +-----+ +-----+ +-----+ +-----+ | A +-------+ B +-------+ C +--------+ D +--------+ H | +-----+ +--+--+ +--+--+ +--+--+ +-----+ | | | | | | +--+--+ +--+--+ +--+--+ | E +-------+ F +--------+ G | +-----+ +-----+ +-----+ +--------+ |IP(A->E)| +--------+ +--------+ | UDP | |IP(E->G)| +--------+ +--------+ +--------+ | L(E) | | UDP | |IP(G->H)| +--------+ +--------+ +--------+ | L(G) | | L(G) | | UDP | +--------+ +--------+ +--------+ | L(H) | | L(H) | | L(H) | +--------+ +--------+ +--------+ | Packet | ---> | Packet | ---> | Packet | +--------+ +--------+ +--------+ Figure 4: Packet Forwarding Example without PHP As can be seen from the figure, the SR-MPLS label for each segment is left in place until the end of the segment where it is popped and the next instruction is processed. 3.2.3. Additional Forwarding Procedures Non-MPLS Interfaces: Although the description in the previous two sections is based on the use of prefix-SIDs, tunneling SR-MPLS packets is useful when the top label of a received SR-MPLS packet indicates an adjacency-SID and the corresponding adjacent node to that adjacency-SID is not capable of MPLS forwarding but can still process SR-MPLS packets. In this scenario the top label would be replaced by an IP tunnel toward that adjacent node and then forwarded over the corresponding link indicated by the adjacency- SID. When to use IP-based Tunnels: The description in the previous two sections is based on the assumption that MPLS-over-UDP tunnel is used when the nexthop towards the next segment is not MPLS- enabled. However, even in the case where the nexthop towards the next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the next segment could still be used instead due to local policies. For instance, in the example as described in Figure 4, assume F is Xu, et al. Expires December 18, 2019 [Page 11] Internet-Draft SR-MPLS over IP June 2019 now an SR-MPLS-capable transit node while all the other assumptions remain unchanged: since F is not identified by a SID in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP according to local policies, router E replaces the current top label with an MPLS-over-UDP tunnel toward router G and send it out. (Note that if an MPLS LSP was preferred, the packet would be forwarded as native SR-MPLS.) IP Header Fields: When encapsulating an MPLS packet in UDP, the resulting packet is further encapsulated in IP for transmission. IPv4 or IPv6 may be used according to the capabilities of the network. The address fields are set as described in Section 2. The other IP header fields (such as the ECN field [RFC6040], the DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP- encapsulated segment SHOULD be configurable according to the operator's policy: they may be copied from the header of the incoming packet; they may be promoted from the header of the payload packet; they may be set according to instructions programmed to be associated with the SID; or they may be configured dependent on the outgoing interface and payload. The TTL field setting in the encapsulating packet header is handled as described in [RFC7510] which refers to [RFC4023]. Entropy and ECMP: When encapsulating an MPLS packet with an IP tunnel header that is capable of encoding entropy (such as [RFC7510]), the corresponding entropy field (the source port in the case of a UDP tunnel) MAY be filled with an entropy value that is generated by the encapsulator to uniquely identify a flow. However, what constitutes a flow is locally determined by the encapsulator. For instance, if the MPLS label stack contains at least one entropy label and the encapsulator is capable of reading that entropy label, the entropy label value could be directly copied to the source port of the UDP header. Otherwise, the encapsulator may have to perform a hash on the whole label stack or the five-tuple of the SR-MPLS payload if the payload is determined as an IP packet. To avoid re-performing the hash or hunting for the entropy label each time the packet is encapsulated in a UDP tunnel it MAY be desirable that the entropy value contained in the incoming packet (i.e., the UDP source port value) is retained when stripping the UDP header and is re-used as the entropy value of the outgoing packet. Congestion Considerations: Section 5 of [RFC7510] provides a detailed analysis of the implications of congestion in MPLS-over- UDP systems and builds on section 3.1.3 of [RFC8085] that describes the congestion implications of UDP tunnels. All of those considerations apply to SR-MPLS-over-UDP tunnels as described in this document. In particular, it should be noted Xu, et al. Expires December 18, 2019 [Page 12] Internet-Draft SR-MPLS over IP June 2019 that the traffic carried in SR-MPLS flows is likely to be IP traffic. 4. IANA Considerations This document makes no requests for IANA action. 5. Security Considerations The security consideration of [RFC8354] (which redirects the reader to [RFC5095]) and [RFC7510] apply. DTLS [RFC6347] SHOULD be used where security is needed on an MPLS-SR-over-UDP segment including when the IP segment crosses the public Internet or some other untrusted environment. [RFC8402] provides security considerations for Segment Routing, and Section 8.1 of that document is particularly applicable to SR-MPLS. It is difficult for an attacker to pass a raw MPLS encoded packet into a network and operators have considerable experience at excluding such packets at the network boundaries, for example by excluding all packets that are revealed to be carrying an MPLS packet as the payload of IP tunnels. Further discussion of MPLS security is found in [RFC5920]. It is easy for a network ingress node to detect any attempt to smuggle an IP packet into the network since it would see that the UDP destination port was set to MPLS, and such filtering SHOULD be applied. If, however, the mechanisms described in [I-D.ietf-ospf-segment-routing-extensions] or [I-D.ietf-isis-segment-routing-extensions] are applied, a wider variety of UDP port numbers might be in use making port filtering harder. SR packets not having a destination address terminating in the network would be transparently carried and would pose no different security risk to the network under consideration than any other traffic. Where control plane techniques are used (as described in Section 3), it is important that these protocols are adequately secured for the environment in which they are run as discussed in [RFC6862] and [RFC5920]. 6. Contributors Ahmed Bashandy Individual Email: abashandy.ietf@gmail.com Xu, et al. Expires December 18, 2019 [Page 13] Internet-Draft SR-MPLS over IP June 2019 Clarence Filsfils Cisco Email: cfilsfil@cisco.com John Drake Juniper Email: jdrake@juniper.net Shaowen Ma Mellanox Technologies Email: mashaowen@gmail.com Mach Chen Huawei Email: mach.chen@huawei.com Hamid Assarpour Broadcom Email:hamid.assarpour@broadcom.com Robert Raszuk Bloomberg LP Email: robert@raszuk.net Uma Chunduri Huawei Email: uma.chunduri@gmail.com Luis M. Contreras Telefonica I+D Email: luismiguel.contrerasmurillo@telefonica.com Luay Jalil Verizon Email: luay.jalil@verizon.com Gunter Van De Velde Nokia Email: gunter.van_de_velde@nokia.com Tal Mizrahi Marvell Email: talmi@marvell.com Jeff Tantsura Individual Email: jefftant@gmail.com Xu, et al. Expires December 18, 2019 [Page 14] Internet-Draft SR-MPLS over IP June 2019 7. Acknowledgements Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert Sparks, and Al Morton for their insightful comments on this draft. Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer Dawkins, Benjamin Kaduk, Martin Vigoureux, Suresh Krishnan, and Eric Vyncke for careful reviews and resulting comments. 8. References 8.1. Normative References [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-22 (work in progress), May 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [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, . [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, . [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . Xu, et al. Expires December 18, 2019 [Page 15] Internet-Draft SR-MPLS over IP June 2019 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 8.2. Informative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing- header-21 (work in progress), June 2019. [I-D.ietf-bess-datacenter-gateway] Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil, "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection", draft- ietf-bess-datacenter-gateway-02 (work in progress), February 2019. Xu, et al. Expires December 18, 2019 [Page 16] Internet-Draft SR-MPLS over IP June 2019 [I-D.ietf-isis-encapsulation-cap] Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, L., and L. Jalil, "Advertising Tunnelling Capability in IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in progress), April 2017. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-25 (work in progress), May 2019. [I-D.ietf-mpls-spring-entropy-label] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., and J. Tantsura, "Entropy label for SPRING tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in progress), July 2018. [I-D.ietf-ospf-encapsulation-cap] Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. Jalil, "The Tunnel Encapsulations OSPF Router Information", draft-ietf-ospf-encapsulation-cap-09 (work in progress), October 2017. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-27 (work in progress), December 2018. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, DOI 10.17487/RFC6862, March 2013, . Xu, et al. Expires December 18, 2019 [Page 17] Internet-Draft SR-MPLS over IP June 2019 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., Ed., and M. Townsley, "Use Cases for IPv6 Source Packet Routing in Networking (SPRING)", RFC 8354, DOI 10.17487/RFC8354, March 2018, . Authors' Addresses Xiaohu Xu Alibaba, Inc Email: xiaohu.xxh@alibaba-inc.com Stewart Bryant Huawei Email: stewart.bryant@gmail.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Syed Hassan Cisco Email: shassan@cisco.com Wim Henderickx Nokia Email: wim.henderickx@nokia.com Zhenbin Li Huawei Email: lizhenbin@huawei.com Xu, et al. Expires December 18, 2019 [Page 18] ./draft-ietf-rtcweb-transports-17.txt0000644000764400076440000012155013004145207017063 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-mptcp-rfc6824bis-18.txt0000644000764400076440000064165613476707013016330 0ustar iustyiusty Internet Engineering Task Force A. Ford Internet-Draft Pexip Obsoletes: 6824 (if approved) C. Raiciu Intended status: Standards Track U. Politechnica of Bucharest Expires: December 10, 2019 M. Handley U. College London O. Bonaventure U. catholique de Louvain C. Paasch Apple, Inc. June 8, 2019 TCP Extensions for Multipath Operation with Multiple Addresses draft-ietf-mptcp-rfc6824bis-18 Abstract 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 specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience. 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 Ford, et al. Expires December 10, 2019 [Page 1] Internet-Draft Multipath TCP June 2019 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 10, 2019. Copyright Notice Copyright (c) 2019 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. Design Assumptions . . . . . . . . . . . . . . . . . . . 4 1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 8 2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . 9 2.2. Associating a New Subflow with an Existing MPTCP Connection . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Informing the Other Host about Another Potential Address 11 2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 12 2.5. Requesting a Change in a Path's Priority . . . . . . . . 13 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 13 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 14 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 16 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 23 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 28 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 30 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 33 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 34 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 36 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 37 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 38 3.3.7. Congestion Control Considerations . . . . . . . . . . 39 Ford, et al. Expires December 10, 2019 [Page 2] Internet-Draft Multipath TCP June 2019 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 39 3.4. Address Knowledge Exchange (Path Management) . . . . . . 40 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 42 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 45 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 46 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 48 3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 49 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 3.9. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 53 3.9.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 54 3.9.2. Delayed Subflow Start and Subflow Symmetry . . . . . 54 3.9.3. Failure Handling . . . . . . . . . . . . . . . . . . 55 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 57 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 64 8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . 65 8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 67 9.2. Informative References . . . . . . . . . . . . . . . . . 68 Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . 71 Appendix B. TCP Fast Open and MPTCP . . . . . . . . . . . . . . 72 B.1. TFO cookie request with MPTCP . . . . . . . . . . . . . . 72 B.2. Data sequence mapping under TFO . . . . . . . . . . . . . 73 B.3. Connection establishment examples . . . . . . . . . . . . 74 Appendix C. Control Blocks . . . . . . . . . . . . . . . . . . . 76 C.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 76 C.1.1. Authentication and Metadata . . . . . . . . . . . . . 76 C.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 77 C.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 77 C.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . 77 C.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . 78 C.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . 78 Appendix D. Finite State Machine . . . . . . . . . . . . . . . . 78 Appendix E. Changes from RFC6824 . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 1. Introduction Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793] to provide a Multipath TCP [RFC6182] service, which enables a transport connection to operate across multiple paths simultaneously. This document presents the protocol changes required to add multipath capability to TCP; specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reassembly of Ford, et al. Expires December 10, 2019 [Page 3] Internet-Draft Multipath TCP June 2019 data, and termination of sessions. This is not the only information required to create a Multipath TCP implementation, however. This document is complemented by three others: o Architecture [RFC6182], which explains the motivations behind Multipath TCP, contains a discussion of high-level design decisions on which this design is based, and an explanation of a functional separation through which an extensible MPTCP implementation can be developed. o Congestion control [RFC6356] presents a safe congestion control algorithm for coupling the behavior of the multiple paths in order to "do no harm" to other network users. o Application considerations [RFC6897] discusses what impact MPTCP will have on applications, what applications will want to do with MPTCP, and as a consequence of these factors, what API extensions an MPTCP implementation should present. This document is an update to, and obsoletes, the v0 specification of Multipath TCP (RFC6824). This document specifies MPTCP v1, which is not backward compatible with MPTCP v0. This document additionally defines version negotiation procedures for implementations that support both versions. 1.1. Design Assumptions In order to limit the potentially huge design space, the mptcp working group imposed two key constraints on the Multipath TCP design presented in this document: o It must be backwards-compatible with current, regular TCP, to increase its chances of deployment. o It can be assumed that one or both hosts are multihomed and multiaddressed. To simplify the design, we assume that the presence of multiple addresses at a host is sufficient to indicate the existence of multiple paths. These paths need not be entirely disjoint: they may share one or many routers between them. Even in such a situation, making use of multiple paths is beneficial, improving resource utilization and resilience to a subset of node failures. The congestion control algorithms defined in [RFC6356] ensure this does not act detrimentally. Furthermore, there may be some scenarios where different TCP ports on a single host can provide disjoint paths (such as through certain Equal-Cost Multipath (ECMP) implementations Ford, et al. Expires December 10, 2019 [Page 4] Internet-Draft Multipath TCP June 2019 [RFC2992]), and so the MPTCP design also supports the use of ports in path identifiers. There are three aspects to the backwards-compatibility listed above (discussed in more detail in [RFC6182]): External Constraints: The protocol must function through the vast majority of existing middleboxes such as NATs, firewalls, and proxies, and as such must resemble existing TCP as far as possible on the wire. Furthermore, the protocol must not assume the segments it sends on the wire arrive unmodified at the destination: they may be split or coalesced; TCP options may be removed or duplicated. Application Constraints: The protocol must be usable with no change to existing applications that use the common TCP API (although it is reasonable that not all features would be available to such legacy applications). Furthermore, the protocol must provide the same service model as regular TCP to the application. Fallback: The protocol should be able to fall back to standard TCP with no interference from the user, to be able to communicate with legacy hosts. The complementary application considerations document [RFC6897] discusses the necessary features of an API to provide backwards- compatibility, as well as API extensions to convey the behavior of MPTCP at a level of control and information equivalent to that available with regular, single-path TCP. Further discussion of the design constraints and associated design decisions are given in the MPTCP Architecture document [RFC6182] and in [howhard]. 1.2. Multipath TCP in the Networking Stack MPTCP operates at the transport layer and aims to be transparent to both higher and lower layers. It is a set of additional features on top of standard TCP; Figure 1 illustrates this layering. MPTCP is designed to be usable by legacy applications with no changes; detailed discussion of its interactions with applications is given in [RFC6897]. Ford, et al. Expires December 10, 2019 [Page 5] Internet-Draft Multipath TCP June 2019 +-------------------------------+ | Application | +---------------+ +-------------------------------+ | Application | | MPTCP | +---------------+ + - - - - - - - + - - - - - - - + | TCP | | Subflow (TCP) | Subflow (TCP) | +---------------+ +-------------------------------+ | IP | | IP | IP | +---------------+ +-------------------------------+ Figure 1: Comparison of Standard TCP and MPTCP Protocol Stacks 1.3. Terminology This document makes use of a number of terms that are either MPTCP- specific or have defined meaning in the context of MPTCP, as follows: Path: A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of source and destination address/ port pairs. Subflow: A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similar to a regular TCP connection. (MPTCP) Connection: A set of one or more subflows, over which an application can communicate between two hosts. There is a one-to- one mapping between a connection and an application socket. Data-level: The payload data is nominally transferred over a connection, which in turn is transported over subflows. Thus, the term "data-level" is synonymous with "connection level", in contrast to "subflow-level", which refers to properties of an individual subflow. Token: A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID". Host: An end host operating an MPTCP implementation, and either initiating or accepting an MPTCP connection. In addition to these terms, note that MPTCP's interpretation of, and effect on, regular single-path TCP semantics are discussed in Section 4. Ford, et al. Expires December 10, 2019 [Page 6] Internet-Draft Multipath TCP June 2019 1.4. MPTCP Concept This section provides a high-level summary of normal operation of MPTCP, and is illustrated by the scenario shown in Figure 2. A detailed description of operation is given in Section 3. o To a non-MPTCP-aware application, MPTCP will behave the same as normal TCP. Extended APIs could provide additional control to MPTCP-aware applications [RFC6897]. An application begins by opening a TCP socket in the normal way. MPTCP signaling and operation are handled by the MPTCP implementation. o An MPTCP connection begins similarly to a regular TCP connection. This is illustrated in Figure 2 where an MPTCP connection is established between addresses A1 and B1 on Hosts A and B, respectively. o If extra paths are available, additional TCP sessions (termed MPTCP "subflows") are created on these paths, and are combined with the existing session, which continues to appear as a single connection to the applications at both ends. The creation of the additional TCP session is illustrated between Address A2 on Host A and Address B1 on Host B. o MPTCP identifies multiple paths by the presence of multiple addresses at hosts. Combinations of these multiple addresses equate to the additional paths. In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1 or B2. o The discovery and setup of additional subflows will be achieved through a path management method; this document describes a mechanism by which a host can initiate new subflows by using its own additional addresses, or by signaling its available addresses to the other host. o MPTCP adds connection-level sequence numbers to allow the reassembly of segments arriving on multiple subflows with differing network delays. o Subflows are terminated as regular TCP connections, with a four- way FIN handshake. The MPTCP connection is terminated by a connection-level FIN. Ford, et al. Expires December 10, 2019 [Page 7] Internet-Draft Multipath TCP June 2019 Host A Host B ------------------------ ------------------------ Address A1 Address A2 Address B1 Address B2 ---------- ---------- ---------- ---------- | | | | | (initial connection setup) | | |----------------------------------->| | |<-----------------------------------| | | | | | | (additional subflow setup) | | |--------------------->| | | |<---------------------| | | | | | | | | | Figure 2: Example MPTCP Usage Scenario 1.5. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Operation Overview This section presents a single description of common MPTCP operation, with reference to the protocol operation. This is a high-level overview of the key functions; the full specification follows in Section 3. Extensibility and negotiated features are not discussed here. Considerable reference is made to symbolic names of MPTCP options throughout this section -- these are subtypes of the IANA- assigned MPTCP option (see Section 8), and their formats are defined in the detailed protocol specification that follows in Section 3. A Multipath TCP connection provides a bidirectional bytestream between two hosts communicating like normal TCP and, thus, does not require any change to the applications. However, Multipath TCP enables the hosts to use different paths with different IP addresses to exchange packets belonging to the MPTCP connection. A Multipath TCP connection appears like a normal TCP connection to an application. However, to the network layer, each MPTCP subflow looks like a regular TCP flow whose segments carry a new TCP option type. Multipath TCP manages the creation, removal, and utilization of these subflows to send data. The number of subflows that are managed within a Multipath TCP connection is not fixed and it can fluctuate during the lifetime of the Multipath TCP connection. Ford, et al. Expires December 10, 2019 [Page 8] Internet-Draft Multipath TCP June 2019 All MPTCP operations are signaled with a TCP option -- a single numerical type for MPTCP, with "sub-types" for each MPTCP message. What follows is a summary of the purpose and rationale of these messages. 2.1. Initiating an MPTCP Connection This is the same signaling as for initiating a normal TCP connection, but the SYN, SYN/ACK, and initial ACK (and data) packets also carry the MP_CAPABLE option. This option has a variable length and serves multiple purposes. Firstly, it verifies whether the remote host supports Multipath TCP; secondly, this option allows the hosts to exchange some information to authenticate the establishment of additional subflows. Further details are given in Section 3.1. Host A Host B ------ ------ MP_CAPABLE -> [flags] <- MP_CAPABLE [B's key, flags] ACK + MP_CAPABLE (+ data) -> [A's key, B's key, flags, (data-level details)] Retransmission of the ACK + MP_CAPABLE can occur if it is not known if it has been received. The following diagrams show all possible exchanges for the initial subflow setup to ensure this reliability. Ford, et al. Expires December 10, 2019 [Page 9] Internet-Draft Multipath TCP June 2019 Host A (with data to send immediately) Host B ------ ------ MP_CAPABLE -> [flags] <- MP_CAPABLE [B's key, flags] ACK + MP_CAPABLE + data -> [A's key, B's key, flags, data-level details] Host A (with data to send later) Host B ------ ------ MP_CAPABLE -> [flags] <- MP_CAPABLE [B's key, flags] ACK + MP_CAPABLE -> [A's key, B's key, flags] ACK + MP_CAPABLE + data -> [A's key, B's key, flags, data-level details] Host A Host B (sending first) ------ ------ MP_CAPABLE -> [flags] <- MP_CAPABLE [B's key, flags] ACK + MP_CAPABLE -> [A's key, B's key, flags] <- ACK + DSS + data [data-level details] 2.2. Associating a New Subflow with an Existing MPTCP Connection The exchange of keys in the MP_CAPABLE handshake provides material that can be used to authenticate the endpoints when new subflows will be set up. Additional subflows begin in the same way as initiating a normal TCP connection, but the SYN, SYN/ACK, and ACK packets also carry the MP_JOIN option. Host A initiates a new subflow between one of its addresses and one of Host B's addresses. The token -- generated from the key -- is used to identify which MPTCP connection it is joining, and the HMAC is used for authentication. The Hash-based Message Authentication Code (HMAC) uses the keys exchanged in the MP_CAPABLE handshake, and Ford, et al. Expires December 10, 2019 [Page 10] Internet-Draft Multipath TCP June 2019 the random numbers (nonces) exchanged in these MP_JOIN options. MP_JOIN also contains flags and an Address ID that can be used to refer to the source address without the sender needing to know if it has been changed by a NAT. Further details are in Section 3.2. Host A Host B ------ ------ MP_JOIN -> [B's token, A's nonce, A's Address ID, flags] <- MP_JOIN [B's HMAC, B's nonce, B's Address ID, flags] ACK + MP_JOIN -> [A's HMAC] <- ACK 2.3. Informing the Other Host about Another Potential Address The set of IP addresses associated to a multihomed host may change during the lifetime of an MPTCP connection. MPTCP supports the addition and removal of addresses on a host both implicitly and explicitly. If Host A has established a subflow starting at address/ port pair IP#-A1 and wants to open a second subflow starting at address/port pair IP#-A2, it simply initiates the establishment of the subflow as explained above. The remote host will then be implicitly informed about the new address. In some circumstances, a host may want to advertise to the remote host the availability of an address without establishing a new subflow, for example, when a NAT prevents setup in one direction. In the example below, Host A informs Host B about its alternative IP address/port pair (IP#-A2). Host B may later send an MP_JOIN to this new address. The ADD_ADDR option contains a HMAC to authenticate the address as having been sent from the originator of the connection. The receiver of this option echoes it back to the client to indicate successful receipt. Further details are in Section 3.4.1. Ford, et al. Expires December 10, 2019 [Page 11] Internet-Draft Multipath TCP June 2019 Host A Host B ------ ------ ADD_ADDR -> [Echo-flag=0, IP#-A2, IP#-A2's Address ID, HMAC of IP#-A2] <- ADD_ADDR [Echo-flag=1, IP#-A2, IP#-A2's Address ID, HMAC of IP#-A2] There is a corresponding signal for address removal, making use of the Address ID that is signaled in the add address handshake. Further details in Section 3.4.2. Host A Host B ------ ------ REMOVE_ADDR -> [IP#-A2's Address ID] 2.4. Data Transfer Using MPTCP To ensure reliable, in-order delivery of data over subflows that may appear and disappear at any time, MPTCP uses a 64-bit data sequence number (DSN) to number all data sent over the MPTCP connection. Each subflow has its own 32-bit sequence number space, utilising the regular TCP sequence number header, and an MPTCP option maps the subflow sequence space to the data sequence space. In this way, data can be retransmitted on different subflows (mapped to the same DSN) in the event of failure. The Data Sequence Signal (DSS) carries the Data Sequence Mapping. The Data Sequence Mapping consists of the subflow sequence number, data sequence number, and length for which this mapping is valid. This option can also carry a connection-level acknowledgment (the "Data ACK") for the received DSN. With MPTCP, all subflows share the same receive buffer and advertise the same receive window. There are two levels of acknowledgment in MPTCP. Regular TCP acknowledgments are used on each subflow to acknowledge the reception of the segments sent over the subflow independently of their DSN. In addition, there are connection-level acknowledgments for the data sequence space. These acknowledgments track the advancement of the bytestream and slide the receiving window. Ford, et al. Expires December 10, 2019 [Page 12] Internet-Draft Multipath TCP June 2019 Further details are in Section 3.3. Host A Host B ------ ------ DSS -> [Data Sequence Mapping] [Data ACK] [Checksum] 2.5. Requesting a Change in a Path's Priority Hosts can indicate at initial subflow setup whether they wish the subflow to be used as a regular or backup path -- a backup path only being used if there are no regular paths available. During a connection, Host A can request a change in the priority of a subflow through the MP_PRIO signal to Host B. Further details are in Section 3.3.8. Host A Host B ------ ------ MP_PRIO -> 2.6. Closing an MPTCP Connection When a host wants to close an existing subflow, but not the whole connection, it can initiate a regular TCP FIN/ACK exchange. When Host A wants to inform Host B that it has no more data to send, it signals this "Data FIN" as part of the Data Sequence Signal (see above). It has the same semantics and behavior as a regular TCP FIN, but at the connection level. Once all the data on the MPTCP connection has been successfully received, then this message is acknowledged at the connection level with a Data ACK. Further details are in Section 3.3.3. Host A Host B ------ ------ DSS -> [Data FIN] <- DSS [Data ACK] There is an additional method of connection closure, referred to as "Fast Close", which is analogous to closing a single-path TCP connection with a RST signal. The MP_FASTCLOSE signal is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. This can be used on an ACK (ensuring reliability of the signal), or a RST (which is not). Both Ford, et al. Expires December 10, 2019 [Page 13] Internet-Draft Multipath TCP June 2019 examples are shown in the following diagrams. Further details are in Section 3.5. Host A Host B ------ ------ ACK + MP_FASTCLOSE -> [B's key] [RST on all other subflows] -> <- [RST on all subflows] Host A Host B ------ ------ RST + MP_FASTCLOSE -> [B's key] [on all subflows] <- [RST on all subflows] 2.7. Notable Features It is worth highlighting that MPTCP's signaling has been designed with several key requirements in mind: o To cope with NATs on the path, addresses are referred to by Address IDs, in case the IP packet's source address gets changed by a NAT. Setting up a new TCP flow is not possible if the receiver of the SYN is behind a NAT; to allow subflows to be created when either end is behind a NAT, MPTCP uses the ADD_ADDR message. o MPTCP falls back to ordinary TCP if MPTCP operation is not possible, for example, if one host is not MPTCP capable or if a middlebox alters the payload. This is discussed in Section 3.7. o To address the threats identified in [RFC6181], the following steps are taken: keys are sent in the clear in the MP_CAPABLE messages; MP_JOIN messages are secured with HMAC-SHA256 ([RFC2104], [RFC6234]) using those keys; and standard TCP validity checks are made on the other messages (ensuring sequence numbers are in-window [RFC5961]). Residual threats to MPTCP v0 were identified in [RFC7430], and those affecting the protocol (i.e. modification to ADD_ADDR) have been incorporated in this document. Further discussion of security can be found in Section 5. Ford, et al. Expires December 10, 2019 [Page 14] Internet-Draft Multipath TCP June 2019 3. MPTCP Protocol This section describes the operation of the MPTCP protocol, and is subdivided into sections for each key part of the protocol operation. All MPTCP operations are signaled using optional TCP header fields. A single TCP option number ("Kind") has been assigned by IANA for MPTCP (see Section 8), and then individual messages will be determined by a "subtype", the values of which are also stored in an IANA registry (and are also listed in Section 8). As with all TCP options, the Length field is specified in bytes, and includes the 2 bytes of Kind and Length. Throughout this document, when reference is made to an MPTCP option by symbolic name, such as "MP_CAPABLE", this refers to a TCP option with the single MPTCP option type, and with the subtype value of the symbolic name as defined in Section 8. This subtype is a 4-bit field -- the first 4 bits of the option payload, as shown in Figure 3. The MPTCP messages are defined in the following sections. 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 +---------------+---------------+-------+-----------------------+ | Kind | Length |Subtype| | +---------------+---------------+-------+ | | Subtype-specific data | | (variable length) | +---------------------------------------------------------------+ Figure 3: MPTCP Option Format Those MPTCP options associated with subflow initiation are used on packets with the SYN flag set. Additionally, there is one MPTCP option for signaling metadata to ensure segmented data can be recombined for delivery to the application. The remaining options, however, are signals that do not need to be on a specific packet, such as those for signaling additional addresses. Whilst an implementation may desire to send MPTCP options as soon as possible, it may not be possible to combine all desired options (both those for MPTCP and for regular TCP, such as SACK (selective acknowledgment) [RFC2018]) on a single packet. Therefore, an implementation may choose to send duplicate ACKs containing the additional signaling information. This changes the semantics of a duplicate ACK; these are usually only sent as a signal of a lost segment [RFC5681] in regular TCP. Therefore, an MPTCP implementation receiving a duplicate ACK that contains an MPTCP option MUST NOT treat it as a signal of congestion. Additionally, an MPTCP Ford, et al. Expires December 10, 2019 [Page 15] Internet-Draft Multipath TCP June 2019 implementation SHOULD NOT send more than two duplicate ACKs in a row for the purposes of sending MPTCP options alone, in order to ensure no middleboxes misinterpret this as a sign of congestion. Furthermore, standard TCP validity checks (such as ensuring the sequence number and acknowledgment number are within window) MUST be undertaken before processing any MPTCP signals, as described in [RFC5961], and initial subflow sequence numbers SHOULD be generated according to the recommendations in [RFC6528]. 3.1. Connection Initiation Connection initiation begins with a SYN, SYN/ACK, ACK exchange on a single path. Each packet contains the Multipath Capable (MP_CAPABLE) MPTCP option (Figure 4). This option declares its sender is capable of performing Multipath TCP and wishes to do so on this particular connection. The MP_CAPABLE exchange in this specification (v1) is different to that specified in v0. If a host supports multiple versions of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest version number it supports. In return, in its MP_CAPABLE option, the receiver will signal the version number it wishes to use, which MUST be equal to or lower than the version number indicated in the initial MP_CAPABLE. There is a caveat though with respect to this version negotiation with old listeners that only support v0. A listener that supports v0 expects that the MP_CAPABLE option in the SYN-segment includes the initiator's key. If the initiator however already upgraded to v1, it won't include the key in the SYN-segment. Thus, the listener will ignore the MP_CAPABLE of this SYN-segment and reply with a SYN/ACK that does not include an MP_CAPABLE. The initiator MAY choose to immediately fall back to TCP or MAY choose to attempt a connection using MPTCP v0 (if the initiator supports v0), in order to discover whether the listener supports the earlier version of MPTCP. In general a MPTCP v0 connection is likely to be preferred to a TCP one, however in a particular deployment scenario it may be known that the listener is unlikely to support MPTCPv0 and so the initiator may prefer not to attempt a v0 connection. An initiator MAY cache information for a peer about what version of MPTCP it supports if any, and use this information for future connection attempts. The MP_CAPABLE option is variable-length, with different fields included depending on which packet the option is used on. The full MP_CAPABLE option is shown in Figure 4. Ford, et al. Expires December 10, 2019 [Page 16] Internet-Draft Multipath TCP June 2019 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 +---------------+---------------+-------+-------+---------------+ | Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H| +---------------+---------------+-------+-------+---------------+ | Option Sender's Key (64 bits) | | (if option Length > 4) | | | +---------------------------------------------------------------+ | Option Receiver's Key (64 bits) | | (if option Length > 12) | | | +-------------------------------+-------------------------------+ | Data-Level Length (16 bits) | Checksum (16 bits, optional) | +-------------------------------+-------------------------------+ Figure 4: Multipath Capable (MP_CAPABLE) Option The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets that start the first subflow of an MPTCP connection, as well as the first packet that carries data, if the initiator wishes to send first. The data carried by each option is as follows, where A = initiator and B = listener. o SYN (A->B): only the first four octets (Length = 4). o SYN/ACK (B->A): B's Key for this connection (Length = 12). o ACK (no data) (A->B): A's Key followed by B's Key (Length = 20). o ACK (with first data) (A->B): A's Key followed by B's Key followed by Data-Level Length, and optional Checksum (Length = 22 or 24). The contents of the option is determined by the SYN and ACK flags of the packet, along with the option's length field. For the diagram shown in Figure 4, "sender" and "receiver" refer to the sender or receiver of the TCP packet (which can be either host). The initial SYN, containing just the MP_CAPABLE header, is used to define the version of MPTCP being requested, as well as exchanging flags to negotiate connection features, described later. This option is used to declare the 64-bit keys that the end hosts have generated for this MPTCP connection. These keys are used to authenticate the addition of future subflows to this connection. This is the only time the key will be sent in clear on the wire (unless "fast close", Section 3.5, is used); all future subflows will identify the connection using a 32-bit "token". This token is a Ford, et al. Expires December 10, 2019 [Page 17] Internet-Draft Multipath TCP June 2019 cryptographic hash of this key. The algorithm for this process is dependent on the authentication algorithm selected; the method of selection is defined later in this section. Upon reception of the initial SYN-segment, a stateful server generates a random key and replies with a SYN/ACK. The key's method of generation is implementation specific. The key MUST be hard to guess, and it MUST be unique for the sending host across all its current MPTCP connections. Recommendations for generating random numbers for use in keys are given in [RFC4086]. Connections will be indexed at each host by the token (a one-way hash of the key). Therefore, an implementation will require a mapping from each token to the corresponding connection, and in turn to the keys for the connection. There is a risk that two different keys will hash to the same token. The risk of hash collisions is usually small, unless the host is handling many tens of thousands of connections. Therefore, an implementation SHOULD check its list of connection tokens to ensure there is no collision before sending its key, and if there is, then it should generate a new key. This would, however, be costly for a server with thousands of connections. The subflow handshake mechanism (Section 3.2) will ensure that new subflows only join the correct connection, however, through the cryptographic handshake, as well as checking the connection tokens in both directions, and ensuring sequence numbers are in-window. So in the worst case if there was a token collision, the new subflow would not succeed, but the MPTCP connection would continue to provide a regular TCP service. Since key generation is implementation-specific, there is no requirement that they be simply random numbers. An implementation is free to exchange cryptographic material out-of-band and generate these keys from this, in order to provide additional mechanisms by which to verify the identity of the communicating entities. For example, an implementation could choose to link its MPTCP keys to those used in higher-layer TLS or SSH connections. If the server behaves in a stateless manner, it has to generate its own key in a verifiable fashion. This verifiable way of generating the key can be done by using a hash of the 4-tuple, sequence number and a local secret (similar to what is done for the TCP-sequence number [RFC4987]). It will thus be able to verify whether it is indeed the originator of the key echoed back in the later MP_CAPABLE option. As for a stateful server, the tokens SHOULD be checked for uniqueness, however if uniqueness is not met, and there is no way to generate an alternative verifiable key, then the connection MUST fall back to using regular TCP by not sending a MP_CAPABLE in the SYN/ACK. Ford, et al. Expires December 10, 2019 [Page 18] Internet-Draft Multipath TCP June 2019 The ACK carries both A's key and B's key. This is the first time that A's key is seen on the wire, although it is expected that A will have generated a key locally before the initial SYN. The echoing of B's key allows B to operate statelessly, as described above. Therefore, A's key must be delivered reliably to B, and in order to do this, the transmission of this packet must be made reliable. If B has data to send first, then the reliable delivery of the ACK+MP_CAPABLE can be inferred by the receipt of this data with a MPTCP Data Sequence Signal (DSS) option (Section 3.3). If, however, A wishes to send data first, it has two options to ensure the reliable delivery of the ACK+MP_CAPABLE. If it immediately has data to send, then the third ACK (with data) would also contain an MP_CAPABLE option with additional data parameters (the Data-Level Length and optional Checksum as shown in Figure 4). If A does not immediately have data to send, it MUST include the MP_CAPABLE on the third ACK, but without the additional data parameters. When A does have data to send, it must repeat the sending of the MP_CAPABLE option from the third ACK, with additional data parameters. This MP_CAPABLE option is in place of the DSS, and simply specifies the data-level length of the payload, and the checksum (if the use of checksums is negotiated). This is the minimal data required to establish a MPTCP connection - it allows validation of the payload, and given it is the first data, the Initial Data Sequence Number (IDSN) is also known (as it is generated from the key, as described below). Conveying the keys on the first data packet allows the TCP reliability mechanisms to ensure the packet is successfully delivered. The receiver will acknowledge this data at the connection level with a Data ACK, as if a DSS option has been received. There could be situations where both A and B attempt to transmit initial data at the same time. For example, if A did not initially have data to send, but then needed to transmit data before it had received anything from B, it would use a MP_CAPABLE option with data parameters (since it would not know if the MP_CAPABLE on the ACK was received). In such a situation, B may also have transmitted data with a DSS option, but it had not yet been received at A. Therefore, B has received data with a MP_CAPABLE mapping after it has sent data with a DSS option. To ensure these situations can be handled, it follows that the data parameters in a MP_CAPABLE are semantically equivalent to those in a DSS option and can be used interchangeably. Similar situations could occur when the MP_CAPABLE with data is lost and retransmitted. Furthermore, in the case of TCP Segmentation Offloading, the MP_CAPABLE with data parameters may be duplicated across multiple packets, and implementations must also be able to cope with duplicate MP_CAPABLE mappings as well as duplicate DSS mappings. Ford, et al. Expires December 10, 2019 [Page 19] Internet-Draft Multipath TCP June 2019 Additionally, the MP_CAPABLE exchange allows the safe passage of MPTCP options on SYN packets to be determined. If any of these options are dropped, MPTCP will gracefully fall back to regular single-path TCP, as documented in Section 3.7. If at any point in the handshake either party thinks the MPTCP negotiation is compromised, for example by a middlebox corrupting the TCP options, or unexpected ACK numbers being present, the host MUST stop using MPTCP and no longer include MPTCP options in future TCP packets. The other host will then also fall back to regular TCP using the fall back mechanism. Note that new subflows MUST NOT be established (using the process documented in Section 3.2) until a Data Sequence Signal (DSS) option has been successfully received across the path (as documented in Section 3.3). Like all MPTCP options, the MP_CAPABLE option starts with the Kind and Length to specify the TCP-option kind and its length. Followed by that is the MP_CAPABLE option. The first 4 bits of the first octet in the MP_CAPABLE option (Figure 4) define the MPTCP option subtype (see Section 8; for MP_CAPABLE, this is 0x0), and the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this is 1). The second octet is reserved for flags, allocated as follows: A: The leftmost bit, labeled "A", SHOULD be set to 1 to indicate "Checksum Required", unless the system administrator has decided that checksums are not required (for example, if the environment is controlled and no middleboxes exist that might adjust the payload). B: The second bit, labeled "B", is an extensibility flag, and MUST be set to 0 for current implementations. This will be used for an extensibility mechanism in a future specification, and the impact of this flag will be defined at a later date. It is expected, but not mandated, that this flag would be used as part of an alternative security mechanism that does not require a full version upgrade of the protocol, but does require redefining some elements of the handshake. If receiving a message with the 'B' flag set to 1, and this is not understood, then the MP_CAPABLE in this SYN MUST be silently ignored, which triggers a fallback to regular TCP; the sender is expected to retry with a format compatible with this legacy specification. Note that the length of the MP_CAPABLE option, and the meanings of bits "D" through "H", may be altered by setting B=1. C: The third bit, labeled "C", is set to "1" to indicate that the sender of this option will not accept additional MPTCP subflows to the source address and port, and therefore the receiver MUST NOT Ford, et al. Expires December 10, 2019 [Page 20] Internet-Draft Multipath TCP June 2019 try to open any additional subflows towards this address and port. This is an efficiency improvement for situations where the sender knows a restriction is in place, for example if the sender is behind a strict NAT, or operating behind a legacy Layer 4 load balancer. D through H: The remaining bits, labeled "D" through "H", are used for crypto algorithm negotiation. In this specification only the rightmost bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC-SHA256 (as defined in Section 3.2). An implementation that only supports this method MUST set bit "H" to 1, and bits "D" through "G" to 0. A crypto algorithm MUST be specified. If flag bits D through H are all 0, the MP_CAPABLE option MUST be treated as invalid and ignored (that is, it must be treated as a regular TCP handshake). The selection of the authentication algorithm also impacts the algorithm used to generate the token and the Initial Data Sequence Number (IDSN). In this specification, with only the SHA-256 algorithm (bit "H") specified and selected, the token MUST be a truncated (most significant 32 bits) SHA-256 hash ([RFC6234]) of the key. A different, 64-bit truncation (the least significant 64 bits) of the SHA-256 hash of the key MUST be used as the IDSN. Note that the key MUST be hashed in network byte order. Also note that the "least significant" bits MUST be the rightmost bits of the SHA-256 digest, as per [RFC6234]. Future specifications of the use of the crypto bits may choose to specify different algorithms for token and IDSN generation. Both the crypto and checksum bits negotiate capabilities in similar ways. For the Checksum Required bit (labeled "A"), if either host requires the use of checksums, checksums MUST be used. In other words, the only way for checksums not to be used is if both hosts in their SYNs set A=0. This decision is confirmed by the setting of the "A" bit in the third packet (the ACK) of the handshake. For example, if the initiator sets A=0 in the SYN, but the responder sets A=1 in the SYN/ACK, checksums MUST be used in both directions, and the initiator will set A=1 in the ACK. The decision whether to use checksums will be stored by an implementation in a per-connection binary state variable. If A=1 is received by a host that does not want to use checksums, it MUST fall back to regular TCP by ignoring the MP_CAPABLE option as if it was invalid. For crypto negotiation, the responder has the choice. The initiator creates a proposal setting a bit for each algorithm it supports to 1 (in this version of the specification, there is only one proposal, so bit "H" will be always set to 1). The responder responds with only 1 Ford, et al. Expires December 10, 2019 [Page 21] Internet-Draft Multipath TCP June 2019 bit set -- this is the chosen algorithm. The rationale for this behavior is that the responder will typically be a server with potentially many thousands of connections, so it may wish to choose an algorithm with minimal computational complexity, depending on the load. If a responder does not support (or does not want to support) any of the initiator's proposals, it MUST respond without an MP_CAPABLE option, thus forcing a fallback to regular TCP. The MP_CAPABLE option is only used in the first subflow of a connection, in order to identify the connection; all following subflows will use the "Join" option (see Section 3.2) to join the existing connection. If a SYN contains an MP_CAPABLE option but the SYN/ACK does not, it is assumed that sender of the SYN/ACK is not multipath capable; thus, the MPTCP session MUST operate as a regular, single-path TCP. If a SYN does not contain a MP_CAPABLE option, the SYN/ACK MUST NOT contain one in response. If the third packet (the ACK) does not contain the MP_CAPABLE option, then the session MUST fall back to operating as a regular, single-path TCP. This is to maintain compatibility with middleboxes on the path that drop some or all TCP options. Note that an implementation MAY choose to attempt sending MPTCP options more than one time before making this decision to operate as regular TCP (see Section 3.9). If the SYN packets are unacknowledged, it is up to local policy to decide how to respond. It is expected that a sender will eventually fall back to single-path TCP (i.e., without the MP_CAPABLE option) in order to work around middleboxes that may drop packets with unknown options; however, the number of multipath-capable attempts that are made first will be up to local policy. It is possible that MPTCP and non-MPTCP SYNs could get reordered in the network. Therefore, the final state is inferred from the presence or absence of the MP_CAPABLE option in the third packet of the TCP handshake. If this option is not present, the connection SHOULD fall back to regular TCP, as documented in Section 3.7. The initial data sequence number on an MPTCP connection is generated from the key. The algorithm for IDSN generation is also determined from the negotiated authentication algorithm. In this specification, with only the SHA-256 algorithm specified and selected, the IDSN of a host MUST be the least significant 64 bits of the SHA-256 hash of its key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B). This deterministic generation of the IDSN allows a receiver to ensure that there are no gaps in sequence space at the start of the connection. The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3). Ford, et al. Expires December 10, 2019 [Page 22] Internet-Draft Multipath TCP June 2019 3.2. Starting a New Subflow Once an MPTCP connection has begun with the MP_CAPABLE exchange, further subflows can be added to the connection. Hosts have knowledge of their own address(es), and can become aware of the other host's addresses through signaling exchanges as described in Section 3.4. Using this knowledge, a host can initiate a new subflow over a currently unused pair of addresses. It is permitted for either host in a connection to initiate the creation of a new subflow, but it is expected that this will normally be the original connection initiator (see Section 3.9 for heuristics). A new subflow is started as a normal TCP SYN/ACK exchange. The Join Connection (MP_JOIN) MPTCP option is used to identify the connection to be joined by the new subflow. It uses keying material that was exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that handshake also negotiates the crypto algorithm in use for the MP_JOIN handshake. This section specifies the behavior of MP_JOIN using the HMAC-SHA256 algorithm. An MP_JOIN option is present in the SYN, SYN/ACK, and ACK of the three-way handshake, although in each case with a different format. In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the initiator sends a token, random number, and address ID. The token is used to identify the MPTCP connection and is a cryptographic hash of the receiver's key, as exchanged in the initial MP_CAPABLE handshake (Section 3.1). In this specification, the tokens presented in this option are generated by the SHA-256 [RFC6234] algorithm, truncated to the most significant 32 bits. The token included in the MP_JOIN option is the token that the receiver of the packet uses to identify this connection; i.e., Host A will send Token-B (which is generated from Key-B). Note that the hash generation algorithm can be overridden by the choice of cryptographic handshake algorithm, as defined in Section 3.1. The MP_JOIN SYN sends not only the token (which is static for a connection) but also random numbers (nonces) that are used to prevent replay attacks on the authentication method. Recommendations for the generation of random numbers for this purpose are given in [RFC4086]. The MP_JOIN option includes an "Address ID". This is an identifier generated by the sender of the option, used to identify the source address of this packet, even if the IP header has been changed in transit by a middlebox. The numeric value of this field is generated by the sender and must map uniquely to a source IP address for the Ford, et al. Expires December 10, 2019 [Page 23] Internet-Draft Multipath TCP June 2019 sending host. The Address ID allows address removal (Section 3.4.2) without needing to know what the source address at the receiver is, thus allowing address removal through NATs. The Address ID also allows correlation between new subflow setup attempts and address signaling (Section 3.4.1), to prevent setting up duplicate subflows on the same path, if an MP_JOIN and ADD_ADDR are sent at the same time. The Address IDs of the subflow used in the initial SYN exchange of the first subflow in the connection are implicit, and have the value zero. A host MUST store the mappings between Address IDs and addresses both for itself and the remote host. An implementation will also need to know which local and remote Address IDs are associated with which established subflows, for when addresses are removed from a local or remote host. The MP_JOIN option on packets with the SYN flag set also includes 4 bits of flags, 3 of which are currently reserved and MUST be set to zero by the sender. The final bit, labeled "B", indicates whether the sender of this option wishes this subflow to be used as a backup path (B=1) in the event of failure of other paths, or whether it wants it to be used as part of the connection immediately. By setting B=1, the sender of the option is requesting the other host to only send data on this subflow if there are no available subflows where B=0. Subflow policy is discussed in more detail in Section 3.3.8. 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 +---------------+---------------+-------+-----+-+---------------+ | Kind | Length = 12 |Subtype|(rsv)|B| Address ID | +---------------+---------------+-------+-----+-+---------------+ | Receiver's Token (32 bits) | +---------------------------------------------------------------+ | Sender's Random Number (32 bits) | +---------------------------------------------------------------+ Figure 5: Join Connection (MP_JOIN) Option (for Initial SYN) When receiving a SYN with an MP_JOIN option that contains a valid token for an existing MPTCP connection, the recipient SHOULD respond with a SYN/ACK also containing an MP_JOIN option containing a random number and a truncated (leftmost 64 bits) Hash-based Message Authentication Code (HMAC). This version of the option is shown in Figure 6. If the token is unknown, or the host wants to refuse subflow establishment (for example, due to a limit on the number of subflows it will permit), the receiver will send back a reset (RST) signal, analogous to an unknown port in TCP, containing a MP_TCPRST Ford, et al. Expires December 10, 2019 [Page 24] Internet-Draft Multipath TCP June 2019 option (Section 3.6) with a "MPTCP specific error" reason code. Although calculating an HMAC requires cryptographic operations, it is believed that the 32-bit token in the MP_JOIN SYN gives sufficient protection against blind state exhaustion attacks; therefore, there is no need to provide mechanisms to allow a responder to operate statelessly at the MP_JOIN stage. An HMAC is sent by both hosts -- by the initiator (Host A) in the third packet (the ACK) and by the responder (Host B) in the second packet (the SYN/ACK). Doing the HMAC exchange at this stage allows both hosts to have first exchanged random data (in the first two SYN packets) that is used as the "message". This specification defines that HMAC as defined in [RFC2104] is used, along with the SHA-256 hash algorithm [RFC6234], and that the output is truncated to the leftmost 160 bits (20 octets). Due to option space limitations, the HMAC included in the SYN/ACK is truncated to the leftmost 64 bits, but this is acceptable since random numbers are used; thus, an attacker only has one chance to correctly guess the HMAC that matches the random number previously sent by the peer (if the HMAC is incorrect, the TCP connection is closed, so a new MP_JOIN negotiation with a new random number is required). The initiator's authentication information is sent in its first ACK (the third packet of the handshake), as shown in Figure 7. This data needs to be sent reliably, since it is the only time this HMAC is sent; therefore, receipt of this packet MUST trigger a regular TCP ACK in response, and the packet MUST be retransmitted if this ACK is not received. In other words, sending the ACK/MP_JOIN packet places the subflow in the PRE_ESTABLISHED state, and it moves to the ESTABLISHED state only on receipt of an ACK from the receiver. It is not permitted to send data while in the PRE_ESTABLISHED state. The reserved bits in this option MUST be set to zero by the sender. The key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged in the original MP_CAPABLE handshake. The "message" for the HMAC algorithm in each case is the concatenations of random number for each host (denoted by R): for Host A, R-A followed by R-B; and for Host B, R-B followed by R-A. Ford, et al. Expires December 10, 2019 [Page 25] Internet-Draft Multipath TCP June 2019 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 +---------------+---------------+-------+-----+-+---------------+ | Kind | Length = 16 |Subtype|(rsv)|B| Address ID | +---------------+---------------+-------+-----+-+---------------+ | | | Sender's Truncated HMAC (64 bits) | | | +---------------------------------------------------------------+ | Sender's Random Number (32 bits) | +---------------------------------------------------------------+ Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK) 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 +---------------+---------------+-------+-----------------------+ | Kind | Length = 24 |Subtype| (reserved) | +---------------+---------------+-------+-----------------------+ | | | | | Sender's Truncated HMAC (160 bits) | | | | | +---------------------------------------------------------------+ Figure 7: Join Connection (MP_JOIN) Option (for Third ACK) These various MPTCP options fit together to enable authenticated subflow setup as illustrated in Figure 8. Ford, et al. Expires December 10, 2019 [Page 26] Internet-Draft Multipath TCP June 2019 Host A Host B ------------------------ ---------- Address A1 Address A2 Address B1 ---------- ---------- ---------- | | | | | SYN + MP_CAPABLE | |--------------------------------------------->| |<---------------------------------------------| | SYN/ACK + MP_CAPABLE(Key-B) | | | | | ACK + MP_CAPABLE(Key-A, Key-B) | |--------------------------------------------->| | | | | | SYN + MP_JOIN(Token-B, R-A) | | |------------------------------->| | |<-------------------------------| | | SYN/ACK + MP_JOIN(HMAC-B, R-B) | | | | | | ACK + MP_JOIN(HMAC-A) | | |------------------------------->| | |<-------------------------------| | | ACK | HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B)) HMAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A)) Figure 8: Example Use of MPTCP Authentication If the token received at Host B is unknown or local policy prohibits the acceptance of the new subflow, the recipient MUST respond with a TCP RST for the subflow. If appropriate, a MP_TCPRST option with a "Administratively prohibited" reason code (Section 3.6) should be included. If the token is accepted at Host B, but the HMAC returned to Host A does not match the one expected, Host A MUST close the subflow with a TCP RST. In this, and all following cases of sending a RST in this section, the sender SHOULD send a MP_TCPRST option (Section 3.6) on this RST packet with the reason code for a "MPTCP specific error". If Host B does not receive the expected HMAC, or the MP_JOIN option is missing from the ACK, it MUST close the subflow with a TCP RST. If the HMACs are verified as correct, then both hosts have verified each other as being the same peers as existed at the start of the connection, and they have agreed of which connection this subflow will become a part. Ford, et al. Expires December 10, 2019 [Page 27] Internet-Draft Multipath TCP June 2019 If the SYN/ACK as received at Host A does not have an MP_JOIN option, Host A MUST close the subflow with a TCP RST. This covers all cases of the loss of an MP_JOIN. In more detail, if MP_JOIN is stripped from the SYN on the path from A to B, and Host B does not have a listener on the relevant port, it will respond with a RST in the normal way. If in response to a SYN with an MP_JOIN option, a SYN/ACK is received without the MP_JOIN option (either since it was stripped on the return path, or it was stripped on the outgoing path but Host B responded as if it were a new regular TCP session), then the subflow is unusable and Host A MUST close it with a RST. Note that additional subflows can be created between any pair of ports (but see Section 3.9 for heuristics); no explicit application- level accept calls or bind calls are required to open additional subflows. To associate a new subflow with an existing connection, the token supplied in the subflow's SYN exchange is used for demultiplexing. This then binds the 5-tuple of the TCP subflow to the local token of the connection. A consequence is that it is possible to allow any port pairs to be used for a connection. Demultiplexing subflow SYNs MUST be done using the token; this is unlike traditional TCP, where the destination port is used for demultiplexing SYN packets. Once a subflow is set up, demultiplexing packets is done using the 5-tuple, as in traditional TCP. The 5-tuples will be mapped to the local connection identifier (token). Note that Host A will know its local token for the subflow even though it is not sent on the wire -- only the responder's token is sent. 3.3. General MPTCP Operation This section discusses operation of MPTCP for data transfer. At a high level, an MPTCP implementation will take one input data stream from an application, and split it into one or more subflows, with sufficient control information to allow it to be reassembled and delivered reliably and in order to the recipient application. The following subsections define this behavior in detail. The data sequence mapping and the Data ACK are signaled in the Data Sequence Signal (DSS) option (Figure 9). Either or both can be signaled in one DSS, depending on the flags set. The data sequence mapping defines how the sequence space on the subflow maps to the connection level, and the Data ACK acknowledges receipt of data at the connection level. These functions are described in more detail in the following two subsections. Ford, et al. Expires December 10, 2019 [Page 28] Internet-Draft Multipath TCP June 2019 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 +---------------+---------------+-------+----------------------+ | Kind | Length |Subtype| (reserved) |F|m|M|a|A| +---------------+---------------+-------+----------------------+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data sequence number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-Level Length (2 octets) | Checksum (2 octets) | +-------------------------------+------------------------------+ Figure 9: Data Sequence Signal (DSS) Option The flags, when set, define the contents of this option, as follows: o A = Data ACK present o a = Data ACK is 8 octets (if not set, Data ACK is 4 octets) o M = Data Sequence Number (DSN), Subflow Sequence Number (SSN), Data-Level Length, and Checksum (if negotiated) present o m = Data sequence number is 8 octets (if not set, DSN is 4 octets) The flags 'a' and 'm' only have meaning if the corresponding 'A' or 'M' flags are set; otherwise, they will be ignored. The maximum length of this option, with all flags set, is 28 octets. The 'F' flag indicates "Data FIN". If present, this means that this mapping covers the final data from the sender. This is the connection-level equivalent to the FIN flag in single-path TCP. A connection is not closed unless there has been a Data FIN exchange, a MP_FASTCLOSE (Section 3.5) message, or an implementation-specific, connection-level send timeout. The purpose of the Data FIN and the interactions between this flag, the subflow-level FIN flag, and the data sequence mapping are described in Section 3.3.3. The remaining reserved bits MUST be set to zero by an implementation of this specification. Note that the checksum is only present in this option if the use of MPTCP checksumming has been negotiated at the MP_CAPABLE handshake (see Section 3.1). The presence of the checksum can be inferred from the length of the option. If a checksum is present, but its use had not been negotiated in the MP_CAPABLE handshake, the receiver MUST close the subflow with a RST as it not behaving as negotiated. If a Ford, et al. Expires December 10, 2019 [Page 29] Internet-Draft Multipath TCP June 2019 checksum is not present when its use has been negotiated, the receiver MUST close the subflow with a RST as it is considered broken. In both cases, this RST SHOULD be accompanied with a MP_TCPRST option (Section 3.6) with the reason code for a "MPTCP specific error". 3.3.1. Data Sequence Mapping The data stream as a whole can be reassembled through the use of the data sequence mapping components of the DSS option (Figure 9), which define the mapping from the subflow sequence number to the data sequence number. This is used by the receiver to ensure in-order delivery to the application layer. Meanwhile, the subflow-level sequence numbers (i.e., the regular sequence numbers in the TCP header) have subflow-only relevance. It is expected (but not mandated) that SACK [RFC2018] is used at the subflow level to improve efficiency. The data sequence mapping specifies a mapping from subflow sequence space to data sequence space. This is expressed in terms of starting sequence numbers for the subflow and the data level, and a length of bytes for which this mapping is valid. This explicit mapping for a range of data was chosen rather than per-packet signaling to assist with compatibility with situations where TCP/IP segmentation or coalescing is undertaken separately from the stack that is generating the data flow (e.g., through the use of TCP segmentation offloading on network interface cards, or by middleboxes such as performance enhancing proxies). It also allows a single mapping to cover many packets, which may be useful in bulk transfer situations. A mapping is fixed, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. A sender MUST NOT change this mapping after it has been declared; however, the same data sequence number can be mapped to by different subflows for retransmission purposes (see Section 3.3.6). This would also permit the same data to be sent simultaneously on multiple subflows for resilience or efficiency purposes, especially in the case of lossy links. Although the detailed specification of such operation is outside the scope of this document, an implementation SHOULD treat the first data that is received at a subflow for the data sequence space as that which should be delivered to the application, and any later data for that sequence space SHOULD be ignored. The data sequence number is specified as an absolute value, whereas the subflow sequence numbering is relative (the SYN at the start of the subflow has relative subflow sequence number 0). This is to allow middleboxes to change the initial sequence number of a subflow, Ford, et al. Expires December 10, 2019 [Page 30] Internet-Draft Multipath TCP June 2019 such as firewalls that undertake Initial Sequence Number (ISN) randomization. The data sequence mapping also contains a checksum of the data that this mapping covers, if use of checksums has been negotiated at the MP_CAPABLE exchange. Checksums are used to detect if the payload has been adjusted in any way by a non-MPTCP-aware middlebox. If this checksum fails, it will trigger a failure of the subflow, or a fallback to regular TCP, as documented in Section 3.7, since MPTCP can no longer reliably know the subflow sequence space at the receiver to build data sequence mappings. Without checksumming enabled, corrupt data may be delivered to the application if a middlebox alters segment boundaries, alters content, or does not deliver all segments covered by a data sequence mapping. It is therefore RECOMMENDED to use checksumming unless it is known the network path contains no such devices. The checksum algorithm used is the standard TCP checksum [RFC0793], operating over the data covered by this mapping, along with a pseudo- header as shown in Figure 10. 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 +--------------------------------------------------------------+ | | | Data Sequence Number (8 octets) | | | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-Level Length (2 octets) | Zeros (2 octets) | +-------------------------------+------------------------------+ Figure 10: Pseudo-Header for DSS Checksum Note that the data sequence number used in the pseudo-header is always the 64-bit value, irrespective of what length is used in the DSS option itself. The standard TCP checksum algorithm has been chosen since it will be calculated anyway for the TCP subflow, and if calculated first over the data before adding the pseudo-headers, it only needs to be calculated once. Furthermore, since the TCP checksum is additive, the checksum for a DSN_MAP can be constructed by simply adding together the checksums for the data of each constituent TCP segment, and adding the checksum for the DSS pseudo- header. Note that checksumming relies on the TCP subflow containing contiguous data; therefore, a TCP subflow MUST NOT use the Urgent Ford, et al. Expires December 10, 2019 [Page 31] Internet-Draft Multipath TCP June 2019 Pointer to interrupt an existing mapping. Further note, however, that if Urgent data is received on a subflow, it SHOULD be mapped to the data sequence space and delivered to the application analogous to Urgent data in regular TCP. To avoid possible deadlock scenarios, subflow-level processing should be undertaken separately from that at connection level. Therefore, even if a mapping does not exist from the subflow space to the data- level space, the data SHOULD still be ACKed at the subflow (if it is in-window). This data cannot, however, be acknowledged at the data level (Section 3.3.2) because its data sequence numbers are unknown. Implementations MAY hold onto such unmapped data for a short while in the expectation that a mapping will arrive shortly. Such unmapped data cannot be counted as being within the connection level receive window because this is relative to the data sequence numbers, so if the receiver runs out of memory to hold this data, it will have to be discarded. If a mapping for that subflow-level sequence space does not arrive within a receive window of data, that subflow SHOULD be treated as broken, closed with a RST, and any unmapped data silently discarded. Data sequence numbers are always 64-bit quantities, and MUST be maintained as such in implementations. If a connection is progressing at a slow rate, so protection against wrapped sequence numbers is not required, then an implementation MAY include just the lower 32 bits of the data sequence number in the data sequence mapping and/or Data ACK as an optimization, and an implementation can make this choice independently for each packet. An implementation MUST be able to receive and process both 64-bit or 32-bit sequence number values, but it is not required that an implementation is able to send both. An implementation MUST send the full 64-bit data sequence number if it is transmitting at a sufficiently high rate that the 32-bit value could wrap within the Maximum Segment Lifetime (MSL) [RFC7323]. The lengths of the DSNs used in these values (which may be different) are declared with flags in the DSS option. Implementations MUST accept a 32-bit DSN and implicitly promote it to a 64-bit quantity by incrementing the upper 32 bits of sequence number each time the lower 32 bits wrap. A sanity check MUST be implemented to ensure that a wrap occurs at an expected time (e.g., the sequence number jumps from a very high number to a very low number) and is not triggered by out- of-order packets. As with the standard TCP sequence number, the data sequence number should not start at zero, but at a random value to make blind session hijacking harder. This specification requires setting the initial data sequence number (IDSN) of each host to the least significant 64 Ford, et al. Expires December 10, 2019 [Page 32] Internet-Draft Multipath TCP June 2019 bits of the SHA-256 hash of the host's key, as described in Section 3.1. This is required also in order for the receiver to know what the expected IDSN is, and thus determine if any initial connection-level packets are missing; this is particularly relevant if two subflows start transmitting simultaneously. A data sequence mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver. This can be used to reduce overhead in cases where the mapping is known in advance; one such case is when there is a single subflow between the hosts, another is when segments of data are scheduled in larger than packet- sized chunks. An "infinite" mapping can be used to fall back to regular TCP by mapping the subflow-level data to the connection-level data for the remainder of the connection (see Section 3.7). This is achieved by setting the Data-Level Length field of the DSS option to the reserved value of 0. The checksum, in such a case, will also be set to zero. 3.3.2. Data Acknowledgments To provide full end-to-end resilience, MPTCP provides a connection- level acknowledgment, to act as a cumulative ACK for the connection as a whole. This is the "Data ACK" field of the DSS option (Figure 9). The Data ACK is analogous to the behavior of the standard TCP cumulative ACK -- indicating how much data has been successfully received (with no holes). This is in comparison to the subflow-level ACK, which acts analogous to TCP SACK, given that there may still be holes in the data stream at the connection level. The Data ACK specifies the next data sequence number it expects to receive. The Data ACK, as for the DSN, can be sent as the full 64-bit value, or as the lower 32 bits. If data is received with a 64-bit DSN, it MUST be acknowledged with a 64-bit Data ACK. If the DSN received is 32 bits, an implementation can choose whether to send a 32-bit or 64-bit Data ACK, and an implementation MUST accept either in this situation. The Data ACK proves that the data, and all required MPTCP signaling, has been received and accepted by the remote end. One key use of the Data ACK signal is that it is used to indicate the left edge of the advertised receive window. As explained in Section 3.3.4, the receive window is shared by all subflows and is relative to the Data ACK. Because of this, an implementation MUST NOT use the RCV.WND field of a TCP segment at the connection level if it does not also carry a DSS option with a Data ACK field. Furthermore, separating Ford, et al. Expires December 10, 2019 [Page 33] Internet-Draft Multipath TCP June 2019 the connection-level acknowledgments from the subflow level allows processing to be done separately, and a receiver has the freedom to drop segments after acknowledgment at the subflow level, for example, due to memory constraints when many segments arrive out of order. An MPTCP sender MUST NOT free data from the send buffer until it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by all subflows on which the data was sent. The former condition ensures liveness of the connection and the latter condition ensures liveness and self-consistence of a subflow when data needs to be retransmitted. Note, however, that if some data needs to be retransmitted multiple times over a subflow, there is a risk of blocking the sending window. In this case, the MPTCP sender can decide to terminate the subflow that is behaving badly by sending a RST, using an appropriate MP_TCPRST (Section 3.6) error code. The Data ACK MAY be included in all segments; however, optimizations SHOULD be considered in more advanced implementations, where the Data ACK is present in segments only when the Data ACK value advances, and this behavior MUST be treated as valid. This behavior ensures the sender buffer is freed, while reducing overhead when the data transfer is unidirectional. 3.3.3. Closing a Connection In regular TCP, a FIN announces the receiver that the sender has no more data to send. In order to allow subflows to operate independently and to keep the appearance of TCP over the wire, a FIN in MPTCP only affects the subflow on which it is sent. This allows nodes to exercise considerable freedom over which paths are in use at any one time. The semantics of a FIN remain as for regular TCP; i.e., it is not until both sides have ACKed each other's FINs that the subflow is fully closed. When an application calls close() on a socket, this indicates that it has no more data to send; for regular TCP, this would result in a FIN on the connection. For MPTCP, an equivalent mechanism is needed, and this is referred to as the DATA_FIN. A DATA_FIN is an indication that the sender has no more data to send, and as such can be used to verify that all data has been successfully received. A DATA_FIN, as with the FIN on a regular TCP connection, is a unidirectional signal. The DATA_FIN is signaled by setting the 'F' flag in the Data Sequence Signal option (Figure 9) to 1. A DATA_FIN occupies 1 octet (the final octet) of the connection-level sequence space. Note that the DATA_FIN is included in the Data-Level Length, but not at the subflow Ford, et al. Expires December 10, 2019 [Page 34] Internet-Draft Multipath TCP June 2019 level: for example, a segment with DSN 80, and Data-Level Length 11, with DATA_FIN set, would map 10 octets from the subflow into data sequence space 80-89, the DATA_FIN is DSN 90; therefore, this segment including DATA_FIN would be acknowledged with a DATA_ACK of 91. Note that when the DATA_FIN is not attached to a TCP segment containing data, the Data Sequence Signal MUST have a subflow sequence number of 0, a Data-Level Length of 1, and the data sequence number that corresponds with the DATA_FIN itself. The checksum in this case will only cover the pseudo-header. A DATA_FIN has the semantics and behavior as a regular TCP FIN, but at the connection level. Notably, it is only DATA_ACKed once all data has been successfully received at the connection level. Note, therefore, that a DATA_FIN is decoupled from a subflow FIN. It is only permissible to combine these signals on one subflow if there is no data outstanding on other subflows. Otherwise, it may be necessary to retransmit data on different subflows. Essentially, a host MUST NOT close all functioning subflows unless it is safe to do so, i.e., until all outstanding data has been DATA_ACKed, or until the segment with the DATA_FIN flag set is the only outstanding segment. Once a DATA_FIN has been acknowledged, all remaining subflows MUST be closed with standard FIN exchanges. Both hosts SHOULD send FINs on all subflows, as a courtesy to allow middleboxes to clean up state even if an individual subflow has failed. It is also encouraged to reduce the timeouts (Maximum Segment Lifetime) on subflows at end hosts after receiving a DATA_FIN. In particular, any subflows where there is still outstanding data queued (which has been retransmitted on other subflows in order to get the DATA_FIN acknowledged) MAY be closed with a RST with MP_TCPRST (Section 3.6) error code for "too much outstanding data". A connection is considered closed once both hosts' DATA_FINs have been acknowledged by DATA_ACKs. As specified above, a standard TCP FIN on an individual subflow only shuts down the subflow on which it was sent. If all subflows have been closed with a FIN exchange, but no DATA_FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeout. This implies that an implementation will have TIME_WAIT states at both the subflow and connection levels (see Appendix D). This permits "break-before-make" scenarios where connectivity is lost on all subflows before a new one can be re- established. Ford, et al. Expires December 10, 2019 [Page 35] Internet-Draft Multipath TCP June 2019 3.3.4. Receiver Considerations Regular TCP advertises a receive window in each packet, telling the sender how much data the receiver is willing to accept past the cumulative ack. The receive window is used to implement flow control, throttling down fast senders when receivers cannot keep up. MPTCP also uses a unique receive window, shared between the subflows. The idea is to allow any subflow to send data as long as the receiver is willing to accept it. The alternative, maintaining per subflow receive windows, could end up stalling some subflows while others would not use up their window. The receive window is relative to the DATA_ACK. As in TCP, a receiver MUST NOT shrink the right edge of the receive window (i.e., DATA_ACK + receive window). The receiver will use the data sequence number to tell if a packet should be accepted at the connection level. When deciding to accept packets at subflow level, regular TCP checks the sequence number in the packet against the allowed receive window. With multipath, such a check is done using only the connection-level window. A sanity check SHOULD be performed at subflow level to ensure that the subflow and mapped sequence numbers meet the following test: SSN - SUBFLOW_ACK <= DSN - DATA_ACK, where SSN is the subflow sequence number of the received packet and SUBFLOW_ACK is the RCV.NXT (next expected sequence number) of the subflow (with the equivalent connection-level definitions for DSN and DATA_ACK). In regular TCP, once a segment is deemed in-window, it is put either in the in-order receive queue or in the out-of-order queue. In Multipath TCP, the same happens but at the connection level: a segment is placed in the connection level in-order or out-of-order queue if it is in-window at both connection and subflow levels. The stack still has to remember, for each subflow, which segments were received successfully so that it can ACK them at subflow level appropriately. Typically, this will be implemented by keeping per subflow out-of-order queues (containing only message headers, not the payloads) and remembering the value of the cumulative ACK. It is important for implementers to understand how large a receiver buffer is appropriate. The lower bound for full network utilization is the maximum bandwidth-delay product of any one of the paths. However, this might be insufficient when a packet is lost on a slower subflow and needs to be retransmitted (see Section 3.3.6). A tight upper bound would be the maximum round-trip time (RTT) of any path multiplied by the total bandwidth available across all paths. This permits all subflows to continue at full speed while a packet is Ford, et al. Expires December 10, 2019 [Page 36] Internet-Draft Multipath TCP June 2019 fast-retransmitted on the maximum RTT path. Even this might be insufficient to maintain full performance in the event of a retransmit timeout on the maximum RTT path. It is for future study to determine the relationship between retransmission strategies and receive buffer sizing. 3.3.5. Sender Considerations The sender remembers receiver window advertisements from the receiver. It should only update its local receive window values when the largest sequence number allowed (i.e., DATA_ACK + receive window) increases, on the receipt of a DATA_ACK. This is important to allow using paths with different RTTs, and thus different feedback loops. MPTCP uses a single receive window across all subflows, and if the receive window was guaranteed to be unchanged end-to-end, a host could always read the most recent receive window value. However, some classes of middleboxes may alter the TCP-level receive window. Typically, these will shrink the offered window, although for short periods of time it may be possible for the window to be larger (however, note that this would not continue for long periods since ultimately the middlebox must keep up with delivering data to the receiver). Therefore, if receive window sizes differ on multiple subflows, when sending data MPTCP SHOULD take the largest of the most recent window sizes as the one to use in calculations. This rule is implicit in the requirement not to reduce the right edge of the window. The sender MUST also remember the receive windows advertised by each subflow. The allowed window for subflow i is (ack_i, ack_i + rcv_wnd_i), where ack_i is the subflow-level cumulative ACK of subflow i. This ensures data will not be sent to a middlebox unless there is enough buffering for the data. Putting the two rules together, we get the following: a sender is allowed to send data segments with data-level sequence numbers between (DATA_ACK, DATA_ACK + receive_window). Each of these segments will be mapped onto subflows, as long as subflow sequence numbers are in the allowed windows for those subflows. Note that subflow sequence numbers do not generally affect flow control if the same receive window is advertised across all subflows. They will perform flow control for those subflows with a smaller advertised receive window. The send buffer MUST, at a minimum, be as big as the receive buffer, to enable the sender to reach maximum throughput. Ford, et al. Expires December 10, 2019 [Page 37] Internet-Draft Multipath TCP June 2019 3.3.6. Reliability and Retransmissions The data sequence mapping allows senders to resend data with the same data sequence number on a different subflow. When doing this, a host MUST still retransmit the original data on the original subflow, in order to preserve the subflow integrity (middleboxes could replay old data, and/or could reject holes in subflows), and a receiver will ignore these retransmissions. While this is clearly suboptimal, for compatibility reasons this is sensible behavior. Optimizations could be negotiated in future versions of this protocol. Note also that this property would also permit a sender to always send the same data, with the same data sequence number, on multiple subflows, if desired for reliability reasons. This protocol specification does not mandate any mechanisms for handling retransmissions, and much will be dependent upon local policy (as discussed in Section 3.3.8). One can imagine aggressive connection-level retransmissions policies where every packet lost at subflow level is retransmitted on a different subflow (hence, wasting bandwidth but possibly reducing application-to-application delays), or conservative retransmission policies where connection-level retransmits are only used after a few subflow-level retransmission timeouts occur. It is envisaged that a standard connection-level retransmission mechanism would be implemented around a connection-level data queue: all segments that haven't been DATA_ACKed are stored. A timer is set when the head of the connection-level is ACKed at subflow level but its corresponding data is not ACKed at data level. This timer will guard against failures in retransmission by middleboxes that proactively ACK data. The sender MUST keep data in its send buffer as long as the data has not been acknowledged at both connection level and on all subflows on which it has been sent. In this way, the sender can always retransmit the data if needed, on the same subflow or on a different one. A special case is when a subflow fails: the sender will typically resend the data on other working subflows after a timeout, and will keep trying to retransmit the data on the failed subflow too. The sender will declare the subflow failed after a predefined upper bound on retransmissions is reached (which MAY be lower than the usual TCP limits of the Maximum Segment Life), or on the receipt of an ICMP error, and only then delete the outstanding data segments. If multiple retransmissions are triggered that indicate that a subflow performs badly, this MAY lead to a host resetting the subflow with a RST. However, additional research is required to understand the heuristics of how and when to reset underperforming subflows. Ford, et al. Expires December 10, 2019 [Page 38] Internet-Draft Multipath TCP June 2019 For example, a highly asymmetric path may be misdiagnosed as underperforming. A RST for this purpose SHOULD be accompanied with an "Unacceptable performance" MP_TCPRST option (Section 3.6). 3.3.7. Congestion Control Considerations Different subflows in an MPTCP connection have different congestion windows. To achieve fairness at bottlenecks and resource pooling, it is necessary to couple the congestion windows in use on each subflow, in order to push most traffic to uncongested links. One algorithm for achieving this is presented in [RFC6356]; the algorithm does not achieve perfect resource pooling but is "safe" in that it is readily deployable in the current Internet. By this, we mean that it does not take up more capacity on any one path than if it was a single path flow using only that route, so this ensures fair coexistence with single-path TCP at shared bottlenecks. It is foreseeable that different congestion controllers will be implemented for MPTCP, each aiming to achieve different properties in the resource pooling/fairness/stability design space, as well as those for achieving different properties in quality of service, reliability, and resilience. Regardless of the algorithm used, the design of the MPTCP protocol aims to provide the congestion control implementations sufficient information to take the right decisions; this information includes, for each subflow, which packets were lost and when. 3.3.8. Subflow Policy Within a local MPTCP implementation, a host may use any local policy it wishes to decide how to share the traffic to be sent over the available paths. In the typical use case, where the goal is to maximize throughput, all available paths will be used simultaneously for data transfer, using coupled congestion control as described in [RFC6356]. It is expected, however, that other use cases will appear. For instance, a possibility is an 'all-or-nothing' approach, i.e., have a second path ready for use in the event of failure of the first path, but alternatives could include entirely saturating one path before using an additional path (the 'overflow' case). Such choices would be most likely based on the monetary cost of links, but may also be based on properties such as the delay or jitter of links, where stability (of delay or bandwidth) is more important than throughput. Application requirements such as these are discussed in detail in [RFC6897]. Ford, et al. Expires December 10, 2019 [Page 39] Internet-Draft Multipath TCP June 2019 The ability to make effective choices at the sender requires full knowledge of the path "cost", which is unlikely to be the case. It would be desirable for a receiver to be able to signal their own preferences for paths, since they will often be the multihomed party, and may have to pay for metered incoming bandwidth. To enable this, the MP_JOIN option (see Section 3.2) contains the 'B' bit, which allows a host to indicate to its peer that this path should be treated as a backup path to use only in the event of failure of other working subflows (i.e., a subflow where the receiver has indicated B=1 SHOULD NOT be used to send data unless there are no usable subflows where B=0). In the event that the available set of paths changes, a host may wish to signal a change in priority of subflows to the peer (e.g., a subflow that was previously set as backup should now take priority over all remaining subflows). Therefore, the MP_PRIO option, shown in Figure 11, can be used to change the 'B' flag of the subflow on which it is sent. Another use of the MP_PRIO option is to set the 'B' flag on a subflow to cleanly retire its use before closing it and removing it with REMOVE_ADDR Section 3.4.2, for example to support make-before-break session continuity, where new subflows are added before the previously used ones are closed. 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 +---------------+---------------+-------+-----+-+ | Kind | Length |Subtype|(rsv)|B| +---------------+---------------+-------+-----+-+ Figure 11: Change Subflow Priority (MP_PRIO) Option It should be noted that the backup flag is a request from a data receiver to a data sender only, and the data sender SHOULD adhere to these requests. A host cannot assume that the data sender will do so, however, since local policies -- or technical difficulties -- may override MP_PRIO requests. Note also that this signal applies to a single direction, and so the sender of this option could choose to continue using the subflow to send data even if it has signaled B=1 to the other host. 3.4. Address Knowledge Exchange (Path Management) We use the term "path management" to refer to the exchange of information about additional paths between hosts, which in this design is managed by multiple addresses at hosts. For more detail of Ford, et al. Expires December 10, 2019 [Page 40] Internet-Draft Multipath TCP June 2019 the architectural thinking behind this design, see the MPTCP Architecture document [RFC6182]. This design makes use of two methods of sharing such information, and both can be used on a connection. The first is the direct setup of new subflows, already described in Section 3.2, where the initiator has an additional address. The second method, described in the following subsections, signals addresses explicitly to the other host to allow it to initiate new subflows. The two mechanisms are complementary: the first is implicit and simple, while the explicit is more complex but is more robust. Together, the mechanisms allow addresses to change in flight (and thus support operation through NATs, since the source address need not be known), and also allow the signaling of previously unknown addresses, and of addresses belonging to other address families (e.g., both IPv4 and IPv6). Here is an example of typical operation of the protocol: o An MPTCP connection is initially set up between address/port A1 of Host A and address/port B1 of Host B. If Host A is multihomed and multiaddressed, it can start an additional subflow from its address A2 to B1, by sending a SYN with a Join option from A2 to B1, using B's previously declared token for this connection. Alternatively, if B is multihomed, it can try to set up a new subflow from B2 to A1, using A's previously declared token. In either case, the SYN will be sent to the port already in use for the original subflow on the receiving host. o Simultaneously (or after a timeout), an ADD_ADDR option (Section 3.4.1) is sent on an existing subflow, informing the receiver of the sender's alternative address(es). The recipient can use this information to open a new subflow to the sender's additional address. In our example, A will send ADD_ADDR option informing B of address/port A2. The mix of using the SYN-based option and the ADD_ADDR option, including timeouts, is implementation specific and can be tailored to agree with local policy. o If subflow A2-B1 is successfully set up, Host B can use the Address ID in the Join option to correlate this with the ADD_ADDR option that will also arrive on an existing subflow; now B knows not to open A2-B1, ignoring the ADD_ADDR. Otherwise, if B has not received the A2-B1 MP_JOIN SYN but received the ADD_ADDR, it can try to initiate a new subflow from one or more of its addresses to address A2. This permits new sessions to be opened if one host is behind a NAT. Ford, et al. Expires December 10, 2019 [Page 41] Internet-Draft Multipath TCP June 2019 Other ways of using the two signaling mechanisms are possible; for instance, signaling addresses in other address families can only be done explicitly using the Add Address option. 3.4.1. Address Advertisement The Add Address (ADD_ADDR) MPTCP option announces additional addresses (and optionally, ports) on which a host can be reached (Figure 12). This option can be used at any time during a connection, depending on when the sender wishes to enable multiple paths and/or when paths become available. As with all MPTCP signals, the receiver MUST undertake standard TCP validity checks, e.g. [RFC5961], before acting upon it. Every address has an Address ID that can be used for uniquely identifying the address within a connection for address removal. The Address ID is also used to identify MP_JOIN options (see Section 3.2) relating to the same address, even when address translators are in use. The Address ID MUST uniquely identify the address for the sender of the option (within the scope of the connection), but the mechanism for allocating such IDs is implementation specific. All address IDs learned via either MP_JOIN or ADD_ADDR SHOULD be stored by the receiver in a data structure that gathers all the Address ID to address mappings for a connection (identified by a token pair). In this way, there is a stored mapping between Address ID, observed source address, and token pair for future processing of control information for a connection. Note that an implementation MAY discard incoming address advertisements at will, for example, for avoiding updating mapping state, or because advertised addresses are of no use to it (for example, IPv6 addresses when it has IPv4 only). Therefore, a host MUST treat address advertisements as soft state, and it MAY choose to refresh advertisements periodically. Note also that an implementation MAY choose to cache these address advertisements even if they are not currently relevant but may be relevant in the future, such as IPv4 addresses when IPv6 connectivity is available but IPv4 is awaiting DHCP. This option is shown in Figure 12. The illustration is sized for IPv4 addresses. For IPv6, the length of the address will be 16 octets (instead of 4). The 2 octets that specify the TCP port number to use are optional and their presence can be inferred from the length of the option. Although it is expected that the majority of use cases will use the same port pairs as used for the initial subflow (e.g., port 80 remains port 80 on all subflows, as does the ephemeral port at the client), there may be cases (such as port-based load balancing) where Ford, et al. Expires December 10, 2019 [Page 42] Internet-Draft Multipath TCP June 2019 the explicit specification of a different port is required. If no port is specified, MPTCP SHOULD attempt to connect to the specified address on the same port as is already in use by the subflow on which the ADD_ADDR signal was sent; this is discussed in more detail in Section 3.9. The Truncated HMAC present in this Option is the rightmost 64 bits of an HMAC, negotiated and calculated in the same way as for MP_JOIN as described in Section 3.2. For this specification of MPTCP, as there is only one hash algorithm option specified, this will be HMAC as defined in [RFC2104], using the SHA-256 hash algorithm [RFC6234]. In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged in the original MP_CAPABLE handshake. The message for the HMAC is the Address ID, IP Address, and Port which precede the HMAC in the ADD_ADDR option. If the port is not present in the ADD_ADDR option, the HMAC message will nevertheless include two octets of value zero. The rationale for the HMAC is to prevent unauthorized entities from injecting ADD_ADDR signals in an attempt to hijack a connection. Note that additionally the presence of this HMAC prevents the address being changed in flight unless the key is known by an intermediary. If a host receives an ADD_ADDR option for which it cannot validate the HMAC, it SHOULD silently ignore the option. A set of four flags are present after the subtype and before the Address ID. Only the rightmost bit - labelled 'E' - is assigned in this specification. The other bits are currently unassigned and MUST be set to zero by a sender and MUST be ignored by the receiver. The 'E' flag exists to provide reliability for this option. Because this option will often be sent on pure ACKs, there is no guarantee of reliability. Therefore, a receiver receiving a fresh ADD_ADDR option (where E=0), will send the same option back to the sender, but not including the HMAC, and with E=1, to indicate receipt. The lack of this echo can be used by the initial ADD_ADDR sender to retransmit the ADD_ADDR according to local policy. Ford, et al. Expires December 10, 2019 [Page 43] Internet-Draft Multipath TCP June 2019 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 +---------------+---------------+-------+-------+---------------+ | Kind | Length |Subtype|(rsv)|E| Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | | +-------------------------------+ | | Truncated HMAC (8 octets, if E=0) | | +-------------------------------+ | | +-------------------------------+ Figure 12: Add Address (ADD_ADDR) Option Due to the proliferation of NATs, it is reasonably likely that one host may attempt to advertise private addresses [RFC1918]. It is not desirable to prohibit this, since there may be cases where both hosts have additional interfaces on the same private network, and a host MAY advertise such addresses. The MP_JOIN handshake to create a new subflow (Section 3.2) provides mechanisms to minimize security risks. The MP_JOIN message contains a 32-bit token that uniquely identifies the connection to the receiving host. If the token is unknown, the host will return with a RST. In the unlikely event that the token is valid at the receiving host, subflow setup will continue, but the HMAC exchange must occur for authentication. This will fail, and will provide sufficient protection against two unconnected hosts accidentally setting up a new subflow upon the signal of a private address. Further security considerations around the issue of ADD_ADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in Section 5. A host that receives an ADD_ADDR but finds a connection set up to that IP address and port number is unsuccessful SHOULD NOT perform further connection attempts to this address/port combination for this connection. A sender that wants to trigger a new incoming connection attempt on a previously advertised address/port combination can therefore refresh ADD_ADDR information by sending the option again. A host can therefore send an ADD_ADDR message with an already assigned Address ID, but the Address MUST be the same as previously assigned to this Address ID. A new ADD_ADDR may have the same, or different, port number. If the port number is different, the receiving host SHOULD try to set up a new subflow to this new address/port combination. Ford, et al. Expires December 10, 2019 [Page 44] Internet-Draft Multipath TCP June 2019 A host wishing to replace an existing Address ID MUST first remove the existing one (Section 3.4.2). During normal MPTCP operation, it is unlikely that there will be sufficient TCP option space for ADD_ADDR to be included along with those for data sequence numbering (Section 3.3.1). Therefore, it is expected that an MPTCP implementation will send the ADD_ADDR option on separate ACKs. As discussed earlier, however, an MPTCP implementation MUST NOT treat duplicate ACKs with any MPTCP option, with the exception of the DSS option, as indications of congestion [RFC5681], and an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for signaling purposes. 3.4.2. Remove Address If, during the lifetime of an MPTCP connection, a previously announced address becomes invalid (e.g., if the interface disappears, or an IPv6 address is no longer preferred), the affected host SHOULD announce this so that the peer can remove subflows related to this address. Even if an address is not in use by a MPTCP connection, if it has been previously announced, an implementation SHOULD announce its removal. A host MAY also choose to announce that a valid IP address should not be used any longer, for example for make-before- break session continuity. This is achieved through the Remove Address (REMOVE_ADDR) option (Figure 13), which will remove a previously added address (or list of addresses) from a connection and terminate any subflows currently using that address. For security purposes, if a host receives a REMOVE_ADDR option, it must ensure the affected path(s) are no longer in use before it instigates closure. The receipt of REMOVE_ADDR SHOULD first trigger the sending of a TCP keepalive [RFC1122] on the path, and if a response is received the path SHOULD NOT be removed. If the path is found to still be alive, the receiving host SHOULD no longer use the specified address for future connections, but it is the responsibility of the host which sent the REMOVE_ADDR to shut down the subflow. The requesting host MAY also use MP_PRIO (Section 3.3.8) to request a path is no longer used, before removal. Typical TCP validity tests on the subflow (e.g., ensuring sequence and ACK numbers are correct) MUST also be undertaken. An implementation can use indications of these test failures as part of intrusion detection or error logging. The sending and receipt (if no keepalive response was received) of this message SHOULD trigger the sending of RSTs by both hosts on the Ford, et al. Expires December 10, 2019 [Page 45] Internet-Draft Multipath TCP June 2019 affected subflow(s) (if possible), as a courtesy to cleaning up middlebox state, before cleaning up any local state. Address removal is undertaken by ID, so as to permit the use of NATs and other middleboxes that rewrite source addresses. If there is no address at the requested ID, the receiver will silently ignore the request. A subflow that is still functioning MUST be closed with a FIN exchange as in regular TCP, rather than using this option. For more information, see Section 3.3.3. 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 +---------------+---------------+-------+-------+---------------+ | Kind | Length = 3+n |Subtype|(resvd)| Address ID | ... +---------------+---------------+-------+-------+---------------+ (followed by n-1 Address IDs, if required) Figure 13: Remove Address (REMOVE_ADDR) Option 3.5. Fast Close Regular TCP has the means of sending a reset (RST) signal to abruptly close a connection. With MPTCP, a regular RST only has the scope of the subflow and will only close the concerned subflow but not affect the remaining subflows. MPTCP's connection will stay alive at the data level, in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MPTCP-level "reset" to allow the abrupt closure of the whole MPTCP connection, and this is the MP_FASTCLOSE option. MP_FASTCLOSE is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. The reasons for triggering an MP_FASTCLOSE are implementation specific. Regular TCP does not allow sending a RST while the connection is in a synchronized state [RFC0793]. Nevertheless, implementations allow the sending of a RST in this state, if, for example, the operating system is running out of resources. In these cases, MPTCP should send the MP_FASTCLOSE. This option is illustrated in Figure 14. Ford, et al. Expires December 10, 2019 [Page 46] Internet-Draft Multipath TCP June 2019 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 +---------------+---------------+-------+-----------------------+ | Kind | Length |Subtype| (reserved) | +---------------+---------------+-------+-----------------------+ | Option Receiver's Key | | (64 bits) | | | +---------------------------------------------------------------+ Figure 14: Fast Close (MP_FASTCLOSE) Option If Host A wants to force the closure of an MPTCP connection, it has two different options: o Option A (ACK) : Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake. On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down. Host A now enters FASTCLOSE_WAIT state. o Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE option on all subflows, containing the key of Host B as declared in the initial connection handshake. Host A can tear the subflows and the connection down immediately. If host A decides to force the closure by using Option A and sending an ACK with the MP_FASTCLOSE option, the connection shall proceed as follows: o Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows also through sending TCP RST signals. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). o As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole connection (transition from FASTCLOSE_WAIT to CLOSED states). If Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts attempted fast closure simultaneously. Host A should reply with a TCP RST and tear down the connection. o If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow where the MP_FASTCLOSE has been sent), it SHOULD retransmit the MP_FASTCLOSE. The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but Ford, et al. Expires December 10, 2019 [Page 47] Internet-Draft Multipath TCP June 2019 this limit is implementation specific. A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP RST with the MP_FASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes. If however host A decides to force the closure by using Option R and sending a RST with the MP_FASTCLOSE option, Host B will act as follows: Upon receipt of a RST with MP_FASTCLOSE, containing the valid key, Host B tears down all subflows by sending a TCP RST. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). 3.6. Subflow Reset An implementation of MPTCP may also need to send a regular TCP RST to force the closure of a subflow. A host sends a TCP RST in order to close a subflow or reject an attempt to open a subflow (MP_JOIN). In order to inform the receiving host why a subflow is being closed or rejected, the TCP RST packet MAY include the MP_TCPRST Option. The host MAY use this information to decide, for example, whether it tries to re-establish the subflow immediately, later, or never. 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 +---------------+---------------+-------+-----------------------+ | Kind | Length |Subtype|U|V|W|T| Reason | +---------------+---------------+-------+-----------------------+ Figure 15: TCP RST Reason (MP_TCPRST) Option The MP_TCPRST option contains a reason code that allows the sender of the option to provide more information about the reason for the termination of the subflow. Using 12 bits of option space, the first four bits are reserved for flags (only one of which is currently defined), and the remaining octet is used to express a reason code for this subflow termination, from which a receiver MAY infer information about the usability of this path. The "T" flag is used by the sender to indicate whether the error condition that is reported is Transient (T bit set to 1) or Permanent (T bit set to 0). If the error condition is considered to be Transient by the sender of the RST segment, the recipient of this segment MAY try to reestablish a subflow for this connection over the failed path. The time at which a receiver may try to re-establish this is implementation-specific, but SHOULD take into account the properties of the failure defined by the following reason code. If the error condition is considered to be permanent, the receiver of the RST segment SHOULD NOT try to reestablish a subflow for this Ford, et al. Expires December 10, 2019 [Page 48] Internet-Draft Multipath TCP June 2019 connection over this path. The "U", "V" and "W" flags are not defined by this specification and are reserved for future use. An implementation of this specification MUST set these flags to 0, and a receiver MUST ignore them. The "Reason" code is an 8-bit field that indicates the reason for the termination of the subflow. The following codes are defined in this document: o Unspecified error (code 0x0). This is the default error implying the subflow is no longer available. The presence of this option shows that the RST was generated by a MPTCP-aware device. o MPTCP specific error (code 0x01). An error has been detected in the processing of MPTCP options. This is the usual reason code to return in the cases where a RST is being sent to close a subflow for reasons of an invalid response. o Lack of resources (code 0x02). This code indicates that the sending host does not have enough resources to support the terminated subflow. o Administratively prohibited (code 0x03). This code indicates that the requested subflow is prohibited by the policies of the sending host. o Too much outstanding data (code 0x04). This code indicates that there is an excessive amount of data that need to be transmitted over the terminated subflow while having already been acknowledged over one or more other subflows. This may occur if a path has been unavailable for a short period and it is more efficient to reset and start again than it is to retransmit the queued data. o Unacceptable performance (code 0x05). This code indicates that the performance of this subflow was too low compared to the other subflows of this Multipath TCP connection. o Middlebox interference (code 0x06). Middlebox interference has been detected over this subflow making MPTCP signaling invalid. For example, this may be sent if the checksum does not validate. 3.7. Fallback Sometimes, middleboxes will exist on a path that could prevent the operation of MPTCP. MPTCP has been designed in order to cope with many middlebox modifications (see Section 6), but there are still some cases where a subflow could fail to operate within the MPTCP requirements. These cases are notably the following: the loss of Ford, et al. Expires December 10, 2019 [Page 49] Internet-Draft Multipath TCP June 2019 MPTCP options on a path, and the modification of payload data. If such an event occurs, it is necessary to "fall back" to the previous, safe operation. This may be either falling back to regular TCP or removing a problematic subflow. At the start of an MPTCP connection (i.e., the first subflow), it is important to ensure that the path is fully MPTCP capable and the necessary MPTCP options can reach each host. The handshake as described in Section 3.1 SHOULD fall back to regular TCP if either of the SYN messages do not have the MPTCP options: this is the same, and desired, behavior in the case where a host is not MPTCP capable, or the path does not support the MPTCP options. When attempting to join an existing MPTCP connection (Section 3.2), if a path is not MPTCP capable and the MPTCP options do not get through on the SYNs, the subflow will be closed according to the MP_JOIN logic. There is, however, another corner case that should be addressed. That is one of MPTCP options getting through on the SYN, but not on regular packets. This can be resolved if the subflow is the first subflow, and thus all data in flight is contiguous, using the following rules. A sender MUST include a DSS option with data sequence mapping in every segment until one of the sent segments has been acknowledged with a DSS option containing a Data ACK. Upon reception of the acknowledgment, the sender has the confirmation that the DSS option passes in both directions and may choose to send fewer DSS options than once per segment. If, however, an ACK is received for data (not just for the SYN) without a DSS option containing a Data ACK, the sender determines the path is not MPTCP capable. In the case of this occurring on an additional subflow (i.e., one started with MP_JOIN), the host MUST close the subflow with a RST, which SHOULD contain a MP_TCPRST option (Section 3.6) with a "Middlebox interference" reason code. In the case of such an ACK being received on the first subflow (i.e., that started with MP_CAPABLE), before any additional subflows are added, the implementation MUST drop out of an MPTCP mode, back to regular TCP. The sender will send one final data sequence mapping, with the Data-Level Length value of 0 indicating an infinite mapping (to inform the other end in case the path drops options in one direction only), and then revert to sending data on the single subflow without any MPTCP options. If a subflow breaks during operation, e.g. if it is re-routed and MPTCP options are no longer permitted, then once this is detected (by the subflow-level receive buffer filling up, since there is no Ford, et al. Expires December 10, 2019 [Page 50] Internet-Draft Multipath TCP June 2019 mapping available in order to DATA_ACK this data), the subflow SHOULD be treated as broken and closed with a RST, since no data can be delivered to the application layer, and no fallback signal can be reliably sent. This RST SHOULD include the MP_TCPRST option (Section 3.6) with a "Middlebox interference" reason code. These rules should cover all cases where such a failure could happen: whether it's on the forward or reverse path and whether the server or the client first sends data. So far this section has discussed the loss of MPTCP options, either initially, or during the course of the connection. As described in Section 3.3, each portion of data for which there is a mapping is protected by a checksum, if checksums have been negotiated. This mechanism is used to detect if middleboxes have made any adjustments to the payload (added, removed, or changed data). A checksum will fail if the data has been changed in any way. This will also detect if the length of data on the subflow is increased or decreased, and this means the data sequence mapping is no longer valid. The sender no longer knows what subflow-level sequence number the receiver is genuinely operating at (the middlebox will be faking ACKs in return), and it cannot signal any further mappings. Furthermore, in addition to the possibility of payload modifications that are valid at the application layer, there is the possibility that such modifications could be triggered across MPTCP segment boundaries, corrupting the data. Therefore, all data from the start of the segment that failed the checksum onwards is not trustworthy. Note that if checksum usage has not been negotiated, this fallback mechanism cannot be used unless there is some higher or lower layer signal to inform the MPTCP implementation that the payload has been tampered with. When multiple subflows are in use, the data in flight on a subflow will likely involve data that is not contiguously part of the connection-level stream, since segments will be spread across the multiple subflows. Due to the problems identified above, it is not possible to determine what adjustment has done to the data (notably, any changes to the subflow sequence numbering). Therefore, it is not possible to recover the subflow, and the affected subflow must be immediately closed with a RST, featuring an MP_FAIL option (Figure 16), which defines the data sequence number at the start of the segment (defined by the data sequence mapping) that had the checksum failure. Note that the MP_FAIL option requires the use of the full 64-bit sequence number, even if 32-bit sequence numbers are normally in use in the DSS signals on the path. Ford, et al. Expires December 10, 2019 [Page 51] Internet-Draft Multipath TCP June 2019 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 +---------------+---------------+-------+----------------------+ | Kind | Length=12 |Subtype| (reserved) | +---------------+---------------+-------+----------------------+ | | | Data Sequence Number (8 octets) | | | +--------------------------------------------------------------+ Figure 16: Fallback (MP_FAIL) Option The receiver of this option MUST discard all data following the data sequence number specified. Failed data MUST NOT be DATA_ACKed and so will be retransmitted on other subflows (Section 3.3.6). A special case is when there is a single subflow and it fails with a checksum error. If it is known that all unacknowledged data in flight is contiguous (which will usually be the case with a single subflow), an infinite mapping can be applied to the subflow without the need to close it first, and essentially turn off all further MPTCP signaling. In this case, if a receiver identifies a checksum failure when there is only one path, it will send back an MP_FAIL option on the subflow-level ACK, referring to the data-level sequence number of the start of the segment on which the checksum error was detected. The sender will receive this, and if all unacknowledged data in flight is contiguous, will signal an infinite mapping. This infinite mapping will be a DSS option (Section 3.3) on the first new packet, containing a data sequence mapping that acts retroactively, referring to the start of the subflow sequence number of the most recent segment that was known to be delivered intact (i.e. was successfully DATA_ACKed). From that point onwards, data can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session. Whilst in theory paths may only be damaged in one direction, and the MP_FAIL signal affects only one direction of traffic, for implementation simplicity, the receiver of an MP_FAIL MUST also respond with an MP_FAIL in the reverse direction and entirely revert to a regular TCP session. In the rare case that the data is not contiguous (which could happen when there is only one subflow but it is retransmitting data from a subflow that has recently been uncleanly closed), the receiver MUST close the subflow with a RST with MP_FAIL. The receiver MUST discard all data that follows the data sequence number specified. The sender MAY attempt to create a new subflow belonging to the same connection, and, if it chooses to do so, SHOULD place the single subflow immediately in single-path mode by setting an infinite data sequence Ford, et al. Expires December 10, 2019 [Page 52] Internet-Draft Multipath TCP June 2019 mapping. This mapping will begin from the data-level sequence number that was declared in the MP_FAIL. After a sender signals an infinite mapping, it MUST only use subflow ACKs to clear its send buffer. This is because Data ACKs may become misaligned with the subflow ACKs when middleboxes insert or delete data. The receive SHOULD stop generating Data ACKs after it receives an infinite mapping. When a connection has fallen back with an infinite mapping, only one subflow can send data; otherwise, the receiver would not know how to reorder the data. In practice, this means that all MPTCP subflows will have to be terminated except one. Once MPTCP falls back to regular TCP, it MUST NOT revert to MPTCP later in the connection. It should be emphasized that MPTCP is not attempting to prevent the use of middleboxes that want to adjust the payload. An MPTCP-aware middlebox could provide such functionality by also rewriting checksums. 3.8. Error Handling In addition to the fallback mechanism as described above, the standard classes of TCP errors may need to be handled in an MPTCP- specific way. Note that changing semantics -- such as the relevance of a RST -- are covered in Section 4. Where possible, we do not want to deviate from regular TCP behavior. The following list covers possible errors and the appropriate MPTCP behavior: o Unknown token in MP_JOIN (or HMAC failure in MP_JOIN ACK, or missing MP_JOIN in SYN/ACK response): send RST (analogous to TCP's behavior on an unknown port) o DSN out of window (during normal operation): drop the data, do not send Data ACKs o Remove request for unknown address ID: silently ignore 3.9. Heuristics There are a number of heuristics that are needed for performance or deployment but that are not required for protocol correctness. In this section, we detail such heuristics. Note that discussion of buffering and certain sender and receiver window behaviors are presented in Sections 3.3.4 and 3.3.5, as well as retransmission in Section 3.3.6. Ford, et al. Expires December 10, 2019 [Page 53] Internet-Draft Multipath TCP June 2019 3.9.1. Port Usage Under typical operation, an MPTCP implementation SHOULD use the same ports as already in use. In other words, the destination port of a SYN containing an MP_JOIN option SHOULD be the same as the remote port of the first subflow in the connection. The local port for such SYNs SHOULD also be the same as for the first subflow (and as such, an implementation SHOULD reserve ephemeral ports across all local IP addresses), although there may be cases where this is infeasible. This strategy is intended to maximize the probability of the SYN being permitted by a firewall or NAT at the recipient and to avoid confusing any network monitoring software. There may also be cases, however, where a host wishes to signal that a specific port should be used, and this facility is provided in the ADD_ADDR option as documented in Section 3.4.1. It is therefore feasible to allow multiple subflows between the same two addresses but using different port pairs, and such a facility could be used to allow load balancing within the network based on 5-tuples (e.g., some ECMP implementations [RFC2992]). 3.9.2. Delayed Subflow Start and Subflow Symmetry Many TCP connections are short-lived and consist only of a few segments, and so the overheads of using MPTCP outweigh any benefits. A heuristic is required, therefore, to decide when to start using additional subflows in an MPTCP connection. Experimental deployments have shown that MPTCP can be applied in a range of scenarios so an implementation is likely to need to take into account factors including the type of traffic being sent and duration of session, and this information MAY be signalled by the application layer. However, for standard TCP traffic, a suggested general-purpose heuristic that an implementation MAY choose to employ is as follows. If a host has data buffered for its peer (which implies that the application has received a request for data), the host opens one subflow for each initial window's worth of data that is buffered. Consideration should also be given to limiting the rate of adding new subflows, as well as limiting the total number of subflows open for a particular connection. A host may choose to vary these values based on its load or knowledge of traffic and path characteristics. Note that this heuristic alone is probably insufficient. Traffic for many common applications, such as downloads, is highly asymmetric and the host that is multihomed may well be the client that will never fill its buffers, and thus never use MPTCP according to this Ford, et al. Expires December 10, 2019 [Page 54] Internet-Draft Multipath TCP June 2019 heuristic. Advanced APIs that allow an application to signal its traffic requirements would aid in these decisions. An additional time-based heuristic could be applied, opening additional subflows after a given period of time has passed. This would alleviate the above issue, and also provide resilience for low- bandwidth but long-lived applications. Another issue is that both communicating hosts may simultaneously try to set up a subflow between the same pair of addresses. This leads to an inefficient use of resources. If the same ports are used on all subflows, as recommended above, then standard TCP simultaneous open logic should take care of this situation and only one subflow will be established between the address pairs. However, this relies on the same ports being used at both end hosts. If a host does not support TCP simultaneous open, it is RECOMMENDED that some element of randomization is applied to the time to wait before opening new subflows, so that only one subflow is created between a given address pair. If, however, hosts signal additional ports to use (for example, for leveraging ECMP on-path), this heuristic is not appropriate. This section has shown some of the considerations that an implementer should give when developing MPTCP heuristics, but is not intended to be prescriptive. 3.9.3. Failure Handling Requirements for MPTCP's handling of unexpected signals have been given in Section 3.8. There are other failure cases, however, where a hosts can choose appropriate behavior. For example, Section 3.1 suggests that a host SHOULD fall back to trying regular TCP SYNs after one or more failures of MPTCP SYNs for a connection. A host may keep a system-wide cache of such information, so that it can back off from using MPTCP, firstly for that particular destination host, and eventually on a whole interface, if MPTCP connections continue failing. The duration of such a cache would be implementation-specific. Another failure could occur when the MP_JOIN handshake fails. Section 3.8 specifies that an incorrect handshake MUST lead to the subflow being closed with a RST. A host operating an active intrusion detection system may choose to start blocking MP_JOIN packets from the source host if multiple failed MP_JOIN attempts are seen. From the connection initiator's point of view, if an MP_JOIN fails, it SHOULD NOT attempt to connect to the same IP address and Ford, et al. Expires December 10, 2019 [Page 55] Internet-Draft Multipath TCP June 2019 port during the lifetime of the connection, unless the other host refreshes the information with another ADD_ADDR option. Note that the ADD_ADDR option is informational only, and does not guarantee the other host will attempt a connection. In addition, an implementation may learn, over a number of connections, that certain interfaces or destination addresses consistently fail and may default to not trying to use MPTCP for these. Behavior could also be learned for particularly badly performing subflows or subflows that regularly fail during use, in order to temporarily choose not to use these paths. 4. Semantic Issues In order to support multipath operation, the semantics of some TCP components have changed. To aid clarity, this section collects these semantic changes as a reference. Sequence number: The (in-header) TCP sequence number is specific to the subflow. To allow the receiver to reorder application data, an additional data-level sequence space is used. In this data- level sequence space, the initial SYN and the final DATA_FIN occupy 1 octet of sequence space. This is to ensure these signals are acknowledged at the connection level. There is an explicit mapping of data sequence space to subflow sequence space, which is signaled through TCP options in data packets. ACK: The ACK field in the TCP header acknowledges only the subflow sequence number, not the data-level sequence space. Implementations SHOULD NOT attempt to infer a data-level acknowledgment from the subflow ACKs. This separates subflow- and connection-level processing at an end host. Duplicate ACK: A duplicate ACK that includes any MPTCP signaling (with the exception of the DSS option) MUST NOT be treated as a signal of congestion. To limit the chances of non-MPTCP-aware entities mistakenly interpreting duplicate ACKs as a signal of congestion, MPTCP SHOULD NOT send more than two duplicate ACKs containing (non-DSS) MPTCP signals in a row. Receive Window: The receive window in the TCP header indicates the amount of free buffer space for the whole data-level connection (as opposed to for this subflow) that is available at the receiver. This is the same semantics as regular TCP, but to maintain these semantics the receive window must be interpreted at the sender as relative to the sequence number given in the DATA_ACK rather than the subflow ACK in the TCP header. In this way, the original flow control role is preserved. Note that some Ford, et al. Expires December 10, 2019 [Page 56] Internet-Draft Multipath TCP June 2019 middleboxes may change the receive window, and so a host SHOULD use the maximum value of those recently seen on the constituent subflows for the connection-level receive window, and also needs to maintain a subflow-level window for subflow-level processing. FIN: The FIN flag in the TCP header applies only to the subflow it is sent on, not to the whole connection. For connection-level FIN semantics, the DATA_FIN option is used. RST: The RST flag in the TCP header applies only to the subflow it is sent on, not to the whole connection. The MP_FASTCLOSE option provides the fast close functionality of a RST at the MPTCP connection level. Address List: Address list management (i.e., knowledge of the local and remote hosts' lists of available IP addresses) is handled on a per-connection basis (as opposed to per subflow, per host, or per pair of communicating hosts). This permits the application of per-connection local policy. Adding an address to one connection (either explicitly through an Add Address message, or implicitly through a Join) has no implication for other connections between the same pair of hosts. 5-tuple: The 5-tuple (protocol, local address, local port, remote address, remote port) presented by kernel APIs to the application layer in a non-multipath-aware application is that of the first subflow, even if the subflow has since been closed and removed from the connection. This decision, and other related API issues, are discussed in more detail in [RFC6897]. 5. Security Considerations As identified in [RFC6181], the addition of multipath capability to TCP will bring with it a number of new classes of threat. In order to prevent these, [RFC6182] presents a set of requirements for a security solution for MPTCP. The fundamental goal is for the security of MPTCP to be "no worse" than regular TCP today, and the key security requirements are: o Provide a mechanism to confirm that the parties in a subflow handshake are the same as in the original connection setup. o Provide verification that the peer can receive traffic at a new address before using it as part of a connection. o Provide replay protection, i.e., ensure that a request to add/ remove a subflow is 'fresh'. Ford, et al. Expires December 10, 2019 [Page 57] Internet-Draft Multipath TCP June 2019 In order to achieve these goals, MPTCP includes a hash-based handshake algorithm documented in Sections 3.1 and 3.2. The security of the MPTCP connection hangs on the use of keys that are shared once at the start of the first subflow, and are never sent again over the network (unless used in the fast close mechanism, Section 3.5). To ease demultiplexing while not giving away any cryptographic material, future subflows use a truncated cryptographic hash of this key as the connection identification "token". The keys are concatenated and used as keys for creating Hash-based Message Authentication Codes (HMACs) used on subflow setup, in order to verify that the parties in the handshake are the same as in the original connection setup. It also provides verification that the peer can receive traffic at this new address. Replay attacks would still be possible when only keys are used; therefore, the handshakes use single-use random numbers (nonces) at both ends -- this ensures the HMAC will never be the same on two handshakes. Guidance on generating random numbers suitable for use as keys is given in [RFC4086] and discussed in Section 3.1. The nonces are valid for the lifetime of the TCP connection attempt. HMAC is also used to secure the ADD_ADDR option, due to the threats identified in [RFC7430]. The use of crypto capability bits in the initial connection handshake to negotiate use of a particular algorithm allows the deployment of additional crypto mechanisms in the future. This negotiation would nevertheless be susceptible to a bid-down attack by an on-path active attacker who could modify the crypto capability bits in the response from the receiver to use a less secure crypto mechanism. The security mechanism presented in this document should therefore protect against all forms of flooding and hijacking attacks discussed in [RFC6181]. The version negotiation specified in Section 3.1, if differing MPTCP versions shared a common negotiation format, would allow an on-path attacker to apply a theoretical bid-down attack. Since the v1 and v0 protocols have a different handshake, such an attack would require the client to re-establish the connection using v0, and this being supported by the server. Note that an on-path attacker would have access to the raw data, negating any other TCP-level security mechanisms. Also a change from RFC6824 has removed the subflow identifier from the MP_PRIO option (Section 3.3.8), to remove the theoretical attack where a subflow could be placed in "backup" mode by an attacker. During normal operation, regular TCP protection mechanisms (such as ensuring sequence numbers are in-window) will provide the same level of protection against attacks on individual TCP subflows as exists for regular TCP today. Implementations will introduce additional Ford, et al. Expires December 10, 2019 [Page 58] Internet-Draft Multipath TCP June 2019 buffers compared to regular TCP, to reassemble data at the connection level. The application of window sizing will minimize the risk of denial-of-service attacks consuming resources. As discussed in Section 3.4.1, a host may advertise its private addresses, but these might point to different hosts in the receiver's network. The MP_JOIN handshake (Section 3.2) will ensure that this does not succeed in setting up a subflow to the incorrect host. However, it could still create unwanted TCP handshake traffic. This feature of MPTCP could be a target for denial-of-service exploits, with malicious participants in MPTCP connections encouraging the recipient to target other hosts in the network. Therefore, implementations should consider heuristics (Section 3.9) at both the sender and receiver to reduce the impact of this. To further protect against malicious ADD_ADDR messages sent by an off-path attacker, the ADD_ADDR includes an HMAC using the keys negotiated during the handshake. This effectively prevents an attacker from diverting an MPTCP connection through an off-path ADD_ADDR injection into the stream. A small security risk could theoretically exist with key reuse, but in order to accomplish a replay attack, both the sender and receiver keys, and the sender and receiver random numbers, in the MP_JOIN handshake (Section 3.2) would have to match. Whilst this specification defines a "medium" security solution, meeting the criteria specified at the start of this section and the threat analysis ([RFC6181]), since attacks only ever get worse, it is likely that a future version of MPTCP would need to be able to support stronger security. There are several ways the security of MPTCP could potentially be improved; some of these would be compatible with MPTCP as defined in this document, whilst others may not be. For now, the best approach is to get experience with the current approach, establish what might work, and check that the threat analysis is still accurate. Possible ways of improving MPTCP security could include: o defining a new MPCTP cryptographic algorithm, as negotiated in MP_CAPABLE. A sub-case could be to include an additional deployment assumption, such as stateful servers, in order to allow a more powerful algorithm to be used. o defining how to secure data transfer with MPTCP, whilst not changing the signaling part of the protocol. Ford, et al. Expires December 10, 2019 [Page 59] Internet-Draft Multipath TCP June 2019 o defining security that requires more option space, perhaps in conjunction with a "long options" proposal for extending the TCP options space (such as those surveyed in [TCPLO]), or perhaps building on the current approach with a second stage of MPTCP- option-based security. o revisiting the working group's decision to exclusively use TCP options for MPTCP signaling, and instead look at also making use of the TCP payloads. MPTCP has been designed with several methods available to indicate a new security mechanism, including: o available flags in MP_CAPABLE (Figure 4); o available subtypes in the MPTCP option (Figure 3); o the version field in MP_CAPABLE (Figure 4); 6. Interactions with Middleboxes Multipath TCP was designed to be deployable in the present world. Its design takes into account "reasonable" existing middlebox behavior. In this section, we outline a few representative middlebox-related failure scenarios and show how Multipath TCP handles them. Next, we list the design decisions multipath has made to accommodate the different middleboxes. A primary concern is our use of a new TCP option. Middleboxes should forward packets with unknown options unchanged, yet there are some that don't. These we expect will either strip options and pass the data, drop packets with new options, copy the same option into multiple segments (e.g., when doing segmentation), or drop options during segment coalescing. MPTCP uses a single new TCP option "Kind", and all message types are defined by "subtype" values (see Section 8). This should reduce the chances of only some types of MPTCP options being passed, and instead the key differing characteristics are different paths, and the presence of the SYN flag. MPTCP SYN packets on the first subflow of a connection contain the MP_CAPABLE option (Section 3.1). If this is dropped, MPTCP SHOULD fall back to regular TCP. If packets with the MP_JOIN option (Section 3.2) are dropped, the paths will simply not be used. If a middlebox strips options but otherwise passes the packets unchanged, MPTCP will behave safely. If an MP_CAPABLE option is Ford, et al. Expires December 10, 2019 [Page 60] Internet-Draft Multipath TCP June 2019 dropped on either the outgoing or the return path, the initiating host can fall back to regular TCP, as illustrated in Figure 17 and discussed in Section 3.1. Subflow SYNs contain the MP_JOIN option. If this option is stripped on the outgoing path, the SYN will appear to be a regular SYN to Host B. Depending on whether there is a listening socket on the target port, Host B will reply either with SYN/ACK or RST (subflow connection fails). When Host A receives the SYN/ACK it sends a RST because the SYN/ACK does not contain the MP_JOIN option and its token. Either way, the subflow setup fails, but otherwise does not affect the MPTCP connection as a whole. Host A Host B | Middlebox M | | | | | SYN(MP_CAPABLE) | SYN | |-------------------|---------------->| | SYN/ACK | |<------------------------------------| a) MP_CAPABLE option stripped on outgoing path Host A Host B | SYN(MP_CAPABLE) | |------------------------------------>| | Middlebox M | | | | | SYN/ACK |SYN/ACK(MP_CAPABLE)| |<----------------|-------------------| b) MP_CAPABLE option stripped on return path Figure 17: Connection Setup with Middleboxes that Strip Options from Packets We now examine data flow with MPTCP, assuming the flow is correctly set up, which implies the options in the SYN packets were allowed through by the relevant middleboxes. If options are allowed through and there is no resegmentation or coalescing to TCP segments, Multipath TCP flows can proceed without problems. The case when options get stripped on data packets has been discussed in the Fallback section. If only some MPTCP options are stripped, behavior is not deterministic. If some data sequence mappings are lost, the connection can continue so long as mappings exist for the subflow-level data (e.g., if multiple maps have been sent that reinforce each other). If some subflow-level space is left unmapped, however, the subflow is treated as broken and is closed, through the process described in Section 3.7. MPTCP should survive with a loss Ford, et al. Expires December 10, 2019 [Page 61] Internet-Draft Multipath TCP June 2019 of some Data ACKs, but performance will degrade as the fraction of stripped options increases. We do not expect such cases to appear in practice, though: most middleboxes will either strip all options or let them all through. We end this section with a list of middlebox classes, their behavior, and the elements in the MPTCP design that allow operation through such middleboxes. Issues surrounding dropping packets with options or stripping options were discussed above, and are not included here: o NATs [RFC3022] (Network Address (and Port) Translators) change the source address (and often source port) of packets. This means that a host will not know its public-facing address for signaling in MPTCP. Therefore, MPTCP permits implicit address addition via the MP_JOIN option, and the handshake mechanism ensures that connection attempts to private addresses [RFC1918], since they are authenticated, will only set up subflows to the correct hosts. Explicit address removal is undertaken by an Address ID to allow no knowledge of the source address. o Performance Enhancing Proxies (PEPs) [RFC3135] might proactively ACK data to increase performance. MPTCP, however, relies on accurate congestion control signals from the end host, and non- MPTCP-aware PEPs will not be able to provide such signals. MPTCP will, therefore, fall back to single-path TCP, or close the problematic subflow (see Section 3.7). o Traffic Normalizers [norm] may not allow holes in sequence numbers, and may cache packets and retransmit the same data. MPTCP looks like standard TCP on the wire, and will not retransmit different data on the same subflow sequence number. In the event of a retransmission, the same data will be retransmitted on the original TCP subflow even if it is additionally retransmitted at the connection level on a different subflow. o Firewalls [RFC2979] might perform initial sequence number randomization on TCP connections. MPTCP uses relative sequence numbers in data sequence mapping to cope with this. Like NATs, firewalls will not permit many incoming connections, so MPTCP supports address signaling (ADD_ADDR) so that a multiaddressed host can invite its peer behind the firewall/NAT to connect out to its additional interface. o Intrusion Detection/Prevention Systems (IDS/IPS) observe packet streams for patterns and content that could threaten a network. MPTCP may require the instrumentation of additional paths, and an MPTCP-aware IDS/IPS would need to read MPTCP tokens to correlate data from mutliple subflows to maintain comparable visibility into Ford, et al. Expires December 10, 2019 [Page 62] Internet-Draft Multipath TCP June 2019 all of the traffic between devices. Without such changes, an IDS would get an incomplete view of the traffic, increasing the risk of missing traffic of interest (false negatives), and increasing the chances of erroneously identifying a subflow as a risk due to only seeing partial data (false positives). o Application-level middleboxes such as content-aware firewalls may alter the payload within a subflow, such as rewriting URIs in HTTP traffic. MPTCP will detect these using the checksum and close the affected subflow(s), if there are other subflows that can be used. If all subflows are affected, multipath will fall back to TCP, allowing such middleboxes to change the payload. MPTCP-aware middleboxes should be able to adjust the payload and MPTCP metadata in order not to break the connection. In addition, all classes of middleboxes may affect TCP traffic in the following ways: o TCP options may be removed, or packets with unknown options dropped, by many classes of middleboxes. It is intended that the initial SYN exchange, with a TCP option, will be sufficient to identify the path capabilities. If such a packet does not get through, MPTCP will end up falling back to regular TCP. o Segmentation/Coalescing (e.g., TCP segmentation offloading) might copy options between packets and might strip some options. MPTCP's data sequence mapping includes the relative subflow sequence number instead of using the sequence number in the segment. In this way, the mapping is independent of the packets that carry it. o The receive window may be shrunk by some middleboxes at the subflow level. MPTCP will use the maximum window at data level, but will also obey subflow-specific windows. 7. Acknowledgments The authors gratefully acknowledge significant input into this document from Sebastien Barre and Andrew McDonald. The authors also wish to acknowledge reviews and contributions from Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks, Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal, Fabien Duchene, Xavier de Foy, Rahul Jadhav, Klemens Schragel, Mirja Ford, et al. Expires December 10, 2019 [Page 63] Internet-Draft Multipath TCP June 2019 Kuehlewind, Sheng Jiang, Alissa Cooper, Ines Robles, Roman Danyliw, Adam Roach, Barry Leiba, Alexey Melnikov, Eric Vyncke, and Ben Kaduk. 8. IANA Considerations This document obsoletes RFC6824 and as such IANA is requested to update the TCP option space registry to point to this document for Multipath TCP, as follows: +------+--------+-----------------------+---------------+ | Kind | Length | Meaning | Reference | +------+--------+-----------------------+---------------+ | 30 | N | Multipath TCP (MPTCP) | This document | +------+--------+-----------------------+---------------+ Table 1: TCP Option Kind Numbers 8.1. MPTCP Option Subtypes The 4-bit MPTCP subtype sub-registry ("MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry) was defined in RFC6824. Since RFC6824 was an Experimental not Standards Track RFC, and since no further entries have occurred beyond those pointing to RFC6824, IANA is requested to replace the existing registry with Table 2 and with the following explanatory note. Note: This registry specifies the MPTCP Option Subtypes for MPTCP v1, which obsoletes the Experimental MPTCP v0. For the MPTCP v0 subtypes, please refer to RFC6824. Ford, et al. Expires December 10, 2019 [Page 64] Internet-Draft Multipath TCP June 2019 +-------+-----------------+-------------------------+---------------+ | Value | Symbol | Name | Reference | +-------+-----------------+-------------------------+---------------+ | 0x0 | MP_CAPABLE | Multipath Capable | This | | | | | document, | | | | | Section 3.1 | | 0x1 | MP_JOIN | Join Connection | This | | | | | document, | | | | | Section 3.2 | | 0x2 | DSS | Data Sequence Signal | This | | | | (Data ACK and data | document, | | | | sequence mapping) | Section 3.3 | | 0x3 | ADD_ADDR | Add Address | This | | | | | document, | | | | | Section 3.4.1 | | 0x4 | REMOVE_ADDR | Remove Address | This | | | | | document, | | | | | Section 3.4.2 | | 0x5 | MP_PRIO | Change Subflow Priority | This | | | | | document, | | | | | Section 3.3.8 | | 0x6 | MP_FAIL | Fallback | This | | | | | document, | | | | | Section 3.7 | | 0x7 | MP_FASTCLOSE | Fast Close | This | | | | | document, | | | | | Section 3.5 | | 0x8 | MP_TCPRST | Subflow Reset | This | | | | | document, | | | | | Section 3.6 | | 0xf | MP_EXPERIMENTAL | Reserved for private | | | | | experiments | | +-------+-----------------+-------------------------+---------------+ Table 2: MPTCP Option Subtypes Values 0x9 through 0xe are currently unassigned. Option 0xf is reserved for use by private experiments. Its use may be formalized in a future specification. Future assignments in this registry are to be defined by Standards Action as defined by [RFC8126]. Assignments consist of the MPTCP subtype's symbolic name and its associated value, and a reference to its specification. 8.2. MPTCP Handshake Algorithms The "MPTCP Handshake Algorithms" sub-registry under the "Transmission Control Protocol (TCP) Parameters" registry was defined in RFC6824. Since RFC6824 was an Experimental not Standards Track RFC, and since Ford, et al. Expires December 10, 2019 [Page 65] Internet-Draft Multipath TCP June 2019 no further entries have occurred beyond those pointing to RFC6824, IANA is requested to replace the existing registry with Table 3 and with the following explanatory note. Note: This registry specifies the MPTCP Handshake Algorithms for MPTCP v1, which obsoletes the Experimental MPTCP v0. For the MPTCP v0 subtypes, please refer to RFC6824. +-------+----------------------------------------+------------------+ | Flag | Meaning | Reference | | Bit | | | +-------+----------------------------------------+------------------+ | A | Checksum required | This document, | | | | Section 3.1 | | B | Extensibility | This document, | | | | Section 3.1 | | C | Do not attempt to establish new | This document, | | | subflows to the source address. | Section 3.1 | | D-G | Unassigned | | | H | HMAC-SHA256 | This document, | | | | Section 3.2 | +-------+----------------------------------------+------------------+ Table 3: MPTCP Handshake Algorithms Note that the meanings of bits D through H can be dependent upon bit B, depending on how Extensibility is defined in future specifications; see Section 3.1 for more information. Future assignments in this registry are also to be defined by Standards Action as defined by [RFC8126]. Assignments consist of the value of the flags, a symbolic name for the algorithm, and a reference to its specification. 8.3. MP_TCPRST Reason Codes IANA is requested to create a further sub-registry, "MPTCP MP_TCPRST Reason Codes" under the "Transmission Control Protocol (TCP) Parameters" registry, based on the reason code in MP_TCPRST (Section 3.6) message. Initial values for this registry are given in Table 4; future assignments are to be defined by Specification Required as defined by [RFC8126]. Assignments consist of the value of the code, a short description of its meaning, and a reference to its specification. The maximum value is 0xff. As guidance to the Designated Expert [RFC8126], assignments should not normally be refused unless codepoint space is becoming scarce, providing that there is a clear distinction from other, already- Ford, et al. Expires December 10, 2019 [Page 66] Internet-Draft Multipath TCP June 2019 existing codes, and also providing there is sufficient guidance for implementors both sending and receiving these codes. +------+-----------------------------+----------------------------+ | Code | Meaning | Reference | +------+-----------------------------+----------------------------+ | 0x00 | Unspecified TCP error | This document, Section 3.6 | | 0x01 | MPTCP specific error | This document, Section 3.6 | | 0x02 | Lack of resources | This document, Section 3.6 | | 0x03 | Administratively prohibited | This document, Section 3.6 | | 0x04 | Too much outstanding data | This document, Section 3.6 | | 0x05 | Unacceptable performance | This document, Section 3.6 | | 0x06 | Middlebox interference | This document, Section 3.6 | +------+-----------------------------+----------------------------+ Table 4: MPTCP MP_TCPRST Reason Codes 9. References 9.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [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, . [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Ford, et al. Expires December 10, 2019 [Page 67] Internet-Draft Multipath TCP June 2019 9.2. Informative References [deployments] Bonaventure, O. and S. Seo, "Multipath TCP Deployments", IETF Journal 2016, November 2016, . [howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O., and M. Handley, "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP", Usenix Symposium on Networked Systems Design and Implementation 2012, 2012, . [norm] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", Usenix Security 2001, 2001, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [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, . [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, . [RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, . [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, . Ford, et al. Expires December 10, 2019 [Page 68] Internet-Draft Multipath TCP June 2019 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011, . [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, . [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, . [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, . Ford, et al. Expires December 10, 2019 [Page 69] Internet-Draft Multipath TCP June 2019 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. Raiciu, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/RFC7430, July 2015, . [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and Operational Experience with Multipath TCP", RFC 8041, DOI 10.17487/RFC8041, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [TCPLO] Ramaiah, A., "TCP option space extension", Work in Progress, March 2012. Ford, et al. Expires December 10, 2019 [Page 70] Internet-Draft Multipath TCP June 2019 Appendix A. Notes on Use of TCP Options The TCP option space is limited due to the length of the Data Offset field in the TCP header (4 bits), which defines the TCP header length in 32-bit words. With the standard TCP header being 20 bytes, this leaves a maximum of 40 bytes for options, and many of these may already be used by options such as timestamp and SACK. We have performed a brief study on the commonly used TCP options in SYN, data, and pure ACK packets, and found that there is enough room to fit all the options we propose using in this document. SYN packets typically include Maximum Segment Size (MSS) (4 bytes), window scale (3 bytes), SACK permitted (2 bytes), and timestamp (10 bytes) options. Together these sum to 19 bytes. Some operating systems appear to pad each option up to a word boundary, thus using 24 bytes (a brief survey suggests Windows XP and Mac OS X do this, whereas Linux does not). Optimistically, therefore, we have 21 bytes spare, or 16 if it has to be word-aligned. In either case, however, the SYN versions of Multipath Capable (12 bytes) and Join (12 or 16 bytes) options will fit in this remaining space. Note that due to the use of a 64-bit data-level sequence space, it is feasible that MPTCP will not require the timestamp option for protection against wrapped sequence numbers (PAWS [RFC7323]), since the data-level sequence space has far less chance of wrapping. Confirmation of the validity of this optimisation is for further study. TCP data packets typically carry timestamp options in every packet, taking 10 bytes (or 12 with padding). That leaves 30 bytes (or 28, if word-aligned). The Data Sequence Signal (DSS) option varies in length depending on whether the data sequence mapping and DATA_ACK are included, and whether the sequence numbers in use are 4 or 8 octets. The maximum size of the DSS option is 28 bytes, so even that will fit in the available space. But unless a connection is both bidirectional and high-bandwidth, it is unlikely that all that option space will be required on each DSS option. Within the DSS option, it is not necessary to include the data sequence mapping and DATA_ACK in each packet, and in many cases it may be possible to alternate their presence (so long as the mapping covers the data being sent in the following packet). It would also be possible to alternate between 4- and 8-byte sequence numbers in each option. On subflow and connection setup, an MPTCP option is also set on the third packet (an ACK). These are 20 bytes (for Multipath Capable) Ford, et al. Expires December 10, 2019 [Page 71] Internet-Draft Multipath TCP June 2019 and 24 bytes (for Join), both of which will fit in the available option space. Pure ACKs in TCP typically contain only timestamps (10 bytes). Here, Multipath TCP typically needs to encode only the DATA_ACK (maximum of 12 bytes). Occasionally, ACKs will contain SACK information. Depending on the number of lost packets, SACK may utilize the entire option space. If a DATA_ACK had to be included, then it is probably necessary to reduce the number of SACK blocks to accommodate the DATA_ACK. However, the presence of the DATA_ACK is unlikely to be necessary in a case where SACK is in use, since until at least some of the SACK blocks have been retransmitted, the cumulative data-level ACK will not be moving forward (or if it does, due to retransmissions on another path, then that path can also be used to transmit the new DATA_ACK). The ADD_ADDR option can be between 16 and 30 bytes, depending on whether IPv4 or IPv6 is used, and whether or not the port number is present. It is unlikely that such signaling would fit in a data packet (although if there is space, it is fine to include it). It is recommended to use duplicate ACKs with no other payload or options in order to transmit these rare signals. Note this is the reason for mandating that duplicate ACKs with MPTCP options are not taken as a signal of congestion. Appendix B. TCP Fast Open and MPTCP TCP Fast Open (TFO) is an experimental TCP extension, described in [RFC7413], which has been introduced to allow sending data one RTT earlier than with regular TCP. This is considered a valuable gain as very short connections are very common, especially for HTTP request/ response schemes. It achieves this by sending the SYN-segment together with the application's data and allowing the listener to reply immediately with data after the SYN/ACK. [RFC7413] secures this mechanism, by using a new TCP option that includes a cookie which is negotiated in a preceding connection. When using TCP Fast Open in conjunction with MPTCP, there are two key points to take into account, detailed hereafter. B.1. TFO cookie request with MPTCP When a TFO initiator first connects to a listener, it cannot immediately include data in the SYN for security reasons [RFC7413]. Instead, it requests a cookie that will be used in subsequent connections. This is done with the TCP cookie request/response options, of respectively 2 bytes and 6-18 bytes (depending on the chosen cookie length). Ford, et al. Expires December 10, 2019 [Page 72] Internet-Draft Multipath TCP June 2019 TFO and MPTCP can be combined provided that the total length of all the options does not exceed the maximum 40 bytes possible in TCP: o In the SYN: MPTCP uses a 4-bytes long MP_CAPABLE option. The MPTCP and TFO options sum up to 6 bytes. With typical TCP-options using up to 19 bytes in the SYN (24 bytes if options are padded at a word boundary), there is enough space to combine the MP_CAPABLE with the TFO Cookie Request. o In the SYN+ACK: MPTCP uses a 12-bytes long MP_CAPABLE option, but now TFO can be as long as 18 bytes. Since the maximum option length may be exceeded, it is up to the listener to solve this by using a shorter cookie. As an example, if we consider that 19 bytes are used for classical TCP options, the maximum possible cookie length would be of 7 bytes. Note that the same limitation applies to subsequent connections, for the SYN packet (because the initiator then echoes back the cookie to the listener). Finally, if the security impact of reducing the cookie size is not deemed acceptable, the listener can reduce the amount of other TCP- options by omitting the TCP timestamps (as outlined in Appendix A). B.2. Data sequence mapping under TFO MPTCP uses, in the TCP establishment phase, a key exchange that is used to generate the Initial Data Sequence Numbers (IDSNs). In particular, the SYN with MP_CAPABLE occupies the first octet of the data sequence space. With TFO, one way to handle the data sent together with the SYN would be to consider an implicit DSS mapping that covers that SYN segment (since there is not enough space in the SYN to include a DSS option). The problem with that approach is that if a middlebox modifies the TFO data, this will not be noticed by MPTCP because of the absence of a DSS-checksum. For example, a TCP (but not MPTCP)-aware middlebox could insert bytes at the beginning of the stream and adapt the TCP checksum and sequence numbers accordingly. With an implicit mapping, this would give to initiator and listener a different view on the DSS-mapping, with no way to detect this inconsistency as the DSS checksum is not present. To solve this, the TFO data must not be considered part of the Data Sequence Number space: the SYN with MP_CAPABLE still occupies the first octet of data sequence space, but then the first non-TFO data byte occupies the second octet. This guarantees that, if the use of DSS-checksum is negotiated, all data in the data sequence number space is checksummed. We also note that this does not entail a loss of functionality, because TFO-data is always only sent on the initial subflow before any attempt to create additional subflows. Ford, et al. Expires December 10, 2019 [Page 73] Internet-Draft Multipath TCP June 2019 B.3. Connection establishment examples The following shows a few examples of possible TFO+MPTCP establishment scenarios. Before an initiator can send data together with the SYN, it must request a cookie to the listener, as shown in Figure 18. This is done by simply combining the TFO and MPTCP options. initiator listener | | | S Seq=0(Length=0) , | | -----------------------------------------------------------> | | | | S. 0(0) ack 1 , | | <----------------------------------------------------------- | | | | . 0(0) ack 1 | | -----------------------------------------------------------> | | | Figure 18: Cookie request - sequence number and length are annotated as Seq(Length) and used hereafter in the figures. Once this is done, the received cookie can be used for TFO, as shown in Figure 19. In this example, the initiator first sends 20 bytes in the SYN. The listener immediately replies with 100 bytes following the SYN-ACK upon which the initiator replies with 20 more bytes. Note that the last segment in the figure has a TCP sequence number of 21, while the DSS subflow sequence number is 1 (because the TFO data is not part of the data sequence number space, as explained in Section Appendix B.2. Ford, et al. Expires December 10, 2019 [Page 74] Internet-Draft Multipath TCP June 2019 initiator listener | | | S 0(20) , | | -----------------------------------------------------------> | | | | S. 0(0) ack 21 | | <----------------------------------------------------------- | | | | . 1(100) ack 21 | | <----------------------------------------------------------- | | | | . 21(0) ack 1 | | -----------------------------------------------------------> | | | | . 21(20) ack 101 | | -----------------------------------------------------------> | | | Figure 19: The listener supports TFO In Figure 20, the listener does not support TFO. The initiator detects that no state is created in the listener (as no data is acked), and now sends the MP_CAPABLE in the third ack, in order for the listener to build its MPTCP context at then end of the establishment. Now, the tfo data, retransmitted, becomes part of the data sequence mapping because it is effectively sent (in fact re- sent) after the establishment. initiator listener | | | S 0(20) , | | -----------------------------------------------------------> | | | | S. 0(0) ack 1 | | <----------------------------------------------------------- | | | | . 1(0) ack 1 | | -----------------------------------------------------------> | | | | . 1(20) ack 1 | | -----------------------------------------------------------> | | | | . 0(0) ack 21 | | <----------------------------------------------------------- | | | Figure 20: The listener does not support TFO Ford, et al. Expires December 10, 2019 [Page 75] Internet-Draft Multipath TCP June 2019 It is also possible that the listener acknowledges only part of the TFO data, as illustrated in Figure 21. The initiator will simply retransmit the missing data together with a DSS-mapping. initiator listener | | | S 0(1000) , | | -----------------------------------------------------------> | | | | S. 0(0) ack 501 | | <----------------------------------------------------------- | | | | . 501(0) ack 1 | | -----------------------------------------------------------> | | | | . 501(500) ack 1 | | -----------------------------------------------------------> | | | Figure 21: Partial data acknowledgement Appendix C. Control Blocks Conceptually, an MPTCP connection can be represented as an MPTCP protocol control block (PCB) that contains several variables that track the progress and the state of the MPTCP connection and a set of linked TCP control blocks that correspond to the subflows that have been established. RFC 793 [RFC0793] specifies several state variables. Whenever possible, we reuse the same terminology as RFC 793 to describe the state variables that are maintained by MPTCP. C.1. MPTCP Control Block The MPTCP control block contains the following variable per connection. C.1.1. Authentication and Metadata Local.Token (32 bits): This is the token chosen by the local host on this MPTCP connection. The token must be unique among all established MPTCP connections, and is generated from the local key. Local.Key (64 bits): This is the key sent by the local host on this MPTCP connection. Ford, et al. Expires December 10, 2019 [Page 76] Internet-Draft Multipath TCP June 2019 Remote.Token (32 bits): This is the token chosen by the remote host on this MPTCP connection, generated from the remote key. Remote.Key (64 bits): This is the key chosen by the remote host on this MPTCP connection MPTCP.Checksum (flag): This flag is set to true if at least one of the hosts has set the A bit in the MP_CAPABLE options exchanged during connection establishment, and is set to false otherwise. If this flag is set, the checksum must be computed in all DSS options. C.1.2. Sending Side SND.UNA (64 bits): This is the data sequence number of the next byte to be acknowledged, at the MPTCP connection level. This variable is updated upon reception of a DSS option containing a DATA_ACK. SND.NXT (64 bits): This is the data sequence number of the next byte to be sent. SND.NXT is used to determine the value of the DSN in the DSS option. SND.WND (32 bits with RFC 7323, 16 bits otherwise): This is the sending window. MPTCP maintains the sending window at the MPTCP connection level and the same window is shared by all subflows. All subflows use the MPTCP connection level SND.WND to compute the SEQ.WND value that is sent in each transmitted segment. C.1.3. Receiving Side RCV.NXT (64 bits): This is the data sequence number of the next byte that is expected on the MPTCP connection. This state variable is modified upon reception of in-order data. The value of RCV.NXT is used to specify the DATA_ACK that is sent in the DSS option on all subflows. RCV.WND (32 bits with RFC 7323, 16 bits otherwise): This is the connection-level receive window, which is the maximum of the RCV.WND on all the subflows. C.2. TCP Control Blocks The MPTCP control block also contains a list of the TCP control blocks that are associated with the MPTCP connection. Note that the TCP control block on the TCP subflows does not contain the RCV.WND and SND.WND state variables as these are maintained at the MPTCP connection level and not at the subflow level. Ford, et al. Expires December 10, 2019 [Page 77] Internet-Draft Multipath TCP June 2019 Inside each TCP control block, the following state variables are defined. C.2.1. Sending Side SND.UNA (32 bits): This is the sequence number of the next byte to be acknowledged on the subflow. This variable is updated upon reception of each TCP acknowledgment on the subflow. SND.NXT (32 bits): This is the sequence number of the next byte to be sent on the subflow. SND.NXT is used to set the value of SEG.SEQ upon transmission of the next segment. C.2.2. Receiving Side RCV.NXT (32 bits): This is the sequence number of the next byte that is expected on the subflow. This state variable is modified upon reception of in-order segments. The value of RCV.NXT is copied to the SEG.ACK field of the next segments transmitted on the subflow. RCV.WND (32 bits with RFC 7323, 16 bits otherwise): This is the subflow-level receive window that is updated with the window field from the segments received on this subflow. Appendix D. Finite State Machine The diagram in Figure 22 shows the Finite State Machine for connection-level closure. This illustrates how the DATA_FIN connection-level signal (indicated in the diagram as the DFIN flag on a DATA_ACK) interacts with subflow-level FINs, and permits "break- before-make" handover between subflows. Ford, et al. Expires December 10, 2019 [Page 78] Internet-Draft Multipath TCP June 2019 +---------+ | M_ESTAB | +---------+ M_CLOSE | | rcv DATA_FIN ------- | | ------- +---------+ snd DATA_FIN / \ snd DATA_ACK[DFIN] +---------+ | M_FIN |<----------------- ------------------->| M_CLOSE | | WAIT-1 |--------------------------- | WAIT | +---------+ rcv DATA_FIN \ +---------+ | rcv DATA_ACK[DFIN] ------- | M_CLOSE | | -------------- snd DATA_ACK | ------- | | CLOSE all subflows | snd DATA_FIN | V V V +-----------+ +-----------+ +-----------+ |M_FINWAIT-2| | M_CLOSING | | M_LAST-ACK| +-----------+ +-----------+ +-----------+ | rcv DATA_ACK[DFIN] | rcv DATA_ACK[DFIN] | | rcv DATA_FIN -------------- | -------------- | | ------- CLOSE all subflows | CLOSE all subflows | | snd DATA_ACK[DFIN] V delete MPTCP PCB V \ +-----------+ +---------+ ------------------------>|M_TIME WAIT|----------------->| M_CLOSED| +-----------+ +---------+ All subflows in CLOSED ------------ delete MPTCP PCB Figure 22: Finite State Machine for Connection Closure Appendix E. Changes from RFC6824 This section lists the key technical changes between RFC6824, specifying MPTCP v0, and this document, which obsoletes RFC6824 and specifies MPTCP v1. Note that this specification is not backwards compatible with RFC6824. o The document incorporates lessons learnt from the various implementations, deployments and experiments gathered in the documents "Use Cases and Operational Experience with Multipath TCP" [RFC8041] and the IETF Journal article "Multipath TCP Deployments" [deployments]. o Connection initiation, through the exchange of the MP_CAPABLE MPTCP option, is different from RFC6824. The SYN no longer includes the initiator's key, allowing the MP_CAPABLE option on the SYN to be shorter in length, and to avoid duplicating the sending of keying material. Ford, et al. Expires December 10, 2019 [Page 79] Internet-Draft Multipath TCP June 2019 o This also ensures reliable delivery of the key on the MP_CAPABLE option by allowing its transmission to be combined with data and thus using TCP's in-built reliability mechanism. If the initiator does not immediately have data to send, the MP_CAPABLE option with the keys will be repeated on the first data packet. If the other end is first to send, then the presence of the DSS option implicitly confirms the receipt of the MP_CAPABLE. o In the Flags field of MP_CAPABLE, C is now assigned to mean that the sender of this option will not accept additional MPTCP subflows to the source address and port. This is an efficiency improvement, for example where the sender is behind a strict NAT. o In the Flags field of MP_CAPABLE, H now indicates the use of HMAC- SHA256 (rather than HMAC-SHA1). o Connection initiation also defines the procedure for version negotiation, for implementations that support both v0 (RFC6824) and v1 (this document). o The HMAC-SHA256 (rather than HMAC-SHA1) algorithm is used, as the algorithm provides better security. It is used to generate the token in the MP_JOIN and ADD_ADDR messages, and to set the initial data sequence number. o A new subflow-level option exists to signal reasons for sending a RST on a subflow (MP_TCPRST Section 3.6), which can help an implementation decide whether to attempt later re-connection. o The MP_PRIO option (Section 3.3.8), which is used to signal a change of priority for a subflow, no longer includes the AddrID field. Its purpose was to allow the changed priority to be applied on a subflow other than the one it was sent on. However, it has been realised that this could be used by a man-in-the- middle to divert all traffic on to its own path, and MP_PRIO does not include a token or other security mechanism. o The ADD_ADDR option (Section 3.4.1), which is used to inform the other host about another potential address, is different in several ways. It now includes an HMAC of the added address, for enhanced security. In addition, reliability for the ADD_ADDR option has been added: the IPVer field is replaced with a flag field, and one flag is assigned (E) which is used as an 'Echo' so a host can indicate that it has received the option. o An additional way of performing a Fast Close is described, by sending a MP_FASTCLOSE option on a RST on all subflows. This Ford, et al. Expires December 10, 2019 [Page 80] Internet-Draft Multipath TCP June 2019 allows the host to tear down the subflows and the connection immediately. o In the IANA registry a new MPTCP subtype option, MP_EXPERIMENTAL, is reserved for private experiments. However, the document doesn't define how to use the subtype option. o A new Appendix discusses the usage of both the MPTCP and TCP Fast Open on the same packet (Appendix B). Authors' Addresses Alan Ford Pexip EMail: alan.ford@gmail.com Costin Raiciu University Politehnica of Bucharest Splaiul Independentei 313 Bucharest Romania EMail: costin.raiciu@cs.pub.ro Mark Handley University College London Gower Street London WC1E 6BT UK EMail: m.handley@cs.ucl.ac.uk Olivier Bonaventure Universite catholique de Louvain Pl. Ste Barbe, 2 Louvain-la-Neuve 1348 Belgium EMail: olivier.bonaventure@uclouvain.be Ford, et al. Expires December 10, 2019 [Page 81] Internet-Draft Multipath TCP June 2019 Christoph Paasch Apple, Inc. Cupertino US EMail: cpaasch@apple.com Ford, et al. Expires December 10, 2019 [Page 82] ./draft-ietf-pce-lsp-control-request-11.txt0000644000764400076440000006174613550613335020103 0ustar iustyiusty PCE Working Group A. Raghuram Internet-Draft A. Goddard Intended status: Standards Track AT&T Expires: April 15, 2020 J. Karthik S. Sivabalan Cisco Systems, Inc. M. Negi Huawei Technologies October 13, 2019 Ability for a Stateful Path Computation Element (PCE) to request and obtain control of a Label Switched Path (LSP) draft-ietf-pce-lsp-control-request-11 Abstract A Stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A Path Computation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE. There are use-cases in which a stateful PCE may wish to obtain control of locally configured LSPs of which it is aware but that have not been delegated to the PCE. This document describes an extension to the Path Computation Element communication Protocol (PCEP) to enable a PCE to make requests for such control. 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 https://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." Raghuram, et al. Expires April 15, 2020 [Page 1] Internet-Draft LSP Control Request October 2019 This Internet-Draft will expire on April 15, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. LSP Control Request Flag . . . . . . . . . . . . . . . . . . 4 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.1. SRP Object Flags . . . . . . . . . . . . . . . . . . . . 8 8. Manageability Considerations . . . . . . . . . . . . . . . . 8 8.1. Control of Function and Policy . . . . . . . . . . . . . 8 8.2. Information and Data Models . . . . . . . . . . . . . . . 8 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 8 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 8 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 8.6. Impact On Network Operations . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Stateful Path Computation Element (PCE) communication Protocol (PCEP) extensions [RFC8231] specifies a set of extensions to PCEP [RFC5440] to enable stateful control of Traffic Engineering Label Switched Raghuram, et al. Expires April 15, 2020 [Page 2] Internet-Draft LSP Control Request October 2019 Paths (TE LSPs) between and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to synchronize LSP state between Path Computation Clients (PCCs) and PCEs, delegate control of LSPs to PCE, and PCE-control of timing and sequence of path computations within and across PCEP sessions. The stateful PCEP defines the following two useful network operations: o Delegation: As per [RFC8051], an operation to grant a PCE temporary rights to modify a subset of LSP parameters on one or more LSPs of a PCC. LSPs are delegated from a PCC to a PCE and are referred to as "delegated" LSPs. o Revocation: As per [RFC8231], an operation performed by a PCC on a previously delegated LSP. Revocation revokes the rights granted to the PCE in the delegation operation. For Redundant Stateful PCEs (section 5.7.4. of [RFC8231]), during a PCE failure, one of the redundant PCE might want to request to take control over an LSP. The redundant PCEs may use a local policy or a proprietary election mechanism to decide which PCE would take control. In this case, a mechanism is needed for a stateful PCE to request control of one or more LSPs from a PCC, so that a newly elected primary PCE can request to take over control. In case of virtualized PCEs (vPCEs) running in virtual network function (VNF) mode, as the computation load in the network increases, a new instance of vPCE could be instantiated to balance the current load. The PCEs could use a proprietary algorithm to decide which LSPs to be assigned to the new vPCE. Thus, having a mechanism for the PCE to request control of some LSPs is needed. In some deployments, the operator would like to use stateful PCE for global optimization algorithms but would still like to keep the control of the LSP at the PCC. In such cases, a stateful PCE could request to take control during the global optimization and return the delegation once done. Note that [RFC8231] specifies a mechanism for a PCC to delegate an orphaned LSP to another PCE. The mechanism defined in this document can be used in conjunction to [RFC8231]. Ultimately, it is the PCC that decides which PCE to delegate the orphaned LSP to. This specification provides a simple extension: by using it a PCE can request control of one or more LSPs from any PCC over the stateful PCEP session. The procedures for granting and relinquishing control of the LSPs are specified in accordance with the specification [RFC8231] unless explicitly set aside in this document. Raghuram, et al. Expires April 15, 2020 [Page 3] Internet-Draft LSP Control Request October 2019 2. Terminology This document uses the following terms defined in [RFC5440]: PCC: Path Computation Client. PCE: Path Computation Element. PCEP: Path Computation Element communication Protocol. This document uses the following terms defined in [RFC8231]: PCRpt: Path Computation State Report message. PCUpd: Path Computation Update Request message. PLSP-ID: A PCEP-specific identifier for the LSP. SRP: Stateful PCE Request Parameters. Readers of this document are expected to have some familiarity with [RFC8231]. 2.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. LSP Control Request Flag The Stateful PCE Request Parameters (SRP) object is defined in Section 7.2 of [RFC8231] and it includes a Flags field. A new flag, the "LSP-Control Request Flag" (C) - TBD, is introduced in the SRP object. On a PCUpd message, a PCE sets the C Flag to 1 to indicate that it wishes to gain control of LSPs. The LSPs are identified by the PLSP-ID in the LSP object following the SRP object. A PLSP-ID of value other than 0 and 0xFFFFF is used to identify the LSP for which the PCE requests control. The PLSP-ID value of 0 indicates that the PCE is requesting control of all LSPs originating from the PCC that it wishes to delegate. The C Flag has no meaning in other PCEP messages that carry SRP objects and for which the C flag MUST be set to 0 on transmission and MUST be ignored on receipt. Raghuram, et al. Expires April 15, 2020 [Page 4] Internet-Draft LSP Control Request October 2019 4. Operation During normal operation, a PCC that wishes to delegate the control of an LSP sets the D Flag (delegate, Section 7.3 of [RFC8231]) to 1 in all PCRpt messages pertaining to the LSP. The PCE confirms the delegation by setting D Flag to 1 in all PCUpd messages pertaining to the LSP. The PCC revokes the control of the LSP from the PCE by setting D Flag to 0 in PCRpt messages pertaining to the LSP. If the PCE wishes to relinquish the control of the LSP, it sets D Flag to 0 in all PCUpd messages pertaining to the LSP. If a PCE wishes to gain control over an LSP, it sends a PCUpd message with C Flag set to 1 in SRP object. The LSP for which the PCE requests control is identified by the PLSP-ID in the associated LSP object. The PLSP-ID of 0 indicates that the PCE wants control over all LSPs originating from the PCC. An implementation of this feature needs to make sure to check for the LSP control feature (C flag set to 1) before any check for PLSP-ID (as prescribed in [RFC8231]). The D Flag and C Flag are mutually exclusive in a PCUpd message. The PCE MUST NOT send a control request for the LSP which is already delegated to the PCE, i.e. if the D Flag is set in the PCUpd message, then the C Flag MUST NOT be set. If a PCC receives a PCUpd message with D Flag set in the LSP object (i.e. LSP is already delegated) and the C Flag is also set (i.e. PCE is making a control request), the PCC MUST ignore the C Flag. A PCC can decide to delegate the control of the LSP at its own discretion. If the PCC grants or denies the control, it sends a PCRpt message with D Flag set to 1 and 0 respectively in accordance with stateful PCEP [RFC8231]. If the PCC does not grant the control, it MAY choose to not respond, and the PCE MAY choose to retry requesting the control preferably using exponentially increasing timer. Note that, if the PCUpd message with C Flag set is received for a currently non-delegated LSP (for which the PCE is requesting delegation), this MUST NOT trigger the error handling as specified in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP)). As per [RFC8231], a PCC cannot delegate an LSP to more than one PCE at any time. If a PCE requests control of an LSP that has already been delegated by the PCC to another PCE, the PCC MAY ignore the request, or MAY revoke the delegation to the first PCE before delegating it to the second. This choice is a matter of local policy. It should be noted that a legacy implementation of PCC that does not support this extension would receive an LSP control request: PCUpd message with C flag set and D flag (delegate) unset, it would ignore the C flag and trigger the error condition for the D flag as Raghuram, et al. Expires April 15, 2020 [Page 5] Internet-Draft LSP Control Request October 2019 specified in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non- delegated LSP)). Further, in case of PLSP-ID of 0, the error condition as specified in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and error-value 3 (Attempted LSP Update Request for an LSP identified by an unknown PSP-ID)) would be triggered. [RFC8281] describes the setup, maintenance and teardown of PCE- initiated LSPs under the stateful PCE model. It also specifies how a PCE may obtain control over an orphaned LSP that was PCE-initiated. A PCE implementation can apply the mechanism described in this document in conjunction with those in [RFC8281]. 5. Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.] 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. It is up to the individual working groups to use this information as they see fit". 5.1. Huawei's Proof of Concept based on ONOS The PCE function was developed in the ONOS open source platform. This extension was implemented on a private version as a proof of concept to enable multi-instance support. o Organization: Huawei o Implementation: Huawei's PoC based on ONOS Raghuram, et al. Expires April 15, 2020 [Page 6] Internet-Draft LSP Control Request October 2019 o Description: PCEP as a southbound plugin was added to ONOS. To support multi-instance ONOS deployment in a cluster, this extension in PCEP is used. Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol o Maturity Level: Prototype o Coverage: Full o Contact: satishk@huawei.com 6. Security Considerations The security considerations listed in [RFC8231] and [RFC8281] apply to this document as well. However, this document also introduces a new attack vector. An attacker may flood the PCC with request to delegate all of its LSPs at a rate which exceeds the PCC's ability to process them, either by spoofing messages or by compromising the PCE itself. The PCC SHOULD be configured with a threshold rate for the delegation requests received from the PCE. If the threshold is reached, it is RECOMMENDED to log the issue. A PCC is the ultimate arbiter of delegation. As per [RFC8231], a local policy at PCC is used to influence the delegation. A PCC can also revoke the delegation at any time. A PCC need not blindly trust the control requests and SHOULD take local policy and other factors into consideration before honoring the request. Note that, a PCE may not be sure if a PCC supports this feature. A PCE would try sending a control request to a 'legacy' PCC, which would in turn respond with an error as described in Section 4. So a PCE would learn this fact only when it wants to take control over an LSP. A PCE might also be susceptible to a downgrade attacks by falsifying the error condition. As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in BCP 195 [RFC7525] (unless explicitly excluded in [RFC8253]). 7. IANA Considerations Raghuram, et al. Expires April 15, 2020 [Page 7] Internet-Draft LSP Control Request October 2019 7.1. SRP Object Flags IANA maintains a registry called the "Path Computation Element Protocol (PCEP) Numbers" registry. It contains a subregistry called the "SRP Object Flag Field" registry. This document requests IANA to allocate following code point in the "SRP Object Flag Field" subregistry. Bit Description Reference TBD LSP-Control Request Flag This document 8. Manageability Considerations All manageability requirements and considerations listed in [RFC5440] and [RFC8231] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply. 8.1. Control of Function and Policy A PCC implementation SHOULD allow the operator to configure the policy based on which it honors the request to control the LSPs. This includes the handling of the case where an LSP control request is received for an LSP that is currently delegated to some other PCE. A PCC implementation SHOULD also allow the operator to configure the threshold rate based on which it accepts the delegation requests from the PCE. Further, the operator MAY be allowed to trigger the LSP control request for a particular LSP at the PCE. A PCE implementation SHOULD also allow the operator to configure an exponentially increasing timer to retry the control requests for which the PCE did not get a response. 8.2. Information and Data Models The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to include mechanism to trigger the LSP control request. 8.3. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 8.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [RFC8231]. Raghuram, et al. Expires April 15, 2020 [Page 8] Internet-Draft LSP Control Request October 2019 8.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. 8.6. Impact On Network Operations Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document. Further, the mechanism described in this document can help the operator to request control of the LSPs at a particular PCE. 9. Acknowledgements Thanks to Jonathan Hardwick to remind the authors to not use suggested values in IANA section. Thanks to Adrian Farrel, Haomian Zheng and Tomonori Takeda for their valuable comments. Thanks to Shawn M. Emery for security directorate's review. Thanks to Francesca Palombini for GENART review. Thanks to Benjamin Kaduk, Martin Vigoureux, Alvaro Retana, and Barry Leiba for IESG reviews. 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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Raghuram, et al. Expires April 15, 2020 [Page 9] Internet-Draft LSP Control Request October 2019 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . 10.2. Informative References [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . [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, . [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, . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep- yang-12 (work in progress), July 2019. Raghuram, et al. Expires April 15, 2020 [Page 10] Internet-Draft LSP Control Request October 2019 Appendix A. Contributor Addresses Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Jon Parker Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada EMail: jdparker@cisco.com Chaitanya Yadlapalli AT&T 200 S Laurel Aevenue Middletown NJ 07748 USA EMail: cy098d@att.com Authors' Addresses Aswatnarayan Raghuram AT&T 200 S Laurel Aevenue Middletown, NJ 07748 USA EMail: ar2521@att.com Al Goddard AT&T 200 S Laurel Aevenue Middletown, NJ 07748 USA EMail: ag6941@att.com Raghuram, et al. Expires April 15, 2020 [Page 11] Internet-Draft LSP Control Request October 2019 Jay Karthik Cisco Systems, Inc. 125 High Street Boston, Massachusetts 02110 USA EMail: jakarthi@cisco.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada EMail: msiva@cisco.com Mahendra Singh Negi Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: mahend.ietf@gmail.com Raghuram, et al. Expires April 15, 2020 [Page 12] ./draft-ietf-mtgvenue-iaoc-venue-selection-process-16.txt0000644000764400076440000007017313310472052022706 0ustar iustyiusty mtgvenue E. Lear, Ed. Internet-Draft Cisco Systems Intended status: Best Current Practice June 14, 2018 Expires: December 16, 2018 IETF Plenary Meeting Venue Selection Process draft-ietf-mtgvenue-iaoc-venue-selection-process-16 Abstract The IASA has responsibility for arranging IETF plenary meeting Venue selection and operation. This memo specifies IETF community requirements for meeting venues, including hotels and meeting room space. It directs the IASA to make available additional process documents that describe the current meeting selection 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 https://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 16, 2018. Copyright Notice Copyright (c) 2018 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 (https://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. Lear Expires December 16, 2018 [Page 1] Internet-Draft Venue Selection June 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Venue Selection Objectives . . . . . . . . . . . . . . . . . 3 2.1. Core Values . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Venue Selection Non-Objectives . . . . . . . . . . . . . 5 3. Meeting Criteria . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Mandatory Criteria . . . . . . . . . . . . . . . . . . . 5 3.2. Important Criteria . . . . . . . . . . . . . . . . . . . 6 3.3. Other Consideraitons . . . . . . . . . . . . . . . . . . 9 4. Documentation Requirements . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Internet Administrative Support Activity (IASA) has responsibility for arranging IETF plenary meeting venue selection and operation. The purpose of this document is to guide the IASA in their selection of regions, cities, facilities, and hotels. The IASA applies this guidance at different points in the process in an attempt to faithfully meet the requirements of the IETF community. We specify a set of general criteria for venue selection and several requirements for transparency and community consultation. It remains the responsibility of the IASA to apply their best judgment. The IASA accepts input and feedback both during the consultation process and later (for instance when there are changes in the situation at a chosen location). Any appeals remain subject to the provisions of BCP101 [RFC4071]. As always, the community is encouraged to provide direct feedback to the Nominations Committee (NOMCOM), Internet Engineering Steering Group (IESG), and IAB regarding the discharge of the IASA's performance. Four terms describe the places for which the IETF contracts services: Venue: This is an umbrella term for the city, meeting resources and guest room resources. Lear Expires December 16, 2018 [Page 2] Internet-Draft Venue Selection June 2018 Facility: The building that houses meeting rooms and associated resources. It may also house an IETF Hotel. IETF Hotels: One or more hotels, in close proximity to the Facility, where the IETF guest room block allocations are negotiated and where network services managed by the IASA (e.g., the "IETF" SSID) are in use. Overflow Hotels: One or more hotels, usually in close proximity to the Facility, where the IETF has negotiated a group rate for the purposes of the meeting. Of particular note is that Overflow Hotels usually are not connected to the IETF network and do not use network services managed by the IASA. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Venue Selection Objectives 2.1. Core Values Some IETF values pervade the selection process. These often are applicable to multiple requirements listed in this document. They are not limited to the following, but at minimum include: Why we meet? We meet to pursue the IETF's mission [RFC3935], partly by advancing the development of Internet-Drafts and RFCs. We also seek to facilitate attendee participation in multiple topics and to enable cross-pollination of ideas and technologies. Inclusiveness: We would like to facilitate the onsite or remote participation of anyone who wants to be involved. Widespread participation contributes to the diversity of perspectives represented in the working sessions Every country has limits on who it will permit within its borders. However the IETF seeks to: 1. Minimize situations in which onerous entry regulations inhibit, discourage, or prevent participants from attending meetings, or failing that to distribute meeting locations such Lear Expires December 16, 2018 [Page 3] Internet-Draft Venue Selection June 2018 that onerous entry regulations are not always experienced by the same attendees; and 2. Avoid meeting in countries with laws that effectively exclude people on the basis of race, ethnicity, religion, gender, sexual orientation, national origin, citizenship, or gender identity. Where we meet: We meet in different locations globally, in order to spread the difficulty and cost of travel among active participants, balancing travel time and expense across the regions in which participants are based. Our regional location policy is articulated in [I-D.ietf-mtgvenue-meeting-policy]. Internet Access: As an organization, we write specifications for the Internet, and we use it heavily. Meeting attendees need unfiltered access to the general Internet and their corporate networks. "Unfiltered access" in this case means that all forms of communication are allowed. This includes, but is not limited to, access to corporate networks via encrypted VPNs from the meeting Facility and Hotels, including Overflow Hotels. We also need open network access available at high enough data rates, at the meeting Facility, to support our work, including the support of remote participation. Beyond this, we are the first users of our own technology. Any filtering may cause a problem with that technology development. In some cases, local laws may require some filtering. We seek to avoid such locales without reducing the pool of cities to an unacceptable level by stating a number of criteria below, one mandatory and others important, to allow for the case where local laws may require filtering in some circumstances. Focus: We meet to have focused technical discussions. These are not limited to scheduled breakout sessions, although of course those are important. They also happen over meals or drinks, a specific type of non-session that we call a "Bar BOF", or in side meetings. Environments that are noisy or distracting prevent that or reduce its effectiveness, and are therefore less desirable as a meeting Facility.[RFC6771] Economics: Meeting attendees participate as individuals. While many are underwritten by employers or sponsors, many are self-funded. In order to reduce participation costs and travel effort, we therefore seek locations that provide convenient budget Lear Expires December 16, 2018 [Page 4] Internet-Draft Venue Selection June 2018 alternatives for food and lodging, and which minimize travel segments from major airports to the Venue. Within reason, budget should not be a barrier to accommodation. Least Astonishment and Openness: Regular participants should not be surprised by meeting Venue selections, particularly when it comes to locales. To avoid surprise, the venue selection process, as with all other IETF processes, should be as open as practicable. It should be possible for the community to engage early to express its views on prospective selections, so that the community and the IASA can exchange views as to appropriateness long before a venue contract is considered. 2.2. Venue Selection Non-Objectives IETF meeting Venues are not selected or declined with the explicit purposes of: Politics: Endorsing or condemning particular countries, political paradigms, laws, regulations, or policies. Maximal attendance: While the IETF strives to be as inclusive as possible both online and in person, maximal meeting attendance in and of itself is not a goal. It would defeat a key goal of meeting if active contributors with differing points of view did not have the opportunity to resolve their disagreements, no matter how full the rooms. Tourism: Variety in site-seeing experiences. 3. Meeting Criteria This section contains the criteria for IETF meetings. It is broken down into three subsections: mandatory criteria, important criteria, and other considerations, each as explained below. 3.1. Mandatory Criteria If criteria in this subsection cannot be met, a particular location is unacceptable for selection, and the IASA MUST NOT enter into a contract. Should the IASA learn that a location no longer can meet a mandatory requirement after having entered into a contract, it will inform the community and address the matter on a case by case basis. Lear Expires December 16, 2018 [Page 5] Internet-Draft Venue Selection June 2018 o The Facility MUST provide sufficient space in an appropriate layout to accommodate the expected number of participants, leadership, and support staff to attend that meeting. o The Facility and IETF Hotels MUST provide wheelchair access to accommodate the number of people who are anticipated to require it. o It MUST be possible to provision Internet Access to the Facility and IETF Hotels that allows those attending in person to utilize the Internet for all their IETF, business, and day to day needs; as well as sufficient bandwidth and access for remote attendees. This includes, but is not limited to, native and unmodified IPv4 and IPv6 connectivity, global reachability, and no additional limitation that would materially impact their Internet use. To ensure availability, it MUST be possible to provision redundant paths to the Internet. 3.2. Important Criteria The criteria in this subsection are not mandatory, but are still highly significant. It may be necessary to trade one or more of these criteria off against others. A Venue that meets more of these criteria is on the whole preferable than another that meets fewer of these criteria. Requirements classed as Important can also be balanced across Venue selections for multiple meetings. When a particular requirement in this section cannot be met, the IASA MUST notify the community at the time of the venue announcement. Furthermore, it may be appropriate for the IASA to assist those who, as a result, have been inconvenienced in some way. 3.2.1. Venue City Criteria o Travel to the Venue is acceptable based on cost, time, and burden for participants traveling from multiple regions. It is anticipated that the burden borne will be generally shared over the course of multiple years. o The Venue is assessed as favorable for obtaining a host and sponsors. That is, the Meeting is in a location that it is possible and probable to find a host and sponsors. o Travel barriers to entry, including visa requirements, are likely to be such that an overwhelming majority of participants who wish to do so can attend. The term "travel barriers" is to be read broadly by the IASA in the context of whether a successful meeting can be had. Lear Expires December 16, 2018 [Page 6] Internet-Draft Venue Selection June 2018 o Economic, safety, and health risks associated with this Venue are acceptable. o The selection of the venue comports with [I-D.ietf-mtgvenue-meeting-policy]. 3.2.2. Basic Venue Criteria The following requirements relate to the Venue and Facilities. The IETF operates internationally and adjusts to local requirements. Facilities selected for IETF Meetings SHALL have provided written assurance that they are in compliance with local health, safety and accessibility laws and regulations, and will remain in compliance throughout our stay. In addition: o There are sufficient places (e.g., a mix of hallways, bars, meeting rooms, and restaurants) for people to hold ad hoc conversations and group discussions in the combination of spaces offered by the facilities, hotels and bars/restaurants in the surrounding area, within walking distance (5-10 minutes). o The cost of guest rooms, meeting space, meeting food and beverage is affordable, within the norms of business travel. o The Facility is accessible or reasonable accommodations can be made to allow access by people with disabilities. 3.2.3. Technical Meeting Needs The following criteria relate to technical meeting needs. o The Facility's support technologies and services -- network, audio-video, etc. -- are sufficient for the anticipated activities at the meeting, or the Facility is willing to add such infrastructure or these support technologies and services might be provided by a third party, all at no -- or at an acceptable -- cost to the IETF. o The IETF Hotel(s) directly provide, or else permit and facilitate, the delivery of a high performance, robust, unfiltered and unmodified Internet service for the public areas and guest rooms, and that this service be included in the cost of the room. Lear Expires December 16, 2018 [Page 7] Internet-Draft Venue Selection June 2018 3.2.4. Hotel Needs The following criteria relate to IETF Hotels. o The IETF Hotel(s) are within close proximity to each other and the Facility. o The guest rooms at the IETF Hotel(s) are sufficient in number to house 1/3 or more of projected meeting attendees. o Overflow Hotels can be placed under contract, within convenient travel time to and from the Facility and at a variety of guest room rates. o The Facility environs include budget hotels within convenient travel time, cost, and effort. o The IETF Hotel(s) are accessible by people with disabilities. While we mandate wheelchair accessibility, other forms are important, and should be provided to the extent possible, based on anticipated needs of the community. o At least one IETF Hotel or the Facility has a space for use as a lounge, conducive to planned and ad hoc meetings and chatting, as well as working online. There are tables with seating, convenient for small meetings with laptops. These can be at an open bar or casual restaurant. Preferably the lounge area is centrally located, permitting easy access to participants. 3.2.5. Food and Beverage The following criteria relate to food and beverage. o The Facility environs, which includes both onsite, as well as areas within a reasonable walking distance or conveniently accessible by a short taxi ride or by local public transportation, have convenient and inexpensive choices for meals that can accommodate a wide range of dietary requirements. o A range of attendee's health-related and religion-related dietary requirements can be satisfied with robust and flexible onsite service or through access to an adequate grocery. o The Facility environs include grocery shopping that will accommodate a wide range of dietary requirements, within a reasonable walking distance, or conveniently accessible by a short taxi, bus, or subway ride, from the Facility and IETF Hotels. Lear Expires December 16, 2018 [Page 8] Internet-Draft Venue Selection June 2018 3.3. Other Consideraitons The following considerations are desirable, but not as important as the preceding requirements, and thus should not be traded off for them. o We have something of a preference for an IETF meeting to be under "One Roof". That is, qualified meeting space and guest rooms are available in the same facility. o It is desirable for Overflow Hotels to provide reasonable, reliable, unfiltered Internet service for the public areas and guest rooms, and that this service be included in the cost of the room. o It is desirable to enter into a multi-event contract with the Facility and IETF Hotels or associated hotel chains in case such a contract will either reduce administrative costs, reduce direct attendee costs, or both. o Particularly when we are considering a city for the first time, it is desirable to have someone participate in the site visit who is familiar with both the locale and the IETF. Such a person can provide guidance regarding safety, location of local services, and understanding best ways to get to and from the Venue, and local customs, as well as identify how our requirements are met. 4. Documentation Requirements The IETF Community works best when it is well informed. This memo does not specify processes nor who has responsibility for fulfilling our requirements for meetings. Nevertheless, both of these aspects are important. Therefore, the IASA SHALL publicly document and keep current both a list of roles and responsibilities relating to IETF meetings, as well as the selection processes they use in order to fulfill the requirements of the community. 5. IANA Considerations This memo asks the IANA for no new parameters. [The RFC-Editor may remove this section prior to publicaiton.] 6. Security Considerations This note proposes no protocols, and therefore no new protocol insecurities. Lear Expires December 16, 2018 [Page 9] Internet-Draft Venue Selection June 2018 7. Privacy Considerations Different places have different constraints on individual privacy. The requirements in this memo are intended to provide for some limited protections. As meetings are announced, IASA SHALL inform the IETF of any limitations to privacy they have become aware of in their investigations. For example, participants would be informed of any regulatory authentication or logging requirements. 8. Contributors The following people provided substantial text contributions to this memo: Fred Baker Email: fred.ietf@gmail.com Fred originated this work. Ray Pelletier Email: Rpelletier13@gmail.com Laura Nugent Association Management Solutions Email: lnugent@amsl.com Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Ole Jacobsen The Internet Protocol Journal EMail: olejacobsen@me.com Jim Martin INOC Email: jim@inoc.com 9. Acknowledgements Additional contributions came from Jari Arkko, Scott Bradner, Alissa Cooper, Dave Crocker, Jordi Palet Martinez, Andrew Sullivan, and other participants in the mtgvenue working group. Those listed in this section or as contributors may or may not agree with the content of this memo. Lear Expires December 16, 2018 [Page 10] Internet-Draft Venue Selection June 2018 10. References 10.1. Normative References [I-D.ietf-mtgvenue-meeting-policy] Krishnan, S., "High level guidance for the meeting policy of the IETF", draft-ietf-mtgvenue-meeting-policy-06 (work in progress), May 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, . [RFC6771] Eggert, L. and G. Camarillo, "Considerations for Having a Successful "Bar BOF" Side Meeting", RFC 6771, DOI 10.17487/RFC6771, October 2012, . Appendix A. Change Log [RFC Editor: Please remove this section prior to publication.] 2016-01-12: Initial version 2016-01-21: Update to reflect https://iaoc.ietf.org/documents/ VenueSelectionCriteriaJan2016.pdf and https://iaoc.ietf.org/documents/VenueSelectionProcess11Jan16.pdf, accessed from https://iaoc.ietf.org/private/privatemeetings.html. 2016-02-23: Reorganize and capture IAOC Meetings Committee discussions. Lear Expires December 16, 2018 [Page 11] Internet-Draft Venue Selection June 2018 2016-03-03: Final from Design Team. 2016-03-17: First update incorporating mtgvenue@ietf.org comments 2016-05-20 Updated in accordance with editing by Laura Nugent, Dave Crocker, Lou Berger, Fred Baker, and others. posting as working group draft August 2, 2016 Reorganized per Alissa Cooper outline Work in progress. In addition, contributors were re-organized to be authors. 2016-10-28 Editor changeover. Further alignment with guidance by Alissa Cooper, Andrew Sullivan and the mtgvenue working group. Many various changes. 2016-11-16 Extensive editorial, format and polishing pass. A few substance changes, including food section. 2016-11-30 Additions based on working group meeting and off-list discussions; more editorial and format hacking. 2016-12-24 Various clarifying bits to provide some glue between the high-level 'objectives' and the detailed criteria and roles, per suggestions fronm Lear. Editorial changes, per 12/27 response to Cooper. Refined uses of 'Facility' and 'Venue', per 12/4 response to Carpenter; also added Carpenter 'lounge' text. Moved community consultation to a separate criterion; removed 'acceptable to the IETF Community from the 2 entries that had it. Removed Post- Seroul Revisions and Text Carried Forward. 2016-12-24 Address comments made on list by Stephen Farrell . Minor text change in Section 5. Replaced links in sections 5.3 and 5.5. 2017-03-12 Add openness comment as requested by Stephen Farrell. Add statement about 4071 as proposed by Brian and modified by Jari. Elaborated on what "unfiltered" means, based on discussion between Eliot and Stephen. Preface to Section 5 as discussed between Lou and Stephen. Slight editorial tweak to that by Eliot. IETF operates internationally, as proposed by Brian. 2017-04-18 Add new introductory text. Sharpen mandatory definition. Split first criteria into two, and reword them to be more actionable. Remove net cash positive requirement. Change many critera from Mandatory to Important. Remove consensus text. Modify chapeau. Add some normative MUSTs in Section 5, and Lear Expires December 16, 2018 [Page 12] Internet-Draft Venue Selection June 2018 restructure Section 5.5. A bunch of other stuff as well. Use diff. 2017-05-14 Happy Mother's Day. This version removes the tabular format of requirements, moves mandatory requirements up front, adds a desiderata section, adds a mandatory filtering requirement, consolidates introductory text, moves procedural requirements into Section 5, removes the definition of Headquarters Hotel, removes the MUST in late changes, and adds a desire for a local participant in site selection. 2017-09-12 These are last call edits. Big change is around Internet requirements. Also, address Andrew Sullivan comments, as well as SM comments. Brian Carpenter big scrub on IAOC to IASA. 2017-10-20 Final edits from WGLC based on Laura Nugent's review. Most are editorial for clarity. Also, remove large table and link to the live copy. 2018-01-10 Changes based on AD review. 2018-02-02 Changes based on genart review and IETF last call. 2018-05-07 Several versions of changes. Based on reorg of meetings committee, Section 4 and 5 moved out. Also, final LC comments addressed. In particular: no smoking added. Reference to RFC8174 added. Reference to meeting policy doc added. 2018-05-11 Remove no smoking. Author's Address Eliot Lear (editor) Cisco Systems Richtistrasse 7 Wallisellen CH-8304 Switzerland Phone: +41 44 878 9200 Email: lear@cisco.com Lear Expires December 16, 2018 [Page 13] ./draft-ietf-roll-efficient-npdao-16.txt0000644000764400076440000015634013534346556017407 0ustar iustyiusty ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert Expires: March 8, 2020 Cisco R. Sahoo Z. Cao Huawei September 5, 2019 Efficient Route Invalidation draft-ietf-roll-efficient-npdao-16 Abstract This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. 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 https://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 8, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jadhav, et al. Expires March 8, 2020 [Page 1] Internet-Draft Efficient Route Invalidation September 2019 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 and Terminology . . . . . . . . . . 3 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 1.3. Why Is NPDAO Important? . . . . . . . . . . . . . . . . . 5 2. Problems with current NPDAO messaging . . . . . . . . . . . . 6 2.1. Lost NPDAO due to link break to the previous parent . . . 6 2.2. Invalidate Routes of Dependent Nodes . . . . . . . . . . 6 2.3. Possible route downtime caused by asynchronous operation of NPDAO and DAO . . . . . . . . . . . . . . . . . . . . 6 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 6 3.1. Req#1: Remove messaging dependency on link to the previous parent . . . . . . . . . . . . . . . . . . . . . 6 3.2. Req#2: Dependent nodes route invalidation on parent switching . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Req#3: Route invalidation should not impact data traffic 7 4. Changes to RPL signaling . . . . . . . . . . . . . . . . . . 7 4.1. Change in RPL route invalidation semantics . . . . . . . 7 4.2. Transit Information Option changes . . . . . . . . . . . 8 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 11 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 11 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12 4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 13 4.6. Other considerations . . . . . . . . . . . . . . . . . . 13 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 14 4.6.3. Considerations for DCO retry . . . . . . . . . . . . 14 4.6.4. DCO with multiple preferred parents . . . . . . . . . 15 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. New Registry for the Destination Cleanup Object (DCO) Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 17 6.3. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 Jadhav, et al. Expires March 8, 2020 [Page 2] Internet-Draft Efficient Route Invalidation September 2019 8. Normative References . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 20 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20 A.2. Example DCO Messaging with multiple preferred parents . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction RPL [RFC6550] (Routing Protocol for Low power and lossy networks) specifies a proactive distance-vector based routing scheme. RPL has optional messaging in the form of DAO (Destination Advertisement Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can use to learn a route towards the downstream nodes. In storing mode, DAO messages would result in routing entries being created on all intermediate 6LRs from the node's parent all the way towards the 6LBR. RPL allows the use of No-Path DAO (NPDAO) messaging to invalidate a routing path corresponding to the given target, thus releasing resources utilized on that path. A NPDAO is a DAO message with route lifetime of zero, originates at the target node and always flows upstream towards the 6LBR. This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. The document only caters to the RPL's storing mode of operation (MOP). The non-storing MOP does not require use of NPDAO for route invalidation since routing entries are not maintained on 6LRs. 1.1. Requirements Language 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification requires readers to be familiar with all the terms and concepts that are discussed in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550]. Low Power and Lossy Networks (LLN): Network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (batter power). Their Jadhav, et al. Expires March 8, 2020 [Page 3] Internet-Draft Efficient Route Invalidation September 2019 interconnects are characterized by high loss rates, low data rates, and instability. 6LoWPAN Router (6LR): An intermediate router that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as forward and route IPv6 packets. Directed Acyclic Graph (DAG): A directed graph having the property that all edges are oriented in such a way that no cycles exist. Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, i.e., at a single DAG root with no outgoing edges. 6LoWPAN Border Router (6LBR): A border router which is a DODAG root and is the edge node for traffic flowing in and out of the 6LoWPAN network. Destination Advertisement Object (DAO): DAO messaging allows downstream routes to the nodes to be established. DODAG Information Object (DIO): DIO messaging allows upstream routes to the 6LBR to be established. DIO messaging is initiated at the DAO root. Common Ancestor node 6LR/6LBR node which is the first common node between two paths of a target node. No-Path DAO (NPDAO): A DAO message which has target with lifetime 0 used for the purpose of route invalidation. Destination Cleanup Object (DCO): A new RPL control message code defined by this document. DCO messaging improves proactive route invalidation in RPL. Regular DAO: A DAO message with non-zero lifetime. Routing adjacencies are created or updated based on this message. Target node: The node switching its parent whose routing adjacencies are updated (created/removed). 1.2. Current NPDAO messaging RPL uses NPDAO messaging in the storing mode so that the node changing its routing adjacencies can invalidate the previous route. This is needed so that nodes along the previous path can release any resources (such as the routing entry) they maintain on behalf of target node. For the rest of this document consider the following topology: Jadhav, et al. Expires March 8, 2020 [Page 4] Internet-Draft Efficient Route Invalidation September 2019 (6LBR) | | | (A) / \ / \ / \ (G) (H) | | | | | | (B) (C) \ ; \ ; \ ; (D) / \ / \ / \ (E) (F) Figure 1: Sample topology Node (D) is connected via preferred parent (B). (D) has an alternate path via (C) towards the 6LBR. Node (A) is the common ancestor for (D) for paths through (B)-(G) and (C)-(H). When (D) switches from (B) to (C), RPL allows sending NPDAO to (B) and regular DAO to (C). 1.3. Why Is NPDAO Important? Nodes in LLNs may be resource constrained. There is limited memory available and routing entry records are one of the primary elements occupying dynamic memory in the nodes. Route invalidation helps 6LR nodes to decide which entries could be discarded to better optimize resource utilization. Thus it becomes necessary to have an efficient route invalidation mechanism. Also note that a single parent switch may result in a "sub-tree" switching from one parent to another. Thus the route invalidation needs to be done on behalf of the sub- tree and not the switching node alone. In the above example, when Node (D) switches parent, the route updates needs to be done for the routing tables entries of (C),(H),(A),(G), and (B) with destination (D),(E) and (F). Without efficient route invalidation, a 6LR may have to hold a lot of stale route entries. Jadhav, et al. Expires March 8, 2020 [Page 5] Internet-Draft Efficient Route Invalidation September 2019 2. Problems with current NPDAO messaging 2.1. Lost NPDAO due to link break to the previous parent When a node switches its parent, the NPDAO is to be sent to its previous parent and a regular DAO to its new parent. In cases where the node switches its parent because of transient or permanent parent link/node failure then the NPDAO message is bound to fail. 2.2. Invalidate Routes of Dependent Nodes RPL does not specify how route invalidation will work for dependent nodes rooted at the switching node, resulting in stale routing entries of the dependent nodes. The only way for 6LR to invalidate the route entries for dependent nodes would be to use route lifetime expiry which could be substantially high for LLNs. In the example topology, when Node (D) switches its parent, Node (D) generates an NPDAO on its behalf. There is no NPDAO generated by the dependent child nodes (E) and (F), through the previous path via (D) to (B) and (G), resulting in stale entries on nodes (B) and (G) for nodes (E) and (F). 2.3. Possible route downtime caused by asynchronous operation of NPDAO and DAO A switching node may generate both an NPDAO and DAO via two different paths at almost the same time. There is a possibility that an NPDAO generated may invalidate the previous route and the regular DAO sent via the new path gets lost on the way. This may result in route downtime impacting downward traffic for the switching node. In the example topology, consider Node (D) switches from parent (B) to (C). An NPDAO sent via the previous route may invalidate the previous route whereas there is no way to determine whether the new DAO has successfully updated the route entries on the new path. 3. Requirements for the NPDAO Optimization 3.1. Req#1: Remove messaging dependency on link to the previous parent When the switching node sends the NPDAO message to the previous parent, it is normal that the link to the previous parent is prone to failure (that's why the node decided to switch). Therefore, it is required that the route invalidation does not depend on the previous link which is prone to failure. The previous link referred here represents the link between the node and its previous parent (from whom the node is now disassociating). Jadhav, et al. Expires March 8, 2020 [Page 6] Internet-Draft Efficient Route Invalidation September 2019 3.2. Req#2: Dependent nodes route invalidation on parent switching It should be possible to do route invalidation for dependent nodes rooted at the switching node. 3.3. Req#3: Route invalidation should not impact data traffic While sending the NPDAO and DAO messages, it is possible that the NPDAO successfully invalidates the previous path, while the newly sent DAO gets lost (new path not set up successfully). This will result in downstream unreachability to the node switching paths. Therefore, it is desirable that the route invalidation is synchronized with the DAO to avoid the risk of route downtime. 4. Changes to RPL signaling 4.1. Change in RPL route invalidation semantics As described in Section 1.2, the NPDAO originates at the node changing to a new parent and traverses upstream towards the root. In order to solve the problems as mentioned in Section 2, the document adds a new proactive route invalidation message called "Destination Cleanup Object" (DCO) that originates at a common ancestor node and flows downstream between the new and old path. The common ancestor node generates a DCO in response to the change in the next-hop on receiving a regular DAO with updated Path Sequence for the target. The 6LRs in the path for DCO take action such as route invalidation based on the DCO information and subsequently send another DCO with the same information downstream to the next hop. This operation is similar to how the DAOs are handled on intermediate 6LRs in storing MOP in [RFC6550]. Just like DAO in storing MOP, the DCO is sent using link-local unicast source and destination IPv6 address. Unlike DAO, which always travels upstream, the DCO always travels downstream. In Figure 1, when node D decides to switch the path from B to C, it sends a regular DAO to node C with reachability information containing the address of D as the target and an incremented Path Sequence. Node C will update the routing table based on the reachability information in the DAO and in turn generate another DAO with the same reachability information and forward it to H. Node H also follows the same procedure as Node C and forwards it to node A. When node A receives the regular DAO, it finds that it already has a routing table entry on behalf of the target address of node D. It finds however that the next hop information for reaching node D has changed i.e., node D has decided to change the paths. In this case, Node A which is the common ancestor node for node D along the two Jadhav, et al. Expires March 8, 2020 [Page 7] Internet-Draft Efficient Route Invalidation September 2019 paths (previous and new), should generate a DCO which traverses downwards in the network. Node A handles normal DAO forwarding to 6LBR as required by [RFC6550]. 4.2. Transit Information Option changes Every RPL message is divided into base message fields and additional Options as described in Section 6 of [RFC6550]. The base fields apply to the message as a whole and options are appended to add message/use-case specific attributes. As an example, a DAO message may be attributed by one or more "RPL Target" options which specify the reachability information for the given targets. Similarly, a Transit Information option may be associated with a set of RPL Target options. This document specifies a change in the Transit Information Option to contain the "Invalidate previous route" (I) flag. This 'I' flag signals the common ancestor node to generate a DCO on behalf of the target node with a RPL Status of 130 indicating that the address has moved. The 'I' flag is carried in the Transit Information Option which augments the reachability information for a given set of RPL Target(s). Transit Information Option with 'I' flag set should be carried in the DAO message when route invalidation is sought for the corresponding target(s). 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 = 0x06 | Option Length |E|I| Flags | Path Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Sequence | Path Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Updated Transit Information Option (New I flag added) I (Invalidate previous route) flag: The 'I' flag is set by the target node to indicate to the common ancestor node that it wishes to invalidate any previous route between the two paths. [RFC6550] allows the parent address to be sent in the Transit Information Option depending on the mode of operation. In case of storing mode of operation the field is usually not needed. In case of DCO, the parent address field MUST NOT be included. The common ancestor node SHOULD generate a DCO message in response to this 'I' flag when it sees that the routing adjacencies have changed for the target. The 'I' flag is intended to give the target node Jadhav, et al. Expires March 8, 2020 [Page 8] Internet-Draft Efficient Route Invalidation September 2019 control over its own route invalidation, serving as a signal to request DCO generation. 4.3. Destination Cleanup Object (DCO) A new ICMPv6 RPL control message code is defined by this specification and is referred to as "Destination Cleanup Object" (DCO), which is used for proactive cleanup of state and routing information held on behalf of the target node by 6LRs. The DCO message always traverses downstream and cleans up route information and other state information associated with the given target. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |K|D| Flags | RPL Status | DCOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 3: DCO base object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. K: The 'K' flag indicates that the recipient of DCO message is expected to send a DCO-ACK back. If the DCO-ACK is not received even after setting the 'K' flag, an implementation may retry the DCO at a later time. The number of retries are implementation and deployment dependent and are expected to be kept similar with those used in DAO retries in [RFC6550]. Section 4.6.3 specifies the considerations for DCO retry. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition. An example error condition could be that the node sending the DCO-ACK does not find the routing entry for the indicated target. When the sender does not set the 'K' flag it is an indication that the sender does not expect a response, and the sender SHOULD NOT retry the DCO. D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Jadhav, et al. Expires March 8, 2020 [Page 9] Internet-Draft Efficient Route Invalidation September 2019 Flags: The 6 bits remaining unused in the Flags field are reserved for future use. These bits MUST be initialized to zero by the sender and MUST be ignored by the receiver. RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550]. Indicative of the reason why the DCO happened, the RPL Status MUST NOT be changed as the DCO is propagated down the route being invalidated. This value is informative and does not affect the behavior of the receiver. In particular, unknown values are ignored by the receiver. Only Rejection Codes (values of 128 and above) are expected in a DCO. DCOSequence: 8-bit field incremented at each unique DCO message from a node and echoed in the DCO-ACK message. The initial DCOSequence can be chosen randomly by the node. Section 4.4 explains the handling of the DCOSequence. DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present if 'D' flag is not set. DODAGID is used when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. 4.3.1. Secure DCO A Secure DCO message follows the format in [RFC6550] Figure 7, where the base message format is the DCO message shown in Figure 3. 4.3.2. DCO Options The DCO message MUST carry at least one RPL Target and the Transit Information Option and MAY carry other valid options. This specification allows for the DCO message to carry the following options: 0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor Section 6.7 of [RFC6550] defines all the above mentioned options. The DCO carries an RPL Target Option and an associated Transit Information Option with a lifetime of 0x00000000 to indicate a loss of reachability to that Target. Jadhav, et al. Expires March 8, 2020 [Page 10] Internet-Draft Efficient Route Invalidation September 2019 4.3.3. Path Sequence number in the DCO A DCO message may contain a Path Sequence in the Transit Information Option to identify the freshness of the DCO message. The Path Sequence in the DCO MUST use the same Path Sequence number present in the regular DAO message when the DCO is generated in response to a DAO message. Thus if a DCO is received by a 6LR and subsequently a DAO is received with an old sequence number, then the DAO MUST be ignored. When the DCO is generated in response to a DCO from upstream parent, the Path Sequence MUST be copied from the received DCO. 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) The DCO-ACK message SHOULD be sent as a unicast packet by a DCO recipient in response to a unicast DCO message with 'K' flag set. If 'K' flag is not set then the receiver of the DCO message MAY send a DCO-ACK, especially to report an error condition. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |D| Flags | DCOSequence | DCO-ACK Status| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: DCO-ACK base object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Flags: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. DCOSequence: 8-bit field. The DCOSequence in DCO-ACK is copied from the DCOSequence received in the DCO message. Jadhav, et al. Expires March 8, 2020 [Page 11] Internet-Draft Efficient Route Invalidation September 2019 DCO-ACK Status: Indicates the completion. A value of 0 is defined as unqualified acceptance in this specification. A value of 1 is defined as "No routing-entry for the Target found". The remaining status values are reserved as rejection codes. DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present when 'D' flag is not set. DODAGID is used when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. 4.3.5. Secure DCO-ACK A Secure DCO-ACK message follows the format in [RFC6550] Figure 7, where the base message format is the DCO-ACK message shown in Figure 4. 4.4. DCO Base Rules 1. If a node sends a DCO message with newer or different information than the prior DCO message transmission, it MUST increment the DCOSequence field by at least one. A DCO message transmission that is identical to the prior DCO message transmission MAY increment the DCOSequence field. The DCOSequence counter follows the sequence counter operation as defined in Section 7.2 of [RFC6550]. 2. The RPLInstanceID and DODAGID fields of a DCO message MUST be the same value as that of the DAO message in response to which the DCO is generated on the common ancestor node. 3. A node MAY set the 'K' flag in a unicast DCO message to solicit a unicast DCO-ACK in response in order to confirm the attempt. 4. A node receiving a unicast DCO message with the 'K' flag set SHOULD respond with a DCO-ACK. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition. 5. A node receiving a unicast DCO message MUST verify the stored Path Sequence in context to the given target. If the stored Path Sequence is more fresh, newer than the Path Sequence received in the DCO, then the DCO MUST be dropped. 6. A node that sets the 'K' flag in a unicast DCO message but does not receive DCO-ACK in response MAY reschedule the DCO message transmission for another attempt, up until an implementation specific number of retries. 7. A node receiving a unicast DCO message with its own address in the RPL Target Option MUST strip-off that Target Option. If this Target Option is the only one in the DCO message then the DCO message MUST be dropped. Jadhav, et al. Expires March 8, 2020 [Page 12] Internet-Draft Efficient Route Invalidation September 2019 The scope of DCOSequence values is unique to the node which generates it. 4.5. Unsolicited DCO A 6LR may generate an unsolicited DCO to unilaterally cleanup the path on behalf of the target entry. The 6LR has all the state information, namely, the Target address and the Path Sequence, required for generating DCO in its routing table. The conditions why 6LR may generate an unsolicited DCO are beyond the scope of this document but some possible reasons could be: 1. On route expiry of an entry, a 6LR may decide to graciously cleanup the entry by initiating DCO. 2. 6LR needs to entertain higher priority entries in case the routing table is full, thus resulting in eviction of an existing routing entry. In this case the eviction can be handled graciously using DCO. Note that if the 6LR initiates a unilateral path cleanup using DCO and if it has the latest state for the target then the DCO would finally reach the target node. Thus the target node would be informed of its invalidation. 4.6. Other considerations 4.6.1. Dependent Nodes invalidation Current RPL [RFC6550] does not provide a mechanism for route invalidation for dependent nodes. This document allows the dependent nodes invalidation. Dependent nodes will generate their respective DAOs to update their paths, and the previous route invalidation for those nodes should work in the similar manner described for switching node. The dependent node may set the 'I' flag in the Transit Information Option as part of regular DAO so as to request invalidation of previous route from the common ancestor node. Dependent nodes do not have any indication regarding if any of their parents in turn have decided to switch their parent. Thus for route invalidation the dependent nodes may choose to always set the 'I' flag in all its DAO message's Transit Information Option. Note that setting the 'I' flag is not counterproductive even if there is no previous route to be invalidated. Jadhav, et al. Expires March 8, 2020 [Page 13] Internet-Draft Efficient Route Invalidation September 2019 4.6.2. NPDAO and DCO in the same network The current NPDAO mechanism in [RFC6550] can still be used in the same network where DCO is used. The NPDAO messaging can be used, for example, on route lifetime expiry of the target or when the node simply decides to gracefully terminate the RPL session on graceful node shutdown. Moreover, a deployment can have a mix of nodes supporting the DCO and the existing NPDAO mechanism. It is also possible that the same node supports both the NPDAO and DCO signaling for route invalidation. Section 9.8 of [RFC6550] states, "When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message to that removed DAO parent to invalidate the existing router". This document introduces an alternative and more optimized way of route invalidation but it also allows existing NPDAO messaging to work. Thus an implementation has two choices to make when a route invalidation is to be initiated: 1. Use NPDAO to invalidate the previous route and send regular DAO on the new path. 2. Send regular DAO on the new path with the 'I' flag set in the Transit Information Option such that the common ancestor node initiates the DCO message downstream to invalidate the previous route. This document recommends using option 2 for reasons specified in Section 3 in this document. This document assumes that all the 6LRs in the network support this specification. If there are 6LRs en-route DCO message path which do not support this document, then the route invalidation for corresponding targets may not work or may work partially i.e., only part of the path supporting DCO may be invalidated. Alternatively, a node could generate an NPDAO if it does not receive a DCO with itself as target within specified time limit. The specified time limit is deployment specific and depends upon the maximum depth of the network and per hop average latency. Note that sending NPDAO and DCO for the same operation would not result in unwanted side-effects because the acceptability of NPDAO or DCO depends upon the Path Sequence freshness. 4.6.3. Considerations for DCO retry A DCO message could be retried by a sender if it sets the 'K' flag and does not receive a DCO-ACK. The DCO retry time could be dependent on the maximum depth of the network and average per hop latency. This could range from 2 seconds to 120 seconds depending on Jadhav, et al. Expires March 8, 2020 [Page 14] Internet-Draft Efficient Route Invalidation September 2019 the deployment. In case the latency limits are not known, an implementation MUST NOT retry more than once in 3 seconds and MUST NOT retry more than 3 times. The number of retries could also be set depending on how critical the route invalidation could be for the deployment and the link layer retry configuration. For networks supporting only MP2P and P2MP flows, such as in AMI and telemetry applications, the 6LRs may not be very keen to invalidate routes, unless they are highly memory- constrained. For home and building automation networks which may have substantial P2P traffic, the 6LRs might be keen to invalidate efficiently because it may additionally impact the forwarding efficiency. 4.6.4. DCO with multiple preferred parents [RFC6550] allows a node to select multiple preferred parents for route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs generated at the same time for the same Target MUST be sent with the same Path Sequence in the Transit Information". Subsequently when route invalidation has to be initiated, RPL mentions use of NPDAO which can be initiated with an updated Path Sequence to all the parent nodes through which the route is to be invalidated. With DCO, the Target node itself does not initiate the route invalidation and it is left to the common ancestor node. A common ancestor node when it discovers an updated DAO from a new next-hop, it initiates a DCO. With multiple preferred parents, this handling does not change. But in this case it is recommended that an implementation initiates a DCO after a time period (DelayDCO) such that the common ancestor node may receive updated DAOs from all possible next-hops. This will help to reduce DCO control overhead i.e., the common ancestor can wait for updated DAOs from all possible directions before initiating a DCO for route invalidation. After timeout, the DCO needs to be generated for all the next-hops for whom the route invalidation needs to be done. This document recommends using a DelayDCO timer value of 1sec. This value is inspired by the default DelayDAO value of 1sec in [RFC6550]. Here the hypothesis is that the DAOs from all possible parent sets would be received on the common ancestor within this time period. It is still possible that a DCO is generated before all the updated DAOs from all the paths are received. In this case, the ancestor node would start the invalidation procedure for paths from which the updated DAO is not received. The DCO generated in this case would start invalidating the segments along these paths on which the updated DAOs are not received. But once the DAO reaches these Jadhav, et al. Expires March 8, 2020 [Page 15] Internet-Draft Efficient Route Invalidation September 2019 segments, the routing state would be updated along these segments and should not lead to any inconsistent routing state. Note that there is no requirement for synchronization between DCO and DAOs. The DelayDCO timer simply ensures that the DCO control overhead can be reduced and is only needed when the network contains nodes using multiple preferred parent. 5. Acknowledgments Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulous, Peter Van Der Stok for their review and comments. Alvaro Retana helped shape this document's final version with critical review comments. 6. IANA Considerations IANA is requested to allocate new codes for the DCO and DCO-ACK messages from the RPL Control Codes registry. +------+---------------------------------------------+--------------+ | Code | Description | Reference | +------+---------------------------------------------+--------------+ | TBD1 | Destination Cleanup Object | This | | | | document | | TBD2 | Destination Cleanup Object Acknowledgment | This | | | | document | | TBD3 | Secure Destination Cleanup Object | This | | | | document | | TBD4 | Secure Destination Cleanup Object | This | | | Acknowledgment | document | +------+---------------------------------------------+--------------+ IANA is requested to allocate bit 1 from the Transit Information Option Flags registry for the 'I' flag (Section 4.2) 6.1. New Registry for the Destination Cleanup Object (DCO) Flags IANA is requested to create a registry for the 8-bit Destination Cleanup Object (DCO) Flags field. This registry should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description Jadhav, et al. Expires March 8, 2020 [Page 16] Internet-Draft Efficient Route Invalidation September 2019 o Defining RFC The following bits are currently defined: +------------+------------------------------+---------------+ | Bit number | Description | Reference | +------------+------------------------------+---------------+ | 0 | DCO-ACK request (K) | This document | | 1 | DODAGID field is present (D) | This document | +------------+------------------------------+---------------+ DCO Base Flags 6.2. New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status field IANA is requested to create a registry for the 8-bit Destination Cleanup Object Acknowledgment (DCO-ACK) Status field. This registry should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New Status values may be allocated only by an IETF Review. Each value is tracked with the following qualities: o Status Code o Description o Defining RFC The following values are currently defined: +------------+----------------------------------------+-------------+ | Status | Description | Reference | | Code | | | +------------+----------------------------------------+-------------+ | 0 | Unqualified acceptance | This | | | | document | | 1 | No routing-entry for the indicated | This | | | Target found | document | +------------+----------------------------------------+-------------+ DCO-ACK Status Codes 6.3. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags IANA is requested to create a registry for the 8-bit Destination Cleanup Object (DCO) Acknowledgment Flags field. This registry Jadhav, et al. Expires March 8, 2020 [Page 17] Internet-Draft Efficient Route Invalidation September 2019 should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following bits are currently defined: +------------+------------------------------+---------------+ | Bit number | Description | Reference | +------------+------------------------------+---------------+ | 0 | DODAGID field is present (D) | This document | +------------+------------------------------+---------------+ DCO-ACK Base Flags 7. Security Considerations This document introduces the ability for a common ancestor node to invalidate a route on behalf of the target node. The common ancestor node could be directed to do so by the target node using the 'I' flag in DCO's Transit Information Option. However, the common ancestor node is in a position to unilaterally initiate the route invalidation since it possesses all the required state information, namely, the Target address and the corresponding Path Sequence. Thus a rogue common ancestor node could initiate such an invalidation and impact the traffic to the target node. The DCO carries a RPL Status value, which is informative. New Status values may be created over time and a node will ignore an unknown Status value. This enables RPL Status field to be used as a cover channel. But the channel only works once since the message destroys its own medium, that is the existing route that it is removing. This document also introduces an 'I' flag which is set by the target node and used by the ancestor node to initiate a DCO if the ancestor sees an update in the route adjacency. However, this flag could be spoofed by a malicious 6LR in the path and can cause invalidation of an existing active path. Note that invalidation will happen only if the other conditions such as Path Sequence condition is also met. Having said that, such a malicious 6LR may spoof a DAO on behalf of the (sub) child with the 'I' flag set and can cause route invalidation on behalf of the (sub) child node. Note that, using existing mechanisms offered by [RFC6550], a malicious 6LR might also Jadhav, et al. Expires March 8, 2020 [Page 18] Internet-Draft Efficient Route Invalidation September 2019 spoof a DAO with lifetime of zero or otherwise cause denial of service by dropping traffic entirely, so the new mechanism described in this document does not present a substantially increased risk of disruption. This document assumes that the security mechanisms as defined in [RFC6550] are followed, which means that the common ancestor node and all the 6LRs are part of the RPL network because they have the required credentials. A non-secure RPL network needs to take into consideration the risks highlighted in this section as well as those highlighted in [RFC6550]. All RPL messages support a secure version of messages which allows integrity protection using either a MAC or a signature. Optionally, secured RPL messages also have encryption protection for confidentiality. The document adds new messages (DCO, DCO-ACK) which are syntactically similar to existing RPL messages such as DAO, DAO-ACK. Secure versions of DCO and DCO-ACK are added similar to other RPL messages (such as DAO, DAO-ACK). RPL supports three security modes as mentioned in Section 10.1 of [RFC6550]: 1. Unsecured: In this mode, it is expected that the RPL control messages are secured by other security mechanisms, such as link- layer security. In this mode, the RPL control messages, including DCO, DCO-ACK, do not have Security sections. Also note that unsecured mode does not imply that all messages are sent without any protection. 2. Preinstalled: In this mode, RPL uses secure messages. Thus secure versions of DCO, DCO-ACK MUST be used in this mode. 3. Authenticated: In this mode, RPL uses secure messages. Thus secure versions of DCO, DCO-ACK MUST be used in this mode. 8. 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, . Jadhav, et al. Expires March 8, 2020 [Page 19] Internet-Draft Efficient Route Invalidation September 2019 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Example Messaging A.1. Example DCO Messaging In Figure 1, node (D) switches its parent from (B) to (C). This example assumes that Node D has already established its own route via Node B-G-A-6LBR using pathseq=x. The example uses DAO and DCO messaging convention and specifies only the required parameters to explain the example namely, the parameter 'tgt', which stands for Target Option and value of this parameter specifies the address of the target node. The parameter 'pathseq', which specifies the Path Sequence value carried in the Transit Information Option. The parameter 'I_flag' specifies the 'I' flag in the Transit Information Option. sequence of actions is as follows: 1. Node D switches its parent from node B to node C 2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated path to C 3. C checks for a routing entry on behalf of D, since it cannot find an entry on behalf of D it creates a new routing entry and forwards the reachability information of the target D to H in a DAO(tgt=D,pathseq=x+1,I_flag=1). 4. Similar to C, node H checks for a routing entry on behalf of D, cannot find an entry and hence creates a new routing entry and forwards the reachability information of the target D to A in a DAO(tgt=D,pathseq=x+1,I_flag=1). 5. Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1), and checks for a routing entry on behalf of D. It finds a routing entry but checks that the next hop for target D is different (i.e., Node G). Node A checks the I_flag and generates DCO(tgt=D,pathseq=x+1) to previous next hop for target D which is G. Subsequently, Node A updates the routing entry and forwards the reachability information of target D upstream DAO(tgt=D,pathseq=x+1,I_flag=1). 6. Node G receives the DCO(tgt=D,pathseq=x+1). It checks if the received path sequence is later than the stored path sequence. If it is later, Node G invalidates the routing entry of target D Jadhav, et al. Expires March 8, 2020 [Page 20] Internet-Draft Efficient Route Invalidation September 2019 and forwards the (un)reachability information downstream to B in DCO(tgt=D,pathseq=x+1). 7. Similarly, B processes the DCO(tgt=D,pathseq=x+1) by invalidating the routing entry of target D and forwards the (un)reachability information downstream to D. 8. D ignores the DCO(tgt=D,pathseq=x+1) since the target is itself. 9. The propagation of the DCO will stop at any node where the node does not have an routing information associated with the target. If cached routing information is present and the cached Path Sequence is higher than the value in the DCO, then the DCO is dropped. A.2. Example DCO Messaging with multiple preferred parents (6LBR) | | | (N11) / \ / \ / \ (N21) (N22) / / \ / / \ / / \ (N31) (N32) (N33) : | / : | / : | / (N41) Figure 5: Sample topology 2 In Figure 5, node (N41) selects multiple preferred parents (N32) and (N33). The sequence of actions is as follows: 1. (N41) sends DAO(tgt=N41,PS=x,I_flag=1) to (N32) and (N33). Here I_flag refers to the Invalidation flag and PS refers to Path Sequence in Transit Information option. 2. (N32) sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N33) also sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N22) learns multiple routes for the same destination (N41) through multiple next-hops. (N22) may receive the DAOs from (N32) and (N33) in any order with the I_flag set. The implementation should use the DelayDCO timer to wait to initiate the DCO. If (N22) receives an updated DAO from all the paths then the DCO need not Jadhav, et al. Expires March 8, 2020 [Page 21] Internet-Draft Efficient Route Invalidation September 2019 be initiated in this case. Thus the route table at N22 should contain (Dst,NextHop,PS): { (N41,N32,x), (N41,N33,x) }. 3. (N22) sends DAO(tgt=N41,PS=x,I_flag=1) to (N11). 4. (N11) sends DAO(tgt=N41,PS=x,I_flag=1) to (6LBR). Thus the complete path is established. 5. (N41) decides to change preferred parent set from { N32, N33 } to { N31, N32 }. 6. (N41) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N32). (N41) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N31). 7. (N32) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N22). (N22) has multiple routes to destination (N41). It sees that a new Path Sequence for Target=N41 is received and thus it waits for pre- determined time period (DelayDCO time period) to invalidate another route {(N41),(N33),x}. After time period, (N22) sends DCO(tgt=N41,PS=x+1) to (N33). Also (N22) sends the regular DAO(tgt=N41,PS=x+1,I_flag=1) to (N11). 8. (N33) receives DCO(tgt=N41,PS=x+1). The received Path Sequence is latest and thus it invalidates the entry associated with target (N41). (N33) then sends the DCO(tgt=N41,PS=x+1) to (N41). (N41) sees itself as the target and drops the DCO. 9. From Step 6 above, (N31) receives the DAO(tgt=N41,PS=x+1,I_flag=1). It creates a routing entry and sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N21). Similarly (N21) receives the DAO and subsequently sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N11). 10. (N11) receives DAO(tgt=N41,PS=x+1,I_flag=1) from (N21). It waits for DelayDCO timer since it has multiple routes to (N41). (N41) will receive DAO(tgt=N41,PS=x+1,I_flag=1) from (N22) from Step 7 above. Thus (N11) has received regular DAO(tgt=N41,PS=x+1,I_flag=1) from all paths and thus does not initiate DCO. 11. (N11) forwards the DAO(tgt=N41,PS=x+1,I_flag=1) to 6LBR and the full path is established. Authors' Addresses Rahul Arvind Jadhav (editor) Huawei Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com Jadhav, et al. Expires March 8, 2020 [Page 22] Internet-Draft Efficient Route Invalidation September 2019 Pascal Thubert Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis 06254 France Phone: +33 497 23 26 34 Email: pthubert@cisco.com Rabi Narayan Sahoo Huawei Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rabinarayans@huawei.com Zhen Cao Huawei W Chang'an Ave Beijing P.R. China Email: zhencao.ietf@gmail.com Jadhav, et al. Expires March 8, 2020 [Page 23] ./draft-ietf-mtgvenue-meeting-policy-07.txt0000644000764400076440000002605713316534560020154 0ustar iustyiusty Internet Engineering Task Force S. Krishnan Internet-Draft Kaloom Intended status: Best Current Practice July 2, 2018 Expires: January 3, 2019 High level guidance for the meeting policy of the IETF draft-ietf-mtgvenue-meeting-policy-07 Abstract This document describes a meeting location policy for the IETF and the various stakeholders for realizing such a policy. 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 https://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 3, 2019. Copyright Notice Copyright (c) 2018 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 (https://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. Krishnan Expires January 3, 2019 [Page 1] Internet-Draft IETF Meeting Policy July 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The 1-1-1-* meeting policy . . . . . . . . . . . . . . . . . 2 3. Implementation of the policy . . . . . . . . . . . . . . . . 3 4. Procedure for initiating proposals for exploratory meetings . 4 5. Re-evaluation and changes to this policy . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The work of the IETF is primarily conducted on the working group mailing lists, while face-to-face WG meetings mainly provide a high bandwidth mechanism for working out unresolved issues. The IETF currently strives to have a 1-1-1 meeting policy [IETFMEET] where the goal is to distribute the meetings equally between North America, Europe, and Asia. These are the locations most of the IETF participants have come from in the recent past. This meeting rotation is mainly aimed at distributing the travel effort for the existing IETF participants who physically attend meetings and for distributing the timezone difficulty for those who participate remotely. This policy has neither been defined precisely nor documented in an IETF consensus document until now. This document is meant to serve as a consensus-backed statement of this policy published as a BCP. 2. The 1-1-1-* meeting policy Given that the majority of the current participants come from North America, Europe, and Asia [CONT-DIST], the IETF policy is that our meetings should primarily be in those regions. i.e., the meeting policy (let's call this the "1-1-1" policy) is that meetings should rotate between North America, Europe, and Asia. Please note that the boundaries between those regions has been purposefully left undefined. It is important to note that such rotation and any effects to distributing travel pain should be considered from a long- term perspective. While a potential cycle in an IETF year may be a meeting in North America in March, a meeting in Europe in July, and a meeting in Asia on November, the 1-1-1 policy does not imply such a cycle, as long as the distribution to these regions over multiple years is roughly equal. There are many reasons why meetings might be distributed differently in a given year. Meeting locations in subsequent years should seek to re-balance the distribution if possible. Krishnan Expires January 3, 2019 [Page 2] Internet-Draft IETF Meeting Policy July 2018 While this meeting rotation caters to the current set of IETF participants, it is important to recognize that due to the dynamic and evolving nature of participation, there may be significant changes to the regions that provide a major share of participants in the future. The 1-1-1-* meeting policy is a slightly modified version of the aforementioned 1-1-1 meeting policy that allows for additional flexibility in the form of an exploratory meeting denoted as a "*". This exploratory meeting can be used to experiment with exceptional meetings without extensively impacting the regular meetings. e.g. these exploratory meetings can include meetings in other geographical regions, virtual meetings and additional meetings past the three regular meetings in a calendar year. The timing and frequency of future exploratory meetings will be based on IETF consensus as determined by the IETF chair. Once a meeting proposal is initiated, the IESG will make a decision in consultation with the Internet Administrative Support Activity (IASA) to ensure that the proposal can be realistically implemented. The final decision will be communicated back to the community to ensure that there is adequate opportunity to comment. NOTE: There have not been a large number of meetings that would qualify as exploratory meetings under the current 1-1-1-* policy (with IETF95 in Buenos Aires and IETF47 in Adelaide being the exceptional instances). IETF27 (Amsterdam) and IETF54(Yokohama) were earlier examples of exploratory meetings that pioneered Europe and Asia as regular IETF destinations. 3. Implementation of the policy IASA should understand the policy written in this document to be the aspiration of the IETF community. Similarly, any exploratory meeting decisions will also be communicated to the IASA to be implemented. The actual selection of the venue would be performed by the IASA following the process described in [I-D.ietf-mtgvenue-iaoc-venue-selection-process]. As mentioned in [I-D.ietf-mtgvenue-iaoc-venue-selection-process], the IASA will also be responsible o to assist the community in the development of detailed meeting criteria that are feasible and implementable, and o to provide sufficient transparency in a timely manner concerning planned meetings so that community feedback can be collected and acted upon. Krishnan Expires January 3, 2019 [Page 3] Internet-Draft IETF Meeting Policy July 2018 Given that the geographical location of the venue has a significant influence on the venue selection process, it needs to be considered at the same level as the other Important Criteria specified in Section 3.2 of [I-D.ietf-mtgvenue-iaoc-venue-selection-process] (including potentially trading off the geographical region to meet other criteria, and notifying the community if the geographical region requirement cannot be met) 4. Procedure for initiating proposals for exploratory meetings Someone who is interested in pursuing an exploratory venue proposes it on the IETF discussion list or on a future discussion list expressly setup and announced for this purpose. The community gets to comment on the venue and to offer their opinions. If the IETF chair determines that there is community consensus to pursue the venue further, the venue will be put up for discussion on the venue- selection mailing list. This would allow the interested party(ies) to refine their proposal with those tasked with evaluating it and providing further insightful feedback regarding the logistics of the venue. Once the venue selection process takes place, the final decision will be communicated back to the community to ensure that there is adequate opportunity to comment. 5. Re-evaluation and changes to this policy Given the dynamic nature of participant distribution in the IETF, it is expected that this policy needs to be periodically evaluated and revised to ensure that the stated goals continue to be met. The criteria that are to be met need to be agreed upon by the community prior to initiating a revision of this document (e.g. try to mirror draft author distribution over the preceding five years). 6. Acknowledgments The author would like to thank Jari Arkko, Alia Atlas, Fred Baker, Brian Carpenter, Alissa Cooper, Dave Crocker, Spencer Dawkins, Stephen Farrell, Tobias Gondrom, Eric Gray, Bob Hinden, Ole Jacobsen, Olaf Kolkman, Eliot Lear, Andrew Malis, Yoav Nir, Ray Pelletier, Melinda Shore, John Klensin, Charles Eckel, Russ Housley, Andrew Sullivan, Eric Rescorla, Richard Barnes, Cullen Jennings, Ted Lemon, Lou Berger, John Levine, Adam Roach, Mark Nottingham, Tom Petch, Randy Bush, Roni Even, Julien Meuric, Lloyd Wood, Alvaro Retana and Martin Vigoureux for their ideas and comments to improve this document. Krishnan Expires January 3, 2019 [Page 4] Internet-Draft IETF Meeting Policy July 2018 7. References 7.1. Normative References [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, . 7.2. Informative References [CONT-DIST] IETF, "Number of attendees per continent across meetings", 2016, . [I-D.ietf-mtgvenue-iaoc-venue-selection-process] Lear, E., "IETF Plenary Meeting Venue Selection Process", draft-ietf-mtgvenue-iaoc-venue-selection-process-16 (work in progress), June 2018. [IETFMEET] IAOC Plenary Presentation, "IETF 1-1-1 Meeting Policy", 2010, . Author's Address Suresh Krishnan Kaloom Email: suresh@kaloom.com Krishnan Expires January 3, 2019 [Page 5] ./draft-ietf-roll-useofrplinfo-31.txt0000644000764400076440000037334013507375636017066 0ustar iustyiusty ROLL Working Group M. Robles Internet-Draft Aalto Updates: 6553, 6550, 8138 (if approved) M. Richardson Intended status: Standards Track SSW Expires: January 5, 2020 P. Thubert Cisco July 4, 2019 Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane draft-ietf-roll-useofrplinfo-31 Abstract This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC6553 (RPL Option Type), RFC6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC6553 adding a change to the RPL Option Type. Additionally, this document updates RFC6550 defining a flag in the DIO Configuration Option to indicate about this change and updates RFC8138 as well to consider the new Option Type when the RPL Option is decompressed. 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 https://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 5, 2020. Robles, et al. Expires January 5, 2020 [Page 1] Internet-Draft RPL-data-plane July 2019 Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Requirements Language . . . . . . . . . . . . 4 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 4.1. Updates to RFC6553: Indicating the new RPI value. . . . . 7 4.2. Updates to RFC6550: Indicating the new RPI in the DODAG Configuration Option Flag. . . . . . . . . . . . . 10 4.3. Updates to RFC8138: Indicating the way to decompress with the new RPI value. . . . . . . . . . . . . . . . . . . . 11 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 12 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 18 7.1.1. SM: Example of Flow from RAL to root . . . . . . . . 18 7.1.2. SM: Example of Flow from root to RAL . . . . . . . . 19 7.1.3. SM: Example of Flow from root to RUL . . . . . . . . 20 7.1.4. SM: Example of Flow from RUL to root . . . . . . . . 20 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 21 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 22 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 22 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 23 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 24 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 25 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 25 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 27 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 27 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 29 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 30 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 31 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 32 Robles, et al. Expires January 5, 2020 [Page 2] Internet-Draft RPL-data-plane July 2019 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 32 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 33 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 34 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 35 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 35 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 36 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 37 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 38 8.3. Non-SM: Interaction between Leafs . . . . . . . . . . . . 39 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 39 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 41 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 42 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 43 9. Operational Considerations of supporting not-RPL-aware-leaves . . . . . . . . . . . . . . . . . . . . 44 10. Operational considerations of introducing 0x23 . . . . . . . 45 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 14.1. Normative References . . . . . . . . . . . . . . . . . . 50 14.2. Informative References . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is a routing protocol for constrained networks. RFC6553 [RFC6553] defines the "RPL option" (RPL Packet Information or RPI), carried within the IPv6 Hop-by-Hop header to quickly identify inconsistencies (loops) in the routing topology. RFC6554 [RFC6554] defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header to deliver datagrams within a RPL routing domain, particularly in non-storing mode. These various items are referred to as RPL artifacts, and they are seen on all of the data-plane traffic that occurs in RPL routed networks; they do not in general appear on the RPL control plane traffic at all which is mostly hop-by-hop traffic (one exception being DAO messages in non-storing mode). It has become clear from attempts to do multi-vendor interoperability, and from a desire to compress as many of the above artifacts as possible that not all implementers agree when artifacts are necessary, or when they can be safely omitted, or removed. The ROLL WG analysized how [RFC2460] rules apply to storing and non- storing use of RPL. The result was 24 data plane use cases. They Robles, et al. Expires January 5, 2020 [Page 3] Internet-Draft RPL-data-plane July 2019 are exhaustively outlined here in order to be completely unambiguous. During the processing of this document, new rules were published as [RFC8200], and this document was updated to reflect the normative changes in that document. This document updates RFC6553, changing the RPI option value to make RFC8200 routers ignore this option by default. A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a mechanism for compressing RPL Option information and Routing Header type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 technique. Since some of the uses cases here described, use IPv6-in-IPv6 encapsulation. It MUST take in consideration, when encapsulation is applied, the RFC6040 [RFC6040], which defines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IPV6-in-IPV6 tunnel. Additionally, it is recommended the reading of [I-D.ietf-intarea-tunnels] that explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling. Non-constrained uses of RPL are not in scope of this document, and applicability statements for those uses may provide different advice, E.g. [I-D.ietf-anima-autonomic-control-plane]. 1.1. Overview The rest of the document is organized as follows: Section 2 describes the used terminology. Section 3 describes the updates to RFC6553, RFC6550 and RFC 8138. Section 4 provides the reference topology used for the uses cases. Section 5 describes the uses cases included. Section 6 describes the storing mode cases and section 7 the non- storing mode cases. Section 8 describes the operational considerations of supporting not-RPL-aware-leaves. Section 9 depicts operational considerations for the proposed change on RPL Option type, section 10 the IANA considerations and then section 11 describes the security aspects. 2. Terminology and Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Robles, et al. Expires January 5, 2020 [Page 4] Internet-Draft RPL-data-plane July 2019 Terminology defined in [RFC7102] applies to this document: LLN, RPL, RPL Domain and ROLL. RPL-aware-node: A device which implements RPL. Please note that the device can be found inside the LLN or outside LLN. RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. RPL-unaware-node: A device which does not implement RPL, thus the device is not-RPL-aware. Please note that the device can be found inside the LLN. RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. 6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any host or router participating in a LoWPAN. This term is used when referring to situations in which either a host or router can play the role described.". In this document, a 6LN acts as a leaf. 6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate router in the LoWPAN that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as forward and route IPv6 packets. 6LoWPAN routers are present only in route-over topologies." 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border router located at the junction of separate 6LoWPAN networks or between a 6LoWPAN network and another IP network. There may be one or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the responsible authority for IPv6 prefix propagation for the 6LoWPAN network it is serving. An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network." Flag Day: A transition that involves having a network with different values of RPL Option Type. Thus the network does not work correctly (Lack of interoperation). Hop-by-hop re-encapsulation: The term "hop-by-hop re-encapsulation" header refers to adding a header that originates from a node to an adjacent node, using the addresses (usually the GUA or ULA, but could use the link-local addresses) of each node. If the packet must traverse multiple hops, then it must be decapsulated at each hop, and then re-encapsulated again in a similar fashion. Non-storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about its parents. Thus, Robles, et al. Expires January 5, 2020 [Page 5] Internet-Draft RPL-data-plane July 2019 the root know the topology, then the intermediate 6LRs do not maintain routing state so that source routing is needed. Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes (6LRs) maintain routing state (of the children) so that source routing is not needed. Due to lack of space in some figures (tables) we refers IPv6-in-IPv6 as IP6-IP6. 3. RPL Overview RPL defines the RPL Control messages (control plane), a new ICMPv6 [RFC4443] message with Type 155. DIS (DODAG Information Solicitation), DIO (DODAG Information Object) and DAO (Destination Advertisement Object) messages are all RPL Control messages but with different Code values. A RPL Stack is shown in Figure 1. +--------------+ | Upper Layers | | | +--------------+ | RPL | | | +--------------+ | ICMPv6 | | | +--------------+ | IPv6 | | | +--------------+ | 6LoWPAN | | | +--------------+ | PHY-MAC | | | +--------------+ Figure 1: RPL Stack. RPL supports two modes of Downward traffic: in storing mode (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully source routed. A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of storing and non-storing nodes is not supported with the current specifications at the time of writing this document. Robles, et al. Expires January 5, 2020 [Page 6] Internet-Draft RPL-data-plane July 2019 4. Updates to RFC6553, RFC6550 and RFC8138 4.1. Updates to RFC6553: Indicating the new RPI value. This modification is required to be able to send, for example, IPv6 packets from a RPL-Aware-Leaf to a not-RPL-aware node through Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 encapsulation. [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in the Option Type field of the RPL Option header, the two high order bits must be set to '01' and the third bit is equal to '1'. The first two bits indicate that the IPv6 node must discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data may change in route. The remaining bits serve as the option type. +-------+-------------------+----------------+-----------+ | Hex | Binary Value | Description | Reference | + Value +-------------------+ + + | | act | chg | rest | | | +-------+-----+-----+-------+----------------+-----------+ | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | +-------+-----+-----+-------+----------------+-----------+ Figure 2: Option Type in RPL Option. This document illustrates that is is not always possible to know for sure at the source that a packet will only travel within the RPL domain or may leave it. At the time [RFC6553] was published, leaking a Hop-by-Hop header in the outer IPv6 header chain could potentially impact core routers in the internet. So at that time, it was decided to encapsulate any packet with a RPL option using IPv6-in-IPv6 in all cases where it was unclear whether the packet would remain within the RPL domain. In the exception case where a packet would still leak, the Option Type would ensure that the first router in the Internet that does not recognize the option would drop the packet and protect the rest of the network. Even with [RFC8138] that compresses the IPv6-in-IPv6 header, this approach yields extra bytes in a packet which means consuming more energy, more bandwidth, incurring higher chances of loss and possibly causing a fragmentation at the 6LoWPAN level. This impacts the daily operation of constrained devices for a case that generally does not happen and would not heavily impact the core anyway. Robles, et al. Expires January 5, 2020 [Page 7] Internet-Draft RPL-data-plane July 2019 While intention was and remains that the Hop-by-Hop header with a RPL option should be confined within the RPL domain, this specification modifies this behavior in order to reduce the dependency on IPv6-in- IPv6 and protect the constrained devices. Section 4 of [RFC8200] clarifies the behaviour of routers in the Internet as follows: "it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so". When unclear about the travel of a packet, it becomes preferable for a source not to encapsulate, accepting the fact that the packet may leave the RPL domain on its way to its destination. In that event, the packet should reach its destination and should not be discarded by the first node that does not recognize the RPL option. But with the current value of the Option Type, if a node in the Internet is configured to process the Hop-by-Hop header, and if such node encounters an option with the first two bits set to 01 and conforms to [RFC8200], it will drop the packet. Host systems should do the same, irrespective of the configuration. Thus, this document updates the Option Type field to (Figure 3): the two high order bits MUST be set to '00' and the third bit is equal to '1'. The first two bits indicate that the IPv6 node MUST skip over this option and continue processing the header ([RFC8200] Section 4.2) if it doesn't recognize the option type, and the third bit continues to be set to indicate that the Option Data may change en route. The remaining bits serve as the option type and remain as 0x3. This ensures that a packet that leaves the RPL domain of an LLN (or that leaves the LLN entirely) will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop option known as RPI. With the new Option Type, if an IPv6 (intermediate) node (RPL-not- capable) receives a packet with an RPL Option, it should ignore the Hop-by-Hop RPL option (skip over this option and continue processing the header). This is relevant, as it was mentioned previously, in the case that there is a flow from RAL to Internet (see Section 7.2.1). This is a significant update to [RFC6553]. Robles, et al. Expires January 5, 2020 [Page 8] Internet-Draft RPL-data-plane July 2019 +-------+-------------------+-------------+------------+ | Hex | Binary Value | Description | Reference | + Value +-------------------+ + + | | act | chg | rest | | | +-------+-----+-----+-------+-------------+------------+ | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| +-------+-----+-----+-------+-------------+------------+ Figure 3: Revised Option Type in RPL Option. (*)represents this document Without the signaling described below, this change would otherwise create a lack of interoperation (flag day) for existing networks which are currently using 0x63 as the RPI value. A move to 0x23 will not be understood by those networks. It is suggested that RPL implementations accept both 0x63 and 0x23 when processing the header. When forwarding packets, implementations SHOULD use the same value as it was received (This is required because, RPI type code can not be changed by [RFC8200] - Section 4.2). It allows to the network to be incrementally upgraded, and for the DODAG root to know which parts of the network are upgraded. When originating new packets, implementations SHOULD have an option to determine which value to originate with, this option is controlled by the DIO option described below. A network which is switching from straight 6LoWPAN compression mechanism to those described in [RFC8138] will experience a flag day in the data compression anyway, and if possible this change can be deployed at the same time. The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] Section 4.2 compliant nodes tolerant of the RPL artifacts. There is therefore no longer a necessity to remove the artifacts when sending traffic to the Internet. This change clarifies when to use an IPv6- in-IPv6 header, and how to address them: The Hop-by-Hop Options Header containing the RPI option MUST always be added when 6LRs originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST always be added when a 6LR find that it needs to insert a Hop-by-Hop Options Header containing the RPI option. The IPv6-in- IPv6 header is to be addressed to the RPL root when on the way up, and to the end-host when on the way down. In the non-storing case, dealing with not-RPL aware leaf nodes is much easier as the 6LBR (DODAG root) has complete knowledge about the connectivity of all DODAG nodes, and all traffic flows through the root node. Robles, et al. Expires January 5, 2020 [Page 9] Internet-Draft RPL-data-plane July 2019 The 6LBR can recognize not-RPL aware leaf nodes because it will receive a DAO about that node from the 6LR immediately above that not-RPL aware node. This means that the non-storing mode case can avoid ever using hop-by-hop re-encapsulation headers for traffic originating from the root to the leafs. The non-storing mode case does not require the type change from 0x63 to 0x23, as the root can always create the right packet. The type change does not adversely affect the non-storing case. 4.2. Updates to RFC6550: Indicating the new RPI in the DODAG Configuration Option Flag. In order to avoid a Flag Day caused by lack of interoperation between new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag in the DIO Configuration Option, to indicate when then new RPI value can be safely used. This means, the flag is going to indicate the type of RPI that the network is using. Thus, when a node join to a network will know which value to use. With this, RPL-capable nodes know if it is safe to use 0x23 when creating a new RPI. A node that forwards a packet with an RPI MUST NOT modify the option type of the RPI. This is done via a DODAG Configuration Option flag which will propagate through the network. If the flag is received with a value zero (which is the default), then new nodes will remain in RFC6553 Compatible Mode; originating traffic with the old-RPI (0x63) value. As stated in [RFC6550] the DODAG Configuration option is present in DIO messages. The DODAG Configuration option distributes configuration information. It is generally static, and does not change within the DODAG. This information is configured at the DODAG root and distributed throughout the DODAG with the DODAG Configuration option. Nodes other than the DODAG root do not modify this information when propagating the DODAG Configuration option. The DODAG Configuration Option has a Flag field which is modified by this document. Currently, the DODAG Configuration Option in [RFC6550] states: "the unused bits MUST be initialize to zero by the sender and MUST be ignored by the receiver". Bit number three of the flag field in the DODAG Configuration option is to be used as shown in Figure 4 : Robles, et al. Expires January 5, 2020 [Page 10] Internet-Draft RPL-data-plane July 2019 +------------+-----------------+---------------+ | Bit number | Description | Reference | +------------+-----------------+---------------+ | 3 | RPI 0x23 enable | This document | +------------+-----------------+---------------+ Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- day. In case of rebooting, the node (6LN or 6LR) does not remember the RPL Option Type, that is if the flag is set, so DIO messages sent by the node would be set with the flag unset until a DIO message is received with the flag set indicating the new RPI value. The node sets to 0x23 if the node supports this feature. 4.3. Updates to RFC8138: Indicating the way to decompress with the new RPI value. This modification is required to be able to decompress the RPL RPI option with the new value (0x23). RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] in section 6. A node that is decompressing this header MUST decompress using the RPL RPI option type that is currently active: that is, a choice between 0x23 (new) and 0x63 (old). The node will know which to use based upon the presence of the flag in the DODAG Configuration Option defined in Section 4.2. E.g. If the network is in 0x23 mode (by DIO option), then it should be decompressed to 0x23. [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 header. There are potential significant advantages to having a single code path that always processes IPv6-in-IPv6 headers with no conditional branches. In Storing Mode, for the examples of Flow from RAL to RUL and RUL to RUL comprise an IPv6-in-IPv6 and RPI compression headers. The use of the IPv6-in-IPv6 header is MANDATORY in this case, and it SHOULD be compressed with [RFC8138] section 7. Figure 5 illustrates the case in Storing mode where the packet is received from the Internet, then the root encapsulates the packet to insert the RPI. In that example, the leaf is not known to support RFC 8138, and the packet is encapsulated to the 6LR that is the parent and last hop to the final destination. Robles, et al. Expires January 5, 2020 [Page 11] Internet-Draft RPL-data-plane July 2019 +-+ ... -+-+ ... +-+- ... -+-+- .... +-+-+-+ ... +-+-+ ... -+ ... +-... |11110001|SRH-6LoRH| RPI- |IPv6-in-IPv6| NH=1 |11110CPP| UDP | UDP |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld +-+ ... -+-+ ... +-+- ... -+-+-- ...+-+-+-+-+ ... +-+-+ ... -+ ... +-... <-4bytes-> <- RFC 6282 -> No RPL artifact Figure 5: RPI Inserted by the Root in Storing Mode In Figure 5, the source of the IPv6-in-IPv6 encapsulation is the Root, so it is elided in the IPv6-in-IPv6 6LoRH. The destination is the parent 6LR of the destination of the inner packet so it cannot be elided. It is placed as the single entry in an SRH-6LoRH as the first 6LoRH. There is a single entry so the SRH-6LoRH Size is 0. In that example, the type is 1 so the 6LR address is compressed to 2 bytes. It results that the total length of the SRH-6LoRH is 4 bytes. Follows the RPI-6LoRH and then the IPv6-in-IPv6 6LoRH. When the IPv6-in-IPv6 6LoRH is removed, all the router headers that precede it are also removed. The Paging Dispatch [RFC8025] may also be removed if there was no previous Page change to a Page other than 0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and in Page 1. The resulting packet to the destination is the inner packet compressed with [RFC6282]. 5. Sample/reference topology A RPL network in general is composed of a 6LBR, Backbone Router (6BBR), 6LR and 6LN as leaf logically organized in a DODAG structure. Figure 6 shows the reference RPL Topology for this document. The letters above the nodes are there so that they may be referenced in subsequent sections. In the figure, 6LR represents a full router node. The 6LN is a RPL aware router, or host (as a leaf). Additionally, for simplification purposes, it is supposed that the 6LBR has direct access to Internet, thus the 6BBR is not present in the figure. The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no children hosts. The leafs marked as RUL (G and J) are devices which do not speak RPL at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ DAC and efficient-ND only to participate in the network [RFC6775]. In the document these leafs (G and J) are also referred to as an IPv6 node. The 6LBR ("A") in the figure is the root of the Global DODAG. Robles, et al. Expires January 5, 2020 [Page 12] Internet-Draft RPL-data-plane July 2019 +------------+ | INTERNET ----------+ | | | +------------+ | | | | A | +-------+ |6LBR | +-----------|(root) |-------+ | +-------+ | | | | | | | | | | B |C +---|---+ +---|---+ | 6LR | | 6LR | +---------| |--+ +--- ---+ | +-------+ | | +-------+ | | | | | | | | | | | | | | | | | | D | E | | +-|-----+ +---|---+ | | | 6LR | | 6LR | | | | | +------ | | | +---|---+ | +---|---+ | | | | | | | | | +--+ | | | | | | | | | | | | | | | I | J | F | | G | H | | +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ | RAL | | RUL | | RAL | | RAL | | RUL | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | +-------+ +-------+ +------+ +-------+ +-------+ Figure 6: A reference RPL Topology. Robles, et al. Expires January 5, 2020 [Page 13] Internet-Draft RPL-data-plane July 2019 6. Use cases In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 encapsulation are going to be analyzed for a number of representative traffic flows. This document assumes that the LLN is using the no-drop RPI option (0x23). The use cases describe the communication in the following cases: - Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- nodes with the Internet - Between RUL nodes within the LLN (e.g. see Section 7.1.4) - Inside of the LLN when the final destination address resides outside of the LLN (e.g. see Section 7.2.3). The uses cases are as follows: Interaction between Leaf and Root: RAL to root root to RAL RUL to root root to RUL Interaction between Leaf and Internet: RAL to Internet Internet to RAL RUL to Internet Internet to RUL Interaction between Leafs: RAL to RAL (storing and non-storing) RAL to RUL (non-storing) RUL to RAL (storing and non-storing) RUL to RUL (non-storing) Robles, et al. Expires January 5, 2020 [Page 14] Internet-Draft RPL-data-plane July 2019 This document is consistent with the rule that a Header cannot be inserted or removed on the fly inside an IPv6 packet that is being routed. This is a fundamental precept of the IPv6 architecture as outlined in [RFC8200]. As the rank information in the RPI artifact is changed at each hop, it will typically be zero when it arrives at the DODAG root. The DODAG root MUST force it to zero when passing the packet out to the Internet. The Internet will therefore not see any SenderRank information. Despite being legal to leave the RPI artifact in place, an intermediate router that needs to add an extension header (e.g. RH3 or RPI Option) MUST still encapsulate the packet in an (additional) outer IP header. The new header is placed after this new outer IP header. A corollary is that an RH3 or RPI Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 Header, which is addressed TO the intermediate router. When it does so, the whole encapsulating header must be removed. (A replacement may be added). This sometimes can result in outer IP headers being addressed to the next hop router using link-local address. Both RPI and RH3 headers may be modified in very specific ways by routers on the path of the packet without the need to add and remove an encapsulating header. Both headers were designed with this modification in mind, and both the RPL RH3 and the RPL option are marked mutable but recoverable: so an IPsec AH security header can be applied across these headers, but it can not secure the values which mutate. RPI MUST be present in every single RPL data packet. Prior to [RFC8138], there was significant interest in removing the RPI for downward flows in non-storing mode. The exception covered a very small number of cases, and causes significant interoperability challenges, yet costed significant code and testing complexity. The ability to compress the RPI down to three bytes or less removes much of the pressure to optimize this any further [I-D.ietf-anima-autonomic-control-plane]. The earlier examples are more extensive to make sure that the process is clear, while later examples are more concise. The uses cases are delineated based on the following requirements: The RPI option has to be in every packet that traverses the LLN. Robles, et al. Expires January 5, 2020 [Page 15] Internet-Draft RPL-data-plane July 2019 - Because of (1), packets from the Internet have to be encapsulated. - A Header cannot be inserted or removed on the fly inside an IPv6 packet that is being routed. - Extension headers may not be added or removed except by the sender or the receiver. - RPI and RH3 headers may be modified by routers on the path of the packet without the need to add and remove an encapsulating header. - An RH3 or RPI Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 Header, which is addressed to the intermediate router. - Non-storing mode requires downstream encapsulation by root for RH3. The uses cases are delineated based on the following assumptions: This document assumes that the LLN is using the no-drop RPI option (0x23). - Each IPv6 node (including Internet routers) obeys [RFC8200] 8200, so that 0x23 RPI can be safely inserted. - All 6LRs obey [RFC8200]. - The RPI is ignored at the IPv6 dst node (RPL-unaware-leaf). - The leaf can be a router 6LR or a host, both indicated as 6LN. - Non-constrained uses of RPL are not in scope of this document. - Compression is based on [RFC8138]. - The flow label [RFC6437] is not needed in RPL. 7. Storing mode In storing mode (SM) (fully stateful), the sender can determine if the destination is inside the LLN by looking if the destination address is matched by the DIO's Prefix Information Option (PIO) option. Robles, et al. Expires January 5, 2020 [Page 16] Internet-Draft RPL-data-plane July 2019 The following table (Figure 7) itemizes which headers are needed in each of the following scenarios. It indicates if the IPv6-in-IPv6 header that is added, must be addressed to the final destination (the RAL node that is the target(tgt)), to the "root" or if a hop-by-hop header must be added (indicated by "hop"). In the hop-by-hop basis, the destination address for the next hop is the link-layer address of the next hop. In cases where no IPv6-in-IPv6 header is needed, the column states as "No". If the IPv6-in-IPv6 header is needed is a "must". In all cases the RPI headers are needed, since it identifies inconsistencies (loops) in the routing topology. In all cases the RH3 is not needed because it is not used in storing mode. In each case, 6LR_i are the intermediate routers from source to destination. "1 <= i <= n", n is the number of routers (6LR) that the packet goes through from source (6LN) to destination. The leaf can be a router 6LR or a host, both indicated as 6LN. The root refers to the 6LBR (see Figure 6). Robles, et al. Expires January 5, 2020 [Page 17] Internet-Draft RPL-data-plane July 2019 +---------------------+--------------+------------+------------------+ | Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | +---------------------+--------------+------------+------------------+ | | RAL to root | No | No | + +--------------+------------+------------------+ | Leaf - Root | root to RAL | No | No | + +--------------+------------+------------------+ | | root to RUL | No | No | + +--------------+------------+------------------+ | | RUL to root | must | root | +---------------------+--------------+------------+------------------+ | | RAL to Int | No | No | + +--------------+------------+------------------+ | Leaf - Internet | Int to RAL | must | RAL (tgt) | + +--------------+------------+------------------+ | | RUL to Int | must | root | + +--------------+------------+------------------+ | | Int to RUL | must | hop | +---------------------+--------------+------------+------------------+ | | RAL to RAL | No | No | + +--------------+------------+------------------+ | | RAL to RUL | No | No | + Leaf - Leaf +--------------+------------+------------------+ | | RUL to RAL | must | RAL (tgt) | + +--------------+------------+------------------+ | | RUL to RUL | must | hop | +---------------------+--------------+------------+------------------+ Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 7.1. Storing Mode: Interaction between Leaf and Root In this section is described the communication flow in storing mode (SM) between, RAL to root root to RAL RUL to root root to RUL 7.1.1. SM: Example of Flow from RAL to root In storing mode, RFC 6553 (RPI) is used to send RPL Information instanceID and rank information. Robles, et al. Expires January 5, 2020 [Page 18] Internet-Draft RPL-data-plane July 2019 In this case the flow comprises: RAL (6LN) --> 6LR_i --> root(6LBR) For example, a communication flow could be: Node F --> Node D --> Node B --> Node A root(6LBR) The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR (Node E) which decrements the rank in RPI and sends the packet up. When the packet arrives at 6LBR (Node A), the RPI is removed and the packet is processed. No IPv6-in-IPv6 header is required. The RPI header can be removed by the 6LBR because the packet is addressed to the 6LBR. The 6LN must know that it is communicating with the 6LBR to make use of this scenario. The 6LN can know the address of the 6LBR because it knows the address of the root via the DODAGID in the DIO messages. The Table 1 summarizes what headers are needed for this use case. +-------------------+---------+-------+----------+ | Header | 6LN src | 6LR_i | 6LBR dst | +-------------------+---------+-------+----------+ | Inserted headers | RPI | -- | -- | | Removed headers | -- | -- | RPI | | Re-added headers | -- | -- | -- | | Modified headers | -- | RPI | -- | | Untouched headers | -- | -- | -- | +-------------------+---------+-------+----------+ Table 1: SM: Summary of the use of headers from RAL to root 7.1.2. SM: Example of Flow from root to RAL In this case the flow comprises: root (6LBR) --> 6LR_i --> RAL (6LN) For example, a communication flow could be: Node A root(6LBR) --> Node B --> Node D --> Node F In this case the 6LBR inserts RPI header and sends the packet down, the 6LR is going to increment the rank in RPI (it examines the instanceID to identify the right forwarding table), the packet is processed in the 6LN and the RPI removed. Robles, et al. Expires January 5, 2020 [Page 19] Internet-Draft RPL-data-plane July 2019 No IPv6-in-IPv6 header is required. The Table 2 summarizes what headers are needed for this use case. +-------------------+------+-------+------+ | Header | 6LBR | 6LR_i | 6LN | +-------------------+------+-------+------+ | Inserted headers | RPI | -- | -- | | Removed headers | -- | -- | RPI | | Re-added headers | -- | -- | -- | | Modified headers | -- | RPI | -- | | Untouched headers | -- | -- | -- | +-------------------+------+-------+------+ Table 2: SM: Summary of the use of headers from root to RAL 7.1.3. SM: Example of Flow from root to RUL In this case the flow comprises: root (6LBR) --> 6LR_i --> RUL (IPv6) For example, a communication flow could be: Node A root(6LBR) --> Node B --> Node E --> Node G As the RPI extension can be ignored by the not-RPL-aware leaf, this situation is identical to the previous scenario. The Table 3 summarizes what headers are needed for this use case. +-------------------+----------+-------+----------------+ | Header | 6LBR src | 6LR_i | IPv6 dst node | +-------------------+----------+-------+----------------+ | Inserted headers | RPI | -- | -- | | Removed headers | -- | -- | -- | | Re-added headers | -- | -- | -- | | Modified headers | -- | RPI | -- | | Untouched headers | -- | -- | RPI (Ignored) | +-------------------+----------+-------+----------------+ Table 3: SM: Summary of the use of headers from root to RUL 7.1.4. SM: Example of Flow from RUL to root In this case the flow comprises: RUL (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) Robles, et al. Expires January 5, 2020 [Page 20] Internet-Draft RPL-data-plane July 2019 For example, a communication flow could be: Node G --> Node E --> Node B --> Node A root(6LBR) When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header can be addressed to the next hop (Node B), or to the root (Node A). The root removes the header and processes the packet. The Figure 8 shows the table that summarizes what headers are needed for this use case. [1] refers the case where the IPv6-in-IPv6 header is addressed to the next hop (Node B). [2] refers the case where the IPv6-in-IPv6 header is addressed to the root (Node A). +-----------+------+--------------+-----------------+------------------+ | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | | | src | | | | | | node | | | | +-----------+------+--------------+-----------------+------------------+ | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | | headers | | | | | +-----------+------+--------------+-----------------+------------------+ | Removed | -- | -- | -- |IP6-IP6(RPI)[1][2]| | headers | | | | | +-----------+------+--------------+-----------------+------------------+ | Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | | headers | | | | | +-----------+------+--------------+-----------------+------------------+ | Modified | -- | -- | IP6-IP6(RPI)[2] | -- | | headers | | | | | +-----------+------+--------------+-----------------+------------------+ | Untouched | -- | -- | -- | -- | | headers | | | | | +-----------+------+--------------+-----------------+------------------+ Figure 8: SM: Summary of the use of headers from RUL to root. 7.2. SM: Interaction between Leaf and Internet. In this section is described the communication flow in storing mode (SM) between, RAL to Internet Internet to RAL RUL to Internet Robles, et al. Expires January 5, 2020 [Page 21] Internet-Draft RPL-data-plane July 2019 Internet to RUL 7.2.1. SM: Example of Flow from RAL to Internet RPL information from RFC 6553 may go out to Internet as it will be ignored by nodes which have not been configured to be RPI aware. In this case the flow comprises: RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet For example, the communication flow could be: Node F --> Node D --> Node B --> Node A root(6LBR) --> Internet No IPv6-in-IPv6 header is required. Note: In this use case it is used a node as leaf, but this use case can be also applicable to any RPL-aware-node type (e.g. 6LR) The Table 4 summarizes what headers are needed for this use case. +-------------------+---------+-------+------+----------------+ | Header | 6LN src | 6LR_i | 6LBR | Internet dst | +-------------------+---------+-------+------+----------------+ | Inserted headers | RPI | -- | -- | -- | | Removed headers | -- | -- | -- | -- | | Re-added headers | -- | -- | -- | -- | | Modified headers | -- | RPI | -- | -- | | Untouched headers | -- | -- | RPI | RPI (Ignored) | +-------------------+---------+-------+------+----------------+ Table 4: SM: Summary of the use of headers from RAL to Internet 7.2.2. SM: Example of Flow from Internet to RAL In this case the flow comprises: Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) For example, a communication flow could be: Internet --> Node A root(6LBR) --> Node B --> Node D --> Node F When the packet arrives from Internet to 6LBR the RPI header is added in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address set to the 6LR) and sent to 6LR, which modifies the rank in the RPI. When the packet arrives at 6LN the RPI header is removed and the packet processed. Robles, et al. Expires January 5, 2020 [Page 22] Internet-Draft RPL-data-plane July 2019 The Figure 9 shows the table that summarizes what headers are needed for this use case. +-----------+----------+--------------+--------------+--------------+ | Header | Internet | 6LBR | 6LR_i | 6LN dst | | | src | | | | +-----------+----------+--------------+--------------+--------------+ | Inserted | -- | IP6-IP6(RPI) | -- | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ | Removed | -- | -- | -- | IP6-IP6(RPI) | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ | Re-added | -- | -- | -- | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ | Modified | -- | -- | IP6-IP6(RPI) | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ | Untouched | -- | -- | -- | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ Figure 9: SM: Summary of the use of headers from Internet to RAL. 7.2.3. SM: Example of Flow from RUL to Internet In this case the flow comprises: RUL (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet For example, a communication flow could be: Node G --> Node E --> Node B --> Node A root(6LBR) --> Internet The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed either to the root, or hop-by-hop such that the root can remove the RPI header before passing upwards. The IPv6-in-IPv6 addressed to the root cause less processing overhead. On the other hand, with hop-by- hop the intermediate routers can check the routing tables for a better routing path, thus it could be more efficient and faster. Implementation should decide which approach to take. The originating node will ideally leave the IPv6 flow label as zero so that the packet can be better compressed through the LLN. The 6LBR will set the flow label of the packet to a non-zero value when sending to the Internet, for details check [RFC6437]. Robles, et al. Expires January 5, 2020 [Page 23] Internet-Draft RPL-data-plane July 2019 The Figure 10 shows the table that summarizes what headers are needed for this use case. +---------+-------+------------+--------------+-------------+--------+ | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| | | src | | [i=2,...,n] | | dst | | | node | | | | | +---------+-------+------------+--------------+-------------+--------+ | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | | headers | | | [2] | | | +---------+-------+------------+--------------+-------------+--------+ | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | | headers | | | [2] | [1][2] | | +---------+-------+------------+--------------+-------------+--------+ | Re-added| -- | -- | -- | -- | -- | | headers | | | | | | +---------+-------+------------+--------------+-------------+--------+ | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | | headers | | | [1] | | | +---------+-------+------------+--------------+-------------+--------+ |Untouched| -- | -- | -- | -- | -- | | headers | | | | | | +---------+-------+------------+--------------+-------------+--------+ Figure 10: SM: Summary of the use of headers from RUL to Internet. [1] Case when packet is addressed to the root. [2] Case when the packet is addressed hop-by-hop. 7.2.4. SM: Example of Flow from Internet to RUL. In this case the flow comprises: Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6) For example, a communication flow could be: Internet --> Node A root(6LBR) --> Node B --> Node E --> Node G The 6LBR will have to add an RPI header within an IPv6-in-IPv6 header. The IPv6-in-IPv6 is addressed hop-by-hop. The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it. The final node does not process the RPI, the node ignores the RPI. Furhter details about this are mentioned in [I-D.thubert-roll-unaware-leaves], which specifies RPL routing for a 6LN acting as a plain host and not aware of RPL. Robles, et al. Expires January 5, 2020 [Page 24] Internet-Draft RPL-data-plane July 2019 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression [RFC8138][RFC6437]. The Figure 11 shows the table that summarizes what headers are needed for this use case. +-----------+----------+--------------+--------------+--------------+ | Header | Internet | 6LBR | 6LR_i |IPv6 dst node | | | src | | | | +-----------+----------+--------------+--------------+--------------+ | Inserted | -- | IP6-IP6(RPI) | -- | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ | Removed | -- | -- | | IP6-IP6(RPI)| | headers | | | | RPI Ignored | +-----------+----------+--------------+--------------+--------------+ | Re-added | -- | -- | -- | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ | Modified | -- | -- | IP6-IP6(RPI) | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ | Untouched | -- | -- | -- | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ Figure 11: SM: Summary of the use of headers from Internet to RUL. 7.3. SM: Interaction between Leaf and Leaf In this section is described the communication flow in storing mode (SM) between, RAL to RAL RAL to RUL RUL to RAL RUL to RUL 7.3.1. SM: Example of Flow from RAL to RAL In [RFC6550] RPL allows a simple one-hop optimization for both storing and non-storing networks. A node may send a packet destined to a one-hop neighbor directly to that node. See section 9 in [RFC6550]. Robles, et al. Expires January 5, 2020 [Page 25] Internet-Draft RPL-data-plane July 2019 When the nodes are not directly connected, then in storing mode, the flow comprises: 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN For example, a communication flow could be: Node F --> Node D --> Node B --> Node E --> Node H 6LR_ia (Node D) are the intermediate routers from source to the common parent (6LR_x) (Node B) In this case, 1 <= ia <= n, n is the number of routers (6LR) that the packet goes through from 6LN (Node F) to the common parent (6LR_x). 6LR_id (Node E) are the intermediate routers from the common parent (6LR_x) (Node B) to destination 6LN (Node H). In this case, 1 <= id <= m, m is the number of routers (6LR) that the packet goes through from the common parent (6LR_x) to destination 6LN. It is assumed that the two nodes are in the same RPL Domain (that they share the same DODAG root). At the common parent (Node B), the direction of RPI is changed (from increasing to decreasing the rank). While the 6LR nodes will update the RPI, no node needs to add or remove the RPI, so no IPv6-in-IPv6 headers are necessary. The Table 5 summarizes what headers are needed for this use case. +---------------+--------+--------+---------------+--------+--------+ | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | | | src | | parent) | | dst | +---------------+--------+--------+---------------+--------+--------+ | Inserted | RPI | -- | -- | -- | -- | | headers | | | | | | | Removed | -- | -- | -- | -- | RPI | | headers | | | | | | | Re-added | -- | -- | -- | -- | -- | | headers | | | | | | | Modified | -- | RPI | RPI | RPI | -- | | headers | | | | | | | Untouched | -- | -- | -- | -- | -- | | headers | | | | | | +---------------+--------+--------+---------------+--------+--------+ Table 5: SM: Summary of the use of headers for RAL to RAL Robles, et al. Expires January 5, 2020 [Page 26] Internet-Draft RPL-data-plane July 2019 7.3.2. SM: Example of Flow from RAL to RUL In this case the flow comprises: 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 6LN (IPv6) For example, a communication flow could be: Node F --> Node D --> Node B --> Node E --> Node G 6LR_ia are the intermediate routers from source (6LN) to the common parent (6LR_x) In this case, 1 <= ia <= n, n is the number of routers (6LR) that the packet goes through from 6LN to the common parent (6LR_x). 6LR_id (Node E) are the intermediate routers from the common parent (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). In this case, 1 <= id <= m, m is the number of routers (6LR) that the packet goes through from the common parent (6LR_x) to destination 6LN. This situation is identical to the previous situation Section 7.3.1 The Table 6 summarizes what headers are needed for this use case. +-----------+------+--------+---------------+--------+--------------+ | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 dst | | | src | | parent) | | node | +-----------+------+--------+---------------+--------+--------------+ | Inserted | RPI | -- | -- | -- | -- | | headers | | | | | | | Removed | -- | -- | -- | -- | -- | | headers | | | | | | | Re-added | -- | -- | -- | -- | -- | | headers | | | | | | | Modified | -- | RPI | RPI | RPI | -- | | headers | | | | | | | Untouched | -- | -- | -- | -- | RPI(Ignored) | | headers | | | | | | +-----------+------+--------+---------------+--------+--------------+ Table 6: SM: Summary of the use of headers for RAL to RUL 7.3.3. SM: Example of Flow from RUL to RAL In this case the flow comprises: Robles, et al. Expires January 5, 2020 [Page 27] Internet-Draft RPL-data-plane July 2019 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN For example, a communication flow could be: Node G --> Node E --> Node B --> Node D --> Node F 6LR_ia (Node E) are the intermediate routers from source (not-RPL- aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In this case, 1 <= ia <= n, n is the number of routers (6LR) that the packet ges through from source to the common parent. 6LR_id (Node D) are the intermediate routers from the common parent (6LR_x) (Node B) to destination 6LN (Node F). In this case, 1 <= id <= m, m is the number of routers (6LR) that the packet goes through from the common parent (6LR_x) to destination 6LN. The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the destination 6LN (Node F). The Figure 12 shows the table that summarizes what headers are needed for this use case. +---------+-----+------------+-------------+-------------+------------+ | Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | | |src | | Parent | | dst | | |node | | (6LRx) | | | +---------+-----+------------+-------------+-------------+------------+ | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | | headers | | | | | | +---------+-----+------------+-------------+-------------+------------+ | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| | headers | | | | | | +---------+-----+------------+-------------+-------------+------------+ | Re-added| -- | -- | -- | -- | -- | | headers | | | | | | +---------+-----+------------+-------------+-------------+------------+ | Modified| -- | -- |IP6-IP6(RPI) |IP6-IP6(RPI) | -- | | headers | | | | | | +---------+-----+------------+-------------+-------------+------------+ |Untouched| -- | -- | -- | -- | -- | | headers | | | | | | +---------+-----+------------+-------------+-------------+------------+ Figure 12: SM: Summary of the use of headers from RUL to RAL. Robles, et al. Expires January 5, 2020 [Page 28] Internet-Draft RPL-data-plane July 2019 7.3.4. SM: Example of Flow from RUL to RUL In this case the flow comprises: not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id --> not-RPL-aware 6LN (IPv6 dst) For example, a communication flow could be: Node G --> Node E --> Node B --> Node A (root) --> Node C --> Node J Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate router from the not-RPL-aware source (Node G) to the root (6LBR) (Node A). In this case, "1 < ia <= n", n is the number of routers (6LR) that the packet goes through from IPv6 src to the root. 6LR_id (Node C) are the intermediate routers from the root (Node A) to the destination Node J. In this case, 1 <= id <= m, m is the number of routers (6LR) that the packet goes through from the root to destination (IPv6 dst). The RPI is ignored at the IPv6 dst node. The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed hop-by-hop. The Figure 13 shows the table that summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 29] Internet-Draft RPL-data-plane July 2019 +---------+------+-------+-------+---------+-------+-------+ | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | IPv6 | | | src | | | | | dst | | | node | | | | | node | +---------+------+-------+-------+---------+-------+-------+ | Inserted| -- |IP6-IP6| -- | | -- | -- | | headers | | (RPI )| | | | | | | | | | | | | +---------+------+-------+-------+---------+-------+-------+ | Removed | -- | -- | -- | | -- |IP6-IP6| | headers | | | | | |(RPI) | | | | | | | | RPI | | | | | | | |Ignored| +---------+------+-------+-------+---------+-------+-------+ | Re-added| -- | -- | -- | -- | -- | -- | | headers | | | | | | | +---------+------+-------+-------+---------+-------+-------+ | Modified| -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| -- | | headers | | | (RPI) | (RPI) | (RPI) | | | | | | | | | | +---------+------+-------+-------+---------+-------+-------+ |Untouched| -- | -- | -- | -- | -- | -- | | headers | | | | | | | +---------+------+-------+-------+---------+-------+-------+ Figure 13: SM: Summary of the use of headers from RUL to RUL 8. Non Storing mode In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG root) has complete knowledge about the connectivity of all DODAG nodes, and all traffic flows through the root node. Thus, there is no need for all nodes to know about the existence of not-RPL aware nodes. Only the 6LBR needs to act if compensation is necessary for not-RPL aware receivers. The following table (Figure 14) summarizes what headers are needed in the following scenarios, and indicates when the RPI, RH3 and IPv6-in- IPv6 header are to be inserted. It depicts the target destination address possible (indicated by "RAL"), to a 6LR (parent of a 6LN) or to the root. In cases where no IPv6-in-IPv6 header is needed, the column states as "No". There is no expectation on RPL that RPI can be omitted, because it is needed for routing, quality of service and compression. This specification expects that is always a RPI Present. The leaf can be a router 6LR or a host, both indicated as 6LN (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], Robles, et al. Expires January 5, 2020 [Page 30] Internet-Draft RPL-data-plane July 2019 where the RPI header may still be needed for the instanceID to be available for priority/channel selection at each hop. +-----------------+--------------+-----+-----+------------+------------+ | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| | between | | | | | dst | +-----------------+--------------+-----+-----+------------+------------+ | | RAL to root | Yes | No | No | No | + +--------------+-----+-----+------------+------------+ | Leaf - Root | root to RAL | Yes | Yes | No | No | + +--------------+-----+-----+------------+------------+ | | root to RUL | Yes | Yes | must | 6LR | | | | (1) | | | | + +--------------+-----+-----+------------+------------+ | | RUL to root | Yes | No | must | root | +-----------------+--------------+-----+-----+------------+------------+ | | RAL to Int | Yes | No | No | No | + +--------------+-----+-----+------------+------------+ | Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | + +--------------+-----+-----+------------+------------+ | | RUL to Int | Yes | No | must | root | + +--------------+-----+-----+------------+------------+ | | Int to RUL | Yes | Yes | must | 6LR | +-----------------+--------------+-----+-----+------------+------------+ | | RAL to RAL | Yes | Yes | must | root/RAL | + +--------------+-----+-----+------------+------------+ | | RAL to RUL | Yes | Yes | must | root/6LR | + Leaf - Leaf +--------------+-----+-----+------------+------------+ | | RUL to RAL | Yes | Yes | must | root/RAL | + +--------------+-----+-----+------------+------------+ | | RUL to RUL | Yes | Yes | must | root/6LR | +-----------------+--------------+-----+-----+------------+------------+ Figure 14: Table that shows headers needed in Non-Storing mode: RPI, RH3, IPv6-in-IPv6 encapsulation. 8.1. Non-Storing Mode: Interaction between Leaf and Root In this section is described the communication flow in Non Storing Mode (Non-SM) between, RAL to root root to RAL RUL to root root to RUL Robles, et al. Expires January 5, 2020 [Page 31] Internet-Draft RPL-data-plane July 2019 8.1.1. Non-SM: Example of Flow from RAL to root In non-storing mode the leaf node uses default routing to send traffic to the root. The RPI header must be included since it contains the rank information, which is used to avoid/detect loops. RAL (6LN) --> 6LR_i --> root(6LBR) For example, a communication flow could be: Node F --> Node D --> Node B --> Node A (root) 6LR_i are the intermediate routers from source to destination. In this case, "1 <= i <= n", n is the number of routers (6LR) that the packet goes through from source (6LN) to destination (6LBR). This situation is the same case as storing mode. The Table 7 summarizes what headers are needed for this use case. +-------------------+---------+-------+----------+ | Header | 6LN src | 6LR_i | 6LBR dst | +-------------------+---------+-------+----------+ | Inserted headers | RPI | -- | -- | | Removed headers | -- | -- | RPI | | Re-added headers | -- | -- | -- | | Modified headers | -- | RPI | -- | | Untouched headers | -- | -- | -- | +-------------------+---------+-------+----------+ Table 7: Non-SM: Summary of the use of headers from RAL to root 8.1.2. Non-SM: Example of Flow from root to RAL In this case the flow comprises: root (6LBR) --> 6LR_i --> RAL (6LN) For example, a communication flow could be: Node A (root) --> Node B --> Node D --> Node F 6LR_i are the intermediate routers from source to destination. In this case, "1 <= i <= n", n is the number of routers (6LR) that the packet goes through from source (6LBR) to destination (6LN). The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is necessary as the traffic originates with an RPL aware node, the 6LBR. The destination is known to be RPL-aware because the root knows the whole topology in non-storing mode. Robles, et al. Expires January 5, 2020 [Page 32] Internet-Draft RPL-data-plane July 2019 The Table 8 summarizes what headers are needed for this use case. +-------------------+----------+-----------+-----------+ | Header | 6LBR src | 6LR_i | 6LN dst | +-------------------+----------+-----------+-----------+ | Inserted headers | RPI, RH3 | -- | -- | | Removed headers | -- | -- | RH3, RPI | | Re-added headers | -- | -- | -- | | Modified headers | -- | RPI, RH3 | -- | | Untouched headers | -- | -- | -- | +-------------------+----------+-----------+-----------+ Table 8: Non-SM: Summary of the use of headers from root to RAL 8.1.3. Non-SM: Example of Flow from root to RUL In this case the flow comprises: root (6LBR) --> 6LR_i --> RUL (IPv6) For example, a communication flow could be: Node A (root) --> Node B --> Node E --> Node G 6LR_i are the intermediate routers from source to destination. In this case, "1 <= i <= n", n is the number of routers (6LR) that the packet goes through from source (6LBR) to destination (IPv6). In 6LBR the RH3 is added, it is modified at each intermediate 6LR (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), but left there. As the RPI is added, then the IPv6 node which does not understand the RPI, will ignore it (following RFC8200), thus encapsulation is not necessary. The Figure 15 depicts the table that summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 33] Internet-Draft RPL-data-plane July 2019 +-----------+----------+--------------+----------------+----------+ | Header | 6LBR | 6LR_i | 6LR_n | IPv6 | | | | i=(1,..,n-1) | | dst | | | | | | node | +-----------+----------+--------------+----------------+----------+ | Inserted | RPI, RH3 | -- | -- | -- | | headers | | | | | +-----------+----------+--------------+----------------+----------+ | Removed | -- | -- | | -- | | headers | | | | | +-----------+----------+--------------+----------------+----------+ | Re-added | -- | -- | -- | -- | | headers | | | | | +-----------+----------+--------------+----------------+----------+ | Modified | -- | RPI, RH3 | RPI, | -- | | headers | | | RH3(consumed) | | +-----------+----------+--------------+----------------+----------+ | Untouched | -- | -- | -- | RPI, RH3 | | headers | | | | (both | | | | | | ignored) | +-----------+----------+--------------+----------------+----------+ Figure 15: Non-SM: Summary of the use of headers from root to RUL 8.1.4. Non-SM: Example of Flow from RUL to root In this case the flow comprises: RUL (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) For example, a communication flow could be: Node G --> Node E --> Node B --> Node A (root) 6LR_i are the intermediate routers from source to destination. In this case, "1 < i <= n", n is the number of routers (6LR) that the packet goes through from source (IPv6) to destination (6LBR). For example, 6LR_1 (i=1) is the router that receives the packets from the IPv6 node. In this case the RPI is added by the first 6LR (6LR1) (Node E), encapsulated in an IPv6-in-IPv6 header, and is modified in the following 6LRs. The RPI and entire packet is consumed by the root. The Figure 16 shows the table that summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 34] Internet-Draft RPL-data-plane July 2019 +---------+----+-----------------+-----------------+-----------------+ | Header |IPv6| 6LR_1 | 6LR_i | 6LBR dst | | |src | | | | | |node| | | | +---------+----+-----------------+-----------------+-----------------+ | Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- | | headers | | | | | +---------+----+-----------------+-----------------+-----------------+ | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| | headers | | | | | +---------+----+-----------------+-----------------+-----------------+ | Re-added| -- | -- | -- | -- | | headers | | | | | +---------+----+-----------------+-----------------+-----------------+ | Modified| -- | -- |IPv6-in-IPv6(RPI)| -- | | headers | | | | | +---------+----+-----------------+-----------------+-----------------+ |Untouched| -- | -- | -- | -- | | headers | | | | | +---------+----+-----------------+-----------------+-----------------+ Figure 16: Non-SM: Summary of the use of headers from RUL to root 8.2. Non-Storing Mode: Interaction between Leaf and Internet This section will describe the communication flow in Non Storing Mode (Non-SM) between: RAL to Internet Internet to RAL RUL to Internet Internet to RUL 8.2.1. Non-SM: Example of Flow from RAL to Internet In this case the flow comprises: RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet For example, a communication flow could be: Node F --> Node D --> Node B --> Node A --> Internet 6LR_i are the intermediate routers from source to destination. In this case, "1 <= i <= n", n is the number of routers (6LR) that the packet goes through from source (6LN) to 6LBR. Robles, et al. Expires January 5, 2020 [Page 35] Internet-Draft RPL-data-plane July 2019 This case is identical to storing-mode case. The IPv6 flow label should be set to zero to aid in compression [RFC8138], and the 6LBR will set it to a non-zero value when sending towards the Internet [RFC6437]. The Table 9 summarizes what headers are needed for this use case. +-------------------+---------+-------+------+----------------+ | Header | 6LN src | 6LR_i | 6LBR | Internet dst | +-------------------+---------+-------+------+----------------+ | Inserted headers | RPI | -- | -- | -- | | Removed headers | -- | -- | -- | -- | | Re-added headers | -- | -- | -- | -- | | Modified headers | -- | RPI | -- | -- | | Untouched headers | -- | -- | RPI | RPI (Ignored) | +-------------------+---------+-------+------+----------------+ Table 9: Non-SM: Summary of the use of headers from RAL to Internet 8.2.2. Non-SM: Example of Flow from Internet to RAL In this case the flow comprises: Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) For example, a communication flow could be: Internet --> Node A (root) --> Node B --> Node D --> Node F 6LR_i are the intermediate routers from source to destination. In this case, "1 <= i <= n", n is the number of routers (6LR) that the packet goes through from 6LBR to destination(6LN). The 6LBR must add an RH3 header. As the 6LBR will know the path and address of the target node, it can address the IPv6-in-IPv6 header to that node. The 6LBR will zero the flow label upon entry in order to aid compression [RFC8138]. The Table 10 summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 36] Internet-Draft RPL-data-plane July 2019 +-----------+----------+--------------+--------------+--------------+ | Header | Internet | 6LBR | 6LR_i | 6LN src | | | dst | | | | +-----------+----------+--------------+--------------+--------------+ | Inserted | -- | IPv6-in-IPv6 | -- | -- | | headers | | (RH3,RPI) | | | | Removed | -- | -- | -- | IPv6-in-IPv6 | | headers | | | | (RH3,RPI) | | Re-added | -- | -- | -- | -- | | headers | | | | | | Modified | -- | -- | IPv6-in-IPv6 | -- | | headers | | | (RH3,RPI) | | | Untouched | -- | -- | -- | -- | | headers | | | | | +-----------+----------+--------------+--------------+--------------+ Table 10: Non-SM: Summary of the use of headers from Internet to RAL 8.2.3. Non-SM: Example of Flow from RUL to Internet In this case the flow comprises: RUL (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet For example, a communication flow could be: Node G --> Node E --> Node B --> Node A --> Internet 6LR_i are the intermediate routers from source to destination. In this case, "1 < i <= n", n is the number of routers (6LR) that the packet goes through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). In this case the flow label is recommended to be zero in the IPv6 node. As RPL headers are added in the IPv6 node packet, the first 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. The IPv6-in-IPv6 header will be addressed to the root. This case is identical to the storing-mode case (see Section 7.2.3). The Figure 17 shows the table that summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 37] Internet-Draft RPL-data-plane July 2019 +---------+----+-------------+--------------+--------------+--------+ | Header |IPv6| 6LR_1 | 6LR_i | 6LBR |Internet| | |src | | [i=2,..,n] | | dst | | |node| | | | | +---------+----+-------------+--------------+--------------+--------+ | Inserted| -- |IP6-IP6(RPI) | -- | -- | -- | | headers | | | | | | +---------+----+-------------+--------------+--------------+--------+ | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | | headers | | | | | | +---------+----+-------------+--------------+--------------+--------+ | Re-added| -- | -- | -- | -- | -- | | headers | | | | | | +---------+----+-------------+--------------+--------------+--------+ | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | | headers | | | | | | +---------+----+-------------+--------------+--------------+--------+ |Untouched| -- | -- | -- | -- | -- | | headers | | | | | | +---------+----+-------------+--------------+--------------+--------+ Figure 17: Non-SM: Summary of the use of headers from RUL to Internet 8.2.4. Non-SM: Example of Flow from Internet to RUL In this case the flow comprises: Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6) For example, a communication flow could be: Internet --> Node A (root) --> Node B --> Node E --> Node G 6LR_i are the intermediate routers from source to destination. In this case, "1 < i <= n", n is the number of routers (6LR) that the packet goes through from 6LBR to RUL (IPv6). The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 6LBR will know the path, and will recognize that the final node is not an RPL capable node as it will have received the connectivity DAO from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 header destination be the last 6LR. The 6LBR will set to zero the flow label upon entry in order to aid compression [RFC8138]. The Figure 18 shows the table that summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 38] Internet-Draft RPL-data-plane July 2019 +---------+--------+-------------+--------------+--------------+-----+ | Header |Internet| 6LBR | 6LR_1 | 6lR_i |IPv6 | | | src | | | (i=2,...,n) |dst | | | | | | |node | +---------+--------+-------------+--------------+--------------+-----+ | Inserted| -- | IPv6-in-IPv6| -- | -- | -- | | headers | | (RH3,RPI) | | | | +---------+--------+-------------+--------------+--------------+-----+ | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | | headers | | | | (RH3,RPI)[1] | | +---------+--------+-------------+--------------+--------------+-----+ | Re-added| -- | -- | -- | -- | -- | | headers | | | | | | +---------+--------+-------------+--------------+--------------+-----+ | Modified| -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | | headers | | | (RH3,RPI) | (RH3,RPI) | | +---------+--------+-------------+--------------+--------------+-----+ |Untouched| -- | -- | -- | -- | -- | | headers | | | | | | +---------+--------+-------------+--------------+--------------+-----+ Figure 18: Non-SM: Summary of the use of headers from Internet to RUL [1] The last 6LR before the IPv6 node. 8.3. Non-SM: Interaction between Leafs In this section is described the communication flow in Non Storing Mode (Non-SM) between, RAL to RAL RAL to RUL RUL to RAL RUL to RUL 8.3.1. Non-SM: Example of Flow from RAL to RAL In this case the flow comprises: 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst For example, a communication flow could be: Node F --> Node D --> Node B --> Node A (root) --> Node B --> Node E --> Node H Robles, et al. Expires January 5, 2020 [Page 39] Internet-Draft RPL-data-plane July 2019 6LR_ia are the intermediate routers from source to the root In this case, 1 <= ia <= n, n is the number of routers (6LR) that the packet goes through from 6LN to the root. 6LR_id are the intermediate routers from the root to the destination. In this case, "1 <= ia <= m", m is the number of the intermediate routers (6LR). This case involves only nodes in same RPL Domain. The originating node will add a RPI header to the original packet, and send the packet upwards. The originating node must put the RPI into an IPv6-in-IPv6 header addressed to the root, so that the 6LBR can remove that header. If it does not, then additional resources are wasted on the way down to carry the useless RPI option. The 6LBR will need to insert an RH3 header, which requires that it add an IPv6-in-IPv6 header. It should be able to remove the RPI, as it was contained in an IPv6-in-IPv6 header addressed to it. Otherwise, there may be a RPI header buried inside the inner IP header, which should get ignored. Networks that use the RPL P2P extension [RFC6997] are essentially non-storing DODAGs and fall into this scenario or scenario Section 8.1.2, with the originating node acting as 6LBR. The Figure 19 shows the table that summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 40] Internet-Draft RPL-data-plane July 2019 +---------+------------+----------+------------+----------+------------+ | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | | | src | | | | dst | +---------+------------+----------+------------+----------+------------+ | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | | headers | (RPI1) | |(RH3-> 6LN, | | | | | | | RPI2) | | | +---------+------------+----------+------------+----------+------------+ | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| | headers | | | (RPI1) | | (RH3, | | | | | | | RPI2) | +---------+------------+----------+------------+----------+------------+ | Re-added| -- | -- | -- | -- | -- | | headers | | | | | | +---------+------------+----------+------------+----------+------------+ | Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- | | headers | | (RPI1) | | (RPI2) | | +---------+------------+----------+------------+----------+------------+ |Untouched| -- | -- | -- | -- | -- | | headers | | | | | | +---------+------------+----------+------------+----------+------------+ Figure 19: Non-SM: Summary of the use of headers for RAL to RAL. IP6-in-IP6 refers to IPv6-in-IPv6. 8.3.2. Non-SM: Example of Flow from RAL to RUL In this case the flow comprises: 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) For example, a communication flow could be: Node F --> Node D --> Node B --> Node A (root) --> Node B --> Node E --> Node G 6LR_ia are the intermediate routers from source to the root In this case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 6LR_id are the intermediate routers from the root to the destination. In this case, "1 <= ia <= m", m is the number of the intermediate routers (6LRs). As in the previous case, the 6LN will insert a RPI (RPI_1) header which must be in an IPv6-in-IPv6 header addressed to the root so that the 6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. The Figure 20 shows the table that summarizes what headers are needed for this use case. Robles, et al. Expires January 5, 2020 [Page 41] Internet-Draft RPL-data-plane July 2019 +-----------+---------+---------+---------+---------+---------+------+ | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LR_m | IPv6 | | | src | | | | | dst | | | | | | | | node | +-----------+---------+---------+---------+---------+---------+------+ | Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | | headers | (RPI1) | | (RH3, | | | | | | | | RPI2) | | | | +-----------+---------+---------+---------+---------+---------+------+ | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | | headers | | | (RPI1) | | (RH3, | | | | | | | | RPI2) | | +-----------+---------+---------+---------+---------+---------+------+ | Re-added | -- | -- | -- | -- | -- | -- | | headers | | | | | | | +-----------+---------+---------+---------+---------+---------+------+ | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | | headers | | (RPI1) | | (RH3, | | | | | | | | RPI2) | | | +-----------+---------+---------+---------+---------+---------+------+ | Untouched | -- | -- | -- | -- | -- | -- | | headers | | | | | | | +-----------+---------+---------+---------+---------+---------+------+ Figure 20: Non-SM: Summary of the use of headers from RAL to RUL. 8.3.3. Non-SM: Example of Flow from RUL to RAL In this case the flow comprises: not-RPL-aware 6LN (IPv6) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN For example, a communication flow could be: Node G --> Node E --> Node B --> Node A (root) --> Node B --> Node E --> Node H 6LR_ia are the intermediate routers from source to the root. In this case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 6LR_id are the intermediate routers from the root to the destination. In this case, "1 <= ia <= m", m is the number of the intermediate routers (6LR). This scenario is mostly identical to the previous one. The RPI is added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header addressed to the root. The 6LBR will remove this RPI, and add it's own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI_2). Robles, et al. Expires January 5, 2020 [Page 42] Internet-Draft RPL-data-plane July 2019 The Figure 21 shows the table that summarizes what headers are needed for this use case. +-----------+------+---------+---------+---------+---------+---------+ | Header | IPv6 | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LN | | | src | | | | | dst | | | node | | | | | | +-----------+------+---------+---------+---------+---------+---------+ | Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | | headers | | (RPI1) | | (RH3, | | | | | | | | RPI2) | | | +-----------+------+---------+---------+---------+---------+---------+ | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | | headers | | | | (RPI1) | | (RH3, | | | | | | | | RPI2) | +-----------+------+---------+---------+---------+---------+---------+ | Re-added | -- | | -- | -- | -- | -- | | headers | | | | | | | +-----------+------+---------+---------+---------+---------+---------+ | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | | headers | | | (RPI1) | | (RH3, | | | | | | | | RPI2) | | +-----------+------+---------+---------+---------+---------+---------+ | Untouched | -- | | -- | -- | -- | -- | | headers | | | | | | | +-----------+------+---------+---------+---------+---------+---------+ Figure 21: Non-SM: Summary of the use of headers from RUL to RAL. 8.3.4. Non-SM: Example of Flow from RUL to RUL In this case the flow comprises: not-RPL-aware 6LN (IPv6 src) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6 dst) For example, a communication flow could be: Node G --> Node E --> Node B --> Node A (root) --> Node C --> Node J 6LR_ia are the intermediate routers from source to the root. In this case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 6LR_id are the intermediate routers from the root to the destination. In this case, "1 <= ia <= m", m is the number of the intermediate routers (6LR). This scenario is the combination of the previous two cases. Robles, et al. Expires January 5, 2020 [Page 43] Internet-Draft RPL-data-plane July 2019 The Figure 22 shows the table that summarizes what headers are needed for this use case. +---------+------+-------+-------+---------+-------+---------+------+ | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | IPv6 | | | src | | | | | | dst | | | node | | | | | | node | +---------+------+-------+-------+---------+-------+---------+------+ | Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | | headers | | (RPI1)| | (RH3, | | | | | | | | | RPI2) | | | | +---------+------+-------+-------+---------+-------+---------+------+ | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | | headers | | | | (RPI1) | | (RH3, | | | | | | | | | RPI2) | | +---------+------+-------+-------+---------+-------+---------+------+ | Re-added| -- | -- | -- | -- | -- | -- | -- | | headers | | | | | | | | +---------+------+-------+-------+---------+-------+---------+------+ | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | | headers | | | (RPI1)| | (RH3, | | | | | | | | | RPI2)| | | +---------+------+-------+-------+---------+-------+---------+------+ |Untouched| -- | -- | -- | -- | -- | -- | -- | | headers | | | | | | | | +---------+------+-------+-------+---------+-------+---------+------+ Figure 22: Non-SM: Summary of the use of headers from RUL to RUL 9. Operational Considerations of supporting not-RPL-aware-leaves Roughly half of the situations described in this document involve leaf ("host") nodes that do not speak RPL. These nodes fall into two further categories: ones that drop a packet that have RPI or RH3 headers, and ones that continue to process a packet that has RPI and/ or RH3 headers. [RFC8200] provides for new rules that suggest that nodes that have not been configured (explicitly) to examine Hop-by-Hop headers, should ignore those headers, and continue processing the packet. Despite this, and despite the switch from 0x63 to 0x23, there may be hosts that are pre-RFC8200, or simply intolerant. Those hosts will drop packets that continue to have RPL artifacts in them. In general, such hosts can not be easily supported in RPL LLNs. There are some specific cases where it is possible to remove the RPL artifacts prior to forwarding the packet to the leaf host. The critical thing is that the artifacts have been inserted by the RPL Robles, et al. Expires January 5, 2020 [Page 44] Internet-Draft RPL-data-plane July 2019 root inside an IPv6-in-IPv6 header, and that the header has been addressed to the 6LR immediately prior to the leaf node. In that case, in the process of removing the IPv6-in-IPv6 header, the artifacts can also be removed. The above case occurs whenever traffic originates from the outside the LLN (the "Internet" cases above), and non-storing mode is used. In non-storing mode, the RPL root knows the exact topology (as it must be create the RH3 header), and therefore knows what the 6LR prior to the leaf. For example, in Figure 5, node E is the 6LR prior to the leaf node G, or node C is the 6LR prior to the leaf node J. traffic originating from the RPL root (such as when the data collection system is co-located on the RPL root), does not require an IPv6-in-IPv6 header (in either mode), as the packet is originating at the root, and the root can insert the RPI and RH3 headers directly into the packet, as it is formed. Such a packet is slightly smaller, but only can be sent to nodes (whether RPL aware or not), that will tolerate the RPL artifacts. An operator that finds itself with a lot of traffic from the RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation if the leaf is not tolerant of the RPL artifacts. Such an operator could otherwise omit this unnecessary header if it was certain of the properties of the leaf. As storing mode can not know the final path of the traffic, intolerant (that drop packets with RPL artifacts) leaf nodes can not be supported. 10. Operational considerations of introducing 0x23 This section describes the operational considerations of introducing the new RPI value of 0x23. During bootstrapping the node gets the DIO with the information of RPL Option Type, indicating the new RPI in the DODAG Configuration Option Flag. The DODAG root is in charge to configure the current network to the new value, through DIO messages and when all the nodes are set with the new value. The DODAG should change to a new DODAG version. In case of rebooting, the node does not remember the RPL Option Type. Thus, the DIO is sent with a flag indicating the new RPI value. The DODAG Configuration option is contained in a RPL DIO message, which contains a unique DTSN counter. The leaf nodes respond to this message with DAO messages containing the same DTSN. This is a normal Robles, et al. Expires January 5, 2020 [Page 45] Internet-Draft RPL-data-plane July 2019 part of RPL routing; the RPL root therefore knows when the updated DODAG Configuration Option has been seen by all nodes. Before the migration happens, all the RPL-aware nodes should support both values . The migration procedure it is triggered when the DIO is sent with the flag indicating the new RPI value. Namely, it remains at 0x63 until it is sure that the network is capable of 0x23, then it abruptly change to 0x23. This options allows to send packets to not-RPL nodes, which should ignore the option and continue processing the packets. In case that a node join to a network that only process 0x63, it would produce a flag day as was mentioned previously. Indicating the new RPI in the DODAG Configuration Option Flag is a way to avoid the flag day in a network. It is recommended that a network process both options to enable interoperability. 11. IANA Considerations This document updates the registration made in [RFC6553] Destination Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in Figure 23. +-------+-------------------+------------------------+---------- -+ | Hex | Binary Value | Description | Reference | + Value +-------------------+ + + | | act | chg | rest | | | +-------+-----+-----+-------+------------------------+------------+ | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| +-------+-----+-----+-------+------------------------+------------+ | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | | | | | | |[RFCXXXX](*)| +-------+-----+-----+-------+------------------------+------------+ Figure 23: Option Type in RPL Option.(*)represents this document DODAG Configuration option is updated as follows (Figure 24): +------------+-----------------+---------------+ | Bit number | Description | Reference | +------------+-----------------+---------------+ | 3 | RPI 0x23 enable | This document | +------------+-----------------+---------------+ Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- day. Robles, et al. Expires January 5, 2020 [Page 46] Internet-Draft RPL-data-plane July 2019 12. Security Considerations The security considerations covered in [RFC6553] and [RFC6554] apply when the packets are in the RPL Domain. The IPv6-in-IPv6 mechanism described in this document is much more limited than the general mechanism described in [RFC2473]. The willingness of each node in the LLN to decapsulate packets and forward them could be exploited by nodes to disguise the origin of an attack. While a typical LLN may be a very poor origin for attack traffic (as the networks tend to be very slow, and the nodes often have very low duty cycles) given enough nodes, they could still have a significant impact, particularly if attack is targeting another LLN. Additionally, some uses of RPL involve large backbone ISP scale equipment [I-D.ietf-anima-autonomic-control-plane], which may be equipped with multiple 100Gb/s interfaces. Blocking or careful filtering of IPv6-in-IPv6 traffic entering the LLN as described above will make sure that any attack that is mounted must originate from compromised nodes within the LLN. The use of BCP38 [BCP38] filtering at the RPL root on egress traffic will both alert the operator to the existence of the attack, as well as drop the attack traffic. As the RPL network is typically numbered from a single prefix, which is itself assigned by RPL, BCP38 filtering involves a single prefix comparison and should be trivial to automatically configure. There are some scenarios where IPv6-in-IPv6 traffic should be allowed to pass through the RPL root, such as the IPv6-in-IPv6 mediated communications between a new Pledge and the Join Registrar/ Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the RPL root to do careful filtering: it occurs only when the Join Coordinator is not co-located inside the RPL root. With the above precautions, an attack using IPv6-in-IPv6 tunnels can only be by a node within the LLN on another node within the LLN. Such an attack could, of course, be done directly. An attack of this kind is meaningful only if the source addresses are either fake or if the point is to amplify return traffic. Such an attack, could also be done without the use of IPv6-in-IPv6 headers using forged source addresses. If the attack requires bi-directional communication, then IPv6-in-IPv6 provides no advantages. Whenever IPv6-in-IPv6 headers are being proposed, there is a concern about creating security issues. In the security section of Robles, et al. Expires January 5, 2020 [Page 47] Internet-Draft RPL-data-plane July 2019 [RFC2473], it was suggested that tunnel entry and exit points can be secured, via "Use IPsec". This recommendation is not practical for RPL networks. [RFC5406] goes into some detail on what additional details would be needed in order to "Use IPsec". Use of ESP would prevent RFC8183 compression (compression must occur before encryption), and RFC8183 compression is lossy in a way that prevents use of AH. These are minor issues. The major issue is how to establish trust enough such that IKEv2 could be used. This would require a system of certificates to be present in every single node, including any Internet nodes that might need to communicate with the LLN. Thus, "Use IPsec" requires a global PKI in the general case. More significantly, the use of IPsec tunnels to protect the IPv6-in- IPv6 headers would in the general case scale with the square of the number of nodes. This is a lot of resource for a constrained nodes on a constrained network. In the end, the IPsec tunnels would be providing only BCP38-like origin authentication! That is, IPsec provides a transitive guarantee to the tunnel exit point that the tunnel entry point did BCP38 on traffic going in. Just doing BCP38 origin filtering at the entry and exit of the LLN provides a similar level amount of security without all the scaling and trust problems of using IPsec as RFC2473 suggested. IPsec is not recommended. An LLN with hostile nodes within it would not be protected against impersonation with the LLN by entry/exit filtering. The RH3 header usage described here can be abused in equivalent ways (to disguise the origin of traffic and attack other nodes) with an IPv6-in-IPv6 header to add the needed RH3 header. As such, the attacker's RH3 header will not be seen by the network until it reaches the end host, which will decapsulate it. An end-host should be suspicious about a RH3 header which has additional hops which have not yet been processed, and SHOULD ignore such a second RH3 header. In addition, the LLN will likely use [RFC8138] to compress the IPv6- in-IPv6 and RH3 headers. As such, the compressor at the RPL-root will see the second RH3 header and MAY choose to discard the packet if the RH3 header has not been completely consumed. A consumed (inert) RH3 header could be present in a packet that flows from one LLN, crosses the Internet, and enters another LLN. As per the discussion in this document, such headers do not need to be removed. However, there is no case described in this document where an RH3 is inserted in a non-storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation. It should just be noted that an incoming RH3 must be fully consumed, or very carefully inspected. Robles, et al. Expires January 5, 2020 [Page 48] Internet-Draft RPL-data-plane July 2019 The RPI header, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different RPLInstanceID, perhaps one with a higher energy cost, for instance. It could also be that not all nodes are reachable in an LLN using the default instanceID, but a change of instanceID would permit an attacker to bypass such filtering. Like the RH3, a RPI header is to be inserted by the RPL root on traffic entering the LLN by first inserting an IPv6-in-IPv6 header. The attacker's RPI header therefore will not be seen by the network. Upon reaching the destination node the RPI header has no further meaning and is just skipped; the presence of a second RPI header will have no meaning to the end node as the packet has already been identified as being at it's final destination. The RH3 and RPI headers could be abused by an attacker inside of the network to route packets on non-obvious ways, perhaps eluding observation. This usage is in fact part of [RFC6997] and can not be restricted at all. This is a feature, not a bug. [RFC7416] deals with many other threats to LLNs not directly related to the use of IPv6-in-IPv6 headers, and this document does not change that analysis. Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an attack on another part of the LLN, while disguising the origin of the attack. The mechanism can even be abused to make it appear that the attack is coming from outside the LLN, and unless countered, this could be used to mount a Distributed Denial Of Service attack upon nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of such attacks already seen in the real world. If an attack comes from inside of LLN, it can be alleviated with SAVI (Source Address Validation Improvement) using [RFC8505] with [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source traffic with an address that is not registered, and the registration process checks for topological correctness. Notice that there is an L2 authentication in most of the cases. If an attack comes from outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, but by construction, the RH3 can typically only address nodes within the LLN. That is, a RH3 with a CmprI less than 8 , should be considered an attack (see RFC6554, section 3). Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic through the RPL root to perform this attack. To counter, the RPL root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the simpler solution), or it SHOULD walk the IP header extension chain until it can inspect the upper-layer-payload as described in [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing Robles, et al. Expires January 5, 2020 [Page 49] Internet-Draft RPL-data-plane July 2019 on the source addresses of all IP headers that it examines in both directions. Note: there are some situations where a prefix will spread across multiple LLNs via mechanisms such as the one described in [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering needs to take this into account, either by exchanging detailed routing information on each LLN, or by moving the BCP38 filtering further towards the Internet, so that the details of the multiple LLNs do not matter. 13. Acknowledgments This work is done thanks to the grant by the Stand.ICT project. A special BIG thanks to C. M. Heard for the help with the Section 4. Much of the redaction in that section is based on his comments. Additionally, the authors would like to acknowledge the review, feedback, and comments of (alphabetical order): Robert Cragie, Simon Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 14. References 14.1. Normative References [BCP38] 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [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, . Robles, et al. Expires January 5, 2020 [Page 50] Internet-Draft RPL-data-plane July 2019 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, . [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, . [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, . [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, . [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 14.2. Informative References Robles, et al. Expires January 5, 2020 [Page 51] Internet-Draft RPL-data-plane July 2019 [DDOS-KREBS] Goodin, D., "Record-breaking DDoS reportedly delivered by >145k hacked cameras", September 2016, . [I-D.ietf-6lo-ap-nd] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, "Address Protected Neighbor Discovery for Low-power and Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in progress), April 2019. [I-D.ietf-6lo-backbone-router] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Backbone Router", draft-ietf-6lo-backbone-router-11 (work in progress), February 2019. [I-D.ietf-6tisch-dtsecurity-secure-join] Richardson, M., "6tisch Secure Join protocol", draft-ietf- 6tisch-dtsecurity-secure-join-01 (work in progress), February 2017. [I-D.ietf-anima-autonomic-control-plane] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", draft-ietf-anima-autonomic-control- plane-19 (work in progress), March 2019. [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-22 (work in progress), June 2019. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-09 (work in progress), July 2018. [I-D.thubert-roll-unaware-leaves] Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- unaware-leaves-07 (work in progress), April 2019. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . Robles, et al. Expires January 5, 2020 [Page 52] Internet-Draft RPL-data-plane July 2019 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, February 2009, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 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, . [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, DOI 10.17487/RFC6997, August 2013, . [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, . [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, . [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, . Robles, et al. Expires January 5, 2020 [Page 53] Internet-Draft RPL-data-plane July 2019 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, . Authors' Addresses Maria Ines Robles Aalto University Otaniemi Espoo 02150 Finland Email: mariainesrobles@gmail.com Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/mcr/ Pascal Thubert Cisco Systems, Inc Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 France Email: pthubert@cisco.com Robles, et al. Expires January 5, 2020 [Page 54] ./draft-ietf-netconf-restconf-notif-15.txt0000644000764400076440000015051213500163026017750 0ustar iustyiusty NETCONF E. Voit Internet-Draft R. Rahman Intended status: Standards Track E. Nilsen-Nygaard Expires: December 13, 2019 Cisco Systems A. Clemm Huawei A. Bierman YumaWorks June 11, 2019 Dynamic subscription to YANG Events and Datastores over RESTCONF draft-ietf-netconf-restconf-notif-15 Abstract This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. 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 https://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 13, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Voit, et al. Expires December 13, 2019 [Page 1] Internet-Draft RESTCONF-Notif June 2019 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. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 3 3.1. Transport Connectivity . . . . . . . . . . . . . . . . . 4 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. RESTCONF RPCs and HTTP Status Codes . . . . . . . . . . . 4 3.4. Call Flow for Server-Sent Events . . . . . . . . . . . . 7 4. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Notification Messages . . . . . . . . . . . . . . . . . . . . 10 6. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 A.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 16 A.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 16 A.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 19 A.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 21 A.2. Subscription State Notifications . . . . . . . . . . . . 21 A.2.1. subscription-modified . . . . . . . . . . . . . . . . 22 A.2.2. subscription-completed, subscription-resumed, and replay-complete . . . . . . . . . . . . . . . . . . . 22 A.2.3. subscription-terminated and subscription-suspended . 22 A.3. Filter Example . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Changes between revisions . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Mechanisms to support event subscription and push are defined in [I-D.draft-ietf-netconf-subscribed-notifications]. Enhancements to [I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG datastore subscription and push are defined in [I-D.ietf-netconf-yang-push]. This document provides a transport specification for dynamic subscriptions over RESTCONF [RFC8040]. Requirements for these mechanisms are captured in [RFC7923]. Voit, et al. Expires December 13, 2019 [Page 2] Internet-Draft RESTCONF-Notif June 2019 The streaming of notifications encapsulating the resulting information push is done via the mechanism described in section 6.3 of [RFC8040]. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms use the definitions from [I-D.draft-ietf-netconf-subscribed-notifications]: dynamic subscription, event stream, notification message, publisher, receiver, subscriber, and subscription. Other terms reused include datastore, which is defined in [RFC8342], and HTTP2 stream which maps to the definition of "stream" within [RFC7540], Section 2. [ note to the RFC Editor - please replace XXXX within this document with the number of this document ] 3. Dynamic Subscriptions This section provides specifics on how to establish and maintain dynamic subscriptions over RESTCONF [RFC8040]. Subscribing to event streams is accomplished in this way via RPCs defined within [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4. The RPCs are done via RESTCONF POSTs. YANG datastore subscription is accomplished via augmentations to [I-D.draft-ietf-netconf-subscribed-notifications] as described within [I-D.ietf-netconf-yang-push] Section 4.4. As described in [RFC8040] Section 6.3, a GET needs to be made against a specific URI on the publisher. Subscribers cannot pre-determine the URI against which a subscription might exist on a publisher, as the URI will only exist after the "establish-subscription" RPC has been accepted. Therefore, the POST for the "establish-subscription" RPC replaces the GET request for the "location" leaf which is used in [RFC8040] to obtain the URI. The subscription URI will be determined and sent as part of the response to the "establish-subscription" RPC, and a subsequent GET to this URI will be done in order to start the flow of notification messages back to the subscriber. A subscription does not move to the active state as per Section 2.4.1. of [I-D.draft-ietf-netconf-subscribed-notifications] until the GET is received. Voit, et al. Expires December 13, 2019 [Page 3] Internet-Draft RESTCONF-Notif June 2019 3.1. Transport Connectivity For a dynamic subscription, where a RESTCONF session doesn't already exist, a new RESTCONF session is initiated from the subscriber. As stated in Section 2.1 of [RFC8040], a subscriber MUST establish the HTTP session over TLS [RFC8446] in order to secure the content in transit. Without the involvement of additional protocols, HTTP sessions by themselves do not allow for a quick recognition of when the communication path has been lost with the publisher. Where quick recognition of the loss of a publisher is required, a subscriber SHOULD use a TLS heartbeat [RFC6520], just from subscriber to publisher, to track HTTP session continuity. Loss of the heartbeat MUST result in any subscription related TCP sessions between those endpoints being torn down. A subscriber can then attempt to re-establish the dynamic subscription by using the procedure described in Section 3.4. 3.2. Discovery Subscribers can learn what event streams a RESTCONF server supports by querying the "streams" container of ietf-subscribed- notification.yang in [I-D.draft-ietf-netconf-subscribed-notifications]. Support for the "streams" container of ietf-restconf-monitoring.yang in [RFC8040] is not required. In the case when the RESTCONF binding specified by this document is used to convey the "streams" container from ietf- restconf-monitoring.yang (i.e., that feature is supported), any event streams contained therein are also expected to be present in the "streams" container of ietf-restconf-monitoring.yang. Subscribers can learn what datastores a RESTCONF server supports by following Section 2 of [I-D.draft-ietf-netconf-nmda-restconf]. 3.3. RESTCONF RPCs and HTTP Status Codes Specific HTTP responses codes as defined in [RFC7231] section 6 will indicate the result of RESTCONF RPC requests with the publisher. An HTTP status code of 200 is the proper response to any successful RPC defined within [I-D.draft-ietf-netconf-subscribed-notifications] or [I-D.ietf-netconf-yang-push]. If a publisher fails to serve the RPC request for one of the reasons indicated in [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4.6 or [I-D.ietf-netconf-yang-push] Appendix A, this will Voit, et al. Expires December 13, 2019 [Page 4] Internet-Draft RESTCONF-Notif June 2019 be indicated by an appropriate error code, as shown below, transported in the HTTP response. When an HTTP error code is returned, the RPC reply MUST include an "rpc-error" element per [RFC8040] Section 7.1 with the following parameter values: o an "error-type" node of "application". o an "error-tag" node with the value being a string that corresponds to an identity associated with the error. This "error-tag" will come from one of two places. Either it will correspond to the error identities within [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 for general subscription errors: error identity uses error-tag HTTP Code ---------------------- -------------- --------- dscp-unavailable invalid-value 400 encoding-unsupported invalid-value 400 filter-unsupported invalid-value 400 insufficient-resources resource-denied 409 no-such-subscription invalid-value 404 replay-unsupported operation-not-supported 501 Or this "error-tag" will correspond to the error identities within [I-D.ietf-netconf-yang-push] Appendix A.1 for subscription errors specific to YANG datastores: error identity uses error-tag HTTP Code ---------------------- -------------- --------- cant-exclude operation-not-supported 501 datastore-not-subscribable invalid-value 400 no-such-subscription-resync invalid-value 404 on-change-unsupported operation-not-supported 501 on-change-sync-unsupported operation-not-supported 501 period-unsupported invalid-value 400 update-too-big too-big 400 sync-too-big too-big 400 unchanging-selection operation-failed 500 o an "error-app-tag" node with the value being a string that corresponds to an identity associated with the error, as defined in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 for general subscriptions, and [I-D.ietf-netconf-yang-push] Appendix A.1, for datastore subscriptions. The tag to use depends on the RPC for which the error occurred. Viable errors for different RPCs are as follows: Voit, et al. Expires December 13, 2019 [Page 5] Internet-Draft RESTCONF-Notif June 2019 RPC select an identity with a base ---------------------- ------------------------------ establish-subscription establish-subscription-error modify-subscription modify-subscription-error delete-subscription delete-subscription-error kill-subscription delete-subscription-error resync-subscription resync-subscription-error Each error identity will be inserted as the "error-app-tag" using JSON encoding following the form :. An example of such a valid encoding would be "ietf-subscribed- notifications:no-such-subscription". In case of error responses to an "establish-subscription" or "modify- subscription" request there is the option of including an "error- info" node. This node may contain hints for parameter settings that might lead to successful RPC requests in the future. Following are the yang-data structures which may be returned: establish-subscription returns hints in yang-data structure ---------------------- ------------------------------------ target: event stream establish-subscription-stream-error-info target: datastore establish-subscription-datastore-error-info modify-subscription returns hints in yang-data structure ---------------------- ------------------------------------ target: event stream modify-subscription-stream-error-info target: datastore modify-subscription-datastore-error-info The yang-data included within "error-info" SHOULD NOT include the optional leaf "reason", as such a leaf would be redundant with information that is already placed within the "error-app-tag". In case of an rpc error as a result of a "delete-subscription", a "kill-subscription", or a "resync-subscription" request, no "error-info" needs to be included, as the "subscription-id" is the only RPC input parameter and no hints regarding this RPC input parameters need to be provided. Note that "error-path" [RFC8040] does not need to be included with the "rpc-error" element, as subscription errors are generally associated with the choice of RPC input parameters. Voit, et al. Expires December 13, 2019 [Page 6] Internet-Draft RESTCONF-Notif June 2019 3.4. Call Flow for Server-Sent Events The call flow for Server-Sent Events (SSE) is defined in Figure 1. The logical connections denoted by (a) and (b) can be a TCP connection or an HTTP2 stream (if HTTP2 is used, multiple HTTP2 streams can be carried in one TCP connection). Requests to [I-D.draft-ietf-netconf-subscribed-notifications] or [I-D.ietf-netconf-yang-push] augmented RPCs are sent on a connection indicated by (a). A successful "establish-subscription" will result in an RPC response returned with both a subscription identifier which uniquely identifies a subscription, as well as a URI which uniquely identifies the location of subscription on the publisher (b). This URI is defined via the "uri" leaf the Data Model in Section 7. An HTTP GET is then sent on a separate logical connection (b) to the URI on the publisher. This signals the publisher to initiate the flow of notification messages which are sent in SSE [W3C-20150203] as a response to the GET. There cannot be two or more simultaneous GET requests on a subscription URI: any GET request received while there is a current GET request on the same URI MUST be rejected with HTTP error code 409. As described in [RFC8040] Section 6.4, RESTCONF servers SHOULD NOT send the "event" or "id" fields in the SSE event notifications. Voit, et al. Expires December 13, 2019 [Page 7] Internet-Draft RESTCONF-Notif June 2019 +--------------+ +--------------+ | Subscriber | | Publisher | | | | | | Logical | | Logical | | Connection | | Connection | | (a) (b) | | (a) (b) | +--------------+ +--------------+ | RESTCONF POST (RPC:establish-subscription) | |--------------------------------------------->| | HTTP 200 OK (ID,URI)| |<---------------------------------------------| | |HTTP GET (URI) | | |--------------------------------------------->| | | HTTP 200 OK| | |<---------------------------------------------| | | SSE (notif-message)| | |<---------------------------------------------| | RESTCONF POST (RPC:modify-subscription) | | |--------------------------------------------->| | | | HTTP 200 OK| | |<---------------------------------------------| | | | SSE (subscription-modified)| | |<------------------------------------------(c)| | | SSE (notif-message)| | |<---------------------------------------------| | RESTCONF POST (RPC:delete-subscription) | | |--------------------------------------------->| | | | HTTP 200 OK| | |<---------------------------------------------| | | | | | | | | | (a) (b) (a) (b) Figure 1: Dynamic with server-sent events Additional requirements for dynamic subscriptions over SSE include: o All subscription state notifications from a publisher MUST be returned in a separate SSE message used by the subscription to which the state change refers. o Subscription RPCs MUST NOT use the connection currently providing notification messages for that subscription. o In addition to an RPC response for a "modify-subscription" RPC traveling over (a), a "subscription-modified" state change notification MUST be sent within (b). This allows the receiver to know exactly when, within the stream of events, the new terms of Voit, et al. Expires December 13, 2019 [Page 8] Internet-Draft RESTCONF-Notif June 2019 the subscription have been applied to the notification messages. See arrow (c). o In addition to any required access permissions (e.g., NACM), RPCs modify-subscription, resync-subscription and delete-subscription SHOULD only be allowed by the same RESTCONF username [RFC8040] which invoked establish-subscription. Such a restriction generally serves to preserve users' privacy, but exceptions might be made for administrators that may need to modify or delete other users' subscriptions. o The kill-subscription RPC can be invoked by any RESTCONF username with the required administrative permissions. A publisher MUST terminate a subscription in the following cases: o Receipt of a "delete-subscription" or a "kill-subscription" RPC for that subscription. o Loss of TLS heartbeat A publisher MAY terminate a subscription at any time as stated in [I-D.draft-ietf-netconf-subscribed-notifications] Section 1.3 4. QoS Treatment Qos treatment for event streams is described in [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.3. In addition, if HTTP2 is used, the publisher MUST: o take the "weighting" leaf node in [I-D.draft-ietf-netconf-subscribed-notifications], and copy it into the HTTP2 stream weight, [RFC7540] section 5.3, and o take any existing subscription "dependency", as specified by the "dependency" leaf node in [I-D.draft-ietf-netconf-subscribed-notifications], and use the HTTP2 stream for the parent subscription as the HTTP2 stream dependency, [RFC7540] section 5.3.1, of the dependent subscription. o set the exclusive flag, [RFC7540] section 5.3.1, to 0. For dynamic subscriptions with the same DSCP value to a specific publisher, it is recommended that the subscriber sends all URI GET requests on a common HTTP2 session (if HTTP2 is used). Conversely, a subscriber can not use a common HTTP2 session for subscriptions with different DSCP values. Voit, et al. Expires December 13, 2019 [Page 9] Internet-Draft RESTCONF-Notif June 2019 5. Notification Messages Notification messages transported over RESTCONF will be encoded according to [RFC8040], section 6.4. 6. YANG Tree The YANG model defined in Section 7 has one leaf augmented into three places of [I-D.draft-ietf-netconf-subscribed-notifications]. module: ietf-restconf-subscribed-notifications augment /sn:establish-subscription/sn:output: +--ro uri? inet:uri augment /sn:subscriptions/sn:subscription: +--ro uri? inet:uri augment /sn:subscription-modified: +--ro uri? inet:uri 7. YANG module This module references [I-D.draft-ietf-netconf-subscribed-notifications]. file "ietf-restconf-subscribed-notifications@2019-01-11.yang" module ietf-restconf-subscribed-notifications { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:" + "ietf-restconf-subscribed-notifications"; prefix rsn; import ietf-subscribed-notifications { prefix sn; } import ietf-inet-types { prefix inet; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Editor: Eric Voit Voit, et al. Expires December 13, 2019 [Page 10] Internet-Draft RESTCONF-Notif June 2019 Editor: Alexander Clemm Editor: Reshad Rahman "; description "Defines RESTCONF as a supported transport for subscribed event notifications. Copyright (c) 2019 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 (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2019-01-11 { description "Initial version"; reference "RFC XXXX: RESTCONF Transport for Event Notifications"; } grouping uri { description "Provides a reusable description of a URI."; leaf uri { type inet:uri; config false; description "Location of a subscription specific URI on the publisher."; } } augment "/sn:establish-subscription/sn:output" { description "This augmentation allows RESTCONF specific parameters for a response to a publisher's subscription request."; uses uri; } augment "/sn:subscriptions/sn:subscription" { Voit, et al. Expires December 13, 2019 [Page 11] Internet-Draft RESTCONF-Notif June 2019 description "This augmentation allows RESTCONF specific parameters to be exposed for a subscription."; uses uri; } augment "/sn:subscription-modified" { description "This augmentation allows RESTCONF specific parameters to be included as part of the notification that a subscription has been modified."; uses uri; } } 8. IANA Considerations This document registers the following namespace URI in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed- notifications Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following YANG module in the "YANG Module Names" registry [RFC6020]: Name: ietf-restconf-subscribed-notifications Namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed- notifications Prefix: rsn Reference: RFC XXXX: RESTCONF Transport for Event Notifications 9. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management transports such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The one new data node introduced in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, Voit, et al. Expires December 13, 2019 [Page 12] Internet-Draft RESTCONF-Notif June 2019 or notification) to this data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: Container: "/subscriptions" o "uri": leaf will show where subscribed resources might be located on a publisher. Access control must be set so that only someone with proper access permissions, i.e., the same RESTCONF [RFC8040] user credentials which invoked the corresponding "establish- subscription", has the ability to access this resource. The subscription URI is implementation specific and is encrypted via the use of TLS. Therefore, even if an attacker succeeds in guessing the subscription URI, a RESTCONF username [RFC8040] with the required administrative permissions must be used to be able to access or modify that subscription. It is recommended that the subscription URI values not be easily predictable. The access permission considerations for the RPCs modify- subscription, resync-subscription, delete-subscription and kill- subscription are described in Section 3.4. If a buggy or compromised RESTCONF subscriber sends a number of "establish-subscription" requests, then these subscriptions accumulate and may use up system resources. In such a situation, the publisher MAY also suspend or terminate a subset of the active subscriptions from that RESTCONF subscriber in order to reclaim resources and preserve normal operation for the other subscriptions. 10. Acknowledgments We wish to acknowledge the helpful contributions, comments, and suggestions that were received from: Ambika Prasad Tripathy, Alberto Gonzalez Prieto, Susan Hares, Tim Jenkins, Balazs Lengyel, Kent Watsen, Michael Scharf, Guangying Zheng, Martin Bjorklund, Qin Wu and Robert Wilton. 11. References 11.1. Normative References [I-D.draft-ietf-netconf-subscribed-notifications] Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A., and E. Nilsen-Nygaard, "Custom Subscription to Event Streams", draft-ietf-netconf-subscribed-notifications-21 (work in progress), January 2019. Voit, et al. Expires December 13, 2019 [Page 13] Internet-Draft RESTCONF-Notif June 2019 [I-D.ietf-netconf-yang-push] Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to YANG datastore push updates", draft-ietf- netconf-yang-push-20 (work in progress), October 2018, . [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, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [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, . [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, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Voit, et al. Expires December 13, 2019 [Page 14] Internet-Draft RESTCONF-Notif June 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [W3C-20150203] Hickson, I., "Server-Sent Events, World Wide Web Consortium CR CR-eventsource-20121211", February 2015, . 11.2. Informative References [I-D.draft-ietf-netconf-netconf-event-notifications] Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., Nilsen-Nygaard, E., and A. Tripathy, "NETCONF support for event notifications", May 2018, . [I-D.draft-ietf-netconf-nmda-restconf] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "RESTCONF Extensions to Support the Network Management Datastore Architecture", April 2018, . [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, . [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements for Subscription to YANG Datastores", RFC 7923, DOI 10.17487/RFC7923, June 2016, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . Voit, et al. Expires December 13, 2019 [Page 15] Internet-Draft RESTCONF-Notif June 2019 [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. Zhang, "A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)", RFC 8347, DOI 10.17487/RFC8347, March 2018, . [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", November 1999, . Appendix A. Examples This section is non-normative. To allow easy comparison, this section mirrors the functional examples shown with NETCONF over XML within [I-D.draft-ietf-netconf-netconf-event-notifications]. In addition, HTTP2 vs HTTP1.1 headers are not shown as the contents of the JSON encoded objects are identical within. The subscription URI values used in the examples in this section are purely illustrative, and are not indicative of the expected usage which is described in Section 9. The DSCP values are only for example purposes and are all indicated in decimal since the encoding is JSON [RFC7951]. A.1. Dynamic Subscriptions A.1.1. Establishing Dynamic Subscriptions The following figure shows two successful "establish-subscription" RPC requests as per [I-D.draft-ietf-netconf-subscribed-notifications]. The first request is given a subscription identifier of 22, the second, an identifier of 23. Voit, et al. Expires December 13, 2019 [Page 16] Internet-Draft RESTCONF-Notif June 2019 +------------+ +-----------+ | Subscriber | | Publisher | +------------+ +-----------+ | | |establish-subscription | |------------------------------>| (a) | HTTP 200 OK, id#22, URI#1 | |<------------------------------| (b) |GET (URI#1) | |------------------------------>| (c) | HTTP 200 OK,notif-mesg (id#22)| |<------------------------------| | | | | |establish-subscription | |------------------------------>| | HTTP 200 OK, id#23, URI#2| |<------------------------------| |GET (URI#2) | |------------------------------>| | | | | | notif-mesg (id#22)| |<------------------------------| | HTTP 200 OK,notif-mesg (id#23)| |<------------------------------| | | Figure 2: Multiple subscriptions over RESTCONF/HTTP To provide examples of the information being transported, example messages for interactions in Figure 2 are detailed below: POST /restconf/operations /ietf-subscribed-notifications:establish-subscription { "ietf-subscribed-notifications:input": { "stream-xpath-filter": "/example-module:foo/", "stream": "NETCONF", "dscp": 10 } } Figure 3: establish-subscription request (a) Voit, et al. Expires December 13, 2019 [Page 17] Internet-Draft RESTCONF-Notif June 2019 As publisher was able to fully satisfy the request, the publisher sends the subscription identifier of the accepted subscription, and the URI: HTTP status code - 200 { "id": 22, "uri": "https://example.com/restconf/subscriptions/22" } Figure 4: establish-subscription success (b) Upon receipt of the successful response, the subscriber does a GET the provided URI to start the flow of notification messages. When the publisher receives this, the subscription is moved to the active state (c). GET /restconf/subscriptions/22 Figure 5: establish-subscription subsequent POST While not shown in Figure 2, if the publisher had not been able to fully satisfy the request, or subscriber has no authorization to establish the subscription, the publisher would have sent an RPC error response. For instance, if the "dscp" value of 10 asserted by the subscriber in Figure 3 proved unacceptable, the publisher may have returned: HTTP status code - 400 { "ietf-restconf:errors" : { "error" : [ { "error-type": "application", "error-tag": "invalid-value", "error-severity": "error", "error-app-tag": "ietf-subscribed-notifications:dscp-unavailable" } ] } } Figure 6: an unsuccessful establish subscription Voit, et al. Expires December 13, 2019 [Page 18] Internet-Draft RESTCONF-Notif June 2019 The subscriber can use this information in future attempts to establish a subscription. A.1.2. Modifying Dynamic Subscriptions An existing subscription may be modified. The following exchange shows a negotiation of such a modification via several exchanges between a subscriber and a publisher. This negotiation consists of a failed RPC modification request/response, followed by a successful one. +------------+ +-----------+ | Subscriber | | Publisher | +------------+ +-----------+ | | | notification message (id#23)| |<-----------------------------| | | |modify-subscription (id#23) | |----------------------------->| (d) | HTTP 400 error (with hint)| |<-----------------------------| (e) | | |modify-subscription (id#23) | |----------------------------->| | HTTP 200 OK | |<-----------------------------| | | | notif-mesg (id#23)| |<-----------------------------| | | Figure 7: Interaction model for successful subscription modification If the subscription being modified in Figure 7 is a datastore subscription as per [I-D.ietf-netconf-yang-push], the modification request made in (d) may look like that shown in Figure 8. As can be seen, the modifications being attempted are the application of a new xpath filter as well as the setting of a new periodic time interval. Voit, et al. Expires December 13, 2019 [Page 19] Internet-Draft RESTCONF-Notif June 2019 POST /restconf/operations /ietf-subscribed-notifications:modify-subscription { "ietf-subscribed-notifications:input": { "id": 23, "ietf-yang-push:datastore-xpath-filter": "/example-module:foo/example-module:bar", "ietf-yang-push:periodic": { "ietf-yang-push:period": 500 } } } Figure 8: Subscription modification request (c) If the publisher can satisfy both changes, the publisher sends a positive result for the RPC. If the publisher cannot satisfy either of the proposed changes, the publisher sends an RPC error response (e). The following is an example RPC error response for (e) which includes a hint. This hint is an alternative time period value which might have resulted in a successful modification: HTTP status code - 400 { "ietf-restconf:errors" : { "error" : [ "error-type": "application", "error-tag": "invalid-value", "error-severity": "error", "error-app-tag": "ietf-yang-push:period-unsupported", "error-info": { "ietf-yang-push": "modify-subscription-datastore-error-info": { "period-hint": 3000 } } ] } } Figure 9: Modify subscription failure with Hint (e) Voit, et al. Expires December 13, 2019 [Page 20] Internet-Draft RESTCONF-Notif June 2019 A.1.3. Deleting Dynamic Subscriptions The following demonstrates deleting a subscription. This subscription may have been to either a stream or a datastore. POST /restconf/operations /ietf-subscribed-notifications:delete-subscription { "delete-subscription": { "id": "22" } } Figure 10: Delete subscription If the publisher can satisfy the request, the publisher replies with success to the RPC request. If the publisher cannot satisfy the request, the publisher sends an error-rpc element indicating the modification didn't work. Figure 11 shows a valid response for existing valid subscription identifier, but that subscription identifier was created on a different transport session: HTTP status code - 404 { "ietf-restconf:errors" : { "error" : [ "error-type": "application", "error-tag": "invalid-value", "error-severity": "error", "error-app-tag": "ietf-subscribed-notifications:no-such-subscription" ] } } Figure 11: Unsuccessful delete subscription A.2. Subscription State Notifications A publisher will send subscription state notifications according to the definitions within [I-D.draft-ietf-netconf-subscribed-notifications]). Voit, et al. Expires December 13, 2019 [Page 21] Internet-Draft RESTCONF-Notif June 2019 A.2.1. subscription-modified A "subscription-modified" encoded in JSON would look like: { "ietf-restconf:notification" : { "eventTime": "2007-09-01T10:00:00Z", "ietf-subscribed-notifications:subscription-modified": { "id": 39, "uri": "https://example.com/restconf/subscriptions/22" "stream-xpath-filter": "/example-module:foo", "stream": { "ietf-netconf-subscribed-notifications" : "NETCONF" } } } } Figure 12: subscription-modified subscription state notification A.2.2. subscription-completed, subscription-resumed, and replay- complete A "subscription-completed" would look like: { "ietf-restconf:notification" : { "eventTime": "2007-09-01T10:00:00Z", "ietf-subscribed-notifications:subscription-completed": { "id": 39, } } } Figure 13: subscription-completed notification in JSON The "subscription-resumed" and "replay-complete" are virtually identical, with "subscription-completed" simply being replaced by "subscription-resumed" and "replay-complete". A.2.3. subscription-terminated and subscription-suspended A "subscription-terminated" would look like: Voit, et al. Expires December 13, 2019 [Page 22] Internet-Draft RESTCONF-Notif June 2019 { "ietf-restconf:notification" : { "eventTime": "2007-09-01T10:00:00Z", "ietf-subscribed-notifications:subscription-terminated": { "id": 39, "error-id": "suspension-timeout" } } } Figure 14: subscription-terminated subscription state notification The "subscription-suspended" is virtually identical, with "subscription-terminated" simply being replaced by "subscription- suspended". A.3. Filter Example This section provides an example which illustrate the method of filtering event record contents. The example is based on the YANG notification "vrrp-protocol-error-event" as defined per the ietf- vrrp.yang module within [RFC8347]. Event records based on this specification which are generated by the publisher might appear as: data: { data: "ietf-restconf:notification" : { data: "eventTime" : "2018-09-14T08:22:33.44Z", data: "ietf-vrrp:vrrp-protocol-error-event" : { data: "protocol-error-reason" : "checksum-error" data: } data: } data: } Figure 15: RFC 8347 (VRRP) - Example Notification Suppose a subscriber wanted to establish a subscription which only passes instances of event records where there is a "checksum-error" as part of a VRRP protocol event. Also assume the publisher places such event records into the NETCONF stream. To get a continuous series of matching event records, the subscriber might request the application of an XPath filter against the NETCONF stream. An "establish-subscription" RPC to meet this objective might be: Voit, et al. Expires December 13, 2019 [Page 23] Internet-Draft RESTCONF-Notif June 2019 POST /restconf/operations /ietf-subscribed-notifications:establish-subscription { "ietf-subscribed-notifications:input": { "stream": "NETCONF", "stream-xpath-filter": "/ietf-vrrp:vrrp-protocol-error-event[ protocol-error-reason='checksum-error']/", } } Figure 16: Establishing a subscription error reason via XPath For more examples of XPath filters, see [XPATH]. Suppose the "establish-subscription" in Figure 16 was accepted. And suppose later a subscriber decided they wanted to broaden this subscription cover to all VRRP protocol events (i.e., not just those with a "checksum error"). The subscriber might attempt to modify the subscription in a way which replaces the XPath filter with a subtree filter which sends all VRRP protocol events to a subscriber. Such a "modify-subscription" RPC might look like: POST /restconf/operations /ietf-subscribed-notifications:modify-subscription { "ietf-subscribed-notifications:input": { "stream": "NETCONF", "stream-subtree-filter": { "/ietf-vrrp:vrrp-protocol-error-event" : {} } } } Figure 17 For more examples of subtree filters, see [RFC6241], section 6.4. Appendix B. Changes between revisions (To be removed by RFC editor prior to publication) v14 - v15 o Addressed review comments from Kent. v13 - v14 Voit, et al. Expires December 13, 2019 [Page 24] Internet-Draft RESTCONF-Notif June 2019 o Addressed review comments from IESG. v12 - v13 o Enhanced "error-tag" values based on SN review. v11 - v12 o Added text in 3.2 for expected behavior when ietf-restconf- monitoring.yang is also supported. o Added section 2 to the reference to draft-ietf-netconf-nmda- restconf. o Replaced kill-subscription-error by delete-subscription-error in section 3.3. o Clarified vertical lines (a) and (b) in Figure 1 of section 3.4 o Section 3.4, 3rd bullet after Figure 1, replaced "must" with "MUST". o Modified text in section 3.4 regarding access to RPCs modify- subscription, resync-subscription, delete-subscription and kill- subscription. o Section 4, first bullet for HTTP2: replaced dscp and priority with weighting and weight. o Section 6, added YANG tree diagram and fixed description of the module. o Section 7, fixed indentation of module description statement. o Section 7, in YANG module changed year in copyright statement to 2019. o Section 8, added text on how server protects access to the subscription URI. o Fixed outdated references and removed unused references. o Fixed the instances of line too long. o Fixed example in Figure 3. v10 - v11 Voit, et al. Expires December 13, 2019 [Page 25] Internet-Draft RESTCONF-Notif June 2019 o Per Kent's request, added name attribute to artwork which need to be extracted v09 - v10 o Fixed typo for resync. o Added text wrt RPC permissions and RESTCONF username. v08 - v09 o Addressed comments received during WGLC. v07 - v08 o Aligned with RESTCONF mechanism. o YANG model: removed augment of subscription-started, added restconf transport. o Tweaked Appendix A.1 to match draft-ietf-netconf-netconf-event- notifications-13. o Added Appendix A.3 for filter example. v06 - v07 o Removed configured subscriptions. o Subscription identifier renamed to id. v05 - v06 o JSON examples updated by Reshad. v04 - v05 o Error mechanisms updated to match embedded RESTCONF mechanisms o Restructured format and sections of document. o Added a YANG data model for HTTP specific parameters. o Mirrored the examples from the NETCONF transport draft to allow easy comparison. v03 - v04 Voit, et al. Expires December 13, 2019 [Page 26] Internet-Draft RESTCONF-Notif June 2019 o Draft not fully synched to new version of subscribed-notifications yet. o References updated v02 - v03 o Event notification reframed to notification message. o Tweaks to wording/capitalization/format. v01 - v02 o Removed sections now redundant with [I-D.draft-ietf-netconf-subscribed-notifications] and [I-D.ietf-netconf-yang-push] such as: mechanisms for subscription maintenance, terminology definitions, stream discovery. o 3rd party subscriptions are out-of-scope. o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions o Timeframes for event tagging are self-defined. o Clean-up of wording, references to terminology, section numbers. v00 - v01 o Removed the ability for more than one subscription to go to a single HTTP2 stream. o Updated call flows. Extensively. o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions o HTTP is not used to determine that a receiver has gone silent and is not Receiving Event Notifications o Many clean-ups of wording and terminology Authors' Addresses Eric Voit Cisco Systems Email: evoit@cisco.com Voit, et al. Expires December 13, 2019 [Page 27] Internet-Draft RESTCONF-Notif June 2019 Reshad Rahman Cisco Systems Email: rrahman@cisco.com Einar Nilsen-Nygaard Cisco Systems Email: einarnn@cisco.com Alexander Clemm Huawei Email: ludwig@clemm.org Andy Bierman YumaWorks Email: andy@yumaworks.com Voit, et al. Expires December 13, 2019 [Page 28] ./draft-ietf-rtcweb-alpn-04.txt0000644000764400076440000003577312712725447015624 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-netmod-syslog-model-26.txt0000644000764400076440000017775313252706170017311 0ustar iustyiusty NETMOD WG C. Wildes, Ed. Internet-Draft Cisco Systems Inc. Intended status: Standards Track K. Koushik, Ed. Expires: September 14, 2018 Verizon Wireless March 15, 2018 A YANG Data Model for Syslog Configuration draft-ietf-netmod-syslog-model-26 Abstract This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. 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 14, 2018. Copyright Notice Copyright (c) 2018 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. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. NDMA Compliance . . . . . . . . . . . . . . . . . . . . . 3 Wildes & Koushik Expires September 14, 2018 [Page 1] Internet-Draft Syslog Management March 2018 1.4. Editorial Note (To be removed by RFC Editor) . . . . . . . 3 2. Design of the Syslog Model . . . . . . . . . . . . . . . . . . 3 2.1. Syslog Module . . . . . . . . . . . . . . . . . . . . . . 5 3. Syslog YANG Module . . . . . . . . . . . . . . . . . . . . . . 7 3.1. The ietf-syslog Module . . . . . . . . . . . . . . . . . . 8 4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 26 6.2. The YANG Module Names Registry . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Implementer Guidelines . . . . . . . . . . . . . . . . 29 Appendix A.1. Extending Facilities . . . . . . . . . . . . . . 29 Appendix A.2. Syslog Terminal Output . . . . . . . . . . . . . 30 Appendix A.3. Syslog File Naming Convention . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This document defines a YANG [RFC7950] configuration data model that may be used to configure the syslog feature running on a system. YANG models can be used with network management protocols such as NETCONF [RFC6241] to install, manipulate, and delete the configuration of network devices. The data model makes use of the YANG "feature" construct which allows implementations to support only those syslog features that lie within their capabilities. This module can be used to configure the syslog application conceptual layers as implemented on the target system. Essentially, a syslog process receives messages (from the kernel, processes, applications or other syslog processes) and processes them. The processing may involve logging to a local file, and/or displaying on console, and/or relaying to syslog processes on other machines. The processing is determined by the "facility" that originated the message and the "severity" assigned to the message by the facility. Such definitions of syslog protocol are defined in [RFC5424], and are used in this RFC. The YANG model in this document conforms to the Network Management Datastore Architecture defined in [draft-ietf-netmod-revised- datastores]. 1.1. Requirements Language Wildes & Koushik Expires September 14, 2018 [Page 2] Internet-Draft Syslog Management March 2018 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology The term "originator" is defined in [RFC5424]: an "originator" generates syslog content to be carried in a message. The term "relay" is defined in [RFC5424]: a "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays The term "collectors" is defined in [RFC5424]: a "collector" gathers syslog content for further analysis. The term "action" refers to the processing that takes place for each syslog message received. 1.3. NDMA Compliance The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores [I-D.ietf-netmod-revised-datastores]. 1.4. Editorial Note (To be removed by RFC Editor) This document 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. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft- ietf-netconf-keystore o "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value for draft-ietf-netconf-tls-client-server o "zzzz" --> the assigned RFC value for this draft o I-D.ietf-netmod-revised-datastores --> the assigned RFC value for draft-ietf-netmod-revised-datastores 2. Design of the Syslog Model The syslog model was designed by comparing various syslog features Wildes & Koushik Expires September 14, 2018 [Page 3] Internet-Draft Syslog Management March 2018 implemented by various vendors' in different implementations. This document addresses the common leafs between implementations and creates a common model, which can be augmented with proprietary features, if necessary. This model is designed to be very simple for maximum flexibility. Some optional features are defined in this document to specify functionality that is present in specific vendor configurations. Syslog consists of originators and collectors. The following diagram shows syslog messages flowing from originators, to collectors where filtering can take place. Originators +-------------+ +-------------+ +-------------+ +-------------+ | Various | | OS | | | | Remote | | Components | | Kernel | | Line Cards | | Servers | +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ | SNMP | | Interface | | Standby | | Syslog | | Events | | Events | | Supervisor | | Itself | +-------------+ +-------------+ +-------------+ +-------------+ | | +----------------------------------------------------------------+ | | | | +-------------+--------------+ | | | v v v Collectors +----------+ +----------+ +----------------+ | | | Log | |Remote Relay(s)/| | Console | | File(s) | |Collector(s) | +----------+ +----------+ +----------------+ Figure 1. Syslog Processing Flow Collectors are configured using the leaves in the syslog model "actions" container which correspond to each message collector: console log file(s) remote relay(s)/collector(s) Wildes & Koushik Expires September 14, 2018 [Page 4] Internet-Draft Syslog Management March 2018 Within each action, a selector is used to filter syslog messages. A selector consists of a list of one or more filters specified by facility-severity pairs, and, if supported via the select-match feature, an optional regular expression pattern match that is performed on the [RFC5424] field. A syslog message is processed if: There is an element of facility-list (F, S) where the message facility matches F and the message severity matches S and/or the message text matches the regex pattern (if it is present) The facility is one of a specific syslog-facility, or all facilities. The severity is one of type syslog-severity, all severities, or none. None is a special case that can be used to disable a filter. When filtering severity, the default comparison is that messages of the specified severity and higher are selected to be logged. This is shown in the model as "default equals-or-higher". This behavior can be altered if the select-adv-compare feature is enabled to specify a compare operation and an action. Compare operations are: "equals" to select messages with this single severity, or "equals-or-higher" to select messages of the specified severity and higher. Actions are used to log the message or block the message from being logged. Many vendors extend the list of facilities available for logging in their implementation. An example is included in Extending Facilities (Appendix A.1). 2.1. Syslog Module A simplified graphical representation of the data model is used in this document. Please see [I-D.ietf-netmod-yang-tree-diagrams] for tree diagram notation. Wildes & Koushik Expires September 14, 2018 [Page 5] Internet-Draft Syslog Management March 2018 module: ietf-syslog +--rw syslog! +--rw actions +--rw console! {console-action}? | +--rw facility-filter | | +--rw facility-list* [facility severity] | | +--rw facility union | | +--rw severity union | | +--rw advanced-compare {select-adv-compare}? | | +--rw compare? enumeration | | +--rw action? enumeration | +--rw pattern-match? string {select-match}? +--rw file {file-action}? | +--rw log-file* [name] | +--rw name inet:uri | +--rw facility-filter | | +--rw facility-list* [facility severity] | | +--rw facility union | | +--rw severity union | | +--rw advanced-compare {select-adv-compare}? | | +--rw compare? enumeration | | +--rw action? enumeration | +--rw pattern-match? string {select-match}? | +--rw structured-data? boolean {structured-data}? | +--rw file-rotation | +--rw number-of-files? uint32 {file-limit-size}? | +--rw max-file-size? uint32 {file-limit-size}? | +--rw rollover? uint32 | | {file-limit-duration}? | +--rw retention? uint32 | {file-limit-duration}? +--rw remote {remote-action}? +--rw destination* [name] +--rw name string +--rw (transport) | +--:(udp) | | +--rw udp | | +--rw address? inet:host | | +--rw port? inet:port-number | +--:(tls) | +--rw tls | +--rw address? inet:host | +--rw port? inet:port-number | +--rw client-auth | | +--rw (auth-type)? | | +--:(certificate) | | +--rw certificate? leafref | +--rw server-auth | | +--rw pinned-ca-certs? leafref | | +--rw pinned-server-certs? leafref | +--rw hello-params | {tls-client-hello-params-config}? | +--rw tls-versions Wildes & Koushik Expires September 14, 2018 [Page 6] Internet-Draft Syslog Management March 2018 | | +--rw tls-version* identityref | +--rw cipher-suites | +--rw cipher-suite* identityref +--rw facility-filter | +--rw facility-list* [facility severity] | +--rw facility union | +--rw severity union | +--rw advanced-compare {select-adv-compare}? | +--rw compare? enumeration | +--rw action? enumeration +--rw pattern-match? string {select-match}? +--rw structured-data? boolean {structured-data}? +--rw facility-override? identityref +--rw source-interface? if:interface-ref | {remote-source-interface}? +--rw signing! {signed-messages}? +--rw cert-signers +--rw cert-signer* [name] | +--rw name string | +--rw cert | | +--rw algorithm? | | | identityref | | +--rw private-key? | | | union | | +--rw public-key? | | | binary | | +---x generate-private-key | | | +---w input | | | +---w algorithm? | | | identityref | | +--rw certificates | | | +--rw certificate* [name] | | | +--rw name string | | | +--rw value? binary | | +---x generate-certificate-signing-request | | +---w input | | | +---w subject binary | | | +---w attributes? binary | | +--ro output | | +--ro certificate-signing-request | | binary | +--rw hash-algorithm? enumeration +--rw cert-initial-repeat? uint32 +--rw cert-resend-delay? uint32 +--rw cert-resend-count? uint32 +--rw sig-max-delay? uint32 +--rw sig-number-resends? uint32 +--rw sig-resend-delay? uint32 +--rw sig-resend-count? uint32 Figure 2. ietf-syslog Module Tree 3. Syslog YANG Module Wildes & Koushik Expires September 14, 2018 [Page 7] Internet-Draft Syslog Management March 2018 3.1. The ietf-syslog Module This module imports typedefs from [RFC6991], [I-D.ietf-netmod-rfc7223bis], groupings from [I-D.ietf-netconf-keystore], and [I-D.ietf-netconf-tls-client-server], and it references [RFC5424], [RFC5425], [RFC5426], [RFC5848], [RFC8089], [RFC8174], and [Std-1003.1-2008]. Wildes & Koushik Expires September 14, 2018 [Page 8] Internet-Draft Syslog Management March 2018 file "ietf-syslog@2018-03-15.yang" module ietf-syslog { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-syslog"; prefix syslog; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix if; reference "I-D.ietf-netmod-rfc7223bis: A YANG Data Model for Interface Management"; } import ietf-tls-client { prefix tlsc; reference "I-D.ietf-netconf-tls-client-server: YANG Groupings for TLS Clients and TLS Servers"; } import ietf-keystore { prefix ks; reference "I-D.ietf-netconf-keystore: YANG Data Model for a Keystore Mechanism"; } organization "IETF NETMOD (Network Modeling) Working Group"; contact "WG Web: WG List: Editor: Kiran Agrahara Sreenivasa Editor: Clyde Wildes "; description "This module contains a collection of YANG definitions for syslog configuration. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Wildes & Koushik Expires September 14, 2018 [Page 9] Internet-Draft Syslog Management March 2018 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). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119 (http://tools.ietf.org/html/rfc2119). This version of this YANG module is part of RFC zzzz (http://tools.ietf.org/html/rfczzzz); see the RFC itself for full legal notices."; revision 2018-03-15 { description "Initial Revision"; reference "RFC zzzz: Syslog YANG Model"; } feature console-action { description "This feature indicates that the local console action is supported."; } feature file-action { description "This feature indicates that the local file action is supported."; } feature file-limit-size { description "This feature indicates that file logging resources are managed using size and number limits."; } feature file-limit-duration { description "This feature indicates that file logging resources are managed using time based limits."; } feature remote-action { description "This feature indicates that the remote server action is supported."; } Wildes & Koushik Expires September 14, 2018 [Page 10] Internet-Draft Syslog Management March 2018 feature remote-source-interface { description "This feature indicates that source-interface is supported supported for the remote-action."; } feature select-adv-compare { description "This feature represents the ability to select messages using the additional comparison operators when comparing the syslog message severity."; } feature select-match { description "This feature represents the ability to select messages based on a Posix 1003.2 regular expression pattern match."; } feature structured-data { description "This feature represents the ability to log messages in structured-data format."; reference "RFC 5424: The Syslog Protocol"; } feature signed-messages { description "This feature represents the ability to configure signed syslog messages."; reference "RFC 5848: Signed Syslog Messages"; } typedef syslog-severity { type enumeration { enum "emergency" { value 0; description "The severity level 'Emergency' indicating that the system is unusable."; } enum "alert" { value 1; description "The severity level 'Alert' indicating that an action must be taken immediately."; } enum "critical" { value 2; description "The severity level 'Critical' indicating a critical condition."; Wildes & Koushik Expires September 14, 2018 [Page 11] Internet-Draft Syslog Management March 2018 } enum "error" { value 3; description "The severity level 'Error' indicating an error condition."; } enum "warning" { value 4; description "The severity level 'Warning' indicating a warning condition."; } enum "notice" { value 5; description "The severity level 'Notice' indicating a normal but significant condition."; } enum "info" { value 6; description "The severity level 'Info' indicating an informational message."; } enum "debug" { value 7; description "The severity level 'Debug' indicating a debug-level message."; } } description "The definitions for Syslog message severity. Note that a lower value is a higher severity. Comparisons of equal-or-higher severity mean equal or lower numeric value"; reference "RFC 5424: The Syslog Protocol"; } identity syslog-facility { description "This identity is used as a base for all syslog facilities."; reference "RFC 5424: The Syslog Protocol"; } identity kern { base syslog-facility; description "The facility for kernel messages (0)."; reference "RFC 5424: The Syslog Protocol"; } Wildes & Koushik Expires September 14, 2018 [Page 12] Internet-Draft Syslog Management March 2018 identity user { base syslog-facility; description "The facility for user-level messages (1)."; reference "RFC 5424: The Syslog Protocol"; } identity mail { base syslog-facility; description "The facility for the mail system (2)."; reference "RFC 5424: The Syslog Protocol"; } identity daemon { base syslog-facility; description "The facility for the system daemons (3)."; reference "RFC 5424: The Syslog Protocol"; } identity auth { base syslog-facility; description "The facility for security/authorization messages (4)."; reference "RFC 5424: The Syslog Protocol"; } identity syslog { base syslog-facility; description "The facility for messages generated internally by syslogd facility (5)."; reference "RFC 5424: The Syslog Protocol"; } identity lpr { base syslog-facility; description "The facility for the line printer subsystem (6)."; reference "RFC 5424: The Syslog Protocol"; } identity news { base syslog-facility; description "The facility for the network news subsystem (7)."; Wildes & Koushik Expires September 14, 2018 [Page 13] Internet-Draft Syslog Management March 2018 reference "RFC 5424: The Syslog Protocol"; } identity uucp { base syslog-facility; description "The facility for the UUCP subsystem (8)."; reference "RFC 5424: The Syslog Protocol"; } identity cron { base syslog-facility; description "The facility for the clock daemon (9)."; reference "RFC 5424: The Syslog Protocol"; } identity authpriv { base syslog-facility; description "The facility for privileged security/authorization messages (10)."; reference "RFC 5424: The Syslog Protocol"; } identity ftp { base syslog-facility; description "The facility for the FTP daemon (11)."; reference "RFC 5424: The Syslog Protocol"; } identity ntp { base syslog-facility; description "The facility for the NTP subsystem (12)."; reference "RFC 5424: The Syslog Protocol"; } identity audit { base syslog-facility; description "The facility for log audit messages (13)."; reference "RFC 5424: The Syslog Protocol"; } identity console { Wildes & Koushik Expires September 14, 2018 [Page 14] Internet-Draft Syslog Management March 2018 base syslog-facility; description "The facility for log alert messages (14)."; reference "RFC 5424: The Syslog Protocol"; } identity cron2 { base syslog-facility; description "The facility for the second clock daemon (15)."; reference "RFC 5424: The Syslog Protocol"; } identity local0 { base syslog-facility; description "The facility for local use 0 messages (16)."; reference "RFC 5424: The Syslog Protocol"; } identity local1 { base syslog-facility; description "The facility for local use 1 messages (17)."; reference "RFC 5424: The Syslog Protocol"; } identity local2 { base syslog-facility; description "The facility for local use 2 messages (18)."; reference "RFC 5424: The Syslog Protocol"; } identity local3 { base syslog-facility; description "The facility for local use 3 messages (19)."; reference "RFC 5424: The Syslog Protocol"; } identity local4 { base syslog-facility; description "The facility for local use 4 messages (20)."; reference "RFC 5424: The Syslog Protocol"; } Wildes & Koushik Expires September 14, 2018 [Page 15] Internet-Draft Syslog Management March 2018 identity local5 { base syslog-facility; description "The facility for local use 5 messages (21)."; reference "RFC 5424: The Syslog Protocol"; } identity local6 { base syslog-facility; description "The facility for local use 6 messages (22)."; reference "RFC 5424: The Syslog Protocol"; } identity local7 { base syslog-facility; description "The facility for local use 7 messages (23)."; reference "RFC 5424: The Syslog Protocol"; } grouping severity-filter { description "This grouping defines the processing used to select log messages by comparing syslog message severity using the following processing rules: - if 'none', do not match. - if 'all', match. - else compare message severity with the specified severity according to the default compare rule (all messages of the specified severity and greater match) or if the select-adv-compare feature is present, use the advance-compare rule."; leaf severity { type union { type syslog-severity; type enumeration { enum none { value 2147483647; description "This enum describes the case where no severities are selected."; } enum all { value -2147483648; description "This enum describes the case where all severities are selected."; } } Wildes & Koushik Expires September 14, 2018 [Page 16] Internet-Draft Syslog Management March 2018 } mandatory true; description "This leaf specifies the syslog message severity."; } container advanced-compare { when '../severity != "all" and ../severity != "none"' { description "The advanced compare container is not applicable for severity 'all' or severity 'none'"; } if-feature select-adv-compare; leaf compare { type enumeration { enum equals { description "This enum specifies that the severity comparison operation will be equals."; } enum equals-or-higher { description "This enum specifies that the severity comparison operation will be equals or higher."; } } default equals-or-higher; description "The compare can be used to specify the comparison operator that should be used to compare the syslog message severity with the specified severity."; } leaf action { type enumeration { enum log { description "This enum specifies that if the compare operation is true the message will be logged."; } enum block { description "This enum specifies that if the compare operation is true the message will not be logged."; } } default log; description "The action can be used to specify if the message should be logged or blocked based on the outcome of the compare operation."; } description "This container describes additional severity compare operations that can be used in place of the default Wildes & Koushik Expires September 14, 2018 [Page 17] Internet-Draft Syslog Management March 2018 severity comparison. The compare leaf specifies the type of the compare that is done and the action leaf specifies the intended result. Example: compare->equals and action->block means messages that have a severity that are equal to the specified severity will not be logged."; } } grouping selector { description "This grouping defines a syslog selector which is used to select log messages for the log-actions (console, file, remote, etc.). Choose one or both of the following: facility [ ...] pattern-match regular-expression-match-string If both facility and pattern-match are specified, both must match in order for a log message to be selected."; container facility-filter { description "This container describes the syslog filter parameters."; list facility-list { key "facility severity"; ordered-by user; description "This list describes a collection of syslog facilities and severities."; leaf facility { type union { type identityref { base syslog-facility; } type enumeration { enum all { description "This enum describes the case where all facilities are requested."; } } } description "The leaf uniquely identifies a syslog facility."; } uses severity-filter; } } leaf pattern-match { if-feature select-match; type string; description "This leaf describes a Posix 1003.2 regular expression string that can be used to select a syslog message for logging. The match is performed on the SYSLOG-MSG field."; reference Wildes & Koushik Expires September 14, 2018 [Page 18] Internet-Draft Syslog Management March 2018 "RFC 5424: The Syslog Protocol Std-1003.1-2008 Regular Expressions"; } } grouping structured-data { description "This grouping defines the syslog structured data option which is used to select the format used to write log messages."; leaf structured-data { if-feature structured-data; type boolean; default false; description "This leaf describes how log messages are written. If true, messages will be written with one or more STRUCTURED-DATA elements; if false, messages will be written with STRUCTURED-DATA = NILVALUE."; reference "RFC 5424: The Syslog Protocol"; } } container syslog { presence "Enables logging."; description "This container describes the configuration parameters for syslog."; container actions { description "This container describes the log-action parameters for syslog."; container console { if-feature console-action; presence "Enables logging to the console"; description "This container describes the configuration parameters for console logging."; uses selector; } container file { if-feature file-action; description "This container describes the configuration parameters for file logging. If file-archive limits are not supplied, it is assumed that the local implementation defined limits will be used."; list log-file { key "name"; description "This list describes a collection of local logging files."; leaf name { Wildes & Koushik Expires September 14, 2018 [Page 19] Internet-Draft Syslog Management March 2018 type inet:uri { pattern 'file:.*'; } description "This leaf specifies the name of the log file which MUST use the uri scheme file:."; reference "RFC 8089: The file URI Scheme"; } uses selector; uses structured-data; container file-rotation { description "This container describes the configuration parameters for log file rotation."; leaf number-of-files { if-feature file-limit-size; type uint32; default 1; description "This leaf specifies the maximum number of log files retained. Specify 1 for implementations that only support one log file."; } leaf max-file-size { if-feature file-limit-size; type uint32; units "megabytes"; description "This leaf specifies the maximum log file size."; } leaf rollover { if-feature file-limit-duration; type uint32; units "minutes"; description "This leaf specifies the length of time that log events should be written to a specific log file. Log events that arrive after the rollover period cause the current log file to be closed and a new log file to be opened."; } leaf retention { if-feature file-limit-duration; type uint32; units "minutes"; description "This leaf specifies the length of time that completed/closed log event files should be stored in the file system before they are removed."; } } } } Wildes & Koushik Expires September 14, 2018 [Page 20] Internet-Draft Syslog Management March 2018 container remote { if-feature remote-action; description "This container describes the configuration parameters for forwarding syslog messages to remote relays or collectors."; list destination { key "name"; description "This list describes a collection of remote logging destinations."; leaf name { type string; description "An arbitrary name for the endpoint to connect to."; } choice transport { mandatory true; description "This choice describes the transport option."; case udp { container udp { description "This container describes the UDP transport options."; reference "RFC 5426: Transmission of Syslog Messages over UDP"; leaf address { type inet:host; description "The leaf uniquely specifies the address of the remote host. One of the following must be specified: an ipv4 address, an ipv6 address, or a host name."; } leaf port { type inet:port-number; default 514; description "This leaf specifies the port number used to deliver messages to the remote server."; } } } case tls { container tls { description "This container describes the TLS transport options."; reference "RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog "; leaf address { Wildes & Koushik Expires September 14, 2018 [Page 21] Internet-Draft Syslog Management March 2018 type inet:host; description "The leaf uniquely specifies the address of the remote host. One of the following must be specified: an ipv4 address, an ipv6 address, or a host name."; } leaf port { type inet:port-number; default 6514; description "TCP port 6514 has been allocated as the default port for syslog over TLS."; } uses tlsc:tls-client-grouping; } } } uses selector; uses structured-data; leaf facility-override { type identityref { base syslog-facility; } description "If specified, this leaf specifies the facility used to override the facility in messages delivered to the remote server."; } leaf source-interface { if-feature remote-source-interface; type if:interface-ref; description "This leaf sets the source interface to be used to send messages to the remote syslog server. If not set, messages can be sent on any interface."; } container signing { if-feature signed-messages; presence "If present, syslog-signing options is activated."; description "This container describes the configuration parameters for signed syslog messages."; reference "RFC 5848: Signed Syslog Messages"; container cert-signers { description "This container describes the signing certificate configuration for Signature Group 0 which covers the case for administrators who want all Signature Blocks to be sent to a single destination."; list cert-signer { key "name"; Wildes & Koushik Expires September 14, 2018 [Page 22] Internet-Draft Syslog Management March 2018 description "This list describes a collection of syslog message signers."; leaf name { type string; description "This leaf specifies the name of the syslog message signer."; } container cert { uses ks:private-key-grouping; uses ks:certificate-grouping; description "This is the certificate that is periodically sent to the remote receiver. Selection of the certificate also implicitly selects the private key used to sign the syslog messages."; } leaf hash-algorithm { type enumeration { enum SHA1 { value 1; description "This enum describes the SHA1 algorithm."; } enum SHA256 { value 2; description "This enum describes the SHA256 algorithm."; } } description "This leaf describes the syslog signer hash algorithm used."; } } leaf cert-initial-repeat { type uint32; default 3; description "This leaf specifies the number of times each Certificate Block should be sent before the first message is sent."; } leaf cert-resend-delay { type uint32; units "seconds"; default 3600; description "This leaf specifies the maximum time delay in seconds until resending the Certificate Block."; } leaf cert-resend-count { type uint32; Wildes & Koushik Expires September 14, 2018 [Page 23] Internet-Draft Syslog Management March 2018 default 0; description "This leaf specifies the maximum number of other syslog messages to send until resending the Certificate Block."; } leaf sig-max-delay { type uint32; units "seconds"; default 60; description "This leaf specifies when to generate a new Signature Block. If this many seconds have elapsed since the message with the first message number of the Signature Block was sent, a new Signature Block should be generated."; } leaf sig-number-resends { type uint32; default 0; description "This leaf specifies the number of times a Signature Block is resent. (It is recommended to select a value of greater than 0 in particular when the UDP transport RFC 5426 is used.)."; } leaf sig-resend-delay { type uint32; units "seconds"; default 5; description "This leaf specifies when to send the next Signature Block transmission based on time. If this many seconds have elapsed since the previous sending of this Signature Block, resend it."; } leaf sig-resend-count { type uint32; default 0; description "This leaf specifies when to send the next Signature Block transmission based on a count. If this many other syslog messages have been sent since the previous sending of this Signature Block, resend it. A value of 0 means that you don't resend based on the number of messages."; } } } } } } } Wildes & Koushik Expires September 14, 2018 [Page 24] Internet-Draft Syslog Management March 2018 } Figure 3. ietf-syslog Module 4. Usage Examples Requirement: Enable console logging of syslogs of severity critical all critical Enable remote logging of syslogs to udp destination foo.example.com for facility auth, severity error remote1
foo.example.com
 auth error Figure 4. ietf-syslog Examples 5. Acknowledgements The authors wish to thank the following who commented on this proposal: Wildes & Koushik Expires September 14, 2018 [Page 25] Internet-Draft Syslog Management March 2018 Andy Bierman, Martin Bjorklund, Alex Campbell, Alex Clemm, Francis Dupont, Jim Gibson, Jeffrey Haas, Bob Harold, John Heasley, Giles Heron, Lisa Huang, Mahesh Jethanandani, Warren Kumari, Jeffrey K Lange, Jan Lindblad, Chris Lonvick, Alexey Melnikov, Kathleen Moriarty, Tom Petch, Adam Roach, Juergen Schoenwaelder, Phil Shafer, Yaron Sheffer, Jason Sterne, Peter Van Horne, Kent Watsen, Bert Wijnen, Dale R Worley, and Aleksandr Zhdankin. 6. IANA Considerations 6.1. The IETF XML Registry This document registers one URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested: URI: urn:ietf:params:xml:ns:yang:ietf-syslog Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 6.2. The YANG Module Names Registry This document registers one YANG module in the YANG Module Names registry [RFC7895]. Following the format in [RFC7950], the following registration is requested: name: ietf-syslog namespace: urn:ietf:params:xml:ns:yang:ietf-syslog prefix: ietf-syslog reference: RFC zzzz 7. Security Considerations The YANG module defined in this document is designed to be accessed via YANG based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols have mandatory-to- implement secure transport layers (e.g., SSH, TLS) with mutual authentication. The NETCONF access control model (NACM) [RFC6536] provides the means to restrict access for particular users to a pre-configured subset of all available protocol operations and content. Wildes & Koushik Expires September 14, 2018 [Page 26] Internet-Draft Syslog Management March 2018 There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes should be considered sensitive or vulnerable in all network environments. Logging in particular is used to assess the state of systems and can be used to indicate a network compromise. If logging were to be disabled through malicious means, attacks may not be readily detectable. Therefore write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations and on network security. In addition there are data nodes that require careful analysis and review. These are the subtrees and data nodes and their sensitivity/ vulnerability: facility-filter/pattern-match: When writing this node, implementations MUST ensure that the regular expression pattern match is not constructed to cause a regular expression denial of service attack due to a pattern that causes the regular expression implementation to work very slowly (exponentially related to input size). remote/destination/signing/cert-signer: When writing this subtree, implementations MUST NOT specify a private key that is used for any other purpose. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: remote/destination/transport: This subtree contains information about other hosts in the network, and the TLS transport certificate properties if TLS is selected as the transport protocol. remote/destination/signing: This subtree contains information about the syslog message signing properties including signing certificate information. There are no RPC operations defined in this YANG module. 8. References 8.1. Normative References [I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keystore" Mechanism", Internet-Draft draft-ietf-netconf-keystore-04, October 2017. [I-D.ietf-netconf-tls-client-server] Wildes & Koushik Expires September 14, 2018 [Page 27] Internet-Draft Syslog Management March 2018 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and TLS Servers", Internet-Draft draft-ietf-netconf-tls- client-server-05, October 2017. [I-D.ietf-netmod-rfc7223bis] Bjorklund, M., "A YANG Data Model for Interface Management", Internet-Draft draft-ietf-netmod- rfc7223bis-03, January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . [RFC5425] Miao, F., Ed., Ma, Y.Ed., and J. Salowey, Ed., "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, DOI 10.17487/RFC5425, March 2009, . [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, DOI 10.17487/RFC5426, March 2009, . [RFC5848] Kelsey, J., Callas, J. and A. Clemm, "Signed Syslog Messages", RFC 5848, DOI 10.17487/RFC5848, May 2010, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7895] Bierman, A., Bjorklund, M. and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [Std-1003.1-2008] Wildes & Koushik Expires September 14, 2018 [Page 28] Internet-Draft Syslog Management March 2018 The Open Group, ""Chapter 9: Regular Expressions". The Open Group Base Specifications Issue 6, IEEE Std 1003.1-2008, 2016 Edition.", September 2016, . 8.2. Informative References [I-D.ietf-netmod-revised-datastores] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K. and R. Wilton, "Network Management Datastore Architecture", Internet-Draft draft-ietf-netmod-revised- datastores-10, January 2018. [I-D.ietf-netmod-yang-tree-diagrams] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", Internet-Draft draft-ietf-netmod-yang-tree-diagrams-06, February 2018. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [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, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC8040] Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Appendix A. Implementer Guidelines Appendix A.1. Extending Facilities Many vendors extend the list of facilities available for logging in their implementation. Additional facilities may not work with the syslog protocol as defined in [RFC5424] and hence such facilities apply for local syslog-like logging functionality. The following is an example that shows how additional facilities could be added to the list of available facilities (in this example two facilities are added): Wildes & Koushik Expires September 14, 2018 [Page 29] Internet-Draft Syslog Management March 2018 module example-vendor-syslog-types { namespace "http://example.com/ns/vendor-syslog-types"; prefix vendor-syslogtypes; import ietf-syslog { prefix syslogtypes; } organization "Example, Inc."; contact "Example, Inc. Customer Service E-mail: syslog-yang@example.com"; description "This module contains a collection of vendor-specific YANG type definitions for SYSLOG."; revision 2017-08-11 { description "Version 1.0"; reference "Vendor SYSLOG Types: SYSLOG YANG Model"; } identity vendor_specific_type_1 { base syslogtypes:syslog-facility; description "Adding vendor specific type 1 to syslog-facility"; } identity vendor_specific_type_2 { base syslogtypes:syslog-facility; description "Adding vendor specific type 2 to syslog-facility"; } } Appendix A.2. Syslog Terminal Output Terminal output with requirements more complex than the console subtree currently provides, are expected to be supported via vendor extensions rather than handled via the file subtree. Appendix A.3. Syslog File Naming Convention The syslog/file/log-file/file-rotation container contains configuration parameters for syslog file rotation. This section describes how these fields might be used by an implementer to name syslog files in a rotation process. This information is offered as an informative guide only. Wildes & Koushik Expires September 14, 2018 [Page 30] Internet-Draft Syslog Management March 2018 When an active syslog file with a name specified by log-file/name, reaches log-file/max-file-size and/or syslog events arrive after the period specified by log-file/rollover, the logging system can close the file, can compress it, and can name the archive file .0.gz. The logging system can then open a new active syslog file . When the new syslog file reaches either of the size limits referenced above, .0.gz can be renamed .1.gz and the new syslog file can be closed, compressed and renamed .0.gz. Each time that a new syslog file is closed, each of the prior syslog archive files named ..gz can be renamed to ..gz. Removal of archive log files could occur when either or both: - log-file/number-of-files specified - the logging system can create up to log-file/number-of-files syslog archive files after which, the contents of the oldest archived file could be overwritten. - log-file/retention specified - the logging system can remove those syslog archive files whose file expiration time (file creation time plus the specified log-file/retention time) is prior to the current time. Authors' Addresses Clyde Wildes, editor Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 US Phone: +1 408 527-2672 Email: cwildes@cisco.com Kiran Koushik, editor Verizon Wireless 500 W Dove Rd. Southlake, TX 76092 US Phone: +1 512 650-0210 Email: kirankoushik.agraharasreenivasa@verizonwireless.com Wildes & Koushik Expires September 14, 2018 [Page 31] ./draft-ietf-rtgwg-yang-rip-11.txt0000644000764400076440000023146413531574003016243 0ustar iustyiusty Network Working Group X. Liu Internet-Draft Volta Networks Intended status: Standards Track P. Sarda Expires: February 29, 2020 Ericsson V. Choudhary Individual August 28, 2019 A YANG Data Model for Routing Information Protocol (RIP) draft-ietf-rtgwg-yang-rip-11 Abstract This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs). The YANG model in this document conforms to the Network Management Datastore Architecture (NMDA). 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 https://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 29, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Liu, et al. Expires February 29, 2020 [Page 1] Internet-Draft YANG RIP August 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 2.1. Scope of the Model . . . . . . . . . . . . . . . . . . . 3 2.2. Relation with Core Routing Framework . . . . . . . . . . 4 2.3. Protocol Configuration . . . . . . . . . . . . . . . . . 4 2.4. Protocol States . . . . . . . . . . . . . . . . . . . . . 5 2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 6 2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Optional Features . . . . . . . . . . . . . . . . . . . . 6 3. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 6 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.1. Normative References . . . . . . . . . . . . . . . . . . 35 7.2. Informative References . . . . . . . . . . . . . . . . . 37 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction This document introduces a YANG [RFC7950] data model for the Routing Information Protocol (RIP) [RFC2453][RFC2080]. RIP was designed to work as an Interior Gateway Protocol (IGP) in moderate-size Autonomous Systems (AS). This YANG model supports both RIP version 2 and RIPng. RIP version 2 (defined in [RFC2453]) supports IPv4. RIPng (defined in [RFC2080]) supports IPv6. 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]. Liu, et al. Expires February 29, 2020 [Page 2] Internet-Draft YANG RIP August 2019 The following terms are defined in [RFC7950] and are not redefined here: o augment o data model o data node 1.2. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in [RFC8340]. 1.3. Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +-----------+-----------------+-------------------------------+ | Prefix | YANG module | Reference | +-----------+-----------------+-------------------------------+ | yang | ietf-yang-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] | | if | ietf-interfaces | [RFC8343] | | ip | ietf-ip | [RFC8344] | | rt | ietf-routing | [RFC8349] | | bfd-types | ietf-bfd-types | [I-D.ietf-bfd-yang] | | isis | ietf-isis | [I-D.ietf-isis-yang-isis-cfg] | | key-chain | ietf-key-chain | [RFC8177] | | ospf | ietf-ospf | [I-D.ietf-ospf-yang] | +-----------+-----------------+-------------------------------+ Table 1: Prefixes and Corresponding YANG Modules 2. Design of the Data Model 2.1. Scope of the Model The model covers RIP version 2 [RFC2453] and RIPng [RFC2080] protocols. The model is designed to be implemented on a device where RIP version 2 or RIPng is implemented, and can be used to: o Configure the RIP version 2 or RIPng protocol. Liu, et al. Expires February 29, 2020 [Page 3] Internet-Draft YANG RIP August 2019 o Manage the protocol operational behaviors. o Retrieve the protocol operational status. The capabilities describe in [RFC1724] are covered. 2.2. Relation with Core Routing Framework This model augments the core routing data model "ietf-routing" specified in [RFC8349]. +--rw routing +--rw router-id? +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw type | +--rw name | +--rw rip <= Augmented by this Model ... The "rip" container instantiates a RIP protocol entity that supports RIP version 2 or RIPng. Depending on the implementation of "ietf- routing", a RIP instance MAY belong to a logical router or network instance. 2.3. Protocol Configuration The model structure for the protocol configuration is as shown below: augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw rip +--rw +--rw interface* [interface] +--rw interface if:interface-ref +--rw +--rw neighbors {explicit-neighbors}? | +--rw neighbor* [address] | +--rw address inet:ip-address | +--rw The model allows to configure the following protocol entities: o Protocol instance (RIP version 2 or RIPng) Liu, et al. Expires February 29, 2020 [Page 4] Internet-Draft YANG RIP August 2019 o Interface o Neighbor 2.4. Protocol States The model structure for the protocol states is as shown below: augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw rip +--ro +--rw interface* [interface] | +--rw interface if:interface-ref | +--ro | +--ro statistics {interface-statistics}? | +--ro +--ro ipv4 | +--ro neighbors | | +--ro neighbor* [ipv4-address] | | +--ro | +--ro routes | +--ro route* [ipv4-prefix] | +--ro +--ro ipv6 | +--ro neighbors | | +--ro neighbor* [ipv6-address] | | +--ro | +--ro routes | +--ro route* [ipv6-prefix] | +--ro ipv6-prefix inet:ipv6-prefix | +--ro +--ro statistics {global-statistics}? +--ro This model conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [RFC8407]. When protocol states are retrieved from the NMDA operational state datastore, the returned states cover all "config true" (rw) and "config false" (ro) nodes defined in the schema. The model allows to retrieve protocol states at the following levels: o Protocol instance (RIP version 2 or RIPng) Liu, et al. Expires February 29, 2020 [Page 5] Internet-Draft YANG RIP August 2019 o Interface o Neighbor o Route 2.5. RPC Operations This model defines one RPC "clear-rip-route" that can be used to clear RIP routes from the routing table. 2.6. Notifications This model does not define RIP specific notifications. To enable notifications, the mechanism defined in [I-D.ietf-netconf-subscribed-notifications] and [I-D.ietf-netconf-yang-push] can be used. This mechanism currently allows the user to: o Subscribe notifications on a per client basis. o Specify subtree filters or xpath filters so that only interested contents will be sent. o Specify either periodic or on-demand notifications. 2.7. Optional Features This model defines several features are beyond the basic RIP configuration and it is the responsibility of each vendor to decide whether to support a given feature on a device. 3. Tree Structure This document defines the YANG module "ietf-rip", which has the following tree structure: module: ietf-rip augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw rip +--rw originate-default-route | +--rw enabled? boolean | +--rw route-policy? route-policy-ref +--rw default-metric? uint8 +--rw distance? uint8 +--rw triggered-update-threshold? uint8 +--rw maximum-paths? uint8 Liu, et al. Expires February 29, 2020 [Page 6] Internet-Draft YANG RIP August 2019 +--rw output-delay? uint8 +--rw distribute-list* [prefix-set-name direction] | +--rw prefix-set-name prefix-set-ref | +--rw direction enumeration | +--rw if-name? if:interface-ref +--rw redistribute | +--rw bgp* [asn] | | +--rw asn inet:as-number | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw cg-nat! | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw connected! | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw ipsec! | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw isis* [instance] | | +--rw instance | | | -> ../../../../../rt:control-plane-protocol/name | | +--rw level? enumeration | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw nat! | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw ospfv2* [instance] | | +--rw instance | | | -> ../../../../../rt:control-plane-protocol/name | | +--rw route-type? ospf:route-type | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw ospfv3* [instance] | | +--rw instance | | | -> ../../../../../rt:control-plane-protocol/name | | +--rw route-type? ospf:route-type | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw ripv2* [instance] | | +--rw instance | | | -> ../../../../../rt:control-plane-protocol/name | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw ripng* [instance] | | +--rw instance | | | -> ../../../../../rt:control-plane-protocol/name Liu, et al. Expires February 29, 2020 [Page 7] Internet-Draft YANG RIP August 2019 | | +--rw metric? uint8 | | +--rw route-policy? route-policy-ref | +--rw static! | +--rw metric? uint8 | +--rw route-policy? route-policy-ref +--rw timers | +--rw update-interval? uint16 | +--rw invalid-interval? uint16 | +--rw holddown-interval? uint16 | +--rw flush-interval? uint16 +--rw interfaces | +--rw interface* [interface] | +--rw interface if:interface-ref | +--rw authentication | | +--rw (auth-type-selection)? | | +--:(auth-key-chain) | | | +--rw key-chain? key-chain:key-chain-ref | | +--:(auth-key) | | +--rw key? string | | +--rw crypto-algorithm? identityref | +--rw bfd {bfd}? | | +--rw enable? boolean | | +--rw local-multiplier? multiplier | | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) | | +--rw min-interval? uint32 | +--rw cost? uint8 | +--rw neighbors {explicit-neighbors}? | | +--rw neighbor* [address] | | +--rw address inet:ip-address | +--rw no-listen? empty | +--rw originate-default-route | | +--rw enabled? boolean | | +--rw route-policy? route-policy-ref | +--rw passive? empty | +--rw split-horizon? enumeration | +--rw summary-address | | +--rw address? inet:ip-prefix | | +--rw metric? uint8 | +--rw timers | | +--rw update-interval? uint16 | | +--rw invalid-interval? uint16 | | +--rw holddown-interval? uint16 | | +--rw flush-interval? uint16 Liu, et al. Expires February 29, 2020 [Page 8] Internet-Draft YANG RIP August 2019 | +--ro oper-status? enumeration | +--ro next-full-update? uint32 | +--ro valid-address? boolean | +--ro statistics {interface-statistics}? | +--ro discontinuity-time? yang:date-and-time | +--ro bad-packets-rcvd? yang:counter32 | +--ro bad-routes-rcvd? yang:counter32 | +--ro updates-sent? yang:counter32 +--ro next-triggered-update? uint32 +--ro num-of-routes? uint32 +--ro ipv4 | +--ro neighbors | | +--ro neighbor* [ipv4-address] | | +--ro ipv4-address inet:ipv4-address | | +--ro last-update? yang:date-and-time | | +--ro bad-packets-rcvd? yang:counter32 | | +--ro bad-routes-rcvd? yang:counter32 | +--ro routes | +--ro route* [ipv4-prefix] | +--ro ipv4-prefix inet:ipv4-prefix | +--ro next-hop? inet:ipv4-address | +--ro interface? if:interface-ref | +--ro redistributed? boolean | +--ro route-type? enumeration | +--ro metric? uint8 | +--ro expire-time? uint16 | +--ro deleted? boolean | +--ro holddown? boolean | +--ro need-triggered-update? boolean | +--ro inactive? boolean | +--ro flush-expire-before-holddown? boolean +--ro ipv6 | +--ro neighbors | | +--ro neighbor* [ipv6-address] | | +--ro ipv6-address inet:ipv6-address | | +--ro last-update? yang:date-and-time | | +--ro bad-packets-rcvd? yang:counter32 | | +--ro bad-routes-rcvd? yang:counter32 | +--ro routes | +--ro route* [ipv6-prefix] | +--ro ipv6-prefix inet:ipv6-prefix | +--ro next-hop? inet:ipv6-address | +--ro interface? Liu, et al. Expires February 29, 2020 [Page 9] Internet-Draft YANG RIP August 2019 if:interface-ref | +--ro redistributed? boolean | +--ro route-type? enumeration | +--ro metric? uint8 | +--ro expire-time? uint16 | +--ro deleted? boolean | +--ro holddown? boolean | +--ro need-triggered-update? boolean | +--ro inactive? boolean | +--ro flush-expire-before-holddown? boolean +--ro statistics {global-statistics}? +--ro discontinuity-time? yang:date-and-time +--ro requests-rcvd? yang:counter32 +--ro requests-sent? yang:counter32 +--ro responses-rcvd? yang:counter32 +--ro responses-sent? yang:counter32 rpcs: +---x clear-rip-route +---w input +---w rip-instance? leafref 4. YANG Module file "ietf-rip@2018-02-03.yang" module ietf-rip { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-rip"; prefix rip; import ietf-inet-types { prefix "inet"; } import ietf-yang-types { prefix "yang"; } import ietf-interfaces { prefix "if"; } import ietf-ip { prefix "ip"; } Liu, et al. Expires February 29, 2020 [Page 10] Internet-Draft YANG RIP August 2019 import ietf-routing { prefix "rt"; } import ietf-key-chain { prefix "key-chain"; } import ietf-bfd-types { prefix "bfd-types"; } import ietf-ospf { prefix "ospf"; } import ietf-isis { prefix "isis"; } organization "IETF Routing Area Working Group (rtgwg)"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Prateek Sarda Editor: Vikram Choudhary "; description "This YANG module defines a model for managing Routing Information Protocol (RIP), including RIP version 2 and RIPng. Copyright (c) 2018 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). Liu, et al. Expires February 29, 2020 [Page 11] Internet-Draft YANG RIP August 2019 This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2018-02-03 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Routing Information Protocol (RIP). RFC 2453: RIP Version 2. RFC 2080: RIPng for IPv6. RFC 1724: RIP Version 2 MIB Extension."; } /* * Features */ feature bfd { description "This feature indicates that the RIP implementation on the system supports BFD (Bidirectional Forwarding Detection)."; } feature explicit-neighbors { description "This feature indicates that the system supports explicit neighbor configuration on a RIP interface."; } feature global-statistics { description "This feature indicates that the system supports collecting global statistic data related to RIP."; } feature interface-statistics { description "This feature indicates that the system supports collecting per-interface statistic data related to RIP."; } /* * Typedefs */ typedef prefix-set-ref { type string; description Liu, et al. Expires February 29, 2020 [Page 12] Internet-Draft YANG RIP August 2019 "A type for a reference to a prefix set. The string value is the name identifier for uniquely identifying the referenced prefix set, which contains a list of prefixes that a routing policy can applied. The definition of such a prefix set is outside the scope of this document."; } typedef route-policy-ref { type string; description "A type for a reference to a route policy. The string value is the name identifier for uniquely identifying the referenced routing policy, which contains one or more policy rules that can be used for a routing decision. The definition of such a routing policy is outside the scope of this document."; } /* * Identities */ identity rip { base rt:routing-protocol; description "Identity for the RIP routing protocol."; } identity ripv2 { base rip:rip; description "Identity for RIPv2 (RIP version 2)."; } identity ripng { base rip:rip; description "Identity for RIPng."; } /* * Groupings */ grouping originate-default-route-container { description "Containing settings whether to originate the default route in RIP routing instance."; container originate-default-route { description "Injects the default route into the RIP (RIPv2 or RIPng) Liu, et al. Expires February 29, 2020 [Page 13] Internet-Draft YANG RIP August 2019 routing instance."; leaf enabled { type boolean; default false; description "'true' if originating default route is enabled."; } leaf route-policy { type route-policy-ref; description "The conditions of the route policy are applied to the default route."; } } } grouping redistribute-container { description "Container of redistribute attributes."; container redistribute { description "Redistributes routes learned from other routing protocols into the RIP routing instance."; list bgp { key "asn"; description "Redistributes routes from the specified BGP (Border Gateway Protocol) autonomous system (AS) into the RIP routing instance."; leaf asn { type inet:as-number; description "BGP autonomous system (AS) number."; } uses redistribute-route-policy-attributes; } container cg-nat { presence "Present if Carrier Grade Network Address Translation (CGNAT) routes are redistributed."; description "Carrier Grade Network Address Translation (CGNAT) routes."; uses redistribute-route-policy-attributes; } container connected { presence Liu, et al. Expires February 29, 2020 [Page 14] Internet-Draft YANG RIP August 2019 "Present if directly attached network routes are redistributed."; description "Redistributes directly attached networks into the RIP routing instance."; uses redistribute-route-policy-attributes; } container ipsec { presence "Present if IP security routing instance routes are redistributed."; description "Redistributes routes from the IP security routing instance into the RIP routing instance."; uses redistribute-route-policy-attributes; } list isis { key "instance"; description "Redistributes IS-IS routes."; leaf instance { type leafref { path "../../../../../rt:control-plane-protocol/rt:name"; } must "derived-from-or-self(" + "../../../../../rt:control-plane-protocol" + "[rt:name = current()]/rt:type, 'isis:isis')" { description "The type of the routing protocol must be 'isis'"; } description "Redistributes routes from the specified IS-IS routing instance into the RIP routing instance."; } leaf level { type enumeration { enum 1 { description "IS-IS level 1 routes."; } enum 2 { description "IS-IS level 2 routes."; } enum 1-2 { description "IS-IS level 1-2 routes."; } } description "IS-IS level."; Liu, et al. Expires February 29, 2020 [Page 15] Internet-Draft YANG RIP August 2019 } uses redistribute-route-policy-attributes; } container nat { presence "Present if Network Address Translation (NAT) routes are redistributed."; description "Redistributes Network Address Translation (NAT) routes into the RIP routing instance."; uses redistribute-route-policy-attributes; } list ospfv2 { when "derived-from-or-self(../../../rt:type, 'rip:ripv2')" { description "Applicable to RIPv2."; } key "instance"; description "Redistributes routes from the specified OSPFv2 routing instance into the RIPv2 routing instance."; leaf instance { type leafref { path "../../../../../rt:control-plane-protocol/rt:name"; } must "derived-from-or-self(" + "../../../../../rt:control-plane-protocol" + "[rt:name = current()]/rt:type, 'ospf:ospfv2')" { description "The type of the routing protocol must be 'ospfv2'"; } description "OSPFv2 instance ID. Redistributes routes from the specified OSPFv2 routing instance into the RIPv2 routing instance. "; } leaf route-type { type ospf:route-type; description "Redistributes only those OSPFv2 routes matching the specified route type into the RIPv2 routing instance."; } uses redistribute-route-policy-attributes; } list ospfv3 { when "derived-from-or-self(../../../rt:type, 'rip:ripng')" { description "Applicable to RIPng."; Liu, et al. Expires February 29, 2020 [Page 16] Internet-Draft YANG RIP August 2019 } key "instance"; description "Redistributes routes from the specified OSPFv3 routing instance into the RIPng routing instance."; leaf instance { type leafref { path "../../../../../rt:control-plane-protocol/rt:name"; } must "derived-from-or-self(" + "../../../../../rt:control-plane-protocol" + "[rt:name = current()]/rt:type, 'ospf:ospfv3')" { description "The type of the routing protocol must be 'ospfv3'"; } description "OSPFv3 instance ID. Redistributes routes from the specified OSPFv3 routing instance into the RIPng routing instance. "; } leaf route-type { type ospf:route-type; description "Redistributes only those OSPFv3 routes matching the specified route type into the RIPng routing instance."; } uses redistribute-route-policy-attributes; } list ripv2 { when "derived-from-or-self(../../../rt:type, 'rip:ripv2')" { description "Applicable to RIPv2."; } key "instance"; description "Redistributes routes from another RIPv2 routing instance into the current RIPv2 routing instance."; leaf instance { type leafref { path "../../../../../rt:control-plane-protocol/rt:name"; } must "derived-from-or-self(" + "../../../../../rt:control-plane-protocol" + "[rt:name = current()]/rt:type, 'rip:ripv2')" { description "The type of the routing protocol must be 'ripv2'"; } description Liu, et al. Expires February 29, 2020 [Page 17] Internet-Draft YANG RIP August 2019 "Redistributes routes from the specified RIPv2 routing instance into the RIPv2 routing instance."; } uses redistribute-route-policy-attributes; } list ripng { when "derived-from-or-self(../../../rt:type, 'rip:ripng')" { description "Applicable to RIPng."; } key "instance"; description "Redistributes routes from another RIPng routing instance into the current RIPng routing instance."; leaf instance { type leafref { path "../../../../../rt:control-plane-protocol/rt:name"; } must "derived-from-or-self(" + "../../../../../rt:control-plane-protocol" + "[rt:name = current()]/rt:type, 'rip:ripng')" { description "The type of the routing protocol must be 'ripng'"; } description "Redistributes routes from the specified RIPng routing instance into the RIPng routing instance."; } uses redistribute-route-policy-attributes; } container static { presence "Present if redistributing static routes."; description "Redistributes static routes into the RIP routing instance."; uses redistribute-route-policy-attributes; } } // redistribute } // redistribute-container grouping redistribute-route-policy-attributes { description "Attributes for redistributing a route policy."; leaf metric { type uint8 { range 0..16; } description Liu, et al. Expires February 29, 2020 [Page 18] Internet-Draft YANG RIP August 2019 "Metric used for the redistributed route. If a metric is not specified, the metric configured with the default-metric attribute in RIP router configuration is used. If the default-metric attribute has not been configured, the default metric for redistributed routes is 1."; } leaf route-policy { type route-policy-ref; description "Applies the conditions of the specified route policy to routes that are redistributed into the RIP routing instance."; } } // redistribute-route-policy-attributes grouping timers-container { description "Container for settings of basic timers"; container timers { must "invalid-interval >= (update-interval * 3)" { description "invalid-interval must be at least three times the value for the update-interval argument."; } must "flush-interval > invalid-interval" { description "flush-interval must be larger than the value for the invalid-interval argument"; } description "Timers for the specified RIPv2 or RIPng instance or interface."; leaf update-interval { type uint16 { range 1..32767; } units seconds; default 30; description "Interval at which RIPv2 or RIPng updates are sent."; } leaf invalid-interval { type uint16 { range 1..32767; } units seconds; default 180; Liu, et al. Expires February 29, 2020 [Page 19] Internet-Draft YANG RIP August 2019 description "Interval before a route is declared invalid after no updates are received. This value is at least three times the value for the update-interval argument."; } leaf holddown-interval { type uint16 { range 1..32767; } units seconds; default 180; description "Interval before better routes are released."; } leaf flush-interval { type uint16 { range 1..32767; } units seconds; default 240; description "Interval before a route is flushed from the routing table. This value must be larger than the value for the invalid-interval argument."; } } // timers } grouping global-attributes { description "Global configuration and state attributes."; uses originate-default-route-container; leaf default-metric { type uint8 { range 0..16; } default 1; description "Set the default metric."; } leaf distance { type uint8 { range 1..255; } default 120; description Liu, et al. Expires February 29, 2020 [Page 20] Internet-Draft YANG RIP August 2019 "The administrative distance of the RIPv2 or RIPng for the current RIPv2 or RIPng instance."; } leaf triggered-update-threshold { type uint8 { range 1..30; } units seconds; default 5; description "This attribute is used to suppress triggered updates. When the arrival of a regularly scheduled update matches the number of seconds or is less than the number seconds configured with this attribute, the triggered update is suppressed."; } leaf maximum-paths { type uint8 { range 1..16; } default 8; description "The number of multiple equal-cost RIPv2 or RIPng routes that can be used as the best paths for balancing the load of outgoing traffic packets."; } leaf output-delay { type uint8 { range 1..50; } units milliseconds; description "A delay time between packets sent in multipacket RIPv2 or RIPng updates."; } } // global-attributes grouping distribute-lists { description "Grouping for distribute lists."; list distribute-list { key "prefix-set-name direction"; description "List of distribute-lists, which are used to filter in-coming or out-going routing updates."; Liu, et al. Expires February 29, 2020 [Page 21] Internet-Draft YANG RIP August 2019 leaf prefix-set-name { type prefix-set-ref; description "Reference to a prefix list to be applied to RIPv2 or RIPng packets."; } leaf direction { type enumeration { enum "in" { description "Apply the distribute-list to in-coming routes."; } enum "out" { description "Apply the distribute-list to out-going routes."; } } description "Direction of the routing updates."; } leaf if-name { type if:interface-ref; description "Reference to an interface to which the prefix list is applied."; } } } // distribute-lists grouping route-attributes { description "Grouping for route attributes."; leaf redistributed { type boolean; description "Redistributed routes"; } leaf route-type { type enumeration { enum connected { description "Connected route."; } enum external { description "External route."; } Liu, et al. Expires February 29, 2020 [Page 22] Internet-Draft YANG RIP August 2019 enum external-backup { description "External backup route."; } enum rip { description "RIP route."; } } description "Route type."; } leaf metric { type uint8 { range 0..16; } description "Route metric."; } leaf expire-time { type uint16; description "Expiration time."; } leaf deleted { type boolean; description "Deleted route."; } leaf holddown { type boolean; description "Holddown route."; } leaf need-triggered-update { type boolean; description "The route needs triggered update."; } leaf inactive { type boolean; description "The route is inactive."; } leaf flush-expire-before-holddown { type boolean; description "The flush timer expired before holddown time."; } } // route-attribute /* * Configuration data and operational state data nodes */ augment "/rt:routing/rt:control-plane-protocols/" Liu, et al. Expires February 29, 2020 [Page 23] Internet-Draft YANG RIP August 2019 + "rt:control-plane-protocol" { when "derived-from(rt:type, 'rip:rip')" { description "This augment is only valid for a routing protocol instance of RIP (type 'ripv2' or 'ripng')."; } description "RIP augmentation."; container rip { description "RIP data."; uses global-attributes; uses distribute-lists; uses redistribute-container; uses timers-container; container interfaces { description "Containing a list of RIP interfaces."; list interface { key "interface"; description "List of RIP interfaces."; leaf interface { type if:interface-ref; must "(derived-from-or-self(" + "../../../../rt:type, 'rip:ripv2') and " + "/if:interfaces/if:interface[if:name=current()]/" + "ip:ipv4) or " + "(derived-from-or-self(" + "../../../../rt:type, 'rip:ripng') and " + "/if:interfaces/if:interface[if:name=current()]/" + "ip:ipv6)" { error-message "Invalid interface type."; description "RIPv2 can be enabled on IPv4 interfae, and RIPng can be enabled on IPv6 interface."; } description "Enable RIP on this interface."; } container authentication { when "derived-from-or-self(" + "../../../../rt:type, 'rip:ripv2')" { description "Only applicable to RIPv2."; } Liu, et al. Expires February 29, 2020 [Page 24] Internet-Draft YANG RIP August 2019 description "Enables authentication and specifies the authentication scheme for the RIP interface"; choice auth-type-selection { description "Specify the authentication scheme."; reference "RFC8177: YANG Data Model for Key Chains."; case auth-key-chain { leaf key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key { leaf key { type string; description "Key string in ASCII format."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } } container bfd { if-feature bfd; description "BFD configuration."; uses bfd-types:client-cfg-parms; } leaf cost { type uint8 { range 1..16; } default 1; description "Interface cost."; } container neighbors { Liu, et al. Expires February 29, 2020 [Page 25] Internet-Draft YANG RIP August 2019 if-feature explicit-neighbors; description "Specifies the RIP neighbors. Useful for a non-broadcast multiple access (NBMA) network."; list neighbor { key "address"; description "Specify a RIP neighbor on a non-broadcast network."; leaf address { type inet:ip-address; description "Neighbor IP address."; } } } leaf no-listen { type empty; description "Disables listening to and processing of RIPv2 or RIPng packets on the specified interface."; } uses originate-default-route-container; leaf passive { type empty; description "Disables sending of RIPv2 or RIPng packets on the specified interface."; } leaf split-horizon { type enumeration { enum disabled { description "Disables split-horizon processing."; } enum simple { description "Enables simple split-horizon processing."; } enum poison-reverse { description "Enables split-horizon processing with poison reverse."; } } default simple; Liu, et al. Expires February 29, 2020 [Page 26] Internet-Draft YANG RIP August 2019 description "Controls RIPv2 or RIPng split-horizon processing on the specified interface."; } container summary-address { description "Summarizes information about RIPv2 or RIPng routes sent over the specified interface in RIPv2 or RIPng update packets."; leaf address { type inet:ip-prefix; description "Specifies the IP address and the prefix length that identify the routes to be summarized. The IP address can be specified in either IPv4 or IPv6 format, as specified in RFC6991."; } leaf metric { type uint8 { range 0..16; } description "Metric used for the route. If this attribute is not used, the value set through the default-metric attribute in RIPv2 or RIPng router configuration is used for the route. "; } } uses timers-container; /* Operational state */ leaf oper-status { type enumeration { enum up { description "RIPv2 or RIPng is operational on this interface."; } enum down { description "RIPv2 or RIPng is not operational on this interface."; } } config false; description "Operational state."; Liu, et al. Expires February 29, 2020 [Page 27] Internet-Draft YANG RIP August 2019 } leaf next-full-update { type uint32; config false; description "Next full update time."; } leaf valid-address { type boolean; config false; description "The interface has a valid address."; } container statistics { if-feature interface-statistics; config false; description "Interface statistic counters."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of the statistic counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } leaf bad-packets-rcvd { type yang:counter32; description "The number of RIP invalid packets received by the RIP process which were subsequently discarded for any reason (e.g. a version 0 packet, or an unknown command type)."; } leaf bad-routes-rcvd { type yang:counter32; description "The number of routes, in valid RIP packets, which were ignored for any reason (e.g. unknown address family, or invalid metric)."; } leaf updates-sent { type yang:counter32; description Liu, et al. Expires February 29, 2020 [Page 28] Internet-Draft YANG RIP August 2019 "The number of triggered RIP updates actually sent on this interface. This explicitly does NOT include full updates sent containing new information."; } } } // interface } // interfaces /* Operational state */ leaf next-triggered-update { type uint32; config false; description "Next triggered update."; } leaf num-of-routes { type uint32; config false; description "The number of routes."; } container ipv4 { when "derived-from-or-self(../../rt:type, 'rip:ripv2')" { description "IPv4 address family is supported by RIPv2."; } config false; description "IPv4 address family information."; container neighbors { description "IPv4 neighbor information."; list neighbor { key "ipv4-address"; description "A RIPv2 neighbor."; leaf ipv4-address { type inet:ipv4-address; description "IP address that a RIP neighbor is using as its source address."; } leaf last-update { type yang:date-and-time; description Liu, et al. Expires February 29, 2020 [Page 29] Internet-Draft YANG RIP August 2019 "The time when the most recent RIP update was received from this neighbor."; } leaf bad-packets-rcvd { type yang:counter32; description "The number of RIP invalid packets received from this neighbor which were subsequently discarded for any reason (e.g. a version 0 packet, or an unknown command type)."; } leaf bad-routes-rcvd { type yang:counter32; description "The number of routes received from this neighbor, in valid RIP packets, which were ignored for any reason (e.g. unknown address family, or invalid metric)."; } } // neighbor } // neighbors container routes { description "IPv4 route information."; list route { key "ipv4-prefix"; description "A RIPv2 IPv4 route."; leaf ipv4-prefix { type inet:ipv4-prefix; description "IPv4 address and prefix length, in the format specified in RFC6991."; } leaf next-hop { type inet:ipv4-address; description "Next hop IPv4 address."; } leaf interface { type if:interface-ref; description "The interface that the route uses."; } uses route-attributes; } // route } // routes Liu, et al. Expires February 29, 2020 [Page 30] Internet-Draft YANG RIP August 2019 } // ipv4 container ipv6 { when "derived-from-or-self(../../rt:type, 'rip:ripng')" { description "IPv6 address family is supported by RIPng."; } config false; description "IPv6 address family information."; container neighbors { description "IPv6 neighbor information."; list neighbor { key "ipv6-address"; description "A RIPng neighbor."; leaf ipv6-address { type inet:ipv6-address; description "IP address that a RIP neighbor is using as its source address."; } leaf last-update { type yang:date-and-time; description "The time when the most recent RIP update was received from this neighbor."; } leaf bad-packets-rcvd { type yang:counter32; description "The number of RIP invalid packets received from this neighbor which were subsequently discarded for any reason (e.g. a version 0 packet, or an unknown command type)."; } leaf bad-routes-rcvd { type yang:counter32; description "The number of routes received from this neighbor, in valid RIP packets, which were ignored for any reason (e.g. unknown address family, or invalid metric)."; } } // neighbor } // neighbors container routes { Liu, et al. Expires February 29, 2020 [Page 31] Internet-Draft YANG RIP August 2019 description "IPv6 route information."; list route { key "ipv6-prefix"; description "A RIPng IPv6 route."; leaf ipv6-prefix { type inet:ipv6-prefix; description "IPv6 address and prefix length, in the format specified in RFC6991."; } leaf next-hop { type inet:ipv6-address; description "Next hop IPv6 address."; } leaf interface { type if:interface-ref; description "The interface that the route uses."; } uses route-attributes; } // route } // routes } // ipv6 container statistics { if-feature global-statistics; config false; description "Global statistic counters."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of the statistic counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } leaf requests-rcvd { type yang:counter32; description "The number of requests received by RIP."; } Liu, et al. Expires February 29, 2020 [Page 32] Internet-Draft YANG RIP August 2019 leaf requests-sent { type yang:counter32; description "The number of requests sent by RIP."; } leaf responses-rcvd { type yang:counter32; description "The number of responses received by RIP."; } leaf responses-sent { type yang:counter32; description "The number of responses sent by RIP."; } } // statistics } // container rip } /* * RPCs */ rpc clear-rip-route { description "Clears RIP routes from the IP routing table and routes redistributed into the RIP protocol for the specified RIP instance or for all RIP instances in the current context."; input { leaf rip-instance { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } description "Instance name identifying a specific RIP instance. This leaf is optional for the rpc. If it is specified, the rpc will clear all routes in the specified RIP instance; if it is not specified, the rpc will clear all routes in all RIP instances."; } } } // rcp clear-rip-route } Liu, et al. Expires February 29, 2020 [Page 33] Internet-Draft YANG RIP August 2019 5. IANA Considerations RFC Ed.: In this section, replace all occurrences of 'XXXX' with the actual RFC number (and remove this note). This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-rip Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document registers the following YANG modules in the YANG Module Names registry [RFC7950]: -------------------------------------------------------------------- name: ietf-rip namespace: urn:ietf:params:xml:ns:yang:ietf-rip prefix: rip reference: RFC XXXX -------------------------------------------------------------------- 6. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: Liu, et al. Expires February 29, 2020 [Page 34] Internet-Draft YANG RIP August 2019 /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ rip:rip Unauthorized access to any data node of these subtrees can adversely affect the routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/ rip:rip Unauthorized access to any data node of these subtrees can disclose the operational state information of RIP on this device. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: RPC clear-rip-route: Unauthorized access to the RPC above can adversely affect the routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems. 7. References 7.1. Normative References [RFC1724] Malkin, G. and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, DOI 10.17487/RFC1724, November 1994, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, . Liu, et al. Expires February 29, 2020 [Page 35] Internet-Draft YANG RIP August 2019 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, DOI 10.17487/RFC2080, January 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [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, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . Liu, et al. Expires February 29, 2020 [Page 36] Internet-Draft YANG RIP August 2019 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 7.2. Informative References [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . [I-D.ietf-netconf-subscribed-notifications] Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Event Notifications", draft-ietf-netconf-subscribed-notifications-26 (work in progress), May 2019. [I-D.ietf-netconf-yang-push] Clemm, A. and E. Voit, "Subscription to YANG Datastores", draft-ietf-netconf-yang-push-25 (work in progress), May 2019. [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work in progress), August 2018. Liu, et al. Expires February 29, 2020 [Page 37] Internet-Draft YANG RIP August 2019 [I-D.ietf-isis-yang-isis-cfg] Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. Lhotka, "YANG Data Model for IS-IS Protocol", draft-ietf- isis-yang-isis-cfg-35 (work in progress), March 2019. [I-D.ietf-ospf-yang] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for OSPF Protocol", draft-ietf-ospf- yang-28 (work in progress), August 2019. Liu, et al. Expires February 29, 2020 [Page 38] Internet-Draft YANG RIP August 2019 Appendix A. Data Tree Example This section contains an example of an instance data tree in the JSON encoding [RFC7951], containing both configuration and state data. +---------------------+ | | | Router 203.0.113.1 | | | +----------+----------+ |eth1 |2001:db8:0:1::1/64 | | |2001:db8:0:1::2/64 +----------+----------+ | | | | Another Router +---------| 2001:db8:0:2::/64 | | | +---------------------+ The configuration instance data tree for Router 203.0.113.1 in the above figure could be as follows: Liu, et al. Expires February 29, 2020 [Page 39] Internet-Draft YANG RIP August 2019 { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth1", "description": "An interface with RIPng enabled.", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:1::1", "prefix-length": 64 } ], "forwarding": true } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.1", "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-rip:ripng", "name": "ripng-1", "description": "RIPng instance ripng-1.", "ietf-rip:rip": { "redistribute": { "connected": { } } "interfaces": { "interface": [ { "interface": "eth1", "split-horizon": "poison-reverse" } ] } } } ] } } } Liu, et al. Expires February 29, 2020 [Page 40] Internet-Draft YANG RIP August 2019 The cooresponding operational state data for Router 203.0.113.1 could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth1", "description": "An interface with RIPng enabled.", "type": "iana-if-type:ethernetCsmacd", "phys-address": "00:00:5e:00:53:01", "oper-status": "up", "statistics": { "discontinuity-time": "2016-10-24T17:11:27+02:00" }, "ietf-ip:ipv6": { "forwarding": true, "mtu": 1500, "address": [ { "ip": "2001:db8:0:1::1", "prefix-length": 64, "origin": "static", "status": "preferred" }, { "ip": "fe80::200:5eff:fe00:5301", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ { "ip": "2001:db8:0:1::2", "link-layer-address": "00:00:5e:00:53:02", "origin": "dynamic", "is-router": [null], "state": "reachable" }, { "ip": "fe80::200:5eff:fe00:5302", "link-layer-address": "00:00:5e:00:53:02", "origin": "dynamic", "is-router": [null], "state": "reachable" } ] Liu, et al. Expires February 29, 2020 [Page 41] Internet-Draft YANG RIP August 2019 } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.1", "interfaces": { "interface": [ "eth1" ] }, "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-rip:ripng", "name": "ripng-1", "description": "RIPng instance ripng-1.", "ietf-rip:rip": { "default-metric": 1, "next-triggered-update": 5 "interfaces": { "interface": [ { "interface": "eth1", "oper-status": "up", "cost": 1, "split-horizon": "poison-reverse", "valid-address": true } ] }, "ipv6" { "neighbors": { "neighbor": [ { "address": "fe80::200:5eff:fe00:5302", "last-update": "2017-01-02T10:34:55+02:00" } ] } "routes": { "route": [ { "ipv6-prefix": "2001:db8:0:1::/64", "interface": "eth1", "redistributed": true, "route-type": "connected", "metric": 1, Liu, et al. Expires February 29, 2020 [Page 42] Internet-Draft YANG RIP August 2019 "expire-time": 22 }, { "ipv6-prefix": "2001:db8:0:2::/64", "next-hop": "fe80::200:5eff:fe00:5302", "interface": "eth1", "redistributed": false, "route-type": "rip", "metric": 2, "expire-time": 82 } ] } }, "statistics": { "discontinuity-time": "2016-10-24T17:11:27+02:00", "requests-rcvd": 523, "requests-sent": 262, "responses-rcvd": 261, "responses-sent": 523 } } } ] } } } Authors' Addresses Xufeng Liu Volta Networks EMail: xufeng.liu.ietf@gmail.com Prateek Sarda Ericsson Fern Icon, Survey No 28 and 36/5, Doddanakundi Village Bangalore Karnataka 560037 India EMail: prateek.sarda@ericsson.com Liu, et al. Expires February 29, 2020 [Page 43] Internet-Draft YANG RIP August 2019 Vikram Choudhary Individual Bangalore 560066 India EMail: vikschw@gmail.com Liu, et al. Expires February 29, 2020 [Page 44] ./draft-ietf-oauth-jwt-bcp-07.txt0000644000764400076440000010522113550627157016057 0ustar iustyiusty OAuth Working Group Y. Sheffer Internet-Draft Intuit Updates: RFC 7519 (if approved) D. Hardt Intended status: Best Current Practice Expires: April 15, 2020 M. Jones Microsoft October 13, 2019 JSON Web Token Best Current Practices draft-ietf-oauth-jwt-bcp-07 Abstract JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. 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 https://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 15, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Sheffer, et al. Expires April 15, 2020 [Page 1] Internet-Draft JWT BCP October 2019 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. Target Audience . . . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions used in this document . . . . . . . . . . . . 4 2. Threats and Vulnerabilities . . . . . . . . . . . . . . . . . 4 2.1. Weak Signatures and Insufficient Signature Validation . . 4 2.2. Weak Symmetric Keys . . . . . . . . . . . . . . . . . . . 5 2.3. Incorrect Composition of Encryption and Signature . . . . 5 2.4. Plaintext Leakage through Analysis of Ciphertext Length . 5 2.5. Insecure Use of Elliptic Curve Encryption . . . . . . . . 5 2.6. Multiplicity of JSON Encodings . . . . . . . . . . . . . 6 2.7. Substitution Attacks . . . . . . . . . . . . . . . . . . 6 2.8. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 6 2.9. Indirect Attacks on the Server . . . . . . . . . . . . . 6 3. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Perform Algorithm Verification . . . . . . . . . . . . . 7 3.2. Use Appropriate Algorithms . . . . . . . . . . . . . . . 7 3.3. Validate All Cryptographic Operations . . . . . . . . . . 8 3.4. Validate Cryptographic Inputs . . . . . . . . . . . . . . 8 3.5. Ensure Cryptographic Keys have Sufficient Entropy . . . . 8 3.6. Avoid Length-Dependent Encryption Inputs . . . . . . . . 9 3.7. Use UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 9 3.8. Validate Issuer and Subject . . . . . . . . . . . . . . . 9 3.9. Use and Validate Audience . . . . . . . . . . . . . . . . 9 3.10. Do Not Trust Received Claims . . . . . . . . . . . . . . 10 3.11. Use Explicit Typing . . . . . . . . . . . . . . . . . . . 10 3.12. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs . . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Document History . . . . . . . . . . . . . . . . . . 15 A.1. draft-ietf-oauth-jwt-bcp-07 . . . . . . . . . . . . . . . 15 A.2. draft-ietf-oauth-jwt-bcp-06 . . . . . . . . . . . . . . . 15 A.3. draft-ietf-oauth-jwt-bcp-05 . . . . . . . . . . . . . . . 15 A.4. draft-ietf-oauth-jwt-bcp-04 . . . . . . . . . . . . . . . 15 A.5. draft-ietf-oauth-jwt-bcp-03 . . . . . . . . . . . . . . . 15 A.6. draft-ietf-oauth-jwt-bcp-02 . . . . . . . . . . . . . . . 15 Sheffer, et al. Expires April 15, 2020 [Page 2] Internet-Draft JWT BCP October 2019 A.7. draft-ietf-oauth-jwt-bcp-01 . . . . . . . . . . . . . . . 15 A.8. draft-ietf-oauth-jwt-bcp-00 . . . . . . . . . . . . . . . 15 A.9. draft-sheffer-oauth-jwt-bcp-01 . . . . . . . . . . . . . 15 A.10. draft-sheffer-oauth-jwt-bcp-00 . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON- based security tokens that contain a set of claims that can be signed and/or encrypted. The JWT specification has seen rapid adoption because it encapsulates security-relevant information in one easy-to- protect location, and because it is easy to implement using widely- available tools. One application area in which JWTs are commonly used is representing digital identity information, such as OpenID Connect ID Tokens [OpenID.Core] and OAuth 2.0 [RFC6749] access tokens and refresh tokens, the details of which are deployment-specific. Since the JWT specification was published, there have been several widely published attacks on implementations and deployments. Such attacks are the result of under-specified security mechanisms, as well as incomplete implementations and incorrect usage by applications. The goal of this document is to facilitate secure implementation and deployment of JWTs. Many of the recommendations in this document are about implementation and use of the cryptographic mechanisms underlying JWTs that are defined by JSON Web Signature (JWS) [RFC7515], JSON Web Encryption (JWE) [RFC7516], and JSON Web Algorithms (JWA) [RFC7518]. Others are about use of the JWT claims themselves. These are intended to be minimum recommendations for the use of JWTs in the vast majority of implementation and deployment scenarios. Other specifications that reference this document can have stricter requirements related to one or more aspects of the format, based on their particular circumstances; when that is the case, implementers are advised to adhere to those stricter requirements. Furthermore, this document provides a floor, not a ceiling, so stronger options are always allowed (e.g., depending on differing evaluations of the importance of cryptographic strength vs. computational load). Community knowledge about the strength of various algorithms and feasible attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document. Sheffer, et al. Expires April 15, 2020 [Page 3] Internet-Draft JWT BCP October 2019 1.1. Target Audience The intended audience of this document is: - Implementers of JWT libraries (and the JWS and JWE libraries used by those libraries), - Implementers of code that uses such libraries (to the extent that some mechanisms may not be provided by libraries, or until they are), and - Developers of specifications that rely on JWTs, both inside and outside the IETF. 1.2. Conventions used in this document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Threats and Vulnerabilities This section lists some known and possible problems with JWT implementations and deployments. Each problem description is followed by references to one or more mitigations to those problems. 2.1. Weak Signatures and Insufficient Signature Validation Signed JSON Web Tokens carry an explicit indication of the signing algorithm, in the form of the "alg" header parameter, to facilitate cryptographic agility. This, in conjunction with design flaws in some libraries and applications, have led to several attacks: - The algorithm can be changed to "none" by an attacker, and some libraries would trust this value and "validate" the JWT without checking any signature. - An "RS256" (RSA, 2048 bit) parameter value can be changed into "HS256" (HMAC, SHA-256), and some libraries would try to validate the signature using HMAC-SHA256 and using the RSA public key as the HMAC shared secret (see [McLean] and CVE-2015-9235). For mitigations, see Section 3.1 and Section 3.2. Sheffer, et al. Expires April 15, 2020 [Page 4] Internet-Draft JWT BCP October 2019 2.2. Weak Symmetric Keys In addition, some applications use a keyed MAC algorithm such as "HS256" to sign tokens, but supply a weak symmetric key with insufficient entropy (such as a human memorable password). Such keys are vulnerable to offline brute-force or dictionary attacks once an attacker gets hold of such a token [Langkemper]. For mitigations, see Section 3.5. 2.3. Incorrect Composition of Encryption and Signature Some libraries that decrypt a JWE-encrypted JWT to obtain a JWS- signed object do not always validate the internal signature. For mitigations, see Section 3.3. 2.4. Plaintext Leakage through Analysis of Ciphertext Length Many encryption algorithms leak information about the length of the plaintext, with a varying amount of leakage depending on the algorithm and mode of operation. This problem is exacerbated when the plaintext is initially compressed, because the length of the compressed plaintext and, thus, the ciphertext depend not only on the length of the original plaintext but also on its content. Compression attacks are particularly powerful when there is attacker- controlled data in the same compression space as secret data, as is the case for some attacks on HTTPS. See [Kelsey] for general background on compression and encryption, and [Alawatugoda] for a specific example of attacks on HTTP cookies. For mitigations, see Section 3.6. 2.5. Insecure Use of Elliptic Curve Encryption Per [Sanso], several JOSE libraries fail to validate their inputs correctly when performing elliptic curve key agreement (the "ECDH-ES" algorithm). An attacker that is able to send JWEs of its choosing that use invalid curve points and observe the cleartext outputs resulting from decryption with the invalid curve points can use this vulnerability to recover the recipient's private key. For mitigations, see Section 3.4. Sheffer, et al. Expires April 15, 2020 [Page 5] Internet-Draft JWT BCP October 2019 2.6. Multiplicity of JSON Encodings Previous versions of the JSON format such as the obsoleted [RFC7159] allowed several different character encodings: UTF-8, UTF-16 and UTF- 32. This is not the case anymore, with the latest standard [RFC8259] only allowing UTF-8 except for internal use within a "closed ecosystem". This ambiguity where older implementations and those used within closed environments may generate non-standard encodings, may result in the JWT being misinterpreted by its recipient. This in turn could be used by a malicious sender to bypass the recipient's validation checks. For mitigations, see Section 3.7. 2.7. Substitution Attacks There are attacks in which one recipient will be given a JWT that was intended for it, and will attempt to use it at a different recipient for which that JWT was not intended. For instance, if an OAuth 2.0 [RFC6749] access token is legitimately presented to an OAuth 2.0 protected resource for which it is intended, that protected resource might then present that same access token to a different protected resource for which the access token is not intended, in an attempt to gain access. If such situations are not caught, this can result in the attacker gaining access to resources that it is not entitled to access. For mitigations, see Section 3.8 and Section 3.9. 2.8. Cross-JWT Confusion As JWTs are being used by more different protocols in diverse application areas, it becomes increasingly important to prevent cases of JWT tokens that have been issued for one purpose being subverted and used for another. Note that this is a specific type of substitution attack. If the JWT could be used in an application context in which it could be confused with other kinds of JWTs, then mitigations MUST be employed to prevent these substitution attacks. For mitigations, see Section 3.8, Section 3.9, Section 3.11, and Section 3.12. 2.9. Indirect Attacks on the Server Various JWT claims are used by the recipient to perform lookup operations, such as database and LDAP searches. Others include URLs that are similarly looked up by the server. Any of these claims can Sheffer, et al. Expires April 15, 2020 [Page 6] Internet-Draft JWT BCP October 2019 be used by an attacker as vectors for injection attacks or server- side request forgery (SSRF) attacks. For mitigations, see Section 3.10. 3. Best Practices The best practices listed below should be applied by practitioners to mitigate the threats listed in the preceding section. 3.1. Perform Algorithm Verification Libraries MUST enable the caller to specify a supported set of algorithms and MUST NOT use any other algorithms when performing cryptographic operations. The library MUST ensure that the "alg" or "enc" header specifies the same algorithm that is used for the cryptographic operation. Moreover, each key MUST be used with exactly one algorithm, and this MUST be checked when the cryptographic operation is performed. 3.2. Use Appropriate Algorithms As Section 5.2 of [RFC7515] says, "it is an application decision which algorithms may be used in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid." Therefore, applications MUST only allow the use of cryptographically current algorithms that meet the security requirements of the application. This set will vary over time as new algorithms are introduced and existing algorithms are deprecated due to discovered cryptographic weaknesses. Applications MUST therefore be designed to enable cryptographic agility. That said, if a JWT is cryptographically protected end-to-end by a transport layer, such as TLS using cryptographically current algorithms, there may be no need to apply another layer of cryptographic protections to the JWT. In such cases, the use of the "none" algorithm can be perfectly acceptable. The "none" algorithm should only be used when the JWT is cryptographically protected by other means. JWTs using "none" are often used in application contexts in which the content is optionally signed; then the URL-safe claims representation and processing can be the same in both the signed and unsigned cases. JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly requested to do by the caller. Similarly, JWT libraries SHOULD NOT consume JWTs using "none" unless explicitly requested by the caller. Sheffer, et al. Expires April 15, 2020 [Page 7] Internet-Draft JWT BCP October 2019 Applications SHOULD follow these algorithm-specific recommendations: - Avoid all RSA-PKCS1 v1.5 encryption algorithms ([RFC8017], Sec. 7.2}, preferring RSA-OAEP ([RFC8017], Sec. 7.1). - ECDSA signatures [ANSI-X962-2005] require a unique random value for every message that is signed. If even just a few bits of the random value are predictable across multiple messages then the security of the signature scheme may be compromised. In the worst case, the private key may be recoverable by an attacker. To counter these attacks, JWT libraries SHOULD implement ECDSA using the deterministic approach defined in [RFC6979]. This approach is completely compatible with existing ECDSA verifiers and so can be implemented without new algorithm identifiers being required. 3.3. Validate All Cryptographic Operations All cryptographic operations used in the JWT MUST be validated and the entire JWT MUST be rejected if any of them fail to validate. This is true not only of JWTs with a single set of Header Parameters but also for Nested JWTs, in which both outer and inner operations MUST be validated using the keys and algorithms supplied by the application. 3.4. Validate Cryptographic Inputs Some cryptographic operations, such as Elliptic Curve Diffie-Hellman key agreement ("ECDH-ES") take inputs that may contain invalid values, such as points not on the specified elliptic curve or other invalid points (see, e.g. [Valenta], Sec. 7.1). The JWS/JWE library itself must validate these inputs before using them or it must use underlying cryptographic libraries that do so (or both!). ECDH-ES ephemeral public key (epk) inputs should be validated according to the recipient's chosen elliptic curve. For the NIST prime-order curves P-256, P-384 and P-521, validation MUST be performed according to Section 5.6.2.3.4 "ECC Partial Public-Key Validation Routine" of NIST Special Publication 800-56A revision 3 [nist-sp-800-56a-r3]. Likewise, if the "X25519" or "X448" [RFC8037] algorithms are used, then the security considerations in [RFC8037] apply. 3.5. Ensure Cryptographic Keys have Sufficient Entropy The Key Entropy and Random Values advice in Section 10.1 of [RFC7515] and the Password Considerations in Section 8.8 of [RFC7518] MUST be followed. In particular, human-memorizable passwords MUST NOT be directly used as the key to a keyed-MAC algorithm such as "HS256". Sheffer, et al. Expires April 15, 2020 [Page 8] Internet-Draft JWT BCP October 2019 In particular, passwords should only be used to perform key encryption, rather than content encryption, as described in Section 4.8 of [RFC7518]. Note that even when used for key encryption, password-based encryption is still subject to brute-force attacks. 3.6. Avoid Length-Dependent Encryption Inputs Compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext. 3.7. Use UTF-8 [RFC7515], [RFC7516], and [RFC7519] all specify that UTF-8 be used for encoding and decoding JSON used in Header Parameters and JWT Claims Sets. This is also in line with the latest JSON specification [RFC8259]. Implementations and applications MUST do this, and not use or admit the use of other Unicode encodings for these purposes. 3.8. Validate Issuer and Subject When a JWT contains an "iss" (issuer) claim, the application MUST validate that the cryptographic keys used for the cryptographic operations in the JWT belong to the issuer. If they do not, the application MUST reject the JWT. The means of determining the keys owned by an issuer is application- specific. As one example, OpenID Connect [OpenID.Core] issuer values are "https" URLs that reference a JSON metadata document that contains a "jwks_uri" value that is an "https" URL from which the issuer's keys are retrieved as a JWK Set [RFC7517]. This same mechanism is used by [RFC8414]. Other applications may use different means of binding keys to issuers. Similarly, when the JWT contains a "sub" (subject) claim, the application MUST validate that the subject value corresponds to a valid subject and/or issuer/subject pair at the application. This may include confirming that the issuer is trusted by the application. If the issuer, subject, or the pair are invalid, the application MUST reject the JWT. 3.9. Use and Validate Audience If the same issuer can issue JWTs that are intended for use by more than one relying party or application, the JWT MUST contain an "aud" (audience) claim that can be used to determine whether the JWT is being used by an intended party or was substituted by an attacker at an unintended party. Sheffer, et al. Expires April 15, 2020 [Page 9] Internet-Draft JWT BCP October 2019 In such cases, the relying party or application MUST validate the audience value and if the audience value is not present or not associated with the recipient, it MUST reject the JWT. 3.10. Do Not Trust Received Claims The "kid" (key ID) header is used by the relying application to perform key lookup. Applications should ensure that this does not create SQL or LDAP injection vulnerabilities, by validating and/or sanitizing the received value. Similarly, blindly following a "jku" (JWK set URL) or "x5u" (X.509 URL) header, which may contain an arbitrary URL, could result in server-side request forgery (SSRF) attacks. Applications SHOULD protect against such attacks, e.g., by matching the URL to a whitelist of allowed locations, and ensuring no cookies are sent in the GET request. 3.11. Use Explicit Typing Sometimes, one kind of JWT can be confused for another. If a particular kind of JWT is subject to such confusion, that JWT can include an explicit JWT type value, and the validation rules can specify checking the type. This mechanism can prevent such confusion. Explicit JWT typing is accomplished by using the "typ" header parameter. For instance, the [RFC8417] specification uses the "application/secevent+jwt" media type to perform explicit typing of Security Event Tokens (SETs). Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix be omitted from the "typ" value. Therefore, for example, the "typ" value used to explicitly include a type for a SET SHOULD be "secevent+jwt". When explicit typing is employed for a JWT, it is RECOMMENDED that a media type name of the format "application/example+jwt" be used, where "example" is replaced by the identifier for the specific kind of JWT. When applying explicit typing to a Nested JWT, the "typ" header parameter containing the explicit type value MUST be present in the inner JWT of the Nested JWT (the JWT whose payload is the JWT Claims Set). In some cases the same "typ" header parameter value will be present in the outer JWT as well, to explicitly type the entire Nested JWT. Note that the use of explicit typing may not achieve disambiguation from existing kinds of JWTs, as the validation rules for existing kinds JWTs often do not use the "typ" header parameter value. Explicit typing is RECOMMENDED for new uses of JWTs. Sheffer, et al. Expires April 15, 2020 [Page 10] Internet-Draft JWT BCP October 2019 3.12. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs Each application of JWTs defines a profile specifying the required and optional JWT claims and the validation rules associated with them. If more than one kind of JWT can be issued by the same issuer, the validation rules for those JWTs MUST be written such that they are mutually exclusive, rejecting JWTs of the wrong kind. To prevent substitution of JWTs from one context into another, application developers may employ a number of strategies: - Use explicit typing for different kinds of JWTs. Then the distinct "typ" values can be used to differentiate between the different kinds of JWTs. - Use different sets of required claims or different required claim values. Then the validation rules for one kind of JWT will reject those with different claims or values. - Use different sets of required header parameters or different required header parameter values. Then the validation rules for one kind of JWT will reject those with different header parameters or values. - Use different keys for different kinds of JWTs. Then the keys used to validate one kind of JWT will fail to validate other kinds of JWTs. - Use different "aud" values for different uses of JWTs from the same issuer. Then audience validation will reject JWTs substituted into inappropriate contexts. - Use different issuers for different kinds of JWTs. Then the distinct "iss" values can be used to segregate the different kinds of JWTs. Given the broad diversity of JWT usage and applications, the best combination of types, required claims, values, header parameters, key usages, and issuers to differentiate among different kinds of JWTs will, in general, be application specific. As discussed in Section 3.11, for new JWT applications, the use of explicit typing is RECOMMENDED. 4. Security Considerations This entire document is about security considerations when implementing and deploying JSON Web Tokens. Sheffer, et al. Expires April 15, 2020 [Page 11] Internet-Draft JWT BCP October 2019 5. IANA Considerations This document requires no IANA actions. 6. Acknowledgements Thanks to Antonio Sanso for bringing the "ECDH-ES" invalid point attack to the attention of JWE and JWT implementers. Tim McLean [McLean] published the RSA/HMAC confusion attack. Thanks to Nat Sakimura for advocating the use of explicit typing. Thanks to Neil Madden for his numerous comments, and to Carsten Bormann, Brian Campbell, Brian Carpenter, Alissa Cooper, Roman Danyliw, Ben Kaduk, Mirja Kuehlewind, Barry Leiba, Eric Rescorla, Adam Roach, Martin Vigoureux, and Eric Vyncke for their reviews. 7. References 7.1. Normative References [nist-sp-800-56a-r3] Barker, E., Chen, L., Keller, S., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, Draft NIST Special Publication 800-56A Revision 3", April 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . Sheffer, et al. Expires April 15, 2020 [Page 12] Internet-Draft JWT BCP October 2019 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 7.2. Informative References [Alawatugoda] Alawatugoda, J., Stebila, D., and C. Boyd, "Protecting Encrypted Cookies from Compression Side-Channel Attacks", Financial Cryptography and Data Security pp. 86-106, DOI 10.1007/978-3-662-47854-7_6, 2015. [ANSI-X962-2005] "American National Standard X9.62: The Elliptic Curve Digital Signature Algorithm (ECDSA)", November 2005. [Kelsey] Kelsey, J., "Compression and Information Leakage of Plaintext", Fast Software Encryption pp. 263-276, DOI 10.1007/3-540-45661-9_21, 2002. [Langkemper] Langkemper, S., "Attacking JWT Authentication", September 2016, . [McLean] McLean, T., "Critical vulnerabilities in JSON Web Token libraries", March 2015, . Sheffer, et al. Expires April 15, 2020 [Page 13] Internet-Draft JWT BCP October 2019 [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, . [Sanso] Sanso, A., "Critical Vulnerability Uncovered in JSON Encryption", March 2017, . [Valenta] Valenta, L., Sullivan, N., Sanso, A., and N. Heninger, "In search of CurveSwap: Measuring elliptic curve implementations in the wild", March 2018, . Sheffer, et al. Expires April 15, 2020 [Page 14] Internet-Draft JWT BCP October 2019 Appendix A. Document History [[ to be removed by the RFC editor before publication as an RFC ]] A.1. draft-ietf-oauth-jwt-bcp-07 - IESG review comments. A.2. draft-ietf-oauth-jwt-bcp-06 - Second AD review. - Removed unworkable recommendation to pad encrypted passwords. A.3. draft-ietf-oauth-jwt-bcp-05 - Genart review comments. A.4. draft-ietf-oauth-jwt-bcp-04 - AD review comments. A.5. draft-ietf-oauth-jwt-bcp-03 - Acknowledgements. A.6. draft-ietf-oauth-jwt-bcp-02 - Implemented WGLC feedback. A.7. draft-ietf-oauth-jwt-bcp-01 - Feedback from Brian Campbell. A.8. draft-ietf-oauth-jwt-bcp-00 - Initial WG draft. No change from the latest individual version. A.9. draft-sheffer-oauth-jwt-bcp-01 - Added explicit typing. A.10. draft-sheffer-oauth-jwt-bcp-00 - Initial version. Sheffer, et al. Expires April 15, 2020 [Page 15] Internet-Draft JWT BCP October 2019 Authors' Addresses Yaron Sheffer Intuit EMail: yaronf.ietf@gmail.com Dick Hardt EMail: dick.hardt@gmail.com Michael B. Jones Microsoft EMail: mbj@microsoft.com URI: http://self-issued.info/ Sheffer, et al. Expires April 15, 2020 [Page 16] ./draft-ietf-softwire-iftunnel-07.txt0000644000764400076440000007406713500446454017066 0ustar iustyiusty Softwire Working Group M. Boucadair Internet-Draft Orange Intended status: Standards Track I. Farrer Expires: December 15, 2019 Deutsche Telekom AG R. Asati Cisco Systems, Inc. June 13, 2019 Tunnel Interface Types YANG Module draft-ietf-softwire-iftunnel-07 Abstract This document specifies the initial version of a YANG module containing a collection of IANA maintained YANG identities, used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA web site. Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly. Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed. Editorial Note (To be removed by RFC Editor) Please update these statements in the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Tunnel Interface Types YANG Module"; o "reference: RFC XXXX" o "...must be updated as defined in RFCXXXX." Please update the "revision" date of the YANG modules. Boucadair, et al. Expires December 15, 2019 [Page 1] Internet-Draft Tunnel Interface Types June 2019 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 https://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 15, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. IANA Tunnel Type YANG Module . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.1. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Updates to the IANA tunnelType Table . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Example Usage . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Boucadair, et al. Expires December 15, 2019 [Page 2] Internet-Draft Tunnel Interface Types June 2019 1. Introduction This document specifies the initial version of the iana-tunnel-type YANG module containing a collection of IANA maintained YANG identities identifying tunnel interface types. The module reflects IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY]. The latest revision of this module can be obtained from the IANA web site. Tunnel-specific extensions may be added to the Interface module [RFC8343] as a function of the tunnel type. An example of this is provided in Appendix A. It is not the intention of this document to define tunnel-specific extensions for every tunnel encapsulation technology; those are discussed in dedicated documents such as [I-D.ietf-softwire-yang]. Likewise, it is out of the scope of this document to update the existing IANA registry [TUNNELTYPE-IANA-REGISTRY] with a comprehensive list of tunnel technologies. Guidelines and registration procedures for interface types and sub-types are discussed in [I-D.thaler-iftype-reg]. This document uses the common YANG types defined in [RFC6991] and adopts the Network Management Datastore Architecture (NMDA [RFC8342]). The terminology for describing YANG modules is defined in [RFC7950]. The meanings of the symbols used in the tree diagram are defined in [RFC8340]. 2. IANA Tunnel Type YANG Module The iana-tunnel-type module imports the 'iana-if-type' module defined in [RFC7224]. The initial version of the module includes tunnel types defined in [RFC4087], [RFC7856], [RFC7870], and [RFC6346]. file "iana-tunnel-type@2019-04-04.yang" module iana-tunnel-type { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-tunnel-type"; prefix iana-tunnel-type; import iana-if-type { prefix ift; reference "RFC 7224: IANA Interface Type YANG Module"; } Boucadair, et al. Expires December 15, 2019 [Page 3] Internet-Draft Tunnel Interface Types June 2019 organization "IANA"; contact "Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 "; description "This module contains a collection of YANG identities defined by IANA and used as interface types for tunnel interfaces. Copyright (c) 2019 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."; revision 2019-04-04 { description "Initial revision."; reference "RFC XXXX: Tunnel Interface Types YANG Module"; } identity other { base ift:tunnel; description "None of the following values."; reference "RFC 4087: IP Tunnel MIB"; } identity direct { base ift:tunnel; description "No intermediate header."; reference "RFC 2003: IP Encapsulation within IP Boucadair, et al. Expires December 15, 2019 [Page 4] Internet-Draft Tunnel Interface Types June 2019 RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers"; } identity gre { base ift:tunnel; description "GRE encapsulation."; reference "RFC 1701: Generic Routing Encapsulation (GRE) RFC 1702: Generic Routing Encapsulation over IPv4 networks RFC 7676: IPv6 Support for Generic Routing Encapsulation (GRE)"; } identity minimal { base ift:tunnel; description "Minimal encapsulation."; reference "RFC 2004: Minimal Encapsulation within IP"; } identity l2tp { base ift:tunnel; description "L2TP encapsulation."; reference "RFC 2661: Layer Two Tunneling Protocol (L2TP)"; } identity pptp { base ift:tunnel; description "PPTP encapsulation."; reference "RFC 2637: Point-to-Point Tunneling Protocol (PPTP)"; } identity l2f { base ift:tunnel; description "L2F encapsulation."; reference "RFC 2341: Cisco Layer Two Forwarding (Protocol) (L2F)"; } identity udp { base ift:tunnel; description "UDP encapsulation."; reference "Section 3.1.11 of RFC 8085"; } Boucadair, et al. Expires December 15, 2019 [Page 5] Internet-Draft Tunnel Interface Types June 2019 identity atmp { base ift:tunnel; description "ATMP encapsulation."; reference "RFC 2107: Ascend Tunnel Management Protocol - ATMP"; } identity msdp { base ift:tunnel; description "MSDP encapsulation."; reference "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; } identity sixtofour { base ift:tunnel; description "6to4 encapsulation."; reference "RFC 3056: Connection of IPv6 Domains via IPv4 Clouds"; } identity sixoverfour { base ift:tunnel; description "6over4 encapsulation."; reference "RFC 2529: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"; } identity isatap { base ift:tunnel; description "ISATAP encapsulation."; reference "RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)"; } identity teredo { base ift:tunnel; description "Teredo encapsulation."; reference "RFC 4380: Teredo- Tunneling IPv6 over UDP through Network Address Translations (NATs)"; } identity iphttps { base ift:tunnel; description Boucadair, et al. Expires December 15, 2019 [Page 6] Internet-Draft Tunnel Interface Types June 2019 "IP over HTTPS (IP-HTTPS) Tunneling Protocol."; reference "Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling Protocol Specification, https://msdn.microsoft.com/en-us/library/dd358571.aspx"; } identity softwiremesh { base ift:tunnel; description "softwire mesh tunnel."; reference "RFC 5565: Softwire Mesh Framework"; } identity dslite { base ift:tunnel; description "DS-Lite tunnel."; reference "RFC 6333: Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"; } identity aplusp { base ift:tunnel; description "A+P encapsulation."; reference "RFC 6346: The Address plus Port (A+P) Approach to the IPv4 Address Shortage"; } } 3. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Boucadair, et al. Expires December 15, 2019 [Page 7] Internet-Draft Tunnel Interface Types June 2019 The module defined in this document defines YANG identities for the iana-tunnel-types registry. These identities are intended to be referenced by other YANG modules, and by themselves do not expose any nodes which are writable, contain read-only state, or RPCs. As such, there are no additional security issues to be considered relating to the module defined in this document. 4. IANA Considerations 4.1. YANG Module This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:iana-tunnel-type Registrant Contact: IANA. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following following YANG module in the "YANG Module Names" subregistry [RFC7950] within the "YANG Parameters" registry. Name: iana-tunnel-type Namespace: urn:ietf:params:xml:ns:yang:iana-tunnel-type Prefix: iana-tunnel-type Reference: RFC XXXX This document defines the initial version of the IANA-maintained iana-tunnel-type YANG module. IANA is requested to add this note: Tunnel type values must not be directly added to the iana-tunnel- type YANG module. They must instead be respectively added to the "tunnelType" sub-registry (under the "ifType definitions" registry). When a tunnel type is added to the "tunnelType" sub-registry, a new "identity" statement must be added to the iana-tunnel-type YANG module. The name of the "identity" is the lower-case of the corresponding enumeration in the IANAifType-MIB (i.e., IANAtunnelType). The "identity" statement should have the following sub-statements defined: "base": Contains 'ift:tunnel'. "description": Replicates the description from the registry. "reference": Replicates the reference from the registry and add the title of the document. Boucadair, et al. Expires December 15, 2019 [Page 8] Internet-Draft Tunnel Interface Types June 2019 Unassigned or reserved values are not present in the module. When the iana-tunnel-type YANG module is updated, a new "revision" statement must be added in front of the existing revision statements. IANA is requested to add this note to "tunnelType" sub-registry: When this registry is modified, the YANG module iana-tunnel-type must be updated as defined in RFCXXXX. 4.2. Updates to the IANA tunnelType Table This document requests IANA to update the following entries available at https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#smi-numbers-6: OLD: Decimal Name Description References 2 direct no intermediate header [RFC4087] 3 gre GRE encapsulation [RFC4087] 4 minimal Minimal encapsulation [RFC4087] 5 l2tp L2TP encapsulation [RFC4087] 6 pptp PPTP encapsulation [RFC4087] 7 l2f L2F encapsulation [RFC4087] 8 udp UDP encapsulation [RFC4087] 9 atmp ATMP encapsulation [RFC4087] 10 msdp MSDP encapsulation [RFC4087] 11 sixToFour 6to4 encapsulation [RFC4087] 12 sixOverFour 6over4 encapsulation [RFC4087] 13 isatap ISATAP encapsulation [RFC4087] 14 teredo Teredo encapsulation [RFC4087] 16 softwireMesh softwire mesh tunnel [RFC7856] 17 dsLite DS-Lite tunnel [RFC7870] Boucadair, et al. Expires December 15, 2019 [Page 9] Internet-Draft Tunnel Interface Types June 2019 NEW: Decimal Name Description References 2 direct no intermediate header [RFC2003] [RFC4213] 3 gre GRE encapsulation [RFC1701] [RFC1702] [RFC7676] 4 minimal Minimal encapsulation [RFC2004] 5 l2tp L2TP encapsulation [RFC2661] 6 pptp PPTP encapsulation [RFC2637] 7 l2f L2F encapsulation [RFC2341] 8 udp UDP encapsulation [RFC8085] 9 atmp ATMP encapsulation [RFC2107] 10 msdp MSDP encapsulation [RFC3618] 11 sixToFour 6to4 encapsulation [RFC3056] 12 sixOverFour 6over4 encapsulation [RFC2529] 13 isatap ISATAP encapsulation [RFC5214] 14 teredo Teredo encapsulation [RFC4380] 16 softwireMesh softwire mesh tunnel [RFC5565] 17 dsLite DS-Lite tunnel [RFC6333] 5. Acknowledgements Special thanks to Tom Petch and Martin Bjorklund for the detailed review and suggestions. Thanks to Andy Bierman for the Yangdoctors review. Thanks to Dale Worley, David Black, and Yaron Sheffer for the review. 6. References 6.1. Normative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [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, . Boucadair, et al. Expires December 15, 2019 [Page 10] Internet-Draft Tunnel Interface Types June 2019 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [TUNNELTYPE-IANA-REGISTRY] Internet Assigned Numbers Authority, "ifType definitions: tunnelType", . 6.2. Informative References [I-D.ietf-softwire-yang] Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- IPv6 Address plus Port (A+P) Softwires", draft-ietf- softwire-yang-16 (work in progress), January 2019. [I-D.thaler-iftype-reg] Thaler, D. and D. Romascanu, "Guidelines and Registration Procedures for Interface Types", draft-thaler-iftype- reg-02 (work in progress), March 2019. Boucadair, et al. Expires December 15, 2019 [Page 11] Internet-Draft Tunnel Interface Types June 2019 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, DOI 10.17487/RFC1701, October 1994, . [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, DOI 10.17487/RFC1702, October 1994, . [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, . [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, DOI 10.17487/RFC2004, October 1996, . [RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, DOI 10.17487/RFC2107, February 1997, . [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, DOI 10.17487/RFC2341, May 1998, . [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, DOI 10.17487/RFC2529, March 1999, . [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, . [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, DOI 10.17487/RFC2661, August 1999, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . Boucadair, et al. Expires December 15, 2019 [Page 12] Internet-Draft Tunnel Interface Types June 2019 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, . [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, DOI 10.17487/RFC4087, June 2005, . [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, . [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008, . [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, . [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, . [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, . [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, . [RFC7856] Cui, Y., Dong, J., Wu, P., Xu, M., and A. Yla-Jaaski, "Softwire Mesh Management Information Base (MIB)", RFC 7856, DOI 10.17487/RFC7856, May 2016, . Boucadair, et al. Expires December 15, 2019 [Page 13] Internet-Draft Tunnel Interface Types June 2019 [RFC7870] Fu, Y., Jiang, S., Dong, J., and Y. Chen, "Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)", RFC 7870, DOI 10.17487/RFC7870, June 2016, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . Appendix A. Example Usage The following example illustrates how the Interface YANG module can be augmented with tunnel-specific parameters. In this example, the module is augmented with a 'remote-endpoint' for the tunnel. A tree structure is provided below: module: example-iftunnel-extension augment /if:interfaces/if:interface: +--rw remote-endpoint? inet:ipv6-address The 'example-iftunnel-extension' module imports the modules defined in [RFC6991] and [RFC8343] in addition to the "iana-tunnel-type" module defined in this document. module example-iftunnel-extension { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:example-iftunnel-extension"; prefix example; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-interfaces { prefix if; reference Boucadair, et al. Expires December 15, 2019 [Page 14] Internet-Draft Tunnel Interface Types June 2019 "RFC 8343: A YANG Data Model for Interface Management"; } import iana-tunnel-type { prefix iana-tunnel-type; reference "RFC XXXX: A Tunnel Extension to the Interface Management YANG Module"; } organization "IETF Softwire Working Group"; contact "WG Web: WG List: Author: Mohamed Boucadair "; description "This is an example YANG module to extend the Interface YANG module with tunnel-specific parameters. Copyright (c) 2019 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."; revision 2019-04-04 { description "Initial revision."; reference "RFC XXXX: Tunnel Interface Types YANG Module"; } augment "/if:interfaces/if:interface" { when "derived-from(if:type, 'iana-tunnel-type:gre')"; description "Augments Interface module with specific tunnel parameters."; Boucadair, et al. Expires December 15, 2019 [Page 15] Internet-Draft Tunnel Interface Types June 2019 leaf remote-endpoint { type inet:ipv6-address; description "IPv6 address of the remote GRE endpoint."; } } } Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Ian Farrer Deutsche Telekom AG CTO-ATI,Landgrabenweg 151 Bonn, NRW 53227 Germany Email: ian.farrer@telekom.de Rajiv Asati Cisco Systems, Inc. 7025 Kit Creek Rd. RTP, NC 27709 USA Email: Rajiva@cisco.com Boucadair, et al. Expires December 15, 2019 [Page 16] ./draft-ietf-oauth-mtls-17.txt0000644000764400076440000022575513530063656015504 0ustar iustyiusty OAuth Working Group B. Campbell Internet-Draft Ping Identity Intended status: Standards Track J. Bradley Expires: February 23, 2020 Yubico N. Sakimura Nomura Research Institute T. Lodderstedt YES.com AG August 22, 2019 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens draft-ietf-oauth-mtls-17 Abstract This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. 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 https://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 23, 2020. Campbell, et al. Expires February 23, 2020 [Page 1] Internet-Draft OAuth Mutual TLS August 2019 Copyright Notice Copyright (c) 2019 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 (https://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 Notation and Conventions . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 5 2.1. PKI Mutual-TLS Method . . . . . . . . . . . . . . . . . . 6 2.1.1. PKI Method Metadata Value . . . . . . . . . . . . . . 7 2.1.2. Client Registration Metadata . . . . . . . . . . . . 7 2.2. Self-Signed Certificate Mutual-TLS Method . . . . . . . . 8 2.2.1. Self-Signed Method Metadata Value . . . . . . . . . . 8 2.2.2. Client Registration Metadata . . . . . . . . . . . . 8 3. Mutual-TLS Client Certificate-Bound Access Tokens . . . . . . 9 3.1. JWT Certificate Thumbprint Confirmation Method . . . . . 10 3.2. Confirmation Method for Token Introspection . . . . . . . 11 3.3. Authorization Server Metadata . . . . . . . . . . . . . . 12 3.4. Client Registration Metadata . . . . . . . . . . . . . . 12 4. Public Clients and Certificate-Bound Tokens . . . . . . . . . 13 5. Metadata for Mutual-TLS Endpoint Aliases . . . . . . . . . . 13 6. Implementation Considerations . . . . . . . . . . . . . . . . 15 6.1. Authorization Server . . . . . . . . . . . . . . . . . . 15 6.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 16 6.3. Certificate Expiration and Bound Access Tokens . . . . . 16 6.4. Implicit Grant Unsupported . . . . . . . . . . . . . . . 16 6.5. TLS Termination . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7.1. Certificate-Bound Refresh Tokens . . . . . . . . . . . . 17 7.2. Certificate Thumbprint Binding . . . . . . . . . . . . . 17 7.3. TLS Versions and Best Practices . . . . . . . . . . . . . 18 7.4. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 18 7.5. X.509 Certificate Parsing and Validation Complexity . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 Campbell, et al. Expires February 23, 2020 [Page 2] Internet-Draft OAuth Mutual TLS August 2019 9.1. JWT Confirmation Methods Registration . . . . . . . . . . 19 9.2. Authorization Server Metadata Registration . . . . . . . 19 9.3. Token Endpoint Authentication Method Registration . . . . 20 9.4. Token Introspection Response Registration . . . . . . . . 20 9.5. Dynamic Client Registration Metadata Registration . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Example "cnf" Claim, Certificate and JWK . . . . . . 25 Appendix B. Relationship to Token Binding . . . . . . . . . . . 26 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix D. Document(s) History . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction The OAuth 2.0 Authorization Framework [RFC6749] enables third-party client applications to obtain delegated access to protected resources. In the prototypical abstract OAuth flow, illustrated in Figure 1, the client obtains an access token from an entity known as an authorization server and then uses that token when accessing protected resources, such as HTTPS APIs. +--------+ +---------------+ | | | | | |<--(A)-- Get an access token --->| Authorization | | | | Server | | | | | | | +---------------+ | | ^ | | | | | | | (C) | | Client | Validate the | | access token | | | | | | | | v | | +---------------+ | | | (C) | | | | | | |<--(B)-- Use the access token -->| Protected | | | | Resource | | | | | +--------+ +---------------+ Figure 1: Abstract OAuth 2.0 Protocol Flow Campbell, et al. Expires February 23, 2020 [Page 3] Internet-Draft OAuth Mutual TLS August 2019 The flow illustrated in Figure 1 includes the following steps: (A) The client makes an HTTPS "POST" request to the authorization server and presents a credential representing the authorization grant. For certain types of clients (those that have been issued or otherwise established a set of client credentials) the request must be authenticated. In the response, the authorization server issues an access token to the client. (B) The client includes the access token when making a request to access a protected resource. (C) The protected resource validates the access token in order to authorize the request. In some cases, such as when the token is self-contained and cryptographically secured, the validation can be done locally by the protected resource. Other cases require that the protected resource call out to the authorization server to determine the state of the token and obtain meta-information about it. Layering on the abstract flow above, this document standardizes enhanced security options for OAuth 2.0 utilizing client-certificate- based mutual TLS. Section 2 provides options for authenticating the request in step (A). Step (C) is supported with semantics to express the binding of the token to the client certificate for both local and remote processing in Section 3.1 and Section 3.2 respectively. This ensures that, as described in Section 3, protected resource access in step (B) is only possible by the legitimate client using a certificate-bound token and holding the private key corresponding to the certificate. OAuth 2.0 defines a shared-secret method of client authentication but also allows for definition and use of additional client authentication mechanisms when interacting directly with the authorization server. This document describes an additional mechanism of client authentication utilizing mutual-TLS certificate- based authentication, which provides better security characteristics than shared secrets. While [RFC6749] documents client authentication for requests to the token endpoint, extensions to OAuth 2.0 (such as Introspection [RFC7662], Revocation [RFC7009], and the Backchannel Authentication Endpoint in [OpenID.CIBA]) define endpoints that also utilize client authentication and the mutual TLS methods defined herein are applicable to those endpoints as well. Mutual-TLS certificate-bound access tokens ensure that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources. Such a constraint is sometimes referred to as key confirmation, proof-of- Campbell, et al. Expires February 23, 2020 [Page 4] Internet-Draft OAuth Mutual TLS August 2019 possession, or holder-of-key and is unlike the case of the bearer token described in [RFC6750], where any party in possession of the access token can use it to access the associated resources. Binding an access token to the client's certificate prevents the use of stolen access tokens or replay of access tokens by unauthorized parties. Mutual-TLS certificate-bound access tokens and mutual-TLS client authentication are distinct mechanisms, which are complementary but don't necessarily need to be deployed or used together. Additional client metadata parameters are introduced by this document in support of certificate-bound access tokens and mutual-TLS client authentication. The authorization server can obtain client metadata via the Dynamic Client Registration Protocol [RFC7591], which defines mechanisms for dynamically registering OAuth 2.0 client metadata with authorization servers. Also the metadata defined by RFC7591, and registered extensions to it, imply a general data model for clients that is useful for authorization server implementations even when the Dynamic Client Registration Protocol isn't in play. Such implementations will typically have some sort of user interface available for managing client configuration. 1.1. Requirements Notation and Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology Throughout this document the term "mutual TLS" refers to the process whereby, in addition to the normal TLS server authentication with a certificate, a client presents its X.509 certificate and proves possession of the corresponding private key to a server when negotiating a TLS session. In contemporary versions of TLS [RFC8446] [RFC5246] this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the CertificateVerify and Finished messages. 2. Mutual TLS for OAuth Client Authentication This section defines, as an extension of OAuth 2.0, Section 2.3 [RFC6749], two distinct methods of using mutual-TLS X.509 client certificates as client credentials. The requirement of mutual TLS for client authentication is determined by the authorization server Campbell, et al. Expires February 23, 2020 [Page 5] Internet-Draft OAuth Mutual TLS August 2019 based on policy or configuration for the given client (regardless of whether the client was dynamically registered, statically configured, or otherwise established). In order to utilize TLS for OAuth client authentication, the TLS connection between the client and the authorization server MUST have been established or reestablished with mutual-TLS X.509 certificate authentication (i.e. the Client Certificate and Certificate Verify messages are sent during the TLS Handshake). For all requests to the authorization server utilizing mutual-TLS client authentication, the client MUST include the "client_id" parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The presence of the "client_id" parameter enables the authorization server to easily identify the client independently from the content of the certificate. The authorization server can locate the client configuration using the client identifier and check the certificate presented in the TLS Handshake against the expected credentials for that client. The authorization server MUST enforce the binding between client and certificate as described in either Section 2.1 or Section 2.2 below. If no certificate is presented or that which is presented doesn't match that which is expected for the given "client_id", the authorization server returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749 [RFC6749] with the "invalid_client" error code to indicate failed client authentication. 2.1. PKI Mutual-TLS Method The PKI (public key infrastructure) method of mutual-TLS OAuth client authentication adheres to the way in which X.509 certificates are traditionally used for authentication. It relies on a validated certificate chain [RFC5280] and a single subject distinguished name (DN) or a single subject alternative name (SAN) to authenticate the client. Only one subject name value of any type is used for each client. The TLS handshake is utilized to validate the client's possession of the private key corresponding to the public key in the certificate and to validate the corresponding certificate chain. The client is successfully authenticated if the subject information in the certificate matches the single expected subject configured or registered for that particular client (note that a predictable treatment of DN values, such as the distinguishedNameMatch rule from [RFC4517], is needed in comparing the certificate's subject DN to the client's registered DN). Revocation checking is possible with the PKI method but if and how to check a certificate's revocation status is a deployment decision at the discretion of the authorization server. Clients can rotate their X.509 certificates without the need to modify the respective authentication data at the authorization Campbell, et al. Expires February 23, 2020 [Page 6] Internet-Draft OAuth Mutual TLS August 2019 server by obtaining a new certificate with the same subject from a trusted certificate authority (CA). 2.1.1. PKI Method Metadata Value For the PKI method of mutual-TLS client authentication, this specification defines and registers the following authentication method metadata value into the "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. tls_client_auth Indicates that client authentication to the authorization server will occur with mutual TLS utilizing the PKI method of associating a certificate to a client. 2.1.2. Client Registration Metadata In order to convey the expected subject of the certificate, the following metadata parameters are introduced for the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] in support of the PKI method of mutual-TLS client authentication. A client using the "tls_client_auth" authentication method MUST use exactly one of the below metadata parameters to indicate the certificate subject value that the authorization server is to expect when authenticating the respective client. tls_client_auth_subject_dn An [RFC4514] string representation of the expected subject distinguished name of the certificate, which the OAuth client will use in mutual-TLS authentication. tls_client_auth_san_dns A string containing the value of an expected dNSName SAN entry in the certificate, which the OAuth client will use in mutual-TLS authentication. tls_client_auth_san_uri A string containing the value of an expected uniformResourceIdentifier SAN entry in the certificate, which the OAuth client will use in mutual-TLS authentication. tls_client_auth_san_ip A string representation of an IP address in either dotted decimal notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as defined in [RFC5952]) that is expected to be present as an iPAddress SAN entry in the certificate, which the OAuth client will use in mutual-TLS authentication. Per section 8 of [RFC5952] Campbell, et al. Expires February 23, 2020 [Page 7] Internet-Draft OAuth Mutual TLS August 2019 the IP address comparison of the value in this parameter and the SAN entry in the certificate is to be done in binary format. tls_client_auth_san_email A string containing the value of an expected rfc822Name SAN entry in the certificate, which the OAuth client will use in mutual-TLS authentication. 2.2. Self-Signed Certificate Mutual-TLS Method This method of mutual-TLS OAuth client authentication is intended to support client authentication using self-signed certificates. As a prerequisite, the client registers its X.509 certificates (using "jwks" defined in [RFC7591]) or a reference to a trusted source for its X.509 certificates (using "jwks_uri" from [RFC7591]) with the authorization server. During authentication, TLS is utilized to validate the client's possession of the private key corresponding to the public key presented within the certificate in the respective TLS handshake. In contrast to the PKI method, the client's certificate chain is not validated by the server in this case. The client is successfully authenticated if the certificate that it presented during the handshake matches one of the certificates configured or registered for that particular client. The Self-Signed Certificate method allows the use of mutual TLS to authenticate clients without the need to maintain a PKI. When used in conjunction with a "jwks_uri" for the client, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data directly with the authorization server. 2.2.1. Self-Signed Method Metadata Value For the Self-Signed Certificate method of mutual-TLS client authentication, this specification defines and registers the following authentication method metadata value into the "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. self_signed_tls_client_auth Indicates that client authentication to the authorization server will occur using mutual TLS with the client utilizing a self- signed certificate. 2.2.2. Client Registration Metadata For the Self-Signed Certificate method of binding a certificate with a client using mutual TLS client authentication, the existing "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to convey the client's certificates via JSON Web Key (JWK) in a JWK Set (JWKS) [RFC7517]. The "jwks" metadata parameter is a JWK Set Campbell, et al. Expires February 23, 2020 [Page 8] Internet-Draft OAuth Mutual TLS August 2019 containing the client's public keys as an array of JWKs while the "jwks_uri" parameter is a URL that references a client's JWK Set. A certificate is represented with the "x5c" parameter of an individual JWK within the set. Note that the members of the JWK representing the public key (e.g. "n" and "e" for RSA, "x" and "y" for EC) are required parameters per [RFC7518] so will be present even though they are not utilized in this context. Also note that that Section 4.7 of [RFC7517] requires that the key in the first certificate of the "x5c" parameter match the public key represented by those other members of the JWK. 3. Mutual-TLS Client Certificate-Bound Access Tokens When mutual TLS is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate. Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource, such as embedding the certificate hash in the issued access token directly, using the syntax described in Section 3.1, or through token introspection as described in Section 3.2. Binding the access token to the client certificate in that fashion has the benefit of decoupling that binding from the client's authentication with the authorization server, which enables mutual TLS during protected resource access to serve purely as a proof-of-possession mechanism. Other methods of associating a certificate with an access token are possible, per agreement by the authorization server and the protected resource, but are beyond the scope of this specification. In order for a resource server to use certificate-bound access tokens, it must have advance knowledge that mutual TLS is to be used for some or all resource accesses. In particular, the access token itself cannot be used as input to the decision of whether or not to request mutual TLS, since from the TLS perspective those are "Application Data", only exchanged after the TLS handshake has been completed, and the initial CertificateRequest occurs during the handshake, before the Application Data is available. Although subsequent opportunities for a TLS client to present a certificate may be available, e.g., via TLS 1.2 renegotiation [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document makes no provision for their usage. It is expected to be common that a mutual-TLS-using resource server will require mutual TLS for all resources hosted thereupon, or will serve mutual-TLS-protected and regular resources on separate hostname+port combinations, though other workflows are possible. How resource server policy is synchronized with the AS is out of scope for this document. Campbell, et al. Expires February 23, 2020 [Page 9] Internet-Draft OAuth Mutual TLS August 2019 Within the scope of an mutual-TLS-protected resource-access flow, the client makes protected resource requests as described in [RFC6750], however, those requests MUST be made over a mutually authenticated TLS connection using the same certificate that was used for mutual TLS at the token endpoint. The protected resource MUST obtain, from its TLS implementation layer, the client certificate used for mutual TLS and MUST verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt MUST be rejected with an error per [RFC6750] using an HTTP 401 status code and the "invalid_token" error code. Metadata to convey server and client capabilities for mutual-TLS client certificate-bound access tokens is defined in Section 3.3 and Section 3.4 respectively. 3.1. JWT Certificate Thumbprint Confirmation Method When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], the certificate hash information SHOULD be represented using the "x5t#S256" confirmation method member defined herein. To represent the hash of a certificate in a JWT, this specification defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value of the "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash (a.k.a. thumbprint, fingerprint or digest) of the DER encoding [X690] of the X.509 certificate [RFC5280]. The base64url-encoded value MUST omit all trailing pad '=' characters and MUST NOT include any line breaks, whitespace, or other additional characters. The following is an example of a JWT payload containing an "x5t#S256" certificate thumbprint confirmation method. The new JWT content introduced by this specification is the "cnf" confirmation method claim at the bottom of the example that has the "x5t#S256" confirmation method member containing the value that is the hash of the client certificate to which the access token is bound. Campbell, et al. Expires February 23, 2020 [Page 10] Internet-Draft OAuth Mutual TLS August 2019 { "iss": "https://server.example.com", "sub": "ty.webb@example.com", "exp": 1493726400, "nbf": 1493722800, "cnf":{ "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" } } Figure 2: Example JWT Claims Set with an X.509 Certificate Thumbprint Confirmation Method 3.2. Confirmation Method for Token Introspection OAuth 2.0 Token Introspection [RFC7662] defines a method for a protected resource to query an authorization server about the active state of an access token as well as to determine meta-information about the token. For a mutual-TLS client certificate-bound access token, the hash of the certificate to which the token is bound is conveyed to the protected resource as meta-information in a token introspection response. The hash is conveyed using the same "cnf" with "x5t#S256" member structure as the certificate SHA-256 thumbprint confirmation method, described in Section 3.1, as a top-level member of the introspection response JSON. The protected resource compares that certificate hash to a hash of the client certificate used for mutual- TLS authentication and rejects the request, if they do not match. The following is an example of an introspection response for an active token with an "x5t#S256" certificate thumbprint confirmation method. The new introspection response content introduced by this specification is the "cnf" confirmation method at the bottom of the example that has the "x5t#S256" confirmation method member containing the value that is the hash of the client certificate to which the access token is bound. Campbell, et al. Expires February 23, 2020 [Page 11] Internet-Draft OAuth Mutual TLS August 2019 HTTP/1.1 200 OK Content-Type: application/json { "active": true, "iss": "https://server.example.com", "sub": "ty.webb@example.com", "exp": 1493726400, "nbf": 1493722800, "cnf":{ "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" } } Figure 3: Example Introspection Response for a Certificate-Bound Access Token 3.3. Authorization Server Metadata This document introduces the following new authorization server metadata [RFC8414] parameter to signal the server's capability to issue certificate bound access tokens: tls_client_certificate_bound_access_tokens OPTIONAL. Boolean value indicating server support for mutual-TLS client certificate-bound access tokens. If omitted, the default value is "false". 3.4. Client Registration Metadata The following new client metadata parameter is introduced to convey the client's intention to use certificate bound access tokens: tls_client_certificate_bound_access_tokens OPTIONAL. Boolean value used to indicate the client's intention to use mutual-TLS client certificate-bound access tokens. If omitted, the default value is "false". Note that, if a client that has indicated the intention to use mutual-TLS client certificate-bound tokens makes a request to the token endpoint over a non-mutual-TLS connection, it is at the authorization server's discretion as to whether to return an error or issue an unbound token. Campbell, et al. Expires February 23, 2020 [Page 12] Internet-Draft OAuth Mutual TLS August 2019 4. Public Clients and Certificate-Bound Tokens Mutual-TLS OAuth client authentication and certificate-bound access tokens can be used independently of each other. Use of certificate- bound access tokens without mutual-TLS OAuth client authentication, for example, is possible in support of binding access tokens to a TLS client certificate for public clients (those without authentication credentials associated with the "client_id"). The authorization server would configure the TLS stack in the same manner as for the Self-Signed Certificate method such that it does not verify that the certificate presented by the client during the handshake is signed by a trusted CA. Individual instances of a client would create a self- signed certificate for mutual TLS with both the authorization server and resource server. The authorization server would not use the mutual-TLS certificate to authenticate the client at the OAuth layer but would bind the issued access token to that certificate, for which the client has proven possession of the corresponding private key. The access token is then bound to the certificate and can only be used by the client possessing the certificate and corresponding private key and utilizing them to negotiate mutual TLS on connections to the resource server. When the authorization server issues a refresh token to such a client, it SHOULD also bind the refresh token to the respective certificate. And check the binding when the refresh token is presented to get new access tokens. The implementation details of the binding the refresh token are at the discretion of the authorization server. 5. Metadata for Mutual-TLS Endpoint Aliases The process of negotiating client certificate-based mutual TLS involves a TLS server requesting a certificate from the TLS client (the client does not provide one unsolicited). Although a server can be configured such that client certificates are optional, meaning that the connection is allowed to continue when the client does not provide a certificate, the act of a server requesting a certificate can result in undesirable behavior from some clients. This is particularly true of web browsers as TLS clients, which will typically present the end-user with an intrusive certificate selection interface when the server requests a certificate. Authorization servers supporting both clients using mutual TLS and conventional clients MAY chose to isolate the server side mutual-TLS behavior to only clients intending to do mutual TLS, thus avoiding any undesirable effects it might have on conventional clients. The following authorization server metadata parameter is introduced to facilitate such separation: mtls_endpoint_aliases Campbell, et al. Expires February 23, 2020 [Page 13] Internet-Draft OAuth Mutual TLS August 2019 OPTIONAL. A JSON object containing alternative authorization server endpoints that, when present, an OAuth client intending to do mutual TLS uses in preference to the conventional endpoints. The parameter value itself consists of one or more endpoint parameters, such as "token_endpoint", "revocation_endpoint", "introspection_endpoint", etc., conventionally defined for the top-level of authorization server metadata. An OAuth client intending to do mutual TLS (for OAuth client authentication and/or to acquire or use certificate-bound tokens) when making a request directly to the authorization server MUST use the alias URL of the endpoint within the "mtls_endpoint_aliases", when present, in preference to the endpoint URL of the same name at top-level of metadata. When an endpoint is not present in "mtls_endpoint_aliases", then the client uses the conventional endpoint URL defined at the top-level of the authorization server metadata. Metadata parameters within "mtls_endpoint_aliases" that do not define endpoints to which an OAuth client makes a direct request have no meaning and SHOULD be ignored. Below is an example of an authorization server metadata document with the "mtls_endpoint_aliases" parameter, which indicates aliases for the token, revocation, and introspection endpoints that an OAuth client intending to do mutual TLS would in preference to the conventional token, revocation, and introspection endpoints. Note that the endpoints in "mtls_endpoint_aliases" use a different host than their conventional counterparts, which allows the authorization server (via TLS "server_name" extension [RFC6066] or actual distinct hosts) to differentiate its TLS behavior as appropriate. Campbell, et al. Expires February 23, 2020 [Page 14] Internet-Draft OAuth Mutual TLS August 2019 { "issuer": "https://server.example.com", "authorization_endpoint": "https://server.example.com/authz", "token_endpoint": "https://server.example.com/token", "introspection_endpoint": "https://server.example.com/introspect", "revocation_endpoint": "https://server.example.com/revo", "jwks_uri": "https://server.example.com/jwks", "response_types_supported": ["code"], "response_modes_supported": ["fragment","query","form_post"], "grant_types_supported": ["authorization_code", "refresh_token"], "token_endpoint_auth_methods_supported": ["tls_client_auth","client_secret_basic","none"], "tls_client_certificate_bound_access_tokens": true "mtls_endpoint_aliases": { "token_endpoint": "https://mtls.example.com/token", "revocation_endpoint": "https://mtls.example.com/revo", "introspection_endpoint": "https://mtls.example.com/introspect" } } Figure 4: Example Authorization Server Metadata with Mutual-TLS Endpoint Aliases 6. Implementation Considerations 6.1. Authorization Server The authorization server needs to set up its TLS configuration appropriately for the OAuth client authentication methods it supports. An authorization server that supports mutual-TLS client authentication and other client authentication methods or public clients in parallel would make mutual TLS optional (i.e. allowing a handshake to continue after the server requests a client certificate but the client does not send one). In order to support the Self-Signed Certificate method alone, the authorization server would configure the TLS stack in such a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate. As described in Section 3, the authorization server binds the issued access token to the TLS client certificate, which means that it will only issue certificate-bound tokens for a certificate which the client has proven possession of the corresponding private key. Campbell, et al. Expires February 23, 2020 [Page 15] Internet-Draft OAuth Mutual TLS August 2019 The authorization server may also consider hosting the token endpoint, and other endpoints requiring client authentication, on a separate host name or port in order to prevent unintended impact on the TLS behavior of its other endpoints, e.g. the authorization endpoint. As described in Section 5, it may further isolate any potential impact of the server requesting client certificates by offering a distinct set of endpoints on a separate host or port, which are aliases for the originals that a client intending to do mutual TLS will use in preference to the conventional endpoints. 6.2. Resource Server OAuth divides the roles and responsibilities such that the resource server relies on the authorization server to perform client authentication and obtain resource owner (end-user) authorization. The resource server makes authorization decisions based on the access token presented by the client but does not directly authenticate the client per se. The manner in which an access token is bound to the client certificate and how a protected resource verifies the proof- of-possession decouples that from the specific method that the client used to authenticate with the authorization server. Mutual TLS during protected resource access can therefore serve purely as a proof-of-possession mechanism. As such, it is not necessary for the resource server to validate the trust chain of the client's certificate in any of the methods defined in this document. The resource server would therefore configure the TLS stack in a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate. 6.3. Certificate Expiration and Bound Access Tokens As described in Section 3, an access token is bound to a specific client certificate, which means that the same certificate must be used for mutual TLS on protected resource access. It also implies that access tokens are invalidated when a client updates the certificate, which can be handled similar to expired access tokens where the client requests a new access token (typically with a refresh token) and retries the protected resource request. 6.4. Implicit Grant Unsupported This document describes binding an access token to the client certificate presented on the TLS connection from the client to the authorization server's token endpoint, however, such binding of access tokens issued directly from the authorization endpoint via the implicit grant flow is explicitly out of scope. End users interact directly with the authorization endpoint using a web browser and the use of client certificates in user's browsers bring operational and Campbell, et al. Expires February 23, 2020 [Page 16] Internet-Draft OAuth Mutual TLS August 2019 usability issues, which make it undesirable to support certificate- bound access tokens issued in the implicit grant flow. Implementations wanting to employ certificate-bound access tokens should utilize grant types that involve the client making an access token request directly to the token endpoint (e.g. the authorization code and refresh token grant types). 6.5. TLS Termination An authorization server or resource server MAY choose to terminate TLS connections at a load balancer, reverse proxy, or other network intermediary. How the client certificate metadata is securely communicated between the intermediary and the application server in this case is out of scope of this specification. 7. Security Considerations 7.1. Certificate-Bound Refresh Tokens The OAuth 2.0 Authorization Framework [RFC6749] requires that an authorization server bind refresh tokens to the client to which they were issued and that confidential clients (those having established authentication credentials with the authorization server) authenticate to the AS when presenting a refresh token. As a result, refresh tokens are indirectly certificate-bound by way of the client ID and the associated requirement for (certificate-based) authentication to the authorization server when issued to clients utilizing the "tls_client_auth" or "self_signed_tls_client_auth" methods of client authentication. Section 4 describes certificate- bound refresh tokens issued to public clients (those without authentication credentials associated with the "client_id"). 7.2. Certificate Thumbprint Binding The binding between the certificate and access token specified in Section 3.1 uses a cryptographic hash of the certificate. It relies on the hash function having sufficient second-preimage resistance so as to make it computationally infeasible to find or create another certificate that produces to the same hash output value. The SHA-256 hash function was used because it meets the aforementioned requirement while being widely available. If, in the future, certificate thumbprints need to be computed using hash function(s) other than SHA-256, it is suggested that additional related JWT confirmation methods members be defined for that purpose and registered in the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for JWT "cnf" member values. Campbell, et al. Expires February 23, 2020 [Page 17] Internet-Draft OAuth Mutual TLS August 2019 Community knowledge about the strength of various algorithms and feasible attacks can change suddenly, and experience shows that a document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document. 7.3. TLS Versions and Best Practices In the abstract this document is applicable with any TLS version supporting certificate-based client authentication. Both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246] are cited herein because, at the time of writing, 1.3 is the newest version while 1.2 is the most widely deployed. General implementation and security considerations for TLS, including version recommendations, can be found in [BCP195]. TLS certificate validation (for both client and server certificates) requires a local database of trusted certificate authorities (CAs). Decisions about what CAs to trust and how to make such a determination of trust are out of scope for this document. 7.4. X.509 Certificate Spoofing If the PKI method of client authentication is used, an attacker could try to impersonate a client using a certificate with the same subject (DN or SAN) but issued by a different CA, which the authorization server trusts. To cope with that threat, the authorization server SHOULD only accept as trust anchors a limited number of CAs whose certificate issuance policy meets its security requirements. There is an assumption then that the client and server agree out of band on the set of trust anchors that the server uses to create and validate the certificate chain. Without this assumption the use of a subject to identify the client certificate would open the server up to certificate spoofing attacks. 7.5. X.509 Certificate Parsing and Validation Complexity Parsing and validation of X.509 certificates and certificate chains is complex and implementation mistakes have previously exposed security vulnerabilities. Complexities of validation include (but are not limited to) [CX5P] [DCW] [RFC5280]: o checking of Basic Constraints, basic and extended Key Usage constraints, validity periods, and critical extensions; o handling of embedded NUL bytes in ASN.1 counted-length strings, and non-canonical or non-normalized string representations in subject names; Campbell, et al. Expires February 23, 2020 [Page 18] Internet-Draft OAuth Mutual TLS August 2019 o handling of wildcard patterns in subject names; o recursive verification of certificate chains and checking certificate revocation. For these reasons, implementors SHOULD use an established and well- tested X.509 library (such as one used by an established TLS library) for validation of X.509 certificate chains and SHOULD NOT attempt to write their own X.509 certificate validation procedures. 8. Privacy Considerations In TLS versions prior to 1.3, the client's certificate is sent unencrypted in the initial handshake and can potentially be used by third parties to monitor, track, and correlate client activity. This is likely of little concern for clients that act on behalf of a significant number of end-users because individual user activity will not be discernible amidst the client activity as a whole. However, clients that act on behalf of a single end-user, such as a native application on a mobile device, should use TLS version 1.3 whenever possible or consider the potential privacy implications of using mutual TLS on earlier versions. 9. IANA Considerations 9.1. JWT Confirmation Methods Registration This specification requests registration of the following value in the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for JWT "cnf" member values established by [RFC7800]. o Confirmation Method Value: "x5t#S256" o Confirmation Method Description: X.509 Certificate SHA-256 Thumbprint o Change Controller: IESG o Specification Document(s): Section 3.1 of [[ this specification ]] 9.2. Authorization Server Metadata Registration This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414]. o Metadata Name: "tls_client_certificate_bound_access_tokens" o Metadata Description: Indicates authorization server support for mutual-TLS client certificate-bound access tokens. o Change Controller: IESG o Specification Document(s): Section 3.3 of [[ this specification ]] Campbell, et al. Expires February 23, 2020 [Page 19] Internet-Draft OAuth Mutual TLS August 2019 o Metadata Name: "mtls_endpoint_aliases" o Metadata Description: JSON object containing alternative authorization server endpoints, which a client intending to do mutual TLS will use in preference to the conventional endpoints. o Change Controller: IESG o Specification Document(s): Section 5 of [[ this specification ]] 9.3. Token Endpoint Authentication Method Registration This specification requests registration of the following values in the IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] established by [RFC7591]. o Token Endpoint Authentication Method Name: "tls_client_auth" o Change Controller: IESG o Specification Document(s): Section 2.1.1 of [[ this specification ]] o Token Endpoint Authentication Method Name: "self_signed_tls_client_auth" o Change Controller: IESG o Specification Document(s): Section 2.2.1 of [[ this specification ]] 9.4. Token Introspection Response Registration Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] defined the "cnf" (confirmation) claim, which enables confirmation key information to be carried in a JWT. However, the same proof-of- possession semantics are also useful for introspected access tokens whereby the protected resource obtains the confirmation key data as meta-information of a token introspection response and uses that information in verifying proof-of-possession. Therefore this specification defines and registers proof-of-possession semantics for OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. When included as a top-level member of an OAuth token introspection response, "cnf" has the same semantics and format as the claim of the same name defined in [RFC7800]. While this specification only explicitly uses the "x5t#S256" confirmation method member (see Section 3.2), it needs to define and register the higher level "cnf" structure as an introspection response member in order to define and use the more specific certificate thumbprint confirmation method. As such, this specification requests registration of the following value in the IANA "OAuth Token Introspection Response" registry [IANA.OAuth.Parameters] established by [RFC7662]. o Claim Name: "cnf" Campbell, et al. Expires February 23, 2020 [Page 20] Internet-Draft OAuth Mutual TLS August 2019 o Claim Description: Confirmation o Change Controller: IESG o Specification Document(s): [RFC7800] and [[ this specification ]] 9.5. Dynamic Client Registration Metadata Registration This specification requests registration of the following client metadata definitions in the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: o Client Metadata Name: "tls_client_certificate_bound_access_tokens" o Client Metadata Description: Indicates the client's intention to use mutual-TLS client certificate-bound access tokens. o Change Controller: IESG o Specification Document(s): Section 3.4 of [[ this specification ]] o Client Metadata Name: "tls_client_auth_subject_dn" o Client Metadata Description: String value specifying the expected subject DN of the client certificate. o Change Controller: IESG o Specification Document(s): Section 2.1.2 of [[ this specification ]] o Client Metadata Name: "tls_client_auth_san_dns" o Client Metadata Description: String value specifying the expected dNSName SAN entry in the client certificate. o Change Controller: IESG o Specification Document(s): Section 2.1.2 of [[ this specification ]] o Client Metadata Name: "tls_client_auth_san_uri" o Client Metadata Description: String value specifying the expected uniformResourceIdentifier SAN entry in the client certificate. o Change Controller: IESG o Specification Document(s): Section 2.1.2 of [[ this specification ]] o Client Metadata Name: "tls_client_auth_san_ip" o Client Metadata Description: String value specifying the expected iPAddress SAN entry in the client certificate. o Change Controller: IESG o Specification Document(s): Section 2.1.2 of [[ this specification ]] o Client Metadata Name: "tls_client_auth_san_email" o Client Metadata Description: String value specifying the expected rfc822Name SAN entry in the client certificate. o Change Controller: IESG Campbell, et al. Expires February 23, 2020 [Page 21] Internet-Draft OAuth Mutual TLS August 2019 o Specification Document(s): Section 2.1.2 of [[ this specification ]] 10. References 10.1. Normative References [BCP195] 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, June 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [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, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . Campbell, et al. Expires February 23, 2020 [Page 22] Internet-Draft OAuth Mutual TLS August 2019 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012, . [X690] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2015. Campbell, et al. Expires February 23, 2020 [Page 23] Internet-Draft OAuth Mutual TLS August 2019 10.2. Informative References [CX5P] Wong, D., "Common x509 certificate validation/creation pitfalls", September 2016, . [DCW] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., and V. Shmatikov, "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software", . [I-D.ietf-oauth-token-binding] Jones, M., Campbell, B., Bradley, J., and W. Denniss, "OAuth 2.0 Token Binding", draft-ietf-oauth-token- binding-06 (work in progress), March 2018. [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [OpenID.CIBA] Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0", January 2019, . [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, DOI 10.17487/RFC4517, June 2006, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . Campbell, et al. Expires February 23, 2020 [Page 24] Internet-Draft OAuth Mutual TLS August 2019 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . Appendix A. Example "cnf" Claim, Certificate and JWK For reference, an "x5t#S256" value and the X.509 Certificate from which it was calculated are provided in the following examples, Figure 5 and Figure 6 respectively. A JWK representation of the certificate's public key along with the "x5c" member is also provided in Figure 7. "cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"} Figure 5: x5t#S256 Confirmation Claim -----BEGIN CERTIFICATE----- MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTAx ODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGByqG SM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZjjJ /Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0EAwID SQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2eXZOV bUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY= -----END CERTIFICATE----- Figure 6: PEM Encoded Self-Signed Certificate { "kty":"EC", "x":"1yfLHCpXqFjxCeHHHMVDTcLscpb07KUxudBmOMn8C7Q", "y":"8_coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8", "crv":"P-256", "x5c":[ "MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTA xODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGBy qGSM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZ jjJ/Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0E AwIDSQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2 eXZOVbUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY=" ] } Figure 7: JSON Web Key Campbell, et al. Expires February 23, 2020 [Page 25] Internet-Draft OAuth Mutual TLS August 2019 Appendix B. Relationship to Token Binding OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the application of Token Binding to the various artifacts and tokens employed throughout OAuth. That includes binding of an access token to a Token Binding key, which bears some similarities in motivation and design to the mutual-TLS client certificate-bound access tokens defined in this document. Both documents define what is often called a proof-of-possession security mechanism for access tokens, whereby a client must demonstrate possession of cryptographic keying material when accessing a protected resource. The details differ somewhat between the two documents but both have the authorization server bind the access token that it issues to an asymmetric key pair held by the client. The client then proves possession of the private key from that pair with respect to the TLS connection over which the protected resource is accessed. Token Binding uses bare keys that are generated on the client, which avoids many of the difficulties of creating, distributing, and managing certificates used in this specification. However, at the time of writing, Token Binding is fairly new and there is relatively little support for it in available application development platforms and tooling. Until better support for the underlying core Token Binding specifications exists, practical implementations of OAuth 2.0 Token Binding are infeasible. Mutual TLS, on the other hand, has been around for some time and enjoys widespread support in web servers and development platforms. As a consequence, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens can be built and deployed now using existing platforms and tools. In the future, the two specifications are likely to be deployed in parallel for solving similar problems in different environments. Authorization servers may even support both specifications simultaneously using different proof-of-possession mechanisms for tokens issued to different clients. Appendix C. Acknowledgements Scott "not Tomlinson" Tomilson and Matt Peterson were involved in design and development work on a mutual-TLS OAuth client authentication implementation, which predates this document. Experience and learning from that work informed some of the content of this document. This specification was developed within the OAuth Working Group under the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security Area Directors. Additionally, the following individuals contributed ideas, feedback, and wording that helped shape this specification: Campbell, et al. Expires February 23, 2020 [Page 26] Internet-Draft OAuth Mutual TLS August 2019 Vittorio Bertocci, Sergey Beryozkin, Ralph Bragg, Sophie Bremer, Roman Danyliw, Vladimir Dzhuvinov, Samuel Erdtman, Evan Gilman, Leif Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim Manico, Nov Matake, Sascha Preibisch, Eric Rescorla, Justin Richer, Vincent Roca, Filip Skokan, Dave Tonge, and Hannes Tschofenig. Appendix D. Document(s) History [[ to be removed by the RFC Editor before publication as an RFC ]] draft-ietf-oauth-mtls-17 o Updates from IESG ballot position comments. draft-ietf-oauth-mtls-16 o Editorial updates from last call review. draft-ietf-oauth-mtls-15 o Editorial updates from second AD review. draft-ietf-oauth-mtls-14 o Editorial clarifications around there being only a single subject registered/configured per client for the tls_client_auth method. o Add a brief explanation about how, with tls_client_auth and self_signed_tls_client_auth, refresh tokens are certificate-bound indirectly via the client authentication. o Add mention of refresh tokens in the abstract. draft-ietf-oauth-mtls-13 o Add an abstract protocol flow and diagram to serve as an overview of OAuth in general and baseline to describe the various ways in which the mechanisms defined herein are intended to be used. o A little bit less of that German influence. o Rework the TLS references a bit and, in the Terminology section, clean up the description of what messages are sent and verified in the handshake to do 'mutual TLS'. o Move the explanation about "cnf" introspection registration into the IANA Considerations. o Add CIBA as an informational reference and additional example of an OAuth extension that defines an endpoint that utilizes client authentication. o Shorten a few of the section titles. Campbell, et al. Expires February 23, 2020 [Page 27] Internet-Draft OAuth Mutual TLS August 2019 o Add new client metadata values to allow for the use of a SAN in the PKI MTLS client authentication method. o Add privacy considerations attempting to discuss the implications of the client cert being sent in the clear in TLS 1.2. o Changed the 'Certificate Bound Access Tokens Without Client Authentication' section to 'Public Clients and Certificate-Bound Tokens' and moved it up to be a top level section while adding discussion of binding refresh tokens for public clients. o Reword/restructure the main PKI method section somewhat to (hopefully) improve readability. o Reword/restructure the Self-Signed method section a bit to (hopefully) make it more comprehensible. o Reword the AS and RS Implementation Considerations somewhat to (hopefully) improve readability. o Clarify that the protected resource obtains the client certificate used for mutual TLS from its TLS implementation layer. o Add Security Considerations section about the certificate thumbprint binding that includes the hash algorithm agility recommendation. o Add an "mtls_endpoint_aliases" AS metadata parameter that is a JSON object containing alternative authorization server endpoints, which a client intending to do mutual TLS will use in preference to the conventional endpoints. o Minor editorial updates. draft-ietf-oauth-mtls-12 o Add an example certificate, JWK, and confirmation method claim. o Minor editorial updates based on implementer feedback. o Additional Acknowledgements. draft-ietf-oauth-mtls-11 o Editorial updates. o Mention/reference TLS 1.3 RFC8446 in the TLS Versions and Best Practices section. draft-ietf-oauth-mtls-10 o Update draft-ietf-oauth-discovery reference to RFC8414 draft-ietf-oauth-mtls-09 o Change "single certificates" to "self-signed certificates" in the Abstract draft-ietf-oauth-mtls-08 Campbell, et al. Expires February 23, 2020 [Page 28] Internet-Draft OAuth Mutual TLS August 2019 o Incorporate clarifications and editorial improvements from Justin Richer's WGLC review o Drop the use of the "sender constrained" terminology per WGLC feedback from Neil Madden (including changing the metadata parameters from mutual_tls_sender_constrained_access_tokens to tls_client_certificate_bound_access_tokens) o Add a new security considerations section on X.509 parsing and validation per WGLC feedback from Neil Madden and Benjamin Kaduk o Note that a server can terminate TLS at a load balancer, reverse proxy, etc. but how the client certificate metadata is securely communicated to the backend is out of scope per WGLC feedback o Note that revocation checking is at the discretion of the AS per WGLC feedback o Editorial updates and clarifications o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf- oauth-token-binding to -06 o Add folks involved in WGLC feedback to the acknowledgements list draft-ietf-oauth-mtls-07 o Update to use the boilerplate from RFC 8174 draft-ietf-oauth-mtls-06 o Add an appendix section describing the relationship of this document to OAuth Token Binding as requested during the Singapore meeting https://datatracker.ietf.org/doc/minutes-100-oauth/ o Add an explicit note that the implicit flow is not supported for obtaining certificate bound access tokens as discussed at the Singapore meeting https://datatracker.ietf.org/doc/minutes- 100-oauth/ o Add/incorporate text to the Security Considerations on Certificate Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/ V26070X-6OtbVSeUz_7W2k94vCo o Changed the title to be more descriptive o Move the Security Considerations section to before the IANA Considerations o Elaborated on certificate-bound access tokens a bit more in the Abstract o Update draft-ietf-oauth-discovery reference to -08 draft-ietf-oauth-mtls-05 o Editorial fixes draft-ietf-oauth-mtls-04 Campbell, et al. Expires February 23, 2020 [Page 29] Internet-Draft OAuth Mutual TLS August 2019 o Change the name of the 'Public Key method' to the more accurate 'Self-Signed Certificate method' and also change the associated authentication method metadata value to "self_signed_tls_client_auth". o Removed the "tls_client_auth_root_dn" client metadata field as discussed in https://mailarchive.ietf.org/arch/msg/oauth/ swDV2y0be6o8czGKQi1eJV-g8qc o Update draft-ietf-oauth-discovery reference to -07 o Clarify that MTLS client authentication isn't exclusive to the token endpoint and can be used with other endpoints, e.g. RFC 7009 revocation and 7662 introspection, that utilize client authentication as discussed in https://mailarchive.ietf.org/arch/msg/oauth/ bZ6mft0G7D3ccebhOxnEYUv4puI o Reorganize the document somewhat in an attempt to more clearly make a distinction between mTLS client authentication and certificate-bound access tokens as well as a more clear delineation between the two (PKI/Public key) methods for client authentication o Editorial fixes and clarifications draft-ietf-oauth-mtls-03 o Introduced metadata and client registration parameter to publish and request support for mutual TLS sender constrained access tokens o Added description of two methods of binding the cert and client, PKI and Public Key. o Indicated that the "tls_client_auth" authentication method is for the PKI method and introduced "pub_key_tls_client_auth" for the Public Key method o Added implementation considerations, mainly regarding TLS stack configuration and trust chain validation, as well as how to to do binding of access tokens to a TLS client certificate for public clients, and considerations around certificate-bound access tokens o Added new section to security considerations on cert spoofing o Add text suggesting that a new cnf member be defined in the future, if hash function(s) other than SHA-256 need to be used for certificate thumbprints draft-ietf-oauth-mtls-02 o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ U46UMEh8XIOQnvXY9pHFq1MKPns o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is better than "Mutual TLS Profiles for OAuth Clients"). draft-ietf-oauth-mtls-01 Campbell, et al. Expires February 23, 2020 [Page 30] Internet-Draft OAuth Mutual TLS August 2019 o Added more explicit details of using RFC 7662 token introspection with mutual TLS sender constrained access tokens. o Added an IANA OAuth Token Introspection Response Registration request for "cnf". o Specify that tls_client_auth_subject_dn and tls_client_auth_root_dn are RFC 4514 String Representation of Distinguished Names. o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. o Changed the text in the Section 3 to not be specific about using a hash of the cert. o Changed the abbreviated title to 'OAuth Mutual TLS' (previously was the acronym MTLSPOC). draft-ietf-oauth-mtls-00 o Created the initial working group version from draft-campbell- oauth-mtls draft-campbell-oauth-mtls-01 o Fix some typos. o Add to the acknowledgements list. draft-campbell-oauth-mtls-00 o Add a Mutual TLS sender constrained protected resource access method and a x5t#S256 cnf method for JWT access tokens (concepts taken in part from draft-sakimura-oauth-jpop-04). o Fixed "token_endpoint_auth_methods_supported" to "token_endpoint_auth_method" for client metadata. o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" client metadata parameters and mention using "jwks_uri" or "jwks". o Say that the authentication method is determined by client policy regardless of whether the client was dynamically registered or statically configured. o Expand acknowledgements to those that participated in discussions around draft-campbell-oauth-tls-client-auth-00 o Add Nat Sakimura and Torsten Lodderstedt to the author list. draft-campbell-oauth-tls-client-auth-00 o Initial draft. Authors' Addresses Campbell, et al. Expires February 23, 2020 [Page 31] Internet-Draft OAuth Mutual TLS August 2019 Brian Campbell Ping Identity Email: brian.d.campbell@gmail.com John Bradley Yubico Email: ve7jtb@ve7jtb.com URI: http://www.thread-safe.com/ Nat Sakimura Nomura Research Institute Email: n-sakimura@nri.co.jp URI: https://nat.sakimura.org/ Torsten Lodderstedt YES.com AG Email: torsten@lodderstedt.net Campbell, et al. Expires February 23, 2020 [Page 32] ./draft-ietf-rtcweb-data-channel-13.txt0000644000764400076440000010730512452275625017177 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-oauth-resource-indicators-08.txt0000644000764400076440000007520613536230015020472 0ustar iustyiusty OAuth Working Group B. Campbell Internet-Draft Ping Identity Intended status: Standards Track J. Bradley Expires: March 14, 2020 Yubico H. Tschofenig Arm Limited September 11, 2019 Resource Indicators for OAuth 2.0 draft-ietf-oauth-resource-indicators-08 Abstract This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. 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 https://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 14, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Campbell, et al. Expires March 14, 2020 [Page 1] Internet-Draft OAuth Resource Indicators September 2019 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 and Conventions . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Resource Parameter . . . . . . . . . . . . . . . . . . . . . 3 2.1. Authorization Request . . . . . . . . . . . . . . . . . . 5 2.2. Access Token Request . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.1. OAuth Parameters Registration . . . . . . . . . . . . . . 10 5.2. OAuth Extensions Error Registration . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Several years of deployment and implementation experience with the OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in some circumstances such as an authorization server servicing a significant number of diverse resources, for the client to explicitly signal to the authorization server where it intends to use the access token it is requesting. Knowing the protected resource (a.k.a. resource server, application, API, etc.) that will process the access token enables the authorization server to construct the token as necessary for that entity. Properly encrypting the token (or content within the token) to a particular resource, for example, requires knowing which resource will receive and decrypt the token. Furthermore, various resources oftentimes have different requirements with respect to the data contained in, or referenced by, the token and knowing the resource where the client intends to use the token allows the authorization server to mint the token accordingly. Specific knowledge of the intended recipient(s) of the access token also helps facilitate improved security characteristics of the token itself. Bearer tokens, currently the most commonly utilized type of OAuth access token, allow any party in possession of a token to get access to the associated resources. To prevent misuse, several Campbell, et al. Expires March 14, 2020 [Page 2] Internet-Draft OAuth Resource Indicators September 2019 important security assumptions must hold, one of which is that an access token must only be valid for use at a specific protected resource and for a specific scope of access. Section 5.2 of [RFC6750], for example, prescribes including the token's intended recipients within the token to prevent token redirect. When the authorization server is informed of the resource that will process the access token, it can restrict the intended audience of that token to the given resource such that the token cannot be used successfully at other resources. OAuth scope, from Section 3.3 of [RFC6749], is sometimes overloaded to convey the location or identity of the protected resource, however, doing so isn't always feasible or desirable. Scope is typically about what access is being requested rather than where that access will be redeemed (e.g., "email", "admin:org", "user_photos", "channels:read", and "channels:write" are a small sample of scope values in use in the wild that convey only the type of access and not the location or identity). In some circumstances and for some deployments, a means for the client to signal to the authorization server where it intends to use the access token it's requesting is important and useful. A number of implementations and deployments of OAuth 2.0 have already employed proprietary parameters toward that end. Going forward, this specification aspires to provide a standardized and interoperable alternative to the proprietary approaches. 1.1. Requirements Notation and Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 2. Resource Parameter In requests to the authorization server, a client MAY indicate the protected resource (a.k.a. resource server, application, API, etc.) Campbell, et al. Expires March 14, 2020 [Page 3] Internet-Draft OAuth Resource Indicators September 2019 to which it is requesting access by including the following parameter in the request. resource Indicates the target service or resource to which access is being requested. Its value MUST be an absolute URI, as specified by Section 4.3 of [RFC3986]. The URI MUST NOT include a fragment component. It SHOULD NOT include a query component, but it is recognized that there are cases that make a query component a useful and necessary part of the resource parameter, such as when query parameter(s) are used to scope requests to an application. The "resource" parameter URI value is an identifier representing the identity of the resource, which MAY be a locator that corresponds to a network addressable location where the target resource is hosted. Multiple "resource" parameters MAY be used to indicate that the requested token is intended to be used at multiple resources. The parameter value identifies a resource to which the client is requesting access. The parameter can carry the location of a protected resource, typically as an https URL, or a more abstract identifier. This enables the authorization server to apply policy as appropriate for the resource, such as determining the type and content of tokens to be issued, if and how tokens are encrypted, and applying appropriate audience restrictions. The client SHOULD provide the most specific URI that it can for the complete API or set of resources it intends to access. In practice a client will know a base URI for the application or resource that it interacts with, which is appropriate to use as the value of the "resource" parameter. The client SHOULD use the base URI of the API as the "resource" parameter value unless specific knowledge of the resource dictates otherwise. For example, the value "https://api.example.com/" would be used for a resource that is the exclusive application on that host, however, if the resource is one of many applications on that host, something like "https://api.example.com/app/" would be used as a more specific value. Another example, for an API like SCIM [RFC7644] that has multiple endpoints such as "https://apps.example.com/scim/Users", "https://apps.example.com/scim/Groups", and "https://apps.example.com/scim/Schemas" The client would use "https://apps.example.com/scim/" as the resource so that the issued access token is valid for all the endpoints of the SCIM API. The following error code is provided for an authorization server to indicate problems with the requested resource(s) in response to an authorization request or access token request. It can also be used Campbell, et al. Expires March 14, 2020 [Page 4] Internet-Draft OAuth Resource Indicators September 2019 to inform the client that it has requested an invalid combination of resource and scope. invalid_target The requested resource is invalid, missing, unknown, or malformed. The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. Audience restrictions can be communicated in JSON Web Tokens [RFC7519] with the "aud" claim and the top-level member of the same name provides the audience restriction information in a Token Introspection [RFC7662] response. The authorization server may use the exact "resource" value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource. 2.1. Authorization Request When the "resource" parameter is used in an authorization request to the authorization endpoint, it indicates the identity of the protected resource(s) to which access is being requested. When an access token will be returned directly from the authorization endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]), the requested resource is applicable to that access token. In the code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate representation of the authorization grant (the authorization code) is returned from the authorization endpoint, the requested resource is applicable to the full authorization grant. For an authorization request sent as a JSON Web Token (JWT), such as when using JWT Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single "resource" parameter value is represented as a JSON string while multiple values are represented as an array of strings. If the client omits the "resource" parameter when requesting authorization, the authorization server MAY process the request with no specific resource or by using a pre-defined default resource value. Alternatively, the authorization server MAY require clients to specify the resource(s) they intend to access and MAY fail requests that omit the parameter with an "invalid_target" error. The authorization server might use this data to inform the user about the resources the client is going to access on her behalf, to apply policy (e.g., refuse the request due to unknown resources), and to determine the set of resources that can be used in subsequent access token requests. If the authorization server fails to parse the provided value(s) or does not consider the resource(s) acceptable, it should reject the Campbell, et al. Expires March 14, 2020 [Page 5] Internet-Draft OAuth Resource Indicators September 2019 request with an error response using the error code "invalid_target" as the value of the "error" parameter and can provide additional information regarding the reasons for the error using the "error_description". An example of an authorization request where the client tells the authorization server that it wants an access token for use at "https://api.example.com/app/" is shown in Figure 1 below (extra line breaks and indentation are for display purposes only). GET /as/authorization.oauth2?response_type=token &client_id=example-client &state=XzZaJlcwYew1u0QBrRv_Gw &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1 Host: authorization-server.example.com Figure 1: Implicit Flow Authorization Request Below in Figure 2 is an example of an authorization request using the "code" response type where the client is requesting access to the resource owner's contacts and calendar data at "https://cal.example.com/" and "https://contacts.example.com/" (extra line breaks and indentation are for display purposes only). GET /as/authorization.oauth2?response_type=code &client_id=s6BhdRkqt3 &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=calendar%20contacts &resource=https%3A%2F%2Fcal.example.com%2F &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1 Host: authorization-server.example.com Figure 2: Code Flow Authorization Request 2.2. Access Token Request When the "resource" parameter is used on an access token request made to the token endpoint, for all grant types, it indicates the target service or protected resource where the client intends to use the requested access token. The resource value(s) that are acceptable to an authorization server in fulfilling an access token request are at its sole discretion based on local policy or configuration. In the case of a "refresh_token" or "authorization_code" grant type request, such policy may limit the acceptable resources to those that were Campbell, et al. Expires March 14, 2020 [Page 6] Internet-Draft OAuth Resource Indicators September 2019 originally granted by the resource owner or a subset thereof. In the "authorization_code" case where the requested resources are a subset of the set of resources originally granted, the authorization server will issue an access token based on that subset of requested resources while any refresh token that is returned is bound to the full original grant. When requesting a token, the client can indicate the desired target service(s) where it intends to use that token by way of the "resource" parameter and can indicate the desired scope of the requested token using the "scope" parameter. The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services. Effectively, the requested access rights of the token are the cartesian product of all the scopes at all the target services. To the extent possible, when issuing access tokens, the authorization server should downscope the scope value associated with an access token to the value the respective resource is able to process and needs to know. This further improves privacy as a list of scope values is an indication that the resource owner uses the multiple various services listed; downscoping a token to only that which is needed for a particular service can limit the extent to which such information is revealed across different services. As specified in Section 5.1 of [RFC6749], the authorization server must indicate the access token's effective scope to the client in the "scope" response parameter value when it differs from the scope requested by the client. Following from the code flow authorization request shown in Figure 2, the below examples show an "authorization_code" grant type access token request (Figure 3) and response (Figure 4) where the client tells the authorization server that it wants the access token for use at "https://cal.example.com/" (extra line breaks and indentation are for display purposes only). POST /as/token.oauth2 HTTP/1.1 Host: authorization-server.example.com Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ &resource=https%3A%2F%2Fcal.example.com%2F Figure 3: Access Token Request Campbell, et al. Expires March 14, 2020 [Page 7] Internet-Draft OAuth Resource Indicators September 2019 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf zkiQNVpYw", "token_type":"Bearer", "expires_in":3600, "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2", "scope":"calendar" } Figure 4: Access Token Response A subsequent access token request, using the refresh token, where the client tells the authorization server that it wants an access token for use at "https://contacts.example.com/" is shown in Figure 5 below with the response shown in Figure 6 (extra line breaks and indentation are for display purposes only). POST /as/token.oauth2 HTTP/1.1 Host: authorization-server.example.com Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ Content-Type: application/x-www-form-urlencoded grant_type=refresh_token &refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2 &resource=https%3A%2F%2Fcontacts.example.com%2F Figure 5: Access Token Request Campbell, et al. Expires March 14, 2020 [Page 8] Internet-Draft OAuth Resource Indicators September 2019 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH UowfmtNaA5EikYAw", "token_type":"Bearer", "expires_in":3600, "scope":"contacts" } Figure 6: Access Token Response 3. Security Considerations An audience-restricted access token, legitimately presented to a resource, cannot then be taken by that resource and presented elsewhere for illegitimate access to other resources. The "resource" parameter enables a client to indicate the protected resources where the requested access token will be used, which in turn enables the authorization server to apply the appropriate audience restrictions to the token. Some servers may host user content or be multi-tenant. In order to avoid attacks where one tenant uses an access token to illegitimately access resources owned by a different tenant, it is important to use a specific resource URI including any portion of the URI that identifies the tenant, such as a path component. This will allow access tokens to be audience-restricted in a way that identifies the tenant and prevent their use, due to an invalid audience, at resources owned by a different tenant. Although multiple occurrences of the "resource" parameter may be included in a token request, using only a single "resource" parameter is encouraged. A bearer token that has multiple intended recipients (audiences) indicating that the token is valid at more than one protected resource can be used by any one of those protected resources to access any of the other protected resources. Thus, a high degree of trust between the involved parties is needed when using access tokens with multiple audiences. Furthermore an authorization server may be unwilling or unable to fulfill a token request with multiple resources. Campbell, et al. Expires March 14, 2020 [Page 9] Internet-Draft OAuth Resource Indicators September 2019 Whenever feasible, the "resource" parameter should correspond to the network addressable location of the protected resource. This makes it possible for the client to validate that the resource being requested controls the corresponding network location, reducing the risk of malicious endpoints obtaining tokens meant for other resources. If the "resource" parameter contains an abstract identifier, it is the client's responsibility to validate out of band that any network endpoint to which tokens are sent are the intended audience for that identifier. 4. Privacy Considerations In typical OAuth deployments the authorization sever is in a position to observe and track a significant amount of user and client behavior. It is largely just inherent to the nature of OAuth and this document does little to affect that. In some cases, however, such as when access token introspection is not being used, use of the resource parameter defined herein may allow for tracking behavior at a somewhat more granular and specific level than would otherwise be possible in its absence. 5. IANA Considerations 5.1. OAuth Parameters Registration This specification updates the following value in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749]. o Parameter name: resource o Parameter usage location: authorization request, token request o Change controller: IESG o Specification document(s): [[ this specification ]] 5.2. OAuth Extensions Error Registration This specification updates the following error in the IANA "OAuth Extensions Error Registry" [IANA.OAuth.Parameters] established by [RFC6749]. o Error name: invalid_target o Error usage location: implicit grant error response, token error response o Related protocol extension: resource parameter o Change controller: IESG o Specification document(s): [[ this specification ]] Campbell, et al. Expires March 14, 2020 [Page 10] Internet-Draft OAuth Resource Indicators September 2019 6. References 6.1. Normative References [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [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, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [I-D.ietf-oauth-jwsreq] Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)", draft-ietf-oauth-jwsreq-19 (work in progress), June 2019. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, September 2015, . Campbell, et al. Expires March 14, 2020 [Page 11] Internet-Draft OAuth Resource Indicators September 2019 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . Appendix A. Acknowledgements This specification was developed within the OAuth Working Group under the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with Eric Rescorla, Benjamin Kaduk and Roman Danyliw serving as Security Area Directors. Additionally, the following individuals contributed ideas, feedback, and wording that helped shape this specification: Vittorio Bertocci, Sergey Beryozkin, Roman Danyliw, William Denniss, Vladimir Dzhuvinov, George Fletcher, Dick Hardt, Phil Hunt, Michael Jones, Benjamin Kaduk, Barry Leiba, Torsten Lodderstedt, Anthony Nadalin, Justin Richer, Adam Roach, Nat Sakimura, Rifaat Shekh-Yusef, Filip Skokan, Eric Vyncke, and Hans Zandbelt. Appendix B. Document History [[ to be removed by the RFC Editor before publication as an RFC ]] draft-ietf-oauth-resource-indicators-08 o One last update from IESG evaluation comments (https://mailarchive.ietf.org/arch/msg/oauth/ x87EQ0Dwq3_ERrH5PzDjRSaWBt4). draft-ietf-oauth-resource-indicators-07 o One more update from IESG evaluation comments (https://mailarchive.ietf.org/arch/msg/oauth/ RS0UZSsguQurHl4P18Zo77BzZnU). draft-ietf-oauth-resource-indicators-06 o Expand JWT acronym on first use per Genart last call review. o Updates from IESG evaluation comments. draft-ietf-oauth-resource-indicators-05 o Remove specific mention of error_uri, which is rarely (if ever) used and seems to only confuse things for readers of extensions like this one. draft-ietf-oauth-resource-indicators-04 o Editorial updates from AD review that were overlooked in -03. Campbell, et al. Expires March 14, 2020 [Page 12] Internet-Draft OAuth Resource Indicators September 2019 draft-ietf-oauth-resource-indicators-03 o Editorial updates from AD review. o Update draft-ietf-oauth-jwsreq ref to -19. o Update the IANA requests to say they update the registries. draft-ietf-oauth-resource-indicators-02 o Clarify that the value of the "resource" parameter is a URI which can be an abstract identifier for the target resource and doesn't necessarily have to correspond to a network addressable location. draft-ietf-oauth-resource-indicators-01 o Significant rework of the main section of the document attempting to clarify a number of things that came up at, around and after IETF 102 and the call for adoption. o Change the "invalid_resource" error to "invalid_target" to align with draft-ietf-oauth-token-exchange, which has some overlap in functionality. o Allow the "resource" parameter value to have a query component (aligning with draft-ietf-oauth-token-exchange). o Moved the Security Considerations section to before the IANA Considerations. o Other editorial updates. o Rework the Acknowledgements section. o Use RFC 8174 boilerplate. draft-ietf-oauth-resource-indicators-00 o First version of the working group document. A replica of draft- campbell-oauth-resource-indicators-02. draft-campbell-oauth-resource-indicators-02 o No changes. draft-campbell-oauth-resource-indicators-01 o Move Hannes Tschofenig, who wrote https://tools.ietf.org/html/ draft-tschofenig-oauth-audience in '13, from Acknowledgements to Authors. o Added IANA Considerations to register the "resource" parameter and "invalid_resource" error code. draft-campbell-oauth-resource-indicators-00 o Initial draft to define a resource parameter for OAuth 2.0. Campbell, et al. Expires March 14, 2020 [Page 13] Internet-Draft OAuth Resource Indicators September 2019 Authors' Addresses Brian Campbell Ping Identity Email: brian.d.campbell@gmail.com John Bradley Yubico Email: ve7jtb@ve7jtb.com Hannes Tschofenig Arm Limited Email: hannes.tschofenig@gmx.net Campbell, et al. Expires March 14, 2020 [Page 14] ./draft-ietf-rtcweb-data-protocol-09.txt0000644000764400076440000006737312452275542017445 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-oauth-token-exchange-19.txt0000644000764400076440000023270713515103550017411 0ustar iustyiusty OAuth Working Group M. Jones Internet-Draft A. Nadalin Intended status: Standards Track Microsoft Expires: January 21, 2020 B. Campbell, Ed. Ping Identity J. Bradley Yubico C. Mortimore Salesforce July 20, 2019 OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-19 Abstract This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. 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 https://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 21, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jones, et al. Expires January 21, 2020 [Page 1] Internet-Draft OAuth 2.0 Token Exchange July 2019 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. Delegation vs. Impersonation Semantics . . . . . . . . . 4 1.2. Requirements Notation and Conventions . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Token Exchange Request and Response . . . . . . . . . . . . . 6 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Relationship Between Resource, Audience and Scope . . 9 2.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Successful Response . . . . . . . . . . . . . . . . . 9 2.2.2. Error Response . . . . . . . . . . . . . . . . . . . 11 2.3. Example Token Exchange . . . . . . . . . . . . . . . . . 11 3. Token Type Identifiers . . . . . . . . . . . . . . . . . . . 13 4. JSON Web Token Claims and Introspection Response Parameters . 15 4.1. "act" (Actor) Claim . . . . . . . . . . . . . . . . . . . 15 4.2. "scope" (Scopes) Claim . . . . . . . . . . . . . . . . . 17 4.3. "client_id" (Client Identifier) Claim . . . . . . . . . . 18 4.4. "may_act" (Authorized Actor) Claim . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.1. OAuth URI Registration . . . . . . . . . . . . . . . . . 20 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 20 7.2. OAuth Parameters Registration . . . . . . . . . . . . . . 21 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 7.3. OAuth Access Token Type Registration . . . . . . . . . . 22 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 7.4. JSON Web Token Claims Registration . . . . . . . . . . . 22 7.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 7.5. OAuth Token Introspection Response Registration . . . . . 23 7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 7.6. OAuth Extensions Error Registration . . . . . . . . . . . 23 7.6.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Additional Token Exchange Examples . . . . . . . . . 26 A.1. Impersonation Token Exchange Example . . . . . . . . . . 26 A.1.1. Token Exchange Request . . . . . . . . . . . . . . . 26 A.1.2. Subject Token Claims . . . . . . . . . . . . . . . . 26 A.1.3. Token Exchange Response . . . . . . . . . . . . . . . 27 Jones, et al. Expires January 21, 2020 [Page 2] Internet-Draft OAuth 2.0 Token Exchange July 2019 A.1.4. Issued Token Claims . . . . . . . . . . . . . . . . . 27 A.2. Delegation Token Exchange Example . . . . . . . . . . . . 28 A.2.1. Token Exchange Request . . . . . . . . . . . . . . . 28 A.2.2. Subject Token Claims . . . . . . . . . . . . . . . . 29 A.2.3. Actor Token Claims . . . . . . . . . . . . . . . . . 29 A.2.4. Token Exchange Response . . . . . . . . . . . . . . . 29 A.2.5. Issued Token Claims . . . . . . . . . . . . . . . . . 30 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31 Appendix C. Document History . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction A security token is a set of information that facilitates the sharing of identity and security information in heterogeneous environments or across security domains. Examples of security tokens include JSON Web Tokens (JWTs) [JWT] and SAML 2.0 Assertions [OASIS.saml-core-2.0-os]. Security tokens are typically signed to achieve integrity and sometimes also encrypted to achieve confidentiality. Security tokens are also sometimes described as Assertions, such as in [RFC7521]. A Security Token Service (STS) is a service capable of validating security tokens provided to it and issuing new security tokens in response, which enables clients to obtain appropriate access credentials for resources in heterogeneous environments or across security domains. Web Service clients have used WS-Trust [WS-Trust] as the protocol to interact with an STS for token exchange. While WS-Trust uses XML and SOAP, the trend in modern Web development has been towards RESTful patterns and JSON. The OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens [RFC6750] have emerged as popular standards for authorizing third-party applications' access to HTTP and RESTful resources. The conventional OAuth 2.0 interaction involves the exchange of some representation of resource owner authorization for an access token, which has proven to be an extremely useful pattern in practice. However, its input and output are somewhat too constrained as is to fully accommodate a security token exchange framework. This specification defines a protocol extending OAuth 2.0 that enables clients to request and obtain security tokens from authorization servers acting in the role of an STS. Similar to OAuth 2.0, this specification focuses on client developer simplicity and requires only an HTTP client and JSON parser, which are nearly universally available in modern development environments. The STS protocol defined in this specification is not itself RESTful (an STS doesn't lend itself particularly well to a REST approach) but does Jones, et al. Expires January 21, 2020 [Page 3] Internet-Draft OAuth 2.0 Token Exchange July 2019 utilize communication patterns and data formats that should be familiar to developers accustomed to working with RESTful systems. A new grant type for a token exchange request and the associated specific parameters for such a request to the token endpoint are defined by this specification. A token exchange response is a normal OAuth 2.0 response from the token endpoint with a few additional parameters defined herein to provide information to the client. The entity that makes the request to exchange tokens is considered the client in the context of the token exchange interaction. However, that does not restrict usage of this profile to traditional OAuth clients. An OAuth resource server, for example, might assume the role of the client during token exchange in order to trade an access token that it received in a protected resource request for a new token that is appropriate to include in a call to a backend service. The new token might be an access token that is more narrowly scoped for the downstream service or it could be an entirely different kind of token. The scope of this specification is limited to the definition of a basic request-and-response protocol for an STS-style token exchange utilizing OAuth 2.0. Although a few new JWT claims are defined that enable delegation semantics to be expressed, the specific syntax, semantics and security characteristics of the tokens themselves (both those presented to the authorization server and those obtained by the client) are explicitly out of scope and no requirements are placed on the trust model in which an implementation might be deployed. Additional profiles may provide more detailed requirements around the specific nature of the parties and trust involved, such as whether signing and/or encryption of tokens is needed or if proof-of- possession style tokens will be required or issued; however, such details will often be policy decisions made with respect to the specific needs of individual deployments and will be configured or implemented accordingly. The security tokens obtained may be used in a number of contexts, the specifics of which are also beyond the scope of this specification. 1.1. Delegation vs. Impersonation Semantics One common use case for an STS (as alluded to in the previous section) is to allow a resource server A to make calls to a backend service C on behalf of the requesting user B. Depending on the local site policy and authorization infrastructure, it may be desirable for A to use its own credentials to access C along with an annotation of some form that A is acting on behalf of B ("delegation"), or for A to be granted a limited access credential to C but that continues to Jones, et al. Expires January 21, 2020 [Page 4] Internet-Draft OAuth 2.0 Token Exchange July 2019 identify B as the authorized entity ("impersonation"). Delegation and impersonation can be useful concepts in other scenarios involving multiple participants as well. When principal A impersonates principal B, A is given all the rights that B has within some defined rights context and is indistinguishable from B in that context. Thus, when principal A impersonates principal B, then insofar as any entity receiving such a token is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on, but it is not a requirement. For all intents and purposes, when A is impersonating B, A is B within the context of the rights authorized by the token. A's ability to impersonate B could be limited in scope or time, or even with a one- time-use restriction, whether via the contents of the token or an out-of-band mechanism. Delegation semantics are different than impersonation semantics, though the two are closely related. With delegation semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B. In a sense, A is an agent for B. Delegation and impersonation are not inclusive of all situations. When a principal is acting directly on its own behalf, for example, neither delegation nor impersonation are in play. They are, however, the more common semantics operating for token exchange and, as such, are given more direct treatment in this specification. Delegation semantics are typically expressed in a token by including information about both the primary subject of the token as well as the actor to whom that subject has delegated some of its rights. Such a token is sometimes referred to as a composite token because it is composed of information about multiple subjects. Typically, in the request, the "subject_token" represents the identity of the party on behalf of whom the token is being requested while the "actor_token" represents the identity of the party to whom the access rights of the issued token are being delegated. A composite token issued by the authorization server will contain information about both parties. When and if a composite token is issued is at the discretion of the authorization server and applicable policy and configuration. The specifics of representing a composite token and even whether or not such a token will be issued depend on the details of the implementation and the kind of token. The representations of composite tokens that are not JWTs are beyond the scope of this Jones, et al. Expires January 21, 2020 [Page 5] Internet-Draft OAuth 2.0 Token Exchange July 2019 specification. The "actor_token" request parameter, however, does provide a means for providing information about the desired actor and the JWT "act" claim can provide a representation of a chain of delegation. 1.2. Requirements Notation and Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Terminology This specification uses the terms "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request", and "token response" defined by OAuth 2.0 [RFC6749], and the terms "Base64url Encoding", "Claim", and "JWT Claims Set" defined by JSON Web Token (JWT) [JWT]. 2. Token Exchange Request and Response 2.1. Request A client requests a security token by making a token request to the authorization server's token endpoint using the extension grant type mechanism defined in Section 4.5 of [RFC6749]. Client authentication to the authorization server is done using the normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] defines password-based authentication of the client, however, client authentication is extensible and other mechanisms are possible. For example, [RFC7523] defines client authentication using bearer JSON Web Tokens (JWTs) [JWT]. The supported methods of client authentication and whether or not to allow unauthenticated or unidentified clients are deployment decisions that are at the discretion of the authorization server. Note that omitting client authentication allows for a compromised token to be leveraged via an STS into other tokens by anyone possessing the compromised token. Thus client authentication allows for additional authorization checks by the STS as to which entities are permitted to impersonate or receive delegations from other entities. The client makes a token exchange request to the token endpoint with an extension grant type using the HTTP "POST" method. The following parameters are included in the HTTP request entity-body using the Jones, et al. Expires January 21, 2020 [Page 6] Internet-Draft OAuth 2.0 Token Exchange July 2019 "application/x-www-form-urlencoded" format with a character encoding of UTF-8 as described in Appendix B of RFC6749 [RFC6749]. grant_type REQUIRED. The value "urn:ietf:params:oauth:grant-type:token- exchange" indicates that a token exchange is being performed. resource OPTIONAL. A URI that indicates the target service or resource where the client intends to use the requested security token. This enables the authorization server to apply policy as appropriate for the target, such as determining the type and content of the token to be issued or if and how the token is to be encrypted. In many cases, a client will not have knowledge of the logical organization of the systems with which it interacts and will only know a URI of the service where it intends to use the token. The "resource" parameter allows the client to indicate to the authorization server where it intends to use the issued token by providing the location, typically as an https URL, in the token exchange request in the same form that will be used to access that resource. The authorization server will typically have the capability to map from a resource URI value to an appropriate policy. The value of the "resource" parameter MUST be an absolute URI, as specified by Section 4.3 of [RFC3986], which MAY include a query component and MUST NOT include a fragment component. Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. See [I-D.ietf-oauth-resource-indicators] for additional background and uses of the "resource" parameter. audience OPTIONAL. The logical name of the target service where the client intends to use the requested security token. This serves a purpose similar to the "resource" parameter, but with the client providing a logical name for the target service. Interpretation of the name requires that the value be something that both the client and the authorization server understand. An OAuth client identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an OpenID Connect Issuer Identifier [OpenID.Core], are examples of things that might be used as "audience" parameter values. However, "audience" values used with a given authorization server must be unique within that server, to ensure that they are properly interpreted as the intended type of value. Multiple "audience" parameters may be used to indicate that the issued token is intended to be used at the multiple audiences listed. The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical names and resource URIs. Jones, et al. Expires January 21, 2020 [Page 7] Internet-Draft OAuth 2.0 Token Exchange July 2019 scope OPTIONAL. A list of space-delimited, case-sensitive strings, as defined in Section 3.3 of [RFC6749], that allow the client to specify the desired scope of the requested security token in the context of the service or resource where the token will be used. The values and associated semantics of scope are service specific and expected to be described in the relevant service documentation. requested_token_type OPTIONAL. An identifier, as described in Section 3, for the type of the requested security token. If the requested type is unspecified, the issued token type is at the discretion of the authorization server and may be dictated by knowledge of the requirements of the service or resource indicated by the "resource" or "audience" parameter. subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made. Typically, the subject of this token will be the subject of the security token issued in response to the request. subject_token_type REQUIRED. An identifier, as described in Section 3, that indicates the type of the security token in the "subject_token" parameter. actor_token OPTIONAL. A security token that represents the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject. actor_token_type An identifier, as described in Section 3, that indicates the type of the security token in the "actor_token" parameter. This is REQUIRED when the "actor_token" parameter is present in the request but MUST NOT be included otherwise. In processing the request, the authorization server MUST perform the appropriate validation procedures for the indicated token type and, if the actor token is present, also perform the appropriate validation procedures for its indicated token type. The validity criteria and details of any particular token are beyond the scope of this document and are specific to the respective type of token and its content. Jones, et al. Expires January 21, 2020 [Page 8] Internet-Draft OAuth 2.0 Token Exchange July 2019 In the absence of one-time-use or other semantics specific to the token type, the act of performing a token exchange has no impact on the validity of the subject token or actor token. Furthermore, the exchange is a one-time event and does not create a tight linkage between the input and output tokens, so that (for example) while the expiration time of the output token may be influenced by that of the input token, renewal or extension of the input token is not expected to be reflected in the output token's properties. It may still be appropriate or desirable to propagate token revocation events. However, doing so is not a general property of the STS protocol and would be specific to a particular implementation, token type or deployment. 2.1.1. Relationship Between Resource, Audience and Scope When requesting a token, the client can indicate the desired target service(s) where it intends to use that token by way of the "audience" and "resource" parameters, as well as indicating the desired scope of the requested token using the "scope" parameter. The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services. Effectively, the requested access rights of the token are the cartesian product of all the scopes at all the target services. An authorization server may be unwilling or unable to fulfill any token request but the likelihood of an unfulfillable request is significantly higher when very broad access rights are being solicited. As such, in the absence of specific knowledge about the relationship of systems in a deployment, clients should exercise discretion in the breadth of the access requested, particularly the number of target services. An authorization server can use the "invalid_target" error code, defined in Section 2.2.2, to inform a client that it requested access to too many target services simultaneously. 2.2. Response The authorization server responds to a token exchange request with a normal OAuth 2.0 response from the token endpoint, as specified in Section 5 of [RFC6749]. Additional details and explanation are provided in the following subsections. 2.2.1. Successful Response If the request is valid and meets all policy and other criteria of the authorization server, a successful token response is constructed by adding the following parameters to the entity-body of the HTTP Jones, et al. Expires January 21, 2020 [Page 9] Internet-Draft OAuth 2.0 Token Exchange July 2019 response using the "application/json" media type, as specified by [RFC8259], and an HTTP 200 status code. The parameters are serialized into a JavaScript Object Notation (JSON) structure by adding each parameter at the top level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. The order of parameters does not matter and can vary. access_token REQUIRED. The security token issued by the authorization server in response to the token exchange request. The "access_token" parameter from Section 5.1 of [RFC6749] is used here to carry the requested token, which allows this token exchange protocol to use the existing OAuth 2.0 request and response constructs defined for the token endpoint. The identifier "access_token" is used for historical reasons and the issued token need not be an OAuth access token. issued_token_type REQUIRED. An identifier, as described in Section 3, for the representation of the issued security token. token_type REQUIRED. A case-insensitive value specifying the method of using the access token issued, as specified in Section 7.1 of [RFC6749]. It provides the client with information about how to utilize the access token to access protected resources. For example, a value of "Bearer", as specified in [RFC6750], indicates that the issued security token is a bearer token and the client can simply present it as is without any additional proof of eligibility beyond the contents of the token itself. Note that the meaning of this parameter is different from the meaning of the "issued_token_type" parameter, which declares the representation of the issued security token; the term "token type" is more typically used with the aforementioned meaning as the structural or syntactical representation of the security token, as it is in all "*_token_type" parameters in this specification. If the issued token is not an access token or usable as an access token, then the "token_type" value "N_A" is used to indicate that an OAuth 2.0 "token_type" identifier is not applicable in that context. expires_in RECOMMENDED. The validity lifetime, in seconds, of the token issued by the authorization server. Oftentimes the client will not have the inclination or capability to inspect the content of the token and this parameter provides a consistent and token-type- agnostic indication of how long the token can be expected to be Jones, et al. Expires January 21, 2020 [Page 10] Internet-Draft OAuth 2.0 Token Exchange July 2019 valid. For example, the value 1800 denotes that the token will expire in thirty minutes from the time the response was generated. scope OPTIONAL, if the scope of the issued security token is identical to the scope requested by the client; otherwise, REQUIRED. refresh_token OPTIONAL. A refresh token will typically not be issued when the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context. A refresh token can be issued in cases where the client of the token exchange needs the ability to access a resource even when the original credential is no longer valid (e.g., user-not-present or offline scenarios where there is no longer any user entertaining an active session with the client). Profiles or deployments of this specification should clearly document the conditions under which a client should expect a refresh token in response to "urn:ietf:params:oauth:grant- type:token-exchange" grant type requests. 2.2.2. Error Response If the request itself is not valid or if either the "subject_token" or "actor_token" are invalid for any reason, or are unacceptable based on policy, the authorization server MUST construct an error response, as specified in Section 5.2 of [RFC6749]. The value of the "error" parameter MUST be the "invalid_request" error code. If the authorization server is unwilling or unable to issue a token for any target service indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response. The authorization server MAY include additional information regarding the reasons for the error using the "error_description" as discussed in Section 5.2 of [RFC6749]. Other error codes may also be used, as appropriate. 2.3. Example Token Exchange The following example demonstrates a hypothetical token exchange in which an OAuth resource server assumes the role of the client during the exchange. It trades an access token, which it received in a protected resource request, for a new token that it will use to call to a backend service (extra line breaks and indentation in the examples are for display purposes only). Jones, et al. Expires January 21, 2020 [Page 11] Internet-Draft OAuth 2.0 Token Exchange July 2019 Figure 1 shows the resource server receiving a protected resource request containing an OAuth access token in the Authorization header, as specified in Section 2.1 of [RFC6750]. GET /resource HTTP/1.1 Host: frontend.example.com Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC Figure 1: Protected Resource Request In Figure 2, the resource server assumes the role of client for the token exchange and the access token from the request in Figure 1 is sent to the authorization server using a request as specified in Section 2.1. The value of the "subject_token" parameter carries the access token and the value of the "subject_token_type" parameter indicates that it is an OAuth 2.0 access token. The resource server, acting in the role of the client, uses its identifier and secret to authenticate to the authorization server using the HTTP Basic authentication scheme. The "resource" parameter indicates the location of the backend service, https://backend.example.com/api, where the issued token will be used. POST /as/token.oauth2 HTTP/1.1 Host: as.example.com Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0 Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &resource=https%3A%2F%2Fbackend.example.com%2Fapi &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC &subject_token_type= urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token Figure 2: Token Exchange Request The authorization server validates the client credentials and the "subject_token" presented in the token exchange request. From the "resource" parameter, the authorization server is able to determine the appropriate policy to apply to the request and issues a token suitable for use at https://backend.example.com. The "access_token" parameter of the response shown in Figure 3 contains the new token, which is itself a bearer OAuth access token that is valid for one minute. The token happens to be a JWT; however, its structure and format are opaque to the client so the "issued_token_type" indicates only that it is an access token. Jones, et al. Expires January 21, 2020 [Page 12] Internet-Draft OAuth 2.0 Token Exchange July 2019 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV 4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM y5-kdXjwhw", "issued_token_type": "urn:ietf:params:oauth:token-type:access_token", "token_type":"Bearer", "expires_in":60 } Figure 3: Token Exchange Response The resource server can then use the newly acquired access token in making a request to the backend server as illustrated in Figure 4. GET /api HTTP/1.1 Host: backend.example.com Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2 FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW vmDCMy5-kdXjwhw Figure 4: Backend Protected Resource Request Additional examples can be found in Appendix A. 3. Token Type Identifiers Several parameters in this specification utilize an identifier as the value to describe the token in question. Specifically, they are the "requested_token_type", "subject_token_type", "actor_token_type" parameters of the request and the "issued_token_type" member of the response. Token type identifiers are URIs. Token Exchange can work with both tokens issued by other parties and tokens from the given authorization server. For the former the token type identifier indicates the syntax (e.g., JWT or SAML 2.0) so the authorization server can parse it; for the latter it indicates what the given authorization server issued it for (e.g., access_token or refresh_token). Jones, et al. Expires January 21, 2020 [Page 13] Internet-Draft OAuth 2.0 Token Exchange July 2019 The following token type identifiers are defined by this specification. Other URIs MAY be used to indicate other token types. urn:ietf:params:oauth:token-type:access_token Indicates that the token is an OAuth 2.0 access token issued by the given authorization server. urn:ietf:params:oauth:token-type:refresh_token Indicates that the token is an OAuth 2.0 refresh token issued by the given authorization server. urn:ietf:params:oauth:token-type:id_token Indicates that the token is an ID Token, as defined in Section 2 of [OpenID.Core]. urn:ietf:params:oauth:token-type:saml1 Indicates that the token is a base64url-encoded SAML 1.1 [OASIS.saml-core-1.1] assertion. urn:ietf:params:oauth:token-type:saml2 Indicates that the token is a base64url-encoded SAML 2.0 [OASIS.saml-core-2.0-os] assertion. The value "urn:ietf:params:oauth:token-type:jwt", which is defined in Section 9 of [JWT], indicates that the token is a JWT. The distinction between an access token and a JWT is subtle. An access token represents a delegated authorization decision, whereas JWT is a token format. An access token can be formatted as a JWT but doesn't necessarily have to be. And a JWT might well be an access token but not all JWTs are access tokens. The intent of this specification is that "urn:ietf:params:oauth:token-type:access_token" be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client, and usable the same manner as any other access token obtained from that authorization server. (It could well be a JWT, but the client isn't and needn't be aware of that fact.) Whereas, "urn:ietf:params:oauth:token-type:jwt" is to indicate specifically that a JWT is being requested or sent (perhaps in a cross-domain use- case where the JWT is used as an authorization grant to obtain an access token from a different authorization server as is facilitated by [RFC7523]). Note that for tokens which are binary in nature, the URI used for conveying them needs to be associated with the semantics of a base64 or other encoding suitable for usage with HTTP and OAuth. Jones, et al. Expires January 21, 2020 [Page 14] Internet-Draft OAuth 2.0 Token Exchange July 2019 4. JSON Web Token Claims and Introspection Response Parameters It is useful to have defined mechanisms to express delegation within a token as well as to express authorization to delegate or impersonate. Although the token exchange protocol described herein can be used with any type of token, this section defines claims to express such semantics specifically for JWTs and in an OAuth 2.0 Token Introspection [RFC7662] response. Similar definitions for other types of tokens are possible but beyond the scope of this specification. Note that the claims not established herein but used in examples and descriptions, such as "iss", "sub", "exp", etc., are defined by [JWT]. 4.1. "act" (Actor) Claim The "act" (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated. The "act" claim value is a JSON object and members in the JSON object are claims that identify the actor. The claims that make up the "act" claim identify and possibly provide additional information about the actor. For example, the combination of the two claims "iss" and "sub" might be necessary to uniquely identify an actor. However, claims within the "act" claim pertain only to the identity of the actor and are not relevant to the validity of the containing JWT in the same manner as the top-level claims. Consequently, non- identity claims (e.g., "exp", "nbf", and "aud") are not meaningful when used within an "act" claim, and therefore are not used. Jones, et al. Expires January 21, 2020 [Page 15] Internet-Draft OAuth 2.0 Token Exchange July 2019 Figure 5 illustrates the "act" (actor) claim within a JWT Claims Set. The claims of the token itself are about user@example.com while the "act" claim indicates that admin@example.com is the current actor. { "aud":"https://consumer.example.com", "iss":"https://issuer.example.com", "exp":1443904177, "nbf":1443904077, "sub":"user@example.com", "act": { "sub":"admin@example.com" } } Figure 5: Actor Claim A chain of delegation can be expressed by nesting one "act" claim within another. The outermost "act" claim represents the current actor while nested "act" claims represent prior actors. The least recent actor is the most deeply nested. The nested "act" claims serve as a history trail that connects the initial request and subject through the various delegation steps undertaken before reaching the current actor. In this sense, the current actor is considered to include the entire authorization/delegation history, leading naturally to the nested structure described here. For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the "act" claim. Prior actors identified by any nested "act" claims are informational only and are not to be considered in access control decisions. Jones, et al. Expires January 21, 2020 [Page 16] Internet-Draft OAuth 2.0 Token Exchange July 2019 The following example in Figure 6 illustrates nested "act" (actor) claims within a JWT Claims Set. The claims of the token itself are about user@example.com while the "act" claim indicates that the system https://service16.example.com is the current actor and https://service77.example.com was a prior actor. Such a token might come about as the result of service16 receiving a token in a call from service77 and exchanging it for a token suitable to call service26 while the authorization server notes the situation in the newly issued token. { "aud":"https://service26.example.com", "iss":"https://issuer.example.com", "exp":1443904100, "nbf":1443904000, "sub":"user@example.com", "act": { "sub":"https://service16.example.com", "act": { "sub":"https://service77.example.com" } } } Figure 6: Nested Actor Claim When included as a top-level member of an OAuth token introspection response, "act" has the same semantics and format as the claim of the same name. 4.2. "scope" (Scopes) Claim The value of the "scope" claim is a JSON string containing a space- separated list of scopes associated with the token, in the format described in Section 3.3 of [RFC6749]. Jones, et al. Expires January 21, 2020 [Page 17] Internet-Draft OAuth 2.0 Token Exchange July 2019 Figure 7 illustrates the "scope" claim within a JWT Claims Set. { "aud":"https://consumer.example.com", "iss":"https://issuer.example.com", "exp":1443904177, "nbf":1443904077, "sub":"dgaf4mvfs75Fci_FL3heQA", "scope":"email profile phone address" } Figure 7: Scopes Claim OAuth 2.0 Token Introspection [RFC7662] already defines the "scope" parameter to convey the scopes associated with the token. 4.3. "client_id" (Client Identifier) Claim The "client_id" claim carries the client identifier of the OAuth 2.0 [RFC6749] client that requested the token. The following example in Figure 8 illustrates the "client_id" claim within a JWT Claims Set indicating an OAuth 2.0 client with "s6BhdRkqt3" as its identifier. { "aud":"https://consumer.example.com", "iss":"https://issuer.example.com", "exp":1443904177, "sub":"user@example.com", "client_id":"s6BhdRkqt3" } Figure 8: Client Identifier Claim OAuth 2.0 Token Introspection [RFC7662] already defines the "client_id" parameter as the client identifier for the OAuth 2.0 client that requested the token. 4.4. "may_act" (Authorized Actor) Claim The "may_act" claim makes a statement that one party is authorized to become the actor and act on behalf of another party. The claim might be used, for example, when a "subject_token" is presented to the token endpoint in a token exchange request and "may_act" claim in the subject token can be used by the authorization server to determine whether the client (or party identified in the "actor_token") is authorized to engage in the requested delegation or impersonation. Jones, et al. Expires January 21, 2020 [Page 18] Internet-Draft OAuth 2.0 Token Exchange July 2019 The claim value is a JSON object and members in the JSON object are claims that identify the party that is asserted as being eligible to act for the party identified by the JWT containing the claim. The claims that make up the "may_act" claim identify and possibly provide additional information about the authorized actor. For example, the combination of the two claims "iss" and "sub" are sometimes necessary to uniquely identify an authorized actor, while the "email" claim might be used to provide additional useful information about that party. However, claims within the "may_act" claim pertain only to the identity of that party and are not relevant to the validity of the containing JWT in the same manner as top-level claims. Consequently, claims such as "exp", "nbf", and "aud" are not meaningful when used within a "may_act" claim, and therefore are not used. Figure 9 illustrates the "may_act" claim within a JWT Claims Set. The claims of the token itself are about user@example.com while the "may_act" claim indicates that admin@example.com is authorized to act on behalf of user@example.com. { "aud":"https://consumer.example.com", "iss":"https://issuer.example.com", "exp":1443904177, "nbf":1443904077, "sub":"user@example.com", "may_act": { "sub":"admin@example.com" } } Figure 9: Authorized Actor Claim When included as a top-level member of an OAuth token introspection response, "may_act" has the same semantics and format as the claim of the same name. 5. Security Considerations Much of the guidance from Section 10 of [RFC6749], the Security Considerations in The OAuth 2.0 Authorization Framework, is also applicable here. Furthermore, [RFC6819] provides additional security considerations for OAuth and [I-D.ietf-oauth-security-topics] has updated security guidance based on deployment experience and new threats that have emerged since OAuth 2.0 was originally published. Jones, et al. Expires January 21, 2020 [Page 19] Internet-Draft OAuth 2.0 Token Exchange July 2019 All of the normal security issues that are discussed in [JWT], especially in relationship to comparing URIs and dealing with unrecognized values, also apply here. In addition, both delegation and impersonation introduce unique security issues. Any time one principal is delegated the rights of another principal, the potential for abuse is a concern. The use of the "scope" claim (in addition to other typical constraints such as a limited token lifetime) is suggested to mitigate potential for such abuse, as it restricts the contexts in which the delegated rights can be exercised. 6. Privacy Considerations Tokens employed in the context of the functionality described herein may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, MUST only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure of certain information to the client, the token MUST be encrypted to its intended recipient. Deployments SHOULD determine the minimally necessary amount of data and only include such information in issued tokens. In some cases, data minimization may include representing only an anonymous or pseudonymous user. 7. IANA Considerations 7.1. OAuth URI Registration This specification registers the following values in the IANA "OAuth URI" registry [IANA.OAuth.Parameters] established by [RFC6755]. 7.1.1. Registry Contents o URN: urn:ietf:params:oauth:grant-type:token-exchange o Common Name: Token exchange grant type for OAuth 2.0 o Change controller: IESG o Specification Document: Section 2.1 of [[ this specification ]] o URN: urn:ietf:params:oauth:token-type:access_token o Common Name: Token type URI for an OAuth 2.0 access token o Change controller: IESG o Specification Document: Section 3 of [[this specification]] o URN: urn:ietf:params:oauth:token-type:refresh_token o Common Name: Token type URI for an OAuth 2.0 refresh token o Change controller: IESG o Specification Document: Section 3 of [[this specification]] Jones, et al. Expires January 21, 2020 [Page 20] Internet-Draft OAuth 2.0 Token Exchange July 2019 o URN: urn:ietf:params:oauth:token-type:id_token o Common Name: Token type URI for an ID Token o Change controller: IESG o Specification Document: Section 3 of [[this specification]] o URN: urn:ietf:params:oauth:token-type:saml1 o Common Name: Token type URI for a base64url-encoded SAML 1.1 assertion o Change Controller: IESG o Specification Document: Section 3 of [[this specification]] o URN: urn:ietf:params:oauth:token-type:saml2 o Common Name: Token type URI for a base64url-encoded SAML 2.0 assertion o Change Controller: IESG o Specification Document: Section 3 of [[this specification]] 7.2. OAuth Parameters Registration This specification registers the following values in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749]. 7.2.1. Registry Contents o Parameter name: resource o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: audience o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: requested_token_type o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: subject_token o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: subject_token_type o Parameter usage location: token request o Change controller: IESG Jones, et al. Expires January 21, 2020 [Page 21] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: actor_token o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: actor_token_type o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: issued_token_type o Parameter usage location: token response o Change controller: IESG o Specification document(s): Section 2.2.1 of [[ this specification ]] 7.3. OAuth Access Token Type Registration This specification registers the following access token type in the IANA "OAuth Access Token Types" registry [IANA.OAuth.Parameters] established by [RFC6749]. 7.3.1. Registry Contents o Type name: N_A o Additional Token Endpoint Response Parameters: (none) o HTTP Authentication Scheme(s): (none) o Change controller: IESG o Specification document(s): Section 2.2.1 of [[ this specification ]] 7.4. JSON Web Token Claims Registration This specification registers the following Claims in the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] established by [JWT]. 7.4.1. Registry Contents o Claim Name: "act" o Claim Description: Actor o Change Controller: IESG o Specification Document(s): Section 4.1 of [[ this specification ]] o Claim Name: "scope" o Claim Description: Scope Values o Change Controller: IESG Jones, et al. Expires January 21, 2020 [Page 22] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Specification Document(s): Section 4.2 of [[ this specification ]] o Claim Name: "client_id" o Claim Description: Client Identifier o Change Controller: IESG o Specification Document(s): Section 4.3 of [[ this specification ]] o Claim Name: "may_act" o Claim Description: Authorized Actor - the party that is authorized to become the actor o Change Controller: IESG o Specification Document(s): Section 4.4 of [[ this specification ]] 7.5. OAuth Token Introspection Response Registration This specification registers the following values in the IANA "OAuth Token Introspection Response" registry [IANA.OAuth.Parameters] established by [RFC7662]. 7.5.1. Registry Contents o Claim Name: "act" o Claim Description: Actor o Change Controller: IESG o Specification Document(s): Section 4.1 of [[ this specification ]] o Claim Name: "may_act" o Claim Description: Authorized Actor - the party that is authorized to become the actor o Change Controller: IESG o Specification Document(s): Section 4.4 of [[ this specification ]] 7.6. OAuth Extensions Error Registration This specification registers the following values in the IANA "OAuth Extensions Error" registry [IANA.OAuth.Parameters] established by [RFC6749]. 7.6.1. Registry Contents o Error Name: "invalid_target" o Error Usage Location: token error response o Related Protocol Extension: OAuth 2.0 Token Exchange o Change Controller: IETF o Specification Document(s): Section 2.2.2 of [[ this specification ]] Jones, et al. Expires January 21, 2020 [Page 23] Internet-Draft OAuth 2.0 Token Exchange July 2019 8. References 8.1. Normative References [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 8.2. Informative References Jones, et al. Expires January 21, 2020 [Page 24] Internet-Draft OAuth 2.0 Token Exchange July 2019 [I-D.ietf-oauth-resource-indicators] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", draft-ietf-oauth-resource- indicators-02 (work in progress), January 2019. [I-D.ietf-oauth-security-topics] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", draft-ietf- oauth-security-topics-13 (work in progress), July 2019. [OASIS.saml-core-1.1] Maler, E., Mishra, P., and R. Philpott, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1", OASIS Standard oasis-sstc-saml-core-1.1, September 2003. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, . [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, . Jones, et al. Expires January 21, 2020 [Page 25] Internet-Draft OAuth 2.0 Token Exchange July 2019 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [WS-Trust] Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", February 2012, . Appendix A. Additional Token Exchange Examples Two example token exchanges are provided in the following sections illustrating impersonation and delegation, respectively (with extra line breaks and indentation for display purposes only). A.1. Impersonation Token Exchange Example A.1.1. Token Exchange Request In the following token exchange request, a client is requesting a token with impersonation semantics (with only a "subject_token" and no "actor_token", delegation is impossible). The client tells the authorization server that it needs a token for use at the target service with the logical name "urn:example:cooperation-context". POST /as/token.oauth2 HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &audience=urn%3Aexample%3Acooperation-context &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic 3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN 0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ hF64pbTtfjy4VXFVBDaQpKjn5JzAw &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt Figure 10: Token Exchange Request A.1.2. Subject Token Claims The "subject_token" in the prior request is a JWT and the decoded JWT Claims Set is shown here. The JWT is intended for consumption by the authorization server within a specific time window. The subject of Jones, et al. Expires January 21, 2020 [Page 26] Internet-Draft OAuth 2.0 Token Exchange July 2019 the JWT ("bdc@example.net") is the party on behalf of whom the new token is being requested. { "aud":"https://as.example.com", "iss":"https://original-issuer.example.net", "exp":1441910600, "nbf":1441909000, "sub":"bdc@example.net", "scope":"orders profile history" } Figure 11: Subject Token Claims A.1.3. Token Exchange Response The "access_token" parameter of the token exchange response shown below contains the new token that the client requested. The other parameters of the response indicate that the token is a bearer access token that expires in an hour. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4 6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW nVKh85A", "issued_token_type": "urn:ietf:params:oauth:token-type:access_token", "token_type":"Bearer", "expires_in":3600 } Figure 12: Token Exchange Response A.1.4. Issued Token Claims The decoded JWT Claims Set of the issued token is shown below. The new JWT is issued by the authorization server and intended for consumption by a system entity known by the logical name "urn:example:cooperation-context" any time before its expiration. The subject ("sub") of the JWT is the same as the subject the token used to make the request, which effectively enables the client to Jones, et al. Expires January 21, 2020 [Page 27] Internet-Draft OAuth 2.0 Token Exchange July 2019 impersonate that subject at the system entity known by the logical name of "urn:example:cooperation-context" by using the token. { "aud":"urn:example:cooperation-context", "iss":"https://as.example.com", "exp":1441913610, "sub":"bdc@example.net", "scope":"orders profile history" } Figure 13: Issued Token Claims A.2. Delegation Token Exchange Example A.2.1. Token Exchange Request In the following token exchange request, a client is requesting a token and providing both a "subject_token" and an "actor_token". The client tells the authorization server that it needs a token for use at the target service with the logical name "urn:example:cooperation- context". Policy at the authorization server dictates that the issued token be a composite. POST /as/token.oauth2 HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &audience=urn%3Aexample%3Acooperation-context &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1 pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt &actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ oUuDL2tEs6tqPlcBlMjiSzEjm3yBg &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt Figure 14: Token Exchange Request Jones, et al. Expires January 21, 2020 [Page 28] Internet-Draft OAuth 2.0 Token Exchange July 2019 A.2.2. Subject Token Claims The "subject_token" in the prior request is a JWT and the decoded JWT Claims Set is shown here. The JWT is intended for consumption by the authorization server before a specific expiration time. The subject of the JWT ("user@example.net") is the party on behalf of whom the new token is being requested. { "aud":"https://as.example.com", "iss":"https://original-issuer.example.net", "exp":1441910060, "scope":"status feed", "sub":"user@example.net", "may_act": { "sub":"admin@example.net" } } Figure 15: Subject Token Claims A.2.3. Actor Token Claims The "actor_token" in the prior request is a JWT and the decoded JWT Claims Set is shown here. This JWT is also intended for consumption by the authorization server before a specific expiration time. The subject of the JWT ("admin@example.net") is the actor that will wield the security token being requested. { "aud":"https://as.example.com", "iss":"https://original-issuer.example.net", "exp":1441910060, "sub":"admin@example.net" } Figure 16: Actor Token Claims A.2.4. Token Exchange Response The "access_token" parameter of the token exchange response shown below contains the new token that the client requested. The other parameters of the response indicate that the token is a JWT that expires in an hour and that the access token type is not applicable since the issued token is not an access token. Jones, et al. Expires January 21, 2020 [Page 29] Internet-Draft OAuth 2.0 Token Exchange July 2019 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4 6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG 9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw", "issued_token_type":"urn:ietf:params:oauth:token-type:jwt", "token_type":"N_A", "expires_in":3600 } Figure 17: Token Exchange Response A.2.5. Issued Token Claims The decoded JWT Claims Set of the issued token is shown below. The new JWT is issued by the authorization server and intended for consumption by a system entity known by the logical name "urn:example:cooperation-context" any time before its expiration. The subject ("sub") of the JWT is the same as the subject of the "subject_token" used to make the request. The actor ("act") of the JWT is the same as the subject of the "actor_token" used to make the request. This indicates delegation and identifies "admin@example.net" as the current actor to whom authority has been delegated to act on behalf of "user@example.net". { "aud":"urn:example:cooperation-context", "iss":"https://as.example.com", "exp":1441913610, "scope":"status feed", "sub":"user@example.net", "act": { "sub":"admin@example.net" } } Figure 18: Issued Token Claims Jones, et al. Expires January 21, 2020 [Page 30] Internet-Draft OAuth 2.0 Token Exchange July 2019 Appendix B. Acknowledgements This specification was developed within the OAuth Working Group, which includes dozens of active and dedicated participants. It was produced under the chairmanship of Hannes Tschofenig, Derek Atkins, and Rifaat Shekh-Yusef with Kathleen Moriarty, Stephen Farrell, Eric Rescorla, Roman Danyliw, and Benjamin Kaduk serving as Security Area Directors. The following individuals contributed ideas, feedback, and wording to this specification: Caleb Baker, Vittorio Bertocci, Mike Brown, Thomas Broyer, Roman Danyliw, William Denniss, Vladimir Dzhuvinov, Eric Fazendin, Phil Hunt, Benjamin Kaduk, Jason Keglovitz, Torsten Lodderstedt, Barry Leiba, Adam Lewis, James Manger, Nov Matake, Matt Miller, Hilarie Orman, Matthew Perry, Eric Rescorla, Justin Richer, Adam Roach, Rifaat Shekh-Yusef, Scott Tomilson, and Hannes Tschofenig. Appendix C. Document History [[ to be removed by the RFC Editor before publication as an RFC ]] -19 o Fix-up changes introduced in -18. o Fix invalid JSON in the Nested Actor Claim example. o Reference figure numbers in text when introducing the examples in Section 2 and 4. o Editorial updates from additional IESG evaluation comments. o Add an informational reference to ietf-oauth-resource-indicators o Update ietf-oauth-security-topics ref to 13 -18 o Editorial updates based on a few more IESG evaluation comments. -17 o Editorial improvements and example fixes resulting from IESG evaluation comments. o Added a pointer to RFC6749's Appendix B. on the "Use of application/x-www-form-urlencoded Media Type" as a way of providing a normative citation (by reference) for the media type. o Strengthened some of the wording in the privacy considerations to bring it inline with RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. -16 o Fixed typo and added an AD to Acknowledgements. Jones, et al. Expires January 21, 2020 [Page 31] Internet-Draft OAuth 2.0 Token Exchange July 2019 -15 o Updated the nested actor claim example to (hopefully) be more straightforward. o Reworked Privacy Considerations to say to use TLS in transit, minimize the amount of information in the token, and encrypt the token if disclosure of its information to the client is a concern per https://mailarchive.ietf.org/arch/msg/secdir/ KJhx4aq_U5uk3k6zpYP-CEHbpVM o Moved the Security and Privacy Considerations sections to before the IANA Considerations. -14 o Added text in Section 4.1 about the "act" claim stating that only the top-level claims and the current actor are to be considered in applying access control decisions. -13 o Updated the claim name and value syntax for scope to be consistent with the treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. o Updated the client identifier claim name to be consistent with the treatment of client id in RFC 7662 OAuth 2.0 Token Introspection. -12 o Updated to use the boilerplate from RFC 8174. -11 o Added new WG chair and AD to the Acknowledgements. o Applied clarifications suggested during AD review by EKR. -10 o Defined token type URIs for base64url-encoded SAML 1.1 and SAML 2.0 assertions. o Applied editorial fixes. -09 o Changed "security tokens obtained could be used in a number of contexts" to "security tokens obtained may be used in a number of contexts" per a WGLC suggestion. Jones, et al. Expires January 21, 2020 [Page 32] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Clarified that the validity of the subject or actor token have no impact on the validity of the issued token after the exchange has occurred per a WGLC comment. o Changed use of invalid_target error code to a SHOULD per a WGLC comment. o Clarified text about non-identity claims within the "act" claim being meaningless per a WGLC comment. o Added brief Privacy Considerations section per WGLC comments. -08 o Use the bibxml reference for OpenID.Core rather than defining it inline. o Added editor role for Campbell. o Minor clarification of the text for actor_token. -07 o Fixed typo (desecration -> discretion). o Added an explanation of the relationship between scope, audience and resource in the request and added an "invalid_target" error code enabling the AS to tell the client that the requested audiences/resources were too broad. -06 o Drop "An STS for the REST of Us" from the title. o Drop "heavyweight" and "lightweight" from the abstract and introduction. o Clarifications on the language around xxxxxx_token_type. o Remove the want_composite parameter. o Add a short mention of proof-of-possession style tokens to the introduction and remove the respective open issue. -05 o Defined the JWT claim "cid" to express the OAuth 2.0 client identifier of the client that requested the token. o Defined and requested registration for "act" and "may_act" as Token introspection response parameters (in addition to being JWT claims). o Loosen up the language about refresh_token in the response to OPTIONAL from NOT RECOMMENDED based on feedback form real world deployment experience. o Add clarifying text about the distinction between JWT and access token URIs. o Close out (remove) some of the Open Issues bullets that have been resolved. Jones, et al. Expires January 21, 2020 [Page 33] Internet-Draft OAuth 2.0 Token Exchange July 2019 -04 o Clarified that the "resource" and "audience" request parameters can be used at the same time (via http://www.ietf.org/mail- archive/web/oauth/current/msg15335.html). o Clarified subject/actor token validity after token exchange and explained a bit more about the recommendation to not issue refresh tokens (via http://www.ietf.org/mail-archive/web/oauth/current/ msg15318.html). o Updated the examples appendix to use an issuer value that doesn't imply that the client issued and signed the tokens and used "Bearer" and "urn:ietf:params:oauth:token-type:access_token" in one of the responses (via http://www.ietf.org/mail- archive/web/oauth/current/msg15335.html). o Defined and registered urn:ietf:params:oauth:token-type:id_token, since some use cases perform token exchanges for ID Tokens and no URI to indicate that a token is an ID Token had previously been defined. -03 o Updated the document editors (adding Campbell, Bradley, and Mortimore). o Added to the title. o Added to the abstract and introduction. o Updated the format of the request to use application/x-www-form- urlencoded request parameters and the response to use the existing token endpoint JSON parameters defined in OAuth 2.0. o Changed the grant type identifier to urn:ietf:params:oauth:grant- type:token-exchange. o Added RFC 6755 registration requests for urn:ietf:params:oauth:token-type:refresh_token, urn:ietf:params:oauth:token-type:access_token, and urn:ietf:params:oauth:grant-type:token-exchange. o Added RFC 6749 registration requests for request/response parameters. o Removed the Implementation Considerations and the requirement to support JWTs. o Clarified many aspects of the text. o Changed "on_behalf_of" to "subject_token", "on_behalf_of_token_type" to "subject_token_type", "act_as" to "actor_token", and "act_as_token_type" to "actor_token_type". o Added an "audience" request parameter used to indicate the logical names of the target services at which the client intends to use the requested security token. o Added a "want_composite" request parameter used to indicate the desire for a composite token rather than trying to infer it from the presence/absence of token(s) in the request. Jones, et al. Expires January 21, 2020 [Page 34] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Added a "resource" request parameter used to indicate the URLs of resources at which the client intends to use the requested security token. o Specified that multiple "audience" and "resource" request parameter values may be used. o Defined the JWT claim "act" (actor) to express the current actor or delegation principal. o Defined the JWT claim "may_act" to express that one party is authorized to act on behalf of another party. o Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope- token values. o Added the "N_A" (not applicable) OAuth Access Token Type definition for use in contexts in which the token exchange syntax requires a "token_type" value, but in which the token being issued is not an access token. o Added examples. -02 o Enabled use of Security Token types other than JWTs for "act_as" and "on_behalf_of" request values. o Referenced the JWT and OAuth Assertions RFCs. -01 o Updated references. -00 o Created initial working group draft from draft-jones-oauth-token- exchange-01. Authors' Addresses Michael B. Jones Microsoft Email: mbj@microsoft.com URI: http://self-issued.info/ Anthony Nadalin Microsoft Email: tonynad@microsoft.com Jones, et al. Expires January 21, 2020 [Page 35] Internet-Draft OAuth 2.0 Token Exchange July 2019 Brian Campbell (editor) Ping Identity Email: brian.d.campbell@gmail.com John Bradley Yubico Email: ve7jtb@ve7jtb.com Chuck Mortimore Salesforce Email: cmortimore@salesforce.com Jones, et al. Expires January 21, 2020 [Page 36] ./draft-ietf-rtcweb-fec-10.txt0000644000764400076440000006506513513404121015400 0ustar iustyiusty Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track Jul 16, 2019 Expires: January 17, 2020 WebRTC Forward Error Correction Requirements draft-ietf-rtcweb-fec-10 Abstract This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC 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 https://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 17, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Uberti Expires January 17, 2020 [Page 1] Internet-Draft WebRTC FEC Jul 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Types of FEC . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. Separate FEC Stream . . . . . . . . . . . . . . . . . . . 3 3.2. Redundant Encoding . . . . . . . . . . . . . . . . . . . 3 3.3. Codec-Specific In-band FEC . . . . . . . . . . . . . . . 3 4. FEC for Audio Content . . . . . . . . . . . . . . . . . . . . 4 4.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 4 4.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 5 5. FEC for Video Content . . . . . . . . . . . . . . . . . . . . 5 5.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 5 5.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 6 6. FEC for Application Content . . . . . . . . . . . . . . . . . 6 7. Implementation Requirements . . . . . . . . . . . . . . . . . 7 8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction In situations where packet loss is high, or perfect media quality is essential, Forward Error Correction (FEC) can be used to proactively recover from packet losses. This specification provides guidance on which FEC mechanisms to use, and how to use them, for WebRTC implementations. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Types of FEC FEC describes the sending of redundant information in an outgoing packet stream so that information can still be recovered even in the face of packet loss. There are multiple ways this can be Uberti Expires January 17, 2020 [Page 2] Internet-Draft WebRTC FEC Jul 2019 accomplished for RTP media streams [RFC3550]; this section enumerates the various mechanisms available and describes their tradeoffs. 3.1. Separate FEC Stream This approach, as described in [RFC5956], Section 4.3, sends FEC packets as an independent RTP stream with its own synchronization source (SSRC, [RFC3550]) and payload type, multiplexed with the primary encoding. While this approach can protect multiple packets of the primary encoding with a single FEC packet, each FEC packet will have its own IP+UDP+RTP+FEC header, and this overhead can be excessive in some cases, e.g., when protecting each primary packet with a FEC packet. This approach allows for recovery of entire RTP packets, including the full RTP header. 3.2. Redundant Encoding This approach, as described in [RFC2198], allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet. This redundant data may be an exact copy of a previous payload, or for codecs that support variable-bitrate encodings, possibly a smaller, lower-quality representation. In certain cases, the redundant data could include encodings of multiple prior audio frames. Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant data. However, this savings is only realized when the data all fits into a single packet (i.e. the size is less than a MTU). As a result, this approach is generally not useful for video content. As described in [RFC2198], Section 4, this approach cannot recover certain parts of the RTP header, including the marker bit, CSRC information, and header extensions. 3.3. Codec-Specific In-band FEC Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867], support their own in-band FEC mechanism, where redundant data is included in the codec payload. This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient. For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery of a lost packet. This scheme is fairly efficient; experiments Uberti Expires January 17, 2020 [Page 3] Internet-Draft WebRTC FEC Jul 2019 performed indicate that when Opus FEC is used, the overhead imposed is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks. See [RFC6716], Section 2.1.7, and this Opus mailing list post [OpusFEC] for more details. For AMR/AMR-WB, packets can contain copies or lower-quality encodings of multiple prior audio frames. See [RFC4867], Section 3.7.1 for details on this mechanism. In-band FEC mechanisms cannot recover any of the RTP header. 4. FEC for Audio Content The following section provides guidance on how to best use FEC for transmitting audio data. As indicated in Section 8 below, FEC should only be activated if network conditions warrant it, or upon explicit application request. 4.1. Recommended Mechanism When using variable-bitrate codecs without an internal FEC, redundant encoding (as described in Section 3.2) with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED. This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding. When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against individual losses, with minimal overhead. Note that, as indicated above, the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the aforementioned redundant encoding with reduced-bitrate Opus encodings SHOULD be used instead. When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism is RECOMMENDED. This provides slightly more efficient protection of the audio stream than redundant encoding. When using constant-bitrate codecs, e.g., PCMU [RFC5391], redundant encoding MAY be used, but this will result in a potentially significant bitrate increase, and suddenly increasing bitrate to deal with losses from congestion may actually make things worse. Uberti Expires January 17, 2020 [Page 4] Internet-Draft WebRTC FEC Jul 2019 Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED. As mentioned above, the recommended mechanisms do not allow recovery of parts of the RTP header that may be important in certain audio applications, e.g., CSRCs and RTP header extensions like those specified in [RFC6464] and [RFC6465]. Implementations SHOULD account for this and attempt to approximate this information, using an approach similar to those described in [RFC2198], Section 4, and [RFC6464], Section 5. 4.2. Negotiating Support Support for redundant encoding of a given RTP stream SHOULD be indicated by including audio/red [RFC2198] as an additional supported media type for the associated m= section in the SDP offer [RFC3264]. Answerers can reject the use of redundant encoding by not including the audio/red media type in the corresponding m= section in the SDP answer. Support for codec-specific FEC mechanisms are typically indicated via "a=fmtp" parameters. For Opus, a receiver MUST indicate that it is prepared to use incoming FEC data with the "useinbandfec=1" parameter, as specified in [RFC7587]. This parameter is declarative and can be negotiated separately for either media direction. For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. Receivers MUST include this parameter, and set it to an appropriate value, as specified in [TS.26114], Table 6.3. 5. FEC for Video Content The following section provides guidance on how to best use FEC for transmitting video data. As indicated in Section 8 below, FEC should only be activated if network conditions warrant it, or upon explicit application request. 5.1. Recommended Mechanism Video frames, due to their size, often require multiple RTP packets. As discussed above, a separate FEC stream can protect multiple packets with a single FEC packet. In addition, the "flexfec" FEC mechanism described in [I-D.ietf-payload-flexible-fec-scheme] is also Uberti Expires January 17, 2020 [Page 5] Internet-Draft WebRTC FEC Jul 2019 capable of protecting multiple RTP streams via a single FEC stream, including all the streams that are part of a BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] group. As a result, for video content, use of a separate FEC stream with the flexfec RTP payload format is RECOMMENDED. To process the incoming FEC stream, the receiver can demultiplex it by SSRC, and then correlate it with the appropriate primary stream(s) via the CSRC(s) present in the RTP header of flexfec repair packets, or the SSRC field present in the FEC header of flexfec retransmission packets. 5.2. Negotiating Support Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1.2, as an additional supported media type for the associated m= section in the SDP offer [RFC3264]. As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group, even if flexfec is negotiated for each primary stream. Answerers can reject the use of SSRC-multiplexed FEC, by not including the offered FEC formats in the corresponding m= section in the SDP answer. Use of FEC-only m-lines, and grouping using the SDP group mechanism as described in [RFC5956], Section 4.1 is not currently defined for WebRTC, and SHOULD NOT be offered. Answerers SHOULD reject any FEC-only m-lines, unless they specifically know how to handle such a thing in a WebRTC context (perhaps defined by a future version of the WebRTC specifications). 6. FEC for Application Content WebRTC also supports the ability to send generic application data, and provides transport-level retransmission mechanisms to support full and partial (e.g. timed) reliability. See [I-D.ietf-rtcweb-data-channel] for details. Because the application can control exactly what data to send, it has the ability to monitor packet statistics and perform its own application-level FEC, if necessary. As a result, this document makes no recommendations regarding FEC for the underlying data transport. Uberti Expires January 17, 2020 [Page 6] Internet-Draft WebRTC FEC Jul 2019 7. Implementation Requirements To support the functionality recommended above, implementations MUST be able to receive and make use of the relevant FEC formats for their supported audio codecs, and MUST indicate this support, as described in Section 4. Use of these formats when sending, as mentioned above, is RECOMMENDED. The general FEC mechanism described in [I-D.ietf-payload-flexible-fec-scheme] SHOULD also be supported, as mentioned in Section 5. Implementations MAY support additional FEC mechanisms if desired, e.g., [RFC5109]. 8. Adaptive Use of FEC Because use of FEC always causes redundant data to be transmitted, and the total amount of data must remain within any bandwidth limits indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used. This is in contrast to methods like RTX [RFC4588] or flexfec's retransmission mode ( [I-D.ietf-payload-flexible-fec-scheme], Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra roundtrip and thereby increased media latency. Given this, WebRTC implementations SHOULD prefer using RTX or flexfec retransmissions instead of FEC when the connection RTT is within the application's latency budget, and otherwise SHOULD only transmit the amount of FEC needed to protect against the observed packet loss (which can be determined, e.g., by monitoring transmit packet loss data from RTCP Receiver Reports [RFC3550]), unless the application indicates it is willing to pay a quality penalty to proactively avoid losses. Note that when probing bandwidth, i.e., speculatively sending extra data to determine if additional link capacity exists, FEC data SHOULD be used as the additional data. Given that extra data is going to be sent regardless, it makes sense to have that data protect the primary payload; in addition, FEC can typically be applied in a way that increases bandwidth only modestly, which is necessary when probing. When using FEC with layered codecs, e.g., [RFC6386], where only base layer frames are critical to the decoding of future frames, implementations SHOULD only apply FEC to these base layer frames. Uberti Expires January 17, 2020 [Page 7] Internet-Draft WebRTC FEC Jul 2019 Finally, it should be noted that although applying redundancy is often useful in protecting a stream against packet loss, if the loss is caused by network congestion, the additional bandwidth used by the redundant data may actually make the situation worse, and can lead to significant degradation of the network. 9. Security Considerations In the WebRTC context, FEC is specifically concerned with recovering data from lost packets; any corrupted packets will be discarded by the SRTP [RFC3711] decryption process. Therefore, as described in [RFC3711], Section 10, the default processing when using FEC with SRTP is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver. This ordering is used for all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], which are enumerated in [RFC5764], Section 4.1.2. Additional security considerations for each individual FEC mechanism are enumerated in their respective documents. 10. IANA Considerations This document requires no actions from IANA. 11. Acknowledgements Several people provided significant input into this document, including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, Magnus Westerlund, and Mo Zanaty. 12. References 12.1. Normative References [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-20 (work in progress), May 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Uberti Expires January 17, 2020 [Page 8] Internet-Draft WebRTC FEC Jul 2019 [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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [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, DOI 10.17487/RFC4867, April 2007, . [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, . [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TS.26114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 15.0.0, September 2017. 12.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-54 (work in progress), December 2018. [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. Uberti Expires January 17, 2020 [Page 9] Internet-Draft WebRTC FEC Jul 2019 [OpusFEC] Terriberry, T., "Opus FEC", January 2013. [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, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5391] Sollaud, A., "RTP Payload Format for ITU-T Recommendation G.711.1", RFC 5391, DOI 10.17487/RFC5391, November 2008, . [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, . [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, . [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, . [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, . Uberti Expires January 17, 2020 [Page 10] Internet-Draft WebRTC FEC Jul 2019 [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, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . Appendix A. Change log Changes in draft -10: o Additional editorial changes from IETF LC. Changes in draft -09: o Editorial changes from IETF LC. o Added new reference for Opus FEC. Changes in draft -08: o Switch to RFC 8174 boilerplate. Changes in draft -07: o Clarify how bandwidth management interacts with FEC. o Make 3GPP reference normative. Changes in draft -06: o Discuss how multiple streams can be protected by a single FlexFEC stream. o Discuss FEC for bandwidth probing. o Add note about recovery of RTP headers and header extensions. o Add note about FEC/SRTP ordering. o Clarify flexfec demux text, and mention retransmits. o Clarify text regarding offers/answers. o Make RFC2198 support SHOULD strength. Uberti Expires January 17, 2020 [Page 11] Internet-Draft WebRTC FEC Jul 2019 o Clean up references. Changes in draft -05: o No changes. Changes in draft -04: o Discussion of layered codecs. o Discussion of RTX. o Clarified implementation requirements. o FlexFEC MUST -> SHOULD. o Clarified AMR max-red handling. o Updated references. Changes in draft -03: o Added overhead stats for Opus. o Expanded discussion of multi-packet FEC for Opus. o Added discussion of AMR/AMR-WB. o Removed discussion of ssrc-group. o Referenced the data channel doc. o Referenced the RTP/RTCP RFC. o Several small edits based on feedback from Magnus. Changes in draft -02: o Expanded discussion of FEC-only m-lines, and how they should be handled in offers and answers. Changes in draft -01: o Tweaked abstract/intro text that was ambiguously normative. o Removed text on FEC for Opus in CELT mode. Uberti Expires January 17, 2020 [Page 12] Internet-Draft WebRTC FEC Jul 2019 o Changed RFC 2198 recommendation for PCMU to be MAY instead of NOT RECOMMENDED, based on list feedback. o Explicitly called out application data as something not addressed in this document. o Updated flexible-fec reference. Changes in draft -00: o Initial version, from sidebar conversation at IETF 90. Author's Address Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Email: justin@uberti.name Uberti Expires January 17, 2020 [Page 13] ./draft-ietf-opsec-urpf-improvements-04.txt0000644000764400076440000013527613532244037020206 0ustar iustyiusty OPSEC Working Group K. Sriram Internet-Draft D. Montgomery BCP: 84 (if approved) USA NIST Updates: 3704 (if approved) J. Haas Intended status: Best Current Practice Juniper Networks, Inc. Expires: March 2, 2020 August 30, 2019 Enhanced Feasible-Path Unicast Reverse Path Forwarding draft-ietf-opsec-urpf-improvements-04 Abstract This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). The strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible- path uRPF (EFP-uRPF) techniques, which are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers, and encourage greater deployment of uRPF techniques. This document updates RFC 3704. 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 https://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 2, 2020. Sriram, et al. Expires March 2, 2020 [Page 1] Internet-Draft Enhanced FP-uRPF August 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Review of Existing Source Address Validation Techniques . . . 4 2.1. SAV using Access Control List . . . . . . . . . . . . . . 4 2.2. SAV using Strict Unicast Reverse Path Forwarding . . . . 5 2.3. SAV using Feasible-Path Unicast Reverse Path Forwarding . 6 2.4. SAV using Loose Unicast Reverse Path Forwarding . . . . . 7 2.5. SAV using VRF Table . . . . . . . . . . . . . . . . . . . 8 3. SAV using Enhanced Feasible-Path uRPF . . . . . . . . . . . . 8 3.1. Description of the Method . . . . . . . . . . . . . . . . 8 3.1.1. Algorithm A: Enhanced Feasible-Path uRPF . . . . . . 10 3.2. Operational Recommendations . . . . . . . . . . . . . . . 10 3.3. A Challenging Scenario . . . . . . . . . . . . . . . . . 11 3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional Flexibility Across Customer Cone . . . . . . . . . . . . 12 3.5. Augmenting RPF Lists with ROA and IRR Data . . . . . . . 12 3.6. Implementation and Operations Considerations . . . . . . 13 3.6.1. Impact on FIB Memory Size Requirement . . . . . . . . 13 3.6.2. Coping with BGP's Transient Behavior . . . . . . . . 14 3.7. Summary of Recommendations . . . . . . . . . . . . . . . 15 3.7.1. Applicability of the enhanced feasible-path uRPF (EFP-uRPF) method with Algorithm A . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Sriram, et al. Expires March 2, 2020 [Page 2] Internet-Draft Enhanced FP-uRPF August 2019 1. Introduction Source Address Validation (SAV) refers to the detection and mitigation of source address (SA) spoofing [RFC2827]. This document identifies a need for and proposes improvement of improvement of the unicast Reverse Path Forwarding (uRPF) techniques [RFC3704] for SAV. The strict uRPF is inflexible about directionality (see [RFC3704] for definitions), the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two [RFC3704]. However, as shown in this document, the existing feasible-path uRPF still has shortcomings. Even with the feasible- path uRPF, ISPs are often apprehensive that they may be dropping customers' data packets with legitimate source addresses. This document describes an enhanced feasible-path uRPF (EFP-uRPF) technique, which aims to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF. It is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces (presented in Section 3). For some challenging ISP-customer scenarios (see Section 3.3), this document also describes a more relaxed version of the enhanced feasible-path uRPF technique (presented in Section 3.4). Implementation and operations considerations are discussed in Section 3.6. Throughout this document, the routes under consideration are assumed to have been vetted based on prefix filtering [RFC7454] and possibly origin validation [RFC6811]. The EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in SAV. They are expected to add greater operational robustness and efficacy to uRPF, while minimizing ISPs' concerns about accidental service disruption for their customers. It is expected that this will encourage more deployment of uRPF to help realize its DDoS prevention benefits network wide. 1.1. Terminology Reverse Path Forwarding (RPF) list: The list of permissible source- address prefixes for incoming data packets on a given interface. Peering relationships considered in this document are provider-to- customer (P2C), customer-to-provider (C2P), and peer-to-peer (p2p). Provider here refers to transit provider. The first two are transit relationships. A peer connected via a p2p link is known as a lateral peer (non-transit). Sriram, et al. Expires March 2, 2020 [Page 3] Internet-Draft Enhanced FP-uRPF August 2019 Customer Cone: AS A's customer cone is A plus all the ASes that can be reached from A following only P2C links [Luckie]. A stub AS is an AS that does not have any customers or lateral peers. In this document, a single-homed stub AS is one that has a single transit provider and a multi-homed stub AS is one that has multiple (two or more) transit providers. 1.2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Review of Existing Source Address Validation Techniques There are various existing techniques for mitigation against DDoS attacks with spoofed addresses [RFC2827] [RFC3704]. Source address validation (SAV) is performed in network edge devices such as border routers, Cable Modem Termination Systems (CMTS) [RFC4036], and Packet Data Network gateways (PDN-GW) in mobile networks [Firmin]. Ingress Access Control List (ACL) and unicast Reverse Path Forwarding (uRPF) are techniques employed for implementing SAV [RFC2827] [RFC3704] [ISOC]. 2.1. SAV using Access Control List Ingress/egress Access Control Lists (ACLs) are maintained to list acceptable (or alternatively, unacceptable) prefixes for the source addresses in the incoming/outgoing Internet Protocol (IP) packets. Any packet with a source address that fails the filtering criteria is dropped. The ACLs for the ingress/egress filters need to be maintained to keep them up to date. Updating the ACLs is an operator-driven manual process, and hence operationally difficult or infeasible. Typically, the egress ACLs in access aggregation devices (e.g., CMTS, PDN-GW) permit source addresses only from the address spaces (prefixes) that are associated with the interface on which the customer network is connected. Ingress ACLs are typically deployed on border routers, and drop ingress packets when the source address is spoofed (e.g., belongs to obviously disallowed prefix blocks, IANA special-purpose prefixes [SPAR-v4][SPAR-v6], provider's own prefixes, etc.). Sriram, et al. Expires March 2, 2020 [Page 4] Internet-Draft Enhanced FP-uRPF August 2019 2.2. SAV using Strict Unicast Reverse Path Forwarding Note: In the figures (scenarios) in this section and the subsequent sections, the following terminology is used: "fails" means drops packets with legitimate source addresses; "works (but not desirable)" means passes all packets with legitimate source addresses but is oblivious to directionality; "works best" means passes all packets with legitimate source addresses with no (or minimal) compromise of directionality. Further, the notation Pi[ASn ASm ...] denotes a BGP update with prefix Pi and an AS_PATH as shown in the square brackets. In the strict unicast Reverse Path Forwarding (uRPF) method, an ingress packet at a border router is accepted only if the Forwarding Information Base (FIB) contains a prefix that encompasses the source address, and forwarding information for that prefix points back to the interface over which the packet was received. In other words, the reverse path for routing to the source address (if it were used as a destination address) should use the same interface over which the packet was received. It is well known that this method has limitations when networks are multi-homed, routes are not symmetrically announced to all transit providers, and there is asymmetric routing of data packets. Asymmetric routing occurs (see Figure 1) when a customer AS announces one prefix (P1) to one transit provider (ISP-a) and a different prefix (P2) to another transit provider (ISP-b), but routes data packets with source addresses in the second prefix (P2) to the first transit provider (ISP-a) or vice versa. Then data packets with source address in prefix P2 that are received directly from AS1 will get dropped. Further, data packets with source address in prefix P1 that originate from AS1 and traverse via AS3 to AS2 will also get dropped at AS2. Sriram, et al. Expires March 2, 2020 [Page 5] Internet-Draft Enhanced FP-uRPF August 2019 +------------+ ---- P1[AS2 AS1] ---> +------------+ | AS2(ISP-a) | <----P2[AS3 AS1] ---- | AS3(ISP-b)| +------------+ +------------+ /\ /\ \ / \ / \ / P1[AS1]\ /P2[AS1] \ / +-----------------------+ | AS1(customer) | +-----------------------+ P1, P2 (prefixes originated) Consider data packets received at AS2 (1) from AS1 with source address (SA) in P2, or (2) from AS3 that originated from AS1 with SA in P1: * Strict uRPF fails * Feasible-path uRPF fails * Loose uRPF works (but not desirable) * Enhanced Feasible-path uRPF works best Figure 1: Scenario 1 for illustration of efficacy of uRPF schemes. 2.3. SAV using Feasible-Path Unicast Reverse Path Forwarding The feasible-path uRPF technique helps partially overcome the problem identified with the strict uRPF in the multi-homing case. The feasible-path uRPF is similar to the strict uRPF, but in addition to inserting the best-path prefix, additional prefixes from alternative announced routes are also included in the RPF list. This method relies on either (a) announcements for the same prefixes (albeit some may be prepended to effect lower preference) propagating to all transit providers performing feasible-path uRPF checks, or (b) announcement of an aggregate less specific prefix to all transit providers while announcing more specific prefixes (covered by the less specific prefix) to different transit providers as needed for traffic engineering. As an example, in the multi-homing scenario (see Scenario 2 in Figure 2), if the customer AS announces routes for both prefixes (P1, P2) to both transit providers (with suitable prepends if needed for traffic engineering), then the feasible-path uRPF method works. It should be mentioned that the feasible-path uRPF works in this scenario only if customer routes are preferred at AS2 and AS3 over a shorter non-customer route. However, the feasible-path uRPF method has limitations as well. One form of limitation naturally occurs when the recommendation (a) or (b) mentioned above regarding propagation of prefixes is not followed. Another form of limitation can be described as follows. In Scenario Sriram, et al. Expires March 2, 2020 [Page 6] Internet-Draft Enhanced FP-uRPF August 2019 2 (described here, illustrated in Figure 2), it is possible that the second transit provider (ISP-b or AS3) does not propagate the prepended route for prefix P1 to the first transit provider (ISP-a or AS2). This is because AS3's decision policy permits giving priority to a shorter route to prefix P1 via a lateral peer (AS2) over a longer route learned directly from the customer (AS1). In such a scenario, AS3 would not send any route announcement for prefix P1 to AS2 (over the p2p link). Then a data packet with source address in prefix P1 that originates from AS1 and traverses via AS3 to AS2 will get dropped at AS2. +------------+ routes for P1, P2 +-----------+ | AS2(ISP-a) |<-------------------->| AS3(ISP-b)| +------------+ (p2p) +-----------+ /\ /\ \ / P1[AS1]\ /P2[AS1] \ / P2[AS1 AS1 AS1]\ /P1[AS1 AS1 AS1] \ / +-----------------------+ | AS1(customer) | +-----------------------+ P1, P2 (prefixes originated) Consider data packets received at AS2 via AS3 that originated from AS1 and have source address in P1: * Feasible-path uRPF works (if customer route to P1 is preferred at AS3 over shorter path) * Feasible-path uRPF fails (if shorter path to P1 is preferred at AS3 over customer route) * Loose uRPF works (but not desirable) * Enhanced Feasible-path uRPF works best Figure 2: Scenario 2 for illustration of efficacy of uRPF schemes. 2.4. SAV using Loose Unicast Reverse Path Forwarding In the loose unicast Reverse Path Forwarding (uRPF) method, an ingress packet at the border router is accepted only if the FIB has one or more prefixes that encompass the source address. That is, a packet is dropped if no route exists in the FIB for the source address. Loose uRPF sacrifices directionality. It only drops packets if the source address is unreachable in the current FIB (e.g., IANA special-purpose prefixes [SPAR-v4][SPAR-v6], unallocated, allocated but currently not routed). Sriram, et al. Expires March 2, 2020 [Page 7] Internet-Draft Enhanced FP-uRPF August 2019 2.5. SAV using VRF Table The Virtual Routing and Forwarding (VRF) technology [RFC4364] [Juniper] allows a router to maintain multiple routing table instances separate from the global Routing Information Base (RIB). External BGP (eBGP) peering sessions send specific routes to be stored in a dedicated VRF table. The uRPF process queries the VRF table (instead of the FIB) for source address validation. A VRF table can be dedicated per eBGP peer and used for uRPF for only that peer, resulting in strict mode operation. For implementing loose uRPF on an interface, the corresponding VRF table would be global, i.e., contains the same routes as in the FIB. 3. SAV using Enhanced Feasible-Path uRPF 3.1. Description of the Method Enhanced feasible-path uRPF (EFP-uRPF) method adds greater operational robustness and efficacy to existing uRPF methods discussed in Section 2. That is because it avoids dropping legitimate data packets and avoids compromising directionality. The method is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces. The EFP-uRPF method can be best explained with an example as follows: Let us say, a border router of ISP-A has in its Adj-RIBs-In [RFC4271] the set of prefixes {Q1, Q2, Q3} each of which has AS-x as its origin and AS-x is in ISP-A's customer cone. In this set, the border router received the route for prefix Q1 over a customer facing interface, while it learned the routes for prefixes Q2 and Q3 from a lateral peer and an upstream transit provider, respectively. In this example scenario, the enhanced feasible-path uRPF method requires Q1, Q2, and Q3 be included in the RPF list for the customer interface under consideration. Thus, the enhanced feasible-path uRPF (EFP-uRPF) method gathers feasible paths for customer interfaces in a more precise way (as compared to feasible-path uRPF) so that all legitimate packets are accepted while the directionality property is not compromised. The above described EFP-uRPF method is recommended to be applied on customer interfaces. It can be extended to create the RPF lists for lateral peer interfaces also. That is, the EFP-uRPF method can be applied (and loose uRPF avoided) on lateral peer interfaces. That Sriram, et al. Expires March 2, 2020 [Page 8] Internet-Draft Enhanced FP-uRPF August 2019 will help avoid compromise of directionality for lateral peer interfaces (which is inevitable with loose uRPF; see Section 2.4). Looking back at Scenarios 1 and 2 (Figure 1 and Figure 2), the enhanced feasible-path uRPF (EFP-uRPF) method works better than the other uRPF methods. Scenario 3 (Figure 3) further illustrates the enhanced feasible-path uRPF method with a more concrete example. In this scenario, the focus is on operation of the feasible-path uRPF at ISP4 (AS4). ISP4 learns a route for prefix P1 via a customer-to- provider (C2P) interface from customer ISP2 (AS2). This route for P1 has origin AS1. ISP4 also learns a route for P2 via another C2P interface from customer ISP3 (AS3). Additionally, AS4 learns a route for P3 via a lateral peer-to-peer (p2p) interface from ISP5 (AS5). Routes for all three prefixes have the same origin AS (i.e., AS1). Using the enhanced feasible-path uRPF scheme, given the commonality of the origin AS across the routes for P1, P2 and P3, AS4 includes all of these prefixes in the RPF list for the customer interfaces (from AS2 and AS3). +----------+ P3[AS5 AS1] +------------+ | AS4(ISP4)|<---------------| AS5(ISP5) | +----------+ (p2p) +------------+ /\ /\ /\ / \ / P1[AS2 AS1]/ \P2[AS3 AS1] / (C2P)/ \(C2P) / / \ / +----------+ +----------+ / | AS2(ISP2)| | AS3(ISP3)| / +----------+ +----------+ / /\ /\ / \ / / P1[AS1]\ /P2[AS1] /P3[AS1] (C2P)\ /(C2P) /(C2P) \ / / +----------------+ / | AS1(customer) |/ +----------------+ P1, P2, P3 (prefixes originated) Consider that data packets (sourced from AS1) may be received at AS4 with source address in P1, P2 or P3 via any of the neighbors (AS2, AS3, AS5): * Feasible-path uRPF fails * Loose uRPF works (but not desirable) * Enhanced Feasible-path uRPF works best Figure 3: Scenario 3 for illustration of efficacy of uRPF schemes. Sriram, et al. Expires March 2, 2020 [Page 9] Internet-Draft Enhanced FP-uRPF August 2019 3.1.1. Algorithm A: Enhanced Feasible-Path uRPF The underlying algorithm in the solution method described above (Section 3.1) can be specified as follows (to be implemented in a transit AS): 1. Create the set of unique origin ASes considering only the routes in the Adj-RIBs-In of customer interfaces. Call it Set A = {AS1, AS2, ..., ASn}. 2. Considering all routes in Adj-RIBs-In for all interfaces (customer, lateral peer, and transit provider), form the set of unique prefixes that have a common origin AS1. Call it Set X1. 3. Include set X1 in Reverse Path Filter (RPF) list on all customer interfaces on which one or more of the prefixes in set X1 were received. 4. Repeat Steps 2 and 3 for each of the remaining ASes in Set A (i.e., for ASi, where i = 2, ..., n). The above algorithm can be extended to apply EFP-uRPF method to lateral peer interfaces also. However, it is left up to the operator to decide whether they should apply EFP-uRPF or loose uRPF method on lateral peer interfaces. The loose uRPF method is recommended to be applied on transit provider interfaces. 3.2. Operational Recommendations The following operational recommendations will make the operation of the enhanced feasible-path uRPF robust: For multi-homed stub AS: o A multi-homed stub AS should announce at least one of the prefixes it originates to each of its transit provider ASes. (It is understood that a single-homed stub AS would announce all prefixes it originates to its sole transit provider AS.) For non-stub AS: o A non-stub AS should also announce at least one of the prefixes it originates to each of its transit provider ASes. o Additionally, from the routes it has learned from customers, a non-stub AS SHOULD announce at least one route per origin AS to each of its transit provider ASes. Sriram, et al. Expires March 2, 2020 [Page 10] Internet-Draft Enhanced FP-uRPF August 2019 3.3. A Challenging Scenario It should be observed that in the absence of ASes adhering to above recommendations, the following example scenario may be constructed which poses a challenge for the enhanced feasible-path uRPF (as well as for traditional feasible-path uRPF). In the scenario illustrated in Figure 4, since routes for neither P1 nor P2 are propagated on the AS2-AS4 interface (due to the presence of NO_EXPORT Community), the enhanced feasible-path uRPF at AS4 will reject data packets received on that interface with source addresses in P1 or P2. (For a little more complex example scenario, see slide #10 in [sriram-urpf].) +----------+ | AS4(ISP4)| +----------+ /\ /\ / \ P1[AS3 AS1] P1 and P2 not / \ P2[AS3 AS1] propagated / \ (C2P) (C2P) / \ +----------+ +----------+ | AS2(ISP2)| | AS3(ISP3)| +----------+ +----------+ /\ /\ \ / P1[AS1] P1[AS1] NO_EXPORT \ / P2[AS1] P2[AS1] NO_EXPORT \ / (C2P) (C2P) \ / +----------------+ | AS1(customer) | +----------------+ P1, P2 (prefixes originated) Consider that data packets (sourced from AS1) may be received at AS4 with source address in P1 or P2 via AS2: * Feasible-path uRPF fails * Loose uRPF works (but not desirable) * Enhanced Feasible-path uRPF with Algorithm A fails * Enhanced Feasible-path uRPF with Algorithm B works best Figure 4: Illustration of a challenging scenario. Sriram, et al. Expires March 2, 2020 [Page 11] Internet-Draft Enhanced FP-uRPF August 2019 3.4. Algorithm B: Enhanced Feasible-Path uRPF with Additional Flexibility Across Customer Cone Adding further flexibility to the enhanced feasible-path uRPF method can help address the potential limitation identified above using the scenario in Figure 4 (Section 3.3). In the following, "route" refers to a route currently existing in the Adj-RIB-in. Including the additional degree of flexibility, the modified algorithm called Algorithm B (implemented in a transit AS) can be described as follows: 1. Create the set of all directly-connected customer interfaces. Call it Set I = {I1, I2, ..., Ik}. 2. Create the set of all unique prefixes for which routes exist in Adj-RIBs-In for the interfaces in Set I. Call it Set P = {P1, P2, ..., Pm}. 3. Create the set of all unique origin ASes seen in the routes that exist in Adj-RIBs-In for the interfaces in Set I. Call it Set A = {AS1, AS2, ..., ASn}. 4. Create the set of all unique prefixes for which routes exist in Adj-RIBs-In of all lateral peer and transit provider interfaces such that each of the routes has its origin AS belonging in Set A. Call it Set Q = {Q1, Q2, ..., Qj}. 5. Then, Set Z = Union(P,Q) is the RPF list that is applied for every customer interface in Set I. When Algorithm B (which is more flexible than Algorithm A) is employed on customer interfaces, the type of limitation identified in Figure 4 (Section 3.3) is overcome and the method works. The directionality property is minimally compromised, but still the proposed EFP-uRPF method with Algorithm B is a much better choice (for the scenario under consideration) than applying the loose uRPF method which is oblivious to directionality. So, applying EFP-uRPF method with Algorithm B is recommended on customer interfaces for the challenging scenarios such as those described in Section 3.3. 3.5. Augmenting RPF Lists with ROA and IRR Data It is worth emphasizing that an indirect part of the proposal in this document is that RPF filters may be augmented from secondary sources. Hence, the construction of RPF lists using a method proposed in this document (Algorithm A or B) can be augmented with data from Route Sriram, et al. Expires March 2, 2020 [Page 12] Internet-Draft Enhanced FP-uRPF August 2019 Origin Authorization (ROA) [RFC6482] as well as Internet Routing Registry (IRR) data. Special care should be exercised when using IRR data because it not always accurate or trusted. In the EFP-uRPF method with Algorithm A (see Section 3.1.1), if a ROA includes prefix Pi and ASj, then augment with Pi the RPF list of each customer interface on which at least one route with origin ASj was received. In the EFP-uRPF method with Algorithm B, if ASj belongs in set A (see Step #3 Section 3.4) and if a ROA includes prefix Pi and ASj, then augment with Pi the RPF list Z in Step 5 of Algorithm B. Similar procedures can be followed with reliable IRR data as well. This will help make the RPF lists more robust about source addresses that may be legitimately used by customers of the ISP. 3.6. Implementation and Operations Considerations 3.6.1. Impact on FIB Memory Size Requirement The existing RPF checks in edge routers take advantage of existing line card implementations to perform the RPF functions. For implementation of the enhanced feasible-path uRPF, the general necessary feature would be to extend the line cards to take arbitrary RPF lists that are not necessarily the same as the existing FIB contents. In the algorithms (Section 3.1.1 and Section 3.4) described here, the RPF lists are constructed by applying a set of rules to all received BGP routes (not just those selected as best path and installed in the FIB). The concept of uRPF querying an RPF list (instead of the FIB) is similar to uRPF querying a VRF table (see (Section 2.5). The techniques described in this document require that there should be additional memory (i.e., ternary content addressable memory (TCAM)) available to store the RPF lists in line cards. For an ISP's AS, the RPF list size for each line card will roughly equal the total number of originated prefixes from ASes in its customer cone (assuming Algorithm B in Section 3.4 is used). (Note: EFP-uRPF with Algorithm A (see Section 3.1.1) requires much less memory than EFP- uRPF with Algorithm B.) The following table shows the measured customer cone sizes in number of prefixes originated (from all ASes in the customer cone) for various types of ISPs [sriram-ripe63]: Sriram, et al. Expires March 2, 2020 [Page 13] Internet-Draft Enhanced FP-uRPF August 2019 +---------------------------------+---------------------------------+ | Type of ISP | Measured Customer Cone Size in | | | # Prefixes (in turn this is an | | | estimate for RPF list size on | | | the line card) | +---------------------------------+---------------------------------+ | Very Large Global ISP #1 | 32393 | | ------------------------------- | ------------------------------- | | Very Large Global ISP #2 | 29528 | | ------------------------------- | ------------------------------- | | Large Global ISP | 20038 | | ------------------------------- | ------------------------------- | | Mid-size Global ISP | 8661 | | ------------------------------- | ------------------------------- | | Regional ISP (in Asia) | 1101 | +---------------------------------+---------------------------------+ Table 1: Customer cone sizes (# prefixes) for various types of ISPs. For some super large global ISPs that are at the core of the Internet, the customer cone size (# prefixes) can be as high as a few hundred thousand [CAIDA]. But uRPF is most effective when deployed at ASes at the edges of the Internet where the customer cone sizes are smaller as shown in Table 1. A very large global ISP's router line card is likely to have a FIB size large enough to accommodate 2 million routes [Cisco1]. Similarly, the line cards in routers corresponding to a large global ISP, a mid-size global ISP, and a regional ISP are likely to have FIB sizes large enough to accommodate about 1 million, 0.5 million, and 100K routes, respectively [Cisco2]. Comparing these FIB size numbers with the corresponding RPF list size numbers in Table 1, it can be surmised that the conservatively estimated RPF list size is only a small fraction of the anticipated FIB memory size under relevant ISP scenarios. What is meant here by relevant ISP scenarios is that only smaller ISPs (and possibly some mid-size and regional ISPs) are expected to implement the proposed EFP-uRPF method since it is most effective closer to the edges of the Internet. 3.6.2. Coping with BGP's Transient Behavior BGP routing announcements can exhibit transient behavior. Routes may be withdrawn temporarily and then re-announced due to transient conditions such as BGP session reset or link failure-recovery. To cope with this, hysteresis should be introduced in the maintenance of the RPF lists. Deleting entries from the RPF lists SHOULD be delayed by a pre-determined amount (the value based on operational Sriram, et al. Expires March 2, 2020 [Page 14] Internet-Draft Enhanced FP-uRPF August 2019 experience) when responding to route withdrawals. This should help suppress the effects due to the transients in BGP. 3.7. Summary of Recommendations Depending on the scenario, an ISP or enterprise AS operator should follow one of the following recommendations concerning uRPF/SAV: 1. For directly connected networks, i.e., subnets directly connected to the AS, the AS under consideration SHOULD perform ACL-based source address validation (SAV). 2. For a directly connected single-homed stub AS (customer), the AS under consideration SHOULD perform SAV based on the strict uRPF method. 3. For all other scenarios: * The enhanced feasible-path uRPF (EFP-uRPF) method with Algorithm B (see Section 3.4) SHOULD be applied on customer interfaces. * Loose uRPF method SHOULD be applied on lateral peer and transit provider interfaces. It is also recommended that prefixes from registered ROAs and IRR route objects that include ASes in an ISP's customer cone SHOULD be used to augment the pertaining RPF lists (see Section 3.5 for details). 3.7.1. Applicability of the enhanced feasible-path uRPF (EFP-uRPF) method with Algorithm A EFP-uRPF method with Algorithm A is not mentioned in the above set of recommendations. It is an alternative to EFP-uRPF with Algorithm B and can be used in limited circumstances. The EFP-uRPF method with Algorithm A is expected to work fine if an ISP deploying it has only multi-homed stub customers. It is trivially equivalent to strict uRPF if an ISP deploys it for a single-homed stub customer. More generally, it is also expected to work fine when there is absence of limitations such as those described in Section 3.3. However, caution is required for use of EFP-uRPF with Algorithm A because even if the limitations are not expected at the time of deployment, the vulnerability to change in conditions exists. It may be difficult for an ISP to know or track the extent of use of NO_EXPORT (see Section 3.3) on routes within its customer cone. If an ISP decides to use EFP-uRPF with Algorithm A, it should make its direct customers aware of the operational recommendations in Section 3.2. This means Sriram, et al. Expires March 2, 2020 [Page 15] Internet-Draft Enhanced FP-uRPF August 2019 that the ISP notifies direct customers that at least one prefix originated by each AS in the direct customer's customer cone must propagate to the ISP. On a lateral peer interface, an ISP may choose to apply the EFP-uRPF method with Algorithm A (with appropriate modification of the algorithm). This is because stricter forms of uRPF (than the loose uRPF) may be considered applicable by some ISPs on interfaces with lateral peers. 4. Security Considerations The security considerations in BCP 38 [RFC2827] and BCP 84 [RFC3704] apply for this document as well. In addition, if considering using EFP-uRPF method with Algorithm A, an ISP or AS operator should be aware of the applicability considerations and potential vulnerabilities discussed in Section 3.7.1. In augmenting RPF lists with ROA (and possibly reliable IRR) information (see Section 3.5), a trade-off is made in favor of reducing false positives (regarding invalid detection in SAV) at the expense of a slight other risk. The other risk being a malicious actor at another AS in the neighborhood within the customer cone might take advantage (of the augmented prefix) to some extent. This risk also exists even with normal announced prefixes (i.e., without ROA augmentation) for any uRPF method other than the strict. However, the risk is mitigated if the transit provider of the other AS in question is performing SAV. Though not within the scope of this document, security hardening of routers and other supporting systems (e.g., Resource PKI (RPKI) and ROA management systems) against compromise is extremely important. The compromise of those systems can affect the operation and performance of the SAV methods described in this document. 5. IANA Considerations This document does not request new capabilities or attributes. It does not create any new IANA registries. 6. Acknowledgements The authors would like to thank Sandy Murphy, Alvaro Retana, Job Snijders, Marco Marzetti, Marco d'Itri, Nick Hilliard, Gert Doering, Fred Baker, Igor Gashinsky, Igor Lubashev, Andrei Robachevsky, Barry Greene, Amir Herzberg, Ruediger Volk, Jared Mauch, Oliver Borchert, Mehmet Adalier, and Joel Jaeggli for comments and suggestions. The Sriram, et al. Expires March 2, 2020 [Page 16] Internet-Draft Enhanced FP-uRPF August 2019 comments and suggestions received from the IESG reviewers are also much appreciated. 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, . [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, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [CAIDA] "Information for AS 174 (COGENT-174)", CAIDA Spoofer Project , . [Cisco1] "Internet Routing Table Growth Causes ROUTING-FIB- 4-RSRC_LOW Message on Trident-Based Line Cards", Cisco Trouble-shooting Tech-notes , January 2014, . Sriram, et al. Expires March 2, 2020 [Page 17] Internet-Draft Enhanced FP-uRPF August 2019 [Cisco2] "Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 5.x (Chapter 15: Managing the Unicast RIB and FIB)", Cisco Configuration Guides , March 2018, . [Firmin] Firmin, F., "The Evolved Packet Core", 3GPP The Mobile Broadband Standard , . [ISOC] Vixie (Ed.), P., "Addressing the challenge of IP spoofing", ISOC report , September 2015, . [Juniper] "Creating Unique VPN Routes Using VRF Tables", Juniper Networks TechLibrary , March 2019, . [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and kc. claffy, "AS Relationships, Customer Cones, and Validation", In Proceedings of the 2013 ACM Internet Measurement Conference (IMC), DOI 10.1145/2504730.2504735, October 2013, . [RFC4036] Sawyer, W., "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management", RFC 4036, DOI 10.17487/RFC4036, April 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, . Sriram, et al. Expires March 2, 2020 [Page 18] Internet-Draft Enhanced FP-uRPF August 2019 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, . [SPAR-v4] "IANA IPv4 Special-Purpose Address Registry", IANA , . [SPAR-v6] "IANA IPv6 Special-Purpose Address Registry", IANA , . [sriram-ripe63] Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on a Router", Presented at RIPE-63; also, at IETF-83 SIDR WG Meeting, March 2012, . [sriram-urpf] Sriram et al., K., "Enhanced Feasible-Path Unicast Reverse Path Filtering", Presented at the OPSEC WG Meeting, IETF-101 London , March 2018, . Authors' Addresses Kotikalapudi Sriram USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg MD 20899 USA Email: ksriram@nist.gov Sriram, et al. Expires March 2, 2020 [Page 19] Internet-Draft Enhanced FP-uRPF August 2019 Doug Montgomery USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg MD 20899 USA Email: dougm@nist.gov Jeffrey Haas Juniper Networks, Inc. 1133 Innovation Way Sunnyvale CA 94089 USA Email: jhaas@juniper.net Sriram, et al. Expires March 2, 2020 [Page 20] ./draft-ietf-rtcweb-ip-handling-12.txt0000644000764400076440000006357013507015245017046 0ustar iustyiusty Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track July 2, 2019 Expires: January 3, 2020 WebRTC IP Address Handling Requirements draft-ietf-rtcweb-ip-handling-12 Abstract This document provides information and requirements for how IP addresses should be handled by WebRTC 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 https://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 3, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Uberti Expires January 3, 2020 [Page 1] Internet-Draft WebRTC IP Handling July 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5 6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 7 6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 7 6.2. Determining Associated Local Addresses . . . . . . . . . 7 7. Application Guidance . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction One of WebRTC's key features is its support of peer-to-peer connections. However, when establishing such a connection, which involves connection attempts from various IP addresses, WebRTC may allow a web application to learn additional information about the user compared to an application that only uses the Hypertext Transfer Protocol (HTTP) [RFC7230]. This may be problematic in certain cases. This document summarizes the concerns, and makes recommendations on how WebRTC implementations should best handle the tradeoff between privacy and media performance. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Problem Statement In order to establish a peer-to-peer connection, WebRTC implementations use Interactive Connectivity Establishment (ICE) [RFC8445], which attempts to discover multiple IP addresses using techniques such as Session Traversal Utilities for NAT (STUN) Uberti Expires January 3, 2020 [Page 2] Internet-Draft WebRTC IP Handling July 2019 [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766], and then checks the connectivity of each local-address-remote-address pair in order to select the best one. The addresses that are collected usually consist of an endpoint's private physical or virtual addresses and its public Internet addresses. These addresses are provided to the web application so that they can be communicated to the remote endpoint for its checks. This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. The information revealed falls into three categories: 1. If the client is multihomed, additional public IP addresses for the client can be learned. In particular, if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple interfaces (a "split-tunnel" VPN), WebRTC can discover not only the public address for the VPN, but also the ISP public address over which the VPN is running. 2. If the client is behind a Network Address Translator (NAT), the client's private IP addresses, often [RFC1918] addresses, can be learned. 3. If the client is behind a proxy (a client-configured "classical application proxy", as defined in [RFC1919], Section 3), but direct access to the Internet is permitted, WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client. This concern also applies to the "enterprise TURN server" scenario described in [RFC7478], Section 2.3.5.1, if, as above, direct Internet access is permitted. However, when the term "proxy" is used in this document, it is always in reference to an [RFC1919] proxy server. Of these three concerns, the first is the most significant, because for some users, the purpose of using a VPN is for anonymity. However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. The second concern is less significant but valid nonetheless. The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 [RFC6146]. While disclosure of the [RFC4941] IPv6 addresses recommended by Uberti Expires January 3, 2020 [Page 3] Internet-Draft WebRTC IP Handling July 2019 [I-D.ietf-rtcweb-transports] is fairly benign due to their intentionally short lifetimes, IPv4 addresses present some challenges. Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits of entropy with an indefinite lifetime. As such, they can be a fairly significant fingerprinting surface. In addition, intranet web sites can be attacked more easily when their IPv4 address range is externally known. Private IP addresses can also act as an identifier that allows web applications running in isolated browsing contexts (e.g., normal and private browsing) to learn that they are running on the same device. This could allow the application sessions to be correlated, defeating some of the privacy protections provided by isolation. It should be noted that private addresses are just one potential mechanism for this correlation and this is an area for further study. The third concern is the least common, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has provided similar functionality since the introduction of Real-Time Media Flow Protocol (RTMFP) support [RFC7016] in 2008. 4. Goals WebRTC's support of secure peer-to-peer connections facilitates deployment of decentralized systems, which can have privacy benefits. As a result, blunt solutions that disable WebRTC or make it significantly harder to use are undesirable. This document takes a more nuanced approach, with the following goals: o Provide a framework for understanding the problem so that controls might be provided to make different tradeoffs regarding performance and privacy concerns with WebRTC. o Using that framework, define settings that enable peer-to-peer communications, each with a different balance between performance and privacy. o Finally, provide recommendations for default settings that provide reasonable performance without also exposing addressing information in a way that might violate user expectations. Uberti Expires January 3, 2020 [Page 4] Internet-Draft WebRTC IP Handling July 2019 5. Detailed Design 5.1. Principles The key principles for our framework are stated below: 1. By default, WebRTC traffic should follow typical IP routing, i.e., WebRTC should use the same interface used for HTTP traffic, and only the system's 'typical' public addresses (or those of an enterprise TURN server, if present) should be visible to the application. However, in the interest of optimal media quality, it should be possible to enable WebRTC to make use of all network interfaces to determine the ideal route. 2. By default, WebRTC should be able to negotiate direct peer-to- peer connections between endpoints (i.e., without traversing a NAT or relay server) when such connections are possible. This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. 3. It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web applications learning such addresses. This document does not require this to be the default state, as there is no currently defined mechanism that can satisfy this requirement as well as the aforementioned requirement to allow direct peer-to-peer connections. 4. By default, WebRTC traffic should not be sent through proxy servers, due to the media quality problems associated with sending WebRTC traffic over TCP, which is almost always used when communicating with such proxies, as well as proxy performance issues that may result from proxying WebRTC's long-lived, high- bandwidth connections. However, it should be possible to force WebRTC to send its traffic through a configured proxy if desired. 5.2. Modes and Recommendations Based on these ideas, we define four specific modes of WebRTC behavior, reflecting different media quality/privacy tradeoffs: Mode 1: Enumerate all addresses: WebRTC MUST use all network interfaces to attempt communication with STUN servers, TURN servers, or peers. This will converge on the best media path, and is ideal when media performance is the highest priority, but it discloses the most information. Uberti Expires January 3, 2020 [Page 5] Internet-Draft WebRTC IP Handling July 2019 Mode 2: Default route + associated local addresses: WebRTC MUST follow the kernel routing table rules, which will typically cause media packets to take the same route as the application's HTTP traffic. If an enterprise TURN server is present, the preferred route MUST be through this TURN server. Once an interface has been chosen, the private IPv4 and IPv6 addresses associated with this interface MUST be discovered and provided to the application as host candidates. This ensures that direct connections can still be established in this mode. Mode 3: Default route only: This is the the same as Mode 2, except that the associated private addresses MUST NOT be provided; the only IP addresses gathered are those discovered via mechanisms like STUN and TURN (on the default route). This may cause traffic to hairpin through a NAT, fall back to an application TURN server, or fail altogether, with resulting quality implications. Mode 4: Force proxy: This is the same as Mode 3, but when the application's HTTP traffic is sent through a proxy, WebRTC media traffic MUST also be proxied. If the proxy does not support UDP (as is the case for all HTTP and most SOCKS [RFC1928] proxies), or the WebRTC implementation does not support UDP proxying, the use of UDP will be disabled, and TCP will be used to send and receive media through the proxy. Use of TCP will result in reduced media quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. Mode 1 MUST NOT be used unless user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia (device permissions) consent, described in [I-D.ietf-rtcweb-security-arch], Section 6.2. Alternatively, implementations can provide a specific mechanism to obtain user consent. In cases where user consent has not been obtained, Mode 2 SHOULD be used. These defaults provide a reasonable tradeoff that permits trusted WebRTC applications to achieve optimal network performance, but gives applications without consent (e.g., 1-way streaming or data channel applications) only the minimum information needed to achieve direct connections, as defined in Mode 2. However, implementations MAY choose stricter modes if desired, e.g., if a user indicates they want all WebRTC traffic to follow the default route. Uberti Expires January 3, 2020 [Page 6] Internet-Draft WebRTC IP Handling July 2019 Future documents may define additional modes and/or update the recommended default modes. Note that the suggested defaults can still be used even for organizations that want all external WebRTC traffic to traverse a proxy or enterprise TURN server, simply by setting an organizational firewall policy that allows WebRTC traffic to only leave through the proxy or TURN server. This provides a way to ensure the proxy or TURN server is used for any external traffic, but still allows direct connections (and, in the proxy case, avoids the performance issues associated with forcing media through said proxy) for intra- organization traffic. 6. Implementation Guidance This section provides guidance to WebRTC implementations on how to implement the policies described above. 6.1. Ensuring Normal Routing When trying to follow typical IP routing, as required by Modes 2 and 3, the simplest approach is to bind() the sockets used for peer-to- peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic. STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. 6.2. Determining Associated Local Addresses When binding to a wildcard address, some extra work is needed to determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing treatment). Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). First, the appropriate remote IPv4/IPv6 address is obtained by resolving the host component of the web application URI [RFC3986]. If the client is behind a proxy and cannot resolve these IPs via DNS, the address of the proxy can be used instead. Or, if the web application was loaded from a file:// URI [RFC8089], rather than over the network, the implementation can fall back to a well-known DNS name or IP address. Once a suitable remote IP has been determined, the implementation can create a UDP socket, bind() it to the appropriate wildcard address, and then connect() to the remote IP. Generally, this results in the Uberti Expires January 3, 2020 [Page 7] Internet-Draft WebRTC IP Handling July 2019 socket being assigned a local address based on the kernel routing table, without sending any packets over the network. Finally, the socket can be queried using getsockname() or the equivalent to determine the appropriate local address. 7. Application Guidance The recommendations mentioned in this document may cause certain WebRTC applications to malfunction. In order to be robust in all scenarios, the following guidelines are provided for applications: o Applications SHOULD deploy a TURN server with support for both UDP and TCP connections to the server. This ensures that connectivity can still be established, even when Mode 3 or 4 are in use, assuming the TURN server can be reached. o Applications SHOULD detect when they don't have access to the full set of ICE candidates by checking for the presence of host candidates. If no host candidates are present, Mode 3 or 4 above is in use; this knowledge can be useful for diagnostic purposes. 8. Security Considerations This document describes several potential privacy and security concerns associated with WebRTC peer-to-peer connections, and provides mechanisms and recommendations for WebRTC implementations to address these concerns. 9. IANA Considerations This document requires no actions from IANA. 10. Acknowledgements Several people provided input into this document, including Bernard Aboba, Harald Alvestrand, Youenn Fablet, Ted Hardie, Matthew Kaufmann, Eric Rescorla, Adam Roach, and Martin Thomson. 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, . Uberti Expires January 3, 2020 [Page 8] Internet-Draft WebRTC IP Handling July 2019 [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, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [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, DOI 10.17487/RFC5766, April 2010, . [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 11.2. Informative References [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-17 (work in progress), October 2016. [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, . [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, DOI 10.17487/RFC1919, March 1996, . Uberti Expires January 3, 2020 [Page 9] Internet-Draft WebRTC IP Handling July 2019 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [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, . [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol", RFC 7016, DOI 10.17487/RFC7016, November 2013, . [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, . [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . Appendix A. Change log Changes in draft -12: o Editorial updates from IETF LC review. Changes in draft -11: o Editorial updates from AD review. Changes in draft -10: o Incorporate feedback from IETF 102 on the problem space. o Note that future versions of the document may define new modes. Changes in draft -09: o Fixed confusing text regarding enterprise TURN servers. Uberti Expires January 3, 2020 [Page 10] Internet-Draft WebRTC IP Handling July 2019 Changes in draft -08: o Discuss how enterprise TURN servers should be handled. Changes in draft -07: o Clarify consent guidance. Changes in draft -06: o Clarify recommendations. o Split implementation guidance into two sections. Changes in draft -05: o Separated framework definition from implementation techniques. o Removed RETURN references. o Use origin when determining local IPs, rather than a well-known IP. Changes in draft -04: o Rewording and cleanup in abstract, intro, and problem statement. o Added 2119 boilerplate. o Fixed weird reference spacing. o Expanded acronyms on first use. o Removed 8.8.8.8 mention. o Removed mention of future browser considerations. Changes in draft -03: o Clarified when to use which modes. o Added 2119 qualifiers to make normative statements. o Defined 'proxy'. o Mentioned split tunnels in problem statement. Changes in draft -02: Uberti Expires January 3, 2020 [Page 11] Internet-Draft WebRTC IP Handling July 2019 o Recommendations -> Requirements o Updated text regarding consent. Changes in draft -01: o Incorporated feedback from Adam Roach; changes to discussion of cam/mic permission, as well as use of proxies, and various editorial changes. o Added several more references. Changes in draft -00: o Published as WG draft. Author's Address Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Email: justin@uberti.name Uberti Expires January 3, 2020 [Page 12] ./draft-ietf-ospf-encapsulation-cap-09.txt0000644000764400076440000005347213167133542017754 0ustar iustyiusty OSPF Working Group X. Xu, Ed. Internet-Draft Huawei Intended status: Standards Track B. Decraene, Ed. Expires: April 12, 2018 Orange R. Raszuk Bloomberg LP L. Contreras Telefonica I+D L. Jalil Verizon October 9, 2017 The Tunnel Encapsulations OSPF Router Information draft-ietf-ospf-encapsulation-cap-09 Abstract Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the tunnel encapsulator router needs to select a type of tunnel which is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisement (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. 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 https://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 12, 2018. Xu, et al. Expires April 12, 2018 [Page 1] Internet-Draft Tunnel Encapsulations RI October 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 (https://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. Tunnel Encapsulations TLV . . . . . . . . . . . . . . . . . . 3 4. Tunnel Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 3 5. Tunnel Parameter Sub-TLVs . . . . . . . . . . . . . . . . . . 4 5.1. Encapsulation Sub-TLV . . . . . . . . . . . . . . . . . . 5 5.2. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . . . 5 5.3. Endpoint Sub-TLV . . . . . . . . . . . . . . . . . . . . 5 5.4. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Load-Balancing Block Sub-TLV . . . . . . . . . . . . . . 6 5.6. IP QoS Field . . . . . . . . . . . . . . . . . . . . . . 6 5.7. UDP Destination Port . . . . . . . . . . . . . . . . . . 7 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.1. OSPF Router Information . . . . . . . . . . . . . . . . . 7 7.2. Tunnel Parameter Sub-TLVs Registry . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Networks use tunnels for a variety of reasons, such as: o Partial deployment of IPv6 in IPv4 networks or IPv4 in IPv6 networks as described in [RFC5565], where IPvx tunnels are used between IPvx-enabled routers so as to traverse non-IPvx routers. Xu, et al. Expires April 12, 2018 [Page 2] Internet-Draft Tunnel Encapsulations RI October 2017 o Remote Loop-Free Alternate (RLFA) repair tunnels as described in [RFC7490], where tunnels are used between the Point of Local Repair and the selected PQ node. The tunnel encapsulator router needs to select a type of tunnel which is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisement (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. In this document, OSPF refers to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 2. Terminology This memo makes use of the terms defined in [RFC7770]. 3. Tunnel Encapsulations TLV Routers advertise their supported tunnel encapsulation type(s) by advertising a new TLV of the OSPF Router Information (RI) Opaque LSA [RFC7770], referred to as the Tunnel Encapsulations TLV. This TLV is applicable to both OSPFv2 and OSPFv3. The Type code of the Tunnel Encapsulations is TBD1, the Length value is variable, and the Value field contains one or more Tunnel Sub-TLVs as defined in Section 4. Each Tunnel Sub-TLV indicates a particular encapsulation format that the advertising router supports along with the parameters corresponding to the tunnel type. The Tunnel Encapsulations TLV MAY appear more than once within a given OSPF Router Information (RI) Opaque LSA. If the Tunnel Encapsulations TLV appears more than once in an OSPF Router Information LSA, the set of all Tunnel Sub-TLVs from all Tunnel Encapsulations TLV SHOULD be considered. The scope of the advertisement depends on the application but it is recommended that it SHOULD be domain-wide. 4. Tunnel Sub-TLV The Tunnel Sub-TLV is structured as follows: Xu, et al. Expires April 12, 2018 [Page 3] Internet-Draft Tunnel Encapsulations RI October 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Type (2 Octets) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tunnel Parameter Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Tunnel Sub-TLV Tunnel Type (2 octets): Identifies the type of tunneling technology signaled. Tunnel types are shared with the BGP extension [I-D.ietf-idr-tunnel-encaps] and hence are defined in the IANA registry "BGP Tunnel Encapsulation Attribute Tunnel Types". Unknown Tunnel types are to be ignored upon receipt. Length (2 octets): Unsigned 16-bit integer indicating the total number of octets of the value field. Value (variable): Zero or more Tunnel Parameter Sub-TLVs as defined in Section 5. If a Tunnel Sub-TLV is invalid, it MUST be ignored and skipped. However, other Tunnel Sub-TLVs MUST be considered 5. Tunnel Parameter Sub-TLVs A Tunnel Parameter Sub-TLV is structured as follows: +---------------------------------------------+ | Tunnel Parameter Sub-Type (2 Octets) | +---------------------------------------------+ | Tunnel Parameter Length (2 Octets) | +---------------------------------------------+ | Tunnel Parameter Value (Variable) | | | +---------------------------------------------+ Figure 2: Tunnel Parameter Sub-TLV Tunnel Parameter Sub-Type (2 octets): Each sub-type defines a parameter of the Tunnel Sub-TLV. Sub-Types are registered in the IANA registry "OSPF Tunnel Parameter Sub-TLVs" Section 7.2. Xu, et al. Expires April 12, 2018 [Page 4] Internet-Draft Tunnel Encapsulations RI October 2017 Tunnel Parameter Length (2 octets): Unsigned 16-bit integer indicating the total number of octets of the Tunnel Parameter Value field. Tunnel Parameter Value (variable): Encodings of the value field depend on the Sub-TLV type as enumerated above. The following sub-sections define the encoding in detail. Any unknown Tunnel Parameter Sub-Type MUST be ignored and skipped upon receipt. When a reserved value (See Section 7.2) is seen in an LSA, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel Parameter Value has an incorrect syntax or semantic, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is invalid, its Tunnel Sub-TLV MUST be ignored. However, other Tunnel Sub-TLVs MUST be considered. 5.1. Encapsulation Sub-TLV This Sub-TLV type is 1. The syntax, semantic, and usage of its value field are defined in Section 3.2 "Encapsulation Sub-TLVs for Particular Tunnel Types" of [I-D.ietf-idr-tunnel-encaps]. 5.2. Protocol Type Sub-TLV This Sub-TLV type is 2. The syntax, semantic, and usage of its value field are defined in Section 3.4.1 "Protocol Type sub-TLV" of [I-D.ietf-idr-tunnel-encaps]. 5.3. Endpoint Sub-TLV This Sub-TLV type is 3. It MUST be present once and only once in a given Tunnel Sub-TLV. The value field contain two sub-fields: a two-octet Address Family sub-field an Address sub-field, whose length depends upon the Address Family. 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 Family | Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ (Variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Endpoint Sub-TLV Xu, et al. Expires April 12, 2018 [Page 5] Internet-Draft Tunnel Encapsulations RI October 2017 The Address Family subfield contains a value from IANA's "Address Family Numbers" registry. In this document, we assume that the Address Family is either IPv4 or IPv6; use of other address families is outside the scope of this document. If the Address Family subfield contains the value for IPv4, the address subfield MUST contain an IPv4 address (a /32 IPv4 prefix). In this case, the length field of Remote Endpoint sub-TLV MUST contain the value 6. If the Address Family subfield contains the value for IPv6, the address sub-field MUST contain an IPv6 address (a /128 IPv6 prefix). In this case, the length field of Remote Endpoint sub-TLV MUST contain the value 18 (0x12). IPv6 link local addresses are not valid values of the IP address field. 5.4. Color Sub-TLV This Sub-TLV type is 4. It may appear zero or more time in a given Tunnel Sub-TLV. The value field is a 4-octet opaque unsigned integer. The color value is user-defined and configured locally on the advertising routers. It may be used by service providers to define policies on the tunnel encapsulator routers, for example, to control the selection of the tunnel to use. This color value can be referenced by BGP routes carrying Color Extended Community [I-D.ietf-idr-tunnel-encaps]. If the tunnel is used to reach the BGP Next-Hop of BGP routes, then attaching a Color Extended Community to those routes express the willingness of the BGP speaker to use a tunnel of the same color. 5.5. Load-Balancing Block Sub-TLV This Sub-TLV type is 5. The syntax, semantic, and usage of its value field are defined in [RFC5640]. 5.6. IP QoS Field This Sub-TLV type is 6. The syntax, semantic, and usage of its value field are defined in Section 3.3.1 "IPv4 DS Field" of [I-D.ietf-idr-tunnel-encaps]. Xu, et al. Expires April 12, 2018 [Page 6] Internet-Draft Tunnel Encapsulations RI October 2017 5.7. UDP Destination Port This Sub-TLV type is 7. The syntax, semantic, and usage of its value field are defined in Section 3.3.2 "UDP Destination Port" of [I-D.ietf-idr-tunnel-encaps]. 6. Operation The advertisement of a Tunnel Encapsulations Sub-TLV indicates that the advertising router supports a particular tunnel decapsulation along with the parameters to be used for the tunnel. The decision to use that tunnel is driven by the capability of the tunnel encapsulator router to support the encapsulation type and the policy on the tunnel encapsulator router. The Color Sub-TLV (See Section 5.4) may be used as an input to this policy. Note that some tunnel types may require the execution of an explicit tunnel setup protocol before they can be used to transit data. A tunnel MUST NOT be used if there is no route toward the IP address specified in the Endpoint Sub-TLV (See Section 5.3) or if the route is not advertised in the same OSPF domain. 7. IANA Considerations 7.1. OSPF Router Information This document requests IANA to allocate a new code point from the OSPF Router Information (RI) registry. Value TLV Name Reference ----- ---------------------- ------------- TBD1 Tunnel Encapsulations This document Figure 4: Tunnel Encapsulation Router Information 7.2. Tunnel Parameter Sub-TLVs Registry This document requests IANA to create, under "Open Shortest Path First (OSPF) Parameters", a new registry "OSPF Tunnel Parameter Sub- TLVs" with the following registration procedure: The values in the range 1-34999 are to be allocated using the "Standards Action" registration procedure as defined in [RFC8126]. The values in the range 35000-65499 are to be allocated using the "First Come, First Served" registration procedure. Xu, et al. Expires April 12, 2018 [Page 7] Internet-Draft Tunnel Encapsulations RI October 2017 Registry Name: OSPF Tunnel Parameter Sub-TLVs Value Name Reference ----------- -------------------- ------------------------------ 0 Reserved This document 1 Encapsulation This document & [I-D.ietf-idr-tunnel-encaps] 2 Protocol Type This document & [I-D.ietf-idr-tunnel-encaps] 3 Endpoint This document 4 Color This document 5 Load-Balancing Block This document & [RFC5640] 6 IP QoS This document & [I-D.ietf-idr-tunnel-encaps] 7 UDP Destination Port This document & [I-D.ietf-idr-tunnel-encaps] 8-65499 Unassigned 65500-65534 Experimental This document 65535 Reserved This document Figure 5: OSPF Tunnel Parameter Sub-TLVs Registry 8. Security Considerations Security considerations applicable to softwires can be found in the mesh framework [RFC5565]. In general, security issues of the tunnel protocols signaled through this OSPF capability extension are inherited. If a third-party is able to modify any of the information that is used to form encapsulation headers, to choose a tunnel type, or to choose a particular tunnel for a particular payload type, user data packets may end up getting misrouted, mis-delivered, and/or dropped. However, since an OSPF routing domain is usually a well-controlled network under a single administrative domain, the possibility of the above attack is very low. We note that the last paragraph of Section 6 forbid the establishment of a tunnel toward arbitrary destinations. It prohibits a destination outside of the OSPF domain. This avoid that a third- party gaining access to an OSPF router be able to send the traffic to other destinations, e.g., for inspection purposes. Security considerations for the base OSPF protocol are covered in [RFC2328] and [RFC5340]. Xu, et al. Expires April 12, 2018 [Page 8] Internet-Draft Tunnel Encapsulations RI October 2017 9. Contributors Uma Chunduri Huawei Email: uma.chunduri@gmail.com 10. Acknowledgements This document is partially inspired by [RFC5512]. The authors would like to thank Greg Mirsky, John E Drake, Carlos Pignataro and Karsten Thomann for their valuable comments on this document. Special thanks should be given to Acee Lindem for his multiple detailed reviews of this document and help. The authors would like to thank Pete Resnick, Joe Touch, David Mandelberg, Sabrina Tanamal, Tim Wicinski, Amanda Baber for their Last Call reviews and thank Spencer Dawkins, Mirja Kuehlewind, Ben Campbell, Benoit Claise, Alvaro Retana, Adam Roach and Suresh Krishnan for their AD reviews. 11. References 11.1. Normative References [I-D.ietf-idr-tunnel-encaps] Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- Balancing for Mesh Softwires", RFC 5640, DOI 10.17487/RFC5640, August 2009, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Xu, et al. Expires April 12, 2018 [Page 9] Internet-Draft Tunnel Encapsulations RI October 2017 11.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, . [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, . [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, . Authors' Addresses Xiaohu Xu (editor) Huawei Email: xuxiaohu@huawei.com Bruno Decraene (editor) Orange Email: bruno.decraene@orange.com Robert Raszuk Bloomberg LP Email: robert@raszuk.net Xu, et al. Expires April 12, 2018 [Page 10] Internet-Draft Tunnel Encapsulations RI October 2017 Luis M. Contreras Telefonica I+D Email: luismiguel.contrerasmurillo@telefonica.com Luay Jalil Verizon Email: luay.jalil@verizon.com Xu, et al. Expires April 12, 2018 [Page 11] ./draft-ietf-pce-segment-routing-16.txt0000644000764400076440000023260413437215366017274 0ustar iustyiusty PCE S. Sivabalan Internet-Draft C. Filsfils Updates: 8408 (if approved) Cisco Systems, Inc. Intended status: Standards Track J. Tantsura Expires: September 5, 2019 Apstra, Inc. W. Henderickx Nokia J. Hardwick Metaswitch Networks March 4, 2019 PCEP Extensions for Segment Routing draft-ietf-pce-segment-routing-16 Abstract Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link- state Interior Gateway Protocols (IGPs). A Segment Routing Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 https://datatracker.ietf.org/drafts/current/. Sivabalan, et al. Expires September 5, 2019 [Page 1] Internet-Draft PCEP Extensions for Segment Routing March 2019 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 5, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. The Path Setup Type Capability TLV . . . . . . . . . 7 4.1.2. The SR PCE Capability sub-TLV . . . . . . . . . . . . 8 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9 4.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 12 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 14 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Exchanging the SR PCE Capability . . . . . . . . . . . . 15 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. SR-ERO Validation . . . . . . . . . . . . . . . . . . 16 5.2.2. Interpreting the SR-ERO . . . . . . . . . . . . . . . 18 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 20 6. Management Considerations . . . . . . . . . . . . . . . . . . 21 6.1. Controlling the Path Setup Type . . . . . . . . . . . . . 21 6.2. Migrating a Network to Use PCEP Segment Routed Paths . . 22 6.3. Verification of Network Operation . . . . . . . . . . . . 23 6.4. Relationship to Existing Management Models . . . . . . . 24 Sivabalan, et al. Expires September 5, 2019 [Page 2] Internet-Draft PCEP Extensions for Segment Routing March 2019 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 24 8.2. New NAI Type Registry . . . . . . . . . . . . . . . . . . 25 8.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 25 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 26 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 8.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 27 8.7. New Path Setup Type . . . . . . . . . . . . . . . . . . . 28 8.8. New Metric Type . . . . . . . . . . . . . . . . . . . . . 28 8.9. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. Compatibility with Early Implementations . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Segment Routing (SR) leverages the source routing paradigm. Using SR, a source node steers a packet through a path without relying on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is specified as an ordered list of instructions called "segments". Each segment is an instruction to route the packet to a specific place in the network, or to perform a function on the packet. A database of segments can be distributed through the network using a routing protocol (such as IS-IS or OSPF) or by any other means. Several types of segment are defined. A node segment uniquely identifies a specific node in the SR domain. Each router in the SR domain associates a node segment with an ECMP-aware shortest path to the node that it identifies. An adjacency segment represents a unidirectional adjacency. An adjacency segment is local to the node which advertises it. Both node segments and adjacency segments can be used for SR. [RFC8402] describes the SR architecture. The corresponding IS-IS and OSPF extensions are specified in [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions], respectively. The SR architecture can be implemented using either an MPLS forwarding plane [I-D.ietf-spring-segment-routing-mpls] or an IPv6 forwarding plane [I-D.ietf-6man-segment-routing-header]. The MPLS forwarding plane can be applied to SR without any change, in which case an SR path corresponds to an MPLS Label Switching Path (LSP). This document is relevant to the MPLS forwarding plane only. In this Sivabalan, et al. Expires September 5, 2019 [Page 3] Internet-Draft PCEP Extensions for Segment Routing March 2019 document, "Node-SID" and "Adjacency-SID" denote Node Segment Identifier and Adjacency Segment Identifier respectively. A Segment Routing path (SR path) can be derived from an IGP Shortest Path Tree (SPT). SR-TE paths may not follow an IGP SPT. Such paths may be chosen by a suitable network planning tool and provisioned on the ingress node of the SR-TE path. [RFC5440] describes the Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. A PCE computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various constraints and optimization criteria. [RFC8231] specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide synchronization of LSP state between a PCC and a PCE or between a pair of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PCE, controlling the setup and path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended for an operational model in which LSPs are configured on the PCC, and control over them is delegated to the PCE. A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in [RFC8281]. This mechanism is useful in Software Defined Networking (SDN) applications, such as on-demand engineering, or bandwidth calendaring [RFC8413]. It is possible to use a stateful PCE for computing one or more SR-TE paths taking into account various constraints and objective functions. Once a path is chosen, the stateful PCE can initiate an SR-TE path on a PCC using PCEP extensions specified in [RFC8281] using the SR specific PCEP extensions specified in this document. Additionally, using procedures described in this document, a PCC can request an SR path from either a stateful or a stateless PCE. This specification relies on the procedures specified in [RFC8408] to exchange the segment routing capability and to specify that the path setup type of an LSP is segment routing. This specification also updates [RFC8408] to clarify the use of sub-TLVs in the PATH-SETUP- TYPE-CAPABILITY TLV. See Section 4.1.1 for details. This specification provides a mechanism for a network controller (acting as a PCE) to instantiate candidate paths for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more information on the SR Policy Architecture, see [I-D.ietf-spring-segment-routing-policy]. Sivabalan, et al. Expires September 5, 2019 [Page 4] Internet-Draft PCEP Extensions for Segment Routing March 2019 2. Terminology The following terminologies are used in this document: ERO: Explicit Route Object IGP: Interior Gateway Protocol IS-IS: Intermediate System to Intermediate System LSR: Label Switching Router MSD: Base MPLS Imposition Maximum SID Depth, as defined in [RFC8491] NAI: Node or Adjacency Identifier OSPF: Open Shortest Path First PCC: Path Computation Client PCE: Path Computation Element PCEP: Path Computation Element Communication Protocol RRO: Record Route Object SID: Segment Identifier SR: Segment Routing SR-DB: Segment Routing Database: the collection of SRGBs, SRLBs and SIDs and the objects they map to, advertised by a link state IGP SRGB: Segment Routing Global Block SRLB: Segment Routing Local Block SR-TE: Segment Routing Traffic Engineering 3. Overview of PCEP Operation in SR Networks In an SR network, the ingress node of an SR path prepends an SR header to all outgoing packets. The SR header consists of a list of SIDs (or MPLS labels in the context of this document). The header has all necessary information so that, in combination with the information distributed by the IGP, the packets can be guided from the ingress node to the egress node of the path; hence, there is no need for any signaling protocol. Sivabalan, et al. Expires September 5, 2019 [Page 5] Internet-Draft PCEP Extensions for Segment Routing March 2019 In PCEP messages, LSP route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. SR- TE paths computed by a PCE can be represented in an ERO in one of the following forms: o An ordered set of IP addresses representing network nodes/links. o An ordered set of SIDs, with or without the corresponding IP addresses. o An ordered set of MPLS labels, with or without corresponding IP address. The PCC converts these into an MPLS label stack and next hop, as described in Section 5.2.2. This document defines a new ERO subobject denoted by "SR-ERO subobject" capable of carrying a SID as well as the identity of the node/adjacency represented by the SID. SR-capable PCEP speakers should be able to generate and/or process such ERO subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP Initiate Request message (PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in [RFC8231]. When a PCEP session between a PCC and a PCE is established, both PCEP speakers exchange their capabilities to indicate their ability to support SR-specific functionality. A PCE can update an LSP that is initially established via RSVP-TE signaling to use an SR-TE path, by sending a PCUpd to the PCC that delegated the LSP to it ([RFC8231]). A PCC can update an undelegated LSP that is initially established via RSVP-TE signaling to use an SR- TE path as follows. First, it requests an SR-TE Path from a PCE by sending a PCReq message. If it receives a suitable path, it establishes the path in the data plane, and then tears down the original RSVP-TE path. If the PCE is stateful, then the PCC sends PCRpt messages indicating that the new path is set up and the old path is torn down, per [RFC8231]. Similarly, a PCE or PCC can update an LSP initially created with an SR-TE path to use RSVP-TE signaling, if necessary. This capability is useful for rolling back a change when a network is migrated from RSVP-TE to SR-TE technology. A PCC MAY include an RRO containing the recorded LSP in PCReq and PCRpt messages as specified in [RFC5440] and [RFC8231], respectively. Sivabalan, et al. Expires September 5, 2019 [Page 6] Internet-Draft PCEP Extensions for Segment Routing March 2019 This document defines a new RRO subobject for SR networks. The methods used by a PCC to record the SR-TE LSP are outside the scope of this document. In summary, this document: o Defines a new ERO subobject, a new RRO subobject and new PCEP error codes. o Specifies how two PCEP speakers can establish a PCEP session that can carry information about SR-TE paths. o Specifies processing rules for the ERO subobject. o Defines a new path setup type to be used in the PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs ([RFC8408]). o Defines a new sub-TLV for the PATH-SETUP-TYPE-CAPABILITY TLV. The extensions specified in this document complement the existing PCEP specifications to support SR-TE paths. As such, the PCEP messages (e.g., Path Computation Request, Path Computation Reply, Path Computation Report, Path Computation Update, Path Computation Initiate, etc.,) are formatted according to [RFC5440], [RFC8231], [RFC8281], and any other applicable PCEP specifications. 4. Object Formats 4.1. The OPEN Object 4.1.1. The Path Setup Type Capability TLV [RFC8408] defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional list of sub-TLVs which are intended to convey parameters that are associated with the path setup types supported by a PCEP speaker. This specification updates [RFC8408], as follows. It creates a new registry which defines the valid type indicators of the sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV (see Section 8.6). A PCEP speaker MUST NOT include a sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV unless it appears in this registry. If a PCEP speaker receives a sub-TLV whose type indicator does not match one of those from the registry, or else is not recognised by the speaker, then the speaker MUST ignore the sub-TLV. Sivabalan, et al. Expires September 5, 2019 [Page 7] Internet-Draft PCEP Extensions for Segment Routing March 2019 4.1.2. The SR PCE Capability sub-TLV This document defines a new Path Setup Type (PST) for SR, as follows: o PST = 1: Path is setup using Segment Routing Traffic Engineering. A PCEP speaker SHOULD indicate its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST included in the PST list. This document also defines the SR-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their SR capability. If a PCEP speaker includes PST=1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SR-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. The format of the SR-PCE-CAPABILITY sub-TLV is shown in the following figure: 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=TBD11 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |N|X| MSD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SR-PCE-CAPABILITY sub-TLV format The code point for the TLV type is TBD11. The TLV length is 4 octets. The 32-bit value is formatted as follows. Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver. Flags: This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver. * N: A PCC sets this flag bit to 1 to indicate that it is capable of resolving a Node or Adjacency Identifier (NAI) to a SID. * X: A PCC sets this flag bit to 1 to indicate that it does not impose any limit on the MSD. Sivabalan, et al. Expires September 5, 2019 [Page 8] Internet-Draft PCEP Extensions for Segment Routing March 2019 Maximum SID Depth (MSD): specifies the maximum number of SIDs (MPLS label stack depth in the context of this document) that a PCC is capable of imposing on a packet. Section 5.1 explains the relationship between this field and the X flag. 4.2. The RP/SRP Object To set up an SR-TE LSP using SR, the RP (Request Parameters) or SRP (Stateful PCE Request Parameters) object MUST include the PATH-SETUP- TYPE TLV, specified in [RFC8408], with the PST set to 1 (path setup using SR-TE). The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 4.3. ERO An SR-TE path consists of one or more SIDs where each SID MAY be associated with the identifier that represents the node or adjacency corresponding to the SID. This identifier is referred to as the 'Node or Adjacency Identifier' (NAI). As described later, a NAI can be represented in various formats (e.g., IPv4 address, IPv6 address, etc). Furthermore, a NAI is used for troubleshooting purposes and, if necessary, to derive SID value as described below. The ERO specified in [RFC5440] is used to carry SR-TE path information. In order to carry SID and/or NAI, this document defines a new ERO subobject referred to as "SR-ERO subobject" whose format is specified in the following section. An ERO carrying an SR-TE path consists of one or more ERO subobjects, and MUST carry only SR-ERO subobjects. Note that an SR-ERO subobject does not need to have both SID and NAI. However, at least one of them MUST be present. When building the MPLS label stack from ERO, a PCC MUST assume that SR-ERO subobjects are organized as a last-in-first-out stack. The first subobject relative to the beginning of ERO contains the information about the topmost label. The last subobject contains information about the bottommost label. 4.3.1. SR-ERO Subobject An SR-ERO subobject is formatted as shown in the following diagram. Sivabalan, et al. Expires September 5, 2019 [Page 9] Internet-Draft PCEP Extensions for Segment Routing March 2019 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT | Flags |F|S|C|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable, optional) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SR-ERO subobject format The fields in the SR-ERO Subobject are as follows: The 'L' Flag: Indicates whether the subobject represents a loose-hop in the LSP [RFC3209]. If this flag is set to zero, a PCC MUST NOT overwrite the SID value present in the SR-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID values in the received SR-ERO based on its local policy. Type: Set to 36. Length: Contains the total length of the subobject in octets. The Length MUST be at least 8, and MUST be a multiple of 4. An SR-ERO subobject MUST contain at least one of a SID or an NAI. The flags described below indicate whether the SID or NAI fields are absent. NAI Type (NT): Indicates the type and format of the NAI contained in the object body, if any is present. If the F bit is set to zero (see below) then the NT field has no meaning and MUST be ignored by the receiver. This document describes the following NT values: NT=0 The NAI is absent. NT=1 The NAI is an IPv4 node ID. NT=2 The NAI is an IPv6 node ID. NT=3 The NAI is an IPv4 adjacency. NT=4 The NAI is an IPv6 adjacency with global IPv6 addresses. NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs. NT=6 The NAI is an IPv6 adjacency with link-local IPv6 addresses. Sivabalan, et al. Expires September 5, 2019 [Page 10] Internet-Draft PCEP Extensions for Segment Routing March 2019 Flags: Used to carry additional information pertaining to the SID. This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver. * M: If this bit is set to 1, the SID value represents an MPLS label stack entry as specified in [RFC3032]. Otherwise, the SID value is an administratively configured value which represents an index into an MPLS label space (either SRGB or SRLB) per [RFC8402]. * C: If the M bit and the C bit are both set to 1, then the TC, S, and TTL fields in the MPLS label stack entry are specified by the PCE. However, a PCC MAY choose to override these values according its local policy and MPLS forwarding rules. If the M bit is set to 1 but the C bit is set to zero, then the TC, S, and TTL fields MUST be ignored by the PCC. The PCC MUST set these fields according to its local policy and MPLS forwarding rules. If the M bit is set to zero then the C bit MUST be set to zero. * S: When this bit is set to 1, the SID value in the subobject body is absent. In this case, the PCC is responsible for choosing the SID value, e.g., by looking up in the SR-DB using the NAI which, in this case, MUST be present in the subobject. If the S bit is set to 1 then the M and C bits MUST be set to zero. * F: When this bit is set to 1, the NAI value in the subobject body is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST be set to zero. The S and F bits MUST NOT both be set to 1. SID: The Segment Identifier. Depending on the M bit, it contains either: * A 4 octet index defining the offset into an MPLS label space per [RFC8402]. * A 4 octet MPLS Label Stack Entry, where the 20 most significant bits encode the label value per [RFC3032]. NAI: The NAI associated with the SID. The NAI's format depends on the value in the NT field, and is described in the following section. At least one of the SID and the NAI MUST be included in the SR-ERO subobject, and both MAY be included. Sivabalan, et al. Expires September 5, 2019 [Page 11] Internet-Draft PCEP Extensions for Segment Routing March 2019 4.3.2. NAI Associated with SID This document defines the following NAIs: 'IPv4 Node ID' is specified as an IPv4 address. In this case, the NT value is 1 and the NAI field length is 4 octets. 'IPv6 Node ID' is specified as an IPv6 address. In this case, the NT value is 2 and the NAI field length is 16 octets. 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this case, the NT value is 3 and the NAI field length is 8 octets. The format of the NAI is shown in the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: NAI for IPv4 adjacency 'IPv6 Global Adjacency' is specified as a pair of global IPv6 addresses. It is used to describe an IPv6 adjacency for a link that uses global IPv6 addresses. Each global IPv6 address is configured on a specific router interface, so together they identify an adjacency between a pair of routers. In this case, the NT value is 4 and the NAI field length is 32 octets. The format of the NAI is shown in the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local IPv6 address (16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote IPv6 address (16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: NAI for IPv6 global adjacency 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of (node ID, interface ID) tuples. In this case, the NT value is 5 and the NAI field length is 16 octets. The format of the NAI is shown in the following figure: Sivabalan, et al. Expires September 5, 2019 [Page 12] Internet-Draft PCEP Extensions for Segment Routing March 2019 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Node-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Node-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 'IPv6 Link-Local Adjacency' is specified as a pair of (global IPv6 address, interface ID) tuples. It is used to describe an IPv6 adjacency for a link that uses only link local IPv6 addresses. Each global IPv6 address is configured on a specific router, so together they identify a pair of adjacent routers. The interface IDs identify the link that the adjacency is formed over. In this case, the NT value is 6 and the NAI field length is 40 octets. The format of the NAI is shown in the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local IPv6 address (16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote IPv6 address (16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: NAI for IPv6 link-local adjacency 4.4. RRO A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per [RFC8231]. The RRO on this message represents the SID list that was applied by the PCC, that is, the actual path taken by the LSP. The procedures of [RFC8231] with respect to the RRO apply equally to this specification without change. An RRO contains one or more subobjects called "SR-RRO subobjects" whose format is shown below: Sivabalan, et al. Expires September 5, 2019 [Page 13] Internet-Draft PCEP Extensions for Segment Routing March 2019 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=36 | Length | NT | Flags |F|S|C|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: SR-RRO Subobject format The format of the SR-RRO subobject is the same as that of the SR-ERO subobject, but without the L flag. A PCC MUST order the SR-RRO subobjects such that the first subobject relative to the beginning of the RRO identifies the first segment visited by the SR-TE LSP, and the last subobject identifies the final segment of the SR-TE LSP, that is, its endpoint. 4.5. METRIC Object A PCC MAY request that PCE optimizes an individual path computation request to minimize the SID depth of the computed path by using the METRIC object defined in [RFC5440]. This document defines a new type for the METRIC object to be used for this purpose, as follows: o T = 11: Maximum SID Depth of the requested path. If the PCC includes a METRIC object of this type on a path computation request, then the PCE minimizes the SID depth of the computed path. If the B (bound) bit is set to to 1 in the METRIC object, then the PCE MUST NOT return a path whose SID depth exceeds the given metric-value. If the PCC did not set the X flag in its SR- PCE-CAPABILITY TLV, then it MUST set the B bit to 1. If the PCC set the X flag in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to 1 or zero. If a PCEP session is established with a non-zero default MSD value, then the PCC MUST NOT send an MSD METRIC object with an MSD greater than the session's default MSD. If the PCE receives a path computation request with an MSD METRIC object on such a session that is greater than the session's default MSD, then it MUST consider the request invalid and send a PCErr with Error-Type = 10 ("Reception of an invalid object") and Error-Value 9 ("MSD exceeds the default for the PCEP session"). Sivabalan, et al. Expires September 5, 2019 [Page 14] Internet-Draft PCEP Extensions for Segment Routing March 2019 5. Procedures 5.1. Exchanging the SR PCE Capability A PCC indicates that it is capable of supporting the head-end functions for SR-TE LSP by including the SR-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCE. A PCE indicates that it is capable of computing SR-TE paths by including the SR-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCC. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=1, and supports that path setup type, then it checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that sub-TLV is absent, then the PCEP speaker MUST send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value TBD1 (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then close the PCEP session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=1, then the PCEP speaker MUST ignore the SR-PCE-CAPABILITY sub- TLV. If a PCC sets the N flag to 1, then the PCE MAY send an SR-ERO subobject containing NAI and no SID (see Section 5.2). Otherwise, the PCE MUST NOT send an SR-ERO subobject containing NAI and no SID. The number of SIDs that can be imposed on a packet depends on the PCC's data plane's capability. If a PCC sets the X flag to 1 then the MSD is not used and MUST be set to zero. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the X flag set to 1 then it MUST ignore the MSD field and assumes that the sender can impose a SID stack of any depth. If a PCC sets the X flag to zero, then it sets the MSD field to the maximum number of SIDs that it can impose on a packet. In this case, the PCC MUST set the MSD to a number greater than zero. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the X flag and MSD both set to zero then it MUST send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value TBD10 (Maximum SID depth must be nonzero) and MUST then close the PCEP session. Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV indicates the SID/label imposition limit for the PCC node. It is anticipated that, in many deployments, the PCCs will have network interfaces that are homogeneous with respect to MSD (that is, each interface has the same MSD). In such cases, having a per-node MSD on the PCEP session is sufficient; the PCE SHOULD interpret this to mean that all network interfaces on the PCC have the given MSD. However, the PCE MAY also learn a per-node MSD and a per-interface MSD from the routing protocols, as specified in: [RFC8491]; [RFC8476]; Sivabalan, et al. Expires September 5, 2019 [Page 15] Internet-Draft PCEP Extensions for Segment Routing March 2019 [I-D.ietf-idr-bgp-ls-segment-routing-msd]. If the PCE learns the per-node MSD of a PCC from a routing protocol, then it MUST ignore the per-node MSD value in the SR-PCE-CAPABILITY sub-TLV and use the per-node MSD learned from the routing protocol instead. If the PCE learns the MSD of a network interface on a PCC from a routing protocol, then it MUST use the per-interface MSD instead of the MSD value in the SR-PCE-CAPABILITY sub-TLV when it computes a path that uses that interface. Once an SR-capable PCEP session is established with a non-zero MSD value, the corresponding PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that MSD value. If a PCC needs to modify the MSD value, it MUST close the PCEP session and re-establish it with the new MSD value. If a PCEP session is established with a non-zero MSD value, and the PCC receives an SR-TE path containing more SIDs than specified in the MSD value, the PCC MUST send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value 3 (Unsupported number of Segment ERO subobjects). If a PCEP session is established with an MSD value of zero, then the PCC MAY specify an MSD for each path computation request that it sends to the PCE, by including a "maximum SID depth" metric object on the request, as defined in Section 4.5. The N flag, X flag and MSD value inside the SR-PCE-CAPABILITY sub-TLV are meaningful only in the Open message sent from a PCC to a PCE. As such, a PCE MUST set the N flag to zero, the X flag to 1 and MSD value to zero in an outbound message to a PCC. Similarly, a PCC MUST ignore any MSD value received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received. 5.2. ERO Processing 5.2.1. SR-ERO Validation If a PCC does not support the SR PCE Capability and thus cannot recognize the SR-ERO or SR-RRO subobjects, it will respond according to the rules for a malformed object per [RFC5440]. On receiving an SR-ERO, a PCC MUST validate that the Length field, the S bit, the F bit and the NT field are consistent, as follows. o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the Length MUST be 8. o If NT=1, the F bit MUST be zero. If the S bit is 1, the Length MUST be 8, otherwise the Length MUST be 12. Sivabalan, et al. Expires September 5, 2019 [Page 16] Internet-Draft PCEP Extensions for Segment Routing March 2019 o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 20, otherwise the Length MUST be 24. o If NT=3, the F bit MUST be zero. If the S bit is 1, the Length MUST be 12, otherwise the Length MUST be 16. o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 36, otherwise the Length MUST be 40. o If NT=5, the F bit MUST be zero. If the S bit is 1, the Length MUST be 20, otherwise the Length MUST be 24. o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 44, otherwise the Length MUST be 48. If a PCC finds that the NT field, Length field, S bit and F bit are not consistent, it MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 ("Malformed object"). If a PCC does not recognise or support the value in the NT field, it MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error- Value = TBD2 ("Unsupported NAI Type in Segment ERO subobject"). If a PCC receives an SR-ERO subobject in which the S and F bits are both set to 1 (that is, both the SID and NAI are absent), it MUST consider the entire ERO invalid and send a PCErr message with Error- Type = 10 ("Reception of an invalid object") and Error-Value = 6 ("Both SID and NAI are absent in SR-ERO subobject"). If a PCC receives an SR-ERO subobject in which the S bit is set to 1 and the F bit is set to zero (that is, the SID is absent and the NAI is present), but the PCC does not support NAI resolution, it MUST consider the entire ERO invalid and send a PCErr message with Error- Type = 4 ("Not supported object") and Error-Value = 4 ("Unsupported parameter"). If a PCC receives an SR-ERO subobject in which the S bit is set to 1 and either or both of the M or C bits is set to 1, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 ("Malformed object"). If a PCC receives an SR-ERO subobject in which the S bit is set to zero and the M bit is set to 1, then the subobject contains an MPLS label. The PCC MAY choose not to accept a label provided by the PCE, based on it local policy. The PCC MUST NOT accept MPLS label value 3 Sivabalan, et al. Expires September 5, 2019 [Page 17] Internet-Draft PCEP Extensions for Segment Routing March 2019 (Implicit NULL), but it MAY accept other special purpose MPLS label values. If the PCC decides not to accept an MPLS label value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error Value = 2 ("Bad label value"). If both M and C bits of an SR-ERO subobject are set to 1, and if a PCC finds erroneous setting in one or more of TC, S, and TTL fields, it MAY overwrite those fields with values chosen according to its own policy. If the PCC does not overwrite them, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 4 ("Bad label format"). If the M bit of an SR-ERO subobject is set to zero but the C bit is set to 1, then the PCC MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 ("Malformed object"). If a PCC receives an SR-ERO subobject in which the S bit is set to zero and the M bit is set to zero, then the subobject contains a SID index value. If the SID is an Adjacency-SID then the L flag MUST NOT be set. If the L flag is set for an Adjacency-SID then the PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 ("Malformed object"). If a PCC detects that the subobjects of an ERO are a mixture of SR- ERO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 5 ("ERO mixes SR-ERO subobjects with other subobject types"). The SR-ERO subobjects can be classified according to whether they contain a SID representing an MPLS label value, a SID representing an index value, or no SID. If a PCC detects that the SR-ERO subobjects are a mixture of more than one of these types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO / SR-RRO subobjects"). If an ERO specifies a new SR-TE path for an existing LSP and the PCC determines that the ERO contains SR-ERO subobjects that are not valid, then the PCC MUST NOT update the LSP. 5.2.2. Interpreting the SR-ERO The SR-ERO contains a sequence of subobjects. Each SR-ERO subobject in the sequence identifies a segment that the traffic will be directed to, in the order given. That is, the first subobject Sivabalan, et al. Expires September 5, 2019 [Page 18] Internet-Draft PCEP Extensions for Segment Routing March 2019 identifies the first segment the traffic will be directed to, the second subobject represents the second segment, and so on. The PCC interprets the SR-ERO by converting it to an MPLS label stack plus a next hop. The PCC sends packets along the segment routed path by prepending the MPLS label stack onto the packets and sending the resulting, modified packet to the next hop. The PCC uses a different procedure to do this conversion, depending on the information that the PCE has provided in the subobjects. o If the subobjects contain SID index values, then the PCC converts them into the corresponding MPLS labels by following the procedure defined in [I-D.ietf-spring-segment-routing-mpls]. o If the subobjects contain NAI only, the PCC first converts each NAI into a SID index value and then proceeds as above. To convert an NAI to a SID index, the PCC looks for a fully-specified prefix or adjacency matching the fields in the NAI. If the PCC finds a matching prefix/adjacency, and the matching prefix/adjacency has a SID associated with it, then the PCC uses that SID. If the PCC cannot find a matching prefix/adjacency, or if the matching prefix/adjacency has no SID associated with it, the PCC behaves as specified in Section 5.2.2.1. o If the subobjects contain MPLS labels, then the PCC looks up the offset of the first subobject's label in its SRGB or SRLB. This gives the first SID. The PCC pushes the labels in any remaining subobjects onto the packet (with the final subobject specifying the bottom-of-stack label). For all cases above, after the PCC has imposed the label stack on the packet, it sends the packet to the segment identified by the first SID. 5.2.2.1. Handling Errors During SR-ERO Conversion There are several errors that can occur during the process of converting an SR-ERO sequence to an MPLS label stack and a next hop. The PCC deals with them as follows. o If the PCC cannot find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD3 ("Unknown SID"). o If the PCC cannot find an NAI in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD4 ("NAI cannot be resolved to a SID"). Sivabalan, et al. Expires September 5, 2019 [Page 19] Internet-Draft PCEP Extensions for Segment Routing March 2019 o If the PCC needs to convert a SID into an MPLS label value but cannot find the corresponding router's SRGB in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD5 ("Could not find SRGB"). o If the PCC finds that a router's SRGB is not large enough for a SID index value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD6 ("SID index exceeds SRGB size"). o If the PCC needs to convert a SID into an MPLS label value but cannot find the corresponding router's SRLB in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD7 ("Could not find SRLB"). o If the PCC finds that a router's SRLB is not large enough for a SID index value, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD8 ("SID index exceeds SRLB size"). o If the number of labels in the computed label stack exceeds the maximum number of SIDs that the PCC can impose on the packet, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 3 ("Unsupported number of Segment ERO subobjects"). If an ERO specifies a new SR-TE path for an existing LSP and the PCC encounters an error while processing the ERO, then the PCC MUST NOT update the LSP. 5.3. RRO Processing The syntax checking rules that apply to the SR-RRO subobject are identical to those of the SR-ERO subobject, except as noted below. If a PCEP speaker receives an SR-RRO subobject in which both SID and NAI are absent, it MUST consider the entire RRO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 7 ("Both SID and NAI are absent in SR-RRO subobject"). If a PCE detects that the subobjects of an RRO are a mixture of SR- RRO subobjects and subobjects of other types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 10 ("RRO mixes SR-RRO subobjects with other subobject types"). Sivabalan, et al. Expires September 5, 2019 [Page 20] Internet-Draft PCEP Extensions for Segment Routing March 2019 The SR-RRO subobjects can be classified according to whether they contain a SID representing an MPLS label value or a SID representing an index value, or no SID. If a PCE detects that the SR-RRO subobjects are a mixture of more than one of these types, then it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO / SR-RRO subobjects"). 6. Management Considerations This document adds a new path setup type to PCEP to allow LSPs to be set up using segment routing techniques. This path setup type may be used with PCEP alongside other path setup types, such as RSVP-TE, or it may be used exclusively. 6.1. Controlling the Path Setup Type The following factors control which path setup type is used for a given LSP. o The available path setup types are constrained to those that are supported by, or enabled on, the PCEP speakers. The PATH-SETUP- TYPE-CAPABILITY TLV indicates which path setup types a PCEP speaker supports. To use segment routing as a path setup type, it is a prerequisite that the PCC and PCE both include PST=1 in the list of supported path setup types in this TLV, and also include the SR-PCE-CAPABILITY sub-TLV. o When a PCE initiates an LSP, it proposes which path setup type to use by including it in the PATH-SETUP-TYPE TLV in the SRP object of the PCInitiate message. The PCE chooses the path setup type based on the capabilities of the network nodes on the path and on its local policy. The PCC MAY choose to accept the proposed path setup type, or to reject the PCInitiate request, based on its local policy. o When a PCC requests a path for an LSP, it can nominate a preferred path setup type by including it in the PATH-SETUP-TYPE TLV in the RP object of the PCReq message. The PCE MAY choose to reply with a path of the requested type, or to reply with a path of a different type, or to reject the request, based on the capabilities of the network nodes on the path and on its local policy. The operator can influence the path setup type as follows. o Implementations MUST allow the operator to enable and disable the segment routing path setup type on a PCEP-speaking device. Sivabalan, et al. Expires September 5, 2019 [Page 21] Internet-Draft PCEP Extensions for Segment Routing March 2019 Implementations MAY also allow the operator to enable and disable the RSVP-TE path setup type. o PCE implementations MUST allow the operator to specify that an LSP should be instantiated using segment routing or RSVP-TE as the proposed path setup type. o PCE implementations MAY allow the operator to configure a preference for the PCE to propose paths using segment routing or RSVP-TE in the absence of a specified path setup type. o PCC implementations MUST allow the operator to specify that a path requested for an LSP nominates segment routing or RSVP-TE as the path setup type. o PCC implementations MAY allow the operator to configure a preference for the PCC to nominate segment routing or RSVP-TE as the path setup type if none is specified for an LSP. o PCC implementations SHOULD allow the operator to configure a PCC to refuse to set up an LSP using an undesired path setup type. 6.2. Migrating a Network to Use PCEP Segment Routed Paths This section discusses the steps that the operator takes when migrating a network to enable PCEP to set up paths using segment routing as the path setup type. o The operator enables the segment routing PST on the PCE servers. o The operator enables the segment routing PST on the PCCs. o The operator resets each PCEP session. The PCEP sessions come back up with segment routing enabled. o If the operator detects a problem, they can roll the network back to its initial state by disabling the segment routing PST on the PCEP speakers and resetting the PCEP sessions. Note that the data plane is unaffected if a PCEP session is reset. Any LSPs that were set up before the session reset will remain in place and will still be present after the session comes back up. An implementation SHOULD allow the operator to manually trigger a PCEP session to be reset. An implementation MAY automatically reset a PCEP session when an operator reconfigures the PCEP speaker's capabilities. However, note Sivabalan, et al. Expires September 5, 2019 [Page 22] Internet-Draft PCEP Extensions for Segment Routing March 2019 that if the capabilities at both ends of the PCEP session are not reconfigured simultaneously, then the session could be reset twice, which could lead to unnecessary network traffic. Therefore, such implementations SHOULD allow the operator to override this behaviour and wait instead for a manual reset. Once segment routing is enabled on a PCEP session, it can be used as the path setup type for future LSPs. User traffic is not automatically migrated from existing LSPs onto segment routed LSPs just by enabling the segment routing PST in PCEP. The migration of user traffic from existing LSPs onto segment routing LSPs is beyond the scope of this document. 6.3. Verification of Network Operation The operator needs the following information to verify that PCEP is operating correctly with respect to the segment routing path setup type. o An implementation SHOULD allow the operator to view whether the PCEP speaker sent the segment routing PST capability to its peer. If the PCEP speaker is a PCC, then the implementation SHOULD also allow the operator to view the values of the L and N flags that were sent, and the value of the MSD field that was sent. o An implementation SHOULD allow the operator to view whether the peer sent the segment routing PST capability. If the peer is a PCC, then the implementation SHOULD also allow the operator to view the values of the L and N flags and MSD fields that the peer sent. o An implementation SHOULD allow the operator to view whether the segment routing PST is enabled on the PCEP session. o If one PCEP speaker advertises the segment routing PST capability, but the other does not, then the implementation SHOULD create a log to inform the operator of the capability mismatch. o An implementation SHOULD allow the operator to view the PST that was proposed, or requested, for an LSP, and the PST that was actually used. o If a PCEP speaker decides to use a different PST to the one that was proposed, or requested, for an LSP, then the implementation SHOULD create a log to inform the operator that the expected PST has not been used. The log SHOULD give the reason for this choice (local policy, equipment capability etc.) Sivabalan, et al. Expires September 5, 2019 [Page 23] Internet-Draft PCEP Extensions for Segment Routing March 2019 o If a PCEP speaker rejects a segment routing path, then it SHOULD create a log to inform the operator, giving the reason for the decision (local policy, MSD exceeded etc.) 6.4. Relationship to Existing Management Models The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In future, this YANG module should be extended or augmented to provide the following additional information relating to segment routing: o The advertised PST capabilities and MSD per PCEP session. o The PST configured for, and used by, each LSP. The PCEP MIB [RFC7420] could also be updated to include this information. 7. Security Considerations The security considerations described in [RFC5440], [RFC8231], [RFC8281] and [RFC8408] are applicable to this specification. No additional security measure is required. Note that this specification enables a network controller to instantiate a path in the network without the use of a hop-by-hop signaling protocol (such as RSVP-TE). This creates an additional vulnerability if the security mechanisms of [RFC5440], [RFC8231] and [RFC8281] are not used. If there is no integrity protection on the session, then an attacker could create a path which is not subjected to the further verification checks that would be performed by the signaling protocol. Note that this specification adds the MSD field to the OPEN message (see Section 4.1.2) which discloses how many MPLS labels the sender can push onto packets that it forwards into the network. If the security mechanisms of [RFC8231] and [RFC8281] are not used with strong encryption, then an attacker could use this new field to gain intelligence about the capabilities of the edge devices in the network. 8. IANA Considerations 8.1. PCEP ERO and RRO subobjects This document defines a new subobject type for the PCEP explicit route object (ERO), and a new subobject type for the PCEP record route object (RRO). The code points for subobject types of these objects is maintained in the RSVP parameters registry, under the Sivabalan, et al. Expires September 5, 2019 [Page 24] Internet-Draft PCEP Extensions for Segment Routing March 2019 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to confirm the early allocation of the following code points in the RSVP Parameters registry for each of the new subobject types defined in this document. Object Subobject Subobject Type --------------------- -------------------------- ------------------ EXPLICIT_ROUTE SR-ERO (PCEP-specific) 36 ROUTE_RECORD SR-RRO (PCEP-specific) 36 8.2. New NAI Type Registry IANA is requested to create a new sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP SR-ERO NAI Types". The allocation policy for this new registry should be by IETF Review. The new registry should contain the following values: Value Description Reference 0 NAI is absent. This document 1 NAI is an IPv4 node ID. This document 2 NAI is an IPv6 node ID. This document 3 NAI is an IPv4 adjacency. This document 4 NAI is an IPv6 adjacency with This document global IPv6 addresses. 5 NAI is an unnumbered This document adjacency with IPv4 node IDs. 6 NAI is an IPv6 adjacency with This document link-local IPv6 addresses. 8.3. New SR-ERO Flag Registry IANA is requested to create a new sub-registry, named "SR-ERO Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the SR-ERO subobject. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following values are defined in this document: Sivabalan, et al. Expires September 5, 2019 [Page 25] Internet-Draft PCEP Extensions for Segment Routing March 2019 Bit Description Reference 0-7 Unassigned 8 NAI is absent (F) This document 9 SID is absent (S) This document 10 SID specifies TC, S This document and TTL in addition to an MPLS label (C) 11 SID specifies an MPLS This document label (M) 8.4. PCEP-Error Object IANA is requested to confirm the early allocation of the code-points in the PCEP-ERROR Object Error Types and Values registry for the following new error-values: Error-Type Meaning ---------- ------- 10 Reception of an invalid object. Error-value = 2: Bad label value Error-value = 3: Unsupported number of SR-ERO subobjects Error-value = 4: Bad label format Error-value = 5: ERO mixes SR-ERO subobjects with other subobject types Error-value = 6: Both SID and NAI are absent in SR- ERO subobject Error-value = 7: Both SID and NAI are absent in SR- RRO subobject Error-value = 9: MSD exceeds the default for the PCEP session Error-value = 10: RRO mixes SR-RRO subobjects with other subobject types Error-value = TBD1: Missing PCE-SR- CAPABILITY sub-TLV Sivabalan, et al. Expires September 5, 2019 [Page 26] Internet-Draft PCEP Extensions for Segment Routing March 2019 Error-value = TBD2: Unsupported NAI Type in SR-ERO subobject Error-value = TBD3: Unknown SID Error-value = TBD4: NAI cannot be resolved to a SID Error-value = TBD5: Could not find SRGB Error-value = TBD6: SID index exceeds SRGB size Error-value = TBD7: Could not find SRLB Error-value = TBD8: SID index exceeds SRLB size Error-value = TBD9: Inconsistent SIDs in SR-ERO / SR-RRO subobjects Error-value = TBD10: MSD must be nonzero Note to IANA: this draft originally had an early allocation for Error-value=11 (Malformed object) in the above list. However, we have since moved the definition of that code point to RFC8408. Note to IANA: some Error-values in the above list were defined after the early allocation took place, and so do not currently have a code point assigned. Please assign code points from the indicated registry and replace each instance of "TBD1", "TBD2" etc. in this document with the respective code points. Note to IANA: some of the Error-value descriptive strings above have changed since the early allocation. Please refresh the registry. 8.5. PCEP TLV Type Indicators IANA is requested to confirm the early allocation of the following code point in the PCEP TLV Type Indicators registry. Note that this TLV type indicator is deprecated but retained in the registry to ensure compatibility with early implementations of this specification. See Appendix A for details. Value Meaning Reference ------------------------- ---------------------------- -------------- 26 SR-PCE-CAPABILITY This document (deprecated) 8.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators IANA is requested to create a new sub-registry, named "PATH-SETUP- TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Sivabalan, et al. Expires September 5, 2019 [Page 27] Internet-Draft PCEP Extensions for Segment Routing March 2019 type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. New values are to be assigned by Standards Action [RFC8126]. The valid range of values in the registry is 0-65535. IANA is requested to initialize the registry with the following values. All other values in the registry should be marked as "Unassigned". Value Meaning Reference ------------------------- ---------------------------- -------------- 0 Reserved This document TBD11 (recommended 26) SR-PCE-CAPABILITY This document Note to IANA: Please replace each instance of "TBD11" in this document with the allocated code point. We have recommended that value 26 be used for consistency with the deprecated value in the PCEP TLV Type Indicators registry. 8.7. New Path Setup Type [RFC8408] created a sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". IANA is requested to allocate a new code point within this registry, as follows: Value Description Reference ------------------------- ---------------------------- -------------- 1 Traffic engineering path is This document setup using Segment Routing. 8.8. New Metric Type IANA is requested to confirm the early allocation of the following code point in the PCEP METRIC object T field registry: Value Description Reference ------------------------- ---------------------------- -------------- 11 Segment-ID (SID) Depth. This document 8.9. SR PCE Capability Flags IANA is requested to create a new sub-registry, named "SR Capability Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the SR-PCE-CAPABILITY TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC Sivabalan, et al. Expires September 5, 2019 [Page 28] Internet-Draft PCEP Extensions for Segment Routing March 2019 The following values are defined in this document: Bit Description Reference 0-5 Unassigned 6 Node or Adjacency This document Identifier (NAI) is supported (N) 7 Unlimited Maximum SID This document Depth (X) Note to IANA: The name of bit 7 has changed from "Unlimited Maximum SID Depth (L)" to "Unlimited Maximum SID Depth (X)". 9. Contributors The following people contributed to this document: - Lakshmi Sharma - Jan Medved - Edward Crabbe - Robert Raszuk - Victor Lopez 10. Acknowledgements We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing- Wher Chen and Tomas Janciga for the valuable comments. 11. References 11.1. Normative References [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-18 (work in progress), December 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . Sivabalan, et al. Expires September 5, 2019 [Page 29] Internet-Draft PCEP Extensions for Segment Routing March 2019 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, . [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, . 11.2. Informative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-16 (work in progress), February 2019. Sivabalan, et al. Expires September 5, 2019 [Page 30] Internet-Draft PCEP Extensions for Segment Routing March 2019 [I-D.ietf-idr-bgp-ls-segment-routing-msd] Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State", draft-ietf-idr-bgp-ls-segment- routing-msd-02 (work in progress), August 2018. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-22 (work in progress), December 2018. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-27 (work in progress), December 2018. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep- yang-09 (work in progress), October 2018. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing- policy-02 (work in progress), October 2018. [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, . [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . [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, . Sivabalan, et al. Expires September 5, 2019 [Page 31] Internet-Draft PCEP Extensions for Segment Routing March 2019 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework for Scheduled Use of Resources", RFC 8413, DOI 10.17487/RFC8413, July 2018, . [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, . Appendix A. Compatibility with Early Implementations An early implementation of this specification will send the SR- CAPABILITY-TLV as a top-level TLV in the OPEN object instead of sending the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object. Implementations that wish to interoperate with such early implementations should also send the SR-CAPABILITY-TLV as a top-level TLV in their OPEN object and should interpret receiving this top- level TLV as though the sender had sent a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and SR-TE PSTs are supported) with the SR-CAPABILITY-TLV as a sub-TLV. If a PCEP speaker receives an OPEN object in which both the SR-CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level TLVs, then it should ignore the top-level SR-CAPABILITY-TLV and process only the PATH-SETUP-TYPE-CAPABILITY TLV. Authors' Addresses Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com Sivabalan, et al. Expires September 5, 2019 [Page 32] Internet-Draft PCEP Extensions for Segment Routing March 2019 Clarence Filsfils Cisco Systems, Inc. Pegasus Parc De kleetlaan 6a, DIEGEM BRABANT 1831 BELGIUM Email: cfilsfil@cisco.com Jeff Tantsura Apstra, Inc. 333 Middlefield Rd #200 Menlo Park, CA 94025 USA Email: jefftant.ietf@gmail.com Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018, CA 95134 BELGIUM Email: wim.henderickx@alcatel-lucent.com Jon Hardwick Metaswitch Networks 100 Church Street Enfield, Middlesex UK Email: jonathan.hardwick@metaswitch.com Sivabalan, et al. Expires September 5, 2019 [Page 33] ./draft-ietf-ospf-ospfv3-segment-routing-extensions-23.txt0000644000764400076440000012255213415337232023076 0ustar iustyiusty Open Shortest Path First IGP P. Psenak, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track S. Previdi, Ed. Expires: July 13, 2019 Individual January 9, 2019 OSPFv3 Extensions for Segment Routing draft-ietf-ospf-ospfv3-segment-routing-extensions-23 Abstract Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. Requirements Language 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 https://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 13, 2019. Psenak & Previdi Expires July 13, 2019 [Page 1] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 4 3.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 4. Segment Routing Capabilities . . . . . . . . . . . . . . . . 5 5. OSPFv3 Extended Prefix Range TLV . . . . . . . . . . . . . . 5 6. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 11 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 11 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 13 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 14 8.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 14 8.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 15 8.3. Segment Routing for External Prefixes . . . . . . . . . . 16 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 16 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 16 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 17 9.2. OSPFv3 Extended-LSA Sub-TLV registry . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Psenak & Previdi Expires July 13, 2019 [Page 2] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 1. Introduction Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Prefix segments represent an ECMP-aware shortest-path to a prefix (or a node), as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most cases, is a one-hop path. SR's control-plane can be applied to both IPv6 and MPLS data-planes, and does not require any additional signalling (other than IGP extensions). The IPv6 data plane is out of the scope of this specification - OSPFv3 extension for SR with IPv6 data plane will be specified in a separate document. When used in MPLS networks, SR paths do not require any LDP or RSVP-TE signalling. However, SR can interoperate in the presence of LSPs established with RSVP or LDP. This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are described in [RFC7855]. 2. Terminology This section lists some of the terminology used in this document: ABR - Area Border Router Adj-SID - Adjacency Segment Identifier AS - Autonomous System ASBR - Autonomous System Boundary Router DR - Designated Router IS-IS - Intermediate System to Intermediate System LDP - Label Distribution Protocol LSP - Label Switched Path MPLS - Multi Protocol Label Switching Psenak & Previdi Expires July 13, 2019 [Page 3] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 OSPF - Open Shortest Path First SPF - Shortest Path First RSVP - Resource Reservation Protocol SID - Segment Identifier SR - Segment Routing SRGB - Segment Routing Global Block SRLB - Segment Routing Local Block SRMS - Segment Routing Mapping Server TLV - Type Length Value 3. Segment Routing Identifiers Segment Routing defines various types of Segment Identifiers (SIDs): Prefix-SID, Adjacency-SID, and LAN Adjacency SID. 3.1. SID/Label Sub-TLV The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined later in this document. It is used to advertise the SID or label associated with a prefix or adjacency. The SID/Label Sub-TLV has 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 7 Length: Either 3 or 4 octets SID/Label: If length is set to 3, then the 20 rightmost bits represent a label. If length is set to 4, then the value represents a 32-bit SID. Psenak & Previdi Expires July 13, 2019 [Page 4] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 The receiving router MUST ignore the SID/Label Sub-TLV if the length is other than 3 or 4. 4. Segment Routing Capabilities Segment Routing requires some additional router capabilities to be advertised to other routers in the area. These SR capabilities are advertised in the OSPFv3 Router Information Opaque LSA (defined in [RFC7770]) and specified in [I-D.ietf-ospf-segment-routing-extensions]. 5. OSPFv3 Extended Prefix Range TLV In some cases it is useful to advertise attributes for a range of prefixes in a single advertisement. The Segment Routing Mapping Server, which is described in [I-D.ietf-spring-segment-routing-ldp-interop], is an example of where SIDs for multiple prefixes can be advertised. To optimize such advertisement in case of multiple prefixes from a contiguous address range, OSPFv3 Extended Prefix Range TLV is defined." The OSPFv3 Extended Prefix Range TLV is a top-level TLV of the following LSAs defined in [RFC8362]: E-Intra-Area-Prefix-LSA E-Inter-Area-Prefix-LSA E-AS-External-LSA E-Type-7-LSA Multiple OSPFv3 Extended Prefix Range TLVs MAY be advertised in each LSA mentioned above. The OSPFv3 Extended Prefix Range TLV has the following format: Psenak & Previdi Expires July 13, 2019 [Page 5] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | AF | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix (variable) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | where: Type: 9 Length: Variable, in octets, dependent on Sub-TLVs. Prefix length: Length of prefix in bits. AF: Address family for the prefix. AF: 0 - IPv4 unicast AF: 1 - IPv6 unicast Range size: Represents the number of prefixes that are covered by the advertisement. The Range Size MUST NOT exceed the number of prefixes that could be satisfied by the prefix length without including: Addresses from the IPv4 multicast address range (224.0.0.0/3), if the AF is IPv4 unicast Addresses other than the IPv6 unicast addresses, if the AF is IPv6 unicast Flags: Reserved. MUST be zero when sent and are ignored when received. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Address Prefix: Psenak & Previdi Expires July 13, 2019 [Page 6] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 For the address family IPv4 unicast, the prefix itself is encoded as a 32-bit value. The default route is represented by a prefix of length 0. For the address family IPv6 unicast, the prefix, encoded as an even multiple of 32-bit words, padded with zeroed bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words. Prefix encoding for other address families is beyond the scope of this specification. Prefix encoding for other address families can be defined in the future standard-track IETF specifications. The range represents the contiguous set of prefixes with the same prefix length as specified by the Prefix Length field. The set starts with the prefix that is specified by the Address Prefix field. The number of prefixes in the range is equal to the Range size. If the OSPFv3 Extended Prefix Range TLVs advertising the exact same range appears in multiple LSAs of the same type, originated by the same OSPFv3 router, the LSA with the numerically smallest Instance ID MUST be used and subsequent instances of the OSPFv3 Extended Prefix Range TLVs MUST be ignored. 6. Prefix SID Sub-TLV The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as defined in [RFC8362] and in Section 5: Intra-Area Prefix TLV Inter-Area Prefix TLV External Prefix TLV OSPFv3 Extended Prefix Range TLV It MAY appear more than once in the parent TLV and has the following format: Psenak & Previdi Expires July 13, 2019 [Page 7] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 4 Length: 7 or 8 octets, dependent on the V-flag Flags: Single octet field. The following flags are defined: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | |NP|M |E |V |L | | | +--+--+--+--+--+--+--+--+ where: NP-Flag: No-PHP flag. If set, then the penultimate hop MUST NOT pop the Prefix-SID before delivering packets to the node that advertised the Prefix-SID. M-Flag: Mapping Server Flag. If set, the SID was advertised by a Segment Routing Mapping Server as described in [I-D.ietf-spring-segment-routing-ldp-interop]. E-Flag: Explicit-Null Flag. If set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with the Explicit-NULL label (0 for IPv4, 2 for IPv6) before forwarding the packet. V-Flag: Value/Index Flag. If set, then the Prefix-SID carries an absolute value. If not set, then the Prefix-SID carries an index. L-Flag: Local/Global Flag. If set, then the value/index carried by the Prefix-SID has local significance. If not set, then the value/index carried by this Sub-TLV has global significance. Other bits: Reserved. These MUST be zero when sent and are ignored when received. Psenak & Previdi Expires July 13, 2019 [Page 8] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Algorithm: Single octet identifying the algorithm the Prefix-SID is associated with as defined in [I-D.ietf-ospf-segment-routing-extensions]. A router receiving a Prefix-SID from a remote node and with an algorithm value that such remote node has not advertised in the SR-Algorithm Sub-TLV [I-D.ietf-ospf-segment-routing-extensions] MUST ignore the Prefix-SID Sub-TLV. SID/Index/Label: According to the V-Flag and L-Flag, it contains: V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field is a 4 octet index defining the offset in the SID/Label space advertised by this router V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field is a 3 octet local label where the 20 rightmost bits are used for encoding the label value. All other combinations of V-flag and L-flag are invalid and any SID advertisement received with an invalid setting for V and L flags MUST be ignored. If an OSPFv3 router advertises multiple Prefix-SIDs for the same prefix, topology, and algorithm, all of them MUST be ignored. When calculating the outgoing label for the prefix, the router MUST take into account, as described below, the E, NP, and M flags advertised by the next-hop router if that router advertised the SID for the prefix. This MUST be done regardless of whether the next-hop router contributes to the best path to the prefix. The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Prefix-SIDs allocated to prefixes that are propagated between areas by an ABR based on intra-area or inter-area reachability, unless the advertised prefix is directly attached to such ABR. The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Prefix-SIDs allocated to redistributed prefixes, unless the redistributed prefix is directly attached to the advertising ASBR. If the NP-Flag is not set, then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane. If the NP-flag is not set, then the received E-flag is ignored. Psenak & Previdi Expires July 13, 2019 [Page 9] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 If the NP-flag is set then: If the E-flag is not set, then any upstream neighbor of the Prefix-SID originator MUST keep the Prefix-SID on top of the stack. This is useful when the originator of the Prefix-SID needs to stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at an ABR (prefix propagation from one area to another) or at an ASBR (prefix propagation from one domain to another). If the E-flag is set, then any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with an Explicit-NULL label. This is useful, e.g., when the originator of the Prefix- SID is the final destination for the related prefix and the originator wishes to receive the packet with the original Traffic Class field [RFC5462]. When the M-Flag is set, the NP-flag and the E-flag MUST be ignored on reception. As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server advertisement. However, PHP behavior SHOULD be done in following cases: The Prefix is intra-area type and the downstream neighbor is the originator of the prefix. The Prefix is inter-area type and the downstream neighbor is an ABR, which is advertising prefix reachability and is setting the LA-bit in the Prefix Options as described in [RFC8362]. The Prefix is external type and the downstream neighbor is an ASBR, which is advertising prefix reachability and is setting the LA-bit in the Prefix Options as described in [RFC8362]. When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a starting SID/Label value. Example 1: If the following router addresses (loopback addresses) need to be mapped into the corresponding Prefix SID indexes: Router-A: 2001:DB8::1/128, Prefix-SID: Index 1 Router-B: 2001:DB8::2/128, Prefix-SID: Index 2 Router-C: 2001:DB8::3/128, Prefix-SID: Index 3 Router-D: 2001:DB8::4/128, Prefix-SID: Index 4 Psenak & Previdi Expires July 13, 2019 [Page 10] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV would be set to 2001:DB8::1, the Prefix Length would be set to 128, the Range Size would be set to 4, and the Index value in the Prefix- SID Sub-TLV would be set to 1. Example 2: If the following prefixes need to be mapped into the corresponding Prefix-SID indexes: 2001:DB8:1::0/120, Prefix-SID: Index 51 2001:DB8:1::100/120, Prefix-SID: Index 52 2001:DB8:1::200/120, Prefix-SID: Index 53 2001:DB8:1::300/120, Prefix-SID: Index 54 2001:DB8:1::400/120, Prefix-SID: Index 55 2001:DB8:1::500/120, Prefix-SID: Index 56 2001:DB8:1::600/120, Prefix-SID: Index 57 then the Prefix field in the OSPFv3 Extended Prefix Range TLV would be set to 2001:DB8:1::0, the Prefix Length would be set to 120, the Range Size would be set to 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 7. Adjacency Segment Identifier (Adj-SID) An Adjacency Segment Identifier (Adj-SID) represents a router adjacency in Segment Routing. 7.1. Adj-SID Sub-TLV The Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link TLV as defined in [RFC8362]. It MAY appear multiple times in the Router- Link TLV. The Adj-SID 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +---------------------------------------------------------------+ where: Type: 5 Length: 7 or 8 octets, dependent on the V flag. Psenak & Previdi Expires July 13, 2019 [Page 11] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 Flags: Single octet field containing the following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|V|L|G|P| | +-+-+-+-+-+-+-+-+ where: B-Flag: Backup Flag. If set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IPFRR or MPLS-FRR) as described in section 3.5 of [RFC8402]. The V-Flag: Value/Index Flag. If set, then the Adj-SID carries an absolute value. If not set, then the Adj-SID carries an index. The L-Flag: Local/Global Flag. If set, then the value/index carried by the Adj-SID has local significance. If not set, then the value/index carried by this Sub-TLV has global significance. The G-Flag: Group Flag. When set, the G-Flag indicates that the Adj-SID refers to a group of adjacencies (and therefore MAY be assigned to other adjacencies as well). P-Flag. Persistent flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains the same across router restart and/or interface flap. Other bits: Reserved. These MUST be zero when sent and are ignored when received. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Weight: Weight used for load-balancing purposes. The use of the weight is defined in [RFC8402]. SID/Index/Label: as described in Section 6. An SR-capable router MAY allocate an Adj-SID for each of its adjacencies and set the B-Flag when the adjacency is eligible for protection by an FRR mechanism (IP or MPLS) as described in [RFC8402]. An SR-capable router MAY allocate more than one Adj-SID to an adjacency. Psenak & Previdi Expires July 13, 2019 [Page 12] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 An SR-capable router MAY allocate the same Adj-SID to different adjacencies. When the P-flag is not set, the Adj-SID MAY be persistent. When the P-flag is set, the Adj-SID MUST be persistent. 7.2. LAN Adj-SID Sub-TLV The LAN Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link TLV. It MAY appear multiple times in the Router-Link TLV. It is used to advertise a SID/Label for an adjacency to a non-DR router on a broadcast, NBMA, or hybrid [RFC6845] network. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +---------------------------------------------------------------+ where: Type: 6 Length: 11 or 12 octets, dependent on V-flag. Flags: same as in Section 7.1 Weight: Weight used for load-balancing purposes. The use of the weight is defined in [RFC8402]. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- SID is advertised. SID/Index/Label: as described in Section 6. When the P-flag is not set, the LAN Adj-SID MAY be persistent. When the P-flag is set, the LAN Adj-SID MUST be persistent. Psenak & Previdi Expires July 13, 2019 [Page 13] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 8. Elements of Procedure 8.1. Intra-area Segment routing in OSPFv3 An OSPFv3 router that supports segment routing MAY advertise Prefix- SIDs for any prefix to which it is advertising reachability (e.g., a loopback IP address as described in Section 6). A Prefix-SID can also be advertised by SR Mapping Servers (as described in [I-D.ietf-spring-segment-routing-ldp-interop]). A Mapping Server advertises Prefix-SIDs for remote prefixes that exist in the OSPFv3 routing domain. Multiple Mapping Servers can advertise Prefix-SIDs for the same prefix, in which case the same Prefix-SID MUST be advertised by all of them. The SR Mapping Server could use either area flooding scope or autonomous system flooding scope when advertising Prefix SIDs for prefixes, based on the configuration of the SR Mapping Server. Depending on the flooding scope used, the SR Mapping Server chooses the OSPFv3 LSA type that will be used. If the area flooding scope is needed, an E-Intra-Area-Prefix-LSA [RFC8362] is used. If autonomous system flooding scope is needed, an E-AS- External-LSA [RFC8362] is used. When a Prefix-SID is advertised by the Mapping Server, which is indicated by the M-flag in the Prefix-SID Sub-TLV (Section 6), the route type as implied by the LSA type is ignored and the Prefix-SID is bound to the corresponding prefix independent of the route type. Advertisement of the Prefix-SID by the Mapping Server using an Inter- Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV [RFC8362] does not itself contribute to the prefix reachability. The NU-bit [RFC5340] MUST be set in the PrefixOptions field of the LSA which is used by the Mapping Server to advertise SID or SID Range, which prevents the advertisement from contributing to prefix reachability. An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs when advertising SIDs for prefixes. Prefixes of different route- types can be combined in a single OSPFv3 Extended Prefix Range TLV advertised by an SR Mapping Server. Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between areas, similar to propagation of prefixes between areas. Same rules that are used for propagating prefixes between areas [RFC5340] are used for the propagation of the prefix ranges. Psenak & Previdi Expires July 13, 2019 [Page 14] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 8.2. Inter-area Segment routing in OSPFv3 In order to support SR in a multi-area environment, OSPFv3 MUST propagate Prefix-SID information between areas. The following procedure is used to propagate Prefix SIDs between areas. When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA from an intra- area prefix to all its connected areas, it will also include the Prefix-SID Sub-TLV, as described in Section 6. The Prefix-SID value will be set as follows: The ABR will look at its best path to the prefix in the source area and find the advertising router associated with the best path to that prefix. The ABR will then determine if such router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connected areas. If no Prefix-SID was advertised for the prefix in the source area by the router that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to other areas. When an OSPFv3 ABR advertises Inter-Area-Prefix-LSA LSAs from an inter-area route to all its connected areas, it will also include the Prefix-SID Sub-TLV, as described in Section 6. The Prefix-SID value will be set as follows: The ABR will look at its best path to the prefix in the backbone area and find the advertising router associated with the best path to that prefix. The ABR will then determine if such router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connected areas. If no Prefix-SID was advertised for the prefix in the backbone area by the ABR that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to other areas. Psenak & Previdi Expires July 13, 2019 [Page 15] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 8.3. Segment Routing for External Prefixes AS-External-LSAs are flooded domain wide. When an ASBR, which supports SR, originates an E-AS-External-LSA, it SHOULD also include a Prefix-SID Sub-TLV, as described in Section 6. The Prefix-SID value will be set to the SID that has been reserved for that prefix. When an NSSA [RFC3101] ABR translates an E-NSSA-LSA into an E-AS- External-LSA, it SHOULD also advertise the Prefix-SID for the prefix. The NSSA ABR determines its best path to the prefix advertised in the translated E-NSSA-LSA and finds the advertising router associated with that path. If the advertising router has advertised a Prefix- SID for the prefix, then the NSSA ABR uses it when advertising the Prefix-SID for the E-AS-External-LSA. Otherwise, the Prefix-SID advertised by any other router will be used. 8.4. Advertisement of Adj-SID The Adjacency Segment Routing Identifier (Adj-SID) is advertised using the Adj-SID Sub-TLV as described in Section 7. 8.4.1. Advertisement of Adj-SID on Point-to-Point Links An Adj-SID MAY be advertised for any adjacency on a P2P link that is in neighbor state 2-Way or higher. If the adjacency on a P2P link transitions from the FULL state, then the Adj-SID for that adjacency MAY be removed from the area. If the adjacency transitions to a state lower than 2-Way, then the Adj-SID advertisement MUST be withdrawn from the area. 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces Broadcast, NBMA, or hybrid [RFC6845] networks in OSPFv3 are represented by a star topology where the DR is the central point to which all other routers on the broadcast, NBMA, or hybrid network connect. As a result, routers on the broadcast, NBMA, or hybrid network advertise only their adjacency to the DR. Routers that do not act as DR do not form or advertise adjacencies with each other. They do, however, maintain 2-Way adjacency state with each other and are directly reachable. When Segment Routing is used, each router on the broadcast, NBMA, or hybrid network MAY advertise the Adj-SID for its adjacency to the DR using the Adj-SID Sub-TLV as described in Section 7.1. SR-capable routers MAY also advertise a LAN-Adj-SID for other neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid network using the LAN-Adj-SID Sub-TLV as described in Section 7.2. Psenak & Previdi Expires July 13, 2019 [Page 16] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 9. IANA Considerations This specification updates several existing OSPFv3 registries. 9.1. OSPFv3 Extended-LSA TLV Registry Following values are allocated: o 9 - OSPFv3 Extended Prefix Range TLV 9.2. OSPFv3 Extended-LSA Sub-TLV registry o 4 - Prefix SID Sub-TLV o 5 - Adj-SID Sub-TLV o 6 - LAN Adj-SID Sub-TLV o 7 - SID/Label Sub-TLV 10. Security Considerations With the OSPFv3 segment routing extensions defined herein, OSPFv3 will now program the MPLS data plane [RFC3031]. Previously, LDP [RFC5036] or another label distribution mechanism was required to advertise MPLS labels and program the MPLS data plane. In general, the same types of attacks that can be carried out on the IP control plane can be carried out on the MPLS control plane resulting in traffic being misrouted in the respective data planes. However, the latter can be more difficult to detect and isolate. Existing security extensions as described in [RFC5340] and [RFC8362] apply to these segment routing extensions. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv3 router or routing process. Reception of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPFv3 control plane. Psenak & Previdi Expires July 13, 2019 [Page 17] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 11. Contributors The following people gave a substantial contribution to the content of this document and should be considered as co-authors: Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Hannes Gredler RtBrick Inc. Austria Email: hannes@rtbrick.com Rob Shakir Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: robjs@google.com Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 BE Email: wim.henderickx@nokia.com Jeff Tantsura Nuage Networks US Email: jefftant.ietf@gmail.com Thanks to Acee Lindem for his substantial contribution to the content of this document. We would like to thank Anton Smirnov for his contribution as well. Psenak & Previdi Expires July 13, 2019 [Page 18] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 12. References 12.1. Normative References [ALGOREG] "IGP Algorithm Types", . [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-27 (work in progress), December 2018. [I-D.ietf-spring-segment-routing-ldp-interop] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment-routing-ldp-interop-15 (work in progress), September 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-18 (work in progress), December 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . Psenak & Previdi Expires July 13, 2019 [Page 19] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 [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, . [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC6845, January 2013, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 12.2. Informative References [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, . [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . Psenak & Previdi Expires July 13, 2019 [Page 20] Internet-Draft OSPFv3 Extensions for Segment Routing January 2019 Authors' Addresses Peter Psenak (editor) Cisco Systems, Inc. Eurovea Centre, Central 3 Pribinova Street 10 Bratislava 81109 Slovakia Email: ppsenak@cisco.com Stefano Previdi (editor) Individual Email: stefano.previdi@net Psenak & Previdi Expires July 13, 2019 [Page 21] ./draft-ietf-perc-double-12.txt0000644000764400076440000011777213531757721015606 0ustar iustyiusty Network Working Group C. Jennings Internet-Draft P. Jones Intended status: Standards Track R. Barnes Expires: March 1, 2020 Cisco Systems A. Roach Mozilla August 29, 2019 SRTP Double Encryption Procedures draft-ietf-perc-double-12 Abstract In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real Time Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real Time Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties. 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 https://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 1, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Jennings, et al. Expires March 1, 2020 [Page 1] Internet-Draft Double SRTP August 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Cryptographic Context . . . . . . . . . . . . . . . . . . . . 4 3.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 5 4. Original Header Block . . . . . . . . . . . . . . . . . . . . 5 5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 7 5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 8 5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 9 6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 10 7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 11 7.1. RTP Retransmission (RTX) . . . . . . . . . . . . . . . . 11 7.2. Redundant Audio Data (RED) . . . . . . . . . . . . . . . 11 7.3. Forward Error Correction (FEC) . . . . . . . . . . . . . 12 7.4. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Recommended Inner and Outer Cryptographic Algorithms . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.1. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Encryption Overview . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Cloud conferencing systems that are based on switched conferencing have a central Media Distributor device that receives media from endpoints and distributes it to other endpoints, but does not need to interpret or change the media content. For these systems, it is desirable to have one cryptographic key that enables encryption and authentication of the media end-to-end while still allowing certain information in the header of a Real Time Protocol (RTP) packet to be changed by the Media Distributor. At the same time, a separate Jennings, et al. Expires March 1, 2020 [Page 2] Internet-Draft Double SRTP August 2019 cryptographic key provides integrity and optional confidentiality for the media flowing between the Media Distributor and the endpoints. The framework document [I-D.ietf-perc-private-media-framework] describes this concept in more detail. This specification defines a transform for the Secure Real Time Protocol (SRTP) that uses the AES-GCM algorithm [RFC7714] to provide encryption and integrity for an RTP packet for the end-to-end cryptographic key as well as a hop-by-hop cryptographic encryption and integrity between the endpoint and the Media Distributor. The Media Distributor decrypts and checks integrity of the hop-by-hop security. The Media Distributor MAY change some of the RTP header information that would impact the end-to-end integrity. In that case, the original value of any RTP header field that is changed is included in an "Original Header Block" that is added to the packet. The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent. The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the Media Distributor changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity. One can think of the double as a normal SRTP transform for encrypting the RTP in a way where things that only know half of the key, can decrypt and modify part of the RTP packet but not other parts, including the media payload. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Terms used throughout this document include: o Media Distributor: A device that receives media from endpoints and distributes it to other endpoints, but does not need to interpret or change the media content (see also [I-D.ietf-perc-private-media-framework]) o end-to-end: The path from one endpoint through one or more Media Distributors to the endpoint at the other end. o hop-by-hop: The path from the endpoint to or from the Media Distributor. Jennings, et al. Expires March 1, 2020 [Page 3] Internet-Draft Double SRTP August 2019 o Original Header Block (OHB): An octet string that contains the original values from the RTP header that might have been changed by a Media Distributor. 3. Cryptographic Context This specification uses a cryptographic context with two parts: o An inner (end-to-end) part that is used by endpoints that originate and consume media to ensure the integrity of media end- to-end, and o An outer (hop-by-hop) part that is used between endpoints and Media Distributors to ensure the integrity of media over a single hop and to enable a Media Distributor to modify certain RTP header fields. RTCP is also handled using the hop-by-hop cryptographic part. The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is AES-GCM. Other combinations of SRTP ciphers that support the procedures in this document can be added to the IANA registry. The keys and salt for these algorithms are generated with the following steps: o Generate key and salt values of the length required for the combined inner (end-to-end) and outer (hop-by-hop) algorithms. o Assign the key and salt values generated for the inner (end-to- end) algorithm to the first half of the key and the first half of the salt for the double algorithm. o Assign the key and salt values for the outer (hop-by-hop) algorithm to the second half of the key and second half of the salt for the double algorithm. The first half of the key is referred to as the inner key while the second half is referred to as the outer key. When a key is used by a cryptographic algorithm, the salt used is the part of the salt generated with that key. o the SSRC is the same for both the inner and out outer algorithms as it can not be changed. o The SEQ and ROC are tracked independently for the inner and outer algorithms. If the Media Distributor is to be able to modify header fields but not decrypt the payload, then it must have cryptographic key for the Jennings, et al. Expires March 1, 2020 [Page 4] Internet-Draft Double SRTP August 2019 outer algorithm, but not the inner (end-to-end) algorithm. This document does not define how the Media Distributor should be provisioned with this information. One possible way to provide keying material for the outer (hop-by-hop) algorithm is to use [I-D.ietf-perc-dtls-tunnel]. 3.1. Key Derivation Although SRTP uses a single master key to derive keys for an SRTP session, this transform requires separate inner and outer keys. In order to allow the inner and outer keys to be managed independently via the master key, the transforms defined in this document MUST be used with the following pseudo-random function (PRF), which preserves the separation between the two halves of the key. Given a positive integer "n" representing the desired output length, a master key "k_master", and an input "x": PRF\_double\_n(k\_master,x) = PRF\_(n/2)(inner(k\_master),x) || PRF\_(n/2)(outer(k\_master),x) Here "PRF_n(k, x)" represents the AES_CM PRF KDF (see Section 4.3.3 of [RFC3711]) for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm. "inner(key)" represents the first half of the key, and "outer(key)" represents the second half of the key. 4. Original Header Block The Original Header Block (OHB) contains the original values of any modified RTP header fields. In the encryption process, the OHB is included in an SRTP packet as described in Section 5. In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header, so that it can pass the proper AAD value to the inner transform. The OHB can reflect modifications to the following fields in an RTP header: the payload type, the sequence number, and the marker bit. All other fields in the RTP header MUST remain unmodified; since the OHB cannot reflect their original values, the receiver will be unable to verify the E2E integrity of the packet. The OHB has the following syntax (in ABNF [RFC5234]): Jennings, et al. Expires March 1, 2020 [Page 5] Internet-Draft Double SRTP August 2019 OCTET = %x00-FF PT = OCTET SEQ = 2OCTET Config = OCTET OHB = [ PT ] [ SEQ ] Config If present, the PT and SEQ parts of the OHB contain the original payload type and sequence number fields, respectively. The final "config" octet of the OHB specifies whether these fields are present, and the original value of the marker bit (if necessary): +-+-+-+-+-+-+-+-+ |R R R R B M P Q| +-+-+-+-+-+-+-+-+ o P: PT is present o Q: SEQ is present o M: Marker bit is present o B: Value of marker bit o R: Reserved, MUST be set to 0 In particular, an all-zero OHB config octet (0x00) indicates that there have been no modifications from the original header. If the marker bit is not present (M=0), then B MUST be set to zero. That is, if "C" represents the value of the config octet, then the masked value "C & 0x0C" MUST NOT have the value "0x80". 5. RTP Operations As implied by the use of the word "double" above, this transform applies AES-GCM to the SRTP packet twice. This allows media distributors to be able to modify some header fields while allowing endpoints to verify the end-to-end integrity of a packet. The first, "inner" application of AES-GCM encrypts the SRTP payload and integrity-protects a version of the SRTP header with extensions truncated. Omitting extensions from the inner integrity check means that they can be modified by a media distributor holding only the "outer" key. The second, "outer" application of AES-GCM encrypts the ciphertext produced by the inner encryption (i.e., the encrypted payload and Jennings, et al. Expires March 1, 2020 [Page 6] Internet-Draft Double SRTP August 2019 authentication tag), plus an OHB that expresses any changes made between the inner and outer transforms. A media distributor that has the outer key but not the inner key may modify the header fields that can be included in the OHB by decrypting, modifying, and re-encrypting the packet. 5.1. Encrypting a Packet To encrypt a packet, the endpoint encrypts the packet using the inner (end-to-end) cryptographic key and then encrypts using the outer (hop-by-hop) cryptographic key. The encryption also supports a mode for repair packets that only does the outer (hop-by-hop) encryption. The processes is as follows: 1. Form an RTP packet. If there are any header extensions, they MUST use [RFC8285]. 2. If the packet is for repair mode data, skip to step 6. 3. Form a synthetic RTP packet with the following contents: * Header: The RTP header of the original packet with the following modifications: * The X bit is set to zero * The header is truncated to remove any extensions (i.e., keep only the first 12 + 4 * CC bytes of the header) * Payload: The RTP payload of the original packet (including padding when present) 4. Apply the inner cryptographic algorithm to the synthetic RTP packet from the previous step. 5. Replace the header of the protected RTP packet with the header of the original packet (to restore any header extensions and reset the X bit), and append an empty OHB (0x00) to the encrypted payload (with the authentication tag) obtained from the step 4. 6. Apply the outer cryptographic algorithm to the RTP packet. If encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST be used when encrypting the RTP packet using the outer cryptographic key. Jennings, et al. Expires March 1, 2020 [Page 7] Internet-Draft Double SRTP August 2019 When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes after the SRTP packet exactly like using EKT with any other SRTP transform. 5.2. Relaying a Packet The Media Distributor has the part of the key for the outer (hop-by- hop) cryptographic algorithm, but it does not have the part of the key for the (end-to-end) cryptographic algorithm. The cryptographic algorithm and key used to decrypt a packet and any encrypted RTP header extensions would be the same as those used in the endpoint's outer algorithm and key. In order to modify a packet, the Media Distributor decrypts the received packet, modifies the packet, updates the OHB with any modifications not already present in the OHB, and re-encrypts the packet using the the outer (hop-by-hop) cryptographic key before transmitting. 1. Apply the outer (hop-by-hop) cryptographic algorithm to decrypt the packet. If decrypting RTP header extensions hop-by-hop, then [RFC6904] MUST be used. Note that the RTP payload produced by this decryption operation contains the original encrypted payload with the tag from the inner transform and the OHB appended. 2. Make any desired changes to the fields are allowed to be changed, i.e., PT, SEQ, and M. The Media Distributor MAY also make modifications to header extensions, without the need to reflect these changes in the OHB. 3. Reflect any changes to header fields in the OHB: * If Media Distributor changed a field that is not already in the OHB, then it MUST add the original value of the field to the OHB. Note that this might result in an increase in the size of the OHB. * If the Media Distributor took a field that had previously been modified and reset to its original value, then it SHOULD drop the corresponding information from the OHB. Note that this might result in a decrease in the size of the OHB. * Otherwise, the Media Distributor MUST NOT modify the OHB. 4. Apply the outer (hop-by-hop) cryptographic algorithm to the packet. If the RTP Sequence Number has been modified, SRTP processing happens as defined in SRTP and will end up using the Jennings, et al. Expires March 1, 2020 [Page 8] Internet-Draft Double SRTP August 2019 new Sequence Number. If encrypting RTP header extensions hop-by- hop, then [RFC6904] MUST be used. In order to avoid nonce reuse, the cryptographic contexts used in step 1 and step 5 MUST use different, independent master keys. Note that this means that the key used for decryption by the MD MUST be different from the key used for re-encryption to the end recipient. Note that if multiple MDs modify the same packet, then the first MD to alter a given header field is the one that adds it to the OHB. If a subsequent MD changes the value of a header field that has already been changed, then the original value will already be in the OHB, so no update to the OHB is required. A Media Distributor that decrypts, modifies, and re-encrypts packets in this way MUST use an independent key for each recipient, and MUST NOT re-encrypt the packet using the sender's keys. If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of AES-GCM. 5.3. Decrypting a Packet To decrypt a packet, the endpoint first decrypts and verifies using the outer (hop-by-hop) cryptographic key, then uses the OHB to reconstruct the original packet, which it decrypts and verifies with the inner (end-to-end) cryptographic key. 1. Apply the outer cryptographic algorithm to the packet. If the integrity check does not pass, discard the packet. The result of this is referred to as the outer SRTP packet. If decrypting RTP header extensions hop-by-hop, then [RFC6904] MUST be used when decrypting the RTP packet using the outer cryptographic key. 2. If the packet is for repair mode data, skip the rest of the steps. Note that the packet that results from the repair algorithm will still have encrypted data that needs to be decrypted as specified by the repair algorithm sections. 3. Remove the inner authentication tag and the OHB from the end of the payload of the outer SRTP packet. 4. Form a new synthetic SRTP packet with: * Header = Received header, with the following modifications: * Header fields replaced with values from OHB (if any) Jennings, et al. Expires March 1, 2020 [Page 9] Internet-Draft Double SRTP August 2019 * The X bit is set to zero * The header is truncated to remove any extensions (i.e., keep only the first 12 + 4 * CC bytes of the header) * Payload is the encrypted payload from the outer SRTP packet (after the inner tag and OHB have been stripped). * Authentication tag is the inner authentication tag from the outer SRTP packet. 5. Apply the inner cryptographic algorithm to this synthetic SRTP packet. Note if the RTP Sequence Number was changed by the Media Distributor, the synthetic packet has the original Sequence Number. If the integrity check does not pass, discard the packet. Once the packet has been successfully decrypted, the application needs to be careful about which information it uses to get the correct behavior. The application MUST use only the information found in the synthetic SRTP packet and MUST NOT use the other data that was in the outer SRTP packet with the following exceptions: o The PT from the outer SRTP packet is used for normal matching to SDP and codec selection. o The sequence number from the outer SRTP packet is used for normal RTP ordering. The PT and sequence number from the inner SRTP packet can be used for collection of various statistics. If the RTP header of the outer packet contains extensions, they MAY be used. However, because extensions are not protected end-to-end, implementations SHOULD reject an RTP packet containing headers that would require end-to-end protection. 6. RTCP Operations Unlike RTP, which is encrypted both hop-by-hop and end-to-end using two separate cryptographic keys, RTCP is encrypted using only the outer (hop-by-hop) cryptographic key. The procedures for RTCP encryption are specified in [RFC3711] and this document introduces no additional steps. Jennings, et al. Expires March 1, 2020 [Page 10] Internet-Draft Double SRTP August 2019 7. Use with Other RTP Mechanisms Media Distributors sometimes interact with RTP media packets sent by endpoints, e.g., to provide recovery or receive commands via DTMF. When media packets are encrypted end-to-end, these procedures require modification. (End-to-end interactions, including end-to-end recovery, are not affected by end-to-end encryption.) Repair mechanisms, in general, will need to perform recovery on encrypted packets (double-encrypted when using this transform), since the Media Distributor does not have access to the plaintext of the packet, only an intermediate, E2E-encrypted form. When the recovery mechanism calls for the recovery packet itself to be encrypted, it is encrypted with only the outer, hop-by-hop key. This allows a media distributor to generate recovery packets without having access to the inner, end-to-end keys. However, it also results in recovery packets being triple-encrypted, twice for the base transform, and once for the recovery protection. 7.1. RTP Retransmission (RTX) When using RTX [RFC4588] with double, the cached payloads MUST be the double-encrypted packets, i.e., the bits that are sent over the wire to the other side. When encrypting a retransmission packet, it MUST be encrypted the packet in repair mode (i.e., with only the hop-by- hop key). If the Media Distributor were to cache the inner, E2E-encrypted payload and retransmit that with an RTX OSN field prepended, then the modifications to the payload would cause the inner integrity check to fail at the receiver. A typical RTX receiver would decrypt the packet, undo the RTX transformation, then process the resulting packet normally by using the steps in Section 5.3. 7.2. Redundant Audio Data (RED) When using RED [RFC2198] with double, the processing at the sender and receiver is the same as when using RED with any other SRTP transform. The main difference between double and any other transform is that in an intermediated environment, usage of RED must be end-to-end. A Media Distributor cannot synthesize RED packets, because it lacks access to the plaintext media payloads that are combined to form a RED payload. Jennings, et al. Expires March 1, 2020 [Page 11] Internet-Draft Double SRTP August 2019 Note that FlexFEC may often provide similar or better repair capabilities compared to RED. For most applications, FlexFEC is a better choice than RED; in particular, FlexFEC has modes in which the Media Distributor can synthesize recovery packets. 7.3. Forward Error Correction (FEC) When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with double, repair packets MUST be constructed by first double-encrypting the packet, then performing FEC. Processing of repair packets proceeds in the opposite order, performing FEC recovery and then decrypting. This ensures that the original media is not revealed to the Media Distributor but at the same time allows the Media Distributor to repair media. When encrypting a packet that contains the Flex FEC data, which is already encrypted, it MUST be encrypted with only the outer, hop-by-hop transform. The algorithm recommended in [I-D.ietf-rtcweb-fec] for repair of video is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that for interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends not using additional FEC only m-line in SDP for the repair packets. 7.4. DTMF When DTMF is sent using the mechanism in [RFC4733], it is end-to-end encrypted and the relay can not read it, so it cannot be used to control the relay. Other out of band methods to control the relay need to be used instead. 8. Recommended Inner and Outer Cryptographic Algorithms This specification recommends and defines AES-GCM as both the inner and outer cryptographic algorithms, identified as DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithm provide for authenticated encryption and will consume additional processing time double-encrypting for hop-by-hop and end-to-end. However, the approach is secure and simple, and is thus viewed as an acceptable trade-off in processing efficiency. Note that names for the cryptographic transforms are of the form DOUBLE_(inner algorithm)_(outer algorithm). While this document only defines a profile based on AES-GCM, it is possible for future documents to define further profiles with different inner and outer algorithms in this same framework. For example, if a new SRTP transform was defined that encrypts some or all of the RTP header, it would be reasonable for systems to have the Jennings, et al. Expires March 1, 2020 [Page 12] Internet-Draft Double SRTP August 2019 option of using that for the outer algorithm. Similarly, if a new transform was defined that provided only integrity, that would also be reasonable to use for the outer transform as the payload data is already encrypted by the inner transform. The AES-GCM cryptographic algorithm introduces an additional 16 octets to the length of the packet. When using AES-GCM for both the inner and outer cryptographic algorithms, the total additional length is 32 octets. The OHB will consume an additional 1-4 octets. Packets in repair mode will carry additional repair data, further increasing their size. 9. Security Considerations This SRTP transform provides protection against two classes of attacker: An network attacker that knows neither the inner nor outer keys, and a malicious MD that knows the outer key. Obviously, it provides no protections against an attacker that holds both the inner and outer keys. The protections with regard to the network are the same as with the normal SRTP AES-GCM transforms. The major difference is that the double transforms are designed to work better in a group context. In such contexts, it is important to note that because these transforms are symmetric, they do not protect against attacks within the group. Any member of the group can generate valid SRTP packets for any SSRC in use by the group. With regard to a malicious MD, the recipient can verify the integrity of the base header fields and confidentiality and integrity of the payload. The recipient has no assurance, however, of the integrity of the header extensions in the packet. The main innovation of this transform relative to other SRTP transforms is that it allows a partly-trusted MD to decrypt, modify, and re-encrypt a packet. When this is done, the cryptographic contexts used for decryption and re-encryption MUST use different, independent master keys. If the same context is used, the nonce formation rules for SRTP will cause the same key and nonce to be used with two different plaintexts, which substantially degrades the security of AES-GCM. In other words, from the perspective of the MD, re-encrypting packets using this protocol will involve the same cryptographic operations as if it had established independent AES-GCM crypto contexts with the sender and the receiver. If the MD doesn't modify any header fields, then an MD that supports AES-GCM could be unused unmodified. Jennings, et al. Expires March 1, 2020 [Page 13] Internet-Draft Double SRTP August 2019 10. IANA Considerations 10.1. DTLS-SRTP We request IANA to add the following values to defines a DTLS-SRTP "SRTP Protection Profile" defined in [RFC5764]. +------------+------------------------------------------+-----------+ | Value | Profile | Reference | +------------+------------------------------------------+-----------+ | {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFCXXXX | | 0x09} | | | | {0x00, | DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM | RFCXXXX | | 0x0A} | | | +------------+------------------------------------------+-----------+ Note to IANA: Please assign value RFCXXXX and update table to point at this RFC for these values. The SRTP transform parameters for each of these protection are: DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM cipher: AES_128_GCM then AES_128_GCM cipher_key_length: 256 bits cipher_salt_length: 192 bits aead_auth_tag_length: 256 bits auth_function: NULL auth_key_length: N/A auth_tag_length: N/A maximum lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM cipher: AES_256_GCM then AES_256_GCM cipher_key_length: 512 bits cipher_salt_length: 192 bits aead_auth_tag_length: 256 bits auth_function: NULL auth_key_length: N/A auth_tag_length: N/A maximum lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets The first half of the key and salt is used for the inner (end-to-end) algorithm and the second half is used for the outer (hop-by-hop) algorithm. Jennings, et al. Expires March 1, 2020 [Page 14] Internet-Draft Double SRTP August 2019 11. Acknowledgments Thank you for reviews and improvements to this specification from Alex Gouaillard, David Benham, Magnus Westerlund, Nils Ohlmeier, Paul Jones, Roni Even, and Suhas Nandakumar. In addition, thank you to Sergio Garcia Murillo proposed the change of transporting the OHB information in the RTP payload instead of the RTP header. 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, . [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, . [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, . [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", RFC 7714, DOI 10.17487/RFC7714, December 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Jennings, et al. Expires March 1, 2020 [Page 15] Internet-Draft Double SRTP August 2019 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . 12.2. Informative References [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-20 (work in progress), May 2019. [I-D.ietf-perc-dtls-tunnel] Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05 (work in progress), April 2019. [I-D.ietf-perc-private-media-framework] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC)", draft-ietf-perc-private-media- framework-12 (work in progress), June 2019. [I-D.ietf-perc-srtp-ekt-diet] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure RTP", draft-ietf-perc-srtp-ekt-diet-10 (work in progress), July 2019. [I-D.ietf-rtcweb-fec] Uberti, J., "WebRTC Forward Error Correction Requirements", draft-ietf-rtcweb-fec-10 (work in progress), July 2019. [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, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . Jennings, et al. Expires March 1, 2020 [Page 16] Internet-Draft Double SRTP August 2019 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Appendix A. Encryption Overview The following figure shows a double encrypted SRTP packet. The sides indicate the parts of the packet that are encrypted and authenticated by the hop-by-hop and end-to-end operations. 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|X| CC |M| PT | sequence number | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | timestamp | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | synchronization source (SSRC) identifier | IO +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO | contributing source (CSRC) identifiers | IO | .... | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O | RTP extension (OPTIONAL) ... | |O +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O I | payload ... | IO O I | +-------------------------------+ IO O I | | RTP padding | RTP pad count | IO O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O | | E2E authentication tag | |O O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O O | | OHB ... | |O +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ | | | HBH authentication tag | || | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | | || | +- E2E Encrypted Portion E2E Authenticated Portion ---+| | | +--- HBH Encrypted Portion HBH Authenticated Portion ----+ Jennings, et al. Expires March 1, 2020 [Page 17] Internet-Draft Double SRTP August 2019 Authors' Addresses Cullen Jennings Cisco Systems Email: fluffy@iii.ca Paul E. Jones Cisco Systems Email: paulej@packetizer.com Richard Barnes Cisco Systems Email: rlb@ipv.sx Adam Roach Mozilla Email: adam@nostrum.com Jennings, et al. Expires March 1, 2020 [Page 18] ./draft-ietf-ospf-segment-routing-extensions-27.txt0000644000764400076440000016737413401314063021667 0ustar iustyiusty Open Shortest Path First IGP P. Psenak, Ed. Internet-Draft S. Previdi, Ed. Intended status: Standards Track C. Filsfils Expires: June 6, 2019 Cisco Systems, Inc. H. Gredler RtBrick Inc. R. Shakir Google, Inc. W. Henderickx Nokia J. Tantsura Apstra, Inc. December 3, 2018 OSPF Extensions for Segment Routing draft-ietf-ospf-segment-routing-extensions-27 Abstract Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv2 extensions required for Segment Routing. 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 https://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." Psenak, et al. Expires June 6, 2019 [Page 1] Internet-Draft OSPF Extensions for Segment Routing December 2018 This Internet-Draft will expire on June 6, 2019. Copyright Notice Copyright (c) 2018 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 (https://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. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 3.3. SR Local Block TLV . . . . . . . . . . . . . . . . . . . 8 3.4. SRMS Preference TLV . . . . . . . . . . . . . . . . . . . 10 4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 11 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 13 6. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 16 6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 17 6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 18 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 7.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 19 7.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 20 7.3. Segment Routing for External Prefixes . . . . . . . . . . 21 7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 22 7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 22 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8.1. OSPF Router Information (RI) TLVs Registry . . . . . . . 22 8.2. OSPFv2 Extended Prefix Opaque LSA TLVs Registry . . . . . 23 8.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry . . . . . . 23 8.4. OSPFv2 Extended Link TLV Sub-TLVs Registry . . . . . . . 23 8.5. IGP Algorithm Type Registry . . . . . . . . . . . . . . . 23 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 Psenak, et al. Expires June 6, 2019 [Page 2] Internet-Draft OSPF Extensions for Segment Routing December 2018 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 13.2. Informative References . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Prefix segments represent an ECMP-aware shortest-path to a prefix (or a node), as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most cases, is a one-hop path. SR's control-plane can be applied to both IPv6 and MPLS data-planes, and does not require any additional signalling (other than IGP extensions). The IPv6 data plane is out of the scope of this specification - it is not applicable to OSPFv2 which only supports the IPv4 address-family. When used in MPLS networks, SR paths do not require any LDP or RSVP-TE signalling. However, SR can interoperate in the presence of LSPs established with RSVP or LDP. There are additional segment types, e.g., Binding SID defined in [I-D.ietf-spring-segment-routing]. This draft describes the OSPF extensions required for Segment Routing. Segment Routing architecture is described in [I-D.ietf-spring-segment-routing]. Segment Routing use cases are described in [RFC7855]. 2. Segment Routing Identifiers Segment Routing defines various types of Segment Identifiers (SIDs): Prefix-SID, Adjacency-SID, LAN Adjacency SID, and Binding SID. Extended Prefix/Link Opaque LSAs defined in [RFC7684] are used for advertisements of the various SID types. Psenak, et al. Expires June 6, 2019 [Page 3] Internet-Draft OSPF Extensions for Segment Routing December 2018 2.1. SID/Label Sub-TLV The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined later in this document. It is used to advertise the SID or label associated with a prefix or adjacency. The SID/Label Sub-TLV has 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 1 Length: Variable, 3 or 4 octet SID/Label: If length is set to 3, then the 20 rightmost bits represent a label. If length is set to 4, then the value represents a 32-bit SID. The receiving router MUST ignore the SID/Label Sub-TLV if the length is other then 3 or 4. 3. Segment Routing Capabilities Segment Routing requires some additional router capabilities to be advertised to other routers in the area. These SR capabilities are advertised in the Router Information Opaque LSA (defined in [RFC7770]). The TLVs defined below are applicable to both OSPFv2 and OSPFv3; see also [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 3.1. SR-Algorithm TLV The SR-Algorithm TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]). The SR-Algorithm TLV is optional. It SHOULD only be advertised once in the Router Information Opaque LSA. If the SR-Algorithm TLV is not advertised by the node, such node is considered as not being segment routing capable. Psenak, et al. Expires June 6, 2019 [Page 4] Internet-Draft OSPF Extensions for Segment Routing December 2018 An SR Router can use various algorithms when calculating reachability to OSPF routers or prefixes in an OSPF area. Examples of these algorithms are metric based Shortest Path First (SPF), various flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a router to advertise the algorithms currently used by the router to other routers in an OSPF area. The SR-Algorithm TLV has 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm... | Algorithm n | | +- -+ | | + + where: Type: 8 Variable, in octets, dependent on number of algorithms advertised. Algorithm: Single octet identifying the algorithm. The following values are defined by this document: 0: Shortest Path First (SPF) algorithm based on link metric. This is the standard shortest path algorithm as computed by the OSPF protocol. Consistent with the deployed practice for link- state protocols, Algorithm 0 permits any node to overwrite the SPF path with a different path based on its local policy. If the SR-Algorithm TLV is advertised, Algorithm 0 MUST be included. 1: Strict Shortest Path First (SPF) algorithm based on link metric. The algorithm is identical to Algorithm 0 but Algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy at the node claiming support for Algorithm 1 MUST NOT alter the SPF paths computed by Algorithm 1. When multiple SR-Algorithm TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information LSA. If the SR-Algorithm TLV appears in multiple Router Information LSAs that have different flooding scopes, the SR- Algorithm TLV in the Router Information LSA with the area-scoped flooding scope MUST be used. If the SR-Algorithm TLV appears in Psenak, et al. Expires June 6, 2019 [Page 5] Internet-Draft OSPF Extensions for Segment Routing December 2018 multiple Router Information LSAs that have the same flooding scope, the SR-Algorithm TLV in the Router Information (RI) LSA with the numerically smallest Instance ID MUST be used and subsequent instances of the SR-Algorithm TLV MUST be ignored. The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of SR-Algorithm TLV advertisement, area-scoped flooding is REQUIRED. 3.2. SID/Label Range TLV Prefix SIDs MAY be advertised in a form of an index as described in Section 5. Such index defines the offset in the SID/Label space advertised by the router. The SID/Label Range TLV is used to advertise such SID/Label space. The SID/Label Range TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]). The SID/Label Range TLV MAY appear multiple times and 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | + + where: Type: 9 Length: Variable, in octets, dependent on Sub-TLVs. Range Size: 3-octet SID/label range size (i.e., the number of SIDs or labels in the range including the first SID/label). It MUST be greater than 0. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Psenak, et al. Expires June 6, 2019 [Page 6] Internet-Draft OSPF Extensions for Segment Routing December 2018 Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as defined in Section 2.1. The SID/Label Sub-TLV MUST be included in the SID/Label Range TLV. The SID/Label advertised in the SID/Label Sub-TLV represents the first SID/Label in the advertised range. Only a single SID/Label Sub-TLV MAY be advertised in SID/Label Range TLV. If more then one SID/Label Sub-TLVs are present, the SID/Label Range TLV MUST be ignored. Multiple occurrences of the SID/Label Range TLV MAY be advertised, in order to advertise multiple ranges. In such case: o The originating router MUST encode each range into a different SID/Label Range TLV. o The originating router decides the order in which the set of SID/ Label Range TLVs are advertised inside the Router Information Opaque LSA. The originating router MUST ensure the order is the same after a graceful restart (using checkpointing, non-volatile storage, or any other mechanism) in order to assure the SID/label range and SID index correspondence is preserved across graceful restarts. o The receiving router MUST adhere to the order in which the ranges are advertised when calculating a SID/label from a SID index. o The originating router MUST NOT advertise overlapping ranges. o When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]. The following example illustrates the advertisement of multiple ranges: Psenak, et al. Expires June 6, 2019 [Page 7] Internet-Draft OSPF Extensions for Segment Routing December 2018 The originating router advertises the following ranges: Range 1: Range Size: 100 SID/Label Sub-TLV: 100 Range 1: Range Size: 100 SID/Label Sub-TLV: 1000 Range 1: Range Size: 100 SID/Label Sub-TLV: 500 The receiving routers concatenate the ranges and build the Segment Routing Global Block (SRGB) as follows: SRGB = [100, 199] [1000, 1099] [500, 599] The indexes span multiple ranges: index=0 means label 100 ... index 99 means label 199 index 100 means label 1000 index 199 means label 1099 ... index 200 means label 500 ... The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). For the purpose of SID/ Label Range TLV advertisement, area-scoped flooding is REQUIRED. 3.3. SR Local Block TLV The SR Local Block TLV (SRLB TLV) contains the range of labels the node has reserved for local SIDs. SIDs from the SRLB MAY be used for Adjacency-SIDs, but also by components other than the OSPF protocol. As an example, an application or a controller can instruct the router to allocate a specific local SID. Some controllers or applications can use the control plane to discover the available set of local SIDs on a particular router. In such cases, the SRLB is advertised in the control plane. The requirement to advertise the SRLB is further described in [I-D.ietf-spring-segment-routing-mpls]. The SRLB TLV is used to advertise the SRLB. The SRLB TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]). The SRLB TLV MAY appear multiple times in the Router Information Opaque LSA and has the following format: Psenak, et al. Expires June 6, 2019 [Page 8] Internet-Draft OSPF Extensions for Segment Routing December 2018 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | + + where: Type: 14 Length: Variable, in octets, dependent on Sub-TLVs. Range Size: 3-octet SID/label range size (i.e., the number of SIDs or labels in the range including the first SID/label). It MUST be greater than 0. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as defined in Section 2.1. The SID/Label Sub-TLV MUST be included in the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV represents the first SID/Label in the advertised range. Only a single SID/Label Sub-TLV MAY be advertised in the SRLB TLV. If more then one SID/Label Sub-TLVs are present, the SRLB TLV MUST be ignored. The originating router MUST NOT advertise overlapping ranges. Each time a SID from the SRLB is allocated, it SHOULD also be reported to all components (e.g., controller or applications) in order for these components to have an up-to-date view of the current SRLB allocation. This is required to avoid collisions between allocation instructions. Within the context of OSPF, the reporting of local SIDs is done through OSPF Sub-TLVs such as the Adjacency-SID (Section 6). However, the reporting of allocated local SIDs can also be done through other means and protocols which are outside the scope of this document. Psenak, et al. Expires June 6, 2019 [Page 9] Internet-Draft OSPF Extensions for Segment Routing December 2018 A router advertising the SRLB TLV MAY also have other label ranges, outside of the SRLB, used for its local allocation purposes which are not advertised in the SRLB TLV. For example, it is possible that an Adjacency-SID is allocated using a local label that is not part of the SRLB. The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). For the purpose of SRLB TLV advertisement, area-scoped flooding is REQUIRED. 3.4. SRMS Preference TLV The Segment Routing Mapping Server Preference TLV (SRMS Preference TLV) is used to advertise a preference associated with the node that acts as an SR Mapping Server. The role of an SRMS is described in [I-D.ietf-spring-segment-routing-ldp-interop]. SRMS preference is defined in [I-D.ietf-spring-segment-routing-ldp-interop]. The SRMS Preference TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]). The SRMS Preference TLV MAY only be advertised once in the Router Information Opaque LSA and 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 15 Length: 4 octets Preference: 1 octet. SRMS preference value from 0 to 255. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. When multiple SRMS Preference TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information LSA. If the SRMS Preference TLV appears in multiple Router Information LSAs that have different flooding scopes, the SRMS Preference TLV in the Router Information LSA with the narrowest Psenak, et al. Expires June 6, 2019 [Page 10] Internet-Draft OSPF Extensions for Segment Routing December 2018 flooding scope MUST be used. If the SRMS Preference TLV appears in multiple Router Information LSAs that have the same flooding scope, the SRMS Preference TLV in the Router Information LSA with the numerically smallest Instance ID MUST be used and subsequent instances of the SRMS Preference TLV MUST be ignored. The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). For the purpose of the SRMS Preference TLV advertisement, AS-scoped flooding SHOULD be used. This is because SRMS servers can be located in a different area then consumers of the SRMS advertisements. If the SRMS advertisements from the SRMS server are only used inside the SRMS server's area, area-scoped flooding MAY be used. 4. OSPF Extended Prefix Range TLV In some cases it is useful to advertise attributes for a range of prefixes. The Segment Routing Mapping Server, which is described in [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we need a single advertisement to advertise SIDs for multiple prefixes from a contiguous address range. The OSPF Extended Prefix Range TLV, which is a top level TLV of the Extended Prefix LSA described in [RFC7684] is defined for this purpose. Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a single OSPF Extended Prefix Opaque LSA MUST have the same flooding scope. The OSPF Extended Prefix Range 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | AF | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | where: Psenak, et al. Expires June 6, 2019 [Page 11] Internet-Draft OSPF Extensions for Segment Routing December 2018 Type: 2 Length: Variable, in octets, dependent on Sub-TLVs. Prefix length: Length of prefix in bits. AF: Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast. The inclusion of address family in this TLV allows for future extension. Range size: Represents the number of prefixes that are covered by the advertisement. The Range Size MUST NOT exceed the number of prefixes that could be satisfied by the prefix length without including the IPv4 multicast address range (224.0.0.0/3). Flags: Single octet field. The following flags are defined: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |IA| | | | | | | | +--+--+--+--+--+--+--+--+ where: IA-Flag: Inter-Area flag. If set, advertisement is of inter- area type. An ABR that is advertising the OSPF Extended Prefix Range TLV between areas MUST set this bit. This bit is used to prevent redundant flooding of Prefix Range TLVs between areas as follows: An ABR only propagates an inter-area Prefix Range advertisement from the backbone area to connected non- backbone areas if the advertisement is considered to be the best one. The following rules are used to select the best range from the set of advertisements for the same Prefix Range: An ABR always prefers intra-area Prefix Range advertisements over inter-area advertisements. An ABR does not consider inter-area Prefix Range advertisements coming from non-backbone areas. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. Psenak, et al. Expires June 6, 2019 [Page 12] Internet-Draft OSPF Extensions for Segment Routing December 2018 Address Prefix: For the address family IPv4 unicast, the prefix itself is encoded as a 32-bit value. The default route is represented by a prefix of length 0. Prefix encoding for other address families is beyond the scope of this specification. 5. Prefix SID Sub-TLV The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV described in [RFC7684] and the OSPF Extended Prefix Range TLV described in Section 4. It MAY appear more than once in the parent TLV and 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | MT-ID | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 2 Length: 7 or 8 octets, dependent on the V-flag Flags: Single octet field. The following flags are defined: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | |NP|M |E |V |L | | | +--+--+--+--+--+--+--+--+ where: NP-Flag: No-PHP flag. If set, then the penultimate hop MUST NOT pop the Prefix-SID before delivering packets to the node that advertised the Prefix-SID. M-Flag: Mapping Server Flag. If set, the SID was advertised by a Segment Routing Mapping Server as described in [I-D.ietf-spring-segment-routing-ldp-interop]. Psenak, et al. Expires June 6, 2019 [Page 13] Internet-Draft OSPF Extensions for Segment Routing December 2018 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with the Explicit-NULL label (0 for IPv4) before forwarding the packet. V-Flag: Value/Index Flag. If set, then the Prefix-SID carries an absolute value. If not set, then the Prefix-SID carries an index. L-Flag: Local/Global Flag. If set, then the value/index carried by the Prefix-SID has local significance. If not set, then the value/index carried by this Sub-TLV has global significance. Other bits: Reserved. These MUST be zero when sent and are ignored when received. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. MT-ID: Multi-Topology ID (as defined in [RFC4915]). Algorithm: Single octet identifying the algorithm the Prefix-SID is associated with as defined in Section 3.1. A router receiving a Prefix-SID from a remote node and with an algorithm value that such remote node has not advertised in the SR-Algorithm Sub-TLV (Section 3.1) MUST ignore the Prefix-SID Sub- TLV. SID/Index/Label: According to the V and L flags, it contains: V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label field is a 4 octet index defining the offset in the SID/Label space advertised by this router V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label field is a 3 octet local label where the 20 rightmost bits are used for encoding the label value. All other combinations of V-flag and L-flag are invalid and any SID advertisement received with an invalid setting for V and L flags MUST be ignored. If an OSPF router advertises multiple Prefix-SIDs for the same prefix, topology and algorithm, all of them MUST be ignored. When calculating the outgoing label for the prefix, the router MUST take into account, as described below, the E, NP and M flags Psenak, et al. Expires June 6, 2019 [Page 14] Internet-Draft OSPF Extensions for Segment Routing December 2018 advertised by the next-hop router if that router advertised the SID for the prefix. This MUST be done regardless of whether the next-hop router contributes to the best path to the prefix. The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Prefix-SIDs allocated to inter-area prefixes that are originated by the ABR based on intra-area or inter-area reachability between areas, unless the advertised prefix is directly attached to the ABR. The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Prefix-SIDs allocated to redistributed prefixes, unless the redistributed prefix is directly attached to the ASBR. If the NP-Flag is not set, then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane. If the NP-flag is not set, then the received E-flag is ignored. If the NP-flag is set then: If the E-flag is not set, then any upstream neighbor of the Prefix-SID originator MUST keep the Prefix-SID on top of the stack. This is useful when the originator of the Prefix-SID need to stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at an Area Border Router (prefix propagation from one area to another) or at an AS Boundary Router (prefix propagation from one domain to another). If the E-flag is set, then any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with an Explicit-NULL label. This is useful, e.g., when the originator of the Prefix- SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at reception. As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server advertisement. However, PHP behavior SHOULD be done in following cases: The Prefix is intra-area type and the downstream neighbor is the originator of the prefix. The Prefix is inter-area type and downstream neighbor is an ABR, which is advertising prefix reachability and is also generating Psenak, et al. Expires June 6, 2019 [Page 15] Internet-Draft OSPF Extensions for Segment Routing December 2018 the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684]. The Prefix is external type and downstream neighbor is an ASBR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-flag set for this prefix as described in section 2.1 of [RFC7684]. When a Prefix-SID is advertised in an Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a starting SID/Label value. Example 1: If the following router addresses (loopback addresses) need to be mapped into the corresponding Prefix SID indexes: Router-A: 192.0.2.1/32, Prefix-SID: Index 1 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 then the Prefix field in the Extended Prefix Range TLV would be set to 192.0.2.1, Prefix Length would be set to 32, Range Size would be set to 4, and the Index value in the Prefix-SID Sub-TLV would be set to 1. Example 2: If the following prefixes need to be mapped into the corresponding Prefix-SID indexes: 192.0.2.0/30, Prefix-SID: Index 51 192.0.2.4/30, Prefix-SID: Index 52 192.0.2.8/30, Prefix-SID: Index 53 192.0.2.12/30, Prefix-SID: Index 54 192.0.2.16/30, Prefix-SID: Index 55 192.0.2.20/30, Prefix-SID: Index 56 192.0.2.24/30, Prefix-SID: Index 57 then the Prefix field in the Extended Prefix Range TLV would be set to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 6. Adjacency Segment Identifier (Adj-SID) An Adjacency Segment Identifier (Adj-SID) represents a router adjacency in Segment Routing. Psenak, et al. Expires June 6, 2019 [Page 16] Internet-Draft OSPF Extensions for Segment Routing December 2018 6.1. Adj-SID Sub-TLV Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in [RFC7684]. It MAY appear multiple times in the Extended Link TLV. The Adj-SID 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | MT-ID | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +---------------------------------------------------------------+ where: Type: 2 Length: 7 or 8 octets, dependent on the V flag. Flags: Single octet field containing the following flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|V|L|G|P| | +-+-+-+-+-+-+-+-+ where: B-Flag: Backup Flag. If set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IPFRR or MPLS-FRR) as described in section 3.5 of [I-D.ietf-spring-segment-routing]. The V-Flag: Value/Index Flag. If set, then the Adj-SID carries an absolute value. If not set, then the Adj-SID carries an index. The L-Flag: Local/Global Flag. If set, then the value/index carried by the Adj-SID has local significance. If not set, then the value/index carried by this Sub-TLV has global significance. The G-Flag: Group Flag. When set, the G-Flag indicates that the Adj-SID refers to a group of adjacencies (and therefore MAY be assigned to other adjacencies as well). Psenak, et al. Expires June 6, 2019 [Page 17] Internet-Draft OSPF Extensions for Segment Routing December 2018 P-Flag. Persistent flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap. Other bits: Reserved. These MUST be zero when sent and are ignored when received. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. MT-ID: Multi-Topology ID (as defined in [RFC4915]. Weight: Weight used for load-balancing purposes. The use of the weight is defined in [I-D.ietf-spring-segment-routing]. SID/Index/Label: as described in Section 5. An SR capable router MAY allocate an Adj-SID for each of its adjacencies and set the B-Flag when the adjacency is eligible for protection by an FRR mechanism (IP or MPLS) as described in section 3.5 of [I-D.ietf-spring-segment-routing]. An SR capable router MAY allocate more than one Adj-SID to an adjacency An SR capable router MAY allocate the same Adj-SID to different adjacencies When the P-flag is not set, the Adj-SID MAY be persistent. When the P-flag is set, the Adj-SID MUST be persistent. 6.2. LAN Adj-SID Sub-TLV LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. It is used to advertise a SID/Label for an adjacency to a non-DR router on a broadcast, NBMA, or hybrid [RFC6845] network. Psenak, et al. Expires June 6, 2019 [Page 18] Internet-Draft OSPF Extensions for Segment Routing December 2018 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | MT-ID | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +---------------------------------------------------------------+ where: Type: 3 Length: 11 or 12 octets, dependent on V-flag. Flags: same as in Section 6.1 Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. MT-ID: Multi-Topology ID (as defined in [RFC4915]. Weight: Weight used for load-balancing purposes. The use of the weight is defined in [I-D.ietf-spring-segment-routing]. Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- SID is advertised. SID/Index/Label: as described in Section 5. When the P-flag is not set, the Adj-SID MAY be persistent. When the P-flag is set, the Adj-SID MUST be persistent. 7. Elements of Procedure 7.1. Intra-area Segment routing in OSPFv2 An OSPFv2 router that supports segment routing MAY advertise Prefix- SIDs for any prefix to which it is advertising reachability (e.g., a loopback IP address as described in Section 5). A Prefix-SID can also be advertised by the SR Mapping Servers (as described in [I-D.ietf-spring-segment-routing-ldp-interop]). A Mapping Server advertises Prefix-SIDs for remote prefixes that exist in the OSPFv2 routing domain. Multiple Mapping Servers can advertise Psenak, et al. Expires June 6, 2019 [Page 19] Internet-Draft OSPF Extensions for Segment Routing December 2018 Prefix-SIDs for the same prefix, in which case the same Prefix-SID MUST be advertised by all of them. The flooding scope of the OSPF Extended Prefix Opaque LSA that is generated by the SR Mapping Server could be either area-scoped or AS-scoped and is determined based on the configuration of the SR Mapping Server. An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when advertising SIDs for prefixes. Prefixes of different route-types can be combined in a single OSPF Extended Prefix Range TLV advertised by an SR Mapping Server. Because the OSPF Extended Prefix Range TLV doesn't include a Route-Type field, as in the OSPF Extended Prefix TLV, it is possible to include adjacent prefixes from different Route-Types in the OSPF Extended Prefix Range TLV. Area-scoped OSPF Extended Prefix Range TLVs are propagated between areas. Similar to propagation of prefixes between areas, an ABR only propagates the OSPF Extended Prefix Range TLV that it considers to be the best from the set it received. The rules used to pick the best OSPF Extended Prefix Range TLV are described in Section 4. When propagating an OSPF Extended Prefix Range TLV between areas, ABRs MUST set the IA-Flag, that is used to prevent redundant flooding of the OSPF Extended Prefix Range TLV between areas as described in Section 4. 7.2. Inter-area Segment routing in OSPFv2 In order to support SR in a multi-area environment, OSPFv2 MUST propagate Prefix-SID information between areas. The following procedure is used to propagate Prefix SIDs between areas. When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area prefix to all its connected areas, it will also originate an Extended Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of the Extended Prefix Opaque LSA type will be set to area-local scope. The route-type in the OSPF Extended Prefix TLV is set to inter-area. The Prefix-SID Sub-TLV will be included in this LSA and the Prefix- SID value will be set as follows: The ABR will look at its best path to the prefix in the source area and find the advertising router associated with the best path to that prefix. The ABR will then determine if such router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connected areas. Psenak, et al. Expires June 6, 2019 [Page 20] Internet-Draft OSPF Extensions for Segment Routing December 2018 If no Prefix-SID was advertised for the prefix in the source area by the router that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to other areas. When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area route to all its connected areas, it will also originate an Extended Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of the Extended Prefix Opaque LSA type will be set to area-local scope. The route-type in OSPF Extended Prefix TLV is set to inter-area. The Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID will be set as follows: The ABR will look at its best path to the prefix in the backbone area and find the advertising router associated with the best path to that prefix. The ABR will then determine if such router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connected areas. If no Prefix-SID was advertised for the prefix in the backbone area by the ABR that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to other areas. 7.3. Segment Routing for External Prefixes Type-5 LSAs are flooded domain wide. When an ASBR, which supports SR, generates Type-5 LSAs, it SHOULD also originate Extended Prefix Opaque LSAs, as described in [RFC7684]. The flooding scope of the Extended Prefix Opaque LSA type is set to AS-wide scope. The route- type in the OSPF Extended Prefix TLV is set to external. The Prefix- SID Sub-TLV is included in this LSA and the Prefix-SID value will be set to the SID that has been reserved for that prefix. When an NSSA [RFC3101] ABR translates Type-7 LSAs into Type-5 LSAs, it SHOULD also advertise the Prefix-SID for the prefix. The NSSA ABR determines its best path to the prefix advertised in the translated Type-7 LSA and finds the advertising router associated with that path. If the advertising router has advertised a Prefix-SID for the prefix, then the NSSA ABR uses it when advertising the Prefix-SID for the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other router will be used. Psenak, et al. Expires June 6, 2019 [Page 21] Internet-Draft OSPF Extensions for Segment Routing December 2018 7.4. Advertisement of Adj-SID The Adjacency Segment Routing Identifier (Adj-SID) is advertised using the Adj-SID Sub-TLV as described in Section 6. 7.4.1. Advertisement of Adj-SID on Point-to-Point Links An Adj-SID MAY be advertised for any adjacency on a P2P link that is in neighbor state 2-Way or higher. If the adjacency on a P2P link transitions from the FULL state, then the Adj-SID for that adjacency MAY be removed from the area. If the adjacency transitions to a state lower then 2-Way, then the Adj-SID advertisement MUST be withdrawn from the area. 7.4.2. Adjacency SID on Broadcast or NBMA Interfaces Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented by a star topology where the Designated Router (DR) is the central point to which all other routers on the broadcast, NBMA, or hybrid network connect. As a result, routers on the broadcast, NBMA, or hybrid network advertise only their adjacency to the DR. Routers that do not act as DR do not form or advertise adjacencies with each other. They do, however, maintain 2-Way adjacency state with each other and are directly reachable. When Segment Routing is used, each router on the broadcast, NBMA, or hybrid network MAY advertise the Adj-SID for its adjacency to the DR using the Adj-SID Sub-TLV as described in Section 6.1. SR capable routers MAY also advertise a LAN-Adj-SID for other neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid network using the LAN-ADJ-SID Sub-TLV as described in Section 6.2. 8. IANA Considerations This specification updates several existing OSPF registries. 8.1. OSPF Router Information (RI) TLVs Registry o 8 (IANA Preallocated) - SR-Algorithm TLV o 9 (IANA Preallocated) - SID/Label Range TLV o 14 - SR Local Block TLV o 15 - SRMS Preference TLV Psenak, et al. Expires June 6, 2019 [Page 22] Internet-Draft OSPF Extensions for Segment Routing December 2018 8.2. OSPFv2 Extended Prefix Opaque LSA TLVs Registry Following values are allocated: o 2 - OSPF Extended Prefix Range TLV 8.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry Following values are allocated: o 1 - SID/Label Sub-TLV o 2 - Prefix SID Sub-TLV 8.4. OSPFv2 Extended Link TLV Sub-TLVs Registry Following initial values are allocated: o 1 - SID/Label Sub-TLV o 2 - Adj-SID Sub-TLV o 3 - LAN Adj-SID/Label Sub-TLV 8.5. IGP Algorithm Type Registry IANA is requested to set up a registry called "IGP Algorithm Type" under a new category of "Interior Gateway Protocol (IGP) Parameters" IANA registries. The registration policy for this registry is "Standards Action" ([RFC8126] and [RFC7120]). Values in this registry come from the range 0-255. The initial values in the IGP Algorithm Type registry are: 0: Shortest Path First (SPF) algorithm based on link metric. This is the standard shortest path algorithm as computed by the IGP protocol. Consistent with the deployed practice for link-state protocols, Algorithm 0 permits any node to overwrite the SPF path with a different path based on its local policy. 1: Strict Shortest Path First (SPF) algorithm based on link metric. The algorithm is identical to Algorithm 0 but Algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy at the node claiming support for Algorithm 1 MUST NOT alter the SPF paths computed by Algorithm 1. Psenak, et al. Expires June 6, 2019 [Page 23] Internet-Draft OSPF Extensions for Segment Routing December 2018 9. Implementation Status An implementation survey with seven questions related to the implementer's support of OSPFv2 Segment Routing was sent to the OSPF WG list and several known implementers. This section contains responses from three implementers who completed the survey. No external means were used to verify the accuracy of the information submitted by the respondents. The respondents are considered experts on the products they reported on. Additionally, responses were omitted from implementers who indicated that they have not implemented the function yet. This section will be removed before publication as an RFC. Responses from Nokia (former Alcatel-Lucent): Link to a web page describing the implementation: https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf The implementation's level of maturity: Production. Coverage: We have implemented all sections and have support for the latest draft. Licensing: Part of the software package that needs to be purchased. Implementation experience: Great spec. We also performed inter- operability testing with Cisco's OSPF Segment Routing implementation. Contact information: wim.henderickx@nokia.com Responses from Cisco Systems: Link to a web page describing the implementation: http://www.segment-routing.net/home/tutorial The implementation's level of maturity: Production. Coverage: All sections have been implemented according to the latest draft. Licensing: Part of a commercial software package. Implementation experience: Many aspects of the draft are result of the actual implementation experience, as the draft evolved from its Psenak, et al. Expires June 6, 2019 [Page 24] Internet-Draft OSPF Extensions for Segment Routing December 2018 initial version to the current one. Interoperability testing with Alcatel-Lucent was performed, which confirmed the draft's ability to serve as a reference for the implementors. Contact information: ppsenak@cisco.com Responses from Juniper: The implementation's name and/or a link to a web page describing the implementation: Feature name is OSPF SPRING The implementation's level of maturity: To be released in 16.2 (second half of 2016) Coverage: All sections implemented except Sections 4, and 6. Licensing: JUNOS Licensing needed. Implementation experience: NA Contact information: shraddha@juniper.net 10. Security Considerations With the OSPFv2 segment routing extensions defined herein, OSPFv2 will now program the MPLS data plane [RFC3031] in addition to the IP data plane. Previously, LDP [RFC5036] or another label distribution mechanism was required to advertise MPLS labels and program the MPLS data plane. In general, the same types of attacks that can be carried out on the IP control plane can be carried out on the MPLS control plane resulting in traffic being misrouted in the respective data planes. However, the latter can be more difficult to detect and isolate. Existing security extensions as described in [RFC2328] and [RFC7684] apply to these segment routing extensions. While OSPF is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC7474] SHOULD be used. Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv2 router or routing process. Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged for Psenak, et al. Expires June 6, 2019 [Page 25] Internet-Draft OSPF Extensions for Segment Routing December 2018 further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane. 11. Contributors The following people gave a substantial contribution to the content of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and Saku Ytti. 12. Acknowledgements We would like to thank Anton Smirnov for his contribution. Thanks to Acee Lindem for the detail review of the draft, corrections, as well as discussion about details of the encoding. 13. References 13.1. Normative References [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-ldp-interop] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment-routing-ldp-interop-15 (work in progress), September 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-15 (work in progress), October 2018. [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, . Psenak, et al. Expires June 6, 2019 [Page 26] Internet-Draft OSPF Extensions for Segment Routing December 2018 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC6845, January 2013, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . 13.2. Informative References [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- extensions-18 (work in progress), November 2018. [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, . Psenak, et al. Expires June 6, 2019 [Page 27] Internet-Draft OSPF Extensions for Segment Routing December 2018 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . Authors' Addresses Peter Psenak (editor) Cisco Systems, Inc. Apollo Business Center Mlynske nivy 43 Bratislava 821 09 Slovakia Email: ppsenak@cisco.com Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy Email: stefano@previdi.net Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Rob Shakir Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: robjs@google.com Psenak, et al. Expires June 6, 2019 [Page 28] Internet-Draft OSPF Extensions for Segment Routing December 2018 Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 BE Email: wim.henderickx@nokia.com Jeff Tantsura Apstra, Inc. Email: jefftant.ietf@gmail.com Psenak, et al. Expires June 6, 2019 [Page 29] ./draft-ietf-sipbrandy-rtpsec-08.txt0000644000764400076440000010477113460440346016667 0ustar iustyiusty Network Working Group J. Peterson Internet-Draft Neustar Intended status: Best Current Practice R. Barnes Expires: October 27, 2019 Cisco R. Housley Vigil Security April 25, 2019 Best Practices for Securing RTP Media Signaled with SIP draft-ietf-sipbrandy-rtpsec-08 Abstract Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities. 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 https://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 27, 2019. Copyright Notice Copyright (c) 2019 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 Peterson, et al. Expires October 27, 2019 [Page 1] Internet-Draft RTP Security April 2019 (https://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. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 4. STIR Profile for Endpoint Authentication and Verification Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7 4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] includes a suite of security services, including Digest authentication, for authenticating entities with a shared secret, TLS for transport security, and S/MIME (optionally) for body security. SIP is frequently used to establish media sessions, in particular audio or audiovisual sessions, which have their own security mechanisms available, such as Secure RTP [RFC3711]. However, the practices needed to bind security at the media layer to security at the SIP layer, to provide an assurance that protection is in place all the way up the stack, rely on a great many external security mechanisms and practices. This document provides documentation to explain their optimal use as a best practice. Revelations about widespread pervasive monitoring of the Internet have led to a greater desire to protect Internet communications Peterson, et al. Expires October 27, 2019 [Page 2] Internet-Draft RTP Security April 2019 [RFC7258]. In order to maximize the use of security features, especially of media confidentiality, opportunistic measures serve as a stopgap when a full suite of services cannot be negotiated all the way up the stack. Opportunistic media security for SIP is described in [I-D.ietf-sipbrandy-osrtp], which builds on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. With opportunistic encryption, there is an attempt to negotiate the use of encryption, but if the negotiation fails, then cleartext is used. Opportunistic encryption approaches typically have no integrity protection for the keying material. This document contains the SIPBRANDY profile of STIR [RFC8224] for media confidentiality, providing a comprehensive security solution for SIP media that includes integrity protection for keying material and offers application-layer assurance that media confidentiality is place. Various specifications that user agents must implement to support media confidentiality are given in the sections below; a summary of the best current practices appears in Section 8. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Security at the SIP and SDP layer There are two approaches to providing confidentiality for media sessions set up with SIP: comprehensive protection and opportunistic security (as defined in [RFC7435]). This document only addresses comprehensive protection. Comprehensive protection for media sessions established by SIP requires the interaction of three protocols: Session Initiation Protocol (SIP) [RFC3261], the Session Description Protocol (SDP) [RFC4566], and the Real-time Protocol (RTP) [RFC3550], in particular its secure profile Secure RTP (SRTP) [RFC3711]. Broadly, it is the responsibility of SIP to provide integrity protection for the media keying attributes conveyed by SDP, and those attributes will in turn identify the keys used by endpoints in the RTP media session(s) that SDP negotiates. Note that this framework does not apply to keys that also require confidentiality protection in the signaling layer, such as the SDP "k=" line, which MUST NOT be used in conjunction with this profile. Peterson, et al. Expires October 27, 2019 [Page 3] Internet-Draft RTP Security April 2019 In that way, once SIP and SDP have exchanged the necessary information to initiate a session, media endpoints will have a strong assurance that the keys they exchange have not been tampered with by third parties, and that end-to-end confidentiality is available. To establishing the identity of the endpoints of a SIP session, this specification uses STIR [RFC8224]. The STIR Identity header has been designed to prevent a class of impersonation attacks that are commonly used in robocalling, voicemail hacking, and related threats. STIR generates a signature over certain features of SIP requests, including header field values that contain an identity for the originator of the request, such as the From header field or P- Asserted-Identity field, and also over the media keys in SDP if they are present. As currently defined, STIR provides a signature over the "a=fingerprint" attribute, which is a fingerprint of the key used by DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive protection for SIP sessions in concert with SDP and SRTP when DTLS- SRTP is the media security service. The underlying PASSporT [RFC8225] object used by STIR is extensible, however, and it would be possible to provide signatures over other SDP attributes that contain alternate keying material. A profile for using STIR to provide media confidentiality is given in Section 4. 4. STIR Profile for Endpoint Authentication and Verification Services STIR [RFC8224] defines the Identity header field for SIP, which provides a cryptographic attestation of the source of communications. This document includes a profile of STIR, called the SIPBRANDY profile, where the STIR verification service will act in concert with an SRTP media endpoint to ensure that the key fingerprints, as given in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy this condition, the verification service function would in this case be implemented in the SIP User Agent Server (UAS), which would be composed with the media endpoint. If the STIR authentication service or verification service functions are implemented at an intermediary rather than an endpoint, this introduces the possibility that the intermediary could act as a man in the middle, altering key fingerprints. As this attack is not in STIR's core threat model, which focuses on impersonation rather than man-in-the-middle attacks, STIR offers no specific protections against such interference. The SIPBRANDY profile for media confidentiality thus shifts these responsibilities to the endpoints rather than the intermediaries. While intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions, the verification needs to be repeated at the endpoint to obtain end-to-end assurance. Intermediaries supporting this specification MUST NOT block or otherwise redirect calls if they do not trust the signing credential. Peterson, et al. Expires October 27, 2019 [Page 4] Internet-Draft RTP Security April 2019 The SIPBRANDY profile is based on an end-to-end trust model, so it is up to the endpoints to determine if they support signing credentials, not intermediaries. In order to be compliant with best practices for SIP media confidentiality with comprehensive protection, user agent implementations MUST implement both the authentication service and verification service roles described in [RFC8224]. STIR authentication services MUST signal their compliance with this specification by including the "msec" claim defined in this specification to the PASSporT payload. Implementations MUST provide key fingerprints in SDP and the appropriate signatures over them as specified in [RFC8225]. When generating either an offer or an answer [RFC3264], compliant implementations MUST include an "a=fingerprint" attribute containing the fingerprint of an appropriate key (see Section 4.1). 4.1. Credentials In order to implement the authentication service function in the user agent, SIP endpoints will need to acquire the credentials needed to sign for their own identity. That identity is typically carried in the From header field of a SIP request, and either contains a greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone number, which can appear in a variety of ways (e.g. "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224] contains guidance for separating the two, and determining what sort of credential is needed to sign for each. To date, few commercial certification authorities (CAs) issue certificates for SIP URIs or telephone numbers; though work is ongoing on systems for this purpose (such as [I-D.ietf-acme-authority-token]) it is not yet mature enough to be recommended as a best practice. This is one reason why STIR permits intermediaries to act as an authentication service on behalf of an entire domain, just as in SIP a proxy server can provide domain-level SIP service. While CAs that offer proof-of-possession certificates similar to those used for email could be offered for SIP, either for greenfield identifiers or for telephone numbers, this specification does not require their use. For users who do not possess such certificates, DTLS-SRTP [RFC5763] permits the use of self-signed public keys. This profile of STIR employs more relaxed authority requirements of [RFC8224] to allow the use of self-signed public keys for authentication services that are composed with user agents, by generating a certificate (per the guidance in [RFC8226]) with a subject corresponding to the user's Peterson, et al. Expires October 27, 2019 [Page 5] Internet-Draft RTP Security April 2019 identity. To obtain comprehensive protection with a self-signed certificate, some out-of-band verification is needed as well. Such a credential could be used for trust on first use (see [RFC7435]) by relying parties. Note that relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for self-signed certificates as they will not increase confidence in the certificate. Users who wish to remain anonymous can instead generate self-signed certificates as described in Section 4.2. Generally speaking, without access to out-of-band information about which certificates were issued to whom, it will be very difficult for relying parties to ascertain whether or not the signer of a SIP request is genuinely an "endpoint." Even the term "endpoint" is a problematic one, as SIP user agents can be composed in a variety of architectures and may not be devices under direct user control. While it is possible that techniques based on certificate transparency [RFC6962] or similar practices could help user agents to recognize one another's certificates, those operational systems will need to ramp up with the CAs that issue credentials to end user devices going forward. 4.2. Anonymous Communications In some cases, the identity of the initiator of a SIP session may be withheld due to user or provider policy. Following the recommendations of [RFC3323], this may involve using an identity such as "anonymous@anonymous.invalid" in the identity fields of a SIP request. [RFC8224] does not currently permit authentication services to sign for requests that supply this identity. It does however permit signing for valid domains, such as "anonymous@example.com," as a way of implementation an anonymization service as specified in [RFC3323]. Even for anonymous sessions, providing media confidentiality and partial SDP integrity is still desirable. This specification RECOMMENDS using one-time self-signed certificates for anonymous communications, with a subjectAltName of "sip:anonymous@anonymous.invalid". After a session is terminated, the certificate SHOULD be discarded, and a new one, with fresh keying material, SHOULD be generated before each future anonymous call. As with self-signed certificates, relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for anonymous certificates as they will not increase confidence in the certificate. Peterson, et al. Expires October 27, 2019 [Page 6] Internet-Draft RTP Security April 2019 Note that when using one-time anonymous self-signed certificates, any man in the middle could strip the Identity header and replace it with one signed by its own one-time certificate, changing the "mkey" parameters of PASSporT and any "a=fingerprint" attributes in SDP as it chooses. This signature only provides protection against non- Identity aware entities that might modify SDP without altering the PASSporT conveyed in the Identity header. 4.3. Connected Identity Usage STIR [RFC8224] provides integrity protection for the fingerprint attributes in SIP request bodies, but not SIP responses. When a session is established, therefore, any SDP body carried by a 200 class response in the backwards direction will not be protected by an authentication service and cannot be verified. Thus, sending a secured SDP body in the backwards direction will require an extra RTT, typically a request sent in the backwards direction. The problem of providing "Connected Identity" in [RFC4474], which is obsoleted by STIR, was explored in [RFC4916], which uses a provisional or mid-dialog UPDATE request in the backwards direction to convey an Identity header field for the recipient of an INVITE. The procedures in that specification are largely compatible with the revision of the Identity header in STIR [RFC8224]. However, the following need to be considered: The UPDATE carrying signed SDP with a fingerprint in the backwards direction needs to be sent during dialog establishment, following the receipt of a PRACK after a provisional 1xx response. For use with this SIPBRANDY profile for media confidentiality, the UAS that responds to the INVITE request needs to act as an authentication service for the UPDATE sent in the backwards direction. The text in Section 4.4.1 of [RFC4916] regarding the receipt at a UAC of error codes 428, 436, 437 and 438 in response to a mid- dialog request RECOMMENDS treating the dialog as terminated. However, Section 6.1.1 of [RFC8224] allows the retransmission of requests with repairable error conditions. In particular, an authentication service might retry a mid-dialog rather than treating the dialog as terminated, although only one such retry is permitted. Note that the examples in [RFC4916] are based on the original [RFC4474], and will not match signatures using STIR [RFC8224]. Peterson, et al. Expires October 27, 2019 [Page 7] Internet-Draft RTP Security April 2019 Future work may be done to revise [RFC4916] for STIR; that work should take into account any impacts on the SIPBRANDY profile described in this document. The use of [RFC4916] has some further interactions with ICE; see Section 7. 4.4. Authorization Decisions [RFC8224] grants STIR verification services a great deal of latitude when making authorization decisions based on the presence of the Identity header field. It is largely a matter of local policy whether an endpoint rejects a call based on absence of an Identity header field, or even the presence of a header that fails an integrity check against the request. For this SIPBRANDY profile of STIR, however, a compliant verification service that receives a dialog-forming SIP request containing an Identity header with a PASSporT type of "msec", after validating the request per the steps described in Section 6.2 of [RFC8224], MUST reject the request if there is any failure in that validation process with the appropriate status code per Section 6.2.2. If the request is valid, then if a terminating user accepts the request, it MUST then follow the steps in Section 4.3 to act as an authentication service and send a signed request with the "msec" PASSPorT type in its Identity header as well, in order to enable end-to-end bidirectional confidentiality. For the purposes of this profile, the "msec" PASSporT type can be used by authentication services in one of two ways: as a mandatory request for media security, or as a merely opportunistic request for media security. As any verification service that receives an Identity header field in a SIP request with an unrecognized PASSporT type will simply ignore that Identity header, an authentication service will know whether or not the terminating side supports "msec" based on whether or not its user agent receives a signed request in the backwards direction per Section 4.3. If no such requests are received, the UA may do one or two things: shut down the dialog, if the policy of the UA requires that "msec" be supported by the terminating side for this dialog; or, if policy permits (e.g., an explicit acceptance by the user), allow the dialog to continue without media security. 5. Media Security Protocols As there are several ways to negotiate media security with SDP, any of which might be used with either opportunistic or comprehensive protection, further guidance to implementers is needed. In [I-D.ietf-sipbrandy-osrtp], opportunistic approaches considered Peterson, et al. Expires October 27, 2019 [Page 8] Internet-Draft RTP Security April 2019 include DTLS-SRTP, security descriptions [RFC4568], and ZRTP [RFC6189]. Support for DTLS-SRTP is REQUIRED by this specification. The "mkey" claim of PASSporT provides integrity protection for "a=fingerprint" attributes in SDP, including cases where multiple "a=fingerprint" attributes appear in the same SDP. 6. Relayed Media and Conferencing Providing end-to-end media confidentiality for SIP is complicated by the presence of many forms of media relays. While many media relays merely proxy media to a destination, others present themselves as media endpoints and terminate security associations before re- originating media to its destination. Centralized conference bridges are one type of entity that typically terminates a media session in order to mux media from multiple sources and then to re-originate the muxed media to conference participants. In many such implementations, only hop-by-hop media confidentiality is possible. Work is ongoing to specify a means to encrypt both the hop-by-hop media between a user agent and a centralized server as well as the end-to-end media between user agents, but is not sufficiently mature at this time to make a recommendation for a best practice here. Those protocols are expected to identify their own best practice recommendations as they mature. Another class of entities that might relay SIP media are back-to-back user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], it may be possible for those devices to act as media relays while still permitting end-to-end confidentiality between user agents. Ultimately, if an endpoint can decrypt media it receives, then that endpoint can forward the decrypted media without the knowledge or consent of the media's originator. No media confidentiality mechanism can protect against these sorts of relayed disclosures, or trusted entities that can decrypt media and then record a copy to be sent elsewhere (see [RFC7245]). 7. ICE and Connected Identity Providing confidentiality for media with comprehensive protection requires careful timing of when media streams should be sent and when a user interface should signify that confidentiality is in place. Peterson, et al. Expires October 27, 2019 [Page 9] Internet-Draft RTP Security April 2019 In order to best enable end-to-end connectivity between user agents, and to avoid media relays as much as possible, implementations of this specification MUST support ICE [RFC8445]. To speed up call establishment, it is RECOMMENDED that implementations support trickle ICE [I-D.ietf-mmusic-trickle-ice-sip]. Note that in the comprehensive protection case, the use of Connected Identity [RFC4916] with ICE entails that the answer containing the key fingerprints, and thus the STIR signature, will come in an UPDATE sent in the backwards direction, a provisional response, and a provisional acknowledgment (PRACK), rather than in any earlier SDP body. Only at such a time as that UPDATE is received will the media keys be considered exchanged in this case. Similarly, in order to prevent, or at least mitigate, the denial-of- service attack described in Section 19.5.1 of [RFC8445], this specification incorporates best practices for ensuring that recipients of media flows have consented to receive such flows. Implementations of this specification MUST implement the STUN usage for consent freshness defined in [RFC7675]. 8. Best Current Practices The following are the best practices for SIP user agents to provide media confidentiality for SIP sessions. Implementations MUST support the STIR endpoint profile given in Section 4, and signal that in PASSporT with the "msec" header element. Implementations MUST follow the authorization decision behavior in Section 4.4. Implementations MUST support DTLS-SRTP for key-management, as described in Section 5. Implementations MUST support the ICE, and the STUN consent freshness mechanism, as specified in Section 7. 9. IANA Considerations This specification defines a new value for the Personal Assertion Token (PASSporT) Extensions registry called "msec," and the IANA is requested to add that entry to the registry with a value pointing to [RFCThis]. Peterson, et al. Expires October 27, 2019 [Page 10] Internet-Draft RTP Security April 2019 10. Security Considerations This document describes the security features that provide media sessions established with SIP with confidentiality, integrity, and authentication. 11. Acknowledgments We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell for contributions to this problem statement and framework. We thank Liang Xia and Alissa Cooper for their careful review. 12. References 12.1. Normative References [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", draft-ietf- mmusic-trickle-ice-sip-18 (work in progress), June 2018. [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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 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, . Peterson, et al. Expires October 27, 2019 [Page 11] Internet-Draft RTP Security April 2019 [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, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 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, . [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, . [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, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . Peterson, et al. Expires October 27, 2019 [Page 12] Internet-Draft RTP Security April 2019 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 12.2. Informative References [I-D.ietf-acme-authority-token] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Challenges Using an Authority Token", draft-ietf-acme- authority-token-03 (work in progress), March 2019. [I-D.ietf-sipbrandy-osrtp] Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. Stach, "An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-08 (work in progress), March 2019. [I-D.kaplan-mmusic-best-effort-srtp] Audet, F. and H. Kaplan, "Session Description Protocol (SDP) Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport Protocol", draft-kaplan-mmusic-best- effort-srtp-01 (work in progress), October 2006. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, . [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, . Peterson, et al. Expires October 27, 2019 [Page 13] Internet-Draft RTP Security April 2019 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [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, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . Authors' Addresses Jon Peterson Neustar, Inc. Email: jon.peterson@team.neustar Richard Barnes Cisco Email: rlb@ipv.sx Russ Housley Vigil Security, LLC Email: housley@vigilsec.com Peterson, et al. Expires October 27, 2019 [Page 14] ./draft-ietf-ospf-xaf-te-07.txt0000644000764400076440000004562013525536510015524 0ustar iustyiusty LSR A. Smirnov Internet-Draft Cisco Systems, Inc. Updates: 5786 (if approved) A. Retana Intended status: Standards Track Futurewei Technologies, Inc. Expires: February 16, 2020 M. Barnes August 15, 2019 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels draft-ietf-ospf-xaf-te-07 Abstract When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross- address family (X-AF) OSPF TE information. This document describes an update to RFC5786 that allows for the easy identification of a router's local X-AF IP addresses. 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 https://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 16, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Smirnov, et al. Expires February 16, 2020 [Page 1] Internet-Draft OSPF Routing with Cross-AF TE tunnels August 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Language . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 4.1. Automatically Switched Optical Networks . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been described to support intra-area TE in IPv4 and IPv6 networks, respectively. In both cases, the TE database provides a tight coupling between the routed protocol and advertised TE signaling information. In other words, any use of the TE database is limited to IPv4 for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340]. In a dual stack network, it may be desirable to set up common MPLS TE LSPs to carry traffic destined to addresses from different address families on a router. The use of common LSPs eases potential scalability and management concerns by halving the number of LSPs in the network. Besides, it allows operators to group traffic based on business characteristics and/or applications or class of service, not constrained by the network protocol used. For example, an LSP created based on MPLS TE information propagated by an OSPFv2 instance can be used to transport both IPv4 and IPv6 traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a separate LSP for each address family. Even if in some cases the address family-specific traffic is to be separated, calculation from a common TE database may prove to be operationally beneficial. Smirnov, et al. Expires February 16, 2020 [Page 2] Internet-Draft OSPF Routing with Cross-AF TE tunnels August 2019 During the SPF calculation on the TE tunnel head-end router, OSPF computes shortcut routes using TE tunnels. A commonly used algorithm for computing shortcuts is defined in [RFC3906]. For that, or any similar, algorithm to work with a common MPLS TE infrastructure in a dual-stack network, a requirement is to reliably map the X-AF addresses to the corresponding tail-end router. This mapping is a challenge because the LSAs containing the routing information are carried in one OSPF instance while the TE calculations may be done using a TE database from a different OSPF instance. A simple solution to this problem is to rely on the Router ID to identify a node in the corresponding OSPFv2 and OSPFv3 link state databases (LSDBs). This solution would mandate both instances on the same router to be configured with the same Router ID. However, relying on the correctness of configuration puts additional burden and cost on the operation of the network. The network becomes even more difficult to manage if OSPFv2 and OSPFv3 topologies do not match exactly, for example if area borders are chosen differently in the two protocols. Also, if the routing processes do fall out of sync (e.g., having different Router IDs for local administrative reasons), there is no defined way for other routers to discover such misalignment and to take corrective measures (such as to avoid routing traffic through affected TE tunnels or alerting the network administrators). The use of misaligned Router IDs may result in delivering the traffic to the wrong tail-end router, which could lead to suboptimal routing or even traffic loops. This document describes an update to [RFC5786] that allows for the easy identification of a router's local X-AF IP addresses. [RFC5786] defined the Node IPv4 Local Address and Node IPv6 Local Address sub- TLVs of the Node Attribute TLV for a router to advertise additional local IPv4 and IPv6 addresses. However, [RFC5786] did not describe the advertisement and usage of these sub-TLVs when the address family of the advertised local address differed from the address family of the OSPF traffic engineering protocol. This document updates [RFC5786] so that a router can also announce one or more local X-AF addresses using the corresponding Local Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can include non-TE enabled interface addresses in their OSPF TE advertisements, and also use the same sub-TLVs to carry X-AF information, facilitating the mapping described above. The method specified in this document can also be used to compute the X-AF mapping of the egress Label Switching Router (LSR) for sub-LSPs of a Point-to-Multipoint LSP [RFC4461]. Considerations of using Point-to-Multipoint MPLS TE for X-AF traffic forwarding is outside the scope of this document. Smirnov, et al. Expires February 16, 2020 [Page 3] Internet-Draft OSPF Routing with Cross-AF TE tunnels August 2019 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Operation To implement the X-AF routing technique described in this document, OSPFv2 will advertise the Node IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4 Local Address sub-TLV, possibly in addition to advertising other IP addresses as documented by [RFC5786]. Multiple instances of OSPFv3 are needed if it is used for both IPv4 and IPv6 [RFC5838]. The operation in this section is described with OSPFv2 as the protocol used for IPv4; that is the most common case. The case of OSPFv3 being used for IPv4 follows the same procedure as what is indicated for OSPFv2 below. On a node that implements X-AF routing, each OSPF instance advertises, using the Node Local Address sub-TLV, all X-AF IPv6 (for OSPFv2 instance) or IPv4 (for OSPFv3) addresses local to the router that can be used by Constrained SPF (CSPF) to calculate MPLS TE LSPs: OSPF instance MUST advertise the IP address listed in the Router Address TLV [RFC3630], [RFC5329] of the X-AF instance maintaining the TE database. OSPF instance SHOULD include additional local addresses advertised by the X-AF OSPF instance in its Node Local Address sub-TLVs. An implementation MAY advertise other local X-AF addresses. When TE information is advertised in an OSPF instance both natively (i.e. as per RFC [RFC3630] or [RFC5329]) and as XAF Node Attribute TLV it is left to local configuration to determine which TE database is used to compute routes for the OSPF instance. On Area Border Routers (ABR), each advertised X-AF IP address MUST be advertised into at most one area. If OSPFv2 and OSPFv3 area border routers coincide (i.e., the areas for all OSPFv2 and OSPFv3 interfaces are the same), then the X-AF addresses MUST be advertised into the same area in both instances. This allows other ABRs connected to the same set of areas to know with which area to associate computed MPLS TE tunnels. Smirnov, et al. Expires February 16, 2020 [Page 4] Internet-Draft OSPF Routing with Cross-AF TE tunnels August 2019 During the X-AF routing calculation, X-AF IP addresses are used to map locally created LSPs to tail-end routers in the Link State Database (LSDB). The mapping algorithm can be described as: Walk the list of all MPLS TE tunnels for which the computing router is a head-end. For each MPLS TE tunnel T: 1. If T's destination address is from the same address family as the OSPF instance associated with the LSDB, then the extensions defined in this document do not apply. 2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination IP address. 3. Walk the X-AF IP addresses in the LSDBs of all connected areas. If a matching IP address is found, advertised by router R in area A, then mark the tunnel T as belonging to area A and terminating on tail-end router R. Assign the intra-area SPF cost to reach router R within area A as the IGP cost of tunnel T. After completing this calculation, each TE tunnel is associated with an area and tail-end router in terms of the routing LSDB of the computing OSPF instance and has a cost. The algorithm described above is to be used only if Node Local Address sub-TLV include X-AF information. Note that for clarity of description the mapping algorithm is specified as a single calculation. Actual implementations for the efficiency may choose to support equivalent mapping functionality without implementing the algorithm exactly as it is described. As an example, consider a router in a dual-stack network respectively using OSPFv2 and OSPFv3 for IPv4 and IPv6 routing. Suppose the OSPFv2 instance is used to propagate MPLS TE information and the router is configured to accept TE LSPs terminating at local addresses 198.51.100.1 and 198.51.100.2. The router advertises in OSPFv2 the IPv4 address 198.51.100.1 in the Router Address TLV, the additional local IPv4 address 198.51.100.2 in the Node IPv4 Local Address sub- TLV, and other Traffic Engineering TLVs as required by [RFC3630]. If the OSPFv3 instance in the network is enabled for X-AF TE routing (that is, to use MPLS TE LSPs computed by OSPFv2 for IPv6 routing), then the OSPFv3 instance of the router will advertise the Node IPv4 Local Address sub-TLV listing the local IPv4 addresses 198.51.100.1 and 198.51.100.2. Other routers in the OSPFv3 network will use this information to reliably identify this router as the egress LSR for MPLS TE LSPs terminating at either 198.51.100.1 or 198.51.100.2. Smirnov, et al. Expires February 16, 2020 [Page 5] Internet-Draft OSPF Routing with Cross-AF TE tunnels August 2019 4. Backward Compatibility Only routers that serve as endpoints for one or more TE tunnels MUST be upgraded to support the procedures described herein: o Tunnel tailend routers advertise the Node IPv4 Local Address sub- TLV and/or the Node IPv6 Local Address sub-TLV. o Tunnel headend routers perform the X-AF routing calculation. Both the endpoints MUST be upgraded before the tailend starts advertising the X-AF information. Other routers in the network do not need to support X-AF procedures. 4.1. Automatically Switched Optical Networks [RFC6827] updates [RFC5786] by defining extensions to be used in an Automatically Switched Optical Network (ASON). The Local TE Router ID Sub-TLV is required for determining ASON reachability. The implication is that if the Local TE Router ID Sub-TLV is present in the Node Attribute TLV, then the procedures in [RFC6827] apply, regardless of whether any X-AF information is advertised. 5. Security Considerations This document describes the use of the Local Address sub-TLVs to provide X-AF information. The advertisement of these sub-TLVs, in any OSPF instance, is not precluded by [RFC5786]. As such, no new security threats are introduced beyond the considerations in OSPFv2 [RFC2328], OSPFv3 [RFC5340], and [RFC5786]. The X-AF information is not used for SPF computation or normal routing, so the mechanism specified here has no effect on IP routing. However, generating incorrect information, or tampering with the sub- TLVs may have an effect on traffic engineering computations. Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing, traffic loops, or even expose the traffic to attacker inspection or modification. These threats are already present in other TE-related specifications, and their considerations apply here as well, including [RFC3630] and [RFC5329]. 6. IANA Considerations This document has no IANA actions. Smirnov, et al. Expires February 16, 2020 [Page 6] Internet-Draft OSPF Routing with Cross-AF TE tunnels August 2019 7. Acknowledgements The authors would like to thank Peter Psenak and Eric Osborne for early discussions and Acee Lindem for discussing compatibility with ASON extensions. Also, Eric Vyncke, Ben Kaduk and Roman Danyliw provided useful comments. We would also like to thank the authors of RFC5786 for laying down the foundation for this work. 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, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels", RFC 3906, DOI 10.17487/RFC3906, October 2004, . Smirnov, et al. Expires February 16, 2020 [Page 7] Internet-Draft OSPF Routing with Cross-AF TE tunnels August 2019 [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, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, . [RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, Ed., "Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols", RFC 6827, DOI 10.17487/RFC6827, January 2013, . Authors' Addresses Anton Smirnov Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium Email: as@cisco.com Alvaro Retana Futurewei Technologies, Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Email: alvaro.retana@futurewei.com Michael Barnes Email: michael_barnes@usa.net Smirnov, et al. Expires February 16, 2020 [Page 8] ./draft-ietf-softwire-yang-16.txt0000644000764400076440000027763713424026344016205 0ustar iustyiusty Softwire Working Group I. Farrer, Ed. Internet-Draft Deutsche Telekom AG Intended status: Standards Track M. Boucadair, Ed. Expires: August 2, 2019 Orange January 29, 2019 YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires draft-ietf-softwire-yang-16 Abstract This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms. Editorial Note (To be removed by RFC Editor) Please update these statements within this document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port Softwires"; o "reference: RFC XXXX" Please update the "revision" date of the YANG modules. 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 https://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 2, 2019. Farrer & Boucadair Expires August 2, 2019 [Page 1] Internet-Draft YANG Modules for A+P Softwires January 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Overview of the Modules . . . . . . . . . . . . . . . . . . . 4 3.1. Overall Structure . . . . . . . . . . . . . . . . . . . . 4 3.2. Additional Components Configuration . . . . . . . . . . . 5 4. Softwire CE YANG Tree Diagram . . . . . . . . . . . . . . . . 5 4.1. CE Tree Diagram . . . . . . . . . . . . . . . . . . . . . 5 4.2. Softwire CE Tree Diagram Description . . . . . . . . . . 7 5. Softwire BR YANG Tree Diagram . . . . . . . . . . . . . . . . 8 5.1. BR Tree Diagram . . . . . . . . . . . . . . . . . . . . . 9 5.2. Softwire BR Tree Diagram Description . . . . . . . . . . 12 6. Softwire CE YANG Module . . . . . . . . . . . . . . . . . . . 13 7. BR Softwire YANG Module . . . . . . . . . . . . . . . . . . . 18 8. Common Softwire Element Groups YANG Module . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 42 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 14.1. Normative References . . . . . . . . . . . . . . . . . . 43 14.2. Informative References . . . . . . . . . . . . . . . . . 44 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 46 A.1. Configuration Example for a lw4o6 BR Binding-Table . . . 46 A.2. Configuration Example for a MAP-E BR . . . . . . . . . . 47 A.3. lw4o6 CE Configuration Example . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Farrer & Boucadair Expires August 2, 2019 [Page 2] Internet-Draft YANG Modules for A+P Softwires January 2019 1. Introduction The IETF Softwire working group has developed several IPv4-in-IPv6 softwire mechanisms to address various deployment contexts and constraints. As a companion to the architectural specification documents, this document focuses on the provisioning of address plus port (A+P) softwire functional elements: Border Routers (BRs) and Customer Premises Equipment (CEs, a.k.a., CPE). The softwire mechanisms covered in this document are Lightweight 4 over 6 (lw4o6) [RFC7596], Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], and Mapping of Address and Port using Translation (MAP-T) [RFC7599]. This document focuses on A+P mechanisms [RFC6346]; the reader can refer to [RFC8513] for a YANG module for DS-Lite [RFC6333]. This document defines YANG modules [RFC7950] that can be used to configure and manage A+P softwire elements using the NETCONF [RFC6241], or RESTCONF [RFC8040] protocols for: o Configuration o Operational State o Notifications 2. Terminology The reader should be familiar with the concepts and terms defined in [RFC7596], [RFC7597], [RFC7599], and the YANG data modelling language defined in [RFC7950]. The YANG modules in this document adopt the Network Management Datastore Architecture (NMDA) [RFC8342]. The meanings of the symbols used in tree diagrams are defined in [RFC8340]. The document uses the abbrieviation 'BR' as a general term for softwire tunnel concentrators, including both MAP Border Routers [RFC7597] and Lightweight 4over6 lWAFTRs [RFC7596]. For brevity, "algorithm" is used to refer to the "mapping algorithm" defined in [RFC7597]. A network element may support one or multiple instances of a softwire mechanism; each of these instances (i.e., binding instances, MAP-E instances, or MAP-T instances) may have its own configuration and parameters. The term 'algo-instance' is used to denote both MAP-E and MAP-T instances. Farrer & Boucadair Expires August 2, 2019 [Page 3] Internet-Draft YANG Modules for A+P Softwires January 2019 3. Overview of the Modules 3.1. Overall Structure The document defines the following two YANG modules for the configuration and monitoring of softwire functional elements: ietf-softwire-ce Provides configuration and monitoring for softwire CE element. This module is defined as augments to the interface YANG module [RFC8343]. ietf-softwire-br Provides configuration and monitoring for softwire BR element. In addition, the following module is defined: ietf-softwire-common Contains groups of common functions that are imported into the CE and BR modules. This approach has been taken so that the various modules can be easily extended to support additional softwire mechanisms, if required. Within the BR and CE modules, the YANG "feature" statement is used to distinguish which of the different softwire mechanism(s) is relevant for a specific element's configuration. For each module, a choice statement 'ce-type' is included for either 'binding' or 'algorithm'. 'Binding' is used for configuring Lightweight 4over6, whereas 'algorithm' is used for configuring MAP-T or MAP-E. In the 'algo-instances' container, a choice statement 'data-plane' is included to specify MAP-E (encapsulation) or MAP-T (translation). Table 1 shows how these choices are used to indicate the desired softwire mechanism: +--------------------+-----------+---------------+ | S46 Mechanism | ce-type? | data-plane? | +--------------------+-----------+---------------+ | Lightweight 4over6 | binding | n/a | | MAP-E | algorithm | encapsulation | | MAP-T | algorithm | translation | +--------------------+-----------+---------------+ Table 1: Softwire Mechanism Choice Statement Enumeration NETCONF notifications are also included. Farrer & Boucadair Expires August 2, 2019 [Page 4] Internet-Draft YANG Modules for A+P Softwires January 2019 Note: Earlier versions of this specification combined the softwire mechanisms by their associated technologies rather than their function in the architecture. As the document was revised, it became apparent that dividing the modules by their role in the architecture (CE or BR) was a better approach as this follows the intended function and existing implementation approaches more closely. 3.2. Additional Components Configuration The softwire modules only aim to provide configuration relevant for softwires. In order to fully provision a CE element, the following may also be necessary: o IPv6 forwarding and routing configuration, enabling the CE to obtain one or more IPv6 prefixes for softwire usage. A YANG module for routing management is described in [RFC8349]. o IPv4 routing configuration, to add one or more IPv4 destination prefix(es) reachable via the configured softwire. A YANG module for routing management is described in [RFC8349]. o Stateful NAT44/NAPT management, to optionally specify a port set (Port Set Identifier (PSID)) along with its length. A YANG module for NAT management is described in [RFC8512]. o Stateless NAT46 management, required by softwire translation based mechanisms (i.e., the assignment of a Network-Specific Prefix to use for IPv4/IPv6 translation). A YANG module for NAT management is described in [RFC8512]. As YANG modules for the above functions are already defined in other documents, their functionality is not duplicated here and they should be referred to, as needed. Appendix A.3 provides XML examples of how these modules can be used together. The CE must already have minimal IPv6 configuration in place so it is reachable by the NETCONF client to obtain softwire configuration. If additional IPv6 specific configuration is necessary, the YANG modules defined in [RFC8344] and [RFC8349] may be used. 4. Softwire CE YANG Tree Diagram 4.1. CE Tree Diagram The CE module provides configuration and monitoring for all of the softwire mechanisms covered in this document (i.e., Lightweight 4over6, MAP-E, and MAP-T). Farrer & Boucadair Expires August 2, 2019 [Page 5] Internet-Draft YANG Modules for A+P Softwires January 2019 This module augments "ietf-interfaces", defined in [RFC8343] with an entry for the softwire. This entry can be referenced to configure IPv4 forwarding features for the element. This entry is added only if tunnel type (Section 10) is set to 'aplusp'. Figure 1 shows the tree structure of the softwire CE YANG module: module: ietf-softwire-ce augment /if:interfaces/if:interface: +--rw softwire-payload-mtu? uint16 +--rw softwire-path-mru? uint16 +--rw (ce-type)? +--:(binding) {binding-mode}? | +--rw binding-ipv6info? union | +--rw br-ipv6-addr inet:ipv6-address +--:(algo) {map-e or map-t}? +--rw algo-instances +--rw algo-instance* [name] +--rw name string +--rw enable? boolean +--rw algo-versioning | +--rw version? uint64 | +--rw date? yang:date-and-time +--rw (data-plane)? | +--:(encapsulation) {map-e}? | | +--rw br-ipv6-addr inet:ipv6-address | +--:(translation) {map-t}? | +--rw dmr-ipv6-prefix? inet:ipv6-prefix +--rw ea-len uint8 +--rw rule-ipv6-prefix inet:ipv6-prefix +--rw rule-ipv4-prefix inet:ipv4-prefix +--rw forwarding boolean augment /if:interfaces/if:interface/if:statistics: +--ro sent-ipv4-packets? | yang:zero-based-counter64 +--ro sent-ipv4-bytes? | yang:zero-based-counter64 +--ro sent-ipv6-packets? | yang:zero-based-counter64 +--ro sent-ipv6-bytes? | yang:zero-based-counter64 +--ro rcvd-ipv4-packets? | yang:zero-based-counter64 +--ro rcvd-ipv4-bytes? | yang:zero-based-counter64 +--ro rcvd-ipv6-packets? | yang:zero-based-counter64 +--ro rcvd-ipv6-bytes? Farrer & Boucadair Expires August 2, 2019 [Page 6] Internet-Draft YANG Modules for A+P Softwires January 2019 | yang:zero-based-counter64 +--ro dropped-ipv4-packets? | yang:zero-based-counter64 +--ro dropped-ipv4-bytes? | yang:zero-based-counter64 +--ro dropped-ipv6-packets? | yang:zero-based-counter64 +--ro dropped-ipv6-bytes? | yang:zero-based-counter64 +--ro dropped-ipv4-fragments? | yang:zero-based-counter64 +--ro dropped-ipv4-fragment-bytes? | yang:zero-based-counter64 +--ro ipv6-fragments-reassembled? | yang:zero-based-counter64 +--ro ipv6-fragments-bytes-reassembled? | yang:zero-based-counter64 +--ro out-icmpv4-error-packets? | yang:zero-based-counter64 +--ro out-icmpv4-error-bytes? | yang:zero-based-counter64 +--ro out-icmpv6-error-packets? | yang:zero-based-counter64 +--ro out-icmpv6-error-bytes? yang:zero-based-counter64 notifications: +---n softwire-ce-event {binding-mode}? +--ro ce-binding-ipv6-addr-change inet:ipv6-address Figure 1: Softwire CE YANG Tree Diagram 4.2. Softwire CE Tree Diagram Description Additional information related to the operation of a CE element is provided below: o softwire-payload-mtu: optionally used to set the IPv4 MTU for the softwire. Needed if the softwire implementation is unable to correctly calculate the correct IPv4 Maximum Transit Unit (MTU) size automatically. o softwire-path-mru: optionally used to set the maximum IPv6 softwire packet size that can be received, including the encapsulation/translation overhead. Needed if the softwire implementation is unable to correctly calculate the correct IPv4 payload Maximum Receive Unit (MRU) size automatically (see Section 3.2 of [RFC4213]). Farrer & Boucadair Expires August 2, 2019 [Page 7] Internet-Draft YANG Modules for A+P Softwires January 2019 o ce-type: provides a choice statement allowing the binding or algorithmic softwire mechanisms to be selected. Further details relevant to binding softwire elements are: o binding-ipv6info: used to set the IPv6 binding prefix type to identify which IPv6 address to use as the tunnel source. It can be 'ipv6-prefix' or 'ipv6-address'. o br-ipv6-addr: sets the IPv6 address of the remote BR. Additional details relevant to some of the important algorithmic elements are provided below: o algo-versioning: optionally used to associate a version number and/or timestamp to the algorithm. This can be used for logging/ data retention purposes [RFC7422]. The version number is selected to uniquely identify the algorithm configuration and a new value written whenever a change is made to the algorithm or a new algo- instance is created. o forwarding: specifies whether the rule can be used as a Forward Mapping Rule (FMR). If not set, this rule is a Basic Mapping Rule (BMR) only and must not be used for forwarding. Refer to Section 4.1 of [RFC7598]. o ea-len: used to set the length of the Embedded-Address (EA), which is defined in the mapping rule for a MAP domain. o data-plane: provides a choice statement for either encapsulation (MAP-E) or translation (MAP-T). o br-ipv6-addr: defines the IPv6 address of the BR. This information is valid for MAP-E. o dmr-ipv6-prefix: defines the Default Mapping Rule (DMR) IPv6 prefix of the BR. This information is valid for MAP-T. Additional information on the notification node is listed below: o ce-binding-ipv6-addr-change: if the CE's binding IPv6 address changes for any reason, the NETCONF client will be notified. 5. Softwire BR YANG Tree Diagram Farrer & Boucadair Expires August 2, 2019 [Page 8] Internet-Draft YANG Modules for A+P Softwires January 2019 5.1. BR Tree Diagram The BR YANG module provides configuration and monitoring for all of the softwire mechanisms covered in this document (i.e., Lightweight 4over6, MAP-E, and MAP-T). Figure 2 provides the tree structure of this module: module: ietf-softwire-br +--rw br-instances +--rw (br-type)? +--:(binding) {binding-mode}? | +--rw binding | +--rw bind-instance* [name] | +--rw name string | +--rw binding-table-versioning | | +--rw version? uint64 | | +--rw date? yang:date-and-time | +--rw softwire-num-max uint32 | +--rw softwire-payload-mtu uint16 | +--rw softwire-path-mru uint16 | +--rw enable-hairpinning? boolean | +--rw binding-table | | +--rw binding-entry* [binding-ipv6info] | | +--rw binding-ipv6info union | | +--rw binding-ipv4-addr? | | | inet:ipv4-address | | +--rw port-set | | | +--rw psid-offset? uint8 | | | +--rw psid-len uint8 | | | +--rw psid uint16 | | +--rw br-ipv6-addr? | | inet:ipv6-address | +--rw icmp-policy | | +--rw icmpv4-errors | | | +--rw allow-incoming-icmpv4? boolean | | | +--rw icmpv4-rate? uint32 | | | +--rw generate-icmpv4-errors? boolean | | +--rw icmpv6-errors | | +--rw generate-icmpv6-errors? boolean | | +--rw icmpv6-rate? uint32 | +--ro traffic-stat | +--ro discontinuity-time yang:date-and-time | +--ro sent-ipv4-packets? | | yang:zero-based-counter64 | +--ro sent-ipv4-bytes? | | yang:zero-based-counter64 | +--ro sent-ipv6-packets? Farrer & Boucadair Expires August 2, 2019 [Page 9] Internet-Draft YANG Modules for A+P Softwires January 2019 | | yang:zero-based-counter64 | +--ro sent-ipv6-bytes? | | yang:zero-based-counter64 | +--ro rcvd-ipv4-packets? | | yang:zero-based-counter64 | +--ro rcvd-ipv4-bytes? | | yang:zero-based-counter64 | +--ro rcvd-ipv6-packets? | | yang:zero-based-counter64 | +--ro rcvd-ipv6-bytes? | | yang:zero-based-counter64 | +--ro dropped-ipv4-packets? | | yang:zero-based-counter64 | +--ro dropped-ipv4-bytes? | | yang:zero-based-counter64 | +--ro dropped-ipv6-packets? | | yang:zero-based-counter64 | +--ro dropped-ipv6-bytes? | | yang:zero-based-counter64 | +--ro dropped-ipv4-fragments? | | yang:zero-based-counter64 | +--ro dropped-ipv4-fragment-bytes? | | yang:zero-based-counter64 | +--ro ipv6-fragments-reassembled? | | yang:zero-based-counter64 | +--ro ipv6-fragments-bytes-reassembled? | | yang:zero-based-counter64 | +--ro out-icmpv4-error-packets? | | yang:zero-based-counter64 | +--ro out-icmpv4-error-bytes? | | yang:zero-based-counter64 | +--ro out-icmpv6-error-packets? | | yang:zero-based-counter64 | +--ro out-icmpv6-error-bytes? | | yang:zero-based-counter64 | +--ro dropped-icmpv4-packets? | | yang:zero-based-counter64 | +--ro dropped-icmpv4-bytes? | | yang:zero-based-counter64 | +--ro hairpin-ipv4-packets? | | yang:zero-based-counter64 | +--ro hairpin-ipv4-bytes? | | yang:zero-based-counter64 | +--ro active-softwire-num? | uint32 +--:(algo) {map-e or map-t}? +--rw algorithm +--rw algo-instance* [name] Farrer & Boucadair Expires August 2, 2019 [Page 10] Internet-Draft YANG Modules for A+P Softwires January 2019 +--rw name string +--rw enable? boolean +--rw algo-versioning | +--rw version? uint64 | +--rw date? yang:date-and-time +--rw (data-plane)? | +--:(encapsulation) {map-e}? | | +--rw br-ipv6-addr inet:ipv6-address | +--:(translation) {map-t}? | +--rw dmr-ipv6-prefix? inet:ipv6-prefix +--rw ea-len uint8 +--rw rule-ipv6-prefix inet:ipv6-prefix +--rw rule-ipv4-prefix inet:ipv4-prefix +--rw forwarding boolean +--rw port-set | +--rw psid-offset? uint8 | +--rw psid-len uint8 | +--rw psid uint16 +--ro traffic-stat +--ro discontinuity-time yang:date-and-time +--ro sent-ipv4-packets? | yang:zero-based-counter64 +--ro sent-ipv4-bytes? | yang:zero-based-counter64 +--ro sent-ipv6-packets? | yang:zero-based-counter64 +--ro sent-ipv6-bytes? | yang:zero-based-counter64 +--ro rcvd-ipv4-packets? | yang:zero-based-counter64 +--ro rcvd-ipv4-bytes? | yang:zero-based-counter64 +--ro rcvd-ipv6-packets? | yang:zero-based-counter64 +--ro rcvd-ipv6-bytes? | yang:zero-based-counter64 +--ro dropped-ipv4-packets? | yang:zero-based-counter64 +--ro dropped-ipv4-bytes? | yang:zero-based-counter64 +--ro dropped-ipv6-packets? | yang:zero-based-counter64 +--ro dropped-ipv6-bytes? | yang:zero-based-counter64 +--ro dropped-ipv4-fragments? | yang:zero-based-counter64 +--ro dropped-ipv4-fragment-bytes? | yang:zero-based-counter64 Farrer & Boucadair Expires August 2, 2019 [Page 11] Internet-Draft YANG Modules for A+P Softwires January 2019 +--ro ipv6-fragments-reassembled? | yang:zero-based-counter64 +--ro ipv6-fragments-bytes-reassembled? | yang:zero-based-counter64 +--ro out-icmpv4-error-packets? | yang:zero-based-counter64 +--ro out-icmpv4-error-bytes? | yang:zero-based-counter64 +--ro out-icmpv6-error-packets? | yang:zero-based-counter64 +--ro out-icmpv6-error-bytes? yang:zero-based-counter64 notifications: +---n softwire-binding-instance-event {binding-mode}? | +--ro bind-name? | | -> /br-instances/binding/bind-instance/name | +--ro invalid-entry* leafref | +--ro added-entry* inet:ipv6-address | +--ro modified-entry* leafref +---n softwire-algorithm-instance-event {map-e, map-t}? +--ro algo-name | -> /br-instances/algorithm/algo-instance/name +--ro invalid-entry-id* | -> /br-instances/algorithm/algo-instance/name +--ro added-entry* | -> /br-instances/algorithm/algo-instance/name +--ro modified-entry* -> /br-instances/algorithm/algo-instance/name Figure 2: Softwire BR YANG Tree 5.2. Softwire BR Tree Diagram Description The descriptions for leaves which are common with the CE module are provided in Section 4.2. Descriptions for additional elements are provided below: o binding-table-versioning: optionally used to associate a version number and/or timestamp to the binding table. This can be used for logging or data retention purposes [RFC7422]. The version number is selected to uniquely identify the binding table configuration and a new timestamp value written whenever a change is made to the contents of the binding table or a new binding table list is created. o binding-entry: used to define the binding relationship between Farrer & Boucadair Expires August 2, 2019 [Page 12] Internet-Draft YANG Modules for A+P Softwires January 2019 3-tuples {lwB4's IPv6 address/prefix, the allocated IPv4 address, restricted port-set}. For detail information, please refer to [RFC7596]. o softwire-num-max: used to set the maximum number of softwire binding rules that can be created on the lw4o6 element simultaneously. This paramter must not be set to zero because this is equivalent to disabling the BR instance. o active-softwire-num: holds the number of softwires currently provisioned on the BR element. Additional information on some of the important notification nodes is listed below: o invalid-entry, added-entry, modified-entry: used to notify the NETCONF client that a specific binding entry or MAP rule has expired, been invalidated, added, or modified. 6. Softwire CE YANG Module This module imports the modules defined in [RFC6991], [RFC8343], and [RFC7224]. It also imports the 'ietf-softwire-common' and 'iana- tunnel-type' modules [I-D.ietf-softwire-iftunnel]. file "ietf-softwire-ce@2019-01-11.yang" module ietf-softwire-ce { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-softwire-ce"; prefix softwire-ce; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-interfaces { prefix if; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-softwire-common { prefix softwire-common; reference "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port Softwires"; } import iana-tunnel-type { prefix iana-tunnel-type; Farrer & Boucadair Expires August 2, 2019 [Page 13] Internet-Draft YANG Modules for A+P Softwires January 2019 reference "RFC YYYY: Tunnel Interface Types YANG Module"; } organization "IETF Softwire Working Group"; contact "WG Web: WG List: Author: Qi Sun Author: Linhui Sun Author: Yong Cui Editor: Ian Farrer Author: Sladjana Zoric Editor: Mohamed Boucadair Author: Rajiv Asati "; description "This document defines a YANG module for the configuration and management of A+P Softwire Customer Premises Equipment (CEs). It covers Lightweight 4over6, MAP-E, and MAP-T mechanisms. Copyright (c) 2019 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."; Farrer & Boucadair Expires August 2, 2019 [Page 14] Internet-Draft YANG Modules for A+P Softwires January 2019 revision 2019-01-11 { description "Initial revision."; reference "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port Softwires"; } /* * Features */ feature binding-mode { description "Binding is used for configuring the Lightweight 4over6 mechanism. Binding based softwire mechanisms are IPv4-over-IPv6 tunnelling transition mechanisms specifically intended for complete independence between the IPv6 subnet prefix (and IPv6 address) and IPv4 address, with or without IPv4 address sharing. This is accomplished by maintaining state for each softwire (per-subscriber state) in the central Border Relay (BR) and using a hub-and-spoke forwarding architecture. In order to delegate the NAPT function and achieve IPv4 address sharing, port-restricted IPv4 addresses needs to be allocated to CEs. This feature indicates that the network element can function as one or more binding based softwire instances."; reference "RFC7596: Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture RFC7597: Mapping of Address and Port with Encapsulation (MAP-E) RFC7599: Mapping of Address and Port using Translation (MAP-T)"; } feature map-e { description "MAP-E is an IPv6 transition mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. MAP-E allows for a reduction of the amount of centralized state using rules to express IPv4/IPv6 address mappings. This introduces an algorithmic relationship between the IPv6 subnet and IPv4 address. This feature indicates that the network element can function as one or more MAP-E softwire instances."; reference Farrer & Boucadair Expires August 2, 2019 [Page 15] Internet-Draft YANG Modules for A+P Softwires January 2019 "RFC7597: Mapping of Address and Port with Encapsulation (MAP-E)"; } feature map-t { description "MAP-T is an IPv6 transition mechanism for transporting IPv4 packets across an IPv6 network using IP translation. It leverages a double stateless NAT64 based solution as well as the stateless algorithmic address & transport layer port mapping algorithm defined for MAP-E. This feature indicates that the network element can function as one or more MAP-T softwire instances."; reference "RFC7599: Mapping of Address and Port using Translation (MAP-T)"; } // Binding Entry grouping binding-entry { description "The binding BR (Border Relay) maintains an address binding table that contains the binding between the CE's IPv6 address, the allocated IPv4 address and restricted port-set."; leaf binding-ipv6info { type union { type inet:ipv6-address; type inet:ipv6-prefix; } description "The IPv6 information for a binding entry. When the IPv6 prefix type is used, the IPv6 source address of the CE is constructed according to the description in RFC7596. If the IPv6 address type is used, the CE can use any valid /128 address from a prefix assigned to the CE."; reference "Section 5.1 of RFC7596."; } leaf br-ipv6-addr { type inet:ipv6-address; mandatory true; description "The IPv6 address of the binding BR."; } } Farrer & Boucadair Expires August 2, 2019 [Page 16] Internet-Draft YANG Modules for A+P Softwires January 2019 // configuration and stateful parameters for softwire CE interface augment "/if:interfaces/if:interface" { when "derived-from(if:type, 'iana-tunnel-type:aplusp')"; description "Softwire CE interface configuration"; leaf softwire-payload-mtu { type uint16; units "bytes"; description "The payload IPv4 MTU for the softwire tunnel."; } leaf softwire-path-mru { type uint16; units "bytes"; description "The path MRU for the softwire (payload + encapsulation overhead)."; reference "RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers"; } choice ce-type { description "Sets the softwire CE mechanism"; case binding { if-feature "binding-mode"; description "CE binding configuration"; uses binding-entry; } case algo { if-feature "map-e or map-t"; description "CE algorithm configuration"; container algo-instances { description "Collection of MAP-E/MAP-T parameters"; list algo-instance { key "name"; description "MAP forwarding rule instance for MAP-E/MAP-T"; leaf name { type string; mandatory true; description "The name is used to uniquely identify an algorithm Farrer & Boucadair Expires August 2, 2019 [Page 17] Internet-Draft YANG Modules for A+P Softwires January 2019 instance. This name can be automatically assigned or explicitly configured."; } uses softwire-common:algorithm-instance; } } } } } augment "/if:interfaces/if:interface/if:statistics" { when "derived-from(../if:type, 'iana-tunnel-type:aplusp')"; description "Softwire CE interface statistics."; uses softwire-common:traffic-stat; } /* * Notifications */ notification softwire-ce-event { if-feature "binding-mode"; description "CE notification"; leaf ce-binding-ipv6-addr-change { type inet:ipv6-address; mandatory true; description "This notification is generated whenever the CE's binding IPv6 address changes for any reason."; } } } 7. BR Softwire YANG Module This module imports typedefs from [RFC6991]. It also imports the 'ietf-softwire-common' module. file "ietf-softwire-br@2019-01-11.yang" module ietf-softwire-br { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-softwire-br"; prefix softwire-br; Farrer & Boucadair Expires August 2, 2019 [Page 18] Internet-Draft YANG Modules for A+P Softwires January 2019 import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-yang-types { prefix yang; reference "Section 3 of RFC 6991"; } import ietf-softwire-common { prefix softwire-common; reference "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port Softwires"; } organization "IETF Softwire Working Group"; contact "WG Web: WG List: Author: Qi Sun Author: Linhui Sun Author: Yong Cui Editor: Ian Farrer Author: Sladjana Zoric Editor: Mohamed Boucadair Author: Rajiv Asati "; description "This document defines a YANG module for the configuration and management of A+P Softwire Border Routers. It covers Lightweight 4over6, MAP-E, and MAP-T mechanisms. Copyright (c) 2019 IETF Trust and the persons identified as Farrer & Boucadair Expires August 2, 2019 [Page 19] Internet-Draft YANG Modules for A+P Softwires January 2019 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."; revision 2019-01-11 { description "Initial revision."; reference "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port Softwires"; } /* * Groupings */ grouping port-set { description "Describes a set of layer 4 port numbers. This may be a simple port range, or use the Port Set Identifier (PSID) algorithm to represent a range of transport layer ports which will be used by a NAPT."; leaf psid-offset { type uint8 { range "0..16"; } description "The number of offset bits. In Lightweight 4over6, the default value is 0 for assigning one contiguous port range. In MAP-E/T, the default value is 6, which means the system ports (0-1023) are excluded by default and the assigned port ranges are distributed across the entire port space, depending on either psid-len or the number of contiguous ports."; } leaf psid-len { type uint8 { range "0..15"; } Farrer & Boucadair Expires August 2, 2019 [Page 20] Internet-Draft YANG Modules for A+P Softwires January 2019 mandatory true; description "The length of PSID, representing the sharing ratio for an IPv4 address. This, along with ea-len, can be used to calculate the number of contiguous ports per port range"; } leaf psid { type uint16; mandatory true; description "Port Set Identifier (PSID) value, which identifies a set of ports algorithmically."; } } grouping binding-entry { description "The binding BR maintains an address binding table that contains the binding between the CE's IPv6 address, the allocated IPv4 address and restricted port-set."; leaf binding-ipv6info { type union { type inet:ipv6-address; type inet:ipv6-prefix; } description "The IPv6 information for a CE binding entry. When the IPv6 prefix type is used, the IPv6 source address of the CE is constructed according to the description in RFC7596; if the IPv6 address type is used, the CE can use any valid /128 address from a prefix assigned to the CE."; reference "RFC7596: Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture"; } leaf binding-ipv4-addr { type inet:ipv4-address; description "The IPv4 address assigned to the binding CE, which is used as the IPv4 external address for binding CE local NAPT44."; } container port-set { description "For Lightweight 4over6, the default value Farrer & Boucadair Expires August 2, 2019 [Page 21] Internet-Draft YANG Modules for A+P Softwires January 2019 for offset should be 0, to configure one contiguous port range."; uses port-set { refine "psid-offset" { default "0"; } } } leaf br-ipv6-addr { type inet:ipv6-address; description "The IPv6 address for binding BR."; } } /* * Features */ feature binding-mode { description "Binding is used for configuring the Lightweight 4over6 mechanism. Binding based softwire mechanisms are IPv4-over-IPv6 tunnelling transition mechanisms specifically intended for complete independence between the IPv6 subnet prefix (and IPv6 address) and IPv4 address, with or without IPv4 address sharing. This is accomplished by maintaining state for each softwire (per-subscriber state) in the central Border Relay (BR) and using a hub-and-spoke forwarding architecture. In order to delegate the NAPT function and achieve IPv4 address sharing, port-restricted IPv4 addresses needs to be allocated to CEs. This feature indicates that the network element can function as one or more binding based softwire instances."; reference "RFC7596: Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture RFC7597: Mapping of Address and Port with Encapsulation (MAP-E) RFC7599: Mapping of Address and Port using Translation (MAP-T)"; } feature map-e { description "MAP-E is an IPv6 transition mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. MAP-E allows for a reduction of the amount of centralized state using Farrer & Boucadair Expires August 2, 2019 [Page 22] Internet-Draft YANG Modules for A+P Softwires January 2019 rules to express IPv4/IPv6 address mappings. This introduces an algorithmic relationship between the IPv6 subnet and IPv4 address. This feature indicates that the network element can function as one or more MAP-E softwire instances."; reference "RFC7597: Mapping of Address and Port with Encapsulation (MAP-E)"; } feature map-t { description "MAP-T is an IPv6 transition mechanism for transporting IPv4 packets across an IPv6 network using IP translation. It leverages a double stateless NAT64 based solution as well as the stateless algorithmic address & transport layer port mapping algorithm defined for MAP-E. This feature indicates that the network element can function as one or more MAP-T softwire instances."; reference "RFC7599: Mapping of Address and Port using Translation (MAP-T)"; } container br-instances { description "BR instances enabled in a network element."; choice br-type { description "Select binding or algorithmic BR functionality."; case binding { if-feature "binding-mode"; container binding { description "binding mechanism (binding table) configuration."; list bind-instance { key "name"; description "A set of binding instances to be configured."; leaf name { type string; mandatory true; description "The name for the binding BR. It is used to uniquely distinguish a binding instance by its name."; } container binding-table-versioning { description Farrer & Boucadair Expires August 2, 2019 [Page 23] Internet-Draft YANG Modules for A+P Softwires January 2019 "binding table's version"; leaf version { type uint64; description "Version number for this binding table."; } leaf date { type yang:date-and-time; description "Timestamp when the binding table was activated. A binding instance may be provided with binding entries that may change in time (e.g., increase the size of the port set). When a party who is the victim of abuse presents an external IP address/port, the version of the binding table is important because depending on the version, a distinct customer may be identified. The timestamp is used as a key to find the appropriate binding table that was put into effect when an abuse occurred."; reference "RFC7422: Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments"; } } leaf softwire-num-max { type uint32 { range "1..max"; } mandatory true; description "The maximum number of softwires that can be created on the binding BR."; } leaf softwire-payload-mtu { type uint16; units "bytes"; mandatory true; description "The payload IPv4 MTU for binding softwire."; } leaf softwire-path-mru { type uint16; units "bytes"; mandatory true; description Farrer & Boucadair Expires August 2, 2019 [Page 24] Internet-Draft YANG Modules for A+P Softwires January 2019 "The path MRU for binding softwire."; reference "RFC4213: Basic Transition Mechanisms for IPv6 Hosts and Routers"; } leaf enable-hairpinning { type boolean; default "true"; description "Enables/disables support for locally forwarding (hairpinning) traffic between two CEs."; reference "Section 6.2 of RFC7596"; } container binding-table { description "binding table"; list binding-entry { key "binding-ipv6info"; description "binding entry"; uses binding-entry; } } container icmp-policy { description "The binding BR can be configured to process or drop incoming ICMP messages, and to generate outgoing ICMP error messages."; container icmpv4-errors { description "ICMPv4 error processing configuration"; leaf allow-incoming-icmpv4 { type boolean; default "true"; description "Enables the processing of incoming ICMPv4 packets."; reference "RFC7596: Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture"; } leaf icmpv4-rate { type uint32; description "Rate limit threshold in messages per-second for processing incoming ICMPv4 errors messages"; } leaf generate-icmpv4-errors { Farrer & Boucadair Expires August 2, 2019 [Page 25] Internet-Draft YANG Modules for A+P Softwires January 2019 type boolean; default "true"; description "Enables the generation of outgoing ICMPv4 error messages on receipt of an inbound IPv4 packet with no matching binding table entry."; reference "Seciton 5.2 of RFC7596."; } } container icmpv6-errors { description "ICMPv6 error processing configuration"; leaf generate-icmpv6-errors { type boolean; default "true"; description "Enables the generation of ICMPv6 error messages if no matching binding table entry is found for a received packet."; reference "Section 6.2 of RFC7596."; } leaf icmpv6-rate { type uint32; description "Rate limit threshold in messages per-second for sending ICMPv6 errors messages"; reference "Section 9 of RFC7596."; } } } container traffic-stat { config false; description "Traffic statistics information for the BR."; leaf discontinuity-time { type yang:date-and-time; mandatory true; description "The time of the most recent occasion on which the BR instance suffered a discontinuity. This must be initialized when the BR instance is configured or rebooted."; } uses softwire-common:traffic-stat; leaf dropped-icmpv4-packets { type yang:zero-based-counter64; description "ICMPv4 packets that are dropped as a result Farrer & Boucadair Expires August 2, 2019 [Page 26] Internet-Draft YANG Modules for A+P Softwires January 2019 of the ICMP policy. Typically, this can be any incoming ICMPv4 packets if ICMPv4 processing is disabled or incoming ICMPv4 packets that exceed the ICMPv4 rate-limit threshold. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf dropped-icmpv4-bytes { type yang:zero-based-counter64; description "ICMPv4 messages, in bytes, that are dropped as a result of the ICMP policy. Typically, it can be any incoming ICMPv4 packets if ICMPv4 processing is disabled or incoming ICMPv4 packets that exceed the ICMPv4 rate-limit threshold. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf hairpin-ipv4-packets { type yang:zero-based-counter64; description "IPv4 packets locally routed between two CEs (hairpinned). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf hairpin-ipv4-bytes { type yang:zero-based-counter64; description "IPv4 bytes locally routed between two CEs (hairpinned). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf active-softwire-num { Farrer & Boucadair Expires August 2, 2019 [Page 27] Internet-Draft YANG Modules for A+P Softwires January 2019 type uint32; config false; description "The number of currently active softwires on the binding instance. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } } } } } case algo { if-feature "map-e or map-t"; container algorithm { description " A set of parameters used for MAP-E/MAP-T."; list algo-instance { key "name"; description "Instances of algorithm"; leaf name { type string; mandatory true; description "The name is used to uniquely identify an algorithm instance. This name can be automatically assigned or explicitly configured."; } uses softwire-common:algorithm-instance; container port-set { description "Indicates a set of ports."; uses port-set; } container traffic-stat { config false; description "Traffic statistics information for the BR."; leaf discontinuity-time { type yang:date-and-time; mandatory true; description Farrer & Boucadair Expires August 2, 2019 [Page 28] Internet-Draft YANG Modules for A+P Softwires January 2019 "The time of the most recent occasion on which the BR instance suffered a discontinuity. This must be reset to the current date-and-time when the BR instance is configured or rebooted."; } uses softwire-common:traffic-stat; } } } } } } /* * Notifications */ notification softwire-binding-instance-event { if-feature "binding-mode"; description "Notifications for binding instance when an entry is added, modified, or is not valid anymore."; leaf bind-name { type leafref { path "/br-instances/binding/bind-instance/name"; } description "The name of the binding-instance that generated the notification."; } leaf-list invalid-entry { type leafref { path "/br-instances/binding/" + "bind-instance[name=current()/../bind-name]/" + "binding-table/binding-entry/binding-ipv6info"; } description "Notify the client that a specific binding entry has expired or is invalid. The binding-ipv6info identifies an entry."; } leaf-list added-entry { type inet:ipv6-address; description "Notify the client that a binding entry has been added. The ipv6 address of that entry is the index. The client gets other information from the binding BR about the entry Farrer & Boucadair Expires August 2, 2019 [Page 29] Internet-Draft YANG Modules for A+P Softwires January 2019 indexed by that ipv6 address."; } leaf-list modified-entry { type leafref { path "/br-instances/binding/" + "bind-instance[name=current()/../bind-name]/" + "binding-table/binding-entry/binding-ipv6info"; } description "The binding-table entry that has been modified."; } } notification softwire-algorithm-instance-event { if-feature "map-e or map-t"; description "Notifications for algorithm instance when an entry is added, modified, or is not valid anymore."; leaf algo-name { type leafref { path "/br-instances/algorithm/algo-instance/name"; } mandatory true; description "algorithmic instance event."; } leaf-list invalid-entry { type leafref { path "/br-instances/algorithm/algo-instance/name"; } description "Invalid entry event."; } leaf-list added-entry { type leafref { path "/br-instances/algorithm/algo-instance/name"; } description "Added entry."; } leaf-list modified-entry { type leafref { path "/br-instances/algorithm/algo-instance/name"; } description "Modified entry."; } } Farrer & Boucadair Expires August 2, 2019 [Page 30] Internet-Draft YANG Modules for A+P Softwires January 2019 } 8. Common Softwire Element Groups YANG Module This module imports typedefs from [RFC6991]. The following YANG module contains definitions that are used by both the softwire CE and softwire BR YANG modules. file "ietf-softwire-common@2019-01-11.yang" module ietf-softwire-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-softwire-common"; prefix softwire-common; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-yang-types { prefix yang; reference "Section 3 of RFC 6991"; } organization "IETF Softwire Working Group"; contact "WG Web: WG List: Author: Qi Sun Author: Linhui Sun Author: Yong Cui Editor: Ian Farrer Author: Sladjana Zoric Editor: Mohamed Boucadair Farrer & Boucadair Expires August 2, 2019 [Page 31] Internet-Draft YANG Modules for A+P Softwires January 2019 Author: Rajiv Asati "; description "This document defines a YANG module defining types common to all A+P modules. Copyright (c) 2019 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."; revision 2019-01-11 { description "Initial revision."; reference "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port Softwires"; } feature map-e { description "MAP-E is an IPv6 transition mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. MAP-E allows for a reduction of the amount of centralized state using rules to express IPv4/IPv6 address mappings. This introduces an algorithmic relationship between the IPv6 subnet and IPv4 address. This feature indicates that the network element can function as one or more MAP-E softwire instances."; reference "RFC7597: Mapping of Address and Port with Encapsulation (MAP-E)"; } feature map-t { description "MAP-T is an IPv6 transition mechanism for transporting IPv4 packets across an IPv6 network using IP translation. It leverages Farrer & Boucadair Expires August 2, 2019 [Page 32] Internet-Draft YANG Modules for A+P Softwires January 2019 a double stateless NAT64 based solution as well as the stateless algorithmic address & transport layer port mapping algorithm defined for MAP-E. This feature indicates that the network element can function as one or more MAP-T softwire instances."; reference "RFC7599: Mapping of Address and Port using Translation (MAP-T)"; } /* * Groupings */ grouping algorithm-instance { description "A collection of parameters that is used fro MAP-E/MAP-T."; leaf enable { type boolean; description "Enable/disable an individual MAP-E or MAP-T rule."; } container algo-versioning { description "Version number for this algorithm instance"; leaf version { type uint64; description "A version number for the mapping algorithm rules provided to the algorithm instance"; } leaf date { type yang:date-and-time; description "Timestamp when the algorithm instance was activated. An algorithm instance may be provided with mapping rules that may change in time (for example, increase the size of the port set). When a party who is the victim of abuse presents an external IP address/port, the version of the algorithm is important because depending on the version, a distinct customer may be identified. The timestamp is used as a key to find the appropriate algorithm that was put into effect when an abuse occurred. "; reference "RFC7422: Deterministic Address Mapping to Reduce Farrer & Boucadair Expires August 2, 2019 [Page 33] Internet-Draft YANG Modules for A+P Softwires January 2019 Logging in Carrier-Grade NAT Deployments"; } } choice data-plane { description "Selects MAP-E (encapsulation) or MAP-T (translation)"; case encapsulation { if-feature "map-e"; description "encapsulation for MAP-E"; leaf br-ipv6-addr { type inet:ipv6-address; mandatory true; description "The IPv6 address of the MAP-E BR."; } } case translation { if-feature "map-t"; description "translation for MAP-T"; leaf dmr-ipv6-prefix { type inet:ipv6-prefix; description "The IPv6 prefix of the MAP-T BR."; } } } leaf ea-len { type uint8; mandatory true; description "Embedded Address (EA) bits are the IPv4 EA-bits in the IPv6 address identifying an IPv4 prefix/address (or part thereof) or a shared IPv4 address (or part thereof) and a port-set identifier. The length of the EA-bits is defined as part of a MAP rule for a MAP domain."; } leaf rule-ipv6-prefix { type inet:ipv6-prefix; mandatory true; description "The Rule IPv6 prefix defined in the mapping rule."; } leaf rule-ipv4-prefix { type inet:ipv4-prefix; mandatory true; Farrer & Boucadair Expires August 2, 2019 [Page 34] Internet-Draft YANG Modules for A+P Softwires January 2019 description "The Rule IPv4 prefix defined in the mapping rule."; } leaf forwarding { type boolean; mandatory true; description "This parameter specifies whether the rule may be used for forwarding (FMR). If set, this rule is used as an FMR; if not set, this rule is a Basic Mapping Rule (BMR) only and must not be used for forwarding."; } } grouping traffic-stat { description "Traffic statistics"; leaf sent-ipv4-packets { type yang:zero-based-counter64; description "Number of decapsulated and forwarded IPv4 packets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf sent-ipv4-bytes { type yang:zero-based-counter64; description "Decapsulated/translated IPv4 traffic sent, in bytes Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf sent-ipv6-packets { type yang:zero-based-counter64; description "Number of encapsulated IPv6 packets sent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf sent-ipv6-bytes { Farrer & Boucadair Expires August 2, 2019 [Page 35] Internet-Draft YANG Modules for A+P Softwires January 2019 type yang:zero-based-counter64; description "Encapsulated IPv6 traffic sent, in bytes Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf rcvd-ipv4-packets { type yang:zero-based-counter64; description "Number of IPv4 packets received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf rcvd-ipv4-bytes { type yang:zero-based-counter64; description "IPv4 traffic received, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf rcvd-ipv6-packets { type yang:zero-based-counter64; description "Number of IPv4-in-IPv6 packets received. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf rcvd-ipv6-bytes { type yang:zero-based-counter64; description "IPv4-in-IPv6 traffic received, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; Farrer & Boucadair Expires August 2, 2019 [Page 36] Internet-Draft YANG Modules for A+P Softwires January 2019 } leaf dropped-ipv4-packets { type yang:zero-based-counter64; description "Number of IPv4 packets dropped at the Internet-facing interface. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf dropped-ipv4-bytes { type yang:zero-based-counter64; description "IPv4 traffic dropped at the Internet-facing interface, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf dropped-ipv6-packets { type yang:zero-based-counter64; description "Number of IPv4-in-IPv6 packets dropped. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf dropped-ipv6-bytes { type yang:zero-based-counter64; description "IPv4-in-IPv6 traffic dropped, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf dropped-ipv4-fragments { type yang:zero-based-counter64; description "Number of fragmented IPv4 packets dropped. Farrer & Boucadair Expires August 2, 2019 [Page 37] Internet-Draft YANG Modules for A+P Softwires January 2019 Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf dropped-ipv4-fragment-bytes { type yang:zero-based-counter64; description "Fragmented IPv4 traffic dropped, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf ipv6-fragments-reassembled { type yang:zero-based-counter64; description "Number of IPv6 fragments successfully reassembled. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf ipv6-fragments-bytes-reassembled { type yang:zero-based-counter64; description "IPv6 fragments successfully reassembled, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf out-icmpv4-error-packets { type yang:zero-based-counter64; description "Internally generated ICMPv4 error packets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf out-icmpv4-error-bytes { type yang:zero-based-counter64; description Farrer & Boucadair Expires August 2, 2019 [Page 38] Internet-Draft YANG Modules for A+P Softwires January 2019 "Internally generated ICMPv4 error messages, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf out-icmpv6-error-packets { type yang:zero-based-counter64; description "Internally generated ICMPv6 error packets. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } leaf out-icmpv6-error-bytes { type yang:zero-based-counter64; description "Internally generated ICMPv6 error messages, in bytes. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of 'discontinuity-time'."; } } } 9. Security Considerations The YANG modules defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. All data nodes defined in the YANG modules which can be created, modified, and deleted (i.e., config true, which is the default) are considered sensitive. Write operations (e.g., edit-config) applied Farrer & Boucadair Expires August 2, 2019 [Page 39] Internet-Draft YANG Modules for A+P Softwires January 2019 to these data nodes without proper protection can negatively affect network operations. An attacker who is able to access the BR can undertake various attacks, such as: o Setting the value of 'br-ipv6-addr' on the CE to point to an illegitimate BR so that it can intercept all the traffic sent by a CE. Illegitimately intercepting users' traffic is an attack with severe implications on privacy. o Setting the MTU to a low value, which may increase the number of fragments ('softwire-payload-mtu'). o Disabling hairpinning (i.e., setting 'enable-hairpinning' to 'false') to prevent communications between CEs. o Setting 'softwire-num-max' to an arbitrary high value, which may be exploited by a misbehaving user to perform a DoS on the binding BR by mounting a massive number of softwires. o Setting 'icmpv4-rate' or 'icmpv6-rate' to a low value, which may lead to the deactivation of ICMP messages handling. o Accessing to private data maintained by the BR (e.g., the binding table or the algorithm configuration). Such data can be misused to track the activity of a host. o Instructing the BR to install entries which in turn will induce a DDoS attack by means of the notifications generated by the BR. This DDoS can be softened by defining a notification interval, but given that this interval parameter can be disabled or set to a low value by the misbehaving entity, the same problem will be observed. Security considerations related to lw4o6, MAP-T, and MAP-E are discussed in [RFC7596], [RFC7597], and [RFC7599] respectively. Security considerations given in [RFC7950] are also applicable here. 10. IANA Considerations This document requests IANA to assign a new tunnel type under the "tunnelType" sub-registry of the "ifType definitions" registry maintained at [TUNNELTYPE-IANA-REGISTRY] and use the following data for the new entry: Farrer & Boucadair Expires August 2, 2019 [Page 40] Internet-Draft YANG Modules for A+P Softwires January 2019 Decimal: TDB1 Name: aplusp Description: A+P encapsulation Reference: [RFC6346] This document requests IANA to register the following in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-softwire-ce Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-softwire-br Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-softwire-common Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests that IANA registers the following YANG modules in the "YANG Module Names" subregistry [RFC7950] within the "YANG Parameters" registry. name: ietf-softwire-ce namespace: urn:ietf:params:xml:ns:yang:ietf-softwire-ce prefix: softwire-ce reference: RFC XXXX name: ietf-softwire-br namespace: urn:ietf:params:xml:ns:yang:ietf-softwire-br prefix: softwire-br reference: RFC XXXX name: ietf-softwire-common namespace: urn:ietf:params:xml:ns:yang:ietf-softwire-common prefix: softwire-common reference: RFC XXXX 11. Acknowledgements The authors would like to thank Lishan Li, Bert Wijnen, Giles Heron, Ole Troan, Andy Wingo and Leo Tietz for their contributions to this work. Thanks to Sheng Jiang for the review. Special thanks to Tom Petch and Martin Bjorklund for the detailed Farrer & Boucadair Expires August 2, 2019 [Page 41] Internet-Draft YANG Modules for A+P Softwires January 2019 review and suggestions. 12. Contributing Authors The following individuals are co-authors: Yong Cui Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6260-3059 Email: cuiyong@tsinghua.edu.cn Qi Sun Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5822 Email: sunqi.ietf@gmail.com Linhui Sun Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5822 Email: lh.sunlinh@gmail.com Sladjana Zechlin Deutsche Telekom AG Landgrabenweg 151 Bonn, NRW 53227 Germany Email: sladjana.zechlin@telekom.de Rajiv Asati Cisco Systems, Inc. 7025 Kit Creek Rd. RTP, NC 27709 USA Email: Rajiva@cisco.com 13. Contributors The following individual contributed to this document: Farrer & Boucadair Expires August 2, 2019 [Page 42] Internet-Draft YANG Modules for A+P Softwires January 2019 Hao Wang Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: wangh13@mails.tsinghua.edu.cn 14. References 14.1. Normative References [I-D.ietf-softwire-iftunnel] Boucadair, M., Farrer, I., and R. Asati, "Tunnel Interface Types YANG Module", draft-ietf-softwire-iftunnel-03 (work in progress), January 2019. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [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, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, . [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, . Farrer & Boucadair Expires August 2, 2019 [Page 43] Internet-Draft YANG Modules for A+P Softwires January 2019 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, . [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, . [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [TUNNELTYPE-IANA-REGISTRY] Internet Assigned Numbers Authority, "tunnelType Definitions", . 14.2. Informative References Farrer & Boucadair Expires August 2, 2019 [Page 44] Internet-Draft YANG Modules for A+P Softwires January 2019 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . [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, . [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, . [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments", RFC 7422, DOI 10.17487/RFC7422, December 2014, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, . Farrer & Boucadair Expires August 2, 2019 [Page 45] Internet-Draft YANG Modules for A+P Softwires January 2019 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, . Appendix A. Configuration Examples The following sections provide examples of how the softwire YANG modules can be used for configuring softwire elements. A.1. Configuration Example for a lw4o6 BR Binding-Table The lwAFTR maintains an address binding table which contains the following 3-tuples: o IPv6 Address for a single lwB4 o Public IPv4 Address o Restricted port-set The entry has two functions: the IPv6 encapsulation of inbound IPv4 packets destined to the lwB4 and the validation of outbound IPv4-in- IPv6 packets received from the lwB4 for de-capsulation. Consider an example for the following lw4o6 binding table entry: lwB4 Binding IPv6 Address: 2001:db8::1 lwB4 Binding IPv4 Address: 192.0.2.1 lwB4 PSID: 0x34 lwB4 PSID Length 8 BR IPv6 Address: 2001:db8:1::2 Farrer & Boucadair Expires August 2, 2019 [Page 46] Internet-Draft YANG Modules for A+P Softwires January 2019 mybinding-instance 2001:db8::1 192.0.2.1 52 8 2001:db8:1::2 1024 1540 1500 Figure 3: lw4o6 Binding-Table Configuration XML A.2. Configuration Example for a MAP-E BR A MAP-E BR is configured with forward mapping rules for the CEs it is serving. In this example (taken from [RFC7597], Appendix A, Example 2), the following parameters are required: o Rule IPv6 Prefix o Rule IPv4 Prefix o Rule EA-bit bit length o IPv6 Address of MAP-BR The mapping rule has two functions: identifying the destination CE IPv6 address for encapsulating inbound IPv4 packets and the validation of outbound IPv4-in-IPv6 packets received from the CE for de-capsulation. The transport type for the data plane also needs to be configured for encapsulation to enable MAP-E and forwarding needs to be enabled. Consider an example for the following MAP-E Forwarding Mapping Rule: Farrer & Boucadair Expires August 2, 2019 [Page 47] Internet-Draft YANG Modules for A+P Softwires January 2019 Data plane: encapsulation Rule IPv6 Prefix: 2001:db8::/40 Rule IPv4 Prefix: 192.0.2.0/24 Rule EA-bit Length: 16 BR IPv6 Address: 2001:db8:ffff::1 Figure 4 provides the example MAP-E BR configuration xml. myalgo-instance 2001:db8:ffff::1 16 192.0.2.0/24 2001:db8::/40 true 6 8 Figure 4: MAP-E FMR Configuration XML A.3. lw4o6 CE Configuration Example This section provides XML examples for configuring a lw4o6 CE. Examples for routing and NAT44 are also provided for convienience. Consider an example for the following lw4o6 CE configuration: lwB4 Binding IPv6 Address: 2001:db8::1 lwB4 Binding IPv4 Address: 192.0.2.1 lwB4 PSID: 0x34 lwB4 PSID Length 8 Farrer & Boucadair Expires August 2, 2019 [Page 48] Internet-Draft YANG Modules for A+P Softwires January 2019 BR IPv6 Address: 2001:db8:1::2 lw4o6-wan iana-tunnel-type:aplusp 2001:db8:1::2 2001:db8::1 Figure 5: lw4o6 CE Configuration XML In the example depicted in Figure 5, the interface name is defined for the softwire tunnel. This name is then referenced by the routing configuration for the IPv4 route. Figure 6 provides an example configuration for the CE's IPv4 routing, using the YANG module described in [RFC8349]. Farrer & Boucadair Expires August 2, 2019 [Page 49] Internet-Draft YANG Modules for A+P Softwires January 2019 static v4 0.0.0.0/0 lw4o6-wan Figure 6: lw4o6 CE Routing Configuration XML Figure 7 provides an example configuration for the CE's NAPT44 function, using the YANG module described in [RFC8512]. 1 1 1 192.0.2.1 6 8 52 1 80 Farrer & Boucadair Expires August 2, 2019 [Page 50] Internet-Draft YANG Modules for A+P Softwires January 2019 1 8 6 32 17 16 1 192.0.2.1/32 192.168.1.0/24 6 2 192.0.2.1/32 192.168.1.0/24 17 3 192.0.2.1/32 192.168.1.0/24 1 Figure 7: lw4o6 NAT Configuration XML Authors' Addresses Farrer & Boucadair Expires August 2, 2019 [Page 51] Internet-Draft YANG Modules for A+P Softwires January 2019 Ian Farrer (editor) Deutsche Telekom AG CTO-ATI, Landgrabenweg 151 Bonn, NRW 53227 Germany Email: ian.farrer@telekom.de Mohamed Boucadair (editor) Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Farrer & Boucadair Expires August 2, 2019 [Page 52] ./draft-ietf-ospf-yang-29.txt0000644000764400076440000071133513552116300015274 0ustar iustyiusty Internet D. Yeung Internet-Draft Arrcus Intended status: Standards Track Y. Qu Expires: April 19, 2020 Futurewei J. Zhang Juniper Networks I. Chen The MITRE Corporation A. Lindem Cisco Systems October 17, 2019 YANG Data Model for OSPF Protocol draft-ietf-ospf-yang-29 Abstract This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. 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 https://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 19, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Yeung, et al. Expires April 19, 2020 [Page 1] Internet-Draft OSPF YANG Data Model October 2019 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 3 2.1. OSPF Operational State . . . . . . . . . . . . . . . . . 3 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5 2.4. Optional Features . . . . . . . . . . . . . . . . . . . . 5 2.5. OSPF Router Configuration/Operational State . . . . . . . 7 2.6. OSPF Area Configuration/Operational State . . . . . . . . 10 2.7. OSPF Interface Configuration/Operational State . . . . . 16 2.8. OSPF Notifications . . . . . . . . . . . . . . . . . . . 19 2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 23 3. OSPF YANG Module . . . . . . . . . . . . . . . . . . . . . . 23 4. Security Considerations . . . . . . . . . . . . . . . . . . . 120 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 123 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.1. Normative References . . . . . . . . . . . . . . . . . . 124 7.2. Informative References . . . . . . . . . . . . . . . . . 129 Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131 1. Overview YANG [RFC6020][RFC7950] is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241], RESTCONF [RFC8040], and other Network Management protocols. Furthermore, YANG data models can be used as the basis for implementation of other interfaces, such as CLI and programmatic APIs. This document defines a YANG data model that can be used to configure and manage OSPF and it is an augmentation to the core routing data model. It fully conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. A core routing data model is defined in [RFC8349], and it provides the basis for the development of data models for routing protocols. The interface data model is defined in [RFC8343] and is used for referencing interfaces from the routing Yeung, et al. Expires April 19, 2020 [Page 2] Internet-Draft OSPF YANG Data Model October 2019 protocol. The key-chain data model used for OSPF authentication is defined in [RFC8177] and provides both a reference to configured key- chains and an enumeration of cryptographic algorithms. Both OSPFv2 [RFC2328] and OSPFv3 [RFC5340] are supported. In addition to the core OSPF protocol, features described in other OSPF RFCs are also supported. These includes demand circuit [RFC1793], traffic engineering [RFC3630], multiple address family [RFC5838], graceful restart [RFC3623] [RFC5187], NSSA [RFC3101], and OSPFv2 or OSPFv3 as a PE-CE Protocol [RFC4577], [RFC6565]. These non-core features are optional in the OSPF data model. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Tree Diagrams This document uses the graphical representation of data models defined in [RFC8340]. 2. Design of Data Model Although the basis of OSPF configuration elements like routers, areas, and interfaces remains the same, the detailed configuration model varies among router vendors. Differences are observed in terms of how the protocol instance is tied to the routing domain and how multiple protocol instances are be instantiated among others. The goal of this document is to define a data model that provides a common user interface to the OSPFv2 and OSPFv3 protocols. There is very little information that is designated as "mandatory", providing freedom for vendors to adapt this data model to their respective product implementations. 2.1. OSPF Operational State The OSPF operational state is included in the same tree as OSPF configuration consistent with the Network Management Datastore Architecture [RFC8342]. Consequently, only the routing container in the ietf-routing model [RFC8349] is augmented. The routing-state container is not augmented. Yeung, et al. Expires April 19, 2020 [Page 3] Internet-Draft OSPF YANG Data Model October 2019 2.2. Overview The OSPF YANG module defined in this document has all the common building blocks for the OSPF protocol. The OSPF YANG module augments the /routing/control-plane-protocols/ control-plane-protocol path defined in the ietf-routing module. The ietf-ospf model defines a single instance of OSPF which may be instantiated as an OSPFv2 or OSPFv3 instance. Multiple instances are instantiated as multiple control-plane protocols instances. module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw af? identityref . . +--rw areas | +--rw area* [area-id] | +--rw area-id area-id-type | . | . | +--rw virtual-links | | +--rw virtual-link* [transit-area-id router-id] | | . | | . | +--rw sham-links {pe-ce-protocol}? | | +--rw sham-link* [local-id remote-id] | | . | | . | +--rw interfaces | +--rw interface* [name] | . | . +--rw topologies {multi-topology}? +--rw topology* [name] . . The ospf container includes one OSPF protocol instance. The instance includes OSPF router level configuration and operational state. Each OSPF instance maps to a control-plane-protcol instance as defined in [RFC8349]. Yeung, et al. Expires April 19, 2020 [Page 4] Internet-Draft OSPF YANG Data Model October 2019 The area and area/interface containers define the OSPF configuration and operational state for OSPF areas and interfaces respectively. The topologies container defines the OSPF configuration and operational state for OSPF topologies when the multi-topology feature is supported. 2.3. OSPFv2 and OSPFv3 The data model defined herein supports both OSPFv2 and OSPFv3. The field 'version' is used to indicate the OSPF version and is mandatory. Based on the configured version, the data model varies to accommodate the differences between OSPFv2 and OSPFv3. 2.4. Optional Features Optional features are beyond the basic OSPF configuration and it is the responsibility of each vendor to decide whether to support a given feature on a particular device. This model defines the following optional features: 1. multi-topology: Support Multi-Topology Routing (MTR) [RFC4915]. 2. multi-area-adj: Support OSPF multi-area adjacency [RFC5185]. 3. explicit-router-id: Support explicit per-instance Router-ID specification. 4. demand-circuit: Support OSPF demand circuits [RFC1793]. 5. mtu-ignore: Support disabling OSPF Database Description packet MTU mismatch checking specified in section 10.6 of [RFC2328]. 6. lls: Support OSPF link-local signaling (LLS) [RFC5613]. 7. prefix-suppression: Support OSPF prefix advertisement suppression [RFC6860]. 8. ttl-security: Support OSPF Time to Live (TTL) security check support [RFC5082]. 9. nsr: Support OSPF Non-Stop Routing (NSR). The OSPF NSR feature allows a router with redundant control-plane capability (e.g., dual Route-Processor (RP) cards) to maintain its state and adjacencies during planned and unplanned control-plane processing restarts. It differs from graceful-restart or Non- Yeung, et al. Expires April 19, 2020 [Page 5] Internet-Draft OSPF YANG Data Model October 2019 Stop Forwarding (NSF) in that no protocol signaling or assistance from adjacent OSPF neighbors is required to recover control-plane state. 10. graceful-restart: Support Graceful OSPF Restart [RFC3623], [RFC5187]. 11. auto-cost: Support OSPF interface cost calculation according to reference bandwidth [RFC2328]. 12. max-ecmp: Support configuration of the maximum number of Equal- Cost Multi-Path (ECMP) paths. 13. max-lsa: Support configuration of the maximum number of LSAs the OSPF instance will accept [RFC1765]. 14. te-rid: Support configuration of the Traffic Engineering (TE) Router-ID, i.e., the Router Address described in Section 2.4.1 of [RFC3630] or the Router IPv6 Address TLV described in Section 3 of [RFC5329]. 15. ldp-igp-sync: Support LDP IGP synchronization [RFC5443]. 16. ospfv2-authentication-trailer: Support OSPFv2 Authentication trailer as specified in [RFC5709] or [RFC7474]. 17. ospfv3-authentication-ipsec: Support IPsec for OSPFv3 authentication [RFC4552]. 18. ospfv3-authentication-trailer: Support OSPFv3 Authentication trailer as specified in [RFC7166]. 19. fast-reroute: Support IP Fast Reroute (IP-FRR) [RFC5714]. 20. node-flag: Support node-flag for OSPF prefixes. [RFC7684]. 21. node-tag: Support node admin tag for OSPF instances [RFC7777]. 22. lfa: Support Loop-Free Alternates (LFAs) [RFC5286]. 23. remote-lfa: Support Remote Loop-Free Alternates (R-LFA) [RFC7490]. 24. stub-router: Support RFC 6987 OSPF Stub Router advertisement [RFC6987]. 25. pe-ce-protocol: Support OSPF as a PE-CE protocol [RFC4577], [RFC6565]. Yeung, et al. Expires April 19, 2020 [Page 6] Internet-Draft OSPF YANG Data Model October 2019 26. ietf-spf-delay: Support IETF SPF delay algorithm [RFC8405]. 27. bfd: Support BFD detection of OSPF neighbor reachability [RFC5880], [RFC5881], and [I-D.ietf-bfd-yang]. 28. hybrid-interface: Support OSPF Hybrid Broadcast and Point-to- Point Interfaces [RFC6845]. It is expected that vendors will support additional features through vendor-specific augmentations. 2.5. OSPF Router Configuration/Operational State The ospf container is the top-level container in this data model. It represents an OSPF protocol instance and contains the router level configuration and operational state. The operational state includes the instance statistics, IETF SPF delay statistics, AS-Scoped Link State Database, local RIB, SPF Log, and the LSA log. module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw af iana-rt-types:address-family +--rw enable? boolean +--rw explicit-router-id? rt-types:router-id | {explicit-router-id}? +--rw preference | +--rw (scope)? | +--:(single-value) | | +--rw all? uint8 | +--:(multi-values) | +--rw (granularity)? | | +--:(detail) | | | +--rw intra-area? uint8 | | | +--rw inter-area? uint8 | | +--:(coarse) | | +--rw internal? uint8 | +--rw external? uint8 +--rw nsr {nsr}? | +--rw enable? boolean +--rw graceful-restart {graceful-restart}? | +--rw enable? boolean | +--rw helper-enable? boolean | +--rw restart-interval? uint16 | +--rw helper-strict-lsa-checking? boolean Yeung, et al. Expires April 19, 2020 [Page 7] Internet-Draft OSPF YANG Data Model October 2019 +--rw auto-cost {auto-cost}? | +--rw enable? boolean | +--rw reference-bandwidth? uint32 +--rw spf-control | +--rw paths? uint16 {max-ecmp}? | +--rw ietf-spf-delay {ietf-spf-delay}? | +--rw initial-delay? uint16 | +--rw short-delay? uint16 | +--rw long-delay? uint16 | +--rw hold-down? uint16 | +--rw time-to-learn? uint16 | +--ro current-state? enumeration | +--ro remaining-time-to-learn? uint16 | +--ro remaining-hold-down? uint16 | +--ro last-event-received? yang:timestamp | +--ro next-spf-time? yang:timestamp | +--ro last-spf-time? yang:timestamp +--rw database-control | +--rw max-lsa? uint32 {max-lsa}? +--rw stub-router {stub-router}? | +--rw (trigger)? | +--:(always) | +--rw always! +--rw mpls | +--rw te-rid {te-rid}? | | +--rw ipv4-router-id? inet:ipv4-address | | +--rw ipv6-router-id? inet:ipv6-address | +--rw ldp | +--rw igp-sync? boolean {ldp-igp-sync}? +--rw fast-reroute {fast-reroute}? | +--rw lfa {lfa}? +--ro protected-routes | +--ro af-stats* [af prefix alternate] | +--ro af iana-rt-types:address-family | +--ro prefix string | +--ro alternate string | +--ro alternate-type? enumeration | +--ro best? boolean | +--ro non-best-reason? string | +--ro protection-available? bits | +--ro alternate-metric1? uint32 | +--ro alternate-metric2? uint32 | +--ro alternate-metric3? uint32 +--ro unprotected-routes | +--ro af-stats* [af prefix] | +--ro af iana-rt-types:address-family | +--ro prefix string +--ro protection-statistics* [frr-protection-method] Yeung, et al. Expires April 19, 2020 [Page 8] Internet-Draft OSPF YANG Data Model October 2019 | +--ro frr-protection-method string | +--ro af-stats* [af] | +--ro af iana-rt-types:address-family | +--ro total-routes? uint32 | +--ro unprotected-routes? uint32 | +--ro protected-routes? uint32 | +--ro linkprotected-routes? uint32 | +--ro nodeprotected-routes? uint32 +--rw node-tags {node-tag}? | +--rw node-tag* [tag] | +--rw tag uint32 +--ro router-id? +--ro local-rib | +--ro route* [prefix] | +--ro prefix inet:ip-prefix | +--ro next-hops | | +--ro next-hop* [next-hop] | | +--ro outgoing-interface? if:interface-ref | | +--ro next-hop inet:ip-address | +--ro metric? uint32 | +--ro route-type? route-type | +--ro route-tag? uint32 +--ro statistics | +--ro discontinuity-time yang:date-and-time | +--ro originate-new-lsa-count? yang:counter32 | +--ro rx-new-lsas-count? yang:counter32 | +--ro as-scope-lsa-count? yang:gauge32 | +--ro as-scope-lsa-chksum-sum? uint32 | +--ro database | +--ro as-scope-lsa-type* | +--ro lsa-type? uint16 | +--ro lsa-count? yang:gauge32 | +--ro lsa-cksum-sum? int32 +--ro database | +--ro as-scope-lsa-type* [lsa-type] | +--ro as-scope-lsas | +--ro as-scope-lsa* [lsa-id adv-router] | +--ro lsa-id union | +--ro adv-router inet:ipv4-address | +--ro decoded-completed? boolean | +--ro raw-data? yang:hex-string | +--ro (version)? | +--:(ospfv2) | | +--ro ospfv2 . . . . | +--:(ospfv3) | +--ro ospfv3 Yeung, et al. Expires April 19, 2020 [Page 9] Internet-Draft OSPF YANG Data Model October 2019 . . +--ro spf-log | +--ro event* [id] | +--ro id uint32 | +--ro spf-type? enumeration | +--ro schedule-timestamp? yang:timestamp | +--ro start-timestamp? yang:timestamp +--ro end-timestamp? yang:timestamp | +--ro trigger-lsa* | +--ro area-id? area-id-type | +--ro link-id? union | +--ro type? uint16 | +--ro lsa-id? yang:dotted-quad | +--ro adv-router? yang:dotted-quad | +--ro seq-num? uint32 +--ro lsa-log | +--ro event* [id] | +--ro id uint32 | +--ro lsa | | +--ro area-id? area-id-type | | +--ro link-id? union | | +--ro type? uint16 | | +--ro lsa-id? yang:dotted-quad | | +--ro adv-router? yang:dotted-quad | | +--ro seq-num? uint32 | +--ro received-timestamp? yang:timestamp | +--ro reason? identityref . . 2.6. OSPF Area Configuration/Operational State The area container contains OSPF area configuration and the list of interface containers representing all the OSPF interfaces in the area. The area operational state includes the area statistics and the Area Link State Database (LSDB). module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw areas | +--rw area* [area-id] | +--rw area-id area-id-type | +--rw area-type? identityref Yeung, et al. Expires April 19, 2020 [Page 10] Internet-Draft OSPF YANG Data Model October 2019 | +--rw summary? boolean | +--rw default-cost? uint32 | +--rw ranges | | +--rw range* [prefix] | | +--rw prefix inet:ip-prefix | | +--rw advertise? boolean | | +--rw cost? uint24 | +--rw topologies {ospf:multi-topology}? | | +--rw topology* [name] | | +--rw name -> ../../../../../../../../ | | ../../../rt:ribs/rib/name | | +--rw summary? boolean | | +--rw default-cost? ospf-metric | | +--rw ranges | | +--rw range* [prefix] | | +--rw prefix inet:ip-prefix | | +--rw advertise? boolean | | +--rw cost? ospf-metric | +--ro statistics | | +--ro discontinuity-time yang:date-and-time | | +--ro spf-runs-count? yang:counter32 | | +--ro abr-count? yang:gauge32 | | +--ro asbr-count? yang:gauge32 | | +--ro ar-nssa-translator-event-count? | | yang:counter32 | | +--ro area-scope-lsa-count? yang:gauge32 | | +--ro area-scope-lsa-cksum-sum? int32 | | +--ro database | | +--ro area-scope-lsa-type* | | +--ro lsa-type? uint16 | | +--ro lsa-count? yang:gauge32 | | +--ro lsa-cksum-sum? int32 | +--ro database | | +--ro area-scope-lsa-type* [lsa-type] | | +--ro lsa-type uint16 | | +--ro area-scope-lsas | | +--ro area-scope-lsa* [lsa-id adv-router] | | +--ro lsa-id union . . . . . . | | +--ro (version)? | | +--:(ospfv2) | | | +--ro ospfv2 | | | +--ro header . . . . . . . . | | | +--ro body | | | +--ro router Yeung, et al. Expires April 19, 2020 [Page 11] Internet-Draft OSPF YANG Data Model October 2019 . . . . . . . . | | | +--ro network . . . . . . . . | | | +--ro summary . . . . . . . . | | | +--ro external . . . . . . . . | | | +--ro opaque . . . . . . . . | | +--:(ospfv3) | | +--ro ospfv3 | | +--ro header . . . . . . | | +--ro body | | +--ro router . . . . . . | | +--ro network . . . . . . | | +--ro inter-area-prefix . . . . . . | | +--ro inter-area-router . . . . . . | | +--ro as-external . . . . . . | | +--ro nssa . . . . . . | | +--ro link . . . . . . | | +--ro intra-area-prefix . . . . . . | | +--ro router-information . . . . . . | +--rw virtual-links Yeung, et al. Expires April 19, 2020 [Page 12] Internet-Draft OSPF YANG Data Model October 2019 | | +--rw virtual-link* [transit-area-id router-id] | | +--rw transit-area-id -> ../../../../ | | area/area-id | | +--rw router-id rt-types:router-id | | +--rw hello-interval? uint16 | | +--rw dead-interval? uint32 | | +--rw retransmit-interval? uint16 | | +--rw transmit-delay? uint16 | | +--rw lls? boolean {lls}? | | +--rw ttl-security {ttl-security}? | | | +--rw enable? boolean | | | +--rw hops? uint8 | | +--rw enable? boolean | | +--rw authentication | | | +--rw (auth-type-selection)? | | | +--:(ospfv2-auth) | | | | +--rw ospfv2-auth-trailer-rfc? | | | | | ospfv2-auth-trailer-rfc-version | | | | | {ospfv2-authentication-trailer}? | | | | +--rw (ospfv2-auth-specification)? | | | | +--:(auth-key-chain) {key-chain}? | | | | | +--rw ospfv2-key-chain? | | | | | key-chain:key-chain-ref | | | | +--:(auth-key-explicit) | | | | +--rw ospfv2-key-id? uint32 | | | | +--rw ospfv2-key? string | | | | +--rw ospfv2-crypto-algorithm? | | | | identityref | | | +--:(ospfv3-auth-ipsec) | | | | {ospfv3-authentication-ipsec}? | | | | +--rw sa? string | | | +--:(ospfv3-auth-trailer) | | | | {ospfv3-authentication-trailer}? | | | +--rw (ospfv3-auth-specification)? | | | +--:(auth-key-chain) {key-chain}? | | | | +--rw ospfv3-key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw ospfv3-sa-id? uint16 | | | +--rw ospfv3-key? string | | | +--rw ospfv3-crypto-algorithm? | | | identityref | | +--ro cost? uint16 | | +--ro state? if-state-type | | +--ro hello-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro wait-timer? rt-types: | | | rtimer-value-seconds16 Yeung, et al. Expires April 19, 2020 [Page 13] Internet-Draft OSPF YANG Data Model October 2019 | | +--ro dr-router-id? rt-types:router-id | | +--ro dr-ip-addr? inet:ip-address | | +--ro bdr-router-id? rt-types:router-id | | +--ro bdr-ip-addr? inet:ip-address | | +--ro statistics | | | +--ro discontinuity-time yang:date-and-time | | | +--ro if-event-count? yang:counter32 | | | +--ro link-scope-lsa-count? yang:gauge32 | | | +--ro link-scope-lsa-cksum-sum? | | | uint32 | | | +--ro database | | | +--ro link-scope-lsa-type* | | | +--ro lsa-type? uint16 | | | +--ro lsa-count? yang:gauge32 | | | +--ro lsa-cksum-sum? int32 | | +--ro neighbors | | | +--ro neighbor* [neighbor-router-id] | | | +--ro neighbor-router-id | | | rt-types:router-id | | | +--ro address? inet:ip-address | | | +--ro dr-router-id? rt-types:router-id | | | +--ro dr-ip-addr? inet:ip-address | | | +--ro bdr-router-id? rt-types:router-id | | | +--ro bdr-ip-addr? inet:ip-address | | | +--ro state? nbr-state-type | | | +--ro dead-timer? rt-types: | | | | rtimer-value-seconds16 | | | +--ro statistics | | | +--ro discontinuity-time | | | yang:date-and-time | | | +--ro nbr-event-count? | | | yang:counter32 | | | +--ro nbr-retrans-qlen? | | | yang:gauge32 | | +--ro database | | +--ro link-scope-lsa-type* [lsa-type] | | +--ro lsa-type uint16 | | +--ro link-scope-lsas . . . . | +--rw sham-links {pe-ce-protocol}? | | +--rw sham-link* [local-id remote-id] | | +--rw local-id inet:ip-address | | +--rw remote-id inet:ip-address | | +--rw hello-interval? uint16 | | +--rw dead-interval? uint32 | | +--rw retransmit-interval? uint16 | | +--rw transmit-delay? uint16 Yeung, et al. Expires April 19, 2020 [Page 14] Internet-Draft OSPF YANG Data Model October 2019 | | +--rw lls? boolean {lls}? | | +--rw ttl-security {ttl-security}? | | | +--rw enable? boolean | | | +--rw hops? uint8 | | +--rw enable? boolean | | +--rw authentication | | | +--rw (auth-type-selection)? | | | +--:(ospfv2-auth) | | | | +--rw ospfv2-auth-trailer-rfc? | | | | | ospfv2-auth-trailer-rfc-version | | | | | {ospfv2-authentication-trailer}? | | | | +--rw (ospfv2-auth-specification)? | | | | +--:(auth-key-chain) {key-chain}? | | | | | +--rw ospfv2-key-chain? | | | | | key-chain:key-chain-ref | | | | +--:(auth-key-explicit) | | | | +--rw ospfv2-key-id? uint32 | | | | +--rw ospfv2-key? string | | | | +--rw ospfv2-crypto-algorithm? | | | | identityref | | | +--:(ospfv3-auth-ipsec) | | | | {ospfv3-authentication-ipsec}? | | | | +--rw sa? string | | | +--:(ospfv3-auth-trailer) | | | | {ospfv3-authentication-trailer}? | | | +--rw (ospfv3-auth-specification)? | | | +--:(auth-key-chain) {key-chain}? | | | | +--rw ospfv3-key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw ospfv3-sa-id? uint16 | | | +--rw ospfv3-key? string | | | +--rw ospfv3-crypto-algorithm? | | | identityref | | +--rw cost? uint16 | | +--rw mtu-ignore? boolean | | {mtu-ignore}? | | +--rw prefix-suppression? boolean | | {prefix-suppression}? | | +--ro state? if-state-type | | +--ro hello-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro wait-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro dr-router-id? rt-types:router-id | | +--ro dr-ip-addr? inet:ip-address | | +--ro bdr-router-id? rt-types:router-id | | +--ro bdr-ip-addr? inet:ip-address Yeung, et al. Expires April 19, 2020 [Page 15] Internet-Draft OSPF YANG Data Model October 2019 | | +--ro statistics | | | +--ro discontinuity-time yang:date-and-time | | | +--ro if-event-count? yang:counter32 | | | +--ro link-scope-lsa-count? yang:gauge32 | | | +--ro link-scope-lsa-cksum-sum? | | | uint32 | | | +--ro database | | | +--ro link-scope-lsa-type* | | | +--ro lsa-type? uint16 | | | +--ro lsa-count? yang:gauge32 | | | +--ro lsa-cksum-sum? int32 | | +--ro neighbors | | | +--ro neighbor* [neighbor-router-id] | | | +--ro neighbor-router-id | | | rt-types:router-id | | | +--ro address? inet:ip-address | | | +--ro dr-router-id? rt-types:router-id | | | +--ro dr-ip-addr? inet:ip-address | | | +--ro bdr-router-id? rt-types:router-id | | | +--ro bdr-ip-addr? inet:ip-address | | | +--ro state? nbr-state-type | | | +--ro cost? uint32 | | | +--ro dead-timer? rt-types: | | | | rtimer-value-seconds16 | | | +--ro statistics | | | +--ro nbr-event-count? | | | yang:counter32 | | | +--ro nbr-retrans-qlen? | | | yang:gauge32 | | +--ro database | | +--ro link-scope-lsa-type* [lsa-type] | | +--ro lsa-type uint16 | | +--ro link-scope-lsas . . . . 2.7. OSPF Interface Configuration/Operational State The interface container contains OSPF interface configuration and operational state. The interface operational state includes the statistics, list of neighbors, and Link-Local Link State Database (LSDB). module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . Yeung, et al. Expires April 19, 2020 [Page 16] Internet-Draft OSPF YANG Data Model October 2019 . +--rw areas | +--rw area* [area-id] | . | . | +--rw interfaces | +--rw interface* [name] | +--rw name if:interface-ref | +--rw interface-type? enumeration | +--rw passive? boolean | +--rw demand-circuit? boolean | {demand-circuit}? | +--rw priority? uint8 | +--rw multi-areas {multi-area-adj}? | | +--rw multi-area* [multi-area-id] | | +--rw multi-area-id area-id-type | | +--rw cost? uint16 | +--rw static-neighbors | | +--rw neighbor* [identifier] | | +--rw identifier inet:ip-address | | +--rw cost? uint16 | | +--rw poll-interval? uint16 | | +--rw priority? uint8 | +--rw node-flag? boolean | {node-flag}? | +--rw bfd {bfd}? | | +--rw enable? boolean | +--rw fast-reroute {fast-reroute}? | | +--rw lfa {lfa}? | | +--rw candidate-enable? boolean | | +--rw enable? boolean | | +--rw remote-lfa {remote-lfa}? | | +--rw enable? boolean | +--rw hello-interval? uint16 | +--rw dead-interval? uint32 | +--rw retransmit-interval? uint16 | +--rw transmit-delay? uint16 | +--rw lls? boolean {lls}? | +--rw ttl-security {ttl-security}? | | +--rw enable? boolean | | +--rw hops? uint8 | +--rw enable? boolean | +--rw authentication | | +--rw (auth-type-selection)? | | +--:(ospfv2-auth) | | | +--rw ospfv2-auth-trailer-rfc? | | | | ospfv2-auth-trailer-rfc-version | | | | {ospfv2-authentication-trailer}? Yeung, et al. Expires April 19, 2020 [Page 17] Internet-Draft OSPF YANG Data Model October 2019 | | | +--rw (ospfv2-auth-specification)? | | | +--:(auth-key-chain) {key-chain}? | | | | +--rw ospfv2-key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw ospfv2-key-id? uint32 | | | +--rw ospfv2-key? string | | | +--rw ospfv2-crypto-algorithm? | | | identityref | | +--:(ospfv3-auth-ipsec) | | | {ospfv3-authentication-ipsec}? | | | +--rw sa? string | | +--:(ospfv3-auth-trailer) | | | {ospfv3-authentication-trailer}? | | +--rw (ospfv3-auth-specification)? | | +--:(auth-key-chain) {key-chain}? | | | +--rw ospfv3-key-chain? | | | key-chain:key-chain-ref | | +--:(auth-key-explicit) | | +--rw ospfv3-sa-id? uint16 | | +--rw ospfv3-key? string | | +--rw ospfv3-crypto-algorithm? | | identityref | +--rw cost? uint16 | +--rw mtu-ignore? boolean | | {mtu-ignore}? | +--rw prefix-suppression? boolean | | {prefix-suppression}? | +--ro state? if-state-type | +--ro hello-timer? rt-types: | | rtimer-value-seconds16 | +--ro wait-timer? rt-types: | | rtimer-value-seconds16 | +--ro dr-router-id? rt-types:router-id | +--ro dr-ip-addr? inet:ip-address | +--ro bdr-router-id? rt-types:router-id | +--ro bdr-ip-addr? inet:ip-address | +--ro statistics | | +--ro if-event-count? yang:counter32 | | +--ro link-scope-lsa-count? yang:gauge32 | | +--ro link-scope-lsa-cksum-sum? | | uint32 | | +--ro database | | +--ro link-scope-lsa-type* | | +--ro lsa-type? uint16 | | +--ro lsa-count? yang:gauge32 | | +--ro lsa-cksum-sum? int32 | +--ro neighbors Yeung, et al. Expires April 19, 2020 [Page 18] Internet-Draft OSPF YANG Data Model October 2019 | | +--ro neighbor* [neighbor-router-id] | | +--ro neighbor-router-id | | rt-types:router-id | | +--ro address? inet:ip-address | | +--ro dr-router-id? rt-types:router-id | | +--ro dr-ip-addr? inet:ip-address | | +--ro bdr-router-id? rt-types:router-id | | +--ro bdr-ip-addr? inet:ip-address | | +--ro state? nbr-state-type | | +--ro dead-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro statistics | | +--ro nbr-event-count? | | yang:counter32 | | +--ro nbr-retrans-qlen? | | yang:gauge32 | +--ro database | . +--ro link-scope-lsa-type* [lsa-type] | . +--ro lsa-type uint16 | . +--ro link-scope-lsas . . . . | +--rw topologies {ospf:multi-topology}? | | +--rw topology* [name] | | +--rw name -> ../../../../../../../../ | | ../../../rt:ribs/rib/name | | +--rw cost? uint32 | +--rw instance-id? uint8 . . 2.8. OSPF Notifications This YANG model defines a list of notifications that inform YANG clients of important events detected during protocol operation. The defined notifications cover the common set of traps from the OSPFv2 MIB [RFC4750] and OSPFv3 MIB [RFC5643]. notifications: +---n if-state-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af Yeung, et al. Expires April 19, 2020 [Page 19] Internet-Draft OSPF YANG Data Model October 2019 | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro state? if-state-type +---n if-config-error | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro packet-source? yang:dotted-quad | +--ro packet-type? packet-type | +--ro error? enumeration +---n nbr-state-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af Yeung, et al. Expires April 19, 2020 [Page 20] Internet-Draft OSPF YANG Data Model October 2019 | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro neighbor-router-id? rt-types:router-id | +--ro neighbor-ip-addr? yang:dotted-quad | +--ro state? nbr-state-type +---n nbr-restart-helper-status-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro neighbor-router-id? rt-types:router-id | +--ro neighbor-ip-addr? yang:dotted-quad | +--ro status? restart-helper-status-type | +--ro age? uint32 | +--ro exit-reason? restart-exit-reason-type +---n if-rx-bad-packet | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? Yeung, et al. Expires April 19, 2020 [Page 21] Internet-Draft OSPF YANG Data Model October 2019 | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro packet-source? yang:dotted-quad | +--ro packet-type? packet-type +---n lsdb-approaching-overflow | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro ext-lsdb-limit? uint32 +---n lsdb-overflow | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro ext-lsdb-limit? uint32 +---n nssa-translator-status-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af Yeung, et al. Expires April 19, 2020 [Page 22] Internet-Draft OSPF YANG Data Model October 2019 | +--ro area-id? area-id-type | +--ro status? nssa-translator-state-type +---n restart-status-change +--ro routing-protocol-name? + -> /rt:routing/control-plane-protocols/ + control-plane-protocol/name +--ro af? + -> /rt:routing/control-plane-protocols/ + control-plane-protocol + [rt:name=current()/../routing-protocol-name]/ + ospf:ospf/af +--ro status? restart-status-type +--ro restart-interval? uint16 +--ro exit-reason? restart-exit-reason-type 2.9. OSPF RPC Operations The "ietf-ospf" module defines two RPC operations: o clear-database: reset the content of a particular OSPF Link State Database. o clear-neighbor: Reset a particular OSPF neighbor or group of neighbors associated with an OSPF interface. rpcs: +---x clear-neighbor | +---w input | +---w routing-protocol-name | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +---w interface? if:interface-ref +---x clear-database +---w input +---w routing-protocol-name -> /rt:routing/control-plane-protocols/ control-plane-protocol/name 3. OSPF YANG Module The following RFCs and drafts are not referenced in the document text but are referenced in the ietf-ospf.yang module: [RFC0905], [RFC4576], [RFC4973], [RFC5250], [RFC5309], [RFC5642], [RFC5881], [RFC6991], [RFC7770], [RFC7884], [RFC8294], and [RFC8476]. file "ietf-ospf@2019-10-17.yang" module ietf-ospf { yang-version 1.1; Yeung, et al. Expires April 19, 2020 [Page 23] Internet-Draft OSPF YANG Data Model October 2019 namespace "urn:ietf:params:xml:ns:yang:ietf-ospf"; prefix ospf; import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management (NMDA Version)"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import iana-routing-types { prefix "iana-rt-types"; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-key-chain { prefix "key-chain"; reference "RFC 8177: YANG Data Model for Key Chains"; } import ietf-bfd-types { prefix "bfd-types"; reference "RFC YYYY: YANG Data Model for Bidirectional Forwarding Detection (BFD). Please replace YYYY with published RFC number for draft-ietf-bfd-yang."; Yeung, et al. Expires April 19, 2020 [Page 24] Internet-Draft OSPF YANG Data Model October 2019 } organization "IETF LSR - Link State Routing Working Group"; contact "WG Web: WG List: Editor: Derek Yeung Author: Acee Lindem Author: Yingzhen Qu Author: Salih K A Author: Ing-Wher Chen "; description "This YANG module defines the generic configuration and operational state for the OSPF protocol common to all vendor implementations. It is intended that the module will be extended by vendors to define vendor-specific OSPF configuration parameters and policies, for example, route maps or route policies. This YANG model conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8242. Copyright (c) 2018 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 (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. 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 Yeung, et al. Expires April 19, 2020 [Page 25] Internet-Draft OSPF YANG Data Model October 2019 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2019-10-17 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for OSPF."; } feature multi-topology { description "Support Multiple-Topology Routing (MTR)."; reference "RFC 4915: Multi-Topology Routing"; } feature multi-area-adj { description "OSPF multi-area adjacency support as in RFC 5185."; reference "RFC 5185: Multi-Area Adjacency"; } feature explicit-router-id { description "Set Router-ID per instance explicitly."; } feature demand-circuit { description "OSPF demand circuit support as in RFC 1793."; reference "RFC 1793: OSPF Demand Circuits"; } feature mtu-ignore { description "Disable OSPF Database Description packet MTU mismatch checking specified in the OSPF protocol specification."; reference "RFC 2328: OSPF Version 2, section 10.6"; } feature lls { description "OSPF link-local signaling (LLS) as in RFC 5613."; reference "RFC 5613: OSPF Link-Local Signaling"; } Yeung, et al. Expires April 19, 2020 [Page 26] Internet-Draft OSPF YANG Data Model October 2019 feature prefix-suppression { description "OSPF prefix suppression support as in RFC 6860."; reference "RFC 6860: Hide Transit-Only Networks in OSPF"; } feature ttl-security { description "OSPF Time to Live (TTL) security check support."; reference "RFC 5082: The Generalized TTL Security Mechanism (GTSM)"; } feature nsr { description "Non-Stop-Routing (NSR) support. The OSPF NSR feature allows a router with redundant control-plane capability (e.g., dual Route-Processor (RP) cards) to maintain its state and adjacencies during planned and unplanned OSPF instance restarts. It differs from graceful-restart or Non-Stop Forwarding (NSF) in that no protocol signaling or assistance from adjacent OSPF neighbors is required to recover control-plane state."; } feature graceful-restart { description "Graceful OSPF Restart as defined in RFC 3623 and RFC 5187."; reference "RFC 3623: Graceful OSPF Restart RFC 5187: OSPFv3 Graceful Restart"; } feature auto-cost { description "Calculate OSPF interface cost according to reference bandwidth."; reference "RFC 2328: OSPF Version 2"; } feature max-ecmp { description "Setting maximum number of ECMP paths."; } feature max-lsa { description "Setting the maximum number of LSAs the OSPF instance Yeung, et al. Expires April 19, 2020 [Page 27] Internet-Draft OSPF YANG Data Model October 2019 will accept."; reference "RFC 1765: OSPF Database Overload"; } feature te-rid { description "Support configuration of the Traffic Engineering (TE) Router-ID, i.e., the Router Address described in Section 2.4.1 of RFC3630 or the Router IPv6 Address TLV described in Section 3 of RFC5329."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5329: Traffic Engineering (TE) Extensions to OSPF Version 3"; } feature ldp-igp-sync { description "LDP IGP synchronization."; reference "RFC 5443: LDP IGP Synchronization"; } feature ospfv2-authentication-trailer { description "Support OSPFv2 authentication trailer for OSPFv2 authentication."; reference "RFC 5709: Supporting Authentication Trailer for OSPFv2 RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management"; } feature ospfv3-authentication-ipsec { description "Support IPsec for OSPFv3 authentication."; reference "RFC 4552: Authentication/Confidentiality for OSPFv3"; } feature ospfv3-authentication-trailer { description "Support OSPFv3 authentication trailer for OSPFv3 authentication."; reference "RFC 7166: Supporting Authentication Trailer for OSPFv3"; } feature fast-reroute { Yeung, et al. Expires April 19, 2020 [Page 28] Internet-Draft OSPF YANG Data Model October 2019 description "Support for IP Fast Reroute (IP-FRR)."; reference "RFC 5714: IP Fast Reroute Framework"; } feature key-chain { description "Support of keychain for authentication."; reference "RFC8177: YANG Data Model for Key Chains"; } feature node-flag { description "Support for node-flag for OSPF prefixes."; reference "RFC 7684: OSPFv2 Prefix/Link Advertisement"; } feature node-tag { description "Support for node admin tag for OSPF routing instances."; reference "RFC 7777: Advertising Node Administrative Tags in OSPF"; } feature lfa { description "Support for Loop-Free Alternates (LFAs)."; reference "RFC 5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates"; } feature remote-lfa { description "Support for Remote Loop-Free Alternates (R-LFA)."; reference "RFC 7490: Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)"; } feature stub-router { description "Support for RFC 6987 OSPF Stub Router Advertisement."; reference "RFC 6987: OSPF Stub Router Advertisement"; } feature pe-ce-protocol { description "Support for OSPF as a PE-CE protocol"; reference "RFC 4577: OSPF as the Provider/Customer Edge Yeung, et al. Expires April 19, 2020 [Page 29] Internet-Draft OSPF YANG Data Model October 2019 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol"; } feature ietf-spf-delay { description "Support for IETF SPF delay algorithm."; reference "RFC 8405: SPF Back-off algorithm for link state IGPs"; } feature bfd { description "Support for BFD detection of OSPF neighbor reachability."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD) RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"; } feature hybrid-interface { description "Support for OSPF Hybrid interface type."; reference "RFC 6845: OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type"; } identity ospf { base "rt:routing-protocol"; description "Any OSPF protocol version"; } identity ospfv2 { base "ospf"; description "OSPFv2 protocol"; } identity ospfv3 { base "ospf"; description "OSPFv3 protocol"; } identity area-type { description "Base identity for OSPF area type."; } identity normal-area { Yeung, et al. Expires April 19, 2020 [Page 30] Internet-Draft OSPF YANG Data Model October 2019 base area-type; description "OSPF normal area."; } identity stub-nssa-area { base area-type; description "OSPF stub or NSSA area."; } identity stub-area { base stub-nssa-area; description "OSPF stub area."; } identity nssa-area { base stub-nssa-area; description "OSPF Not-So-Stubby Area (NSSA)."; reference "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; } identity ospf-lsa-type { description "Base identity for OSPFv2 and OSPFv3 Link State Advertisement (LSA) types"; } identity ospfv2-lsa-type { base ospf-lsa-type; description "OSPFv2 LSA types"; } identity ospfv2-router-lsa { base ospfv2-lsa-type; description "OSPFv2 Router LSA - Type 1"; } identity ospfv2-network-lsa { base ospfv2-lsa-type; description "OSPFv2 Network LSA - Type 2"; } identity ospfv2-summary-lsa-type { base ospfv2-lsa-type; description Yeung, et al. Expires April 19, 2020 [Page 31] Internet-Draft OSPF YANG Data Model October 2019 "OSPFv2 Summary LSA types"; } identity ospfv2-network-summary-lsa { base ospfv2-summary-lsa-type; description "OSPFv2 Network Summary LSA - Type 3"; } identity ospfv2-asbr-summary-lsa { base ospfv2-summary-lsa-type; description "OSPFv2 AS Boundary Router (ASBR) Summary LSA - Type 4"; } identity ospfv2-external-lsa-type { base ospfv2-lsa-type; description "OSPFv2 External LSA types"; } identity ospfv2-as-external-lsa { base ospfv2-external-lsa-type; description "OSPFv2 AS External LSA - Type 5"; } identity ospfv2-nssa-lsa { base ospfv2-external-lsa-type; description "OSPFv2 Not-So-Stubby-Area (NSSA) LSA - Type 7"; } identity ospfv2-opaque-lsa-type { base ospfv2-lsa-type; description "OSPFv2 Opaque LSA types"; } identity ospfv2-link-scope-opaque-lsa { base ospfv2-opaque-lsa-type; description "OSPFv2 Link-Scoped Opaque LSA - Type 9"; } identity ospfv2-area-scope-opaque-lsa { base ospfv2-opaque-lsa-type; description Yeung, et al. Expires April 19, 2020 [Page 32] Internet-Draft OSPF YANG Data Model October 2019 "OSPFv2 Area-Scoped Opaque LSA - Type 10"; } identity ospfv2-as-scope-opaque-lsa { base ospfv2-opaque-lsa-type; description "OSPFv2 AS-Scoped Opaque LSA - Type 11"; } identity ospfv2-unknown-lsa-type { base ospfv2-lsa-type; description "OSPFv2 Unknown LSA type"; } identity ospfv3-lsa-type { base ospf-lsa-type; description "OSPFv3 LSA types."; } identity ospfv3-router-lsa { base ospfv3-lsa-type; description "OSPFv3 Router LSA - Type 0x2001"; } identity ospfv3-network-lsa { base ospfv3-lsa-type; description "OSPFv3 Network LSA - Type 0x2002"; } identity ospfv3-summary-lsa-type { base ospfv3-lsa-type; description "OSPFv3 Summary LSA types"; } identity ospfv3-inter-area-prefix-lsa { base ospfv3-summary-lsa-type; description "OSPFv3 Inter-area Prefix LSA - Type 0x2003"; } identity ospfv3-inter-area-router-lsa { base ospfv3-summary-lsa-type; description Yeung, et al. Expires April 19, 2020 [Page 33] Internet-Draft OSPF YANG Data Model October 2019 "OSPFv3 Inter-area Router LSA - Type 0x2004"; } identity ospfv3-external-lsa-type { base ospfv3-lsa-type; description "OSPFv3 External LSA types"; } identity ospfv3-as-external-lsa { base ospfv3-external-lsa-type; description "OSPFv3 AS-External LSA - Type 0x4005"; } identity ospfv3-nssa-lsa { base ospfv3-external-lsa-type; description "OSPFv3 Not-So-Stubby-Area (NSSA) LSA - Type 0x2007"; } identity ospfv3-link-lsa { base ospfv3-lsa-type; description "OSPFv3 Link LSA - Type 0x0008"; } identity ospfv3-intra-area-prefix-lsa { base ospfv3-lsa-type; description "OSPFv3 Intra-area Prefix LSA - Type 0x2009"; } identity ospfv3-router-information-lsa { base ospfv3-lsa-type; description "OSPFv3 Router Information LSA - Types 0x800C, 0xA00C, and 0xC00C"; } identity ospfv3-unknown-lsa-type { base ospfv3-lsa-type; description "OSPFv3 Unknown LSA type"; } identity lsa-log-reason { description Yeung, et al. Expires April 19, 2020 [Page 34] Internet-Draft OSPF YANG Data Model October 2019 "Base identity for an LSA log reason."; } identity lsa-refresh { base lsa-log-reason; description "Identity used when the LSA is logged as a result of receiving a refresh LSA."; } identity lsa-content-change { base lsa-log-reason; description "Identity used when the LSA is logged as a result of a change in the content of the LSA."; } identity lsa-purge { base lsa-log-reason; description "Identity used when the LSA is logged as a result of being purged."; } identity informational-capability { description "Base identity for router informational capabilities."; } identity graceful-restart { base informational-capability; description "When set, the router is capable of restarting gracefully."; reference "RFC 3623: Graceful OSPF Restart RFC 5187: OSPFv3 Graceful Restart"; } identity graceful-restart-helper { base informational-capability; description "When set, the router is capable of acting as a graceful restart helper."; reference "RFC 3623: Graceful OSPF Restart RFC 5187: OSPFv3 Graceful Restart"; } Yeung, et al. Expires April 19, 2020 [Page 35] Internet-Draft OSPF YANG Data Model October 2019 identity stub-router { base informational-capability; description "When set, the router is capable of acting as an OSPF Stub Router."; reference "RFC 6987: OSPF Stub Router Advertisement"; } identity traffic-engineering { base informational-capability; description "When set, the router is capable of OSPF traffic engineering."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5329: Traffic Engineering (TE) Extensions to OSPF Version 3"; } identity p2p-over-lan { base informational-capability; description "When set, the router is capable of OSPF Point-to-Point over LAN."; reference "RFC 5309: Point-to-Point Operation over LAN in Link State Routing Protocols"; } identity experimental-te { base informational-capability; description "When set, the router is capable of OSPF experimental traffic engineering."; reference "RFC 4973: OSPF-xTE OSPF Experimental Traffic Engineering"; } identity router-lsa-bit { description "Base identity for Router-LSA bits."; } identity vlink-end-bit { base router-lsa-bit; description "V bit, when set, the router is an endpoint of one or more virtual links."; Yeung, et al. Expires April 19, 2020 [Page 36] Internet-Draft OSPF YANG Data Model October 2019 } identity asbr-bit { base router-lsa-bit; description "E bit, when set, the router is an AS Boundary Router (ASBR)."; } identity abr-bit { base router-lsa-bit; description "B bit, when set, the router is an Area Border Router (ABR)."; } identity nssa-bit { base router-lsa-bit; description "Nt bit, when set, the router is an NSSA border router that is unconditionally translating NSSA LSAs into AS-external LSAs."; } identity ospfv3-lsa-option { description "Base identity for OSPF LSA options flags."; } identity af-bit { base ospfv3-lsa-option; description "AF bit, when set, the router supports OSPFv3 Address Families as in RFC5838."; } identity dc-bit { base ospfv3-lsa-option; description "DC bit, when set, the router supports demand circuits."; } identity r-bit { base ospfv3-lsa-option; description "R bit, when set, the originator is an active router."; } Yeung, et al. Expires April 19, 2020 [Page 37] Internet-Draft OSPF YANG Data Model October 2019 identity n-bit { base ospfv3-lsa-option; description "N bit, when set, the router is attached to an NSSA"; } identity e-bit { base ospfv3-lsa-option; description "E bit, this bit describes the way AS-external LSAs are flooded"; } identity v6-bit { base ospfv3-lsa-option; description "V6 bit, if clear, the router/link should be excluded from IPv6 routing calculation"; } identity ospfv3-prefix-option { description "Base identity for OSPFv3 Prefix Options."; } identity nu-bit { base ospfv3-prefix-option; description "NU Bit, when set, the prefix should be excluded from IPv6 unicast calculations."; } identity la-bit { base ospfv3-prefix-option; description "LA bit, when set, the prefix is actually an IPv6 interface address of the Advertising Router."; } identity p-bit { base ospfv3-prefix-option; description "P bit, when set, the NSSA area prefix should be translated to an AS External LSA and advertised by the translating NSSA Border Router."; } identity dn-bit { Yeung, et al. Expires April 19, 2020 [Page 38] Internet-Draft OSPF YANG Data Model October 2019 base ospfv3-prefix-option; description "DN bit, when set, the inter-area-prefix LSA or AS-external LSA prefix has been advertised as an L3VPN prefix."; } identity ospfv2-lsa-option { description "Base identity for OSPFv2 LSA option flags."; } identity mt-bit { base ospfv2-lsa-option; description "MT bit, When set, the router supports multi-topology as in RFC 4915."; } identity v2-dc-bit { base ospfv2-lsa-option; description "DC bit, When set, the router supports demand circuits."; } identity v2-p-bit { base ospfv2-lsa-option; description "P bit, wnly used in type-7 LSA. When set, an NSSA border router should translate the type-7 LSA to a type-5 LSA."; } identity mc-flag { base ospfv2-lsa-option; description "MC Bit, when set, the router supports MOSPF."; } identity v2-e-flag { base ospfv2-lsa-option; description "E Bit, this bit describes the way AS-external LSAs are flooded."; } identity o-bit { base ospfv2-lsa-option; Yeung, et al. Expires April 19, 2020 [Page 39] Internet-Draft OSPF YANG Data Model October 2019 description "O bit, when set, the router is opaque-capable as in RFC 5250."; } identity v2-dn-bit { base ospfv2-lsa-option; description "DN bit, when a type 3, 5 or 7 LSA is sent from a PE to a CE, the DN bit must be set. See RFC 4576."; } identity ospfv2-extended-prefix-flag { description "Base identity for extended prefix TLV flag."; } identity a-flag { base ospfv2-extended-prefix-flag; description "Attach flag, when set it indicates that the prefix corresponds and a route what is directly connected to the advertising router.."; } identity node-flag { base ospfv2-extended-prefix-flag; description "Node flag, when set, it indicates that the prefix is used to represent the advertising node, e.g., a loopback address."; } typedef ospf-metric { type uint32 { range "0 .. 16777215"; } description "OSPF Metric - 24-bit unsigned integer."; } typedef ospf-link-metric { type uint16 { range "0 .. 65535"; } description "OSPF Link Metric - 16-bit unsigned integer."; } Yeung, et al. Expires April 19, 2020 [Page 40] Internet-Draft OSPF YANG Data Model October 2019 typedef opaque-id { type uint32 { range "0 .. 16777215"; } description "Opaque ID - 24-bit unsigned integer."; } typedef area-id-type { type yang:dotted-quad; description "Area ID type."; } typedef route-type { type enumeration { enum intra-area { description "OSPF intra-area route."; } enum inter-area { description "OSPF inter-area route."; } enum external-1 { description "OSPF type 1 external route."; } enum external-2 { description "OSPF type 2 external route."; } enum nssa-1 { description "OSPF type 1 NSSA route."; } enum nssa-2 { description "OSPF type 2 NSSA route."; } } description "OSPF route type."; } typedef if-state-type { type enumeration { enum down { value "1"; description "Interface down state."; } enum loopback { value "2"; description Yeung, et al. Expires April 19, 2020 [Page 41] Internet-Draft OSPF YANG Data Model October 2019 "Interface loopback state."; } enum waiting { value "3"; description "Interface waiting state."; } enum point-to-point { value "4"; description "Interface point-to-point state."; } enum dr { value "5"; description "Interface Designated Router (DR) state."; } enum bdr { value "6"; description "Interface Backup Designated Router (BDR) state."; } enum dr-other { value "7"; description "Interface Other Designated Router state."; } } description "OSPF interface state type."; } typedef router-link-type { type enumeration { enum point-to-point-link { value "1"; description "Point-to-Point link to Router"; } enum transit-network-link { value "2"; description "Link to transit network identified by Designated-Router (DR)"; } enum stub-network-link { value "3"; description Yeung, et al. Expires April 19, 2020 [Page 42] Internet-Draft OSPF YANG Data Model October 2019 "Link to stub network identified by subnet"; } enum virtual-link { value "4"; description "Virtual link across transit area"; } } description "OSPF Router Link Type."; } typedef nbr-state-type { type enumeration { enum down { value "1"; description "Neighbor down state."; } enum attempt { value "2"; description "Neighbor attempt state."; } enum init { value "3"; description "Neighbor init state."; } enum 2-way { value "4"; description "Neighbor 2-Way state."; } enum exstart { value "5"; description "Neighbor exchange start state."; } enum exchange { value "6"; description "Neighbor exchange state."; } enum loading { value "7"; description "Neighbor loading state."; Yeung, et al. Expires April 19, 2020 [Page 43] Internet-Draft OSPF YANG Data Model October 2019 } enum full { value "8"; description "Neighbor full state."; } } description "OSPF neighbor state type."; } typedef restart-helper-status-type { type enumeration { enum not-helping { value "1"; description "Restart helper status not helping."; } enum helping { value "2"; description "Restart helper status helping."; } } description "Restart helper status type."; } typedef restart-exit-reason-type { type enumeration { enum none { value "1"; description "Restart not attempted."; } enum in-progress { value "2"; description "Restart in progress."; } enum completed { value "3"; description "Restart successfully completed."; } enum timed-out { value "4"; description Yeung, et al. Expires April 19, 2020 [Page 44] Internet-Draft OSPF YANG Data Model October 2019 "Restart timed out."; } enum topology-changed { value "5"; description "Restart aborted due to topology change."; } } description "Describes the outcome of the last attempt at a graceful restart, either by itself or acting as a helper."; } typedef packet-type { type enumeration { enum hello { value "1"; description "OSPF Hello packet."; } enum database-description { value "2"; description "OSPF Database Description packet."; } enum link-state-request { value "3"; description "OSPF Link State Request packet."; } enum link-state-update { value "4"; description "OSPF Link State Update packet."; } enum link-state-ack { value "5"; description "OSPF Link State Acknowledgement packet."; } } description "OSPF packet type."; } typedef nssa-translator-state-type { type enumeration { Yeung, et al. Expires April 19, 2020 [Page 45] Internet-Draft OSPF YANG Data Model October 2019 enum enabled { value "1"; description "NSSA translator enabled state."; } enum elected { value "2"; description "NSSA translator elected state."; } enum disabled { value "3"; description "NSSA translator disabled state."; } } description "OSPF NSSA translator state type."; } typedef restart-status-type { type enumeration { enum not-restarting { value "1"; description "Router is not restarting."; } enum planned-restart { value "2"; description "Router is going through planned restart."; } enum unplanned-restart { value "3"; description "Router is going through unplanned restart."; } } description "OSPF graceful restart status type."; } typedef fletcher-checksum16-type { type string { pattern '(0x)?[0-9a-fA-F]{4}'; } description "Fletcher 16-bit checksum in hex-string format 0xXXXX."; Yeung, et al. Expires April 19, 2020 [Page 46] Internet-Draft OSPF YANG Data Model October 2019 reference "RFC 905: ISO Transport Protocol specification ISO DP 8073"; } typedef ospfv2-auth-trailer-rfc-version { type enumeration { enum rfc5709 { description "Support OSPF Authentication Trailer as described in RFC 5709"; reference "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication"; } enum rfc7474 { description "Support OSPF Authentication Trailer as described in RFC 7474"; reference "RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management Authentication"; } } description "OSPFv2 Authentication Trailer Support"; } grouping tlv { description "Type-Length-Value (TLV)"; leaf type { type uint16; description "TLV type."; } leaf length { type uint16; description "TLV length (octets)."; } leaf value { type yang:hex-string; description "TLV value."; } } grouping unknown-tlvs { description "Unknown TLVs grouping - Used for unknown TLVs or Yeung, et al. Expires April 19, 2020 [Page 47] Internet-Draft OSPF YANG Data Model October 2019 unknown sub-TLVs."; container unknown-tlvs { description "All unknown TLVs."; list unknown-tlv { description "Unknown TLV."; uses tlv; } } } grouping node-tag-tlv { description "OSPF Node Admin Tag TLV grouping."; list node-tag { leaf tag { type uint32; description "Node admin tag value."; } description "List of tags."; } } grouping router-capabilities-tlv { description "OSPF Router Capabilities TLV grouping."; reference "RFC 7770: OSPF Router Capabilities"; container router-informational-capabilities { leaf-list informational-capabilities { type identityref { base informational-capability; } description "Informational capability list. This list will contains the identities for the informational capabilities supported by router."; } description "OSPF Router Informational Flag Definitions."; } list informational-capabilities-flags { leaf informational-flag { type uint32; description "Individual informational capability flag."; } description "List of informational capability flags. This will return all the 32-bit informational flags irrespective Yeung, et al. Expires April 19, 2020 [Page 48] Internet-Draft OSPF YANG Data Model October 2019 of whether or not they are known to the device."; } list functional-capabilities { leaf functional-flag { type uint32; description "Individual functional capability flag."; } description "List of functional capability flags. This will return all the 32-bit functional flags irrespective of whether or not they are known to the device."; } } grouping dynamic-hostname-tlv { description "Dynamic Hostname TLV"; reference "RFC 5642: Dynamic Hostnames for OSPF"; leaf hostname { type string { length "1..255"; } description "Dynamic Hostname"; } } grouping sbfd-discriminator-tlv { description "Seamless BFD Discriminator TLV"; reference "RFC 7884: S-BFD Discriminators in OSPF"; list sbfd-discriminators { leaf sbfd-discriminator { type uint32; description "Individual S-BFD Discriminator."; } description "List of S-BFD Discriminators"; } } grouping maximum-sid-depth-tlv { description "Maximum SID Depth (MSD) TLV"; reference "RFC 8476: Signaling Maximum Segment Depth (MSD) using OSPF"; list msd-type { leaf msd-type { type uint8; description "Maximum Segment Depth (MSD) type"; Yeung, et al. Expires April 19, 2020 [Page 49] Internet-Draft OSPF YANG Data Model October 2019 } leaf msd-value { type uint8; description "Maximum Segment Depth (MSD) value for the type"; } description "List of Maximum Segment Depth (MSD) tuples"; } } grouping ospf-router-lsa-bits { container router-bits { leaf-list rtr-lsa-bits { type identityref { base router-lsa-bit; } description "Router LSA bits list. This list will contain identities for the bits which are set in the Router-LSA bits."; } description "Router LSA Bits."; } description "Router LSA Bits - Currently common for OSPFv2 and OSPFv3 but it may diverge with future augmentations."; } grouping ospfv2-router-link { description "OSPFv2 router link."; leaf link-id { type union { type inet:ipv4-address; type yang:dotted-quad; } description "Router-LSA Link ID"; } leaf link-data { type union { type inet:ipv4-address; type uint32; } description "Router-LSA Link data."; } leaf type { type router-link-type; description "Router-LSA Link type."; Yeung, et al. Expires April 19, 2020 [Page 50] Internet-Draft OSPF YANG Data Model October 2019 } } grouping ospfv2-lsa-body { description "OSPFv2 LSA body."; container router { when "derived-from-or-self(../../header/type, " + "'ospfv2-router-lsa')" { description "Only applies to Router-LSAs."; } description "Router LSA."; uses ospf-router-lsa-bits; leaf num-of-links { type uint16; description "Number of links in Router LSA."; } container links { description "All router Links."; list link { description "Router LSA link."; uses ospfv2-router-link; container topologies { description "All topologies for the link."; list topology { description "Topology specific information."; leaf mt-id { type uint8; description "The MT-ID for the topology enabled on the link."; } leaf metric { type uint16; description "Metric for the topology."; } } } } } } container network { when "derived-from-or-self(../../header/type, " + "'ospfv2-network-lsa')" { description "Only applies to Network LSAs."; Yeung, et al. Expires April 19, 2020 [Page 51] Internet-Draft OSPF YANG Data Model October 2019 } description "Network LSA."; leaf network-mask { type yang:dotted-quad; description "The IP address mask for the network."; } container attached-routers { description "All attached routers."; leaf-list attached-router { type inet:ipv4-address; description "List of the routers attached to the network."; } } } container summary { when "derived-from(../../header/type, " + "'ospfv2-summary-lsa-type')" { description "Only applies to Summary LSAs."; } description "Summary LSA."; leaf network-mask { type inet:ipv4-address; description "The IP address mask for the network"; } container topologies { description "All topologies for the summary LSA."; list topology { description "Topology specific information."; leaf mt-id { type uint8; description "The MT-ID for the topology enabled for the summary."; } leaf metric { type ospf-metric; description "Metric for the topology."; } } } } Yeung, et al. Expires April 19, 2020 [Page 52] Internet-Draft OSPF YANG Data Model October 2019 container external { when "derived-from(../../header/type, " + "'ospfv2-external-lsa-type')" { description "Only applies to AS-external LSAs and NSSA LSAs."; } description "External LSA."; leaf network-mask { type inet:ipv4-address; description "The IP address mask for the network"; } container topologies { description "All topologies for the external."; list topology { description "Topology specific information."; leaf mt-id { type uint8; description "The MT-ID for the topology enabled for the external or NSSA prefix."; } leaf flags { type bits { bit E { description "When set, the metric specified is a Type 2 external metric."; } } description "Flags."; } leaf metric { type ospf-metric; description "Metric for the topology."; } leaf forwarding-address { type inet:ipv4-address; description "Forwarding address."; } leaf external-route-tag { type uint32; description "Route tag for the topology."; } Yeung, et al. Expires April 19, 2020 [Page 53] Internet-Draft OSPF YANG Data Model October 2019 } } } container opaque { when "derived-from(../../header/type, " + "'ospfv2-opaque-lsa-type')" { description "Only applies to Opaque LSAs."; } description "Opaque LSA."; container ri-opaque { description "OSPF Router Information (RI) opaque LSA."; reference "RFC 7770: OSPF Router Capabilities"; container router-capabilities-tlv { description "Informational and functional router capabilities"; uses router-capabilities-tlv; } container node-tag-tlvs { description "All node tag TLVs."; list node-tag-tlv { description "Node tag TLV."; uses node-tag-tlv; } } container dynamic-hostname-tlv { description "OSPF Dynamic Hostname"; uses dynamic-hostname-tlv; } container sbfd-discriminator-tlv { description "OSPF S-BFD Discriminators"; uses sbfd-discriminator-tlv; } container maximum-sid-depth-tlv { description "OSPF Maximum SID Depth (MSD) values"; uses maximum-sid-depth-tlv; } uses unknown-tlvs; } Yeung, et al. Expires April 19, 2020 [Page 54] Internet-Draft OSPF YANG Data Model October 2019 container te-opaque { description "OSPFv2 Traffic Engineering (TE) opaque LSA."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPFv2"; container router-address-tlv { description "Router address TLV."; leaf router-address { type inet:ipv4-address; description "Router address."; } } container link-tlv { description "Describes a single link, and it is constructed of a set of Sub-TLVs."; leaf link-type { type router-link-type; mandatory true; description "Link type."; } leaf link-id { type union { type inet:ipv4-address; type yang:dotted-quad; } mandatory true; description "Link ID."; } container local-if-ipv4-addrs { description "All local interface IPv4 addresses."; leaf-list local-if-ipv4-addr { type inet:ipv4-address; description "List of local interface IPv4 addresses."; } } container remote-if-ipv4-addrs { description "All remote interface IPv4 addresses."; leaf-list remote-if-ipv4-addr { type inet:ipv4-address; description "List of remote interface IPv4 addresses."; } } leaf te-metric { Yeung, et al. Expires April 19, 2020 [Page 55] Internet-Draft OSPF YANG Data Model October 2019 type uint32; description "TE metric."; } leaf max-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum bandwidth."; } leaf max-reservable-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum reservable bandwidth."; } container unreserved-bandwidths { description "All unreserved bandwidths."; list unreserved-bandwidth { leaf priority { type uint8 { range "0 .. 7"; } description "Priority from 0 to 7."; } leaf unreserved-bandwidth { type rt-types:bandwidth-ieee-float32; description "Unreserved bandwidth."; } description "List of unreserved bandwidths for different priorities."; } } leaf admin-group { type uint32; description "Administrative group/Resource Class/Color."; } uses unknown-tlvs; } } container extended-prefix-opaque { description "All extended prefix TLVs in the LSA."; list extended-prefix-tlv { description "Extended prefix TLV."; leaf route-type { type enumeration { enum unspecified { value "0"; description "Unspecified."; } Yeung, et al. Expires April 19, 2020 [Page 56] Internet-Draft OSPF YANG Data Model October 2019 enum intra-area { value "1"; description "OSPF intra-area route."; } enum inter-area { value "3"; description "OSPF inter-area route."; } enum external { value "5"; description "OSPF External route."; } enum nssa { value "7"; description "OSPF NSSA external route."; } } description "Route type."; } container flags { leaf-list extended-prefix-flags { type identityref { base ospfv2-extended-prefix-flag; } description "Extended prefix TLV flags list. This list will contain identities for the prefix flags that are set in the extended prefix flags."; } description "Prefix Flags."; } leaf prefix { type inet:ip-prefix; description "Address prefix."; } uses unknown-tlvs; } } container extended-link-opaque { description "All extended link TLVs in the LSA."; container extended-link-tlv { description "Extended link TLV."; uses ospfv2-router-link; container maximum-sid-depth-tlv { description "OSPF Maximum SID Depth (MSD) values"; uses maximum-sid-depth-tlv; } Yeung, et al. Expires April 19, 2020 [Page 57] Internet-Draft OSPF YANG Data Model October 2019 uses unknown-tlvs; } } } } grouping ospfv3-lsa-options { description "OSPFv3 LSA options"; container lsa-options { leaf-list lsa-options { type identityref { base ospfv3-lsa-option; } description "OSPFv3 LSA Option flags list. This list will contain the identities for the OSPFv3 LSA options that are set for the LSA."; } description "OSPFv3 LSA options."; } } grouping ospfv3-lsa-prefix { description "OSPFv3 LSA prefix."; leaf prefix { type inet:ip-prefix; description "LSA Prefix."; } container prefix-options { leaf-list prefix-options { type identityref { base ospfv3-prefix-option; } description "OSPFv3 prefix option flag list. This list will contain the identities for the OSPFv3 options that are set for the OSPFv3 prefix."; } description "Prefix options."; } } grouping ospfv3-lsa-external { description "AS-External and NSSA LSA."; Yeung, et al. Expires April 19, 2020 [Page 58] Internet-Draft OSPF YANG Data Model October 2019 leaf metric { type ospf-metric; description "Metric"; } leaf flags { type bits { bit E { description "When set, the metric specified is a Type 2 external metric."; } bit F { description "When set, a Forwarding Address is included in the LSA."; } bit T { description "When set, an External Route Tag is included in the LSA."; } } description "Flags."; } leaf referenced-ls-type { type identityref { base ospfv3-lsa-type; } description "Referenced Link State type."; } leaf unknown-referenced-ls-type { type uint16; description "Value for an unknown Referenced Link State type."; } uses ospfv3-lsa-prefix; leaf forwarding-address { type inet:ipv6-address; description "Forwarding address."; } leaf external-route-tag { type uint32; description Yeung, et al. Expires April 19, 2020 [Page 59] Internet-Draft OSPF YANG Data Model October 2019 "Route tag."; } leaf referenced-link-state-id { type uint32; description "Referenced Link State ID."; } } grouping ospfv3-lsa-body { description "OSPFv3 LSA body."; container router { when "derived-from-or-self(../../header/type, " + "'ospfv3-router-lsa')" { description "Only applies to Router LSAs."; } description "Router LSA."; uses ospf-router-lsa-bits; uses ospfv3-lsa-options; container links { description "All router link."; list link { description "Router LSA link."; leaf interface-id { type uint32; description "Interface ID for link."; } leaf neighbor-interface-id { type uint32; description "Neighbor's Interface ID for link."; } leaf neighbor-router-id { type rt-types:router-id; description "Neighbor's Router ID for link."; } leaf type { type router-link-type; description "Link type: 1 - Point-to-Point Link 2 - Transit Network Link 3 - Stub Network Link 4 - Virtual Link"; } leaf metric { type uint16; description "Link Metric."; } Yeung, et al. Expires April 19, 2020 [Page 60] Internet-Draft OSPF YANG Data Model October 2019 } } } container network { when "derived-from-or-self(../../header/type, " + "'ospfv3-network-lsa')" { description "Only applies to Network LSAs."; } description "Network LSA."; uses ospfv3-lsa-options; container attached-routers { description "All attached routers."; leaf-list attached-router { type rt-types:router-id; description "List of the routers attached to the network."; } } } container inter-area-prefix { when "derived-from-or-self(../../header/type, " + "'ospfv3-inter-area-prefix-lsa')" { description "Only applies to Inter-Area-Prefix LSAs."; } leaf metric { type ospf-metric; description "Inter-Area Prefix Metric"; } uses ospfv3-lsa-prefix; description "Prefix LSA."; } container inter-area-router { when "derived-from-or-self(../../header/type, " + "'ospfv3-inter-area-router-lsa')" { description "Only applies to Inter-Area-Router LSAs."; } uses ospfv3-lsa-options; leaf metric { type ospf-metric; description "AS Boundary Router (ASBR) Metric."; } leaf destination-router-id { type rt-types:router-id; Yeung, et al. Expires April 19, 2020 [Page 61] Internet-Draft OSPF YANG Data Model October 2019 description "The Router ID of the ASBR described by the LSA."; } description "Inter-Area-Router LSA."; } container as-external { when "derived-from-or-self(../../header/type, " + "'ospfv3-as-external-lsa')" { description "Only applies to AS-external LSAs."; } uses ospfv3-lsa-external; description "AS-External LSA."; } container nssa { when "derived-from-or-self(../../header/type, " + "'ospfv3-nssa-lsa')" { description "Only applies to NSSA LSAs."; } uses ospfv3-lsa-external; description "NSSA LSA."; } container link { when "derived-from-or-self(../../header/type, " + "'ospfv3-link-lsa')" { description "Only applies to Link LSAs."; } leaf rtr-priority { type uint8; description "Router priority for DR election. A router with a higher priority will be preferred in the election and a value of 0 indicates the router is not eligible to become Designated Router or Backup Designated Router (BDR)."; } uses ospfv3-lsa-options; leaf link-local-interface-address { type inet:ipv6-address; description "The originating router's link-local interface address for the link."; Yeung, et al. Expires April 19, 2020 [Page 62] Internet-Draft OSPF YANG Data Model October 2019 } leaf num-of-prefixes { type uint32; description "Number of prefixes."; } container prefixes { description "All prefixes for the link."; list prefix { description "List of prefixes associated with the link."; uses ospfv3-lsa-prefix; } } description "Link LSA."; } container intra-area-prefix { when "derived-from-or-self(../../header/type, " + "'ospfv3-intra-area-prefix-lsa')" { description "Only applies to Intra-Area-Prefix LSAs."; } description "Intra-Area-Prefix LSA."; leaf referenced-ls-type { type identityref { base ospfv3-lsa-type; } description "Referenced Link State type."; } leaf unknown-referenced-ls-type { type uint16; description "Value for an unknown Referenced Link State type."; } leaf referenced-link-state-id { type uint32; description "Referenced Link State ID."; } leaf referenced-adv-router { type rt-types:router-id; description "Referenced Advertising Router."; } leaf num-of-prefixes { Yeung, et al. Expires April 19, 2020 [Page 63] Internet-Draft OSPF YANG Data Model October 2019 type uint16; description "Number of prefixes."; } container prefixes { description "All prefixes in this LSA."; list prefix { description "List of prefixes in this LSA."; uses ospfv3-lsa-prefix; leaf metric { type ospf-metric; description "Prefix Metric."; } } } } container router-information { when "derived-from-or-self(../../header/type, " + "'ospfv3-router-information-lsa')" { description "Only applies to Router Information LSAs (RFC7770)."; } container router-capabilities-tlv { description "Informational and functional router capabilities"; uses router-capabilities-tlv; } container node-tag-tlvs { description "All node tag tlvs."; list node-tag-tlv { description "Node tag tlv."; uses node-tag-tlv; } } container dynamic-hostname-tlv { description "OSPF Dynamic Hostname"; uses dynamic-hostname-tlv; } container sbfd-discriminator-tlv { description "OSPF S-BFD Discriminators"; uses sbfd-discriminator-tlv; } description "Router Information LSA."; reference "RFC 7770: Extensions for Advertising Router Capabilities"; } } Yeung, et al. Expires April 19, 2020 [Page 64] Internet-Draft OSPF YANG Data Model October 2019 grouping lsa-header { description "Common LSA for OSPFv2 and OSPFv3"; leaf age { type uint16; mandatory true; description "LSA age."; } leaf type { type identityref { base ospf-lsa-type; } mandatory true; description "LSA type"; } leaf adv-router { type rt-types:router-id; mandatory true; description "LSA advertising router."; } leaf seq-num { type uint32; mandatory true; description "LSA sequence number."; } leaf checksum { type fletcher-checksum16-type; mandatory true; description "LSA checksum."; } leaf length { type uint16; mandatory true; description "LSA length including the header."; } } grouping ospfv2-lsa { description "OSPFv2 LSA - LSAs are uniquely identified by the tuple with the sequence number differentiating LSA instances."; container header { must "(derived-from(type, " + "'ospfv2-opaque-lsa-type') and " + "opaque-id and opaque-type) or " + "(not(derived-from(type, " Yeung, et al. Expires April 19, 2020 [Page 65] Internet-Draft OSPF YANG Data Model October 2019 + "'ospfv2-opaque-lsa-type')) " + "and not(opaque-id) and not(opaque-type))" { description "Opaque type and ID only apply to Opaque LSAs."; } description "Decoded OSPFv2 LSA header data."; container lsa-options { leaf-list lsa-options { type identityref { base ospfv2-lsa-option; } description "LSA option flags list. This list will contain the identities for the identities for the OSPFv2 LSA options that are set."; } description "LSA options."; } leaf lsa-id { type yang:dotted-quad; mandatory true; description "Link-State ID."; } leaf opaque-type { type uint8; description "Opaque type."; } leaf opaque-id { type opaque-id; description "Opaque ID."; } uses lsa-header; } container body { description "Decoded OSPFv2 LSA body data."; uses ospfv2-lsa-body; } } grouping ospfv3-lsa { Yeung, et al. Expires April 19, 2020 [Page 66] Internet-Draft OSPF YANG Data Model October 2019 description "Decoded OSPFv3 LSA."; container header { description "Decoded OSPFv3 LSA header data."; leaf lsa-id { type uint32; mandatory true; description "OSPFv3 LSA ID."; } uses lsa-header; } container body { description "Decoded OSPF LSA body data."; uses ospfv3-lsa-body; } } grouping lsa-common { description "Common fields for OSPF LSA representation."; leaf decode-completed { type boolean; description "The OSPF LSA body was successfully decoded other than unknown TLVs. Unknown LSAs types and OSPFv2 unknown opaque LSA types are not decoded. Additionally, malformed LSAs are generally not accepted and will not be in the Link State Database."; } leaf raw-data { type yang:hex-string; description "The complete LSA in network byte order hexadecimal as received or originated."; } } grouping lsa { description "OSPF LSA."; uses lsa-common; choice version { description "OSPFv2 or OSPFv3 LSA body."; container ospfv2 { description "OSPFv2 LSA"; uses ospfv2-lsa; Yeung, et al. Expires April 19, 2020 [Page 67] Internet-Draft OSPF YANG Data Model October 2019 } container ospfv3 { description "OSPFv3 LSA"; uses ospfv3-lsa; } } } grouping lsa-key { description "OSPF LSA key - the database key for each LSA of a given type in the Link State DataBase (LSDB)."; leaf lsa-id { type union { type yang:dotted-quad; type uint32; } description "Link-State ID."; } leaf adv-router { type rt-types:router-id; description "Advertising router."; } } grouping instance-stat { description "Per-instance statistics"; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF instance's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF instance was last re-initialized, then this node contains the time the OSPF instance was re-initialized which normally occurs when it was created."; } leaf originate-new-lsa-count { type yang:counter32; description "The number of new LSAs originated. Discontinuities in the value of this counter can occur when the OSPF instance is re-initialized."; } leaf rx-new-lsas-count { Yeung, et al. Expires April 19, 2020 [Page 68] Internet-Draft OSPF YANG Data Model October 2019 type yang:counter32; description "The number of new LSAs received. Discontinuities in the value of this counter can occur when the OSPF instance is re-initialized."; } leaf as-scope-lsa-count { type yang:gauge32; description "The number of AS-scope LSAs."; } leaf as-scope-lsa-chksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for AS-scope LSAs. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } container database { description "Container for per AS-scope LSA statistics."; list as-scope-lsa-type { description "List of AS-scope LSA statistics"; leaf lsa-type { type uint16; description "AS-Scope LSA type."; } leaf lsa-count { type yang:gauge32; description "The number of LSAs of the LSA type."; } leaf lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for the LSAs of this type. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } } } uses instance-fast-reroute-state; Yeung, et al. Expires April 19, 2020 [Page 69] Internet-Draft OSPF YANG Data Model October 2019 } grouping area-stat { description "Per-area statistics."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF area's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF area was last re-initialized, then this node contains the time the OSPF area was re-initialized which normally occurs when it was created."; } leaf spf-runs-count { type yang:counter32; description "The number of times the intra-area SPF has run. Discontinuities in the value of this counter can occur when the OSPF area is re-initialized."; } leaf abr-count { type yang:gauge32; description "The total number of Area Border Routers (ABRs) reachable within this area."; } leaf asbr-count { type yang:gauge32; description "The total number of AS Boundary Routers (ASBRs)."; } leaf ar-nssa-translator-event-count { type yang:counter32; description "The number of NSSA translator-state changes. Discontinuities in the value of this counter can occur when the OSPF area is re-initialized."; } leaf area-scope-lsa-count { type yang:gauge32; description "The number of area-scope LSAs in the area."; } leaf area-scope-lsa-cksum-sum { type uint32; description Yeung, et al. Expires April 19, 2020 [Page 70] Internet-Draft OSPF YANG Data Model October 2019 "The module 2**32 sum of the LSA checksums for area-scope LSAs. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } container database { description "Container for area-scope LSA type statistics."; list area-scope-lsa-type { description "List of area-scope LSA statistics"; leaf lsa-type { type uint16; description "Area-scope LSA type."; } leaf lsa-count { type yang:gauge32; description "The number of LSAs of the LSA type."; } leaf lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for the LSAs of this type. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } } } } grouping interface-stat { description "Per-interface statistics"; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF interface's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF interface was last re-initialized, then this node contains the time the OSPF interface was re-initialized which normally occurs when it was created."; Yeung, et al. Expires April 19, 2020 [Page 71] Internet-Draft OSPF YANG Data Model October 2019 } leaf if-event-count { type yang:counter32; description "The number of times this interface has changed its state or an error has occurred. Discontinuities in the value of this counter can occur when the OSPF interface is re-initialized."; } leaf link-scope-lsa-count { type yang:gauge32; description "The number of link-scope LSAs."; } leaf link-scope-lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for link-scope LSAs. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } container database { description "Container for link-scope LSA type statistics."; list link-scope-lsa-type { description "List of link-scope LSA statistics"; leaf lsa-type { type uint16; description "Link scope LSA type."; } leaf lsa-count { type yang:gauge32; description "The number of LSAs of the LSA type."; } leaf lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for the LSAs of this type. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } Yeung, et al. Expires April 19, 2020 [Page 72] Internet-Draft OSPF YANG Data Model October 2019 } } } grouping neighbor-stat { description "Per-neighbor statistics."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF neighbor's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF neighbor was last re-initialized, then this node contains the time the OSPF neighbor was re-initialized which normally occurs when the neighbor is dynamically discovered andcreated."; } leaf nbr-event-count { type yang:counter32; description "The number of times this neighbor has changed state or an error has occurred. Discontinuities in the value of this counter can occur when the OSPF neighbor is re-initialized."; } leaf nbr-retrans-qlen { type yang:gauge32; description "The current length of the retransmission queue."; } } grouping instance-fast-reroute-config { description "This group defines global configuration of IP Fast ReRoute (FRR)."; container fast-reroute { if-feature fast-reroute; description "This container may be augmented with global parameters for IP-FRR."; container lfa { if-feature lfa; description "This container may be augmented with global parameters for Loop-Free Alternatives (LFA). Container creation has no effect on LFA activation."; } Yeung, et al. Expires April 19, 2020 [Page 73] Internet-Draft OSPF YANG Data Model October 2019 } } grouping instance-fast-reroute-state { description "IP-FRR state data grouping"; container protected-routes { if-feature fast-reroute; config false; description "Instance protection statistics"; list address-family-stats { key "address-family prefix alternate"; description "Per Address Family protected prefix information"; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf prefix { type inet:ip-prefix; description "Protected prefix."; } leaf alternate { type inet:ip-address; description "Alternate next hop for the prefix."; } leaf alternate-type { type enumeration { enum equal-cost { description "ECMP alternate."; } enum lfa { description "LFA alternate."; } enum remote-lfa { description "Remote LFA alternate."; } enum tunnel { description "Tunnel based alternate Yeung, et al. Expires April 19, 2020 [Page 74] Internet-Draft OSPF YANG Data Model October 2019 (like RSVP-TE or GRE)."; } enum ti-lfa { description "TI-LFA alternate."; } enum mrt { description "MRT alternate."; } enum other { description "Unknown alternate type."; } } description "Type of alternate."; } leaf best { type boolean; description "Indicates that this alternate is preferred."; } leaf non-best-reason { type string { length "1..255"; } description "Information field to describe why the alternate is not best."; } leaf protection-available { type bits { bit node-protect { position 0; description "Node protection available."; } bit link-protect { position 1; description "Link protection available."; } bit srlg-protect { position 2; description "SRLG protection available."; } Yeung, et al. Expires April 19, 2020 [Page 75] Internet-Draft OSPF YANG Data Model October 2019 bit downstream-protect { position 3; description "Downstream protection available."; } bit other { position 4; description "Other protection available."; } } description "Protection provided by the alternate."; } leaf alternate-metric1 { type uint32; description "Metric from Point of Local Repair (PLR) to destination through the alternate path."; } leaf alternate-metric2 { type uint32; description "Metric from PLR to the alternate node"; } leaf alternate-metric3 { type uint32; description "Metric from alternate node to the destination"; } } } container unprotected-routes { if-feature fast-reroute; config false; description "List of prefixes that are not protected"; list address-family-stats { key "address-family prefix"; description "Per Address Family (AF) unprotected prefix statistics."; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf prefix { type inet:ip-prefix; Yeung, et al. Expires April 19, 2020 [Page 76] Internet-Draft OSPF YANG Data Model October 2019 description "Unprotected prefix."; } } } list protection-statistics { key frr-protection-method; config false; description "List protection method statistics"; leaf frr-protection-method { type string; description "Protection method used."; } list address-family-stats { key address-family; description "Per Address Family protection statistics."; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf total-routes { type uint32; description "Total prefixes."; } leaf unprotected-routes { type uint32; description "Total prefixes that are not protected."; } leaf protected-routes { type uint32; description "Total prefixes that are protected."; } leaf linkprotected-routes { type uint32; description "Total prefixes that are link protected."; } leaf nodeprotected-routes { type uint32; description "Total prefixes that are node protected."; } } } Yeung, et al. Expires April 19, 2020 [Page 77] Internet-Draft OSPF YANG Data Model October 2019 } grouping interface-fast-reroute-config { description "This group defines interface configuration of IP-FRR."; container fast-reroute { if-feature fast-reroute; container lfa { if-feature lfa; leaf candidate-enable { type boolean; default true; description "Enable the interface to be used as backup."; } leaf enable { type boolean; default false; description "Activates LFA - Per-prefix LFA computation is assumed."; } container remote-lfa { if-feature remote-lfa; leaf enable { type boolean; default false; description "Activates Remote LFA (R-LFA)."; } description "Remote LFA configuration."; } description "LFA configuration."; } description "Interface IP Fast-reroute configuration."; } } grouping interface-physical-link-config { description "Interface cost configuration that only applies to physical interfaces (non-virtual) and sham links."; leaf cost { type ospf-link-metric; description Yeung, et al. Expires April 19, 2020 [Page 78] Internet-Draft OSPF YANG Data Model October 2019 "Interface cost."; } leaf mtu-ignore { if-feature mtu-ignore; type boolean; description "Enable/Disable bypassing the MTU mismatch check in Database Description packets specified in RFC 2328, section 10.6."; } leaf prefix-suppression { if-feature prefix-suppression; type boolean; description "Suppress advertisement of the prefixes associated with the interface."; } } grouping interface-common-config { description "Common configuration for all types of interfaces, including virtual links and sham links."; leaf hello-interval { type uint16; units seconds; description "Interval between hello packets (seconds). It must be the same for all routers on the same network. Different networks, implementations, and deployments will use different hello-intervals. A sample value for a LAN network would be 10 seconds."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf dead-interval { type uint16; units seconds; must "../dead-interval > ../hello-interval" { error-message "The dead interval must be " + "larger than the hello interval"; description "The value must be greater than the 'hello-interval'."; } description "Interval after which a neighbor is declared down (seconds) if hello packets are not received. It is Yeung, et al. Expires April 19, 2020 [Page 79] Internet-Draft OSPF YANG Data Model October 2019 typically 3 or 4 times the hello-interval. A typical value for LAN networks is 40 seconds."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf retransmit-interval { type uint16 { range "1..3600"; } units seconds; description "Interval between retransmitting unacknowledged Link State Advertisements (LSAs) (seconds). This should be well over the round-trip transmit delay for any two routers on the network. A sample value would be 5 seconds."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf transmit-delay { type uint16; units seconds; description "Estimated time needed to transmit Link State Update (LSU) packets on the interface (seconds). LSAs have their age incremented by this amount when advertised on the interface. A sample value would be 1 second."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf lls { if-feature lls; type boolean; description "Enable/Disable link-local signaling (LLS) support."; } container ttl-security { if-feature ttl-security; description "Time to Live (TTL) security check."; leaf enable { type boolean; description "Enable/Disable TTL security check."; } leaf hops { type uint8 { range "1..254"; Yeung, et al. Expires April 19, 2020 [Page 80] Internet-Draft OSPF YANG Data Model October 2019 } default 1; description "Maximum number of hops that an OSPF packet may have traversed before reception."; } } leaf enable { type boolean; default true; description "Enable/disable OSPF protocol on the interface."; } container authentication { description "Authentication configuration."; choice auth-type-selection { description "Options for OSPFv2/OSPFv3 authentication configuration."; case ospfv2-auth { when "derived-from-or-self(../../../../../../rt:type, " + "'ospfv2')" { description "Applied to OSPFv2 only."; } leaf ospfv2-auth-trailer-rfc { if-feature ospfv2-authentication-trailer; type ospfv2-auth-trailer-rfc-version; description "Version of OSFPv2 authentication trailer support - RFC 5709 or RFC 7474"; } choice ospfv2-auth-specification { description "Key chain or explicit key parameter specification"; case auth-key-chain { if-feature key-chain; leaf ospfv2-key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key-explicit { leaf ospfv2-key-id { type uint32; description "Key Identifier"; Yeung, et al. Expires April 19, 2020 [Page 81] Internet-Draft OSPF YANG Data Model October 2019 } leaf ospfv2-key { type string; description "OSPFv2 authentication key. The length of the key may be dependent on the cryptographic algorithm."; } leaf ospfv2-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } } case ospfv3-auth-ipsec { when "derived-from-or-self(../../../../../../rt:type, " + "'ospfv3')" { description "Applied to OSPFv3 only."; } if-feature ospfv3-authentication-ipsec; leaf sa { type string; description "Security Association (SA) name."; } } case ospfv3-auth-trailer { when "derived-from-or-self(../../../../../../rt:type, " + "'ospfv3')" { description "Applied to OSPFv3 only."; } if-feature ospfv3-authentication-trailer; choice ospfv3-auth-specification { description "Key chain or explicit key parameter specification"; case auth-key-chain { if-feature key-chain; leaf ospfv3-key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key-explicit { Yeung, et al. Expires April 19, 2020 [Page 82] Internet-Draft OSPF YANG Data Model October 2019 leaf ospfv3-sa-id { type uint16; description "Security Association (SA) Identifier"; } leaf ospfv3-key { type string; description "OSPFv3 authentication key. The length of the key may be dependent on the cryptographic algorithm."; } leaf ospfv3-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } } } } } grouping interface-config { description "Configuration for real interfaces."; leaf interface-type { type enumeration { enum "broadcast" { description "Specify OSPF broadcast multi-access network."; } enum "non-broadcast" { description "Specify OSPF Non-Broadcast Multi-Access (NBMA) network."; } enum "point-to-multipoint" { description "Specify OSPF point-to-multipoint network."; } enum "point-to-point" { description "Specify OSPF point-to-point network."; } Yeung, et al. Expires April 19, 2020 [Page 83] Internet-Draft OSPF YANG Data Model October 2019 enum "hybrid" { if-feature hybrid-interface; description "Specify OSPF hybrid broadcast/P2MP network."; } } description "Interface type."; } leaf passive { type boolean; description "Enable/Disable passive interface - a passive interface's prefix will be advertised but no neighbor adjacencies will be formed on the interface."; } leaf demand-circuit { if-feature demand-circuit; type boolean; description "Enable/Disable demand circuit."; } leaf priority { type uint8; description "Configure OSPF router priority. On multi-access network this value is for Designated Router (DR) election. The priority is ignored on other interface types. A router with a higher priority will be preferred in the election and a value of 0 indicates the router is not eligible to become Designated Router or Backup Designated Router (BDR)."; } container multi-areas { if-feature multi-area-adj; description "Container for multi-area config."; list multi-area { key multi-area-id; description "Configure OSPF multi-area adjacency."; leaf multi-area-id { type area-id-type; description "Multi-area adjacency area ID."; Yeung, et al. Expires April 19, 2020 [Page 84] Internet-Draft OSPF YANG Data Model October 2019 } leaf cost { type ospf-link-metric; description "Interface cost for multi-area adjacency."; } } } container static-neighbors { description "Statically configured neighbors."; list neighbor { key "identifier"; description "Specify a static OSPF neighbor."; leaf identifier { type inet:ip-address; description "Neighbor Router ID, IPv4 address, or IPv6 address."; } leaf cost { type ospf-link-metric; description "Neighbor cost. Different implementations have different default costs with some defaulting to a cost inversely proportional to the interface speed. Others will default to 1 equating the cost to a hop count." ; } leaf poll-interval { type uint16; units seconds; description "Neighbor poll interval (seconds) for sending OSPF hello packets to discover the neighbor on NBMA networks. This interval dictates the granularity for discovery of new neighbors. A sample would be 120 seconds (2 minutes) for a legacy Packet Data Network (PDN) X.25 network."; reference "RFC 2328: OSPF Version 2, Appendix C.5"; } leaf priority { type uint8; description "Neighbor priority for DR election. A router with a higher priority will be preferred in the election Yeung, et al. Expires April 19, 2020 [Page 85] Internet-Draft OSPF YANG Data Model October 2019 and a value of 0 indicates the router is not eligible to become Designated Router or Backup Designated Router (BDR)."; } } } leaf node-flag { if-feature node-flag; type boolean; default false; description "Set prefix as identifying the advertising router."; reference "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement"; } container bfd { if-feature bfd; description "BFD Client Configuration."; uses bfd-types:client-cfg-parms; reference "RFC YYYY: YANG Data Model for Bidirectional Forwarding Detection (BFD). Please replace YYYY with published RFC number for draft-ietf-bfd-yang."; } uses interface-fast-reroute-config; uses interface-common-config; uses interface-physical-link-config; } grouping neighbor-state { description "OSPF neighbor operational state."; leaf address { type inet:ip-address; config false; description "Neighbor address."; } leaf dr-router-id { type rt-types:router-id; config false; description "Neighbor's Designated Router (DR) Router ID."; } leaf dr-ip-addr { Yeung, et al. Expires April 19, 2020 [Page 86] Internet-Draft OSPF YANG Data Model October 2019 type inet:ip-address; config false; description "Neighbor's Designated Router (DR) IP address."; } leaf bdr-router-id { type rt-types:router-id; config false; description "Neighbor's Backup Designated Router (BDR) Router ID."; } leaf bdr-ip-addr { type inet:ip-address; config false; description "Neighbor's Backup Designated Router (BDR) IP Address."; } leaf state { type nbr-state-type; config false; description "OSPF neighbor state."; } leaf cost { type ospf-link-metric; config false; description "Cost to reach neighbor for Point-to-Multipoint and Hybrid networks"; } leaf dead-timer { type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the neighbor is declared dead."; } container statistics { config false; description "Per-neighbor statistics"; uses neighbor-stat; } } grouping interface-common-state { description "OSPF interface common operational state."; reference "RFC2328 Section 9: OSPF Version2 - The Interface Data Structure"; Yeung, et al. Expires April 19, 2020 [Page 87] Internet-Draft OSPF YANG Data Model October 2019 leaf state { type if-state-type; config false; description "Interface state."; } leaf hello-timer { type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the next hello packet is sent on the interface."; } leaf wait-timer { type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the interface exits the Waiting state."; } leaf dr-router-id { type rt-types:router-id; config false; description "Designated Router (DR) Router ID."; } leaf dr-ip-addr { type inet:ip-address; config false; description "Designated Router (DR) IP address."; } leaf bdr-router-id { type rt-types:router-id; config false; description "Backup Designated Router (BDR) Router ID."; } leaf bdr-ip-addr { type inet:ip-address; config false; description "Backup Designated Router (BDR) IP Address."; } container statistics { config false; description "Per-interface statistics"; Yeung, et al. Expires April 19, 2020 [Page 88] Internet-Draft OSPF YANG Data Model October 2019 uses interface-stat; } container neighbors { config false; description "All neighbors for the interface."; list neighbor { key "neighbor-router-id"; description "List of interface OSPF neighbors."; leaf neighbor-router-id { type rt-types:router-id; description "Neighbor Router ID."; } uses neighbor-state; } } container database { config false; description "Link-scope Link State Database."; list link-scope-lsa-type { key "lsa-type"; description "List OSPF link-scope LSAs."; leaf lsa-type { type uint16; description "OSPF link-scope LSA type."; } container link-scope-lsas { description "All link-scope LSAs of this LSA type."; list link-scope-lsa { key "lsa-id adv-router"; description "List of OSPF link-scope LSAs"; uses lsa-key; uses lsa { refine "version/ospfv2/ospfv2" { must "derived-from-or-self( " + "../../../../../../../../../../" + "rt:type, 'ospfv2')" { description "OSPFv2 LSA."; } } refine "version/ospfv3/ospfv3" { must "derived-from-or-self( " + "../../../../../../../../../../" + "rt:type, 'ospfv3')" { Yeung, et al. Expires April 19, 2020 [Page 89] Internet-Draft OSPF YANG Data Model October 2019 description "OSPFv3 LSA."; } } } } } } } } grouping interface-state { description "OSPF interface operational state."; reference "RFC2328 Section 9: OSPF Version2 - The Interface Data Structure"; uses interface-common-state; } grouping virtual-link-config { description "OSPF virtual link configuration state."; uses interface-common-config; } grouping virtual-link-state { description "OSPF virtual link operational state."; leaf cost { type ospf-link-metric; config false; description "Virtual link interface cost."; } uses interface-common-state; } grouping sham-link-config { description "OSPF sham link configuration state."; uses interface-common-config; uses interface-physical-link-config; } grouping sham-link-state { Yeung, et al. Expires April 19, 2020 [Page 90] Internet-Draft OSPF YANG Data Model October 2019 description "OSPF sham link operational state."; uses interface-common-state; } grouping address-family-area-config { description "OSPF address-family specific area config state."; container ranges { description "Container for summary ranges"; list range { key "prefix"; description "Summarize routes matching address/mask - Applicable to Area Border Routers (ABRs) only."; leaf prefix { type inet:ip-prefix; description "IPv4 or IPv6 prefix"; } leaf advertise { type boolean; description "Advertise or hide."; } leaf cost { type ospf-metric; description "Advertised cost of summary route."; } } } } grouping area-common-config { description "OSPF area common configuration state."; leaf summary { when "derived-from(../area-type,'stub-nssa-area')" { description "Summary advertisement into the stub/NSSA area."; } type boolean; description "Enable/Disable summary advertisement into the stub or Yeung, et al. Expires April 19, 2020 [Page 91] Internet-Draft OSPF YANG Data Model October 2019 NSSA area."; } leaf default-cost { when "derived-from(../area-type,'stub-nssa-area')" { description "Cost for LSA default route advertised into the stub or NSSA area."; } type ospf-metric; description "Set the summary default route cost for a stub or NSSA area."; } } grouping area-config { description "OSPF area configuration state."; leaf area-type { type identityref { base area-type; } default normal-area; description "Area type."; } uses area-common-config; uses address-family-area-config; } grouping area-state { description "OSPF area operational state."; container statistics { config false; description "Per-area statistics"; uses area-stat; } container database { config false; description "Area-scope Link State Database."; list area-scope-lsa-type { key "lsa-type"; description "List OSPF area-scope LSAs."; Yeung, et al. Expires April 19, 2020 [Page 92] Internet-Draft OSPF YANG Data Model October 2019 leaf lsa-type { type uint16; description "OSPF area-scope LSA type."; } container area-scope-lsas { description "All area-scope LSAs of an area-scope LSA type."; list area-scope-lsa { key "lsa-id adv-router"; description "List of OSPF area-scope LSAs"; uses lsa-key; uses lsa { refine "version/ospfv2/ospfv2" { must "derived-from-or-self( " + "../../../../../../../../" + "rt:type, 'ospfv2')" { description "OSPFv2 LSA."; } } refine "version/ospfv3/ospfv3" { must "derived-from-or-self( " + "../../../../../../../../" + "rt:type, 'ospfv3')" { description "OSPFv3 LSA."; } } } } } } } } grouping local-rib { description "Local-rib - RIB for Routes computed by the local OSPF routing instance."; container local-rib { config false; description "Local-rib."; list route { key "prefix"; description "Routes"; leaf prefix { type inet:ip-prefix; description "Destination prefix."; } container next-hops { Yeung, et al. Expires April 19, 2020 [Page 93] Internet-Draft OSPF YANG Data Model October 2019 description "Next hops for the route."; list next-hop { key "next-hop"; description "List of next hops for the route"; leaf outgoing-interface { type if:interface-ref; description "Name of the outgoing interface."; } leaf next-hop { type inet:ip-address; description "Next hop address."; } } } leaf metric { type uint32; description "Metric for this route."; } leaf route-type { type route-type; description "Route type for this route."; } leaf route-tag { type uint32; description "Route tag for this route."; } } } } grouping ietf-spf-delay { leaf initial-delay { type uint32; units milliseconds; description "Delay used while in QUIET state (milliseconds)."; } leaf short-delay { type uint32; units milliseconds; description "Delay used while in SHORT_WAIT state (milliseconds)."; } leaf long-delay { type uint32; units milliseconds; description Yeung, et al. Expires April 19, 2020 [Page 94] Internet-Draft OSPF YANG Data Model October 2019 "Delay used while in LONG_WAIT state (milliseconds)."; } leaf hold-down { type uint32; units milliseconds; description "Timer used to consider an IGP stability period (milliseconds)."; } leaf time-to-learn { type uint32; units milliseconds; description "Duration used to learn all the IGP events related to a single component failure (milliseconds)."; } leaf current-state { type enumeration { enum "quiet" { description "QUIET state"; } enum "short-wait" { description "SHORT_WAIT state"; } enum "long-wait" { description "LONG_WAIT state"; } } config false; description "Current SPF back-off algorithm state."; } leaf remaining-time-to-learn { type rt-types:timer-value-milliseconds; config false; description "Remaining time until time-to-learn timer fires."; } leaf remaining-hold-down { type rt-types:timer-value-milliseconds; config false; description "Remaining time until hold-down timer fires."; } leaf last-event-received { type yang:timestamp; config false; description Yeung, et al. Expires April 19, 2020 [Page 95] Internet-Draft OSPF YANG Data Model October 2019 "Time of last SPF triggering event."; } leaf next-spf-time { type yang:timestamp; config false; description "Time when next SPF has been scheduled."; } leaf last-spf-time { type yang:timestamp; config false; description "Time of last SPF computation."; } description "Grouping for IETF SPF delay configuration and state"; } grouping node-tag-config { description "OSPF node tag config state."; container node-tags { if-feature node-tag; list node-tag { key tag; leaf tag { type uint32; description "Node tag value."; } description "List of tags."; } description "Container for node admin tags."; } } grouping instance-config { description "OSPF instance config state."; leaf enable { type boolean; default true; description "Enable/Disable the protocol."; } Yeung, et al. Expires April 19, 2020 [Page 96] Internet-Draft OSPF YANG Data Model October 2019 leaf explicit-router-id { if-feature explicit-router-id; type rt-types:router-id; description "Defined in RFC 2328. A 32-bit number that uniquely identifies the router."; } container preference { description "Route preference configuration. In many implementations, preference is referred to as administrative distance."; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; choice scope { description "Options for expressing preference as single or multiple values."; case single-value { leaf all { type uint8; description "Preference for intra-area, inter-area, and external routes."; } } case multi-values { choice granularity { description "Options for expressing preference for intra-area and inter-area routes."; case detail { leaf intra-area { type uint8; description "Preference for intra-area routes."; } leaf inter-area { type uint8; description "Preference for inter-area routes."; } } case coarse { leaf internal { type uint8; Yeung, et al. Expires April 19, 2020 [Page 97] Internet-Draft OSPF YANG Data Model October 2019 description "Preference for both intra-area and inter-area routes."; } } } leaf external { type uint8; description "Preference for AS external routes."; } } } } container nsr { if-feature nsr; description "Non-Stop Routing (NSR) config state."; leaf enable { type boolean; description "Enable/Disable NSR."; } } container graceful-restart { if-feature graceful-restart; description "Graceful restart config state."; reference "RFC 3623: OSPF Graceful Restart RFC 5187: OSPFv3 Graceful Restart"; leaf enable { type boolean; description "Enable/Disable graceful restart as defined in RFC 3623 for OSPFv2 and RFC 5187 for OSPFv3."; } leaf helper-enable { type boolean; description "Enable graceful restart helper support for restarting routers (RFC 3623 Section 3)."; } leaf restart-interval { type uint16 { range "1..1800"; } Yeung, et al. Expires April 19, 2020 [Page 98] Internet-Draft OSPF YANG Data Model October 2019 units seconds; default "120"; description "Interval to attempt graceful restart prior to failing (RFC 3623 Section B.1) (seconds)"; } leaf helper-strict-lsa-checking { type boolean; description "Terminate graceful restart when an LSA topology change is detected (RFC 3623 Section B.2)."; } } container auto-cost { if-feature auto-cost; description "Interface Auto-cost configuration state."; leaf enable { type boolean; description "Enable/Disable interface auto-cost."; } leaf reference-bandwidth { when "../enable = 'true'" { description "Only when auto cost is enabled"; } type uint32 { range "1..4294967"; } units Mbits; description "Configure reference bandwidth used to automatically determine interface cost (Mbits). The cost is the reference bandwidth divided by the interface speed with 1 being the minimum cost."; } } container spf-control { leaf paths { if-feature max-ecmp; type uint16 { range "1..65535"; } description "Maximum number of Equal-Cost Multi-Path (ECMP) paths."; } Yeung, et al. Expires April 19, 2020 [Page 99] Internet-Draft OSPF YANG Data Model October 2019 container ietf-spf-delay { if-feature ietf-spf-delay; uses ietf-spf-delay; description "IETF SPF delay algorithm configuration."; } description "SPF calculation control."; } container database-control { leaf max-lsa { if-feature max-lsa; type uint32 { range "1..4294967294"; } description "Maximum number of LSAs OSPF the router will accept."; } description "Database maintenance control."; } container stub-router { if-feature stub-router; description "Set maximum metric configuration"; choice trigger { description "Specific triggers which will enable stub router state."; container always { presence "Enables unconditional stub router support"; description "Unconditional stub router state (advertise transit links with MaxLinkMetric"; reference "RFC 6987: OSPF Stub Router Advertisement"; } } } container mpls { description "OSPF MPLS config state."; container te-rid { if-feature te-rid; description "Stable OSPF Router IP Address used for Traffic Yeung, et al. Expires April 19, 2020 [Page 100] Internet-Draft OSPF YANG Data Model October 2019 Engineering (TE)"; leaf ipv4-router-id { type inet:ipv4-address; description "Explicitly configure the TE IPv4 Router ID."; } leaf ipv6-router-id { type inet:ipv6-address; description "Explicitly configure the TE IPv6 Router ID."; } } container ldp { description "OSPF MPLS LDP config state."; leaf igp-sync { if-feature ldp-igp-sync; type boolean; description "Enable LDP IGP synchronization."; } } } uses instance-fast-reroute-config; uses node-tag-config; } grouping instance-state { description "OSPF instance operational state."; leaf router-id { type rt-types:router-id; config false; description "Defined in RFC 2328. A 32-bit number that uniquely identifies the router."; } uses local-rib; container statistics { config false; description "Per-instance statistics"; uses instance-stat; } container database { Yeung, et al. Expires April 19, 2020 [Page 101] Internet-Draft OSPF YANG Data Model October 2019 config false; description "AS-scope Link State Database."; list as-scope-lsa-type { key "lsa-type"; description "List OSPF AS-scope LSAs."; leaf lsa-type { type uint16; description "OSPF AS scope LSA type."; } container as-scope-lsas { description "All AS-scope of LSA of this LSA type."; list as-scope-lsa { key "lsa-id adv-router"; description "List of OSPF AS-scope LSAs"; uses lsa-key; uses lsa { refine "version/ospfv2/ospfv2" { must "derived-from-or-self( " + "../../../../../../" + "rt:type, 'ospfv2')" { description "OSPFv2 LSA."; } } refine "version/ospfv3/ospfv3" { must "derived-from-or-self( " + "../../../../../../" + "rt:type, 'ospfv3')" { description "OSPFv3 LSA."; } } } } } } } uses spf-log; uses lsa-log; } grouping multi-topology-area-common-config { description "OSPF multi-topology area common configuration state."; leaf summary { when "derived-from(../../../area-type, 'stub-nssa-area')" { description "Summary advertisement into the stub/NSSA area."; } type boolean; Yeung, et al. Expires April 19, 2020 [Page 102] Internet-Draft OSPF YANG Data Model October 2019 description "Enable/Disable summary advertisement into the topology in the stub or NSSA area."; } leaf default-cost { when "derived-from(../../../area-type, 'stub-nssa-area')" { description "Cost for LSA default route advertised into the topology into the stub or NSSA area."; } type ospf-metric; description "Set the summary default route cost for a stub or NSSA area."; } } grouping multi-topology-area-config { description "OSPF multi-topology area configuration state."; uses multi-topology-area-common-config; uses address-family-area-config; } grouping multi-topology-state { description "OSPF multi-topology operational state."; uses local-rib; } grouping multi-topology-interface-config { description "OSPF multi-topology configuration state."; leaf cost { type ospf-link-metric; description "Interface cost for this topology."; } } grouping ospfv3-interface-config { description "OSPFv3 interface specific configuration state."; leaf instance-id { Yeung, et al. Expires April 19, 2020 [Page 103] Internet-Draft OSPF YANG Data Model October 2019 type uint8 { range "0 .. 31"; } description "OSPFv3 instance ID."; } } grouping ospfv3-interface-state { description "OSPFv3 interface specific operational state."; leaf interface-id { type uint16; config false; description "OSPFv3 interface ID."; } } grouping lsa-identifiers { description "The parameters that uniquely identify an LSA."; leaf area-id { type area-id-type; description "Area ID"; } leaf type { type uint16; description "LSA type."; } leaf lsa-id { type union { type inet:ipv4-address; type yang:dotted-quad; } description "Link-State ID."; } leaf adv-router { type rt-types:router-id; description "LSA advertising router."; } leaf seq-num { type uint32; description Yeung, et al. Expires April 19, 2020 [Page 104] Internet-Draft OSPF YANG Data Model October 2019 "LSA sequence number."; } } grouping spf-log { description "Grouping for SPF log."; container spf-log { config false; description "This container lists the SPF log."; list event { key id; description "List of SPF log entries represented as a wrapping buffer in chronological order with the oldest entry returned first."; leaf id { type uint32; description "Event identifier - Purely internal value."; } leaf spf-type { type enumeration { enum full { description "SPF computation was a Full SPF."; } enum intra { description "SPF computation was only for intra-area routes."; } enum inter { description "SPF computation was only for inter-area summary routes."; } enum external { description "SPF computation was only for AS external routes."; } } description "The SPF computation type for the SPF log entry."; } leaf schedule-timestamp { type yang:timestamp; Yeung, et al. Expires April 19, 2020 [Page 105] Internet-Draft OSPF YANG Data Model October 2019 description "This is the timestamp when the computation was scheduled."; } leaf start-timestamp { type yang:timestamp; description "This is the timestamp when the computation was started."; } leaf end-timestamp { type yang:timestamp; description "This the timestamp when the computation was completed."; } list trigger-lsa { description "The list of LSAs that triggered the computation."; uses lsa-identifiers; } } } } grouping lsa-log { description "Grouping for the LSA log."; container lsa-log { config false; description "This container lists the LSA log. Local LSA modifications are also included in the list."; list event { key id; description "List of LSA log entries represented as a wrapping buffer in chronological order with the oldest entries returned first."; leaf id { type uint32; description "Event identifier - purely internal value."; } container lsa { description "This container describes the logged LSA."; Yeung, et al. Expires April 19, 2020 [Page 106] Internet-Draft OSPF YANG Data Model October 2019 uses lsa-identifiers; } leaf received-timestamp { type yang:timestamp; description "This is the timestamp when the LSA was received. In case of local LSA update, the timestamp refers to the LSA origination time."; } leaf reason { type identityref { base lsa-log-reason; } description "This reason for the LSA log entry."; } } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from(rt:type, 'ospf')" { description "This augmentation is only valid for a routing protocol instance of OSPF (type 'ospfv2' or 'ospfv3')."; } description "OSPF protocol ietf-routing module control-plane-protocol augmentation."; container ospf { description "OSPF protocol Instance"; leaf address-family { type iana-rt-types:address-family; description "Address-family of the instance."; } uses instance-config; uses instance-state; container areas { description "All areas."; list area { key "area-id"; description Yeung, et al. Expires April 19, 2020 [Page 107] Internet-Draft OSPF YANG Data Model October 2019 "List of OSPF areas"; leaf area-id { type area-id-type; description "Area ID"; } uses area-config; uses area-state; container virtual-links { when "derived-from-or-self(../area-type, 'normal-area') " + "and ../area-id = '0.0.0.0'" { description "Virtual links must be in backbone area."; } description "All virtual links."; list virtual-link { key "transit-area-id router-id"; description "OSPF virtual link"; leaf transit-area-id { type leafref { path "../../../../area/area-id"; } must "derived-from-or-self(" + "../../../../area[area-id=current()]/area-type, " + "'normal-area') and " + "../../../../area[area-id=current()]/area-id != " + "'0.0.0.0'" { error-message "Virtual link transit area must " + "be non-zero."; description "Virtual-link transit area must be non-zero area."; } description "Virtual link transit area ID."; } leaf router-id { type rt-types:router-id; description "Virtual Link remote endpoint Router ID."; } uses virtual-link-config; uses virtual-link-state; } Yeung, et al. Expires April 19, 2020 [Page 108] Internet-Draft OSPF YANG Data Model October 2019 } container sham-links { if-feature pe-ce-protocol; description "All sham links."; list sham-link { key "local-id remote-id"; description "OSPF sham link"; leaf local-id { type inet:ip-address; description "Address of the local sham Link endpoint."; } leaf remote-id { type inet:ip-address; description "Address of the remote sham Link endpoint."; } uses sham-link-config; uses sham-link-state; } } container interfaces { description "All interfaces."; list interface { key "name"; description "List of OSPF interfaces."; leaf name { type if:interface-ref; description "Interface name reference."; } uses interface-config; uses interface-state; } } } } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf" { when "derived-from(../rt:type, 'ospf')" { description "This augmentation is only valid for OSPF (type 'ospfv2' or 'ospfv3')."; Yeung, et al. Expires April 19, 2020 [Page 109] Internet-Draft OSPF YANG Data Model October 2019 } if-feature multi-topology; description "OSPF multi-topology instance configuration state augmentation."; container topologies { description "All topologies."; list topology { key "name"; description "OSPF topology - The OSPF topology address-family must coincide with the routing-instance address-family."; leaf name { type leafref { path "../../../../../../rt:ribs/rt:rib/rt:name"; } description "RIB name corresponding to the OSPF topology."; } uses multi-topology-state; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf/" + "areas/area" { when "derived-from-or-self(../../../rt:type, " + "'ospfv2')" { description "This augmentation is only valid for OSPFv2."; } if-feature multi-topology; description "OSPF multi-topology area configuration state augmentation."; container topologies { description "All topologies for the area."; list topology { key "name"; description "OSPF area topology."; leaf name { type leafref { path "../../../../../../../../" + "rt:ribs/rt:rib/rt:name"; } Yeung, et al. Expires April 19, 2020 [Page 110] Internet-Draft OSPF YANG Data Model October 2019 description "Single topology enabled for this area."; } uses multi-topology-area-config; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf/" + "areas/area/interfaces/interface" { when "derived-from-or-self(../../../../../rt:type, " + "'ospfv2')" { description "This augmentation is only valid for OSPFv2."; } if-feature multi-topology; description "OSPF multi-topology interface configuration state augmentation."; container topologies { description "All topologies for the interface."; list topology { key "name"; description "OSPF interface topology."; leaf name { type leafref { path "../../../../../../../../../../" + "rt:ribs/rt:rib/rt:name"; } description "Single topology enabled on this interface."; } uses multi-topology-interface-config; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf/" + "areas/area/interfaces/interface" { when "derived-from-or-self(../../../../../rt:type, " + "'ospfv3')" { description "This augmentation is only valid for OSPFv3."; } Yeung, et al. Expires April 19, 2020 [Page 111] Internet-Draft OSPF YANG Data Model October 2019 description "OSPFv3 interface specific configuration state augmentation."; uses ospfv3-interface-config; uses ospfv3-interface-state; } grouping route-content { description "This grouping defines OSPF-specific route attributes."; leaf metric { type uint32; description "OSPF route metric."; } leaf tag { type uint32; default "0"; description "OSPF route tag."; } leaf route-type { type route-type; description "OSPF route type"; } } augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { when "derived-from(rt:source-protocol, 'ospf')" { description "This augmentation is only valid for routes whose source protocol is OSPF."; } description "OSPF-specific route attributes."; uses route-content; } /* * RPCs */ rpc clear-neighbor { description "This RPC request clears a particular set of OSPF neighbors. If the operation fails for OSPF internal reason, then error-tag and error-app-tag should be set to a meaningful value."; input { leaf routing-protocol-name { Yeung, et al. Expires April 19, 2020 [Page 112] Internet-Draft OSPF YANG Data Model October 2019 type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "OSPF protocol instance which information for neighbors are to be cleared. If the referenced OSPF instance doesn't exist, then this operation SHALL fail with error-tag 'data-missing' and error-app-tag 'routing-protocol-instance-not-found'."; } leaf interface { type if:interface-ref; description "Name of the OSPF interface for which neighbors are to be cleared. If the referenced OSPF interface doesn't exist, then this operation SHALL fail with error-tag 'data-missing' and error-app-tag 'ospf-interface-not-found'."; } } } rpc clear-database { description "This RPC request clears a particular OSPF Link State Database. If the operation fails for OSPF internal reason, then error-tag and error-app-tag should be set to a meaningful value."; input { leaf routing-protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "OSPF protocol instance whose Link State Database is to be cleared. If the referenced OSPF instance doesn't exist, then this operation SHALL fail with error-tag 'data-missing' Yeung, et al. Expires April 19, 2020 [Page 113] Internet-Draft OSPF YANG Data Model October 2019 and error-app-tag 'routing-protocol-instance-not-found'."; } } } /* * Notifications */ grouping notification-instance-hdr { description "This grouping describes common instance specific data for OSPF notifications."; leaf routing-protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } must "derived-from( " + "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol[rt:name=current()]/" + "rt:type, 'ospf')"; description "OSPF routing protocol instance name."; } leaf address-family { type leafref { path "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol" + "[rt:name=current()/../routing-protocol-name]/" + "ospf/address-family"; } description "Address family of the OSPF instance."; } } grouping notification-interface { description "This grouping provides interface information for the OSPF interface specific notification."; choice if-link-type-selection { description "Options for link type."; Yeung, et al. Expires April 19, 2020 [Page 114] Internet-Draft OSPF YANG Data Model October 2019 container interface { description "Normal interface."; leaf interface { type if:interface-ref; description "Interface."; } } container virtual-link { description "virtual-link."; leaf transit-area-id { type area-id-type; description "Area ID."; } leaf neighbor-router-id { type rt-types:router-id; description "Neighbor Router ID."; } } container sham-link { description "sham link."; leaf area-id { type area-id-type; description "Area ID."; } leaf local-ip-addr { type inet:ip-address; description "Sham link local address."; } leaf remote-ip-addr { type inet:ip-address; description "Sham link remote address."; } } } } grouping notification-neighbor { description "This grouping provides the neighbor information for neighbor specific notifications."; leaf neighbor-router-id { type rt-types:router-id; description "Neighbor Router ID."; } leaf neighbor-ip-addr { type inet:ip-address; Yeung, et al. Expires April 19, 2020 [Page 115] Internet-Draft OSPF YANG Data Model October 2019 description "Neighbor address."; } } notification if-state-change { uses notification-instance-hdr; uses notification-interface; leaf state { type if-state-type; description "Interface state."; } description "This notification is sent when an interface state change is detected."; } notification if-config-error { uses notification-instance-hdr; uses notification-interface; leaf packet-source { type inet:ip-address; description "Source address."; } leaf packet-type { type packet-type; description "OSPF packet type."; } leaf error { type enumeration { enum "bad-version" { description "Bad version."; } enum "area-mismatch" { description "Area mismatch."; } enum "unknown-nbma-nbr" { description "Unknown NBMA neighbor."; } enum "unknown-virtual-nbr" { description "Unknown virtual link neighbor."; } enum "auth-type-mismatch" { description "Auth type mismatch."; } Yeung, et al. Expires April 19, 2020 [Page 116] Internet-Draft OSPF YANG Data Model October 2019 enum "auth-failure" { description "Auth failure."; } enum "net-mask-mismatch" { description "Network mask mismatch."; } enum "hello-interval-mismatch" { description "Hello interval mismatch."; } enum "dead-interval-mismatch" { description "Dead interval mismatch."; } enum "option-mismatch" { description "Option mismatch."; } enum "mtu-mismatch" { description "MTU mismatch."; } enum "duplicate-router-id" { description "Duplicate Router ID."; } enum "no-error" { description "No error."; } } description "Error code."; } description "This notification is sent when an interface config error is detected."; } notification nbr-state-change { uses notification-instance-hdr; uses notification-interface; uses notification-neighbor; leaf state { type nbr-state-type; description "Neighbor state."; } description "This notification is sent when a neighbor state change is detected."; } notification nbr-restart-helper-status-change { Yeung, et al. Expires April 19, 2020 [Page 117] Internet-Draft OSPF YANG Data Model October 2019 uses notification-instance-hdr; uses notification-interface; uses notification-neighbor; leaf status { type restart-helper-status-type; description "Restart helper status."; } leaf age { type rt-types:timer-value-seconds16; description "Remaining time in current OSPF graceful restart interval when the router is acting as a restart helper for the neighbor."; } leaf exit-reason { type restart-exit-reason-type; description "Restart helper exit reason."; } description "This notification is sent when a neighbor restart helper status change is detected."; } notification if-rx-bad-packet { uses notification-instance-hdr; uses notification-interface; leaf packet-source { type inet:ip-address; description "Source address."; } leaf packet-type { type packet-type; description "OSPF packet type."; } description "This notification is sent when an OSPF packet that cannot be parsed is received on an OSPF interface."; } notification lsdb-approaching-overflow { uses notification-instance-hdr; Yeung, et al. Expires April 19, 2020 [Page 118] Internet-Draft OSPF YANG Data Model October 2019 leaf ext-lsdb-limit { type uint32; description "The maximum number of non-default AS-external LSAs entries that can be stored in the Link State Database."; } description "This notification is sent when the number of LSAs in the router's Link State Database has exceeded ninety percent of the AS-external limit (ext-lsdb-limit)."; } notification lsdb-overflow { uses notification-instance-hdr; leaf ext-lsdb-limit { type uint32; description "The maximum number of non-default AS-external LSAs entries that can be stored in the Link State Database."; } description "This notification is sent when the number of LSAs in the router's Link State Database has exceeded the AS-external limit (ext-lsdb-limit)."; } notification nssa-translator-status-change { uses notification-instance-hdr; leaf area-id { type area-id-type; description "Area ID."; } leaf status { type nssa-translator-state-type; description "NSSA translator status."; } description "This notification is sent when there is a change in the router's role in translating OSPF NSSA LSAs to OSPF AS-External LSAs."; } Yeung, et al. Expires April 19, 2020 [Page 119] Internet-Draft OSPF YANG Data Model October 2019 notification restart-status-change { uses notification-instance-hdr; leaf status { type restart-status-type; description "Restart status."; } leaf restart-interval { type uint16 { range 1..1800; } units seconds; default "120"; description "Restart interval."; } leaf exit-reason { type restart-exit-reason-type; description "Restart exit reason."; } description "This notification is sent when the graceful restart state for the router has changed."; } } 4. Security Considerations The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre- configured subset of all available NETCONF or RESTCONF protocol operations and content. Yeung, et al. Expires April 19, 2020 [Page 120] Internet-Draft OSPF YANG Data Model October 2019 There are a number of data nodes defined in ietf-ospf.yang module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Writable data node represent configuration of each instance, area, virtual link, sham-link, and interface. These correspond to the following schema nodes: /ospf /ospf/areas/ /ospf/areas/area[area-id] /ospf/virtual-links/ /ospf/virtual-links/virtual-link[transit-area-id router-id] /ospf/areas/area[area-id]/interfaces /ospf/areas/area[area-id]/interfaces/interface[name] /ospf/area/area[area-id]/sham-links /ospf/area/area[area-id]/sham-links/sham-link[local-id remote-id] For OSPF, the ability to modify OSPF configuration will allow the entire OSPF domain to be compromised including peering with unauthorized routers to misroute traffic or mount a massive Denial- of-Service (DoS) attack. For example, adding OSPF on any unprotected interface could allow an OSPF adjacency to be formed with an unauthorized and malicious neighbor. Once an adjacency is formed, traffic could be hijacked. As a simpler example, a Denial-of-Service attack could be mounted by changing the cost of an OSPF interface to be asymmetric such that a hard routing loop ensues. In general, unauthorized modification of most OSPF features will pose there own set of security risks and the "Security Considerations" in the respective reference RFCs should be consulted. Some of the readable data nodes in the ietf-ospf.yang module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The exposure of the Link State Database (LSDB) will expose the detailed topology of the network. There is a separate Link State Database for each instance, area, virtual link, sham-link, and interface. These correspond to the following schema nodes: Yeung, et al. Expires April 19, 2020 [Page 121] Internet-Draft OSPF YANG Data Model October 2019 /ospf/database /ospf/areas/area[area-id]/database /ospf/virtual-links/virtual-link[transit-area-id router- id]/database /ospf/areas/area[area-id]/interfaces/interface[name]/database /ospf/area/area[area-id]/sham-links/sham-link[local-id remote- id]/database Exposure of the Link State Database includes information beyond the scope of the OSPF router and this may be undesirable since exposure may facilitate other attacks. Additionally, in the case of an area LSDB, the complete IP network topology and, if deployed, the traffic engineering topology of the OSPF area can be reconstucted. Network operators may consider their topologies to be sensitive confidential data. For OSPF authentication, configuration is supported via the specification of key-chains [RFC8177] or the direct specification of key and authentication algorithm. Hence, authentication configuration using the "auth-table-trailer" case in the "authentication" container inherits the security considerations of [RFC8177]. This includes the considerations with respect to the local storage and handling of authentication keys. Additionally, local specification of OSPF authentication keys and the associated authentication algorithm is supported for legacy implementations that do not support key-chains [RFC8177] It is RECOMMENDED that implementations migrate to key-chains due the seamless support of key and algorithm rollover, as well as, the hexadecimal key specification affording more key entropy, and encryption of keys using the Advanced Encryption Standard (AES) Key Wrap Padding Algorithm [RFC5649]. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. The OSPF YANG module supports the "clear-neighbor" and "clear-database" RPCs. If access to either of these is compromised, they can result in temporary network outages be employed to mount DoS attacks. The actual authentication key data (whether locally specified or part of a key-chain) is sensitive and needs to be kept secret from unauthorized parties; compromise of the key data would allow an Yeung, et al. Expires April 19, 2020 [Page 122] Internet-Draft OSPF YANG Data Model October 2019 attacker to forge OSPF traffic that would be accepted as authentic, potentially compromising the entirety OSPF domain. 5. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-ospf Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-ospf namespace: urn:ietf:params:xml:ns:yang:ietf-ospf prefix: ospf reference: RFC XXXX 6. Acknowledgements The authors wish to thank Yi Yang, Alexander Clemm, Gaurav Gupta, Ladislav Lhotka, Stephane Litkowski, Greg Hankins, Manish Gupta, Michael Darwish, and Alan Davey for their thorough reviews and helpful comments. Thanks to Tom Petch for last call review and improvement of the document organization. Thanks to Alvaro Retana for AD comments. Thanks to Benjamin Kaduk, Suresh Krishnan, and Roman Dannyliw for IESG review comments. This document was produced using Marshall Rose's xml2rfc tool. Author affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed. MITRE has approved this document for Public Release, Distribution Unlimited, with Public Release Case Number 18-3194. Yeung, et al. Expires April 19, 2020 [Page 123] Internet-Draft OSPF YANG Data Model October 2019 7. References 7.1. Normative References [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work in progress), August 2018. [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, DOI 10.17487/RFC1765, March 1995, . [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, DOI 10.17487/RFC1793, April 1995, . [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, . [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, . [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . Yeung, et al. Expires April 19, 2020 [Page 124] Internet-Draft OSPF YANG Data Model October 2019 [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, DOI 10.17487/RFC4576, June 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, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC4973] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering", RFC 4973, DOI 10.17487/RFC4973, July 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, . [RFC5185] Mirtorabi, S., Psenak, P., Lindem, A., Ed., and A. Oswal, "OSPF Multi-Area Adjacency", RFC 5185, DOI 10.17487/RFC5185, May 2008, . [RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful Restart", RFC 5187, DOI 10.17487/RFC5187, June 2008, . [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [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, . [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, . Yeung, et al. Expires April 19, 2020 [Page 125] Internet-Draft OSPF YANG Data Model October 2019 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI 10.17487/RFC5613, August 2009, . [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, DOI 10.17487/RFC5642, August 2009, . [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, . [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, . [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [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, . Yeung, et al. Expires April 19, 2020 [Page 126] Internet-Draft OSPF YANG Data Model October 2019 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, June 2012, . [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC6845, January 2013, . [RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, DOI 10.17487/RFC6860, January 2013, . [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, . [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, . [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, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . Yeung, et al. Expires April 19, 2020 [Page 127] Internet-Draft OSPF YANG Data Model October 2019 [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising Node Administrative Tags in OSPF", RFC 7777, DOI 10.17487/RFC7777, March 2016, . [RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, "OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators", RFC 7884, DOI 10.17487/RFC7884, July 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Yeung, et al. Expires April 19, 2020 [Page 128] Internet-Draft OSPF YANG Data Model October 2019 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, DOI 10.17487/RFC8405, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, . 7.2. Informative References [RFC0905] "ISO Transport Protocol specification ISO DP 8073", RFC 905, DOI 10.17487/RFC0905, April 1984, . [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, . [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, . [RFC5643] Joyal, D., Ed. and V. Manral, Ed., "Management Information Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August 2009, . [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, . Yeung, et al. Expires April 19, 2020 [Page 129] Internet-Draft OSPF YANG Data Model October 2019 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . Yeung, et al. Expires April 19, 2020 [Page 130] Internet-Draft OSPF YANG Data Model October 2019 Appendix A. Contributors' Addresses Dean Bogdanovic Volta Networks, Inc. EMail: dean@voltanet.io Kiran Koushik Agrahara Sreenivasa Verizon 500 W Dove Rd Southlake, TX 76092 USA EMail: kk@employees.org Authors' Addresses Derek Yeung Arrcus EMail: derek@arrcus.com Yingzhen Qu Futurewei 2330 Central Expressway Santa Clara, CA 95050 USA EMail: yingzhen.qu@futurewei.com Jeffrey Zhang Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA EMail: zzhang@juniper.net Ing-Wher Chen The MITRE Corporation EMail: ingwherchen@mitre.org Yeung, et al. Expires April 19, 2020 [Page 131] Internet-Draft OSPF YANG Data Model October 2019 Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 EMail: acee@cisco.com Yeung, et al. Expires April 19, 2020 [Page 132] ./draft-ietf-rtcweb-jsep-26.txt0000644000764400076440000076623213435634761015641 0ustar iustyiusty Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track C. Jennings Expires: August 31, 2019 Cisco E. Rescorla, Ed. Mozilla February 27, 2019 JavaScript Session Establishment Protocol draft-ietf-rtcweb-jsep-26 Abstract This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling 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 https://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 31, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Uberti, et al. Expires August 31, 2019 [Page 1] Internet-Draft JSEP February 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 7 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 7 3.2. Session Descriptions and State Machine . . . . . . . . . 7 3.3. Session Description Format . . . . . . . . . . . . . . . 11 3.4. Session Description Control . . . . . . . . . . . . . . . 11 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 3.5.5. ICE Versions . . . . . . . . . . . . . . . . . . . . 16 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16 3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 25 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 28 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 30 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30 Uberti, et al. Expires August 31, 2019 [Page 2] Internet-Draft JSEP February 2019 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 31 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 34 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 35 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35 5.1.2. Profile Names and Interoperability . . . . . . . . . 35 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 37 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 37 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57 5.5. Processing a Local Description . . . . . . . . . . . . . 57 5.6. Processing a Remote Description . . . . . . . . . . . . . 58 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58 5.8. Parsing a Session Description . . . . . . . . . . . . . . 59 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 60 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64 5.9. Applying a Local Description . . . . . . . . . . . . . . 65 5.10. Applying a Remote Description . . . . . . . . . . . . . . 67 5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 71 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 74 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.2. Informative References . . . . . . . . . . . . . . . . . 100 Uberti, et al. Expires August 31, 2019 [Page 3] Internet-Draft JSEP February 2019 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 103 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115 1. Introduction This document describes how the W3C WEBRTC RTCPeerConnection interface [W3C.webrtc] is used to control the setup, management and teardown of a multimedia session. 1.1. General Design of JSEP WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible. The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case. In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. With these considerations in mind, this document describes the JavaScript Session Establishment Protocol (JSEP) that allows for full control of the signaling state machine from JavaScript. As described above, JSEP assumes a model in which a JavaScript application executes inside a runtime containing WebRTC APIs (the "JSEP implementation"). The JSEP implementation is almost entirely divorced from the core signaling flow, which is instead handled by the JavaScript making use of two interfaces: (1) passing in local and remote session descriptions and (2) interacting with the ICE state machine. The combination of the JSEP implementation and the JavaScript application is referred to throughout this document as a "JSEP endpoint". In this document, the use of JSEP is described as if it always occurs between two JSEP endpoints. Note though in many cases it will actually be between a JSEP endpoint and some kind of server, such as a gateway or MCU. This distinction is invisible to the JSEP endpoint; it just follows the instructions it is given via the API. JSEP's handling of session descriptions is simple and straightforward. Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API. The application then uses that offer to set up its local config via the setLocalDescription() API. The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., Uberti, et al. Expires August 31, 2019 [Page 4] Internet-Draft JSEP February 2019 WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the initiator over the signaling channel. When the initiator gets that answer, it installs it using the setRemoteDescription() API, and initial setup is complete. This process can be repeated for additional offer/answer exchanges. Regarding ICE [RFC8445], JSEP decouples the ICE state machine from the overall signaling state machine, as the ICE state machine must remain in the JSEP implementation, because only the implementation has the necessary knowledge of candidates and other transport information. Performing this separation provides additional flexibility in protocols that decouple session descriptions from transport. For instance, in traditional SIP, each offer or answer is self-contained, including both the session descriptions and the transport information. However, [I-D.ietf-mmusic-trickle-ice-sip] allows SIP to be used with trickle ICE [I-D.ietf-ice-trickle], in which the session description can be sent immediately and the transport information can be sent when available. Sending transport information separately can allow for faster ICE and DTLS startup, since ICE checks can start as soon as any transport information is available rather than waiting for all of it. JSEP's decoupling of the ICE and signaling state machines allows it to accommodate either model. Through its abstraction of signaling, the JSEP approach does require the application to be aware of the signaling process. While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer; said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher level call-oriented interface to the application developer. For example, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP. Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. Uberti, et al. Expires August 31, 2019 [Page 5] Internet-Draft JSEP February 2019 1.2. Other Approaches Considered One approach that was considered instead of JSEP was to include a lightweight signaling protocol. Instead of providing session descriptions to the API, the API would produce and consume messages from this protocol. While providing a more high-level API, this put more control of signaling within the JSEP implementation, forcing it to have to understand and handle concepts like signaling glare (see [RFC3264], Section 4). A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component directly. This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented. In addition, these API points could be called in any order, resulting in a more complex set of interactions with the media subsystem than the JSEP approach, which specifies how session descriptions are to be evaluated and applied. One variation on JSEP that was considered was to keep the basic session description-oriented API, but to move the mechanism for generating offers and answers out of the JSEP implementation. Instead of providing createOffer/createAnswer methods within the implementation, this approach would instead expose a getCapabilities API which would provide the application with the information it needed in order to generate its own session descriptions. This increases the amount of work that the application needs to do; it needs to know how to generate session descriptions from capabilities, and especially how to generate the correct answer from an arbitrary offer and the supported capabilities. While this could certainly be addressed by using a library like the one mentioned above, it basically forces the use of said library even for a simple example. Providing createOffer/createAnswer avoids this problem. 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]. Uberti, et al. Expires August 31, 2019 [Page 6] Internet-Draft JSEP February 2019 3. Semantics and Syntax 3.1. Signaling Model JSEP does not specify a particular signaling model or state machine, other than the generic need to exchange session descriptions in the fashion described by [RFC3264] (offer/answer) in order for both sides of the session to know how to conduct the session. JSEP provides mechanisms to create offers and answers, as well as to apply them to a session. However, the JSEP implementation is totally decoupled from the actual mechanism by which these offers and answers are communicated to the remote side, including addressing, retransmission, forking, and glare handling. These issues are left entirely up to the application; the application has complete control over which offers and answers get handed to the implementation, and when. +-----------+ +-----------+ | Web App |<--- App-Specific Signaling -->| Web App | +-----------+ +-----------+ ^ ^ | SDP | SDP V V +-----------+ +-----------+ | JSEP |<----------- Media ------------>| JSEP | | Impl. | | Impl. | +-----------+ +-----------+ Figure 1: JSEP Signaling Model 3.2. Session Descriptions and State Machine In order to establish the media plane, the JSEP implementation needs specific parameters to indicate what to transmit to the remote side, as well as how to handle the media that is received. These parameters are determined by the exchange of session descriptions in offers and answers, and there are certain details to this process that must be handled in the JSEP APIs. Whether a session description applies to the local side or the remote side affects the meaning of that description. For example, the list of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative and the remote side MUST either accept them or reject Uberti, et al. Expires August 31, 2019 [Page 7] Internet-Draft JSEP February 2019 them altogether. An example of such a parameter is the DTLS fingerprints [RFC8122], which are calculated based on the local certificate(s) offered, and are not subject to negotiation. In addition, various RFCs put different conditions on the format of offers versus answers. For example, an offer may propose an arbitrary number of m= sections (i.e., media descriptions as described in [RFC4566], Section 5.14), but an answer must contain the exact same number as the offer. Lastly, while the exact media parameters are only known only after an offer and an answer have been exchanged, the offerer may receive ICE checks, and possibly media (e.g., in the case of a re-offer after a connection has been established) before it receives an answer. To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. Therefore, in order to handle session descriptions properly, the JSEP implementation needs: 1. To know if a session description pertains to the local or remote side. 2. To know if a session description is an offer or an answer. 3. To allow the offer to be specified independently of the answer. JSEP addresses this by adding both setLocalDescription and setRemoteDescription methods and having session description objects contain a type field indicating the type of session description being supplied. This satisfies the requirements listed above for both the offerer, who first calls setLocalDescription(sdp [offer]) and then later setRemoteDescription(sdp [answer]), as well as for the answerer, who first calls setRemoteDescription(sdp [offer]) and then later setLocalDescription(sdp [answer]). During the offer/answer exchange, the outstanding offer is considered to be "pending" at the offerer and the answerer, as it may either be accepted or rejected. If this is a re-offer, each side will also have "current" local and remote descriptions, which reflect the result of the last offer/answer exchange. Sections Section 4.1.12, Section 4.1.14, Section 4.1.11, and Section 4.1.13, provide more detail on pending and current descriptions. JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order Uberti, et al. Expires August 31, 2019 [Page 8] Internet-Draft JSEP February 2019 to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known. These "resources" can include things like extra ICE components, TURN candidates, or video decoders. Provisional answers, on the other hand, do no such deallocation; as a result, multiple dissimilar provisional answers, with their own codec choices, transport parameters, etc., can be received and applied during call setup. Note that the final answer itself may be different than any received provisional answers. In [RFC3264], the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack level, a new offer can be generated at any point. For example, when using SIP for signaling, if one offer is sent, then cancelled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer. To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the JavaScript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows: Uberti, et al. Expires August 31, 2019 [Page 9] Internet-Draft JSEP February 2019 setRemote(OFFER) setLocal(PRANSWER) /-----\ /-----\ | | | | v | v | +---------------+ | +---------------+ | | |----/ | |----/ | have- | setLocal(PRANSWER) | have- | | remote-offer |------------------- >| local-pranswer| | | | | | | | | +---------------+ +---------------+ ^ | | | | setLocal(ANSWER) | setRemote(OFFER) | | | V setLocal(ANSWER) | +---------------+ | | | | | |<---------------------------+ | stable | | |<---------------------------+ | | | +---------------+ setRemote(ANSWER) | ^ | | | | setLocal(OFFER) | setRemote(ANSWER) | | | V | +---------------+ +---------------+ | | | | | have- | setRemote(PRANSWER) |have- | | local-offer |------------------- >|remote-pranswer| | | | | | |----\ | |----\ +---------------+ | +---------------+ | ^ | ^ | | | | | \-----/ \-----/ setLocal(OFFER) setRemote(PRANSWER) Figure 2: JSEP State Machine Aside from these state transitions there is no other difference between the handling of provisional ("pranswer") and final ("answer") answers. Uberti, et al. Expires August 31, 2019 [Page 10] Internet-Draft JSEP February 2019 3.3. Session Description Format JSEP's session descriptions use SDP syntax for their internal representation. While this format is not optimal for manipulation from JavaScript, it is widely accepted, and frequently updated with new features; any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP. If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. As detailed below, most applications should be able to treat the SessionDescriptions produced and consumed by these various API calls as opaque blobs; that is, the application will not need to read or change them. 3.4. Session Description Control In order to give the application control over various common session parameters, JSEP provides control surfaces which tell the JSEP implementation how to generate session descriptions. This avoids the need for JavaScript to modify session descriptions in most cases. Changes to these objects result in changes to the session descriptions generated by subsequent createOffer/Answer calls. 3.4.1. RtpTransceivers RtpTransceivers allow the application to control the RTP media associated with one m= section. Each RtpTransceiver has an RtpSender and an RtpReceiver, which an application can use to control the sending and receiving of RTP media. The application may also modify the RtpTransceiver directly, for instance, by stopping it. RtpTransceivers generally have a 1:1 mapping with m= sections, although there may be more RtpTransceivers than m= sections when RtpTransceivers are created but not yet associated with a m= section, or if RtpTransceivers have been stopped and disassociated from m= sections. An RtpTransceiver is said to be associated with an m= section if its mid property is non-null; otherwise it is said to be disassociated. The associated m= section is determined using a mapping between transceivers and m= section indices, formed when creating an offer or applying a remote offer. Uberti, et al. Expires August 31, 2019 [Page 11] Internet-Draft JSEP February 2019 An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. However, in certain cases where a m= section has been rejected, as discussed in Section 5.2.2 below, that m= section will be "recycled" and associated with a new RtpTransceiver with a new mid value. RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds new m= sections. 3.4.2. RtpSenders RtpSenders allow the application to control how RTP media is sent. An RtpSender is conceptually responsible for the outgoing RTP stream(s) described by an m= section. This includes encoding the attached MediaStreamTrack, sending RTP media packets, and generating/ processing RTCP for the outgoing RTP streams(s). 3.4.3. RtpReceivers RtpReceivers allow the application to inspect how RTP media is received. An RtpReceiver is conceptually responsible for the incoming RTP stream(s) described by an m= section. This includes processing received RTP media packets, decoding the incoming stream(s) to produce a remote MediaStreamTrack, and generating/ processing RTCP for the incoming RTP stream(s). 3.5. ICE 3.5.1. ICE Gathering Overview JSEP gathers ICE candidates as needed by the application. Collection of ICE candidates is referred to as a gathering phase, and this is triggered either by the addition of a new or recycled m= section to the local session description, or new ICE credentials in the description, indicating an ICE restart. Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the JSEP implementation in response to changes in the ICE configuration. When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set. When this bit is set, calls to the createOffer API will generate new ICE credentials. This bit is cleared by a call to the setLocalDescription API with new ICE credentials from either an offer or an answer, i.e., from either a local- or remote-initiated ICE restart. Uberti, et al. Expires August 31, 2019 [Page 12] Internet-Draft JSEP February 2019 When a new gathering phase starts, the ICE agent will notify the application that gathering is occurring through an event. Then, when each new ICE candidate becomes available, the ICE agent will supply it to the application via an additional event; these candidates will also automatically be added to the current and/or pending local session description. Finally, when all candidates have been gathered, an event will be dispatched to signal that the gathering process is complete. Note that gathering phases only gather the candidates needed by new/recycled/restarting m= sections; other m= sections continue to use their existing candidates. Also, if an m= section is bundled (either by a successful bundle negotiation or by being marked as bundle-only), then candidates will be gathered and exchanged for that m= section if and only if its MID is a BUNDLE-tag, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. 3.5.2. ICE Candidate Trickling Candidate trickling is a technique through which a caller may incrementally provide candidates to the callee after the initial offer has been dispatched; the semantics of "Trickle ICE" are defined in [I-D.ietf-ice-trickle]. This process allows the callee to begin acting upon the call and setting up the ICE (and perhaps DTLS) connections immediately, without having to wait for the caller to gather all possible candidates. This results in faster media setup in cases where gathering is not performed prior to initiating the call. JSEP supports optional candidate trickling by providing APIs, as described above, that provide control and feedback on the ICE candidate gathering process. Applications that support candidate trickling can send the initial offer immediately and send individual candidates when they get the notified of a new candidate; applications that do not support this feature can simply wait for the indication that gathering is complete, and then create and send their offer, with all the candidates, at this time. Upon receipt of trickled candidates, the receiving application will supply them to its ICE agent. This triggers the ICE agent to start using the new remote candidates for connectivity checks. 3.5.2.1. ICE Candidate Format In JSEP, ICE candidates are abstracted by an IceCandidate object, and as with session descriptions, SDP syntax is used for the internal representation. Uberti, et al. Expires August 31, 2019 [Page 13] Internet-Draft JSEP February 2019 The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. Note that this field does not contain an "a=" prefix, as indicated in the following example: candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts. If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. The IceCandidate object also contains fields to indicate which m= section it is associated with, which can be identified in one of two ways, either by a m= section index, or a MID. The m= section index is a zero-based index, with index N referring to the N+1th m= section in the session description referenced by this IceCandidate. The MID is a "media stream identification" value, as defined in [RFC5888], Section 4, which provides a more robust way to identify the m= section in the session description, using the MID of the associated RtpTransceiver object (which may have been locally generated by the answerer when interacting with a non-JSEP endpoint that does not support the MID attribute, as discussed in Section 5.10 below). If the MID field is present in a received IceCandidate, it MUST be used for identification; otherwise, the m= section index is used instead. When creating an IceCandidate object, JSEP implementations MUST populate each of the candidate, ufrag, m= section index, and MID fields. Implementations MUST also be prepared to receive objects with some fields missing, as mentioned above. 3.5.3. ICE Candidate Policy Typically, when gathering ICE candidates, the JSEP implementation will gather all possible forms of initial candidates - host, server reflexive, and relay. However, in certain cases, applications may want to have more specific control over the gathering process, due to privacy or related concerns. For example, one may want to only use relay candidates, to leak as little location information as possible (keeping in mind that this choice comes with corresponding operational costs). To accomplish this, JSEP allows the application Uberti, et al. Expires August 31, 2019 [Page 14] Internet-Draft JSEP February 2019 to restrict which ICE candidates are used in a session. Note that this filtering is applied on top of any restrictions the implementation chooses to enforce regarding which IP addresses are permitted for the application, as discussed in [I-D.ietf-rtcweb-ip-handling]. There may also be cases where the application wants to change which types of candidates are used while the session is active. A prime example is where a callee may initially want to use only relay candidates, to avoid leaking location information to an arbitrary caller, but then change to use all candidates (for lower operational cost) once the user has indicated they want to take the call. For this scenario, the JSEP implementation MUST allow the candidate policy to be changed in mid-session, subject to the aforementioned interactions with local policy. To administer the ICE candidate policy, the JSEP implementation will determine the current setting at the start of each gathering phase. Then, during the gathering phase, the implementation MUST NOT expose candidates disallowed by the current policy to the application, use them as the source of connectivity checks, or indirectly expose them via other fields, such as the raddr/rport attributes for other ICE candidates. Later, if a different policy is specified by the application, the application can apply it by kicking off a new gathering phase via an ICE restart. 3.5.4. ICE Candidate Pool JSEP applications typically inform the JSEP implementation to begin ICE gathering via the information supplied to setLocalDescription, as the local description indicates the number of ICE components which will be needed and for which candidates must be gathered. However, to accelerate cases where the application knows the number of ICE components to use ahead of time, it may ask the implementation to gather a pool of potential ICE candidates to help ensure rapid media setup. When setLocalDescription is eventually called, and the JSEP implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the application immediately via the ICE candidate event. If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual. This only occurs for the first offer/answer exchange, after which the candidate pool is emptied and no longer used. Uberti, et al. Expires August 31, 2019 [Page 15] Internet-Draft JSEP February 2019 One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to minimize the time it takes to establish connectivity, to avoid clipping of initial media. By pre-gathering candidates into the pool, it can exchange and start sending connectivity checks from these candidates almost immediately upon receipt of a call. Note though that by holding on to these pre-gathered candidates, which will be kept alive as long as they may be needed, the application will consume resources on the STUN/TURN servers it is using. 3.5.5. ICE Versions While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one. Implementations MUST be able to accept remote descriptions that do not have the "ice2" attribute. 3.6. Video Size Negotiation Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute [RFC6236] to indicate what video frame sizes it is capable of receiving. A receiver may have hard limits on what its video decoder can process, or it may have some maximum set by policy. By specifying these limits in an "a=imageattr" attribute, JSEP endpoints can attempt to ensure that the remote sender transmits video at an acceptable resolution. However, when communicating with a non-JSEP endpoint that does not understand this attribute, any signaled limits may be exceeded, and the JSEP implementation MUST handle this gracefully, e.g., by discarding the video. Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels). JSEP implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. However, sample aspect ratio has no impact on the size negotiation described below; all dimensions are measured in pixels, whether square or not. 3.6.1. Creating an imageattr Attribute The receiver will first intersect any known local limits (e.g., hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive. If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. Uberti, et al. Expires August 31, 2019 [Page 16] Internet-Draft JSEP February 2019 If these local limits preclude receiving any video, i.e., the degenerate case of no permitted resolutions, the "a=imageattr" attribute MUST be omitted, and the m= section MUST be marked as sendonly/inactive, as appropriate. Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and maximum x= and y= values. The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important. It SHOULD be set to 1.0. The "a=imageattr" field is payload type specific. When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED. However, when the supported video codecs have different limitations, specific "a=imageattr" attributes MUST be inserted for each payload type. As an example, consider a system with a multiformat video decoder, which is capable of decoding any resolution from 48x48 to 720p, In this case, the implementation would generate this attribute: a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] This declaration indicates that the receiver is capable of decoding any image resolution from 48x48 up to 1280x720 pixels. 3.6.2. Interpreting imageattr Attributes [RFC6236] defines "a=imageattr" to be an advisory field. This means that it does not absolutely constrain the video formats that the sender can use, but gives an indication of the preferred values. This specification prescribes more specific behavior. When a MediaStreamTrack, which is producing video of a certain resolution (the "track resolution"), is attached to a RtpSender, which is encoding the track video at the same or lower resolution(s) (the "encoder resolutions"), and a remote description is applied that references the sender and contains valid "a=imageattr recv" attributes, it MUST follow the rules below to ensure the sender does not transmit a resolution that would exceed the size criteria specified in the attributes. These rules MUST be followed as long as the attributes remain present in the remote description, including cases in which the track changes its resolution, or is replaced with a different track. Uberti, et al. Expires August 31, 2019 [Page 17] Internet-Draft JSEP February 2019 Depending on how the RtpSender is configured, it may be producing a single encoding at a certain resolution, or, if simulcast Section 3.7 has been negotiated, multiple encodings, each at their own specific resolution. In addition, depending on the configuration, each encoding may have the flexibility to reduce resolution when needed, or may be locked to a specific output resolution. For each encoding being produced by the RtpSender, the set of "a=imageattr recv" attributes in the corresponding m= section of the remote description is processed to determine what should be transmitted. Only attributes that reference the media format selected for the encoding are considered; each such attribute is evaluated individually, starting with the attribute with the highest "q=" value. If multiple attributes have the same "q=" value, they are evaluated in the order they appear in their containing m= section. Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. For each "a=imageattr recv" attribute, the following rules are applied. If this processing is successful, the encoding is transmitted accordingly, and no further attributes are considered for that encoding. Otherwise, the next attribute is evaluated, in the aforementioned order. If none of the supplied attributes can be processed successfully, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. o The limits from the attribute are compared to the encoder resolution. Only the specific limits mentioned below are considered; any other values, such as picture aspect ratio, MUST be ignored. When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO [TS26.114]), as it significantly simplifies the matching logic. o If the attribute includes a "sar=" (sample aspect ratio) value set to something other than "1.0", indicating the receiver wants to receive non-square pixels, this cannot be satisfied and the attribute MUST NOT be used. o If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to satisfy the limits. Downscaling MUST NOT change the picture aspect ratio of the encoding, ignoring any trivial differences due to rounding. For example, if the encoder resolution is 1280x720, Uberti, et al. Expires August 31, 2019 [Page 18] Internet-Draft JSEP February 2019 and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360. If downscaling cannot be applied, the attribute MUST NOT be used. o If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST NOT apply upscaling. JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. o If the encoder resolution is within the maximum and minimum sizes, no action is needed. 3.7. Simulcast JSEP supports simulcast transmission of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding. This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. Applications request support for simulcast by configuring multiple encodings on an RtpSender. Upon generation of an offer or answer, these encodings are indicated via SDP markings on the corresponding m= section, as described below. Receivers that understand simulcast and are willing to receive it will also include SDP markings to indicate their support, and JSEP endpoints will use these markings to determine whether simulcast is permitted for a given RtpSender. If simulcast support is not negotiated, the RtpSender will only use the first configured encoding. Note that the exact simulcast parameters are up to the sending application. While the aforementioned SDP markings are provided to ensure the remote side can receive and demux multiple simulcast encodings, the specific resolutions and bitrates to be used for each encoding are purely a send-side decision in JSEP. JSEP currently does not provide a mechanism to configure receipt of simulcast. This means that if simulcast is offered by the remote endpoint, the answer generated by a JSEP endpoint will not indicate support for receipt of simulcast, and as such the remote endpoint will only send a single encoding per m= section. In addition, JSEP does not provide a mechanism to handle an incoming offer requesting simulcast from the JSEP endpoint. This means that setting up simulcast in the case where the JSEP endpoint receives the Uberti, et al. Expires August 31, 2019 [Page 19] Internet-Draft JSEP February 2019 initial offer requires out-of-band signaling or SDP inspection. However, in the case where the JSEP endpoint sets up simulcast in its in initial offer, any established simulcast streams will continue to work upon receipt of an incoming re-offer. Future versions of this specification may add additional APIs to handle the incoming initial offer scenario. When using JSEP to transmit multiple encodings from a RtpSender, the techniques from [I-D.ietf-mmusic-sdp-simulcast] and [I-D.ietf-mmusic-rid] are used. Specifically, when multiple encodings have been configured for a RtpSender, the m= section for the RtpSender will include an "a=simulcast" attribute, as defined in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each encoding, as specified in [I-D.ietf-mmusic-rid], Section 4; the use of RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section. 3.8. Interactions With Forking Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device. For example, SIP [RFC3261] defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside the scope of JSEP, they do have some impact on the configuration of the media plane that is relevant. When forking happens at the signaling layer, the JavaScript application responsible for the signaling needs to make the decisions about what media should be sent or received at any point of time, as well as which remote endpoint it should communicate with; JSEP is used to make sure the media engine can make the RTP and media perform as required by the application. The basic operations that the applications can have the media engine do are: o Start exchanging media with a given remote peer, but keep all the resources reserved in the offer. o Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. 3.8.1. Sequential Forking Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one active session ever exists at a time; no mixing of received media is performed. Uberti, et al. Expires August 31, 2019 [Page 20] Internet-Draft JSEP February 2019 JSEP handles sequential forking well, allowing the application to easily control the policy for selecting the desired remote endpoint. When an answer arrives from one of the callees, the application can choose to apply it either as a provisional answer, leaving open the possibility of using a different answer in the future, or apply it as a final answer, ending the setup flow. In a "first-one-wins" situation, the first answer will be applied as a final answer, and the application will reject any subsequent answers. In SIP parlance, this would be ACK + BYE. In a "last-one-wins" situation, all answers would be applied as provisional answers, and any previous call leg will be terminated. At some point, the application will end the setup process, perhaps with a timer; at this point, the application could reapply the pending remote description as a final answer. 3.8.2. Parallel Forking Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple simultaneous active signaling sessions can be established as a result. If multiple callees send media at the same time, the possibilities for handling this are described in [RFC3960], Section 3.1. Most SIP devices today only support exchanging media with a single device at a time, and do not try to mix multiple early media audio sources, as that could result in a confusing situation. For example, consider having a European ringback tone mixed together with the North American ringback tone - the resulting sound would not be like either tone, and would confuse the user. If the signaling application wishes to only exchange media with one of the remote endpoints at a time, then from a media engine point of view, this is exactly like the sequential forking case. In the parallel forking case where the JavaScript application wishes to simultaneously exchange media with multiple peers, the flow is slightly more complex, but the JavaScript application can follow the strategy that [RFC3960] describes using UPDATE. The UPDATE approach allows the signaling to set up a separate media flow for each peer that it wishes to exchange media with. In JSEP, this offer used in the UPDATE would be formed by simply creating a new PeerConnection (see Section 4.1) and making sure that the same local media streams have been added into this new PeerConnection. Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in [RFC3960]. As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote Uberti, et al. Expires August 31, 2019 [Page 21] Internet-Draft JSEP February 2019 description and their own local and remote addresses. The media flow from these sessions can be managed using setDirection (see Section 4.2.3), or the application can choose to play out the media from all sessions mixed together. Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs. 4. Interface This section details the basic operations that must be present to implement JSEP functionality. The actual API exposed in the W3C API may have somewhat different syntax, but should map easily to these concepts. 4.1. PeerConnection 4.1.1. Constructor The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates, as well as the initial ICE candidate policy and pool size, and also the bundle policy to use. If an ICE candidate policy is specified, it functions as described in Section 3.5.3, causing the JSEP implementation to only surface the permitted candidates (including any implementation-internal filtering) to the application, and only use those candidates for connectivity checks. The set of available policies is as follows: all: All candidates permitted by implementation policy will be gathered and used. relay: All candidates except relay candidates will be filtered out. This obfuscates the location information that might be ascertained by the remote peer from the received candidates. Depending on how the application deploys and chooses relay servers, this could obfuscate location to a metro or possibly even global level. The default ICE candidate policy MUST be set to "all" as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for. Because pre- gathering results in utilizing STUN/TURN server resources for Uberti, et al. Expires August 31, 2019 [Page 22] Internet-Draft JSEP February 2019 potentially long periods of time, this must only occur upon application request, and therefore the default candidate pool size MUST be zero. The application can specify its preferred policy regarding use of bundle, the multiplexing mechanism defined in [I-D.ietf-mmusic-sdp-bundle-negotiation]. Regardless of policy, the application will always try to negotiate bundle onto a single transport, and will offer a single bundle group across all m= sections; use of this single transport is contingent upon the answerer accepting bundle. However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to bundle media streams together, which affects how it will interoperate with a non-bundle-aware endpoint. When negotiating with a non-bundle-aware endpoint, only the streams not marked as bundle- only streams will be established. The set of available policies is as follows: balanced: The first m= section of each type (audio, video, or application) will contain transport parameters, which will allow an answerer to unbundle that section. The second and any subsequent m= section of each type will be marked bundle-only. The result is that if there are N distinct media types, then candidates will be gathered for for N media streams. This policy balances desire to multiplex with the need to ensure basic audio and video can still be negotiated in legacy cases. When acting as answerer, if there is no bundle group in the offer, the implementation will reject all but the first m= section of each type. max-compat: All m= sections will contain transport parameters; none will be marked as bundle-only. This policy will allow all streams to be received by non-bundle-aware endpoints, but require separate candidates to be gathered for each media stream. max-bundle: Only the first m= section will contain transport parameters; all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. When acting as answerer, the implementation will reject any m= sections other than the first m= section, unless they are in the same bundle group as that m= section. Uberti, et al. Expires August 31, 2019 [Page 23] Internet-Draft JSEP February 2019 As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST be set to "balanced". The application can specify its preferred policy regarding use of RTP/RTCP multiplexing [RFC5761] using one of the following policies: negotiate: The JSEP implementation will gather both RTP and RTCP candidates but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. require: The JSEP implementation will only gather RTP candidates and will insert an "a=rtcp-mux-only" indication into any new m= sections in offers it generates. This halves the number of candidates that the offerer needs to gather. Applying a description with an m= section that does not contain an "a=rtcp- mux" attribute will cause an error to be returned. The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to set the multiplexing policy to "negotiate". 4.1.2. addTrack The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same "LS" group when creating an offer or answer. Adding tracks to the same "LS" group indicates that the playback of these tracks should be synchronized for proper lip sync, as described in [RFC5888], Section 7. addTrack attempts to minimize the number of transceivers as follows: If the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver that was created by the most recent call to setRemoteDescription() and does not have a local track. Otherwise, a new transceiver will be created, as described in Section 4.1.4. 4.1.3. removeTrack The removeTrack method removes a MediaStreamTrack from the PeerConnection, using the RtpSender argument to indicate which sender should have its track removed. The sender's track is cleared, and the sender stops sending. Future calls to createOffer will mark the m= section associated with the sender as recvonly (if transceiver.direction is sendrecv) or as inactive (if transceiver.direction is sendonly). Uberti, et al. Expires August 31, 2019 [Page 24] Internet-Draft JSEP February 2019 4.1.4. addTransceiver The addTransceiver method adds a new RtpTransceiver to the PeerConnection. If a MediaStreamTrack argument is provided, then the transceiver will be configured with that media type and the track will be attached to the transceiver. Otherwise, the application MUST explicitly specify the type; this mode is useful for creating recvonly transceivers as well as for creating transceivers to which a track can be attached at some later point. At the time of creation, the application can also specify a transceiver direction attribute, a set of MediaStreams which the transceiver is associated with (allowing LS group assignments), and a set of encodings for the media (used for simulcast as described in Section 3.7). 4.1.5. createDataChannel The createDataChannel method creates a new data channel and attaches it to the PeerConnection. If no data channel currently exists for this PeerConnection, then a new offer/answer exchange is required. All data channels on a given PeerConnection share the same SCTP/DTLS association and therefore the same m= section, so subsequent creation of data channels does not have any impact on the JSEP state. The createDataChannel method also includes a number of arguments which are used by the PeerConnection (e.g., maxPacketLifetime) but are not reflected in the SDP and do not affect the JSEP state. 4.1.6. createOffer The createOffer method generates a blob of SDP that contains a [RFC3264] offer with the supported configurations for the session, including descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent. An options parameter may be supplied to provide additional control over the generated offer. This options parameter allows an application to trigger an ICE restart, for the purpose of reestablishing connectivity. In the initial offer, the generated SDP will contain all desired functionality for the session (functionality that is supported but not desired by default may be omitted); for each SDP line, the generation of the SDP will follow the process defined for generating an initial offer from the document that specifies the given SDP line. The exact handling of initial offer generation is detailed in Section 5.2.1 below. Uberti, et al. Expires August 31, 2019 [Page 25] Internet-Draft JSEP February 2019 In the event createOffer is called after the session is established, createOffer will generate an offer to modify the current session based on any changes that have been made to the session, e.g., adding or stopping RtpTransceivers, or requesting an ICE restart. For each existing stream, the generation of each SDP line must follow the process defined for generating an updated offer from the RFC that specifies the given SDP line. For each new stream, the generation of the SDP must follow the process of generating an initial offer, as mentioned above. If no changes have been made, or for SDP lines that are unaffected by the requested changes, the offer will only contain the parameters negotiated by the last offer-answer exchange. The exact handling of subsequent offer generation is detailed in Section 5.2.2. below. Session descriptions generated by createOffer must be immediately usable by setLocalDescription; if a system has limited resources (e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those resources. Calling this method may do things such as generating new ICE credentials, but does not change the PeerConnection state, trigger candidate gathering, or cause media to start or stop flowing. Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. 4.1.7. createAnswer The createAnswer method generates a blob of SDP that contains a [RFC3264] SDP answer with the supported configuration for the session that is compatible with the parameters supplied in the most recent call to setRemoteDescription, which MUST have been called prior to calling createAnswer. Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any candidates that have been gathered by the ICE agent. An options parameter may be supplied to provide additional control over the generated answer. As an answer, the generated SDP will contain a specific configuration that specifies how the media plane should be established; for each SDP line, the generation of the SDP must follow the process defined for generating an answer from the document that specifies the given SDP line. The exact handling of answer generation is detailed in Section 5.3. below. Uberti, et al. Expires August 31, 2019 [Page 26] Internet-Draft JSEP February 2019 Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system. Calling this method may do things such as generating new ICE credentials, but does not change the PeerConnection state, trigger candidate gathering, or or cause a media state change. Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. 4.1.8. SessionDescriptionType Session description objects (RTCSessionDescription) may be of type "offer", "pranswer", "answer" or "rollback". These types provide information as to how the description parameter should be parsed, and how the media state should be changed. "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations. A description used as an "offer" may be applied anytime the PeerConnection is in a stable state, or as an update to a previously supplied but unanswered "offer". "pranswer" indicates that a description should be parsed as an answer, but not a final answer, and so should not result in the freeing of allocated resources. It may result in the start of media transmission, if the answer does not specify an inactive media direction. A description used as a "pranswer" may be applied as a response to an "offer", or an update to a previously sent "pranswer". "answer" indicates that a description should be parsed as an answer, the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released. A description used as an "answer" may be applied as a response to an "offer", or an update to a previously sent "pranswer". The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that were allocated as a result of the offer. As such, the application can use some discretion on whether an answer should be applied as provisional or final, and can change the type of the session description as needed. For example, in a serial forking scenario, an application may receive multiple "final" answers, one from each remote endpoint. The application could choose to accept the initial answers as provisional answers, and only apply an answer as final when it receives one that meets its criteria (e.g. a live user instead of voicemail). Uberti, et al. Expires August 31, 2019 [Page 27] Internet-Draft JSEP February 2019 "rollback" is a special session description type implying that the state machine should be rolled back to the previous stable state, as described in Section 4.1.8.2. The contents MUST be empty. 4.1.8.1. Use of Provisional Answers Most applications will not need to create answers using the "pranswer" type. While it is good practice to send an immediate response to an offer, in order to warm up the session transport and prevent media clipping, the preferred handling for a JSEP application is to create and send a "sendonly" final answer with a null MediaStreamTrack immediately after receiving the offer, which will prevent media from being sent by the caller, and allow media to be sent immediately upon answer by the callee. Later, when the callee actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow. While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. As an example, consider a typical JSEP application that wants to set up audio and video as quickly as possible. When the callee receives an offer with audio and video MediaStreamTracks, it will send an immediate answer accepting these tracks as sendonly (meaning that the caller will not send the callee any media yet, and because the callee has not yet added its own MediaStreamTracks, the callee will not send any media either). It will then ask the user to accept the call and acquire the needed local tracks. Upon acceptance by the user, the application will plug in the tracks it has acquired, which, because ICE and DTLS handshaking have likely completed by this point, can start transmitting immediately. The application will also send a new offer to the remote side indicating call acceptance and moving the audio and video to be two-way media. A detailed example flow along these lines is shown in Section 7.3. Of course, some applications may not be able to perform this double offer-answer exchange, particularly ones that are attempting to gateway to legacy signaling protocols. In these cases, pranswer can still provide the application with a mechanism to warm up the transport. 4.1.8.2. Rollback In certain situations it may be desirable to "undo" a change made to setLocalDescription or setRemoteDescription. Consider a case where a call is ongoing, and one side wants to change some of the session Uberti, et al. Expires August 31, 2019 [Page 28] Internet-Draft JSEP February 2019 parameters; that side generates an updated offer and then calls setLocalDescription. However, the remote side, either before or after setRemoteDescription, decides it does not want to accept the new parameters, and sends a reject message back to the offerer. Now, the offerer, and possibly the answerer as well, need to return to a stable state and the previous local/remote description. To support this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the stable state. A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. 4.1.9. setLocalDescription The setLocalDescription method instructs the PeerConnection to apply the supplied session description as its local configuration. The type field indicates whether the description should be processed as an offer, provisional answer, final answer, or rollback; offers and answers are checked differently, using the various rules that exist for each SDP line. This API changes the local media state; among other things, it sets up local resources for receiving and decoding media. In order to successfully handle scenarios where the application wants to offer to change from one media format to a different, incompatible format, the PeerConnection must be able to simultaneously support use of both the current and pending local descriptions (e.g., support the codecs that exist in either description). This dual processing begins when the PeerConnection enters the "have-local-offer" state, and continues until setRemoteDescription is called with either a final answer, at which point the PeerConnection can fully adopt the pending local description, or a rollback, which results in a revert to the current local description. This API indirectly controls the candidate gathering process. When a local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and begin gathering candidates for each transport, using ones from the candidate pool if available. If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. Uberti, et al. Expires August 31, 2019 [Page 29] Internet-Draft JSEP February 2019 4.1.10. setRemoteDescription The setRemoteDescription method instructs the PeerConnection to apply the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. This API changes the local media state; among other things, it sets up local resources for sending and encoding media. If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. 4.1.11. currentLocalDescription The currentLocalDescription method returns the current negotiated local description - i.e., the local description from the last successful offer/answer exchange - in addition to any local candidates that have been generated by the ICE agent since the local description was set. A null object will be returned if an offer/answer exchange has not yet been completed. 4.1.12. pendingLocalDescription The pendingLocalDescription method returns a copy of the local description currently in negotiation - i.e., a local offer set without any corresponding remote answer - in addition to any local candidates that have been generated by the ICE agent since the local description was set. A null object will be returned if the state of the PeerConnection is "stable" or "have-remote-offer". 4.1.13. currentRemoteDescription The currentRemoteDescription method returns a copy of the current negotiated remote description - i.e., the remote description from the last successful offer/answer exchange - in addition to any remote candidates that have been supplied via processIceMessage since the remote description was set. A null object will be returned if an offer/answer exchange has not yet been completed. Uberti, et al. Expires August 31, 2019 [Page 30] Internet-Draft JSEP February 2019 4.1.14. pendingRemoteDescription The pendingRemoteDescription method returns a copy of the remote description currently in negotiation - i.e., a remote offer set without any corresponding local answer - in addition to any remote candidates that have been supplied via processIceMessage since the remote description was set. A null object will be returned if the state of the PeerConnection is "stable" or "have-local-offer". 4.1.15. canTrickleIceCandidates The canTrickleIceCandidates property indicates whether the remote side supports receiving trickled candidates. There are three potential values: null: No SDP has been received from the other side, so it is not known if it can handle trickle. This is the initial value before setRemoteDescription() is called. true: SDP has been received from the other side indicating that it can support trickle. false: SDP has been received from the other side indicating that it cannot support trickle. As described in Section 3.5.2, JSEP implementations always provide candidates to the application individually, consistent with what is needed for Trickle ICE. However, applications can use the canTrickleIceCandidates property to determine whether their peer can actually do Trickle ICE, i.e., whether it is safe to send an initial offer or answer followed later by candidates as they are gathered. As "true" is the only value that definitively indicates remote Trickle ICE support, an application which compares canTrickleIceCandidates against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE-compatible agent. 4.1.16. setConfiguration The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to be changed during the session. The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: Uberti, et al. Expires August 31, 2019 [Page 31] Internet-Draft JSEP February 2019 o Any changes to the STUN/TURN servers to use affect the next gathering phase. If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit mentioned in Section 3.5.1 will be set. This will cause the next call to createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used. If the ICE candidate pool has a nonzero size, and a local description has not yet been applied, any existing candidates will be discarded, and new candidates will be gathered from the new servers. o Any change to the ICE candidate policy affects the next gathering phase. If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set. Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not made available to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. o The ICE candidate pool size MUST NOT be changed after applying a local description. If a local description has not yet been applied, any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded. o The bundle and RTCP-multiplexing policies MUST NOT be changed after the construction of the PeerConnection. This call may result in a change to the state of the ICE Agent. 4.1.17. addIceCandidate The addIceCandidate method provides an update to the ICE agent via an IceCandidate object Section 3.5.2.1. If the IceCandidate's candidate field is filled in, the IceCandidate is treated as a new remote ICE candidate, which will be added to the current and/or pending remote description according to the rules defined for Trickle ICE. Otherwise, the IceCandidate is treated as an end-of-candidates indication, as defined in [I-D.ietf-ice-trickle]. In either case, the m= section index, MID, and ufrag fields from the supplied IceCandidate are used to determine which m= section and ICE candidate generation the IceCandidate belongs to, as described in Section 3.5.2.1 above. In the case of an end-of-candidates indication, the absence of both the m= section index and MID fields is interpreted to mean that the indication applies to all m= sections in the specified ICE candidate generation. However, if both fields Uberti, et al. Expires August 31, 2019 [Page 32] Internet-Draft JSEP February 2019 are absent for a new remote candidate, this MUST be treated as an invalid condition, as specified below. If any IceCandidate fields contain invalid values, or an error occurs during the processing of the IceCandidate object, the supplied IceCandidate MUST be ignored and an error MUST be returned. Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent. In the case of a new remote candidate, connectivity checks will be sent to the new candidate. 4.2. RtpTransceiver 4.2.1. stop The stop method stops an RtpTransceiver. This will cause future calls to createOffer to generate a zero port for the associated m= section. See below for more details. 4.2.2. stopped The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section. In either of these cases, it is set to "true", and otherwise will be set to "false". A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP. It cannot be restarted. 4.2.3. setDirection The setDirection method sets the direction of a transceiver, which affects the direction property of the associated m= section on future calls to createOffer and createAnswer. The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", mirroring the identically-named directional attributes defined in [RFC4566], Section 6. When creating offers, the transceiver direction is directly reflected in the output, even for re-offers. When creating answers, the transceiver direction is intersected with the offered direction, as explained in Section 5.3 below. Note that while setDirection sets the direction property of the transceiver immediately ( Section 4.2.4), this property does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive. The direction in effect is represented Uberti, et al. Expires August 31, 2019 [Page 33] Internet-Draft JSEP February 2019 by the currentDirection property, which is only updated when an answer is applied. 4.2.4. direction The direction property indicates the last value passed into setDirection. If setDirection has never been called, it is set to the direction the transceiver was initialized with. 4.2.5. currentDirection The currentDirection property indicates the last negotiated direction for the transceiver's associated m= section. More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection is set to null. 4.2.6. setCodecPreferences The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and createAnswer. Note that setCodecPreferences does not directly affect which codec the implementation decides to send. It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer. Even when a codec is excluded by setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it. The codec preferences of an RtpTransceiver can cause codecs to be excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded. The codec preferences cannot add media formats that would otherwise not be present. The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer, in which case the order of the media formats in the associated m= section will follow the specified preferences. Uberti, et al. Expires August 31, 2019 [Page 34] Internet-Draft JSEP February 2019 5. SDP Interaction Procedures This section describes the specific procedures to be followed when creating and parsing SDP objects. 5.1. Requirements Overview JSEP implementations must comply with the specifications listed below that govern the creation and processing of offers and answers. 5.1.1. Usage Requirements All session descriptions handled by JSEP implementations, both local and remote, MUST indicate support for the following specifications. If any of these are absent, this omission MUST be treated as an error. o ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use a Lite implementation; implementations MUST properly handle remote endpoints which do ICE-Lite. o DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as appropriate for the media type, as specified in [I-D.ietf-rtcweb-security-arch] The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as discussed in [I-D.ietf-rtcweb-security-arch]. 5.1.2. Profile Names and Interoperability For media m= sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764] as well as the "TCP/DTLS/RTP/SAVPF" profile specified in [RFC7850], and MUST indicate one of these profiles for each media m= line they produce in an offer. For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile, and MUST indicate one of these profiles for each data m= line they produce in an offer. The exact profile to use is determined by the protocol associated with the current default or selected ICE candidate, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles. For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". In order to simplify compatibility with such endpoints, JSEP Uberti, et al. Expires August 31, 2019 [Page 35] Internet-Draft JSEP February 2019 implementations MUST follow the following rules when processing the media m= sections in a received offer: o Any profile in the offer matching one of the following MUST be accepted: * "RTP/AVP" (Defined in [RFC4566], Section 8.2.2) * "RTP/AVPF" (Defined in [RFC4585], Section 9) * "RTP/SAVP" (Defined in [RFC3711], Section 12) * "RTP/SAVPF" (Defined in [RFC5124], Section 6) * "TCP/DTLS/RTP/SAVP" (Defined in [RFC7850], Section 3.4) * "TCP/DTLS/RTP/SAVPF" (Defined in [RFC7850], Section 3.5) * "UDP/TLS/RTP/SAVP" (Defined in [RFC5764], Section 9) * "UDP/TLS/RTP/SAVPF" (Defined in [RFC5764], Section 9) o The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer. o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attribute. Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. o The use of AVPF or AVP simply controls the timing rules used for RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr- int=0". Otherwise, assume that AVPF is being used in an AVP compatible mode and use a value of "trr-int=4000". o For data m= sections, implementations MUST support receiving the "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles. Note that re-offers by JSEP implementations MUST use the correct profile strings even if the initial offer/answer exchange used an (incorrect) older profile string. This simplifies JSEP behavior, with minimal downside, as any remote endpoint that fails to handle such a re-offer will also fail to handle a JSEP endpoint's initial offer. Uberti, et al. Expires August 31, 2019 [Page 36] Internet-Draft JSEP February 2019 5.2. Constructing an Offer When createOffer is called, a new SDP description must be created that includes the functionality specified in [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are explained below. 5.2.1. Initial Offers When createOffer is called for the first time, the result is known as the initial offer. The first step in generating an initial offer is to generate session- level attributes, as specified in [RFC4566], Section 5. Specifically: o The first SDP line MUST be "v=0", as specified in [RFC4566], Section 5.1 o The second SDP line MUST be an "o=" line, as specified in [RFC4566], Section 5.2. The value of the field SHOULD be "-". The sess-id MUST be representable by a 64-bit signed integer, and the value MUST be less than (2**63)-1. It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the highest bit set to zero and the remaining 63 bits being cryptographically random. The value of the tuple SHOULD be set to a non- meaningful address, such as IN IP4 0.0.0.0, to prevent leaking a local IP address in this field; this problem is discussed in [I-D.ietf-rtcweb-ip-handling]. As mentioned in [RFC4566], the entire o= line needs to be unique, but selecting a random number for is sufficient to accomplish this. o The third SDP line MUST be a "s=" line, as specified in [RFC4566], Section 5.3; to match the "o=" line, a single dash SHOULD be used as the session name, e.g. "s=-". Note that this differs from the advice in [RFC4566] which proposes a single space, but as both "o=" and "s=" are meaningless in JSEP, having the same meaningless value seems clearer. o Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. o Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included. Uberti, et al. Expires August 31, 2019 [Page 37] Internet-Draft JSEP February 2019 o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; both and SHOULD be set to zero, e.g. "t=0 0". o An "a=ice-options" line with the "trickle" and "ice2" options MUST be added, as specified in [I-D.ietf-ice-trickle], Section 3 and [RFC8445], Section 10. o If WebRTC identity is being used, an "a=identity" line as described in [I-D.ietf-rtcweb-security-arch], Section 5. The next step is to generate m= sections, as specified in [RFC4566], Section 5.14. An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped RtpTransceivers; this is done in the order the RtpTransceivers were added to the PeerConnection. If there are no such RtpTransceivers, no m= sections are generated; more can be added later, as discussed in [RFC3264], Section 5. For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m= section. Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates. Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all have the same [RFC8122] fingerprint value(s), or these value(s) MUST be session-level attributes. Each m= section should be generated as specified in [RFC4566], Section 5.14. For the m= line itself, the following rules MUST be followed: o If the m= section is marked as bundle-only, then the port value MUST be set to 0. Otherwise, the port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. o To properly indicate use of DTLS, the field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. Uberti, et al. Expires August 31, 2019 [Page 38] Internet-Draft JSEP February 2019 o If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. o Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in [RFC7874], Section 3, and [RFC7742], Section 5. The m= line MUST be followed immediately by a "c=" line, as specified in [RFC4566], Section 5.7. Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1. [I-D.ietf-mmusic-sdp-mux-attributes] groups SDP attributes into different categories. To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, repeating the guidance from [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: o An "a=mid" line, as specified in [RFC5888], Section 4. All MID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14. Note that this does not set the RtpTransceiver mid property, as that only occurs when the description is applied. The generated MID value can be considered a "proposed" MID at this point. o A direction attribute which is the same as that of the associated transceiver. o For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6, and [RFC3264], Section 5.1. o For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the payload type of the primary codec, as specified in [RFC4588], Section 8.1. Uberti, et al. Expires August 31, 2019 [Page 39] Internet-Draft JSEP February 2019 o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC mechanisms that MUST be supported are specified in [I-D.ietf-rtcweb-fec], Section 6, and specific usage for each media type is outlined in Sections 4 and 5. o If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in [RFC4566], Section 6. This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. o If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in Section 3.6. o For each supported RTP header extension, an "a=extmap" line, as specified in [RFC5285], Section 5. The list of header extensions that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions that require encryption MUST be specified as indicated in [RFC6904], Section 4. o For each supported RTCP feedback mechanism, an "a=rtcp-fb" line, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. o If the RtpTransceiver has a sendrecv or sendonly direction: * For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2, but omitting the "appdata" field. o If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified. The "a=rid" line is specified in [I-D.ietf-mmusic-rid], and its direction MUST be "send". If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the implementation. RID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per- PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-avtext-rid], Section 3. If no encodings have been Uberti, et al. Expires August 31, 2019 [Page 40] Internet-Draft JSEP February 2019 specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. o If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2. The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. o If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag. (In initial offers, this means those "m=" sections which do not contain an "a=bundle-only" attribute.) o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. o For each desired digest algorithm, one or more "a=fingerprint" lines for each of the endpoint's certificates, as specified in [RFC8122], Section 5. o An "a=setup" line, as specified in [RFC4145], Section 4, and clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. The role value in the offer MUST be "actpass". o An "a=tls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp], Section 5.2. o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.3. o If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- only" line, as specified in [I-D.ietf-mmusic-mux-exclusive], Section 4. o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. Uberti, et al. Expires August 31, 2019 [Page 41] Internet-Draft JSEP February 2019 Lastly, if a data channel has been created, a m= section MUST be generated for data. The field MUST be set to "application" and the field MUST be set to "UDP/DTLS/SCTP" [I-D.ietf-mmusic-sctp-sdp]. The "fmt" value MUST be set to "webrtc- datachannel" as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.1. Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 6.1. As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section either has a unique address or is associated with the bundle-tag (e.g., if it is the only m= section): o "a=ice-ufrag" o "a=ice-pwd" o "a=fingerprint" o "a=setup" o "a=tls-id" Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in [RFC5888]. This attribute MUST have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. The effect of this is that the JSEP implementation offers all m= sections as one bundle group. However, whether the m= sections are bundle-only or not depends on the bundle policy. The next step is to generate session-level lip sync groups as defined in [RFC5888], Section 7. For each MediaStream referenced by more than one RtpTransceiver (by passing those MediaStreams as arguments to the addTrack and addTransceiver methods), a group of type "LS" MUST be added that contains the mid values for each RtpTransceiver. Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical. This assists development and debugging by making it easier to understand individual media sections, especially if one of a set of initially identical attributes is subsequently changed. However, implementations MAY choose to aggregate attributes at the Uberti, et al. Expires August 31, 2019 [Page 42] Internet-Draft JSEP February 2019 session level and JSEP implementations MUST be prepared to receive attributes in either location. Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], and MUST NOT be included: o "a=crypto" o "a=key-mgmt" o "a=ice-lite" Note that when bundle is used, any additional attributes that are added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes] on how those attributes interact with bundle. Note that these requirements are in some cases stricter than those of SDP. Implementations MUST be prepared to accept compliant SDP even if it would not conform to the requirements for generating SDP in this specification. 5.2.2. Subsequent Offers When createOffer is called a second (or later) time, or is called after a local description has already been installed, the processing is somewhat different than for an initial offer. If the previous offer was not applied using setLocalDescription, meaning the PeerConnection is still in the "stable" state, the steps for generating an initial offer should be followed, subject to the following restriction: o The fields of the "o=" line MUST stay the same except for the field, which MUST increment by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment on every call. The value of the generated is independent of the of the current local description; in particular, in the case where the current version is N, an offer is created and applied with version N+1, and then that offer is rolled back so that the current version is again N, the next generated offer will still have version N+2. Note that if the application creates an offer by reading currentLocalDescription instead of calling createOffer, the returned Uberti, et al. Expires August 31, 2019 [Page 43] Internet-Draft JSEP February 2019 SDP may be different than when setLocalDescription was originally called, due to the addition of gathered ICE candidates, but the will not have changed. There are no known scenarios in which this causes problems, but if this is a concern, the solution is simply to use createOffer to ensure a unique . If the previous offer was applied using setLocalDescription, but a corresponding answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "have-local-offer" state, an offer is generated by following the steps in the "stable" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o If any RtpTransceiver has been added, and there exists an m= section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating an m= section for the added RtpTransceiver as if the m= section were being added to the session description (including a new MID value), and placing it at the same index as the m= section with a zero port. o If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it. This prevents adding back RtpTransceivers whose m= sections were recycled and used for a new RtpTransceiver in a previous offer/ answer exchange, as described above. o If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to zero and all "a=msid" lines removed. o For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same if they are present in the current description, regardless of changes to the transceiver's direction or track. If no "a=msid" line is present in the current description, "a=msid" line(s) MUST be generated according to the same rules as for an initial offer. o Each "m=" and c=" line MUST be filled in with the port, relevant RTP profile, and address of the default candidate for the m= section, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2, and clarified in Section 5.1.2. If no RTP candidates have yet been gathered, dummy values MUST still be used, as described above. Uberti, et al. Expires August 31, 2019 [Page 44] Internet-Draft JSEP February 2019 o Each "a=mid" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option ( Section 5.2.3.1 was specified. If the m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. o If the m= section is not bundled into another m= section, its "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate, as indicated in [RFC5761], Section 5.1.3. If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial offer section above. o If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. If candidate gathering for the section has completed, an "a=end-of- candidates" attribute MUST be added, as described in [I-D.ietf-ice-trickle], Section 9.3. If the m= section is bundled into another m= section, both "a=candidate" and "a=end-of- candidates" MUST be omitted. o For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. o For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same. If the previous offer was applied using setLocalDescription, and a corresponding answer from the remote side has been applied using setRemoteDescription, meaning the PeerConnection is in the "have- remote-pranswer" or "stable" states, an offer is generated based on the negotiated session descriptions by following the steps mentioned for the "have-local-offer" state above. In addition, for each existing, non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current local or remote description, as appropriate: o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include media formats which have not been excluded by the codec preferences of the associated transceiver, and MUST include all currently available formats. Media formats that were Uberti, et al. Expires August 31, 2019 [Page 45] Internet-Draft JSEP February 2019 previously offered but are no longer available (e.g., a shared hardware codec) MAY be excluded. o Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in the same order as in the most recent answer. Any media formats that were not present in the most recent answer MUST be added after all existing formats. o The RTP header extensions MUST only include those that are present in the most recent answer. o The RTCP feedback mechanisms MUST only include those that are present in the most recent answer, except for the case of format- specific mechanisms that are referencing a newly-added media format. o The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line. o The "a=rtcp-mux" line MUST be the same as that in the most recent answer. o The "a=rtcp-mux-only" line MUST NOT be added. o The "a=rtcp-rsize" line MUST NOT be added unless present in the most recent answer. o An "a=bundle-only" line MUST NOT be added, as indicated in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 6. Instead, JSEP implementations MUST simply omit parameters in the IDENTICAL and TRANSPORT categories for bundled m= sections, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. o Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux"). This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute. Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or Uberti, et al. Expires August 31, 2019 [Page 46] Internet-Draft JSEP February 2019 re-enabled m= sections. In other words, the bundle attribute must contain all m= sections that were previously bundled, as long as they are still alive, as well as any new m= sections. "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and MUST contain any previously existing MID identifiers, as long as the identified m= sections still exist and are not rejected, and the group still contains at least two MID identifiers. This ensures that any synchronized "recvonly" m= sections continue to be synchronized in the new offer. 5.2.3. Options Handling The createOffer method takes as a parameter an RTCOfferOptions object. Special processing is performed when generating a SDP description if the following options are present. 5.2.3.1. IceRestart If the "IceRestart" option is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.1.1.1. If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated). Similarly, if the ICE configuration has changed, this option has no effect, since new ufrag and pwd attributes will be generated automatically. This option is primarily useful for reestablishing connectivity in cases where failures are detected by the application. 5.2.3.2. VoiceActivityDetection Silence suppression, also known as discontinuous transmission ("DTX"), can reduce the bandwidth used for audio by switching to a special encoding when voice activity is not detected, at the cost of some fidelity. If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for each offered audio codec, as specified in [RFC3389], Section 5.1, except for codecs that have their own internal silence suppression support. For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is desired. For example, when using the Opus codec [RFC6716], the Uberti, et al. Expires August 31, 2019 [Page 47] Internet-Draft JSEP February 2019 "usedtx=1" parameter, specified in [RFC7587], would be used in the offer. If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs. For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired. For example, when using the Opus codec, the "usedtx=0" parameter would be specified in the offer. In addition, the implementation MUST NOT use silence suppression for media it generates, regardless of whether the "CN" codecs or related fmtp parameters appear in the peer's description. The impact of these rules is that silence suppression in JSEP depends on mutual agreement of both sides, which ensures consistent handling regardless of which codec is used. The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer audio level header extension described in [RFC6464], Section 4. 5.3. Generating an Answer When createAnswer is called, a new SDP description must be created that is compatible with the supplied remote description as well as the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are explained below. 5.3.1. Initial Answers When createAnswer is called for the first time after a remote description has been provided, the result is known as the initial answer. If no remote description has been installed, an answer cannot be generated, and an error MUST be returned. Note that the remote description SDP may not have been created by a JSEP endpoint and may not conform to all the requirements listed in Section 5.2. For many cases, this is not a problem. However, if any mandatory SDP attributes are missing, or functionality listed as mandatory-to-use above is not present, this MUST be treated as an error, and MUST cause the affected m= sections to be marked as rejected. The first step in generating an initial answer is to generate session-level attributes. The process here is identical to that indicated in the initial offers section above, except that the "a=ice-options" line, with the "trickle" option as specified in [I-D.ietf-ice-trickle], Section 3, and the "ice2" option as specified Uberti, et al. Expires August 31, 2019 [Page 48] Internet-Draft JSEP February 2019 in [RFC8445], Section 10, is only included if such an option was present in the offer. The next step is to generate session-level lip sync groups, as defined in [RFC5888], Section 7. For each group of type "LS" present in the offer, select the local RtpTransceivers that are referenced by the MID values in the specified group, and determine which of them either reference a common local MediaStream (specified in the calls to addTrack/addTransceiver used to create them), or have no MediaStream to reference because they were not created by addTrack/ addTransceiver. If at least two such RtpTransceivers exist, a group of type "LS" with the mid values of these RtpTransceivers MUST be added. Otherwise the offered "LS" group MUST be ignored and no corresponding group generated in the answer. As a simple example, consider the following offer of a single audio and single video track contained in the same MediaStream. SDP lines not relevant to this example have been removed for clarity. As explained in Section 5.2, a group of type "LS" has been added that references each track's RtpTransceiver. a=group:LS a1 v1 m=audio 10000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=msid:ms1 m=video 10001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=msid:ms1 If the answerer uses a single MediaStream when it adds its tracks, both of its transceivers will reference this stream, and so the subsequent answer will contain a "LS" group identical to that in the offer, as shown below: a=group:LS a1 v1 m=audio 20000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=msid:ms2 m=video 20001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=msid:ms2 Uberti, et al. Expires August 31, 2019 [Page 49] Internet-Draft JSEP February 2019 However, if the answerer groups its tracks into separate MediaStreams, its transceivers will reference different streams, and so the subsequent answer will not contain a "LS" group. m=audio 20000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=msid:ms2a m=video 20001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=msid:ms2b Finally, if the answerer does not add any tracks, its transceivers will not reference any MediaStreams, causing the preferences of the offerer to be maintained, and so the subsequent answer will contain an identical "LS" group. a=group:LS a1 v1 m=audio 20000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=recvonly m=video 20001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=recvonly The Section 7.2 example later in this document shows a more involved case of "LS" group generation. The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in [RFC3264], Section 6. For the purposes of this discussion, any session-level attributes in the offer that are also valid as media-level attributes are considered to be present in each m= section. Each offered m= section will have an associated RtpTransceiver, as described in Section 5.10. If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in [RFC3264], Section 6, and further processing for this m= section can be skipped: o The associated RtpTransceiver has been stopped. Uberti, et al. Expires August 31, 2019 [Page 50] Internet-Draft JSEP February 2019 o None of the offered media formats are supported and, if applicable, allowed by codec preferences. o The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section. o The bundle policy is "balanced", and this is not the first m= section for this media type or in the same bundle group as the first m= section for this media type. o This m= section is in a bundle group, and the group's offerer tagged m= section is being rejected due to one of the above reasons. This requires all m= sections in the bundle group to be rejected, as specified in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 7.3.3. Otherwise, each m= section in the answer should then be generated as specified in [RFC3264], Section 6.1. For the m= line itself, the following rules must be followed: o The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. o The field MUST be set to exactly match the field for the corresponding m= line in the offer. o If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, regardless of what was offered, and MUST exclude any codecs not present in the codec preferences. o Otherwise, the media formats on the m= line MUST be generated in the same order as those offered in the current remote description, excluding any currently unsupported formats. Any currently available media formats that are not present in the current remote description MUST be added after all existing formats. o In either case, the media formats in the answer MUST include at least one format that is present in the offer, but MAY include formats that are locally supported but not present in the offer, as mentioned in [RFC3264], Section 6.1. If no common format exists, the m= section is rejected as described above. The m= line MUST be followed immediately by a "c=" line, as specified in [RFC4566], Section 5.7. Again, as no candidates are available Uberti, et al. Expires August 31, 2019 [Page 51] Internet-Draft JSEP February 2019 yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1. If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being bundled must use unique ICE credentials and candidates. Each m= section MUST contain the following attributes (which are of attribute types other than IDENTICAL and TRANSPORT): o If and only if present in the offer, an "a=mid" line, as specified in [RFC5888], Section 9.1. The "mid" value MUST match that specified in the offer. o A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. o For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6, and [RFC3264], Section 6.1. o If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the payload type of the primary codec, as specified in [RFC4588], Section 8.1. o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC mechanisms that MUST be supported are specified in [I-D.ietf-rtcweb-fec], Section 6, and specific usage for each media type is outlined in Sections 4 and 5. o If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in Section 5.2. o If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in Section 3.6. o For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in [RFC5285], Section 5. The list of header extensions that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header Uberti, et al. Expires August 31, 2019 [Page 52] Internet-Draft JSEP February 2019 extensions that require encryption MUST be specified as indicated in [RFC6904], Section 4. o For each supported RTCP feedback mechanism that is present in the offer, an "a=rtcp-fb" line, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. o If the RtpTransceiver has a sendrecv or sendonly direction: * For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2, but omitting the "appdata" field. Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. o For each desired digest algorithm, one or more "a=fingerprint" lines for each of the endpoint's certificates, as specified in [RFC8122], Section 5. o An "a=setup" line, as specified in [RFC4145], Section 4, and clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. The role value in the answer MUST be "active" or "passive". When the offer contains the "actpass" value, as will always be the case with JSEP endpoints, the answerer SHOULD use the "active" role. Offers from non-JSEP endpoints MAY send other values for "a=setup", in which case the answer MUST use a value consistent with the value in the offer. o An "a=tls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp], Section 5.3. o If present in the offer, an "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.3. Otherwise, an "a=rtcp" line, as specified in [RFC3605], Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0" (because no candidates have yet been gathered). o If present in the offer, an "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. Uberti, et al. Expires August 31, 2019 [Page 53] Internet-Draft JSEP February 2019 If a data channel m= section has been offered, a m= section MUST also be generated for data. The field MUST be set to "application" and the and fields MUST be set to exactly match the fields in the offer. Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 6.1. As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section is not bundled into another m= section: o "a=ice-ufrag" o "a=ice-pwd" o "a=fingerprint" o "a=setup" o "a=tls-id" Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may also appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux"). If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as specified in [RFC5888]. These attributes MUST have semantics "BUNDLE", and MUST include the all mid identifiers from the offered bundle groups that have not been rejected. Note that regardless of the presence of "a=bundle-only" in the offer, no m= sections in the answer should have an "a=bundle-only" line. Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. The attributes prohibited in the creation of offers are also prohibited in the creation of answers. Uberti, et al. Expires August 31, 2019 [Page 54] Internet-Draft JSEP February 2019 5.3.2. Subsequent Answers When createAnswer is called a second (or later) time, or is called after a local description has already been installed, the processing is somewhat different than for an initial answer. If the previous answer was not applied using setLocalDescription, meaning the PeerConnection is still in the "have-remote-offer" state, the steps for generating an initial answer should be followed, subject to the following restriction: o The fields of the "o=" line MUST stay the same except for the field, which MUST increment if the session description changes in any way from the previously generated answer. If any session description was previously supplied to setLocalDescription, an answer is generated by following the steps in the "have-remote-offer" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. Note that in certain cases, the m= line protocol may not match that of the default candidate, because the m= line protocol value MUST match what was supplied in the offer, as described above. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.1.1.1. If the m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. o Each "a=tls-id" line MUST stay the same unless the offerer's "a=tls-id" line changed, in which case a new "a=tls-id" value MUST be created, as described in [I-D.ietf-mmusic-dtls-sdp], Section 5.2. o Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer. o RTCP multiplexing must be used, and an "a=rtcp-mux" line inserted if and only if the m= section previously used RTCP multiplexing. Uberti, et al. Expires August 31, 2019 [Page 55] Internet-Draft JSEP February 2019 o If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial answer section above. o If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. If candidate gathering for the section has completed, an "a=end-of- candidates" attribute MUST be added, as described in [I-D.ietf-ice-trickle], Section 9.3. If the m= section is bundled into another m= section, both "a=candidate" and "a=end-of- candidates" MUST be omitted. o For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same, regardless of changes to the transceiver's direction or track. If no "a=msid" line is present in the current description, "a=msid" line(s) MUST be generated according to the same rules as for an initial answer. 5.3.3. Options Handling The createAnswer method takes as a parameter an RTCAnswerOptions object. The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all m= sections where the offerer chose to perform ICE restart. The following options are supported in RTCAnswerOptions. 5.3.3.1. VoiceActivityDetection Silence suppression in the answer is handled as described in Section 5.2.3.2, with one exception: if support for silence suppression was not indicated in the offer, the VoiceActivityDetection parameter has no effect, and the answer should be generated as if VoiceActivityDetection was set to false. This is done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). The impact of this rule is that an answerer will not try to use silence suppression with any endpoint that does not offer it, making silence suppression support bilateral even with non-JSEP endpoints. Uberti, et al. Expires August 31, 2019 [Page 56] Internet-Draft JSEP February 2019 5.4. Modifying an Offer or Answer The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription. If precise control over the SDP is needed, the aforementioned createOffer/createAnswer options or RtpTransceiver APIs MUST be used. After calling setLocalDescription with an offer or answer, the application MAY modify the SDP to reduce its capabilities before sending it to the far side, as long as it follows the rules above that define a valid JSEP offer or answer. Likewise, an application that has received an offer or answer from a peer MAY modify the received SDP, subject to the same constraints, before calling setRemoteDescription. As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the JSEP implementation to the extent of its capabilities. It is an error to assume that all SDP is well-formed; however, one should be able to assume that any implementation of this specification will be able to process, as a remote offer or answer, unmodified SDP coming from any other implementation of this specification. 5.5. Processing a Local Description When a SessionDescription is supplied to setLocalDescription, the following steps MUST be performed: o If the description is of type "rollback", follow the processing defined in Section 5.7 and skip the processing described in the rest of this section. o Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: * If the type is "offer", the PeerConnection state MUST be either "stable" or "have-local-offer". * If the type is "pranswer" or "answer", the PeerConnection state MUST be either "have-remote-offer" or "have-local-pranswer". o If the type is not correct for the current state, processing MUST stop and an error MUST be returned. o The SessionDescription is then checked to ensure that its contents are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in Uberti, et al. Expires August 31, 2019 [Page 57] Internet-Draft JSEP February 2019 Section 5.4; otherwise, processing MUST stop and an error MUST be returned. o Next, the SessionDescription is parsed into a data structure, as described in Section 5.8 below. o Finally, the parsed SessionDescription is applied as described in Section 5.9 below. 5.6. Processing a Remote Description When a SessionDescription is supplied to setRemoteDescription, the following steps MUST be performed: o If the description is of type "rollback", follow the processing defined in Section 5.7 and skip the processing described in the rest of this section. o Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: * If the type is "offer", the PeerConnection state MUST be either "stable" or "have-remote-offer". * If the type is "pranswer" or "answer", the PeerConnection state MUST be either "have-local-offer" or "have-remote-pranswer". o If the type is not correct for the current state, processing MUST stop and an error MUST be returned. o Next, the SessionDescription is parsed into a data structure, as described in Section 5.8 below. If parsing fails for any reason, processing MUST stop and an error MUST be returned. o Finally, the parsed SessionDescription is applied as described in Section 5.10 below. 5.7. Processing a Rollback A rollback may be performed if the PeerConnection is in any state except for "stable". This means that both offers and provisional answers can be rolled back. Rollback can only be used to cancel proposed changes; there is no support for rolling back from a stable state to a previous stable state. If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned. Note that this implies that once the answerer has performed setLocalDescription with his answer, this cannot be rolled back. Uberti, et al. Expires August 31, 2019 [Page 58] Internet-Draft JSEP February 2019 The effect of rollback MUST be the same regardless of whether setLocalDescription or setRemoteDescription is called. In order to process rollback, a JSEP implementation abandons the current offer/answer transaction, sets the signaling state to "stable", and sets the pending local and/or remote description (see Section 4.1.12 and Section 4.1.14) to null. Any resources or candidates that were allocated by the abandoned local description are discarded; any media that is received is processed according to the previous local and remote descriptions. A rollback disassociates any RtpTransceivers that were associated with m= sections by the application of the rolled-back session description (see Section 5.10 and Section 5.9). This means that some RtpTransceivers that were previously associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to null, and the mapping between the transceiver and its m= section index MUST be discarded. RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be stopped and removed from the PeerConnection. However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method. This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. 5.8. Parsing a Session Description The SDP contained in the session description object consists of a sequence of text lines, each containing a key-value expression, as described in [RFC4566], Section 5. The SDP is read, line-by-line, and converted to a data structure that contains the deserialized information. However, SDP allows many types of lines, not all of which are relevant to JSEP applications. For each line, the implementation will first ensure it is syntactically correct according to its defining ABNF, check that it conforms to [RFC4566] and [RFC3264] semantics, and then either parse and store or discard the provided value, as described below. If any line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description, even if the value is to be discarded. This ensures that implementations do not accidentally misinterpret ambiguous SDP. Uberti, et al. Expires August 31, 2019 [Page 59] Internet-Draft JSEP February 2019 5.8.1. Session-Level Parsing First, the session-level lines are checked and parsed. These lines MUST occur in a specific order, and with a specific syntax, as defined in [RFC4566], Section 5. Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the same type (typically "a=") can occur in any order. The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked. The "c=" line MUST be checked for syntax but its value is only used for ICE mismatch detection, as defined in [RFC8445], Section 5.4. Note that JSEP implementations should never encounter this condition because ICE is required for WebRTC. The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are not used by this specification; they MUST be checked for syntax but their values are not used. The remaining non-attribute lines are processed as follows: The "v=" line MUST have a version of 0, as specified in [RFC4566], Section 5.1. The "o=" line MUST be parsed as specified in [RFC4566], Section 5.2. The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored. Finally, the attribute lines are processed. Specific processing MUST be applied for the following session-level attribute ("a=") lines: o Any "a=group" lines are parsed as specified in [RFC5888], Section 5, and the group's semantics and mids are stored. o If present, a single "a=ice-lite" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.3, and a value indicating the presence of ice-lite is stored. o If present, a single "a=ice-ufrag" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the ufrag value is stored. Uberti, et al. Expires August 31, 2019 [Page 60] Internet-Draft JSEP February 2019 o If present, a single "a=ice-pwd" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the password value is stored. o If present, a single "a=ice-options" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.6, and the set of specified options is stored. o Any "a=fingerprint" lines are parsed as specified in [RFC8122], Section 5, and the set of fingerprint and algorithm values is stored. o If present, a single "a=setup" line is parsed as specified in [RFC4145], Section 4, and the setup value is stored. o If present, a single "a=tls-id" line is parsed as specified in [I-D.ietf-mmusic-dtls-sdp] Section 5, and the tls-id value is stored. o Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified [I-D.ietf-rtcweb-security-arch], Section 5. o Any "a=extmap" lines are parsed as specified in [RFC5285], Section 5, and their values are stored. Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize. As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. Once all the session-level lines have been parsed, processing continues with the lines in m= sections. 5.8.2. Media Section Parsing Like the session-level lines, the media section lines MUST occur in the specific order and with the specific syntax defined in [RFC4566], Section 5. The "m=" line itself MUST be parsed as described in [RFC4566], Section 5.14, and the media, port, proto, and fmt values stored. Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: Uberti, et al. Expires August 31, 2019 [Page 61] Internet-Draft JSEP February 2019 o As with the "c=" line at the session level, the "c=" line MUST be parsed according to [RFC4566], Section 5.7, but its value is not used. o The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored. Specific processing MUST also be applied for the following attribute lines: o If present, a single "a=ice-ufrag" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the ufrag value is stored. o If present, a single "a=ice-pwd" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the password value is stored. o If present, a single "a=ice-options" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.6, and the set of specified options is stored. o Any "a=candidate" attributes MUST be parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1, and their values stored. o Any "a=remote-candidates" attributes MUST be parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.2, but their values are ignored. o If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and its presence or absence flagged and stored. o Any "a=fingerprint" lines are parsed as specified in [RFC8122], Section 5, and the set of fingerprint and algorithm values is stored. If the "m=" proto value indicates use of RTP, as described in Section 5.1.2 above, the following attribute lines MUST be processed: o The "m=" fmt value MUST be parsed as specified in [RFC4566], Section 5.14, and the individual values stored. o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in [RFC4566], Section 6, and their values stored. Uberti, et al. Expires August 31, 2019 [Page 62] Internet-Draft JSEP February 2019 o If present, a single "a=ptime" line MUST be parsed as described in [RFC4566], Section 6, and its value stored. o If present, a single "a=maxptime" line MUST be parsed as described in [RFC4566], Section 6, and its value stored. o If present, a single direction attribute line (e.g. "a=sendrecv") MUST be parsed as described in [RFC4566], Section 6, and its value stored. o Any "a=ssrc" attributes MUST be parsed as specified in [RFC5576], Section 4.1, and their values stored. o Any "a=extmap" attributes MUST be parsed as specified in [RFC5285], Section 5, and their values stored. o Any "a=rtcp-fb" attributes MUST be parsed as specified in [RFC4585], Section 4.2., and their values stored. o If present, a single "a=rtcp-mux" attribute MUST be parsed as specified in [RFC5761], Section 5.1.3, and its presence or absence flagged and stored. o If present, a single "a=rtcp-mux-only" attribute MUST be parsed as specified in [I-D.ietf-mmusic-mux-exclusive], Section 3, and its presence or absence flagged and stored. o If present, a single "a=rtcp-rsize" attribute MUST be parsed as specified in [RFC5506], Section 5, and its presence or absence flagged and stored. o If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored, as this information is superfluous when using ICE. o If present, "a=msid" attributes MUST be parsed as specified in [I-D.ietf-mmusic-msid], Section 3.2, and their values stored, ignoring any "appdata" field. If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. o Any "a=imageattr" attributes MUST be parsed as specified in [RFC6236], Section 3, and their values stored. o Any "a=rid" lines MUST be parsed as specified in [I-D.ietf-mmusic-rid], Section 10, and their values stored. Uberti, et al. Expires August 31, 2019 [Page 63] Internet-Draft JSEP February 2019 o If present, a single "a=simulcast" line MUST be parsed as specified in [I-D.ietf-mmusic-sdp-simulcast], and its values stored. Otherwise, if the "m=" proto value indicates use of SCTP, the following attribute lines MUST be processed: o The "m=" fmt value MUST be parsed as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.3, and the application protocol value stored. o An "a=sctp-port" attribute MUST be present, and it MUST be parsed as specified in [I-D.ietf-mmusic-sctp-sdp], Section 5.2, and the value stored. o If present, a single "a=max-message-size" attribute MUST be parsed as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the value stored. Otherwise, use the specified default. Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize. As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. 5.8.3. Semantics Verification Assuming parsing completes successfully, the parsed description is then evaluated to ensure internal consistency as well as proper support for mandatory features. Specifically, the following checks are performed: o For each m= section, valid values for each of the mandatory-to-use features enumerated in Section 5.1.1 MUST be present. These values MAY either be present at the media level, or inherited from the session level. * ICE ufrag and password values, which MUST comply with the size limits specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer or a response to a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. * DTLS setup value, which MUST be set according to the rules specified in [RFC5763], Section 5 and MUST be consistent with Uberti, et al. Expires August 31, 2019 [Page 64] Internet-Draft JSEP February 2019 the selected role of the current DTLS connection, if one exists and is being continued. * DTLS fingerprint values, where at least one fingerprint MUST be present. o All RID values referenced in an "a=simulcast" line MUST exist as "a=rid" lines. o Each m= section is also checked to ensure prohibited features are not used. o If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute. If an m= section contains an "a=rtcp-mux-only" attribute, that section MUST also contain an "a=rtcp-mux" attribute. o If an m= section was present in the previous answer, the state of RTP/RTCP multiplexing MUST match what was previously negotiated. If this session description is of type "pranswer" or "answer", the following additional checks are applied: o The session description must follow the rules defined in [RFC3264], Section 6, including the requirement that the number of m= sections MUST exactly match the number of m= sections in the associated offer. o For each m= section, the media type and protocol values MUST exactly match the media type and protocol values in the corresponding m= section in the associated offer. If any of the preceding checks failed, processing MUST stop and an error MUST be returned. 5.9. Applying a Local Description The following steps are performed at the media engine level to apply a local description. If an error is returned, the session MUST be restored to the state it was in before performing these steps. First, m= sections are processed. For each m= section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. o If this m= section is new, begin gathering candidates for it, as defined in [RFC8445], Section 5.1.1, unless it is definitively Uberti, et al. Expires August 31, 2019 [Page 65] Internet-Draft JSEP February 2019 being bundled (either this is an offer and the m= section is marked bundle-only, or it is an answer and the m= section is bundled into into another m= section.) o Or, if the ICE ufrag and password values have changed, trigger the ICE agent to start an ICE restart as described in [RFC8445], Section 9, and begin gathering new candidates for the m= section. If this description is an answer, also start checks on that media section. o If the m= section proto value indicates use of RTP: * If there is no RtpTransceiver associated with this m= section, find one and associate it with this m= section according to the following steps. Note that this situation will only occur when applying an offer. + Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section indices established when creating the offer. + Set the value of this RtpTransceiver's mid property to the MID of the m= section. * If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.3. * For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in [RFC5285], Section 6. * If the MID header extension is supported, prepare to demux RTP streams intended for this m= section based on the MID header extension, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 15. * For each specified media format, establish a mapping between the payload type and the actual media format, as described in [RFC3264], Section 6.1. In addition, prepare to demux RTP streams intended for this m= section based on the media formats supported by this m= section, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. * For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in [RFC4588], Sections 8.6 and 8.7. Uberti, et al. Expires August 31, 2019 [Page 66] Internet-Draft JSEP February 2019 * If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in Section 5.11 below. 5.10. Applying a Remote Description The following steps are performed to apply a remote description. If an error is returned, the session MUST be restored to the state it was in before performing these steps. If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true. Otherwise, set this property to false. The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. o For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in [RFC4566], Section 5.8. Within this overall limit, the implementation can dynamically decide how to best allocate the available bandwidth between m= sections, respecting any specific limits that have been specified for individual m= sections. o For any specified "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2. o Any "AS" bandwidth value MUST be ignored, as the meaning of this construct at the session level is not well defined. For each m= section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. o If the ICE ufrag or password changed from the previous remote description: * If the description is of type "offer", the implementation MUST note that an ICE restart is needed, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.1.1.1 * If the description is of type "answer" or "pranswer", then check to see if the current local description is an ICE restart, and if not, generate an error. If the PeerConnection state is "have-remote-pranswer", and the ICE ufrag or password Uberti, et al. Expires August 31, 2019 [Page 67] Internet-Draft JSEP February 2019 changed from the previous provisional answer, then signal the ICE agent to discard any previous ICE check list state for the m= section. Finally, signal the ICE agent to begin checks. o If the current local description indicates an ICE restart, and either the ICE ufrag or password has not changed from the previous remote description, as prescribed by [RFC8445], Section 9, generate an error. o Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their connectivity checks. o Pair any supplied ICE candidates with any gathered local candidates, as described in [RFC8445], Section 6.1.2, and start connectivity checks with the appropriate credentials. o If an "a=end-of-candidates" attribute is present, process the end- of-candidates indication as described in [I-D.ietf-ice-trickle], Section 11. o If the m= section proto value indicates use of RTP: * If the m= section is being recycled (see Section 5.2.2), dissociate the currently associated RtpTransceiver by setting its mid property to null, and discard the mapping between the transceiver and its m= section index. * If the m= section is not associated with any RtpTransceiver (possibly because it was dissociated in the previous step), either find an RtpTransceiver or create one according to the following steps: + If the m= section is sendrecv or recvonly, and there are RtpTransceivers of the same type that were added to the PeerConnection by addTrack and are not associated with any m= section and are not stopped, find the first (according to the canonical order described in Section 5.2.1) such RtpTransceiver. + If no RtpTransceiver was found in the previous step, create one with a recvonly direction. + Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid property to the MID of the m= section, and establish a mapping between the transceiver and the index of the m= section. If the m= section does not include a MID (i.e., Uberti, et al. Expires August 31, 2019 [Page 68] Internet-Draft JSEP February 2019 the remote endpoint does not support the MID extension), generate a value for the RtpTransceiver mid property, following the guidance for "a=mid" mentioned in Section 5.2.1. * For each specified media format that is also supported by the local implementation, establish a mapping between the specified payload type and the media format, as described in [RFC3264], Section 6.1. Specifically, this means that the implementation records the payload type to be used in outgoing RTP packets when sending each specified media format, as well as the relative preference for each format that is indicated in their ordering. If any indicated media format is not supported by the local implementation, it MUST be ignored. * For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in [RFC4588], Section 4. If any referenced primary payload types are not present, this MUST result in an error. Note that RTX payload types may refer to primary payload types which are not supported by the local media implementation, in which case, the RTX payload type MUST also be ignored. * For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media formats. * For each specified SSRC that is signaled in the m= section, prepare to demux RTP streams intended for this m= section using that SSRC, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. * For each specified RTP header extension that is also supported by the local implementation, establish a mapping between the extension ID and URI, as described in [RFC5285], Section 5. Specifically, this means that the implementation records the extension ID to be used in outgoing RTP packets when sending each specified header extension. If any indicated RTP header extension is not supported by the local implementation, it MUST be ignored. * For each specified RTCP feedback mechanism that is supported by the local implementation, enable them on the associated media formats. * For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending Uberti, et al. Expires August 31, 2019 [Page 69] Internet-Draft JSEP February 2019 media, as specified in [RFC3890]. If a "TIAS" value is not present, but an "AS" value is specified, generate a "TIAS" value using this formula: TIAS = AS * 1000 * 0.95 - (50 * 40 * 8) The 50 is based on 50 packets per second, the 40 is based on an estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS), and the 0.95 is to allocate 5% to RTCP. "TIAS" is used in preference to "AS" because it provides more accurate control of bandwidth. * For any "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2. * Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. * If the m= section is of type audio: + For each specified "CN" media format, configure silence suppression for all supported media formats with the same clockrate, as described in [RFC3389], Section 5, except for formats that have their own internal silence suppression mechanisms. Silence suppression for such formats (e.g., Opus) is controlled via fmtp parameters, as discussed in Section 5.2.3.2. + For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in [RFC4733], Section 2.5.1.2. If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats. + For any specified "ptime" value, configure the available media formats to use the specified packet size when sending. If the specified size is not supported for a media format, use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in Section 5.11 below. Uberti, et al. Expires August 31, 2019 [Page 70] Internet-Draft JSEP February 2019 5.11. Applying an Answer In addition to the steps mentioned above for processing a local or remote description, the following steps are performed when processing a description of type "pranswer" or "answer". For each m= section, the following steps MUST be performed: o If the m= section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for this section, and, unless a non-rejected m= section is bundled with this m= section, discard any associated ICE components, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.3.1. o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. Note that although JSEP requires that answerers change the tls-id value if and only if the offerer does, non-JSEP answerers are permitted to change the tls-id as long as the offer contained an ICE restart. Thus, JSEP implementations which process DTLS data prior to receiving an answer MUST be prepared to receive either a ClientHello or data from the previous DTLS connection. o If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any underlying ICE components, once they are active. o If the m= section proto value indicates use of RTP: * If the m= section references RTCP feedback mechanisms that were not present in the corresponding m= section in the offer, this indicates a negotiation problem and MUST result in an error. However, new media formats and new RTP header extension values are permitted in the answer, as described in [RFC3264], Section 7, and [RFC5285], Section 6. * If the m= section has RTCP mux enabled, discard the RTCP ICE component, if one exists, and begin or continue muxing RTCP over the RTP ICE component, as specified in [RFC5761], Section 5.1.3. Otherwise, prepare to transmit RTCP over the Uberti, et al. Expires August 31, 2019 [Page 71] Internet-Draft JSEP February 2019 RTCP ICE component; if no RTCP ICE component exists, because RTCP mux was previously enabled, this MUST result in an error. * If the m= section has reduced-size RTCP enabled, configure the RTCP transmission for this m= section to use reduced-size RTCP, as specified in [RFC5506]. * If the directional attribute in the answer indicates that the JSEP implementation should be sending media ("sendonly" for local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is also locally supported, as discussed in [RFC3264], Sections 6.1 and 7, and start transmitting RTP media using that format once the underlying transport layers have been established. If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one. If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as specified in [RFC7160], Section 3.1. * The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including the payload type for the send media format chosen above. Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated, and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in [I-D.ietf-mmusic-rid], Section 4. * If the m= section is of type audio, and silence suppression was configured for the send media format as a result of processing the remote description, and is also enabled for that format in the local description, use silence suppression for outgoing media, in accordance with the guidance in Section 5.2.3.2. If these conditions are not met, silence suppression MUST NOT be used for outgoing media. * If simulcast has been negotiated, send the number of Source RTP Streams as specified in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2.2. * If the send media format chosen above has a corresponding "rtx" media format, or a FEC mechanism has been negotiated, establish a Redundancy RTP Stream with a random SSRC for each Source RTP Stream, and start or continue transmitting RTX/FEC packets as needed. Uberti, et al. Expires August 31, 2019 [Page 72] Internet-Draft JSEP February 2019 * If the send media format chosen above has a corresponding "red" media format of the same clockrate, allow redundant encoding using the specified format for resiliency purposes, as discussed in [I-D.ietf-rtcweb-fec], Section 3.2. Note that unlike RTX or FEC media formats, the "red" format is transmitted on the Source RTP Stream, not the Redundancy RTP Stream. * Enable the RTCP feedback mechanisms referenced in the media section for all Source RTP Streams using the specified media formats. Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified in [RFC4585], Section 4.2. When sending RTCP feedback, follow the rules and recommendations from [RFC8108] Section 5.4.1, to select which SSRC to use. * If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for local answers, "sendonly" for remote answers, or "inactive" for either type of answer) stop transmitting all RTP media, but continue sending RTCP, as described in [RFC3264], Section 5.1. o If the m= section proto value indicates use of SCTP: * If an SCTP association exists, and the remote SCTP port has changed, discard the existing SCTP association. This includes the case when the PeerConnection state is "have-remote- pranswer". * If no valid SCTP association exists, prepare to initiate a SCTP association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description, and the remote SCTP port value from the remote description, as described in [I-D.ietf-mmusic-sctp-sdp], Section 10.2. If the answer contains valid bundle groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these m= sections accordingly, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. If the description is of type "answer", and there are still remaining candidates in the ICE candidate pool, discard them. Uberti, et al. Expires August 31, 2019 [Page 73] Internet-Draft JSEP February 2019 6. Processing RTP/RTCP When bundling, associating incoming RTP/RTCP with the proper m= section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. When not bundling, the proper m= section is clear from the ICE component over which the RTP/RTCP is received. Once the proper m= section(s) are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the m= section(s) and further processing of the RTP/RTCP is done at the RtpTransceiver level. This includes using RID [I-D.ietf-mmusic-rid] to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream. 7. Examples Note that this example section shows several SDP fragments. To format in 72 columns, some of the lines in SDP have been split into multiple lines, where leading whitespace indicates that a line is a continuation of the previous line. In addition, some blank lines have been added to improve readability but are not valid in SDP. More examples of SDP for WebRTC call flows, including examples with IPv6 addresses, can be found in [I-D.ietf-rtcweb-sdp]. 7.1. Simple Example This section shows a very simple example that sets up a minimal audio / video call between two JSEP endpoints without using trickle ICE. The example in the following section provides a more detailed example of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to Bob's endpoint. The messages from the JavaScript application in Alice's browser to the JavaScript in Bob's browser, abbreviated as AliceJS and BobJS respectively, are assumed to flow over some signaling protocol via a web server. The JavaScript on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used. The user agents (JSEP implementations) in Alice and Bob's browsers, abbreviated as AliceUA and BobUA respectively, are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". Uberti, et al. Expires August 31, 2019 [Page 74] Internet-Draft JSEP February 2019 // set up local media state AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: addTrack with two tracks: audio and video AliceJS->AliceUA: createOffer to get offer AliceJS->AliceUA: setLocalDescription with offer AliceUA->AliceJS: multiple onicecandidate events with candidates // wait for ICE gathering to complete AliceUA->AliceJS: onicecandidate event with null candidate AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription // |offer-A1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-A1| WebServer->BobJS: signaling with |offer-A1| // |offer-A1| arrives at Bob BobJS->BobUA: create a PeerConnection BobJS->BobUA: setRemoteDescription with |offer-A1| BobUA->BobJS: ontrack events for audio and video tracks // Bob accepts call BobJS->BobUA: addTrack with local tracks BobJS->BobUA: createAnswer BobJS->BobUA: setLocalDescription with answer BobUA->BobJS: multiple onicecandidate events with candidates // wait for ICE gathering to complete BobUA->BobJS: onicecandidate event with null candidate BobJS->BobUA: get |answer-A1| from currentLocalDescription // |answer-A1| is sent over signaling protocol to Alice BobJS->WebServer: signaling with |answer-A1| WebServer->AliceJS: signaling with |answer-A1| // |answer-A1| arrives at Alice AliceJS->AliceUA: setRemoteDescription with |answer-A1| AliceUA->AliceJS: ontrack events for audio and video tracks // media flows BobUA->AliceUA: media sent from Bob to Alice AliceUA->BobUA: media sent from Alice to Bob The SDP for |offer-A1| looks like: v=0 o=- 4962303333179871722 1 IN IP4 0.0.0.0 Uberti, et al. Expires August 31, 2019 [Page 75] Internet-Draft JSEP February 2019 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 203.0.113.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:47017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ETEn a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10101 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10101 typ host a=end-of-candidates m=video 10102 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.100 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Uberti, et al. Expires August 31, 2019 [Page 76] Internet-Draft JSEP February 2019 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:47017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:BGKk a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10103 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host a=end-of-candidates The SDP for |answer-A1| looks like: v=0 o=- 6729291447651054566 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 203.0.113.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:6sFv a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 Uberti, et al. Expires August 31, 2019 [Page 77] Internet-Draft JSEP February 2019 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=tls-id:eec3392ab83e11ceb6a0990c903fbb19 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=end-of-candidates m=video 10200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 7.2. Detailed Example This section shows a more involved example of a session between two JSEP endpoints. Trickle ICE is used in full trickle mode, with a bundle policy of "max-bundle", an RTCP mux policy of "require", and a single TURN server. Initially, both Alice and Bob establish an audio channel and a data channel. Later, Bob adds two video flows, one for his video feed, and one for screensharing, both supporting FEC, and with the video feed configured for simulcast. Alice accepts these video flows, but does not add video flows of her own, so they are handled as recvonly. Alice also specifies a maximum video decoder resolution. // set up local media state AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: addTrack with an audio track AliceJS->AliceUA: createDataChannel to get data channel AliceJS->AliceUA: createOffer to get |offer-B1| AliceJS->AliceUA: setLocalDescription with |offer-B1| Uberti, et al. Expires August 31, 2019 [Page 78] Internet-Draft JSEP February 2019 // |offer-B1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-B1| WebServer->BobJS: signaling with |offer-B1| // |offer-B1| arrives at Bob BobJS->BobUA: create a PeerConnection BobJS->BobUA: setRemoteDescription with |offer-B1| BobUA->BobJS: ontrack with audio track from Alice // candidates are sent to Bob AliceUA->AliceJS: onicecandidate (host) |offer-B1-candidate-1| AliceJS->WebServer: signaling with |offer-B1-candidate-1| AliceUA->AliceJS: onicecandidate (srflx) |offer-B1-candidate-2| AliceJS->WebServer: signaling with |offer-B1-candidate-2| AliceUA->AliceJS: onicecandidate (relay) |offer-B1-candidate-3| AliceJS->WebServer: signaling with |offer-B1-candidate-3| WebServer->BobJS: signaling with |offer-B1-candidate-1| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-1| WebServer->BobJS: signaling with |offer-B1-candidate-2| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-2| WebServer->BobJS: signaling with |offer-B1-candidate-3| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-3| // Bob accepts call BobJS->BobUA: addTrack with local audio BobJS->BobUA: createDataChannel to get data channel BobJS->BobUA: createAnswer to get |answer-B1| BobJS->BobUA: setLocalDescription with |answer-B1| // |answer-B1| is sent to Alice BobJS->WebServer: signaling with |answer-B1| WebServer->AliceJS: signaling with |answer-B1| AliceJS->AliceUA: setRemoteDescription with |answer-B1| AliceUA->AliceJS: ontrack event with audio track from Bob // candidates are sent to Alice BobUA->BobJS: onicecandidate (host) |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1| BobUA->BobJS: onicecandidate (srflx) |answer-B1-candidate-2| BobJS->WebServer: signaling with |answer-B1-candidate-2| BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-3| BobJS->WebServer: signaling with |answer-B1-candidate-3| WebServer->AliceJS: signaling with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-2| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-2| Uberti, et al. Expires August 31, 2019 [Page 79] Internet-Draft JSEP February 2019 WebServer->AliceJS: signaling with |answer-B1-candidate-3| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-3| // data channel opens BobUA->BobJS: ondatachannel event AliceUA->AliceJS: ondatachannel event BobUA->BobJS: onopen AliceUA->AliceJS: onopen // media is flowing between endpoints BobUA->AliceUA: audio+data sent from Bob to Alice AliceUA->BobUA: audio+data sent from Alice to Bob // some time later Bob adds two video streams // note, no candidates exchanged, because of bundle BobJS->BobUA: addTrack with first video stream BobJS->BobUA: addTrack with second video stream BobJS->BobUA: createOffer to get |offer-B2| BobJS->BobUA: setLocalDescription with |offer-B2| // |offer-B2| is sent to Alice BobJS->WebServer: signaling with |offer-B2| WebServer->AliceJS: signaling with |offer-B2| AliceJS->AliceUA: setRemoteDescription with |offer-B2| AliceUA->AliceJS: ontrack event with first video track AliceUA->AliceJS: ontrack event with second video track AliceJS->AliceUA: createAnswer to get |answer-B2| AliceJS->AliceUA: setLocalDescription with |answer-B2| // |answer-B2| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |answer-B2| WebServer->BobJS: signaling with |answer-B2| BobJS->BobUA: setRemoteDescription with |answer-B2| // media is flowing between endpoints BobUA->AliceUA: audio+video+data sent from Bob to Alice AliceUA->BobUA: audio+video+data sent from Alice to Bob The SDP for |offer-B1| looks like: Uberti, et al. Expires August 31, 2019 [Page 80] Internet-Draft JSEP February 2019 v=0 o=- 4962303333179871723 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 0 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 a=bundle-only |offer-B1-candidate-1| looks like: Uberti, et al. Expires August 31, 2019 [Page 81] Internet-Draft JSEP February 2019 ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host |offer-B1-candidate-2| looks like: ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100 |offer-B1-candidate-3| looks like: ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100 The SDP for |answer-B1| looks like: Uberti, et al. Expires August 31, 2019 [Page 82] Internet-Draft JSEP February 2019 v=0 o=- 7729291447651054566 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 |answer-B1-candidate-1| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host Uberti, et al. Expires August 31, 2019 [Page 83] Internet-Draft JSEP February 2019 |answer-B1-candidate-2| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx raddr 203.0.113.200 rport 10200 |answer-B1-candidate-3| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 198.51.100.200 rport 11200 The SDP for |offer-B2| is shown below. In addition to the new m= sections for video, both of which are offering FEC, and one of which is offering simulcast, note the increment of the version number in the o= line, changes to the c= line, indicating the local candidate that was selected, and the inclusion of gathered candidates as a=candidate lines. v=0 o=- 7729291447651054566 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 v1 v2 a=group:LS a1 v1 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 Uberti, et al. Expires August 31, 2019 [Page 84] Internet-Draft JSEP February 2019 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:actpass a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx raddr 203.0.113.200 rport 10200 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 198.51.100.200 rport 11200 a=end-of-candidates m=application 12200 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.200 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 c=IN IP4 192.0.2.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=rtpmap:104 flexfec/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=rid:1 send a=rid:2 send a=rid:3 send a=simulcast:send 1;2;3 Uberti, et al. Expires August 31, 2019 [Page 85] Internet-Draft JSEP February 2019 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 c=IN IP4 192.0.2.200 a=mid:v2 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=rtpmap:104 flexfec/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae The SDP for |answer-B2| is shown below. In addition to the acceptance of the video m= sections, the use of a=recvonly to indicate one-way video, and the use of a=imageattr to limit the received resolution, note the use of setup:passive to maintain the existing DTLS roles. v=0 o=- 4962303333179871723 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 v1 v2 a=group:LS a1 v1 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid Uberti, et al. Expires August 31, 2019 [Page 86] Internet-Draft JSEP February 2019 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:passive a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100 a=end-of-candidates m=application 12100 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.100 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v1 a=recvonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v2 a=recvonly a=rtpmap:100 VP8/90000 Uberti, et al. Expires August 31, 2019 [Page 87] Internet-Draft JSEP February 2019 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli 7.3. Early Transport Warmup Example This example demonstrates the early warmup technique described in Section 4.1.8.1. Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call. Bob immediately responds with an answer that accepts the audio/video m= sections, but marks them as sendonly (from his perspective), meaning that Alice will not yet send media. This allows the JSEP implementation to start negotiating ICE and DTLS immediately. Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends a second offer which enables the audio and video m= sections, and thereby bidirectional media transmission. The advantage of such a flow is that as soon as the first answer is received, the implementation can proceed with ICE and DTLS negotiation and establish the session transport. If the transport setup completes before the second offer is sent, then media can be transmitted immediately by the callee immediately upon answering the call, minimizing perceived post-dial-delay. The second offer/answer exchange can also change the preferred codecs or other session parameters. This example also makes use of the "relay" ICE candidate policy described in Section 3.5.3 to minimize the ICE gathering and checking needed. // set up local media state AliceJS->AliceUA: create new PeerConnection with "relay" ICE policy AliceJS->AliceUA: addTrack with two tracks: audio and video AliceJS->AliceUA: createOffer to get |offer-C1| AliceJS->AliceUA: setLocalDescription with |offer-C1| // |offer-C1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-C1| WebServer->BobJS: signaling with |offer-C1| Uberti, et al. Expires August 31, 2019 [Page 88] Internet-Draft JSEP February 2019 // |offer-C1| arrives at Bob BobJS->BobUA: create new PeerConnection with "relay" ICE policy BobJS->BobUA: setRemoteDescription with |offer-C1| BobUA->BobJS: ontrack events for audio and video // a relay candidate is sent to Bob AliceUA->AliceJS: onicecandidate (relay) |offer-C1-candidate-1| AliceJS->WebServer: signaling with |offer-C1-candidate-1| WebServer->BobJS: signaling with |offer-C1-candidate-1| BobJS->BobUA: addIceCandidate with |offer-C1-candidate-1| // Bob prepares an early answer to warmup the transport BobJS->BobUA: addTransceiver with null audio and video tracks BobJS->BobUA: transceiver.setDirection(sendonly) for both BobJS->BobUA: createAnswer BobJS->BobUA: setLocalDescription with answer // |answer-C1| is sent over signaling protocol to Alice BobJS->WebServer: signaling with |answer-C1| WebServer->AliceJS: signaling with |answer-C1| // |answer-C1| (sendonly) arrives at Alice AliceJS->AliceUA: setRemoteDescription with |answer-C1| AliceUA->AliceJS: ontrack events for audio and video // a relay candidate is sent to Alice BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| // ICE and DTLS establish while call is ringing // Bob accepts call, starts media, and sends new offer BobJS->BobUA: transceiver.setTrack with audio and video tracks BobUA->AliceUA: media sent from Bob to Alice BobJS->BobUA: transceiver.setDirection(sendrecv) for both transceivers BobJS->BobUA: createOffer BobJS->BobUA: setLocalDescription with offer // |offer-C2| is sent over signaling protocol to Alice BobJS->WebServer: signaling with |offer-C2| WebServer->AliceJS: signaling with |offer-C2| // |offer-C2| (sendrecv) arrives at Alice Uberti, et al. Expires August 31, 2019 [Page 89] Internet-Draft JSEP February 2019 AliceJS->AliceUA: setRemoteDescription with |offer-C2| AliceJS->AliceUA: createAnswer AliceJS->AliceUA: setLocalDescription with |answer-C2| AliceUA->BobUA: media sent from Alice to Bob // |answer-C2| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |answer-C2| WebServer->BobJS: signaling with |answer-C2| BobJS->BobUA: setRemoteDescription with |answer-C2| The SDP for |offer-C1| looks like: v=0 o=- 1070771854436052752 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:actpass a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize Uberti, et al. Expires August 31, 2019 [Page 90] Internet-Draft JSEP February 2019 m=video 0 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=bundle-only |offer-C1-candidate-1| looks like: ufrag 4ZcD index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 0.0.0.0 rport 0 The SDP for |answer-C1| looks like: v=0 o=- 6386516489780559513 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendonly a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 Uberti, et al. Expires August 31, 2019 [Page 91] Internet-Draft JSEP February 2019 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:active a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=video 9 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:751f239e-4ae0-c549-aa3d-890de772998b |answer-C1-candidate-1| looks like: ufrag TpaA index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 0.0.0.0 rport 0 Uberti, et al. Expires August 31, 2019 [Page 92] Internet-Draft JSEP February 2019 The SDP for |offer-C2| looks like: v=0 o=- 6386516489780559513 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:actpass a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 Uberti, et al. Expires August 31, 2019 [Page 93] Internet-Draft JSEP February 2019 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:751f239e-4ae0-c549-aa3d-890de772998b The SDP for |answer-C2| looks like: v=0 o=- 1070771854436052752 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:passive a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay Uberti, et al. Expires August 31, 2019 [Page 94] Internet-Draft JSEP February 2019 raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 8. Security Considerations The IETF has published separate documents [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing the security architecture for WebRTC as a whole. The remainder of this section describes security considerations for this document. While formally the JSEP interface is an API, it is better to think of it as an Internet protocol, with the application JavaScript being untrustworthy from the perspective of the JSEP implementation. Thus, the threat model of [RFC3552] applies. In particular, JavaScript can call the API in any order and with any inputs, including malicious ones. This is particularly relevant when we consider the SDP which is passed to setLocalDescription(). While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior. One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side. Thus, for instance, it is not possible to prevent the remote peer from Uberti, et al. Expires August 31, 2019 [Page 95] Internet-Draft JSEP February 2019 learning your public IP address by removing server reflexive candidates. Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. 9. IANA Considerations This document requires no actions from IANA. 10. Acknowledgements Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter Thatcher provided significant text for this draft. Bernard Aboba, Adam Bergkvist, Dan Burnett, Ben Campbell, Alissa Cooper, Richard Ejzak, Stefan Hakansson, Ted Hardie, Christer Holmberg Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson, Sean Turner, and Magnus Westerlund all provided valuable feedback on this proposal. 11. References 11.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-21 (work in progress), April 2018. [I-D.ietf-mmusic-dtls-sdp] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in progress), November 2018. Uberti, et al. Expires August 31, 2019 [Page 96] Internet-Draft JSEP February 2019 [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", draft-ietf-mmusic-msid-17 (work in progress), December 2018. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-12 (work in progress), May 2017. [I-D.ietf-mmusic-rid] Roach, A., "RTP Payload Format Restrictions", draft-ietf- mmusic-rid-15 (work in progress), May 2018. [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 2017. [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-54 (work in progress), December 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [I-D.ietf-mmusic-sdp-simulcast] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", draft-ietf- mmusic-sdp-simulcast-13 (work in progress), June 2018. [I-D.ietf-rtcweb-fec] Uberti, J., "WebRTC Forward Error Correction Requirements", draft-ietf-rtcweb-fec-08 (work in progress), March 2018. [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-26 (work in progress), March 2016. Uberti, et al. Expires August 31, 2019 [Page 97] Internet-Draft JSEP February 2019 [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-11 (work in progress), February 2019. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 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, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . Uberti, et al. Expires August 31, 2019 [Page 98] Internet-Draft JSEP February 2019 [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, . [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, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [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, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . Uberti, et al. Expires August 31, 2019 [Page 99] Internet-Draft JSEP February 2019 [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, . [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, . [RFC7742] Roach, A., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, . [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, . [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, . [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 11.2. Informative References [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", draft-ietf- mmusic-trickle-ice-sip-18 (work in progress), June 2018. Uberti, et al. Expires August 31, 2019 [Page 100] Internet-Draft JSEP February 2019 [I-D.ietf-rtcweb-ip-handling] Uberti, J., "WebRTC IP Address Handling Requirements", draft-ietf-rtcweb-ip-handling-11 (work in progress), November 2018. [I-D.ietf-rtcweb-sdp] Nandakumar, S. and C. Jennings, "Annotated Example SDP for WebRTC", draft-ietf-rtcweb-sdp-11 (work in progress), October 2018. [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, DOI 10.17487/RFC3960, December 2004, . [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, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 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, . Uberti, et al. Expires August 31, 2019 [Page 101] Internet-Draft JSEP February 2019 [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, . [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, . [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, . [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, . [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, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [TS26.114] 3GPP TS 26.114 V12.8.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (Release 12)", December 2014, . [W3C.webrtc] Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Aboba, B., and T. Brandstetter, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc-20170515, May 2017, . Uberti, et al. Expires August 31, 2019 [Page 102] Internet-Draft JSEP February 2019 Appendix A. Appendix A For the syntax validation performed in Section 5.8, the following list of ABNF definitions is used: Uberti, et al. Expires August 31, 2019 [Page 103] Internet-Draft JSEP February 2019 +------------------------+------------------------------------------+ | Attribute | Reference | +------------------------+------------------------------------------+ | ptime | [RFC4566] Section 9 | | maxptime | [RFC4566] Section 9 | | rtpmap | [RFC4566] Section 9 | | recvonly | [RFC4566] Section 9 | | sendrecv | [RFC4566] Section 9 | | sendonly | [RFC4566] Section 9 | | inactive | [RFC4566] Section 9 | | framerate | [RFC4566] Section 9 | | fmtp | [RFC4566] Section 9 | | quality | [RFC4566] Section 9 | | rtcp | [RFC3605] Section 2.1 | | setup | [RFC4145] Sections 3, 4, and 5 | | connection | [RFC4145] Sections 3, 4, and 5 | | fingerprint | [RFC8122] Section 5 | | rtcp-fb | [RFC4585] Section 4.2 | | extmap | [RFC5285] Section 7 | | mid | [RFC5888] Sections 4 and 5 | | group | [RFC5888] Sections 4 and 5 | | imageattr | [RFC6236] Section 3.1 | | extmap (encrypt | [RFC6904] Section 4 | | option) | | | candidate | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.1 | | remote-candidates | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.2 | | ice-lite | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.3 | | ice-ufrag | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.4 | | ice-pwd | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.4 | | ice-options | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.6 | | msid | [I-D.ietf-mmusic-msid] Section 2 | | rid | [I-D.ietf-mmusic-rid] Section 10 | | simulcast | [I-D.ietf-mmusic-sdp-simulcast] Section | | | 6.1 | | tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 | +------------------------+------------------------------------------+ Table 1: SDP ABNF References Uberti, et al. Expires August 31, 2019 [Page 104] Internet-Draft JSEP February 2019 Appendix B. Change log Note to RFC Editor: Please remove this section before publication. Changes in draft-26: o Update guidance on generation of the m= proto value to be consistent with ice-sip-sdp. Changes in draft-25: o Remove MSID track ID from offers and answers. o Add note about rejecting all m= sections in a BUNDLE group. o Update ICE references to RFC 8445 and mention ice2. Changes in draft-24: o Clarify that rounding is permitted when trying to maintain aspect ratio. o Update tls-id handling to match what is specified in dtls-sdp. Changes in draft-23: o Clarify rollback handling, and treat it similarly to other setLocal/setRemote usages. o Adopt a first-fit policy for handling multiple remote a=imageattr attributes. o Clarify that a session description with zero m= sections is legal. Changes in draft-22: o Clarify currentDirection versus direction. o Correct session-id text so that it aligns with RFC 3264. o Clarify that generated ICE candidate objects must have all four fields. o Make rollback work from any state besides stable and regardless of whether setLocalDescription or setRemoteDescription is used. o Allow modifying SDP before sending or after receiving either offers or answers (previously this was forbidden for answers). Uberti, et al. Expires August 31, 2019 [Page 105] Internet-Draft JSEP February 2019 o Provide rationale for several design choices. Changes in draft-21: o Change dtls-id to tls-id to match MMUSIC draft. o Replace regular expression for proto field with a list and clarify that the answer must exactly match the offer. o Remove text about how to error check on setLocal because local descriptions cannot be changed. o Rework silence suppression support to always require that both sides agree to silence suppression or none is used. o Remove instructions to parse "a=ssrc-group". o Allow the addition of new codecs in answers and in subsequent offers. o Clarify imageattr processing. Replace use of [x=0,y=0] with direction indicators. o Document when early media can occur. o Fix ICE default port handling when bundle-only is used. o Forbid duplicating IDENTICAL/TRANSPORT attributes when you are bundling. o Clarify the number of components to gather when bundle is involved. o Explicitly state that PTs and SSRCs are to be used for demuxing. o Update guidance on "a=setup" line. This should now match the MMUSIC draft. o Update guidance on certificate/digest matching to conform to RFC8122. o Update examples. Changes in draft-20: o Remove Appendix-B. Changes in draft-19: Uberti, et al. Expires August 31, 2019 [Page 106] Internet-Draft JSEP February 2019 o Examples are now machine-generated for correctness, and use IETF- approved example IP addresses. o Add early transport warmup example, and add missing attributes to existing examples. o Only send "a=rtcp-mux-only" and "a=bundle-only" on new m= sections. o Update references. o Add coverage of a=identity. o Explain the lipsync group algorithm more thoroughly. o Remove unnecessary list of MTI specs. o Allow codecs which weren't offered to appear in answers and which weren't selected to appear in subsequent offers. o Codec preferences now are applied on both initial and subsequent offers and answers. o Clarify a=msid handling for recvonly m= sections. o Clarify behavior of attributes for bundle-only data channels. o Allow media attributes to appear in data m= sections when all the media m= sections are bundle-only. o Use consistent terminology for JSEP implementations. o Describe how to handle failed API calls. o Some cleanup on routing rules. Changes in draft-18: o Update demux algorithm and move it to an appendix in preparation for merging it into BUNDLE. o Clarify why we can't handle an incoming offer to send simulcast. o Expand IceCandidate object text. o Further document use of ICE candidate pool. o Document removeTrack. Uberti, et al. Expires August 31, 2019 [Page 107] Internet-Draft JSEP February 2019 o Update requirements to only accept the last generated offer/answer as an argument to setLocalDescription. o Allow round pixels. o Fix code around default timing when AVPF is not specified. o Clean up terminology around m= line and m=section. o Provide a more realistic example for minimum decoder capabilities. o Document behavior when rtcp-mux policy is require but rtcp-mux attribute not provided. o Expanded discussion of RtpSender and RtpReceiver. o Add RtpTransceiver.currentDirection and document setDirection. o Require imageattr x=0, y=0 to indicate that there are no valid resolutions. o Require a privacy-preserving MID/RID construction. o Require support for RFC 3556 bandwidth modifiers. o Update maxptime description. o Note that endpoints may encounter extra codecs in answers and subsequent offers from non-JSEP peers. o Update references. Changes in draft-17: o Split createOffer and createAnswer sections to clearly indicate attributes which always appear and which only appear when not bundled into another m= section. o Add descriptions of RtpTransceiver methods. o Describe how to process RTCP feedback attributes. o Clarify transceiver directions and their interaction with 3264. o Describe setCodecPreferences. o Update RTP demux algorithm. Include RTCP. Uberti, et al. Expires August 31, 2019 [Page 108] Internet-Draft JSEP February 2019 o Update requirements for when a=rtcp is included, limiting to cases where it is needed for backward compatibility. o Clarify SAR handling. o Updated addTrack matching algorithm. o Remove a=ssrc requirements. o Handle a=setup in reoffers. o Discuss how RTX/FEC should be handled. o Discuss how telephone-event should be handled. o Discuss how CN/DTX should be handled. o Add missing references to ABNF table. Changes in draft-16: o Update addIceCandidate to indicate ICE generation and allow per-m= section end-of-candidates. o Update fingerprint handling to use draft-ietf-mmusic-4572-update. o Update text around SDP processing of RTP header extensions and payload formats. o Add sections on simulcast, addTransceiver, and createDataChannel. o Clarify text to ensure that the session ID is a positive 63 bit integer. o Clarify SDP processing for direction indication. o Describe SDP processing for rtcp-mux-only. o Specify how SDP session version in o= line. o Require that when doing an re-offer, the capabilities of the new session are mostly required to be a subset of the previously negotiated session. o Clarified ICE restart interaction with bundle-only. o Remove support for changing SDP before calling setLocalDescription. Uberti, et al. Expires August 31, 2019 [Page 109] Internet-Draft JSEP February 2019 o Specify algorithm for demuxing RTP based on MID, PT, and SSRC. o Clarify rules for rejecting m= lines when bundle policy is balanced or max-bundle. Changes in draft-15: o Clarify text around codecs offered in subsequent transactions to refer to what's been negotiated. o Rewrite LS handling text to indicate edge cases and that we're living with them. o Require that answerer reject m= lines when there are no codecs in common. o Enforce max-bundle on offer processing. o Fix TIAS formula to handle bits vs. kilobits. o Describe addTrack algorithm. o Clean up references. Changes in draft-14: o Added discussion of RtpTransceivers + RtpSenders + RtpReceivers, and how they interact with createOffer/createAnswer. o Removed obsolete OfferToReceiveX options. o Explained how addIceCandidate can be used for end-of-candidates. Changes in draft-13: o Clarified which SDP lines can be ignored. o Clarified how to handle various received attributes. o Revised how attributes should be generated for bundled m= lines. o Remove unused references. o Remove text advocating use of unilateral PTs. o Trigger an ICE restart even if the ICE candidate policy is being made more strict. Uberti, et al. Expires August 31, 2019 [Page 110] Internet-Draft JSEP February 2019 o Remove the 'public' ICE candidate policy. o Move open issues into GitHub issues. o Split local/remote description accessors into current/pending. o Clarify a=imageattr handling. o Add more detail on VoiceActivityDetection handling. o Reference draft-shieh-rtcweb-ip-handling. o Make it clear when an ICE restart should occur. o Resolve changes needed in references. o Remove MSID semantics. o ice-options are now at session level. o Default RTCP mux policy is now 'require'. Changes in draft-12: o Filled in sections on applying local and remote descriptions. o Discussed downscaling and upscaling to fulfill imageattr requirements. o Updated what SDP can be modified by the application. o Updated to latest datachannel SDP. o Allowed multiple fingerprint lines. o Switched back to IPv4 for dummy candidates. o Added additional clarity on ICE default candidates. Changes in draft-11: o Clarified handling of RTP CNAMEs. o Updated what SDP lines should be processed or ignored. o Specified how a=imageattr should be used. Changes in draft-10: Uberti, et al. Expires August 31, 2019 [Page 111] Internet-Draft JSEP February 2019 o Described video size negotiation with imageattr. o Clarified rejection of sections that do not have mux-only. o Add handling of LS groups Changes in draft-09: o Don't return null for {local,remote}Description after close(). o Changed TCP/TLS to UDP/DTLS in RTP profile names. o Separate out bundle and mux policy. o Added specific references to FEC mechanisms. o Added canTrickle mechanism. o Added section on subsequent answers and, answer options. o Added text defining set{Local,Remote}Description behavior. Changes in draft-08: o Added new example section and removed old examples in appendix. o Fixed field handling. o Added text describing a=rtcp attribute. o Reworked handling of OfferToReceiveAudio and OfferToReceiveVideo per discussion at IETF 90. o Reworked trickle ICE handling and its impact on m= and c= lines per discussion at interim. o Added max-bundle-and-rtcp-mux policy. o Added description of maxptime handling. o Updated ICE candidate pool default to 0. o Resolved open issues around AppID/receiver-ID. o Reworked and expanded how changes to the ICE configuration are handled. o Some reference updates. Uberti, et al. Expires August 31, 2019 [Page 112] Internet-Draft JSEP February 2019 o Editorial clarification. Changes in draft-07: o Expanded discussion of VAD and Opus DTX. o Added a security considerations section. o Rewrote the section on modifying SDP to require implementations to clearly indicate whether any given modification is allowed. o Clarified impact of IceRestart on CreateOffer in local-offer state. o Guidance on whether attributes should be defined at the media level or the session level. o Renamed "default" bundle policy to "balanced". o Removed default ICE candidate pool size and clarify how it works. o Defined a canonical order for assignment of MSTs to m= lines. o Removed discussion of rehydration. o Added Eric Rescorla as a draft editor. o Cleaned up references. o Editorial cleanup Changes in draft-06: o Reworked handling of m= line recycling. o Added handling of BUNDLE and bundle-only. o Clarified handling of rollback. o Added text describing the ICE Candidate Pool and its behavior. o Allowed OfferToReceiveX to create multiple recvonly m= sections. Changes in draft-05: o Fixed several issues identified in the createOffer/Answer sections during document review. Uberti, et al. Expires August 31, 2019 [Page 113] Internet-Draft JSEP February 2019 o Updated references. Changes in draft-04: o Filled in sections on createOffer and createAnswer. o Added SDP examples. o Fixed references. Changes in draft-03: o Added text describing relationship to W3C specification Changes in draft-02: o Converted from nroff o Removed comparisons to old approaches abandoned by the working group o Removed stuff that has moved to W3C specification o Align SDP handling with W3C draft o Clarified section on forking. Changes in draft-01: o Added diagrams for architecture and state machine. o Added sections on forking and rehydration. o Clarified meaning of "pranswer" and "answer". o Reworked how ICE restarts and media directions are controlled. o Added list of parameters that can be changed in a description. o Updated suggested API and examples to match latest thinking. o Suggested API and examples have been moved to an appendix. Changes in draft -00: o Migrated from draft-uberti-rtcweb-jsep-02. Uberti, et al. Expires August 31, 2019 [Page 114] Internet-Draft JSEP February 2019 Authors' Addresses Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Email: justin@uberti.name Cullen Jennings Cisco 400 3rd Avenue SW Calgary, AB T2P 4H2 Canada Email: fluffy@iii.ca Eric Rescorla (editor) Mozilla 331 Evelyn Ave Mountain View, CA 94041 USA Email: ekr@rtfm.com Uberti, et al. Expires August 31, 2019 [Page 115] ./draft-ietf-pce-association-group-10.txt0000644000764400076440000020224213520607017017567 0ustar iustyiusty PCE Working Group I. Minei Internet-Draft Google, Inc. Intended status: Standards Track E. Crabbe Expires: February 2, 2020 Individual Contributor S. Sivabalan Cisco Systems, Inc. H. Ananthakrishnan Netflix D. Dhody Huawei Y. Tanaka NTT Communications Corporation August 1, 2019 Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships Between Sets of Label Switched Paths (LSPs) draft-ietf-pce-association-group-10 Abstract This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviours), and is equally applicable to the stateful PCE (active and passive modes) as well as the stateless PCE. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 https://datatracker.ietf.org/drafts/current/. Minei, et al. Expires February 2, 2020 [Page 1] Internet-Draft PCE association group August 2019 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 2, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Relationship with the SVEC List . . . . . . . . . . . . . 5 3.3. Operation Overview . . . . . . . . . . . . . . . . . . . 5 3.4. Operator-configured Association Range . . . . . . . . . . 6 4. Discovery of Supported Association Types . . . . . . . . . . 7 4.1. ASSOC-Type-List TLV . . . . . . . . . . . . . . . . . . . 7 4.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8 5. Operator-configured Association Range TLV . . . . . . . . . . 8 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10 6. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . . 11 6.1. Object Definition . . . . . . . . . . . . . . . . . . . . 11 6.1.1. Global Association Source TLV . . . . . . . . . . . . 13 6.1.2. Extended Association ID TLV . . . . . . . . . . . . . 13 6.1.3. Association Source . . . . . . . . . . . . . . . . . 14 6.1.4. Unique Identification for an Association Group . . . 14 6.2. Relationship with the RSVP ASSOCIATION . . . . . . . . . 15 6.3. Object Encoding in PCEP messages . . . . . . . . . . . . 15 6.3.1. Stateful PCEP messages . . . . . . . . . . . . . . . 15 6.3.2. Request Message . . . . . . . . . . . . . . . . . . . 17 6.3.3. Reply Message . . . . . . . . . . . . . . . . . . . . 18 6.4. Processing Rules . . . . . . . . . . . . . . . . . . . . 19 Minei, et al. Expires February 2, 2020 [Page 2] Internet-Draft PCE association group August 2019 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Association Flags . . . . . . . . . . . . . . . . . . . . 22 7.4. Association Type . . . . . . . . . . . . . . . . . . . . 23 7.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Manageability Considerations . . . . . . . . . . . . . . . . 24 9.1. Control of Function and Policy . . . . . . . . . . . . . 24 9.2. Information and Data Models . . . . . . . . . . . . . . . 24 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 25 9.5. Requirements on Other Protocols . . . . . . . . . . . . . 25 9.6. Impact on Network Operations . . . . . . . . . . . . . . 25 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Example for Operator-configured Association Range . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction [RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP enables the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, for the purpose of computation of Multiprotocol Label Switching (MPLS) as well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP) characteristics. [RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The model of operation where LSPs are initiated from the PCE is described in [RFC8281]. [RFC4872] defines the RSVP ASSOCIATION object, which was defined in the context of GMPLS-controlled Label Switched Paths (LSPs) to be used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state and [RFC6780] described how the ASSOCIATION object can be more generally applied by defining the Extended ASSOCIATION Object. Minei, et al. Expires February 2, 2020 [Page 3] Internet-Draft PCE association group August 2019 This document introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviours), and is equally applicable to stateful PCE (active and passive modes) and stateless PCE. The associations could be created dynamically and conveyed to a PCEP peer within PCEP, or it could be configured manually by an operator on the PCEP peers. Refer Section 3.3 for more details. 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, Path Computation Request (PCReq), Path Computation Reply (PCRep), and PCEP Error (PCErr). This document uses the following terms defined in [RFC8051]: Stateful PCE, Active Stateful PCE, Passive Stateful PCE, and Delegation. This document uses the following terms defined in [RFC8231]: LSP State Report (PCRpt), LSP Update Request (PCUpd), and State Timeout Interval. This document uses the following terms defined in [RFC8281]: PCE- initiated LSP, and LSP Initiate Request (PCInitiate). 3. Architectural Overview 3.1. Motivation Stateful PCE provides the ability to update existing LSPs and to instantiate new ones. There are various situations where several LSPs need to share common information. E.g., to support for PCE- controlled make-before-break, an association between the original and the re-optimized path is desired. Similarly, for end-to-end protection, the association between working and protection LSPs is required (see [I-D.ietf-pce-stateful-path-protection]). For diverse paths, an association between a group of LSPs could be used (see [I-D.ietf-pce-association-diversity]). Another use for the LSP grouping is for applying a common set of configuration parameters or behaviours to a set of LSPs. For a stateless PCE, it might be useful to associate a path computation request to an association group, thus enabling it to associate a common set of policy, configuration parameters or behaviours with the request. Some associations could be created dynamically, such as association between the working and protection LSPs of a tunnel, whereas some Minei, et al. Expires February 2, 2020 [Page 4] Internet-Draft PCE association group August 2019 associations could be created by the operator manually, such as policy-based association, where the LSP could join an operator- configured existing association. Rather than creating separate mechanisms for each use case, this document defines a generic mechanism that can be reused as needed. 3.2. Relationship with the SVEC List Note that, [RFC5440] defines a mechanism for the synchronization of a set of path computation requests by using the SVEC (Synchronization VECtor) object, that specifies the list of synchronized requests that can either be dependent or independent. The SVEC object identifies the relationship between the set of path computation requests, identified by 'Request-ID-number' in RP (Request Parameters) object. [RFC6007] further clarifies the use of the SVEC list for synchronized path computations when computing dependent requests as well as describes a number of usage scenarios for SVEC lists within single- domain and multi-domain environments. The motivation behind the association group defined in this document and the SVEC object are quite different, though some use cases may overlap. PCEP extensions that define a new association type should clarify the relationship between the SVEC object and the association type, if any. 3.3. Operation Overview LSPs are associated with other LSPs with which they interact by adding them to a common association group. Association groups as defined in this document can be applied to LSPs originating at the same head end or different head ends. Some associations could be created dynamically by a PCEP speaker and the associations (along with the set of LSPs) are conveyed to a PCEP peer. Whereas some associations are configured by the operator on the PCEP peers involved beforehand, a PCEP speaker then could ask for a LSP to join the operator-configured association. Usage of dynamic and configured association is usually dependent on the type of the association. For the operator-configured association, the association parameters such as the association identifier, association type, as well as the association source IP address, are manually configured by the operator. In case of dynamic association, the association parameters such as the association identifier, are allocated dynamically by the PCEP speaker, the association source is set as local PCEP speaker Minei, et al. Expires February 2, 2020 [Page 5] Internet-Draft PCE association group August 2019 address, unless local policy dictates otherwise, in which case association source is set based on the local policy. The dynamically created association can be reported to the PCEP peer via the PCEP messages as per the stateful extensions. When the operator-configured association is known to the PCEP peer beforehand, a PCEP peer could ask for a LSP to join the operator-configured association via the stateful PCEP messages. The associations are properties of the LSP and thus could be stored in the LSP state database. The dynamic association exists as long as the LSP state exists. In case of PCEP session termination, the LSP state clean-up MUST also take care of associations. Multiple types of associations can exist, each with their own association identifier space. The definition of the different association types and their behaviours is outside the scope of this document. The establishment and removal of the association relationship can be done on a per LSP basis. An LSP may join multiple association groups, of different or of the same association type. 3.4. Operator-configured Association Range Some association types are dynamic, some are operator-configured and some could be both. For the association types that could be both dynamic and operator-configured and use the same association source, it is necessary to distinguish a range of association identifiers that are marked for operator-configured associations to avoid any association identifier clash within the scope of the association source. This document assumes that these two ranges are configured. A range of association identifiers for each Association type (and Association Source) are kept for the operator-configured associations. Dynamic associations MUST NOT use the association identifier from this range. This range as set at the PCEP speaker (PCC or PCE, as an association source) needs to be communicated to a PCEP peer in the Open Message. A new TLV is defined in this specification for this purpose (Section 5). See Appendix A for an example. Association identifier range for sources other than the PCEP speaker (for example an NMS system) is not communicated in PCEP and the procedure for operator-configured association range setting is outside the scope of this document. Minei, et al. Expires February 2, 2020 [Page 6] Internet-Draft PCE association group August 2019 4. Discovery of Supported Association Types This section defines PCEP extensions so as to support the capability advertisement of the association types supported by a PCEP speaker. A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. The PCEP ASSOC-Type-List TLV is carried within an OPEN object. This way, during PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer the list of supported Association types. 4.1. ASSOC-Type-List TLV The PCEP ASSOC-Type-List TLV is OPTIONAL. It MAY be carried within an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer so as to indicate the list of supported Association types. The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a Value field. The Length field defines the length of the value portion in octets. The TLV is padded to 4-octet alignment, and padding is not included in the Length field (e.g., a 3-octet value would have a length of three, but the total size of the TLV would be eight octets). The PCEP ASSOC-Type-List TLV has the following format: TYPE: TBD LENGTH: N * 2 (where N is the number of association types) VALUE: list of 2-byte association type code points, identifying the association types supported by the sender of the Open message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assoc-type #1 | Assoc-type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assoc-type #N | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The ASSOC-Type-List TLV format Minei, et al. Expires February 2, 2020 [Page 7] Internet-Draft PCE association group August 2019 Assoc-type (2 bytes): Association type code point identifier. IANA manages the "ASSOCIATION Type Field" code point registry (see Section 7.4). 4.1.1. Procedure An ASSOC-Type-List TLV within an OPEN object in an Open message is included by a PCEP speaker in order to advertise a set of one or more supported association types. The ASSOC-Type-List TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message). As specified in [RFC5440], a PCEP peer that does not recognize the ASSOC-Type-List TLV will silently ignore it. Association type (to be defined in other documents) can specify if the association type advertisement is mandatory for it. Thus, the ASSOC-Type-List TLV MUST be included if at least one mandatory association type needs to be advertised and the ASSOC-Type-List TLV MAY be included otherwise. For an association type that specifies that the advertisement is mandatory, a missing Assoc-type in the ASSOC-Type-List TLV (or missing ASSOC-Type-List TLV) is to be interpreted as the association type is not supported by the PCEP speaker. The absence of the ASSOC-Type-List TLV in an OPEN object MUST be interpreted as an absence of information on the list of supported Association types (rather than the Association type is not supported). In this case, the PCEP speaker could still use the ASSOCIATION object: if the peer does not support the association, it will react as per the procedure described in Section 6.4. In case the use of the ASSOC-Type-List TLV is triggered by support for a mandatory association type, then it is RECOMMENDED that the PCEP implementation include all supported Association types (including optional) to ease the operations of the PCEP peer. 5. Operator-configured Association Range TLV This section defines PCEP extension to support the advertisement of the Operator-configured Association Range used for an Association type by the PCEP speaker (as an Association source). A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association Range) TLV is defined. The PCEP OP-CONF-ASSOC-RANGE TLV is carried within an OPEN object. This way, during PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer the Operator-configured Association Range for an association type. Minei, et al. Expires February 2, 2020 [Page 8] Internet-Draft PCE association group August 2019 The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL. It MAY be carried within an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer. The OP-CONF-ASSOC-RANGE TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 bytes for the type, 2 bytes specifying the TLV length, and a Value field. The Length field defines the length of the value portion in bytes. The PCEP OP-CONF-ASSOC-RANGE TLV has the following format: TYPE: 29 (Early allocation by IANA) LENGTH: N * 8 (where N is the number of association types) VALUE: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Assoc-type #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Assoc-ID #1 | Range #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Assoc-type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Assoc-ID #N | Range #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The OP-CONF-ASSOC-RANGE TLV format The Value portion includes the following fields, repeated for each association type: Reserved (2 bytes): This field MUST be set to 0 on transmission and MUST be ignored on receipt. Assoc-type (2 bytes): The association type (Section 7.4). The association types are defined in separate documents. Start-Assoc-ID (2 bytes): The start association identifier for the Operator-configured Association Range for the particular association type. The values 0 and 0xffff MUST NOT be used and on receipt of these values in the TLV, the session is rejected with error message sent (see Section 5.1). Minei, et al. Expires February 2, 2020 [Page 9] Internet-Draft PCE association group August 2019 Range (2 bytes): The number of associations marked for the Operator-configured Associations. The Range MUST be greater than 0, and it MUST be such that (Start-Assoc-ID + Range) do not cross the association identifier range of 0xffff. In case this condition is not satisfied, the session is rejected with error message sent (see Section 5.1). 5.1. Procedure A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN object in an Open message sent to a PCEP peer in order to advertise the Operator-configured Association Range for an association type. The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message). As specified in [RFC5440], a PCEP peer that does not recognize the OP-CONF-ASSOC-RANGE TLV will silently ignore it. The Operator-configured Association Range SHOULD be included for each association type that could be both dynamic and operator-configured. For association types that are only dynamic or only operator- configured, this TLV MAY be skipped, in which case the full range of association identifier is considered dynamic or operator-configured respectively. Each association type (that are defined in separate documents) can specify the default value for the operator-configured association range for their respective association type. The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be interpreted as an absence of explicit Operator-configured Association Range at the PCEP peer. In this case, the default behavior as per each association type applies. If the association source is not a PCEP speaker, the default value for the operator-configured association range is used for the association source. If the Assoc-type is not recognized or supported by the PCEP speaker, it MUST ignore that respective Start-Assoc-ID and Range. If the Assoc-type is recognized/supported but the Start-Assoc-ID or Range are set incorrectly, the PCEP session MUST be rejected with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message). The incorrect range include the case when the (Start-Assoc-ID + Range) crosses the association identifier range of 0xffff. A given Assoc-type MAY appear more than once in the OP-CONF-ASSOC- RANGE TLV in the case of a non-contiguous Operator-configured Association Range. The PCEP speaker originating this TLV MUST NOT Minei, et al. Expires February 2, 2020 [Page 10] Internet-Draft PCE association group August 2019 carry overlapping ranges for an association type. If a PCEP peer receives overlapping ranges for an association type, it MUST consider the Open message malformed and MUST reject the PCEP session with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message). There may be cases where an operator-configured association was configured with association parameters (such as association identifier, association type and association source) at the local PCEP speaker, and later the PCEP session gets established with the association source and a new operator-configured range is learned during session establishment. At this time, the local PCEP speaker MUST remove any associations that are not in the new operator- configured range (by disassociating any LSPs that are part of it (and notifying this change to the PCEP peer)). If a PCEP speaker receives an association for an operator-configured association and the association identifier is not in the operator-configured association range for the association type and association source, it MUST generate an error (as described in Section 6.4). 6. ASSOCIATION Object 6.1. Object Definition Association groups and their memberships are defined using a new ASSOCIATION object. ASSOCIATION Object-Class is 40 (Early allocation by IANA). ASSOCIATION Object-Type is 1 for IPv4 and its format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The IPv4 ASSOCIATION Object format Minei, et al. Expires February 2, 2020 [Page 11] Internet-Draft PCE association group August 2019 ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in Figure 4: 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 | Flags |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Association Source | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The IPv6 ASSOCIATION Object format Reserved (2-byte): MUST be set to 0 and ignored upon receipt. Flags (2-byte): The following flags are currently defined: R (Removal - 1 bit): when set, the requesting PCEP peer requires the removal of an LSP from the association group. When unset, the PCEP peer indicates that the LSP is added or retained as part of the association group. This flag is used for the ASSOCIATION object in the PCRpt and the PCUpd message, the flag is ignored in other PCEP messages. The unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Association type (2-byte): the association type (Section 7.4). The association types are defined in separate documents. Association ID (2-byte): the identifier of the association group. When combined with other association parameters, such as Association Type and Association Source, this value uniquely identifies an association group. The values 0xffff and 0x0 are reserved. The value 0xffff is used to indicate all association groups and could be used with R flag to indicate removal for all associations for the LSP within the scope of association type and association source. Minei, et al. Expires February 2, 2020 [Page 12] Internet-Draft PCE association group August 2019 Association Source: Contains a valid IPv4 address (4 bytes) if the ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if the ASSOCIATION Object-Type is 2. The address provides scoping for the Association ID. See Section 6.1.3 for details. Optional TLVs: The optional TLVs follow the PCEP TLV format of [RFC5440]. This document defines two optional TLVs. Other documents can define more TLVs in future. 6.1.1. Global Association Source TLV The Global Association Source TLV is an optional TLV for use in the Association Object. The meaning and the usage of Global Association Source is as per Section 4 of [RFC6780]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The Global Association Source TLV format Type: 30 (Early allocation by IANA). Length: Fixed value of 4 bytes. Global Association Source: as defined in Section 4 of [RFC6780]. 6.1.2. Extended Association ID TLV The Extended Association ID TLV is an optional TLV for use in the Association Object. The meaning and the usage of Extended Association ID is as per Section 4 of [RFC6780]. Minei, et al. Expires February 2, 2020 [Page 13] Internet-Draft PCE association group August 2019 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 Association ID // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: The Extended Association ID TLV format Type: 31 (Early allocation by IANA). Length: variable. Extended Association ID: as defined in Section 4 of [RFC6780]. 6.1.3. Association Source The Association Source field in the ASSOCIATION object is set to a valid IP address to identify the node that originates the association. In case of dynamic associations, the association source is usually set as the local PCEP speaker address, unless local policy dictates otherwise, in which case association source is set based on the local policy. In case of PCE redundancy, local policy could set the source as a virtual IP address which identifies all instances of the PCE. In case of operator-configured association, the association source is manually configured and it could be set as one of the PCEP speakers, Network Management System (NMS), or any other valid IP address that scopes the association identifier for the association type. 6.1.4. Unique Identification for an Association Group The combination of the mandatory fields Association type, Association ID and Association Source in the ASSOCIATION object uniquely identify the association group. If the optional TLVs - Global Association Source or Extended Association ID are included, then they MUST be included in combination with mandatory fields to uniquely identify the association group. In this document, all these fields are collectively called 'association parameters'. Note that the ASSOCIATION object MAY include other optional TLVs (not defined in this document) based on the association types, that provides 'information' related to the association type, this document uses the term 'association information' for it. Minei, et al. Expires February 2, 2020 [Page 14] Internet-Draft PCE association group August 2019 6.2. Relationship with the RSVP ASSOCIATION The format of PCEP ASSOCIATION Object defined in this document is aligned with the RSVP ASSOCIATION object ([RFC6780]). Various Association types related to RSVP association are defined in [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that define new association types, should clarify how the PCEP associations would work with RSVP associations and vice-versa. 6.3. Object Encoding in PCEP messages Message formats in this document are expressed using Reduced BNF (RBNF) as used in [RFC5440] and defined in [RFC5511]. 6.3.1. Stateful PCEP messages The ASSOCIATION Object MAY be carried in the Path Computation Update (PCUpd), Path Computation Report (PCRpt) and Path Computation Initiate (PCInitiate) messages. When carried in PCRpt message, it is used to report the association group membership pertaining to a LSP to a stateful PCE. The PCRpt message are used for both initial state synchronization operations (Section 5.6 of [RFC8231]) as well as whenever the state of the LSP changes. If the LSP belongs to an association group, then the associations MUST be included during the state synchronization operations. The PCRpt message can also be used to remove an LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object. When an LSP is first reported to the PCE, the PCRpt message MUST include all the association groups that it belongs to. Any subsequent report message SHOULD include only the associations that are being modified or removed. The PCRpt message is defined in [RFC8231] and updated as below: Minei, et al. Expires February 2, 2020 [Page 15] Internet-Draft PCE association group August 2019 ::= Where: ::= [] ::= [] [] Where: ::= [] ::= [] When an LSP is delegated to a stateful PCE, the stateful PCE can create a new association group for this LSP, or associate it with one or more existing association groups. This is done by including the ASSOCIATION Object in a PCUpd message. A stateful PCE can also remove a delegated LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object. The PCUpd message SHOULD include the association groups that are being modified or removed, there is no need to include associations that remains unchanged. The PCUpd message is defined in [RFC8231] and updated as below: ::= Where: ::= [] ::= [] Where: ::= ::= [] Minei, et al. Expires February 2, 2020 [Page 16] Internet-Draft PCE association group August 2019 Unless a PCEP speaker wants to delete an association from an LSP or make changes to the association, it does not need to carry the ASSOCIATION object in future stateful messages. A PCE initiating a new LSP can also include the association groups that this LSP belongs to. This is done by including the ASSOCIATION Object in a PCInitiate message. The PCInitiate message MUST include all the association groups that it belongs to. The PCInitiate message is defined in [RFC8281] and updated as below: ::= Where: ::= [] ::= (| ) ::= [] [] [] Where: ::= [] 6.3.2. Request Message In case of passive (stateful or stateless) PCE, the ASSOCIATION Object is OPTIONAL and MAY be carried in the Path Computation Request (PCReq) message. When carried in a PCReq message, the ASSOCIATION Object is used to associate the path computation request to an association group. The association (and the other LSPs) should be known to the PCE beforehand. These could be operator-configured or dynamically learned before via stateful PCEP messages. The R flag in ASSOCIATION object within PCReq message MUST be set to 0 while sending and ignored on receipt. The PCReq message is defined in [RFC5440] and updated in [RFC8231] , it is further updated below for association: Minei, et al. Expires February 2, 2020 [Page 17] Internet-Draft PCE association group August 2019 ::= [] Where: ::= [] ::= [] ::= [] [] [] [] [] [[]] [] [] Where: ::= [] Note that the LSP object MAY be present for the passive stateful PCE mode. 6.3.3. Reply Message In case of passive (stateful or stateless) PCE, the ASSOCIATION Object is OPTIONAL and MAY be carried in the Path Computation Reply (PCRep) message with the NO-PATH object. The ASSOCIATION object in PCRep message indicates the association group that cause the PCE to fail to find a path. The PCRep message is defined in [RFC5440] and updated in [RFC8231] , it is further updated below for association: Minei, et al. Expires February 2, 2020 [Page 18] Internet-Draft PCE association group August 2019 ::= Where: ::=[] ::= [] [] [] [] [] Where: ::= [] Note that the LSP object MAY be present for the passive stateful PCE mode. 6.4. Processing Rules Association groups can be operator-configured on the necessary PCEP speakers and the PCEP speakers can join the existing association groups. In addition, a PCC or a PCE can create association groups dynamically and the PCEP speaker can also report the associations to its peer via PCEP messages. The operator-configured associations are created via configurations (where all association parameters are manually set) and exist until explicitly removed via configurations. The PCEP speaker can add LSPs to these configured associations and carry this via stateful PCEP messages. The dynamic associations are created dynamically by the PCEP speaker (where all association parameters are populated dynamically). The association group is attached to the LSP state, and the association group exists till there is at least one LSP as part of the association. As described in Section 6.1.4, the association parameters are the combination of Association type, Association ID and Association Source as well as optional global source and extended association identifier, that uniquely identifies an association group. The information related to the association types encoded via the TLVs of a particular association type (not described in this document) are the association information (Section 6.1.4). If a PCEP speaker does not recognize the ASSOCIATION object in the stateful message, it will return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440]. In case of PCReq message, the PCE would react based on the P flag as per [RFC5440]. If a PCEP speaker understands the ASSOCIATION object but does not support the Association type, it MUST return a PCErr message with Minei, et al. Expires February 2, 2020 [Page 19] Internet-Draft PCE association group August 2019 Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 1 "Association type is not supported". If any association parameters are invalid in the ASSOCIATION object, the PCEP speaker would consider this as malformed object and handle it as malformed message [RFC5440]. On receiving a PCEP message with ASSOCIATION, if a PCEP speaker finds that too many LSPs belong to the association group, it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 2 "Too many LSPs in the association group". If a PCEP speaker cannot handle a new association, it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 3 "Too many association groups". These numbers MAY be set by operator or decided based on a local policy. If a PCE peer is unwilling or unable to process the ASSOCIATION object in the stateful message, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440]. In case of PCReq message, the PCE would react based on the P flag as per [RFC5440]. On receiving a PCEP message with ASSOCIATION, if a PCEP speaker could not add the LSP to the association group for any reason, it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 7 "Cannot join the association group". If a PCEP speaker receives an ASSOCIATION object for an operator- configured association and the association identifier is not in the operator-configured association range for the Association type and Association Source, it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 8 "Association identifier not in range". If a PCEP speaker receives ASSOCIATION in PCReq message, and the association is not known (association is not configured, or created dynamically, or learned from a PCEP peer), it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 4 "Association unknown". If the association information (related to the association group as a whole) received from the peer does not match with the local operator- configured information, it MUST return a PCErr message with Error- Type 26 (Early allocation by IANA) "Association Error" and Error- Value 5 "Operator-configured association information mismatch". On receiving association information (related to the association group as a whole) that does not match with the association information previously received about the same association from a peer, it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value 6 "Association information mismatch". Note that information related to each LSP within the Minei, et al. Expires February 2, 2020 [Page 20] Internet-Draft PCE association group August 2019 association as part of the association information TLVs could be different. If a PCEP speaker receives an ASSOCIATION object with the R bit set for removal, and the association group (identified by association parameters) is not known, it MUST return a PCErr message with Error- Type 26 (Early allocation by IANA) "Association Error" and Error- Value 4 "Association unknown". The dynamic associations are cleared along with the LSP state information as per the [RFC8231]. When a PCEP session is terminated, after expiry of State Timeout Interval at PCC, the LSP state associated with that PCEP session is reverted to operator-defined default parameters or behaviours. Same procedure is also followed for the association groups. On session termination at the PCE, when the LSP state reported by PCC is cleared, the association groups are also cleared. When there are no LSPs in an association group, the association is considered to be empty and thus deleted. In case the LSP is delegated to another PCE on session failure, the associations (and association information) set by the PCE remains intact, unless updated by the new PCE that takes over. Upon LSP delegation revocation, the PCC MAY clear the association created by the PCE, but in order to avoid traffic loss, it SHOULD perform this in a make-before-break fashion (same as [RFC8231]). 7. IANA Considerations IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at . 7.1. PCEP Object The "PCEP Numbers" registry contains a subregistry "PCEP Objects". IANA is requested to confirm the early allocation of the following code point in the PCEP Objects registry. Object-Class Value Name Reference 40 (Early allocation by Association [This.I-D] IANA) Object-Type 0: Reserved 1: IPv4 2: IPv6 Minei, et al. Expires February 2, 2020 [Page 21] Internet-Draft PCE association group August 2019 7.2. PCEP TLV IANA is requested to confirm the early allocation of the following code point in the "PCEP TLV Type Indicators" registry. Value Meaning Reference 29 (Early Operator-configured [This.I-D] allocation by Association Range IANA) 30 (Early Global Association Source [This.I-D] allocation by IANA) 31 (Early Extended Association ID [This.I-D] allocation by IANA) IANA is requested to fix the meaning for value 31 in the above registry to 'Extended Association ID', it is currently mentioned as 'Extended Association Id'. IANA is also requested to make a new assignment for the existing "PCEP TLV Type Indicators" registry as follows: Value Meaning Reference TBD ASSOC-Type-List [This.I-D] 7.3. Association Flags This document requests IANA to create a subregistry of the "PCEP Numbers" for the bits carried in the Flags field of the ASSOCIATION object. The subregistry is called "ASSOCIATION Flags Field". New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC Bit Description Reference 15 R (Removal) [This.I-D] Minei, et al. Expires February 2, 2020 [Page 22] Internet-Draft PCE association group August 2019 7.4. Association Type This document requests IANA to create a subregistry of the "PCEP Numbers" for the Association Type field of the the ASSOCIATION object. The subregistry is called "ASSOCIATION Type Field". New values are to be assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities: o Type o Name o Reference There are no association types specified in this document, future documents should request the assignment of association types from this subregistry. 7.5. PCEP-Error Object IANA is requested to confirm the early allocation of the following code points within the "PCEP-ERROR Object Error Types and Values" sub-registry of the "PCEP Numbers" registry, as follows: Error-Type Meaning 26 Association Error [This.I-D] (early Error-value=0: alloc by Unassigned IANA) Error-value=1: Association type is not supported Error-value=2: Too many LSPs in the association group Error-value=3: Too many association groups Error-value=4: Association unknown Error-value=5: Operator-configured association information mismatch Error-value=6: Association information mismatch Error-value=7: Cannot join the association group Error-value=8: Association identifier not in range Minei, et al. Expires February 2, 2020 [Page 23] Internet-Draft PCE association group August 2019 8. Security Considerations The security considerations described in [RFC8231] and [RFC5440] apply to the extensions described in this document as well. Additional considerations related to a malicious PCEP speaker are introduced, as associations could be spoofed and could be used as an attack vector. An attacker could attempt to create too many associations in an attempt to load the PCEP peer. The PCEP peer responds with PCErr as described in Section 6.4. An attacker could impact LSP operations by creating bogus associations. Further, association groups could provides an adversary with the opportunity to eavesdrop on the relationship between the LSPs. Thus securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED. Much of the information carried in the ASSOCIATION object, as per this document is not extra sensitive. It often reflects information that can also be derived from the LSP Database, but association provides a much easier grouping of related LSPs and messages. Implementations and operator can and should use indirect values in ASSOCIATION as a way to hide any sensitive business relationships. 9. Manageability Considerations All manageability requirements and considerations listed in [RFC5440] and [RFC8231] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply. 9.1. Control of Function and Policy A PCE or PCC implementation MUST allow operator-configured associations and SHOULD allow setting of the operator-configured association range (Section 3.4) as described in this document. 9.2. Information and Data Models The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In future, this YANG module should be extended or augmented to provide the following additional information relating to association groups. An implementation SHOULD allow the operator to view the associations configured or created dynamically. Further implementation SHOULD allow to view associations reported by each peer, and the current set of LSPs in the association. Minei, et al. Expires February 2, 2020 [Page 24] Internet-Draft PCE association group August 2019 It might also be useful to find out how many associations for each association type currently exist and to know how many free association identifiers are available for a particular association type and source. 9.3. Liveness Detection and Monitoring 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 Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440] and [RFC8231]. 9.5. Requirements on Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. 9.6. Impact on Network Operations Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this document. 10. Acknowledgments We would like to thank Yuji Kamite and Joshua George for their contributions to this document. Also thanks to Venugopal Reddy, Cyril Margaria, Rakesh Gandhi, Mike Koldychev, and Adrian Farrel for their useful comments. We would like to thank Julien Meuric for shepherding this document and providing comments with text suggestions. Thanks to Stig Venaas for the RTGDIR review comments. Thanks to Alvaro Retana, Mirja Kuhlewind, Martin Vigoureux, Barry Leiba, Eric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG comments. 11. Contributors Minei, et al. Expires February 2, 2020 [Page 25] Internet-Draft PCE association group August 2019 Stephane Litkowski Orange Email: stephane.litkowski@orange.com Xian Zhang Huawei Technologies F3-1-B RnD Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China Email: zhang.xian@huawei.com Mustapha Aissaoui Nokia Email: mustapha.aissaoui@nokia.com 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, . [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, . [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, October 2012, . Minei, et al. Expires February 2, 2020 [Page 26] Internet-Draft PCE association group August 2019 [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, . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . 12.2. Informative References [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, . [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, . Minei, et al. Expires February 2, 2020 [Page 27] Internet-Draft PCE association group August 2019 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, DOI 10.17487/RFC6007, September 2010, . [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep- yang-12 (work in progress), July 2019. [I-D.ietf-pce-stateful-path-protection] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., and M. Negi, "PCEP Extensions for Associating Working and Protection LSPs with Stateful PCE", draft-ietf-pce- stateful-path-protection-07 (work in progress), June 2019. [I-D.ietf-pce-association-diversity] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, "Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling", draft- ietf-pce-association-diversity-08 (work in progress), July 2019. Appendix A. Example for Operator-configured Association Range Consider an association type T1 (which allows both dynamic and operator-configured association with a default range of <0x1000, 0xffff>). Consider that, because of need of the network, the PCE needs to create more dynamic associations and would like to change the association range to <0xbffe, 0xffff> instead. During PCEP session establishment the PCE would advertise the new range, the PCC could skip advertising as the default values are used. If a PCC is creating a dynamic association (with PCC as association source) it needs to pick a free association identifier for type T1 in the range of <0x1, 0x0fff> whereas if a PCE is creating a dynamic association (with PCE as association source) it needs to pick a free association Minei, et al. Expires February 2, 2020 [Page 28] Internet-Draft PCE association group August 2019 identifier from the range <0x1, 0xbffd>. Similarly if an operator- configured association is manually configured with the PCC as association source, it should be from the range <0x1000, 0xffff> whereas if the PCE is association source, it should be from <0xbffe, 0xffff>. In case the association source is not a PCEP peer (for example an NMS system), then the default range of <0x1000, 0xffff> is considered. Authors' Addresses Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: inaminei@google.com Edward Crabbe Individual Contributor Email: edward.crabbe@gmail.com Siva Sivabalan Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 US Email: msiva@cisco.com Hariharan Ananthakrishnan Netflix Email: hari@netflix.com Dhruv Dhody Huawei Divyashree Techno Park, Whitefield Bangalore, KA 560066 India Email: dhruv.ietf@gmail.com Minei, et al. Expires February 2, 2020 [Page 29] Internet-Draft PCE association group August 2019 Yosuke Tanaka NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Email: yosuke.tanaka@ntt.com Minei, et al. Expires February 2, 2020 [Page 30] ./draft-ietf-rtcweb-overview-19.txt0000644000764400076440000015042613201762062016523 0ustar iustyiusty Network Working Group H. Alvestrand Internet-Draft Google Intended status: Standards Track November 12, 2017 Expires: May 16, 2018 Overview: Real Time Protocols for Browser-based Applications draft-ietf-rtcweb-overview-19 Abstract This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB 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 https://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, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Alvestrand Expires May 16, 2018 [Page 1] Internet-Draft WebRTC Overview November 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Principles and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Goals of this document . . . . . . . . . . . . . . . . . 4 2.2. Relationship between API and protocol . . . . . . . . . . 5 2.3. On interoperability and innovation . . . . . . . . . . . 7 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 3. Architecture and Functionality groups . . . . . . . . . . . . 8 4. Data transport . . . . . . . . . . . . . . . . . . . . . . . 12 5. Data framing and securing . . . . . . . . . . . . . . . . . . 13 6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Connection management . . . . . . . . . . . . . . . . . . . . 13 8. Presentation and control . . . . . . . . . . . . . . . . . . 14 9. Local system support functions . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. Changes from draft-alvestrand-dispatch-01 to draft- alvestrand-rtcweb-overview-00 . . . . . . . . . . . . . . 20 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . 20 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 21 A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview . . 21 A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview . . 21 A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview . . 21 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview . . 22 A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview . . 22 A.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 22 A.11. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 22 A.12. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 22 A.13. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 22 Alvestrand Expires May 16, 2018 [Page 2] Internet-Draft WebRTC Overview November 2017 A.14. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 22 A.15. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 23 A.16. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 23 A.17. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 23 A.18. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 23 A.19. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 23 A.20. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 23 A.21. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 24 A.22. Changes from -17 to -18 . . . . . . . . . . . . . . . . . 24 A.23. Changes from -18 to -19 . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The Internet was, from very early in its lifetime, considered a possible vehicle for the deployment of real-time, interactive applications - with the most easily imaginable being audio conversations (aka "Internet telephony") and video conferencing. The first attempts to build this were dependent on special networks, special hardware and custom-built software, often at very high prices or at low quality, placing great demands on the infrastructure. As the available bandwidth has increased, and as processors and other hardware has become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware. Still, there are a number of barriers to the ability to communicate universally - one of these is that there is, as of yet, no single set of communication protocols that all agree should be made available for communication; another is the sheer lack of universal identification systems (such as is served by telephone numbers or email addresses in other communications systems). Development of The Universal Solution has, however, proved hard. The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application". It turns out that as long as the browser platform has the necessary interfaces, it is possible to deliver almost any kind of service on it. Traditionally, these interfaces have been delivered by plugins, which had to be downloaded and installed separately from the browser; in the development of HTML5, application developers see much promise in the possibility of making those interfaces available in a standardized way within the browser. Alvestrand Expires May 16, 2018 [Page 3] Internet-Draft WebRTC Overview November 2017 This memo describes a set of building blocks that can be made accessible and controllable through a Javascript API in a browser, and which together form a sufficient set of functions to allow the use of interactive audio and video in applications that communicate directly between browsers across the Internet. The resulting protocol suite is intended to enable all the applications that are described as required scenarios in the use cases document [RFC7478]. Other efforts, for instance the W3C Web Real-Time Communications, Web Applications Security, and Device and Sensor working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions. This memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media. In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies using application-specific protocols. Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation [RFC3361] or through the transparent insertion of SIP Application Level Gateways (ALGs) -- will not work with such signaling. In the case of networks using cooperative endpoints, the approaches defined in [RFC8155] may serve as a suitable replacement for [RFC3361]. The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones. This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS. Applying the markings described in [I-D.ietf-tsvwg-rtcweb-qos] may be appropriate replacements for such techniques. This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts. 2. Principles and Terminology 2.1. Goals of this document The goal of the WebRTC protocol specification is to specify a set of protocols that, if all are implemented, will allow an implementation to communicate with another implementation using audio, video and data sent along the most direct possible path between the participants. Alvestrand Expires May 16, 2018 [Page 4] Internet-Draft WebRTC Overview November 2017 This document is intended to serve as the roadmap to the WebRTC specifications. It defines terms used by other parts of the WebRTC protocol specifications, lists references to other specifications that don't need further elaboration in the WebRTC context, and gives pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be possible to have all information needed to implement a WebRTC compatible implementation. 2.2. Relationship between API and protocol The total WebRTC effort consists of two major parts, each consisting of multiple documents: o A protocol specification, done in the IETF o A Javascript API specification, defined in a series of W3C documents [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628] Together, these two specifications aim to provide an environment where Javascript embedded in any page, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, as long as the browser supports this specification. The browser environment does not constrain the types of application in which this functionality can be used. The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for interoperation to know whether the entity one is communicating with is a browser or another device implementing this specification. The goal of cooperation between the protocol specification and the API specification is that for all options and features of the protocol specification, it should be clear which API calls to make to exercise that option or feature; similarly, for any sequence of API calls, it should be clear which protocol options and features will be invoked. Both subject to constraints of the implementation, of course. The following terms are used across the documents specifying the WebRTC suite, in the specific meanings given here. Not all terms are used in this document. Other terms are used in their commonly used meaning. Agent: Undefined term. See "SDP Agent" and "ICE Agent". Alvestrand Expires May 16, 2018 [Page 5] Internet-Draft WebRTC Overview November 2017 Application Programming Interface (API): A specification of a set of calls and events, usually tied to a programming language or an abstract formal specification such as WebIDL, with its defined semantics. Browser: Used synonymously with "Interactive User Agent" as defined in the HTML specification [W3C.WD-html5-20110525]. See also "WebRTC User Agent". Data Channel: An abstraction that allows data to be sent between WebRTC endpoints in the form of messages. Two endpoints can have multiple data channels between them. ICE Agent: An implementation of the Interactive Connectivity Establishment (ICE) [RFC5245] protocol. An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle [XEP-0166]). Interactive: Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/ observation is on the order of no more than hundreds of milliseconds. Media: Audio and video content. Not to be confused with "transmission media" such as wires. Media Path: The path that media data follows from one WebRTC endpoint to another. Protocol: A specification of a set of data units, their representation, and rules for their transmission, with their defined semantics. A protocol is usually thought of as going between systems. Real-time Media: Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds). Real-time media can be used to support interactive communication. SDP Agent: The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in [RFC3264] section 3. Signaling: Communication that happens in order to establish, manage and control media paths and data paths. Alvestrand Expires May 16, 2018 [Page 6] Internet-Draft WebRTC Overview November 2017 Signaling Path: The communication channels used between entities participating in signaling to transfer signaling. There may be more entities in the signaling path than in the media path. WebRTC Browser: (also called a WebRTC User Agent or WebRTC UA) Something that conforms to both the protocol specification and the Javascript API cited above. WebRTC non-Browser: Something that conforms to the protocol specification, but does not claim to implement the Javascript API. This can also be called a "WebRTC device" or "WebRTC native application". WebRTC Endpoint: Either a WebRTC browser or a WebRTC non-browser. It conforms to the protocol specification. WebRTC-compatible Endpoint: An endpoint that is able to successfully communicate with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. WebRTC Gateway: A WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities. All WebRTC browsers are WebRTC endpoints, so any requirement on a WebRTC endpoint also applies to a WebRTC browser. A WebRTC non-browser may be capable of hosting applications in a similar way to the way in which a browser can host Javascript applications, typically by offering APIs in other languages. For instance it may be implemented as a library that offers a C++ API intended to be loaded into applications. In this case, similar security considerations as for Javascript may be needed; however, since such APIs are not defined or referenced here, this document cannot give any specific rules for those interfaces. WebRTC gateways are described in a separate document, [I-D.ietf-rtcweb-gateways]. 2.3. On interoperability and innovation The "Mission statement of the IETF" [RFC3935] states that "The benefit of a standard to the Internet is in interoperability - that Alvestrand Expires May 16, 2018 [Page 7] Internet-Draft WebRTC Overview November 2017 multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users." Communication on the Internet frequently occurs in two phases: o Two parties communicate, through some mechanism, what functionality they both are able to support o They use that shared communicative functionality to communicate, or, failing to find anything in common, give up on communication. There are often many choices that can be made for communicative functionality; the history of the Internet is rife with the proposal, standardization, implementation, and success or failure of many types of options, in all sorts of protocols. The goal of having a mandatory to implement function set is to prevent negotiation failure, not to preempt or prevent negotiation. The presence of a mandatory to implement function set serves as a strong changer of the marketplace of deployment - in that it gives a guarantee that, as long as you conform to a specification, and the other party is willing to accept communication at the base level of that specification, you can communicate successfully. The alternative, that is having no mandatory to implement, does not mean that you cannot communicate, it merely means that in order to be part of the communications partnership, you have to implement the standard "and then some". The "and then some" is usually called a profile of some sort; in the version most antithetical to the Internet ethos, that "and then some" consists of having to use a specific vendor's product only. 2.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]. 3. Architecture and Functionality groups For browser-based applications, the model for real-time support does not assume that the browser will contain all the functions needed for an application such as a telephone or a video conference. The vision is that the browser will have the functions needed for a Web application, working in conjunction with its backend servers, to implement these functions. Alvestrand Expires May 16, 2018 [Page 8] Internet-Draft WebRTC Overview November 2017 This means that two vital interfaces need specification: The protocols that browsers use to talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. +------------------------+ On-the-wire | | Protocols | Servers |---------> | | | | +------------------------+ ^ | | | HTTPS/ | WebSockets | | +----------------------------+ | Javascript/HTML/CSS | +----------------------------+ Other ^ ^ RTC APIs | | APIs +---|-----------------|------+ | | | | | +---------+| | | Browser || On-the-wire | Browser | RTC || Protocols | | Function|-----------> | | || | | || | +---------+| +---------------------|------+ | V Native OS Services Figure 1: Browser Model Alvestrand Expires May 16, 2018 [Page 9] Internet-Draft WebRTC Overview November 2017 Note that HTTPS and WebSockets are also offered to the Javascript application through browser APIs. As for all protocol and API specifications, there is no restriction that the protocols can only be used to talk to another browser; since they are fully specified, any endpoint that implements the protocols faithfully should be able to interoperate with the application running in the browser. A commonly imagined model of deployment is the one depicted below. In the figure below JS is Javascript. +-----------+ +-----------+ | Web | | Web | | | Signaling | | | |-------------| | | Server | path | Server | | | | | +-----------+ +-----------+ / \ / \ Application-defined / \ over / \ HTTPS/WebSockets / Application-defined over \ / HTTPS/WebSockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | +-----------+ +-----------+ Figure 2: Browser RTC Trapezoid On this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be conformant to the specifications of the WebRTC protocol suite; the signaling path ("high path") goes via servers that can modify, translate or manipulate the signals as needed. If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by Alvestrand Expires May 16, 2018 [Page 10] Internet-Draft WebRTC Overview November 2017 standardization or by other means of agreement. Existing protocols (e.g. SIP [RFC3261] or XMPP [RFC6120]) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g. SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server. Similarly, if both operators' servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over WebSockets or BOSH [XEP-0124] or a proprietary signaling mechanism used between the application running in the browser and the web server. The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document. The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: o Data transport: such as TCP, UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: congestion management, bandwidth estimation and so on. o Data framing: RTP, SCTP, DTLS, and other data formats that serve as containers, and their functions for data confidentiality and integrity. o Data formats: Codec specifications, format specifications and functionality specifications for the data passed between systems. Audio and video codecs, as well as formats for data and document sharing, belong in this category. In order to make use of data formats, a way to describe them, a session description, is needed. o Connection management: Setting up connections, agreeing on data formats, changing data formats during the duration of a call; SDP, SIP, and Jingle/XMPP belong in this category. o Presentation and control: What needs to happen in order to ensure that interactions behave in a non-surprising manner. This can include floor control, screen layout, voice activated image switching and other such functions - where part of the system require the cooperation between parties. XCON and Cisco/ Alvestrand Expires May 16, 2018 [Page 11] Internet-Draft WebRTC Overview November 2017 Tandberg's TIP were some attempts at specifying this kind of functionality; many applications have been built without standardized interfaces to these functions. o Local system support functions: These are things that need not be specified uniformly, because each participant may choose to do these in a way of the participant's choosing, without affecting the bits on the wire in a way that others have to be cognizant of. Examples in this category include echo cancellation (some forms of it), local authentication and authorization mechanisms, OS access control and the ability to do local recording of conversations. Within each functionality group, it is important to preserve both freedom to innovate and the ability for global communication. Freedom to innovate is helped by doing the specification in terms of interfaces, not implementation; any implementation able to communicate according to the interfaces is a valid implementation. Ability to communicate globally is helped both by having core specifications be unencumbered by IPR issues and by having the formats and protocols be fully enough specified to allow for independent implementation. One can think of the three first groups as forming a "media transport infrastructure", and of the three last groups as forming a "media service". In many contexts, it makes sense to use a common specification for the media transport infrastructure, which can be embedded in browsers and accessed using standard interfaces, and "let a thousand flowers bloom" in the "media service" layer; to achieve interoperable services, however, at least the first five of the six groups need to be specified. 4. Data transport Data transport refers to the sending and receiving of data over the network interfaces, the choice of network-layer addresses at each end of the communication, and the interaction with any intermediate entities that handle the data, but do not modify it (such as TURN relays). It includes necessary functions for congestion control, retransmission, and in-order delivery. WebRTC endpoints MUST implement the transport protocols described in [I-D.ietf-rtcweb-transports]. Alvestrand Expires May 16, 2018 [Page 12] Internet-Draft WebRTC Overview November 2017 5. Data framing and securing The format for media transport is RTP [RFC3550]. Implementation of SRTP [RFC3711] is REQUIRED for all implementations. The detailed considerations for usage of functions from RTP and SRTP are given in [I-D.ietf-rtcweb-rtp-usage]. The security considerations for the WebRTC use case are in [I-D.ietf-rtcweb-security], and the resulting security functions are described in [I-D.ietf-rtcweb-security-arch]. Considerations for the transfer of data that is not in RTP format is described in [I-D.ietf-rtcweb-data-channel], and a supporting protocol for establishing individual data channels is described in [I-D.ietf-rtcweb-data-protocol]. WebRTC endpoints MUST implement these two specifications. WebRTC endpoints MUST implement [I-D.ietf-rtcweb-rtp-usage], [I-D.ietf-rtcweb-security], [I-D.ietf-rtcweb-security-arch], and the requirements they include. 6. Data formats The intent of this specification is to allow each communications event to use the data formats that are best suited for that particular instance, where a format is supported by both sides of the connection. However, a minimum standard is greatly helpful in order to ensure that communication can be achieved. This document specifies a minimum baseline that will be supported by all implementations of this specification, and leaves further codecs to be included at the will of the implementor. WebRTC endpoints that support audio and/or video MUST implement the codecs and profiles required in [RFC7874] and [RFC7742]. 7. Connection management The methods, mechanisms and requirements for setting up, negotiating and tearing down connections is a large subject, and one where it is desirable to have both interoperability and freedom to innovate. The following principles apply: 1. The WebRTC media negotiations will be capable of representing the same SDP offer/answer semantics [RFC3264] that are used in SIP, in such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation. Alvestrand Expires May 16, 2018 [Page 13] Internet-Draft WebRTC Overview November 2017 2. It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms, codecs and security mechanisms without using a media gateway. A signaling gateway to convert between the signaling on the web side to the SIP signaling may be needed. 3. When an SDP for a new codec is specified, no other standardization should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in [I-D.ietf-rtcweb-jsep]. WebRTC browsers MUST implement [I-D.ietf-rtcweb-jsep]. WebRTC endpoints MUST implement the functions described in that document that relate to the network layer (e.g. Bundle [I-D.ietf-mmusic-sdp-bundle-negotiation], RTCP-mux [RFC5761] and Trickle ICE [I-D.ietf-ice-trickle]), but do not need to support the API functionality described there. 8. Presentation and control The most important part of control is the user's control over the browser's interaction with input/output devices and communications channels. It is important that the user have some way of figuring out where his audio, video or texting is being sent, for what purported reason, and what guarantees are made by the parties that form part of this control channel. This is largely a local function between the browser, the underlying operating system and the user interface; this is specified in the peer connection API [W3C.WD-webrtc-20120209], and the media capture API [W3C.WD-mediacapture-streams-20120628]. WebRTC browsers MUST implement these two specifications. 9. Local system support functions These are characterized by the fact that the quality of these functions strongly influence the user experience, but the exact algorithm does not need coordination. In some cases (for instance echo cancellation, as described below), the overall system definition Alvestrand Expires May 16, 2018 [Page 14] Internet-Draft WebRTC Overview November 2017 may need to specify that the overall system needs to have some characteristics for which these facilities are useful, without requiring them to be implemented a certain way. Local functions include echo cancellation, volume control, camera management including focus, zoom, pan/tilt controls (if available), and more. One would want to see certain parts of the system conform to certain properties, for instance: o Echo cancellation should be good enough to achieve the suppression of acoustical feedback loops below a perceptually noticeable level. o Privacy concerns MUST be satisfied; for instance, if remote control of camera is offered, the APIs should be available to let the local participant figure out who's controlling the camera, and possibly decide to revoke the permission for camera usage. o Automatic gain control, if present, should normalize a speaking voice into a reasonable dB range. The requirements on WebRTC systems with regard to audio processing are found in [RFC7874] and includes more guidance about echo cancellation and AGC; the proposed API for control of local devices are found in [W3C.WD-mediacapture-streams-20120628]. WebRTC endpoints MUST implement the processing functions in [RFC7874]. (Together with the requirement in Section 6, this means that WebRTC endpoints MUST implement the whole document.) 10. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 11. Security Considerations Security of the web-enabled real time communications comes in several pieces: o Security of the components: The browsers, and other servers involved. The most target-rich environment here is probably the browser; the aim here should be that the introduction of these components introduces no additional vulnerability. Alvestrand Expires May 16, 2018 [Page 15] Internet-Draft WebRTC Overview November 2017 o Security of the communication channels: It should be easy for a participant to reassure himself of the security of his communication - by verifying the crypto parameters of the links he himself participates in, and to get reassurances from the other parties to the communication that they promise that appropriate measures are taken. o Security of the partners' identity: verifying that the participants are who they say they are (when positive identification is appropriate), or that their identity cannot be uncovered (when anonymity is a goal of the application). The security analysis, and the requirements derived from that analysis, is contained in [I-D.ietf-rtcweb-security]. It is also important to read the security sections of [W3C.WD-mediacapture-streams-20120628] and [W3C.WD-webrtc-20120209]. 12. Acknowledgements The number of people who have taken part in the discussions surrounding this draft are too numerous to list, or even to identify. The ones below have made special, identifiable contributions; this does not mean that others' contributions are less important. Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus Westerlund and Joerg Ott, who offered technical contributions on various versions of the draft. Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for the ASCII drawings in section 1. Thanks to Alissa Cooper, Bjoern Hoehrmann, Colin Perkins, Colton Shields, Eric Rescorla, Heath Matlock, Henry Sinnreich, Justin Uberti, Keith Drage, Magnus Westerlund, Olle E. Johansson, Sean Turner and Simon Leinen for document review. 13. References 13.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. Alvestrand Expires May 16, 2018 [Page 16] Internet-Draft WebRTC Overview November 2017 [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "JavaScript Session Establishment Protocol", draft-ietf-rtcweb-jsep-24 (work in progress), October 2017. [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-26 (work in progress), March 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-09 (work in progress), October 2017. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-13 (work in progress), October 2017. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-17 (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, . [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, . [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, . Alvestrand Expires May 16, 2018 [Page 17] Internet-Draft WebRTC Overview November 2017 [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, . [RFC7742] Roach, A., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, . [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, . [W3C.WD-mediacapture-streams-20120628] Burnett, D. and A. Narayanan, "Media Capture and Streams", World Wide Web Consortium WD WD-mediacapture-streams- 20120628, June 2012, . [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, . 13.2. Informative References [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-14 (work in progress), September 2017. [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-39 (work in progress), August 2017. [I-D.ietf-rtcweb-gateways] Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways", draft-ietf-rtcweb-gateways-02 (work in progress), January 2016. Alvestrand Expires May 16, 2018 [Page 18] Internet-Draft WebRTC Overview November 2017 [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-18 (work in progress), August 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, . [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, DOI 10.17487/RFC3361, August 2002, . [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays around NAT (TURN) Server Auto Discovery", RFC 8155, DOI 10.17487/RFC8155, April 2017, . [W3C.WD-html5-20110525] Hickson, I., "HTML5", World Wide Web Consortium LastCall WD-html5-20110525, May 2011, . [XEP-0124] Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., Stout, L., and W. Tilanus, "BOSH", XSF XEP 0124, November 2016. Alvestrand Expires May 16, 2018 [Page 19] Internet-Draft WebRTC Overview November 2017 [XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, "Jingle", XSF XEP 0166, June 2007. Appendix A. Change log This section may be deleted by the RFC Editor when preparing for publication. A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 Added section "On interoperability and innovation" Added data confidentiality and integrity to the "data framing" layer Added congestion management requirements in the "data transport" layer section Changed need for non-media data from "question: do we need this?" to "Open issue: How do we do this?" Strengthened disclaimer that listed codecs are placeholders, not decisions. More details on why the "local system support functions" section is there. A.2. Changes from draft-alvestrand-dispatch-01 to draft-alvestrand- rtcweb-overview-00 Added section on "Relationship between API and protocol" Added terminology section Mentioned congestion management as part of the "data transport" layer in the layer list A.3. Changes from draft-alvestrand-rtcweb-00 to -01 Removed most technical content, and replaced with pointers to drafts as requested and identified by the RTCWEB WG chairs. Added content to acknowledgments section. Added change log. Spell-checked document. Alvestrand Expires May 16, 2018 [Page 20] Internet-Draft WebRTC Overview November 2017 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to draft-ietf- rtcweb-overview-00 Changed draft name and document date. Removed unused references A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview Added architecture figures to section 2. Changed the description of "echo cancellation" under "local system support functions". Added a few more definitions. A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview Added pointers to use cases, security and rtp-usage drafts (now WG drafts). Changed description of SRTP from mandatory-to-use to mandatory-to- implement. Added the "3 principles of negotiation" to the connection management section. Added an explicit statement that ICE is required for both NAT and consent-to-receive. A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview Added references to a number of new drafts. Expanded the description text under the "trapezoid" drawing with some more text discussed on the list. Changed the "Connection management" sentence from "will be done using SDP offer/answer" to "will be capable of representing SDP offer/ answer" - this seems more consistent with JSEP. Added "security mechanisms" to the things a non-gatewayed SIP devices must support in order to not need a media gateway. Added a definition for "browser". Alvestrand Expires May 16, 2018 [Page 21] Internet-Draft WebRTC Overview November 2017 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview Made introduction more normative. Several wording changes in response to review comments from EKR Added an appendix to hold references and notes that are not yet in a separate document. A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview Minor grammatical fixes. This is mainly a "keepalive" refresh. A.10. Changes from -05 to -06 Clarifications in response to Last Call review comments. Inserted reference to draft-ietf-rtcweb-audio. A.11. Changes from -06 to -07 Added a reference to the "unified plan" draft, and updated some references. Otherwise, it's a "keepalive" draft. A.12. Changes from -07 to -08 Removed the appendix that detailed transports, and replaced it with a reference to draft-ietf-rtcweb-transports. Removed now-unused references. A.13. Changes from -08 to -09 Added text to the Abstract indicating that the intended status is an Applicability Statement. A.14. Changes from -09 to -10 Defined "WebRTC Browser" and "WebRTC device" as things that do, or don't, conform to the API. Updated reference to data-protocol draft Updated data formats to reference -rtcweb-audio- and not the expired -cbran draft. Deleted references to -unified-plan Alvestrand Expires May 16, 2018 [Page 22] Internet-Draft WebRTC Overview November 2017 Deleted reference to -generic-idp (draft expired) Added notes on which referenced documents WebRTC browsers or devices MUST conform to. Added pointer to the security section of the API drafts. A.15. Changes from -10 to -11 Added "WebRTC Gateway" as a third class of device, and referenced the doc describing them. Made a number of text clarifications in response to document reviews. A.16. Changes from -11 to -12 Refined entity definitions to define "WebRTC endpoint" and "WebRTC- compatible endpoint". Changed remaining usage of the term "RTCWEB" to "WebRTC", including in the page header. A.17. Changes from -12 to -13 Changed "WebRTC device" to be "WebRTC non-browser", per decision at IETF 91. This led to the need for "WebRTC endpoint" as the common label for both, and the usage of that term in the rest of the document. Added words about WebRTC APIs in languages other than Javascript. Referenced draft-ietf-rtcweb-video for video codecs to support. A.18. Changes from -13 to -14 None. This is a "keepalive" update. A.19. Changes from -14 to -15 Changed "gateways" reference to point to the WG document. A.20. Changes from -15 to -16 None. This is a "keepalive" publication. Alvestrand Expires May 16, 2018 [Page 23] Internet-Draft WebRTC Overview November 2017 A.21. Changes from -16 to -17 Addressed review comments by Olle E. Johansson and Magnus Westerlund A.22. Changes from -17 to -18 Addressed review comments from Sean Turner and Alissa Cooper A.23. Changes from -18 to -19 A number of grammatical issues were fixed. Added note on operational impact of WebRTC. Unified all definitions into the definitions list. Added a reference for BOSH. Changed ICE reference from 5245bis to RFC 5245. Author's Address Harald T. Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Alvestrand Expires May 16, 2018 [Page 24] ./draft-ietf-pce-hierarchy-extensions-11.txt0000644000764400076440000020576413474532547020326 0ustar iustyiusty PCE Working Group F. Zhang Internet-Draft Q. Zhao Intended status: Standards Track Huawei Expires: December 2, 2019 O. Gonzalez de Dios Telefonica I+D R. Casellas CTTC D. King Old Dog Consulting June 1, 2019 Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) draft-ietf-pce-hierarchy-extensions-11 Abstract The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. This document defines extensions to the Path Computation Element Protocol (PCEP) to support Hierarchical PCE procedures. 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 https://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, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires December, 2019 [Page 1] Internet-Draft PCEP Extensions for H-PCE June 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . .5 1.3. Requirements Language . . . . . . . . . . . . . . . . . .5 2. Requirements for H-PCE . . . . . . . . . . . . . . . . . . .5 2.1. Path Computation Request . . . . . . . . . . . . . . . .6 2.1.1. Qualification of PCEP Requests . . . . . . . . . . .6 2.1.2. Multi-domain Objective Functions . . . . . . . . . .6 2.1.3. Multi-domain Metrics . . . . . . . . . . . . . . . .7 2.2. Parent PCE Capability Advertisement . . . . . . . . . . .7 2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7 2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .8 3.1 Applicability to PCC-PCE Communications . . . . . . . . .8 3.2. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8 3.2.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8 3.2.1.1 Backwards Compatibility . . . . . . . . . . . . . . .9 3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10 3.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . .11 3.3.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .11 3.3.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .12 3.4. Objective Functions . . . . . . . . . . . . . . . . . . .12 3.4.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .12 3.4.2. OF Object . . . . . . . . . . . . . . . . . . . . . .13 3.5. Metric Object . . . . . . . . . . . . . . . . . . . . . .14 3.6. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .15 3.7. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . .15 3.7.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .15 3.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .16 4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .16 4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .16 4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .17 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .17 6. Manageability Considerations . . . . . . . . . . . . . . . .18 6.1. Control of Function and Policy . . . . . . . . . . . . .18 6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .18 6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . . Zhang, et al. Expires December, 2019 [Page 2] Internet-Draft PCEP Extensions for H-PCE June 2019 6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .19 6.2. Information and Data Models . . . . . . . . . . . . . . .19 6.3. Liveness Detection and Monitoring . . . . . . . . . . . .20 6.4. Verify Correct Operations . . . . . . . . . . . . . . . .20 6.5. Requirements On Other Protocols . . . . . . . . . . . . .20 6.6. Impact On Network Operations . . . . . . . . . . . . . .20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .20 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .20 7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .21 7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .21 7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .22 7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .22 7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .22 7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .23 7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .23 7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .24 7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .24 8. Security Considerations . . . . . . . . . . . . . . . . . . .24 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . .24 10.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .25 11. References . . . . . . . . . . . . . . . . . . . . . . . . .25 11.1. Normative References . . . . . . . . . . . . . . . . . .25 11.2. Informative References . . . . . . . . . . . . . . . . .25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .28 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 A1. Implementation Status . . . . . . . . . . . . . . . . . . .28 A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .29 A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .30 A1.3. H-PCE Proof of Concept developed by Huawei . . . . . . .31 1. Introduction The Path Computation Element communication Protocol (PCEP) provides a mechanism for Path Computation Elements (PCEs) and Path Computation Clients (PCCs) to exchange requests for path computation and responses that provide computed paths. The capability to compute the routes of end-to-end inter-domain MPLS Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) is expressed as requirements in [RFC4105] and [RFC4216]. This capability may be realized by a PCE [RFC4655]. The methods for establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in [RFC4726]. [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can be used for computing end-to-end paths for inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs). Zhang, et al. Expires December, 2019 [Page 3] Internet-Draft PCEP Extensions for H-PCE June 2019 Within the hierarchical PCE architecture, the parent PCE is used to compute a multi-domain path based on the domain connectivity information. A child PCE may be responsible for single or multiple domains and is used to compute the intra-domain path based on its own domain topology information. The H-PCE end-to-end domain path computation procedure is described below: o A path computation client (PCC) sends the inter-domain path computation requests to the child PCE responsible for its domain; o The child PCE forwards the request to the parent PCE; o The parent PCE computes the likely domain paths from the ingress domain to the egress domain; o The parent PCE sends the intra-domain path computation requests (between the domain border nodes) to the child PCEs which are responsible for the domains along the domain path; o The child PCEs return the intra-domain paths to the parent PCE; o The parent PCE constructs the end-to-end inter-domain path based on the intra-domain paths; o The parent PCE returns the inter-domain path to the child PCE; o The child PCE forwards the inter-domain path to the PCC. The parent PCE may be requested to provide only the sequence of domains to a child PCE so that alternative inter-domain path computation procedures, including Per Domain (PD) [RFC5152] and Backwards Recursive Path Computation (BRPC) [RFC5441], may be used. This document defines the PCEP extensions for the purpose of implementing Hierarchical PCE procedures, which are described in [RFC6805]. 1.1. Scope The following functions are out of scope of this document: o Determination of Destination Domain (section 4.5 of [RFC6805]): * via a collection of reachability information from child domain; * via requests to the child PCEs to discover if they contain the Zhang, et al. Expires December, 2019 [Page 4] Internet-Draft PCEP Extensions for H-PCE June 2019 destination node; * or any other methods. o Parent Traffic Engineering Database (TED) methods (section 4.4 of [RFC6805]), although suitable mechanisms include: * YANG-based management interfaces; * BGP-LS [RFC7752]; * Future extension to PCEP (such as [I-D.dhodylee-pce-pcep-ls]). o Learning of Domain connectivity and boundary nodes (BN) addresses, methods to achieve this function include: * YANG-based management interfaces; * BGP-LS [RFC7752]; * Future extension to PCEP (such as [I-D.dhodylee-pce-pcep-ls]). o Stateful PCE Operations (Refer [I-D.ietf-pce-stateful-hpce]) o Applicability of hierarchical PCE to large multi-domain environments. * The hierarchical relationship model is described in [RFC6805]. It is applicable to environments with small groups of domains where visibility from the ingress LSRs is limited. As highlighted in [RFC7399] applying the hierarchical PCE model to very large groups of domains, such as the Internet, is not considered feasible or desirable. 1.2. Terminology This document uses the terminology defined in [RFC4655], [RFC5440] and the additional terms defined in Section 1.4 of [RFC6805]. 1.3. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Requirements for H-PCE Zhang, et al. Expires December, 2019 [Page 5] Internet-Draft PCEP Extensions for H-PCE June 2019 This section compiles the set of requirements to the PCEP extensions to support the H-PCE architecture and procedures. [RFC6805] identifies high-level requirements of PCEP extensions required to support the hierarchical PCE model. 2.1. Path Computation Request The Path Computation Request (PCReq) [RFC5440] messages are used by a PCC or a PCE to make a path computation request to a PCE. In order to achieve the full functionality of the H-PCE procedures, the PCReq message needs to include: o Qualification of PCE Requests (Section 4.8.1. of [RFC6805]); o Multi-domain Objective Functions (OF); o Multi-domain Metrics. 2.1.1. Qualification of PCEP Requests As described in Section 4.8.1 of [RFC6805], the H-PCE architecture introduces new request qualifications, which are: o The ability for a child PCE to indicate that a path computation request sent to a parent PCE should be satisfied by a domain sequence only, that is, not by a full end-to-end path. This allows the child PCE to initiate a per-domain (PD) [RFC5152] or a backward recursive path computation (BRPC) [RFC5441]. o As stated in [RFC6805], Section 4.5, if a PCC knows the egress domain, it can supply this information as the path computation request. The PCC may also want to specify the destination domain information in a PCEP request, if it is known. o An inter domain path computed by parent PCE should be capable of disallowing specific domain re-entry. 2.1.2. Multi-domain Objective Functions For H-PCE inter-domain path computation, there are three new Objective Functions defined in this document: o Minimize the number of Transit Domains (MTD) o Minimize the number of border nodes (MBN) o Minimize the number of Common Transit Domains (MCTD) The PCC may specify the multi-domain Objective Function code to use when requesting inter-domain path computation, it may also Zhang, et al. Expires December, 2019 [Page 6] Internet-Draft PCEP Extensions for H-PCE June 2019 include intra-domain OFs, such as Minimum Cost Path (MCP) [RFC5441], which must be considered by participating child PCEs. 2.1.3. Multi-domain Metrics For inter-domain path computation, there are several path metrics of interest. o Domain count (number of domains crossed); o Border Node count. A PCC may be able to limit the number of domains crossed by applying a limit on these metrics. Details in Section 3.4. 2.2. Parent PCE Capability Advertisement A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes to use the procedures described in this document must advertise the fact and negotiate its role with its PCEP peers. It does this using the "H-PCE Capability" TLV, described in Section 3.2.1, in the OPEN Object to advertise its support for PCEP extensions for H-PCE Capability. During the PCEP session establishment procedure, the child PCE needs to be capable of indicating to the parent PCE whether it requests the parent PCE capability or not. 2.3. PCE Domain Identification A PCE domain is a single domain with an associated PCE. Although it is possible for a PCE to manage multiple domains simultaneously. The PCE domain could be an IGP area or AS. The PCE domain identifiers MAY be provided during the PCEP session establishment procedure. 2.4. Domain Diversity In a multi-domain environment, Domain Diversity is defined in [RFC6805] and described as "A pair of paths are domain-diverse if they do not transit any of the same domains. A pair of paths that share a common ingress and egress are domain-diverse if they only share the same domains at the ingress and egress (the ingress and egress domains). Domain diversity may be maximized for a pair of paths by selecting paths that have the smallest number of shared domains." Zhang, et al. Expires December, 2019 [Page 7] Internet-Draft PCEP Extensions for H-PCE June 2019 The main motivation behind domain diversity is to avoid fate sharing, but it can also be because of some geo-political reasons and commercial relationships that would require domain diversity. For example, a pair of paths should choose different transit Autonomous System (AS) because of some policy considerations. In the case when full domain diversity could not be achieved, it is helpful to minimize the commonly shared domains. Also, it is interesting to note that other scope of diversity (node, link, SRLG etc.) can still be applied inside the commonly shared domains. 3. PCEP Extensions This section defines extensions to PCEP [RFC5440] to support the H-PCE procedures. 3.1 Applicability to PCC-PCE Communications Although the extensions defined in this document are intended primarily for use between a child PCE and a parent PCE, they are also applicable for communications between a PCC and its PCE. Thus, the information that may be encoded in a PCReq can be sent from a PCC towards the child PCE. This includes the RP object (Section 3.3) and the Objective Function (OF) codes and objects (Section 3.4). A PCC and a child PCE could also exchange the capability (Section 3.2.1) during its session. This allows a PCC to request paths that transit multiple domains utilizing the capabilities defined in this document. 3.2. OPEN Object Two new TLVs are defined in this document to be carried within an OPEN object. This way, during the PCEP session establishment, the H-PCE capability and Domain information can be advertised. 3.2.1. H-PCE Capability TLV The H-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN Object [RFC5440] to exchange H-PCE capability of PCEP speakers. Its format is shown in the following figure: Zhang, et al. Expires December, 2019 [Page 8] Internet-Draft PCEP Extensions for H-PCE June 2019 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= TBD1 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |P| +---------------------------------------------------------------+ Figure 1: H-PCE-CAPABILITY TLV format The type of the TLV is TBD1 (to be assigned by IANA), and it has a fixed length of 4 octets. The value comprises a single field - Flags (32 bits): P (Parent PCE Request bit): if set, will signal that the child PCE wishes to use the peer PCE as a parent PCE. Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt. The inclusion of this TLV in an OPEN object indicates that the H-PCE extensions are supported by the PCEP speaker. The child PCE MUST include this TLV and set the P flag. The parent PCE MUST include this TLV and unset the P flag. The setting of the P flag (parent PCE request bit) would mean that the PCEP speaker wants the peer to be a parent PCE, so in the case of a PCC to Child-PCE relationship, neither entity would set the P flag. If both peers attempt to set the P flag then the session establishment MUST fail, and the PCEP speaker MUST respond with PCErr message using Error-Type 1: "PCEP Session Establishment Failure" as per [RFC5440]. If the PCE understands the H-PCE path computation request but did not advertise its H-PCE capability, it MUST send a PCErr message with Error-Type=TBD8 ("H-PCE error") and Error-Value=1 ("H-PCE Capability not advertised"). 3.2.1.1 Backwards Compatibility Section 7.1 of [RFC5440] requires that "Unrecognized TLVs MUST be ignored. That means that a PCE that does not support this document but that receives an Open Message containing an Open Object that includes Zhang, et al. Expires December, 2019 [Page 9] Internet-Draft PCEP Extensions for H-PCE June 2019 an H-PCE-CAPABILITIES TLV will ignore that TLV and will continue to attempt to establish a PCEP session. It will, however, not include the TLV in the Open message that it sends, so the H-PCE relationship will not be created. If a PCE does not support the extensions defined in this document but receives them in a PCEP message (notwithstanding the fact that the session was not established as supporting a H-PCE relationship), the receiving PCE will ignore the H-PCE related parameters because they are all encoded in TLVs within standard PCEP objects. 3.2.2. Domain-ID TLV The Domain-ID TLV, when used in the OPEN object, identifies the domains served by the PCE. The child PCE uses this mechanism to inform the domain information to the parent PCE. The Domain-ID TLV is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type= TBD2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Domain ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Domain-ID TLV format The type of the TLV is TBD2 (to be assigned by IANA), and it has a variable Length of the value portion. The value part comprises: Domain Type (8 bits): Indicates the domain type. Four types of domain are currently defined: * Type=1: the Domain ID field carries a 2-byte AS number. Padded with trailing zeros to a 4-byte boundary. * Type=2: the Domain ID field carries a 4-byte AS number. * Type=3: the Domain ID field carries a 4-byte OSPF area ID. * Type=4: the Domain ID field carries (2-byte Area-Len, variable length IS-IS area ID). Padded with trailing zeros to a 4-byte Zhang, et al. Expires December, 2019 [Page 10] Internet-Draft PCEP Extensions for H-PCE June 2019 boundary. Reserved: Zero at transmission; ignored at the receipt. Domain ID (variable): Indicates an IGP Area ID or AS number as per the Domain Type field. It can be 2 bytes, 4 bytes or variable length depending on the domain identifier used. It is padded with trailing zeros to a 4-byte boundary. In case of IS-IS it includes the Area-Len as well. In the case a PCE serves more than one domain, multiple Domain-ID TLVs are included for each domain it serves. 3.3. RP Object 3.3.1. H-PCE-FLAG TLV The H-PCE-FLAG TLV is an optional TLV associated with the RP Object [RFC5440] to indicate the H-PCE path computation request and options. Its format is shown in the following figure: 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= TBD3 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |D|S| +---------------------------------------------------------------+ Figure 3: H-PCE-FLAG TLV format The type of the TLV is TBD3 (to be assigned by IANA), and it has a fixed length of 4 octets. The value comprises a single field - Flags (32 bits): S (Domain Sequence bit): if set, will signal that the child PCE wishes to get only the domain sequence in the path computation reply. Refer to Section 3.7 of [RFC7897] for details. D (Disallow Domain Re-entry bit): if set, will signal that the computed path does not enter a domain more than once. Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt. The presence of the TLV indicates that the H-PCE based path Zhang, et al. Expires December, 2019 [Page 11] Internet-Draft PCEP Extensions for H-PCE June 2019 computation is requested as per this document. 3.3.2. Domain-ID TLV The Domain-ID TLV, carried in an OPEN object, is used to indicate a (list of) managed domains and is described in Section 3.3.1. This TLV, when carried in an RP object, indicates the destination domain ID. If a PCC knows the egress domain, it can supply this information in the PCReq message. The format and procedure of this TLV are defined in Section 3.2.2. If a Domain-id TLV is used in the RP object, and the destination is not actually in the indicated domain, then the parent PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV should be used. A new bit number is assigned to indicate "Destination not found in the indicated domain" (see Section 3.7). 3.4. Objective Functions 3.4.1. OF Codes [RFC5541] defines a mechanism to specify an Objective Function that is used by a PCE when it computes a path. Three new Objective Functions are defined for H-PCE, these are: o MTD * Name: Minimize the number of Transit Domains (MTD) * Objective Function Code - TBD4 (to be assigned by IANA) * Description: Find a path P such that it passes through the least number of transit domains. * Objective functions are formulated using the following terminology: + A network comprises a set of N domains {Di, (i=1...N)}. + A path P passes through K unique domains {Dpi,(i=1...K)}. + Find a path P such that the value of K is minimized. o MBN * Name: Minimize the number of border nodes. * Objective Function Code - TBD5 (to be assigned by IANA) Zhang, et al. Expires December, 2019 [Page 12] Internet-Draft PCEP Extensions for H-PCE June 2019 * Description: Find a path P such that it passes through the least number of border nodes. * Objective functions are formulated using the following terminology: + A network comprises a set of N links {Li, (i=1...N)}. + A path P is a list of K links {Lpi,(i=1...K)}. + D(Lpi) if a function that determines if the links Lpi and Lpi+1 belong to different domains, D(Li) = 1 if link Li and Li+1 belong to different domains, D(Lk) = 0 if link Lk and Lk+1 belong to the same domain. + The number of border node in a path P is denoted by B(P), where B(P) = sum{D(Lpi),(i=1...K-1)}. + Find a path P such that B(P) is minimized. There is one objective function that applies to a set of synchronized path computation requests to increase the domain diversity: o MCTD * Name: Minimize the number of Common Transit Domains * Objective Function Code - TBD13 (to be assigned by IANA) * Description: Find a set of paths such that it passes through the least number of common transit domains. + A network comprises a set of N domains {Di, (i=1...N)}. + A path P passes through K unique domains {Dpi,(i=1...K)}. + A set of paths {P1...Pm} have L transit domains that are common to more than one path {Dpi,(i=1...L)}. + Find a set of paths such that the value of L is minimized. 3.4.2. OF Object The OF (Objective Function) object [RFC5541] is carried within a PCReq message so as to indicate the desired/required objective function to be applied by the PCE during path computation. As per Section 3.2 of [RFC5541] a single OF object may be included in a path Zhang, et al. Expires December, 2019 [Page 13] Internet-Draft PCEP Extensions for H-PCE June 2019 computation request. The new OF codes described in Section 3.4.1 are applicable at the inter-domain path computation performed by the parent PCE, it is also necessary to specify the OF code that may be applied for the intra-domain path computation performed by the child PCE. To accommodate this, the OF-List TLV (described in Section 2.1. of [RFC5541]) is included in the OF object as an optional TLV. The OF-List TLV allows encoding of multiple OF codes. When this TLV is included inside the OF object, only the first OF-code in the OF-LIST TLV is considered. The parent PCE MUST use this OF code in the OF object when sending the intra domain path computation request to the child PCE. If the OF list TLV is included in the OF Object, the OF Code inside the OF Object MUST include one of the H-PCE Objective Functions defined in this document, the OF Code inside the OF List TLV MUST NOT include an H-PCE Objective Function. If this condition is not met, the PCEP speaker MUST respond with a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-Value=TBD15 (Incompatible OF codes in H-PCE). If the Objective Functions defined in this document are unknown or unsupported by a PCE, then the procedure as defined in [RFC5541] is followed. 3.5. Metric Object The METRIC object is defined in Section 7.8 of [RFC5440], comprising of metric-value, metric-type (T field) and flags. This document defines the following types for the METRIC object for H-PCE: o T=TBD6: Domain count metric (number of domains crossed); o T=TBD7: Border Node count metric (number of border nodes crossed). The domain count metric type of the METRIC object encodes the number of domains crossed in the path. The border node count metric type of the METRIC object encodes the number of border nodes in the path. If a domain is re-entered, then domain should be double counted. A PCC or child PCE MAY use the metric in a PCReq message for an inter-domain path computation, meeting the number of domain or border nodes crossing requirement. As per [RFC5440], in this case, the B bit is set to suggest a bound (a maximum) for the metric that must not be exceeded for the PCC to consider the computed path as acceptable. A PCC or child PCE MAY also use this metric to ask the PCE to optimize the metric during inter-domain path computation. In this Zhang, et al. Expires December, 2019 [Page 14] Internet-Draft PCEP Extensions for H-PCE June 2019 case, the B flag is cleared, and the C flag is set. The Parent PCE MAY use the 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 MAY also use this metric to send the computed end to end metric value in a reply message. 3.6. SVEC Object [RFC5440] defines SVEC object which includes flags for the potential dependency between the set of path computation requests (Link, Node and SRLG diverse). This document defines a new flag O for domain diversity. The following new bit is added to the Flags field: o Domain Diverse O-bit - TBD14 : when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST NOT have any transit domains in common. The Domain Diverse O-bit can be used in Hierarchical PCE path computation to compute synchronized domain diverse end to end path or diverse domain sequences. When domain diverse O bit is set, it is applied to the transit domains. The other bit in SVEC object (N, L, S etc.) MAY be set and MUST still be applied in the ingress and egress shared domain. 3.7. PCEP-ERROR Object 3.7.1. Hierarchy PCE Error-Type A new PCEP Error-Type [RFC5440] is used for the H-PCE extension as defined below: +------------+-----------------------------------------+ | Error-Type | Meaning | +------------+-----------------------------------------+ | TBD8 | H-PCE error | | | Error-value=1: H-PCE capability | | | was not advertised | | | Error-value=2: parent PCE capability | | | cannot be provided | +------------+-----------------------------------------+ Figure 4: H-PCE error Zhang, et al. Expires December, 2019 [Page 15] Internet-Draft PCEP Extensions for H-PCE June 2019 3.8. NO-PATH Object To communicate the reason(s) for not being able to find a multi- domain path or domain sequence, the NO-PATH object can be used in the PCRep message. [RFC5440] defines the format of the NO-PATH object. The object may contain a NO-PATH-VECTOR TLV to provide additional information about why a path computation has failed. Three new bit flags are defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object. o Bit number TBD9: When set, the parent PCE indicates that destination domain unknown; o Bit number TBD10: When set, the parent PCE indicates unresponsive child PCE(s); o Bit number TBD11: When set, the parent PCE indicates no available resource available in one or more domains. o Bit number TBD12: When set, the parent PCE indicates that the destination is not found in the indicated domain. 4. H-PCE Procedures The H-PCE path computation procedure is described in [RFC6805]. 4.1. OPEN Procedure between Child PCE and Parent PCE If a child PCE wants to use the peer PCE as a parent, it MUST set the P (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the OPEN object carried in the Open message during the PCEP session initialization procedure. The child PCE MAY also report its list of domain IDs, to the parent PCE, by specifying them in the Domain-ID TLVs in the OPEN object. This object is carried in the OPEN message during the PCEP session initialization procedure The OF codes defined in this document can be carried in the OF-list TLV of the OPEN object. If the OF-list TLV carries the OF codes, it means that the PCE is capable of implementing the corresponding objective functions. This information can be used for selecting a proper parent PCE when a child PCE wants to get a path that satisfies a certain Objective Function. When a child PCE sends a PCReq to a peer PCE, which requires parental Zhang, et al. Expires December, 2019 [Page 16] Internet-Draft PCEP Extensions for H-PCE June 2019 activity and H-PCE capability flags TLV but which were not included in the session establishment procedure described above, the peer PCE SHOULD send a PCErr message to the child PCE and MUST specify the error-type=TBD8 (H-PCE error) and error-value=1 (H-PCE capability was not advertised) in the PCEP-ERROR object. When a specific child PCE sends a PCReq to a peer PCE, that requires parental activity and the peer PCE does not want to act as the parent for it, the peer PCE SHOULD send a PCErr message to the child PCE and MUST specify the error-type=TBD8 (H-PCE error) and error-value=2 (Parent PCE capability cannot be provided) in the PCEP-ERROR object. 4.2. Procedure to Obtain Domain Sequence If a child PCE only wants to get the domain sequence for a multi- domain path computation from a parent PCE, it can set the Domain Path Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq message. The parent PCE which receives the PCReq message tries to compute a domain sequence for it (instead of the E2E path). If the domain path computation succeeds the parent PCE sends a PCRep message which carries the domain sequence in the Explicit Route Object (ERO) to the child PCE. Refer to [RFC7897] for more details about domain sub-objects in the ERO. Otherwise, it sends a PCReq message which carries the NO-PATH object to the child PCE. 5. Error Handling A PCE that is capable of acting as a parent PCE might not be configured or willing to act as the parent for a specific child PCE. This fact could be determined when the child sends a PCReq that requires parental activity, and could result in a negative response in a PCEP Error (PCErr) message and indicate the hierarchy PCE error- type=TBD8 (H-PCE error) and suitable error-value. (Section 3.7) Additionally, the parent PCE may fail to find the multi-domain path or domain sequence due to one or more of the following reasons: o A child PCE cannot find a suitable path to the egress; o The parent PCE does not hear from a child PCE for a specified time; o The Objective Functions specified in the path request cannot be met. In this case, the parent PCE MAY need to send a negative path computation reply specifying the reason. This can be achieved by Zhang, et al. Expires December, 2019 [Page 17] Internet-Draft PCEP Extensions for H-PCE June 2019 including NO-PATH object in the PCRep message. Extension to NO-PATH object is needed to include the aforementioned reasons described in Section 3.7. 6. Manageability Considerations General PCE and PCEP management considerations are discussed in [RFC4655] and [RFC5440]. There are additional management considerations for H-PCE which are described in [RFC6805], and repeated in this section. The administrative entity responsible for the management of the parent PCEs must be determined for the following cases: o multi-domains (e.g., IGP areas or multiple ASes) within a single service provider network, the management responsibility for the parent PCE would most likely be handled by the service provider, o multiple ASes within different service provider networks, it may be necessary for a third party to manage the parent PCEs according to commercial and policy agreements from each of the participating service providers. 6.1. Control of Function and Policy Control and function will need to be carefully managed in an H-PCE network. A child PCE will need to be configured with the address of its parent PCE. It is expected that there will only be one or two parents of any child. The parent PCE also needs to be aware of the child PCEs for all child domains that it can see. This information is most likely to be configured (as part of the administrative definition of each domain). Discovery of the relationships between parent PCEs and child PCEs do not form part of the hierarchical PCE architecture. Mechanisms that rely on advertising or querying PCE locations across domain or provider boundaries are undesirable for security, scaling, commercial, and confidentiality reasons. The specific behaviour of the child and parent PCE are described in the following sub-sections. 6.1.1. Child PCE Support of the hierarchical procedure will be controlled by the management organization responsible for each child PCE. A child PCE must be configured with the address of its parent PCE in order for it to interact with its parent PCE. The child PCE must also be Zhang, et al. Expires December, 2019 [Page 18] Internet-Draft PCEP Extensions for H-PCE June 2019 authorized to peer with the parent PCE. 6.1.2. Parent PCE The parent PCE MUST only accept path computation requests from authorized child PCEs. If a parent PCE receives requests from an unauthorized child PCE, the request SHOULD be dropped. This means that a parent PCE MUST be able to cryptographically authenticate requests from child PCEs. Multi-party shared key authentication schemes are not recommended for inter-domain relationships because of the potential for impersonation and repudiation and for the operational difficulties should revocation be required. The choice of authentication schemes to employ may be left to implementers of H-PCE and are not discussed further in this document. 6.1.3. Policy Control It may be necessary to maintain a policy module on the parent PCE [RFC5394]. This would allow the parent PCE to apply commercially relevant constraints such as SLAs, security, peering preferences, and monetary costs. It may also be necessary for the parent PCE to limit the end-to-end path selection by including or excluding specific domains based on commercial relationships, security implications, and reliability. 6.2. Information and Data Models A MIB module for PCEP was published as RFC 7420 [RFC7420] that describes managed objects for modelling of PCEP communication. A YANG module for PCEP has also been proposed [I-D.ietf-pce-pcep-yang]. Additionally, H-PCE MIB module, or additional data model, will be required to report parent PCE and child PCE information, including: o parent PCE configuration and status, o child PCE configuration and information, o notifications to indicate session changes between parent PCEs and child PCEs, and o notification of parent PCE TED updates and changes. Zhang, et al. Expires December, 2019 [Page 19] Internet-Draft PCEP Extensions for H-PCE June 2019 6.3. Liveness Detection and Monitoring The hierarchical procedure requires interaction with multiple PCEs. Once a child PCE requests an end-to-end path, a sequence of events occurs that requires interaction between the parent PCE and each child PCE. If a child PCE is not operational, and an alternate transit domain is not available, then the failure must be reported. 6.4. Verify Correct Operations Verifying the correct operation of a parent PCE can be performed by monitoring a set of parameters. The parent PCE implementation should provide the following parameters monitored at the parent PCE: o number of child PCE requests, o number of successful hierarchical PCE procedures completions on a per-PCE-peer basis, o number of hierarchical PCE procedure completion failures on a per- PCE-peer basis, and o number of hierarchical PCE procedure requests from unauthorized child PCEs. 6.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. 6.6. Impact On Network Operations The hierarchical PCE procedure is a multiple-PCE path computation scheme. Subsequent requests to and from the child and parent PCEs do not differ from other path computation requests and should not have any significant impact on network operations. 7. IANA Considerations IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry. This document requests IANA actions to allocate code points for the protocol elements defined in this document. 7.1. PCEP TLV Type Indicators IANA Manages the PCEP TLV code point registry (see [RFC5440]). This is maintained as the "PCEP TLV Type Indicators" sub-registry of the Zhang, et al. Expires December, 2019 [Page 20] Internet-Draft PCEP Extensions for H-PCE June 2019 "Path Computation Element Protocol (PCEP) Numbers" registry. This document defines three new PCEP TLVs. IANA is requested to make the following allocation: Type TLV name References ----------------------------------------------- TBD1 H-PCE-CAPABILITY TLV This I-D TBD2 Domain-ID TLV This I-D TBD3 H-PCE-FLAG TLV This I-D 7.2. H-PCE-CAPABILITY TLV Flags This document requests that a new sub-registry, named "H-PCE- CAPABILITY TLV Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the H-PCE-CAPABILITY TLV of the PCEP OPEN object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following values are defined in this document: Bit Description Reference -------------------------------------------------- 31 P (Parent PCE Request bit) This I.D. 7.3. Domain-ID TLV Domain type This document requests that a new sub-registry, named "Domain-ID TLV Domain type", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Domain-Type field of the Domain-ID TLV. The allocation policy for this new sub-registry is IETF Review [RFC8126]. Value Meaning ----------------------------------------------- 1 2-byte AS number 2 4-byte AS number 3 4-byte OSPF area ID 4 Variable length IS-IS area ID Zhang, et al. Expires December, 2019 [Page 21] Internet-Draft PCEP Extensions for H-PCE June 2019 7.4. H-PCE-FLAG TLV Flags This document requests that a new sub-registry, named "H-PCE-FLAG TLV Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the H- PCE-FLAGS TLV of the PCEP RP object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following values are defined in this document: Bit Description Reference ----------------------------------------------- 31 S (Domain This I.D. Sequence bit) 30 D (Disallow Domain This I.D. Re-entry bit) 7.5. OF Codes IANA maintains a 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 Point Name Reference ------------------------------------------------------ TBD4 Minimum number of Transit This I.D. Domains (MTD) TBD5 Minimize number of Border This I.D. Nodes (MBN) TBD13 Minimize the number of This I.D. Common Transit Domains (MCTD) 7.6. METRIC Types IANA maintains one sub-registry for "METRIC object T field". Two new metric types are defined in this document for the METRIC object Zhang, et al. Expires December, 2019 [Page 22] Internet-Draft PCEP Extensions for H-PCE June 2019 (specified in [RFC5440]). IANA is requested to make the following allocations: Value Description Reference ---------------------------------------------------------- TBD6 Domain Count metric This I.D. TBD7 Border Node Count metric This I.D. 7.7. New PCEP Error-Types and 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: Error-Type Meaning and error values Reference ------------------------------------------------------ TBD8 H-PCE Error This I.D. Error-value=1 H-PCE Capability not advertised Error-value=2 Parent PCE Capability cannot be provided 10 Reception of an invalid object [RFC5440] Error-value=TBD15: Incompatible This I.D. OF codes in H-PCE 7.8. New NO-PATH-VECTOR TLV Bit Flag IANA maintains a sub-registry "NO-PATH-VECTOR TLV Flag Field" of bit flags carried in the PCEP NO-PATH-VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440]. IANA is requested to assign three new bit flag as follows: Bit Number Name Flag Reference ------------------------------------------------------ TBD9 Destination Domain unknown This I.D. TBD10 Unresponsive child PCE(s) This I.D. TBD11 No available resource in This I.D. one or more domain TBD12 Destination is not found This I.D. in the indicated domain. Zhang, et al. Expires December, 2019 [Page 23] Internet-Draft PCEP Extensions for H-PCE June 2019 7.9. SVEC Flag IANA maintains a sub-registry "SVEC Object Flag Field" of bit flags carried in the PCEP SVEC object as defined in [RFC5440]. IANA is requested to assign one new bit flag as follows: Bit Number Name Flag Reference ------------------------------------------------------ TBD14 Domain Diverse O-bit This I.D. 8. Security Considerations The hierarchical PCE procedure relies on PCEP and inherits the security considerations defined in [RFC5440]. As PCEP operates over TCP, it may also make use of TCP security mechanisms, such as TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer Security (TLS) [RFC8253]. Any multi-domain operation necessarily involves the exchange of information across domain boundaries. This may represent a significant security and confidentiality risk especially when the child domains are controlled by different commercial concerns. PCEP allows individual PCEs to maintain the confidentiality of their domain path information using path-keys [RFC5520], and the H-PCE architecture is specifically designed to enable as much isolation of domain topology and capabilities information as is possible. For further considerations of the security issues related to inter-AS path computation, see [RFC5376]. 9. Contributing Authors Xian Zhang Huawei EMail: zhang.xian@huawei.com Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Zhang, et al. Expires December, 2019 [Page 24] Internet-Draft PCEP Extensions for H-PCE June 2019 10.Acknowledgements The authors would like to thank Mike McBride, Kyle Rose, Roni Even for their detailed review, comments and suggestions which helped improve 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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, DOI 10.17487/RFC4105, June 2005, . [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, DOI 10.17487/RFC4216, November 2005, . [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . Zhang, et al. Expires December, 2019 [Page 25] Internet-Draft PCEP Extensions for H-PCE June 2019 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, . [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, . [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, DOI 10.17487/RFC5376, November 2008, . [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, DOI 10.17487/RFC5394, December 2008, . [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 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, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, . [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, Zhang, et al. Expires December, 2019 [Page 26] Internet-Draft PCEP Extensions for H-PCE June 2019 . [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, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep- yang-11 (work in progress), March 2019. [I-D.ietf-pce-stateful-hpce] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., and O. Dios, "Hierarchical Stateful Path Computation Element (PCE).", draft-ietf-pce-stateful-hpce-07 (work in progress), April 2019. [I-D.dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", draft- dhodylee-pce-pcep-ls-13 (work in progress), February 2019. Zhang, et al. Expires December, 2019 [Page 27] Internet-Draft PCEP Extensions for H-PCE June 2019 Authors' Addresses Fatai Zhang Huawei Huawei Base, Bantian, Longgang District Shenzhen 518129 China EMail: zhangfatai@huawei.com Quintin Zhao Huawei 125 Nagog Technology Park Acton, MA 01719 USA EMail: quintin.zhao@huawei.com Oscar Gonzalez de Dios Telefonica Don Ramon de la Cruz 82-84 Madrid 28045 Spain EMail: oscar.gonzalezdedios@telefonica.com Ramon Casellas CTTC Av. Carl Friedrich Gauss n.7 Barcelona, Castelldefels Spain EMail: ramon.casellas@cttc.es Daniel King Old Dog Consulting UK EMail: daniel@olddog.co.uk Appendix A1. Implementation Status Zhang, et al. Expires December, 2019 [Page 28] Internet-Draft PCEP Extensions for H-PCE June 2019 The H-PCE architecture and protocol procedures describe in this I-D were implemented and tested for a variety of optical research applications. The Appendix should be removed before publication. A1.1. Inter-layer traffic engineering with H-PCE This work was led by: o Ramon Casellas [ramon.casellas@cttc.es] o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) The H-PCE instances (parent and child) were multi-threaded asynchronous processes. Implemented in C++11, using C++ Boost Libraries. The targeted system used to deploy and run H-PCE applications was a POSIX system (Debian GNU/Linux operating system). Some parts of the software may require a Linux Kernel, the availability of a Routing Controller running collocated in the same host and the usage of libnetfilter / libipq and GNU/Linux firewalling capabilities. Most of the functionality, including algorithms is done by means of plugins (e.g., as shared libraries or .so files in Unix systems). The CTTC PCE supports the H-PCE architecture, but also supports stateful PCE with active capabilities, as an OpenFlow controller, and has dedicated plugins to support monitoring, BRPC, P2MP, path keys, back end PCEs. Management of the H-PCE entities was supported via HTTP and CLI via Telnet. Further details of the H-PCE prototyping and experimentation can be found in the following scientific papers: R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. Morita, "Inter-layer traffic engineering with hierarchical-PCE in MPLS-TP over wavelength switched optical networks" , Optics Express, Vol. 20, No. 28, December 2012. R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. Morita, M. Msurusawa, "Dynamic virtual link mesh topology aggregation in multi-domain translucent WSON with hierarchical- PCE", Optics Express Journal, Vol. 19, No. 26, December 2011. R. Casellas, R. Munoz, R. Martinez, R. Vilalta, L. Liu, T. Tsuritani, I. Morita, V. Lopez, O. Gonzalez de Dios, J. P. Fernandez-Palacios, "SDN based Provisioning Orchestration of Zhang, et al. Expires December, 2019 [Page 29] Internet-Draft PCEP Extensions for H-PCE June 2019 OpenFlow/GMPLS Flexi-grid Networks with a Stateful Hierarchical PCE", in Proceedings of Optical Fiber Communication Conference and Exposition (OFC), 9-13 March, 2014, San Francisco (EEUU). Extended Version to appear in Journal Of Optical Communications and Networking January 2015 F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical PCE Architecture in a Distributed Multi-Platform Control Plane Testbed" , in Proceedings of Optical Fiber Communication Conference and Exposition (OFC) and The National Fiber Optic Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, California (USA). R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. Morita, M. Tsurusawa, "Dynamic Virtual Link Mesh Topology Aggregation in Multi-Domain Translucent WSON with Hierarchical- PCE", in Proceedings of 37th European Conference and Exhibition on Optical Communication (ECOC 2011), 18-22 September 2011, Geneve ( Switzerland). R. Casellas, R. Munoz, R. Martinez, "Lab Trial of Multi-Domain Path Computation in GMPLS Controlled WSON Using a Hierarchical PCE", in Proceedings of OFC/NFOEC Conference (OFC2011), 10 March 2011, Los Angeles (USA). A1.2. Telefonica Netphony (Open Source PCE) The Telefonica Netphony PCE is an open source Java-based implementation of a Path Computation Element, with several flavours, and a Path Computation Client. The PCE follows a modular architecture and allows to add customized algorithms. The PCE has also stateful and remote initiation capabilities. In current version, three components can be built, a domain PCE (aka child PCE), a parent PCE (ready for the H-PCE architecture) and a PCC (path computation client). This work was led by: o Oscar Gonzalez de Dios [oscar.gonzalezdedios@telefonica.com] o Victor Lopez Alvarez [victor.lopezalvarez@telefonica.com] o Telefonica I+D, Madrid, Spain The PCE code is publicly available in a GitHub repository: o https://github.com/telefonicaid/netphony-pce Zhang, et al. Expires December, 2019 [Page 30] Internet-Draft PCEP Extensions for H-PCE June 2019 The PCEP protocol encodings are located in the following repository: o https://github.com/telefonicaid/netphony-network protocols The traffic engineering database and a BGP-LS speaker to fill the database is located in: o https://github.com/telefonicaid/netphony-topology The parent and child PCE are multi-threaded java applications. The path computation uses the jgrapht free Java class library (0.9.1) that provides mathematical graph-theory objects and algorithms. Current version of netphony PCE runs on java 1.7 and 1.8, and has been tested in GNU/Linux, Mac OS-X and Windows environments. The management of the parent and domain PCEs is supported though CLI via Telnet, and configured via XML files. Further details of the netphony H-PCE prototyping and experimentation can be found in the following research papers: o O. Gonzalez de Dios, R. Casellas, F. Paolucci, A. Napoli, L. Gifre, A. Dupas, E, Hugues-Salas, R. Morro, S. Belotti, G. Meloni, T. Rahman, V.P Lopez, R. Martinez, F. Fresi, M. Bohn, S. Yan, L. Velasco, . Layec and J. P. Fernandez-Palacios: Experimental Demonstration of Multivendor and Multidomain EON With Data and Control Interoperability Over a Pan-European Test Bed, in Journal of Lightwave Technology, Dec. 2016, Vol. 34, Issue 7, pp. 1610-1617. o O. Gonzalez de Dios, R. Casellas, R. Morro, F. Paolucci, V. Lopez, R. Martinez, R. Munoz, R. Villalta, P. Castoldi: "Multi-partner Demonstration of BGP-LS enabled multi-domain EON, in Journal of Optical Communications and Networking, Dec. 2015, Vol. 7, Issue 12, pp. B153-B162. o F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical PCE Architecture in a Distributed Multi-Platform Control Plane Testbed" , in Proceedings of Optical Fiber Communication Conference and Exposition (OFC) and The National Fiber Optic Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, California (USA). A1.3. H-PCE Proof of Concept developed by Huawei Huawei developed this H-PCE on the Huawei Versatile Routing Platform (VRP) to experiment with the hierarchy of PCE. Both end to end path computation as well as computation for domain-sequence are supported. Zhang, et al. Expires December, 2019 [Page 31] Internet-Draft PCEP Extensions for H-PCE June 2019 This work was led by: o Udayasree Pallee [udayasreereddy@gmail.com] o Dhruv Dhody [dhruv.ietf@gmail.com] o Huawei Technologies, Bangalore, India Further work on stateful H-PCE [I-D.ietf-pce-stateful-hpce] is being carried out on ONOS. Internet-Draft PCEP Extensions for H-PCE June 2019 ./draft-ietf-perc-private-media-framework-12.txt0000644000764400076440000020627513476041557021054 0ustar iustyiusty Network Working Group P. Jones Internet-Draft Cisco Intended status: Standards Track D. Benham Expires: December 7, 2019 C. Groves Independent June 5, 2019 A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC) draft-ietf-perc-private-media-framework-12 Abstract This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the real-time transport protocol (RTP). 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 https://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 7, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Jones, et al. Expires December 7, 2019 [Page 1] Internet-Draft Private Media Framework June 2019 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. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 5 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 6 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 7 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 8 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 8 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 9 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 10 4.4. HBH Keys and Per-hop Operations . . . . . . . . . . . . . 10 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 11 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 11 4.5.2. Key Exchange during a Conference . . . . . . . . . . 13 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 14 5.2. Certificate Fingerprints in Session Signaling . . . . . . 14 5.3. Conference Identification . . . . . . . . . . . . . . . . 15 6. PERC Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Key Inventory and Management Considerations . . . . . . . 15 6.2. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 16 6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 17 6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 18 6.5. Summary of Key Types and Entity Possession . . . . . . . 18 7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 20 8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 21 8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 21 8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 22 8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 22 8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 23 8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 23 8.3. Key Distributor Attacks . . . . . . . . . . . . . . . . . 23 8.4. Endpoint Attacks . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 Jones, et al. Expires December 7, 2019 [Page 2] Internet-Draft Private Media Framework June 2019 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Switched conferencing is an increasingly popular model for multimedia conferences with multiple participants using a combination of audio, video, text, and other media types. With this model, real-time media flows from conference participants are not mixed, transcoded, transrated, recomposed, or otherwise manipulated by a Media Distributor, as might be the case with a traditional media server or multipoint control unit (MCU). Instead, media flows transmitted by conference participants are simply forwarded by Media Distributors to each of the other participants. Media Distributors often forward only a subset of flows based on voice activity detection or other criteria. In some instances, Media Distributors may make limited modifications to RTP [RFC3550] headers, for example, but the actual media content (e.g., voice or video data) is unaltered. An advantage of switched conferencing is that Media Distributors can be more easily deployed on general-purpose computing hardware, including virtualized environments in private and public clouds. Virtualized public cloud environments have been viewed as less secure since resources are not always physically controlled by those who use them. This document defines improved security so as to lower the barrier to taking advantage of those environments. This document defines a solution framework wherein media privacy is ensured by making it impossible for a Media Distributor to gain access to keys needed to decrypt or authenticate the actual media content sent between conference participants. At the same time, the framework allows for the Media Distributors to modify certain RTP headers; add, remove, encrypt, or decrypt RTP header extensions; and encrypt and decrypt RTP Control Protocol (RTCP) [RFC3550] packets. The framework also prevents replay attacks by authenticating each packet transmitted between a given participant and the Media Distributor using a unique key per Endpoint that is independent from the key for media encryption and authentication. This solution framework provides for enhanced privacy in RTP-based conferencing environments while utilizing existing security procedures defined for RTP with minimal enhancements. Jones, et al. Expires December 7, 2019 [Page 3] Internet-Draft Private Media Framework June 2019 2. Conventions Used in This Document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Additionally, this solution framework uses the following terms and acronyms: End-to-End (E2E): Communications from one Endpoint through one or more Media Distributors to the Endpoint at the other end. Hop-by-Hop (HBH): Communications between an Endpoint and a Media Distributor or between Media Distributors. Trusted Endpoint (or simply Endpoint): An RTP flow terminating entity that has possession of E2E media encryption keys and terminates E2E encryption. This may include embedded user conferencing equipment or browsers on computers, media gateways, MCUs, media recording devices and more that are in the trusted domain for a given deployment. In the context of WebRTC [W3C.CR-webrtc-20180927], where control of a session is divided between a JavaScript application and a browser, the browser acts as the Trusted Endpoint for purposes of this framework (just as it acts as the endpoint for DTLS-SRTP [RFC5764] in one-to-one calls). Media Distributor (MD): An RTP middlebox that forwards Endpoint media content (e.g., voice or video data) unaltered, either a subset or all of the flows at any given time, and is never allowed to have access to E2E encryption keys. It operates according to the Selective Forwarding Middlebox RTP topologies [RFC7667] per the constraints defined by the PERC system, which includes, but is not limited to, having no access to RTP media plaintext and having limits on what RTP header field it can alter. The header fields that may be modified by a Media Distributor are enumerated in Section 4 of the Double cryptographic transform specification [I-D.ietf-perc-double] and chosen with respect to utility and the security considerations outlined in this document. Key Distributor: An entity that is a logical function which distributes keying material and related information to Trusted Endpoints and Media Distributor(s), only that which is appropriate for each. The Key Distributor might be co-resident with another entity trusted with E2E keying material. Jones, et al. Expires December 7, 2019 [Page 4] Internet-Draft Private Media Framework June 2019 Conference: Two or more participants communicating via Trusted Endpoints to exchange RTP flows through one or more Media Distributor. Call Processing: All Trusted Endpoints in the conference connect to it by a call processing dialog, such as with the Focus defined in the Framework for Conferencing with SIP [RFC4353]. Third Party: Any entity that is not an Endpoint, Media Distributor, Key Distributor or Call Processing entity as described in this document. 3. PERC Entities and Trust Model The following figure depicts the trust relationships, direct or indirect, between entities described in the subsequent sub-sections. Note that these entities may be co-located or further divided into multiple, separate physical devices. Please note that some entities classified as untrusted in the simple, general deployment scenario used most commonly in this document might be considered trusted in other deployments. This document does not preclude such scenarios, but keeps the definitions and examples focused by only using the simple, most general deployment scenario. | +----------+ | +-----------------+ | Endpoint | | | Call Processing | +----------+ | +-----------------+ | | +----------------+ | +--------------------+ | Key Distributor| | | Media Distributor | +----------------+ | +--------------------+ | Trusted | Untrusted Entities | Entities | Figure 1: Trusted and Untrusted Entities in PERC 3.1. Untrusted Entities The architecture described in this framework document enables conferencing infrastructure to be hosted in domains, such as in a cloud conferencing provider's facilities, where the trustworthiness is below the level needed to assume the privacy of participant's Jones, et al. Expires December 7, 2019 [Page 5] Internet-Draft Private Media Framework June 2019 media is not compromised. The conferencing infrastructure in such a domain is still trusted with reliably connecting the participants together in a conference, but not trusted with keying material needed to decrypt any of the participant's media. Entities in such lower trustworthiness domains are referred to as untrusted entities from this point forward. It is important to understand that untrusted in this document does not mean an entity is not expected to function properly. Rather, it means only that the entity does not have access to the E2E media encryption keys. 3.1.1. Media Distributor A Media Distributor forwards RTP flows between Endpoints in the conference while performing per-hop authentication of each RTP packet. The Media Distributor may need access to one or more RTP headers or header extensions, potentially adding or modifying a certain subset. The Media Distributor also relays secured messaging between the Endpoints and the Key Distributor and acquires per-hop key information from the Key Distributor. The actual media content must not be decryptable by a Media Distributor, as it is untrusted to have access to the E2E media encryption keys. The key exchange mechanisms specified in this framework prevent the Media Distributor from gaining access to the E2E media encryption keys. An Endpoint's ability to connect to a conference serviced by a Media Distributor does imply that the Endpoint is authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an Endpoint is authorized. Instead, the Key Distributor is responsible for authenticating the Endpoint (e.g., using WebRTC Identity [I-D.ietf-rtcweb-security-arch]) and determining its authorization to receive E2E and HBH media encryption keys. A Media Distributor must perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects of denial of service attacks (refer to Section 8) to a level equal to or better than traditional conferencing (non-PERC) deployments. A Media Distributor or associated conferencing infrastructure may also initiate or terminate various conference control related messaging, which is outside the scope of this framework document. Jones, et al. Expires December 7, 2019 [Page 6] Internet-Draft Private Media Framework June 2019 3.1.2. Call Processing The call processing function is untrusted in the simple, general deployment scenario. When a physical subset of the call processing function resides in facilities outside the trusted domain, it should not be trusted to have access to E2E key information. The call processing function may include the processing of call signaling messages, as well as the signing of those messages. It may also authenticate the Endpoints for the purpose of call signaling and subsequently joining of a conference hosted through one or more Media Distributors. Call processing may optionally ensure the privacy of call signaling messages between itself, the Endpoint, and other entities. 3.2. Trusted Entities From the PERC model system perspective, entities considered trusted (refer to Figure 1) can be in possession of the E2E media encryption keys for one or more conferences. 3.2.1. Endpoint An Endpoint is considered trusted and has access to E2E key information. While it is possible for an Endpoint to be compromised, subsequently performing in undesired ways, defining Endpoint resistance to compromise is outside the scope of this document. Endpoints take measures to mitigate the adverse effects of denial of service attacks (refer to Section 8) from other entities, including from other Endpoints, to a level equal to or better than traditional conference (non-PERC) deployments. 3.2.2. Key Distributor The Key Distributor, which may be colocated with an Endpoint or exist standalone, is responsible for providing key information to Endpoints for both end-to-end (E2E) and hop-by-hop (HBH) security and for providing key information to Media Distributors for the hop-by-hop security. Interaction between the Key Distributor and the call processing function is necessary for proper conference-to-Endpoint mappings. This is described in Section 5.3. The Key Distributor needs to be secured and managed in a way to prevent exploitation by an adversary, as any kind of compromise of the Key Distributor puts the security of the conference at risk. Jones, et al. Expires December 7, 2019 [Page 7] Internet-Draft Private Media Framework June 2019 They Key Distributor needs to know which Endpoints and which Media Distributors are authorized to participate in the conference. How the Key Distributor obtains this information is outside the scope of this document. However, Key Distributors MUST reject DTLS associations with any unauthorized Endpoint or Media Distributor. 4. Framework for PERC The purpose for this framework is to define a means through which media privacy is ensured when communicating within a conferencing environment consisting of one or more Media Distributors that only switch, hence not terminate, media. It does not otherwise attempt to hide the fact that a conference between Endpoints is taking place. This framework reuses several specified RTP security technologies, including Secure Real-time Transport Protocol (SRTP) [RFC3711], Encrypted Key Transport (EKT) [I-D.ietf-perc-srtp-ekt-diet], and DTLS-SRTP. 4.1. End-to-End and Hop-by-Hop Authenticated Encryption This solution framework focuses on the end-to-end privacy and integrity of the participant's media by limiting access to only trusted entities to the E2E key used for authenticated end-to-end encryption. However, this framework does give a Media Distributor access to RTP headers fields and header extensions, as well as the ability to modify a certain subset of the header fields and to add or change header extensions. Packets received by a Media Distributor or an Endpoint are authenticated hop-by-hop. To enable all of the above, this framework defines the use of two security contexts and two associated encryption keys: an "inner" key (an E2E key distinct for each transmitted media flow) for authenticated encryption of RTP media between Endpoints and an "outer" key (HBH key) known only to Media Distributor or the adjacent Endpoint for the hop between an Endpoint and a Media Distributor or peer Endpoint. An Endpoint will receive one or more E2E keys from every other Endpoint in the conference that correspond to the media flows transmitted by those other Endpoints, while HBH keys are derived from the DTLS-SRTP association with the Key Distributor. Two communicating Media Distributors use DTLS-SRTP associations directly with each other to obtain the HBH keys they will use. See Section 4.5 for more details on key exchange. Jones, et al. Expires December 7, 2019 [Page 8] Internet-Draft Private Media Framework June 2019 +-------------+ +-------------+ | |################################| | | Media |------------------------ *----->| Media | | Distributor |<----------------------*-|------| Distributor | | X |#####################*#|#|######| Y | | | | | | | | +-------------+ | | | +-------------+ # ^ | # HBH Key (XY) -+ | | # ^ | # # | | # E2E Key (B) ---+ | # | | # # | | # E2E Key (A) -----+ # | | # # | | # # | | # # | | # # | | # # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # # | | # # | | # # *--------- E2E Key (A) E2E Key (A) ---------* # # | *------- E2E Key (B) E2E Key (B) -------* | # # | | # # | | # # | v # # | v # +-------------+ +-------------+ | Endpoint A | | Endpoint B | +-------------+ +-------------+ Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP Packets The Double transform [I-D.ietf-perc-double] enables Endpoints to perform encryption using both the end-to-end and hop-by-hop contexts while still preserving the same overall interface as other SRTP transforms. The Media Distributor simply uses the corresponding normal (single) AES-GCM transform, keyed with the appropriate HBH keys. See Section 6.1 for a description of the keys used in PERC and Section 7 for diagram of how encrypted RTP packets appear on the wire. RTCP is only encrypted hop-by-hop, not end-to-end. This framework introduces no additional step for RTCP authenticated encryption, so the procedures needed are specified in [RFC3711] and use the same outer, hop-by-hop cryptographic context chosen in the Double operation described above. For this reason, Endpoints MUST NOT send confidential information via RTCP. 4.2. E2E Key Confidentiality To ensure the confidentiality of E2E keys shared between Endpoints, Endpoints use a common Key Encryption Key (KEK) that is known only by the trusted entities in a conference. That KEK, defined in the EKT specification [I-D.ietf-perc-srtp-ekt-diet] as the EKT Key, is used to subsequently encrypt the SRTP master key used for E2E Jones, et al. Expires December 7, 2019 [Page 9] Internet-Draft Private Media Framework June 2019 authenticated encryption of media sent by a given Endpoint. Each Endpoint in the conference creates an SRTP master key for E2E authenticated encryption and keep track of the E2E keys received via the Full EKT Tag for each distinct synchronization source (SSRC) in the conference so that it can properly decrypt received media. An Endpoint may change its E2E key at any time and advertise that new key to the conference as specified in [I-D.ietf-perc-srtp-ekt-diet]. 4.3. E2E Keys and Endpoint Operations Any given RTP media flow is identified by its SSRC, and an Endpoint might send more than one at a time and change the mix of media flows transmitted during the life of a conference. Thus, an Endpoint MUST maintain a list of SSRCs from received RTP flows and each SSRC's associated E2E key information. An Endpoint MUST discard old E2E keys no later than when it leaves the conference (see Section 4.5.2). If the packet is to contain RTP header extensions, it should be noted that those are only encrypted HBH per [I-D.ietf-perc-double]. For this reason, Endpoints MUST NOT transmit confidential information via RTP header extensions. 4.4. HBH Keys and Per-hop Operations To ensure the integrity of transmitted media packets, it is REQUIRED that every packet be authenticated hop-by-hop between an Endpoint and a Media Distributor, as well between Media Distributors. The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the respective hop. Each HBH key is distinct per hop and no two hops ever use the same SRTP master key. While Endpoints also perform HBH authentication, the ability of the Endpoints to reconstruct the original RTP header also enables the Endpoints to authenticate RTP packets E2E. This design yields flexibility to the Media Distributor to change certain RTP header values as packets are forwarded. Which values the Media Distributor can change in the RTP header are defined in [I-D.ietf-perc-double]. RTCP can only be encrypted hop-by-hop, giving the Media Distributor the flexibility to forward RTCP content unchanged, transmit compound RTCP packets or to initiate RTCP packets for reporting statistics or conveying other information. Performing hop-by-hop authentication for all RTP and RTCP packets also helps provide replay protection (see Section 8). The use of the replay protection mechanism specified in Section 3.3.2 of [RFC3711] is REQUIRED at each hop. Jones, et al. Expires December 7, 2019 [Page 10] Internet-Draft Private Media Framework June 2019 If there is a need to encrypt one or more RTP header extensions hop- by-hop, the Endpoint derives an encryption key from the HBH SRTP master key to encrypt header extensions as per [RFC6904]. This still gives the Media Distributor visibility into header extensions, such as the one used to determine audio level [RFC6464] of conference participants. Note that when RTP header extensions are encrypted, all hops need to decrypt and re-encrypt these encrypted header extensions. Please refer to Sections 5.1 through 5.3 of [I-D.ietf-perc-double] for procedures to perform RTP header extension encryption and decryption. 4.5. Key Exchange In brief, the keys used by any given Endpoints are determined in the following way: o The HBH keys that the Endpoint uses to send and receive SRTP media are derived from a DTLS handshake that the Endpoint performs with the Key Distributor (following normal DTLS-SRTP procedures). o The E2E key that an Endpoint uses to send SRTP media can either be set from the DTLS-SRTP association with the Key Distributor or chosen by the Endpoint. It is then distributed to other Endpoints in a Full EKT Tag, encrypted under an EKT Key provided to the client by the Key Distributor within the DTLS channel they negotiated. Note that an Endpoint MAY create a different E2E key per media flow, where a media flow is identified by its SSRC value. o Each E2E key that an Endpoint uses to receive SRTP media is set by receiving a Full EKT Tag from another Endpoint. o The HBH keys used between two Media Distributors is derived from DTLS-SRTP procedures employed directly between them. 4.5.1. Initial Key Exchange and Key Distributor The Media Distributor maintains a tunnel with the Key Distributor (e.g., using [I-D.ietf-perc-dtls-tunnel]), making it possible for the Media Distributor to facilitate the establishment of a secure DTLS association between each Endpoint and the Key Distributor as shown the following figure. The DTLS association between Endpoints and the Key Distributor enables each Endpoint to generate E2E and HBH keys and receive the KEK. At the same time, the Key Distributor securely provides the HBH key information to the Media Distributor. The key information summarized here may include the SRTP master key, SRTP master salt, and the negotiated cryptographic transform. Jones, et al. Expires December 7, 2019 [Page 11] Internet-Draft Private Media Framework June 2019 +-----------+ KEK info | Key | HBH Key info to to Endpoints |Distributor| Endpoints & Media Distributor +-----------+ # ^ ^ # # | | #--- Tunnel # | | # +-----------+ +-----------+ +-----------+ | Endpoint | DTLS | Media | DTLS | Endpoint | | KEK |<------------|Distributor|------------>| KEK | | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | +-----------+ +-----------+ +-----------+ Figure 3: Exchanging Key Information Between Entities In addition to the secure tunnel between the Media Distributor and the Key Distributor, there are two additional types of security associations utilized as a part of the key exchange as discussed in the following paragraphs. One is a DTLS-SRTP association between an Endpoint and the Key Distributor (with packets passing through the Media Distributor) and the other is a DTLS-SRTP association between peer Media Distributors. Endpoints establish a DTLS-SRTP association over the RTP session with the Media Distributor and its media ports for the purposes of key information exchange with the Key Distributor. The Media Distributor does not terminate the DTLS signaling, but instead forwards DTLS packets received from an Endpoint on to the Key Distributor (and vice versa) via a tunnel established between Media Distributor and the Key Distributor. In establishing the DTLS association between Endpoints and the Key Distributor, the Endpoint MUST act as the DTLS client and the Key Distributor MUST act as the DTLS server. The KEK is conveyed by the Key Distributor over the DTLS association to Endpoints via procedures defined in EKT [I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message. The Key Distributor MUST NOT establish DTLS-SRTP associations with Endpoints without first authenticating the Media Distributor tunneling the DTLS-SRTP packets from the Endpoint. Note that following DTLS-SRTP procedures for the [I-D.ietf-perc-double] cipher, the Endpoint generates both E2E and HBH encryption keys and salt values. Endpoints MUST either use the DTLS-SRTP generated E2E key for transmission or generate a fresh E2E key. In either case, the generated SRTP master salt for E2E encryption MUST be replaced with the salt value provided by the Key Jones, et al. Expires December 7, 2019 [Page 12] Internet-Draft Private Media Framework June 2019 Distributor via the EKTKey message. That is because every Endpoint in the conference uses the same SRTP master salt. The Endpoint only transmits the SRTP master key (not the salt) used for E2E encryption to other Endpoints in RTP/RTCP packets per [I-D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP directly with a peer Media Distributor to establish the HBH key for transmitting RTP and RTCP packets to that peer Media Distributor. The Key Distributor does not facilitate establishing a HBH key for use between Media Distributors. 4.5.2. Key Exchange during a Conference Following the initial key information exchange with the Key Distributor, an Endpoint is able to encrypt media end-to-end with an E2E key, sending that E2E key to other Endpoints encrypted with the KEK, and is able to encrypt and authenticate RTP packets using a HBH key. The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any Endpoint's E2E key and subsequently decrypting media. The KEK may need to change from time-to-time during the life of a conference, such as when a new participant joins or leaves a conference. Dictating if, when or how often a conference is to be re-keyed is outside the scope of this document, but this framework does accommodate re-keying during the life of a conference. When a Key Distributor decides to re-key a conference, it transmits a new EKTKey message containing the new EKT Key to each of the conference participants. Upon receipt of the new EKT Key, the Endpoint MUST create a new SRTP master key and prepare to send that key inside a Full EKT Field using the new EKT Key as per Section 4.5 of [I-D.ietf-perc-srtp-ekt-diet]. In order to allow time for all Endpoints in the conference to receive the new keys, the sender should follow the recommendations in Section 4.7 of [I-D.ietf-perc- srtp-ekt-diet]. On receiving a new EKT Key, Endpoints MUST be prepared to decrypt EKT tags using the new key. The EKT SPI field is used to differentiate between tags encrypted with the old and new keys. After re-keying, an Endpoint SHOULD retain prior SRTP master keys and EKT Key for a period of time sufficient for the purpose of ensuring it can decrypt late-arriving or out-of-order packets or packets sent by other Endpoints that used the prior keys for a period of time after re-keying began. An Endpoint MAY retain old keys until the end of the conference. Jones, et al. Expires December 7, 2019 [Page 13] Internet-Draft Private Media Framework June 2019 Endpoints MAY follow the procedures in section 5.2 of [RFC5764] to renegotiate HBH keys as desired. If new HBH keys are generated, the new keys are also delivered to the Media Distributor following the procedures defined in [I-D.ietf-perc-dtls-tunnel] as one possible method. Endpoints MAY change the E2E encryption key used at any time. An Endpoint MUST generate a new E2E encryption key whenever it receives a new EKT Key. After switching to a new key, the new key is conveyed to other Endpoints in the conference in RTP/RTCP packets per [I-D.ietf-perc-srtp-ekt-diet]. 5. Authentication It is important to this solution framework that the entities can validate the authenticity of other entities, especially the Key Distributor and Endpoints. The details of this are outside the scope of specification but a few possibilities are discussed in the following sections. The critical requirements are that an Endpoint can verify it is connected to the correct Key Distributor for the conference and the Key Distributor can verify the Endpoint is the correct Endpoint for the conference. Two possible approaches to solve this are Identity Assertions and Certificate Fingerprints. 5.1. Identity Assertions WebRTC Identity assertion [I-D.ietf-rtcweb-security-arch] is used to bind the identity of the user of the Endpoint to the fingerprint of the DTLS-SRTP certificate used for the call. This certificate is unique for a given call and a conference. This allows the Key Distributor to ensure that only authorized users participate in the conference. Similarly the Key Distributor can create a WebRTC Identity assertion to bind the fingerprint of the unique certificate used by the Key Distributor for this conference so that the Endpoint can validate it is talking to the correct Key Distributor. Such a setup requires an Identity Provider (Idp) trusted by the Endpoints and the Key Distributor. 5.2. Certificate Fingerprints in Session Signaling Entities managing session signaling are generally assumed to be untrusted in the PERC framework. However, there are some deployment scenarios where parts of the session signaling may be assumed trustworthy for the purposes of exchanging, in a manner that can be authenticated, the fingerprint of an entity's certificate. Jones, et al. Expires December 7, 2019 [Page 14] Internet-Draft Private Media Framework June 2019 As a concrete example, SIP [RFC3261] and Session Description Protocol (SDP) [RFC4566] can be used to convey the fingerprint information per [RFC5763]. An Endpoint's SIP User Agent would send an INVITE message containing SDP for the media session along with the Endpoint's certificate fingerprint, which can be signed using the procedures described in [RFC8224] for the benefit of forwarding the message to other entities by the Focus [RFC4353]. Other entities can verify the fingerprints match the certificates found in the DTLS-SRTP connections to find the identity of the far end of the DTLS-SRTP connection and verify that is the authorized entity. Ultimately, if using session signaling, an Endpoint's certificate fingerprint would need to be securely mapped to a user and conveyed to the Key Distributor so that it can check that that user is authorized. Similarly, the Key Distributor's certificate fingerprint can be conveyed to an Endpoint in a manner that can be authenticated as being an authorized Key Distributor for this conference. 5.3. Conference Identification The Key Distributor needs to know what Endpoints are being added to a given conference. Thus, the Key Distributor and the Media Distributor need to know Endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier defined in [I-D.ietf-perc-dtls-tunnel]. How this unique identifier is assigned is outside the scope of this document. 6. PERC Keys This section describes the various keys employed by PERC. 6.1. Key Inventory and Management Considerations This section summarizes the several different keys used in the PERC framework, how they are generated, and what purpose they serve. The keys are described in the order in which they would typically be acquired. The various keys used in PERC are shown in Figure 4 below. Jones, et al. Expires December 7, 2019 [Page 15] Internet-Draft Private Media Framework June 2019 +-----------+----------------------------------------------------+ | Key | Description | +-----------+----------------------------------------------------+ | HBH Key | SRTP master key used to encrypt media hop-by-hop. | +-----------+----------------------------------------------------+ | KEK | Key shared by all Endpoints and used to encrypt | | (EKT Key) | each Endpoint's E2E SRTP master key so receiving | | | Endpoints can decrypt media. | +-----------+----------------------------------------------------+ | E2E Key | SRTP master key used to encrypt media end-to-end. | +-----------+----------------------------------------------------+ Figure 4: Key Inventory While the number of key types is very small, it should be understood that the actual number of distinct keys can be large as the conference grows in size. As an example, with 1,000 participants in a conference, there would be at least 1,000 distinct SRTP master keys, all of which share the same master salt. Each of those keys are passed through the KDF defined in [RFC3711] to produce the actual encryption and authentication keys. Complicating key management is the fact that the KEK can change and, when it does, the Endpoints generate new SRTP master keys that are associated with a new EKT SPI. Endpoints might retain old keys for a period of time to ensure they can properly decrypt late-arriving or out-of-order packets, which means the number of keys held during that period of time might substantially more. A more detailed explanation of each of the keys follows. 6.2. DTLS-SRTP Exchange Yields HBH Keys The first set of keys acquired are for hop-by-hop encryption and decryption. Per the Double [I-D.ietf-perc-double] procedures, the Endpoint performs DTLS-SRTP exchange with the Key Distributor and receives a key that is, in fact, "double" the size that is needed. The end-to-end part is the first half of the key, so the Endpoint discards that information when generating its own key. The second half of the key material is for hop-by-hop operations, so that half of the key (corresponding to the least significant bits) is assigned internally as the HBH key. The Key Distributor informs the Media Distributor of the HBH key. Specifically, the Key Distributor sends the least significant bits corresponding to the half of the keying material determined through Jones, et al. Expires December 7, 2019 [Page 16] Internet-Draft Private Media Framework June 2019 DTLS-SRTP with the Endpoint to the Media Distributor. A salt value is generated along with the HBH key. The salt is also longer than needed for hop-by-hop operations, thus only the least significant bits of the required length (half of the generated salt material) are sent to the Media Distributor. One way to transmit this key and salt information is via the tunnel protocol defined in [I-D.ietf-perc-dtls-tunnel]. No two Endpoints have the same HBH key, thus the Media Distributor MUST keep track each distinct HBH key (and the corresponding salt) and use it only for the specified hop. The HBH key is also used for hop-by-hop encryption of RTCP. RTCP is not end-to-end encrypted in PERC. 6.3. The Key Distributor Transmits the KEK (EKT Key) Via the aforementioned DTLS-SRTP association, the Key Distributor sends the Endpoint the KEK (EKT Key per [I-D.ietf-perc-srtp-ekt-diet]). This key is known only to the Key Distributor and Endpoints. This key is the most important to protect since having knowledge of this key (and the SRTP master salt transmitted as a part of the same message) allows an entity to decrypt any media packet in the conference. Note that the Key Distributor can send any number of EKT Keys to Endpoints. This is used to re-key the entire conference. Each key is identified by a "Security Parameter Index" (SPI) value. Endpoints MUST expect that a conference might be re-keyed when a new participant joins a conference or when a participant leaves a conference in order to protect the confidentiality of the conversation before and after such events. The SRTP master salt to be used by the Endpoint is transmitted along with the EKT Key. All Endpoints in the conference utilize the same SRTP master salt that corresponds with a given EKT Key. The Full EKT Tag in media packets is encrypted using a cipher specified via the EKTKey message (e.g., AES Key Wrap with a 128-bit key). This cipher is different than the cipher used to protect media and is only used to encrypt the Endpoint's SRTP master key (and other EKT Tag data as per [I-D.ietf-perc-srtp-ekt-diet]). The Media Distributor is not given the KEK. Jones, et al. Expires December 7, 2019 [Page 17] Internet-Draft Private Media Framework June 2019 6.4. Endpoints fabricate an SRTP Master Key As stated earlier, the E2E key determined via DTLS-SRTP MAY be discarded in favor of a locally-generated E2E SRTP master key. While the DTLS-SRTP-derived SRTP master key can be used initially, the Endpoint might choose to change the SRTP master key periodically and MUST change the SRTP master key as a result of the EKT key changing. A locally-generated SRTP master key is used along with the master salt transmitted to the Endpoint from the Key Distributor via the EKTKey message to encrypt media end-to-end. Since the Media Distributor is not involved in E2E functions, it does not create this key nor have access to any Endpoint's E2E key. Note, too, that even the Key Distributor is unaware of the locally- generated E2E keys used by each Endpoint. The Endpoint transmits its E2E key to other Endpoints in the conference by periodically including it in SRTP packets in a Full EKT Tag. When placed in the Full EKT Tag, it is encrypted using the EKT Key provided by the Key Distributor. The master salt is not transmitted, though, since all Endpoints receive the same master salt via the EKTKey message from the Key Distributor. The recommended frequency with which an Endpoint transmits its SRTP master key is specified in [I-D.ietf-perc-srtp-ekt-diet]. 6.5. Summary of Key Types and Entity Possession All Endpoints have knowledge of the KEK. Every HBH key is distinct for a given Endpoint, thus Endpoint A and Endpoint B do not have knowledge of the other's HBH key. Since HBH keys are derived from a DTLS-SRTP association, there is at most one HBH key per Endpoint, (The only exception is where the DTLS-SRTP association might be rekeyed per Section 5.2 of [RFC5764] and a new key is created to replace the former key.) Each Endpoint generates its own E2E key (SRTP master key), thus there is a distinct E2E key per endpoint. This key is transmitted (encrypted) via the Full EKT Tag to other Endpoints. Endpoints that receive media from a given transmitting Endpoint gain knowledge of the transmitter's E2E key via the Full EKT Tag. To summarize the various keys and which entity is in possession of a given key, refer to Figure 5. Jones, et al. Expires December 7, 2019 [Page 18] Internet-Draft Private Media Framework June 2019 +----------------------+------------+-------+-------+------------+ | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | +----------------------+------------+-------+-------+------------+ | KEK (EKT Key) | Yes | No | No | Yes | +----------------------+------------+-------+-------+------------+ | E2E Key (A and B) | Yes | No | No | Yes | +----------------------+------------+-------+-------+------------+ | HBH Key (A<=>MD X) | Yes | Yes | No | No | +----------------------+------------+-------+-------+------------+ | HBH Key (B<=>MD Y) | No | No | Yes | Yes | +----------------------+------------+---------------+------------+ | HBH Key (MD X<=>MD Y)| No | Yes | Yes | No | +----------------------+------------+---------------+------------+ Figure 5: Keys Types and Entity Possession 7. Encrypted Media Packet Format Figure 6 presents a complete picture of what an encrypted media packet per this framework looks like when transmitted over the wire. The packet format shown is encrypted using the Double cryptographic transform with an EKT Tag appended to the end. Jones, et al. Expires December 7, 2019 [Page 19] Internet-Draft Private Media Framework June 2019 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|X| CC |M| PT | sequence number | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | timestamp | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | synchronization source (SSRC) identifier | IO +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO | contributing source (CSRC) identifiers | IO | .... | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O | RTP extension (OPTIONAL) ... | |O +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O I | payload ... | IO O I | +-------------------------------+ IO O I | | RTP padding | RTP pad count | IO O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O | | E2E authentication tag | |O O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O O | | OHB ... | |O +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ | | | HBH authentication tag | || | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | | | EKT Tag ... | R || | | +-+-+-+-+-+-+-+-+-+ | || | | +- Neither encrypted nor authenticated; || | | appended after Double is performed || | | || | | || | +- E2E Encrypted Portion E2E Authenticated Portion ---+| | | +--- HBH Encrypted Portion HBH Authenticated Portion ----+ I = Inner (E2E) encryption / authentication O = Outer (HBH) encryption / authentication Figure 6: Encrypted Media Packet Format 8. Security Considerations 8.1. Third Party Attacks Third party attacks are attacks attempted by an adversary that is not supposed to have access to keying material or is otherwise not an authorized participant in the conference. Jones, et al. Expires December 7, 2019 [Page 20] Internet-Draft Private Media Framework June 2019 On-path attacks are mitigated by hop-by-hop integrity protection and encryption. The integrity protection mitigates packet modification and encryption makes selective blocking of packets harder, but not impossible. Off-path attackers could try connecting to different PERC entities to send specifically crafted packets with an aim of forcing the receiver to forward or render bogus media packets. Endpoints and Media Distributors mitigate such an attack by performing hop-by-hop authentication and discarding packets that fail authentication. Another attack vector is a third party claiming to be a Media Distributor, fooling Endpoints into sending packets to the false Media Distributor instead of the correct one. The deceived sending Endpoints could incorrectly assume their packets have been delivered to Endpoints when they in fact have not. While this attack is possible, the result is a simple denial of service with no leakage of confidential information, since the false Media Distributor would not have access to either HBH or E2E encryption keys. A third party could cause a denial-of-service by transmitting many bogus or replayed packets toward receiving devices that ultimately degrade conference or device performance. Therefore, implementations might wish to devise mechanisms to safeguard against such illegitimate packets, such as utilizing rate-limiting or performing basic sanity-checks on packets (e.g., looking at packet length or expected sequence number ranges) before performing more expensive decryption operations. Use of mutual DTLS authentication (as required by DTLS-SRTP) also helps to prevent a denial-of-service attack by preventing a false Endpoint or false Media Distributor from successfully participating as a perceived valid media sender that could otherwise carry out an on-path attack. When mutual authentication fails, a receiving Endpoint would know that it could safely discard media packets received from the Endpoint without inspection. 8.2. Media Distributor Attacks A malicious or compromised Media Distributor can attack the session in a number of possible ways. 8.2.1. Denial of service A simple form of attack is discarding received packets that should be forwarded. This solution framework does not introduce any mitigation for Media Distributors that fail to forward media packets. Jones, et al. Expires December 7, 2019 [Page 21] Internet-Draft Private Media Framework June 2019 Another form of attack is modifying received packets before forwarding. With this solution framework, any modification of the end-to-end authenticated data results in the receiving Endpoint getting an integrity failure when performing authentication on the received packet. The Media Distributor can also attempt to perform resource consumption attacks on the receiving Endpoint. One such attack would be to insert random SSRC/CSRC values in any RTP packet along with a Full EKT Tag. Since such a message would trigger the receiver to form a new cryptographic context, the Media Distributor can attempt to consume the receiving Endpoint's resources. While E2E authentication would fail and the cryptographic context would be destroyed, the key derivation operation would nonetheless consume some computational resources. While resource consumption attacks cannot be mitigated entirely, rate-limiting packets might help reduce the impact of such attacks. 8.2.2. Replay Attack A replay attack is when an already received packet from a previous point in the RTP stream is replayed as new packet. This could, for example, allow a Media Distributor to transmit a sequence of packets identified as a user saying "yes", instead of the "no" the user actually said. A replay attack is mitigated by the requirement to implement replay protection as described in Section 3.3.2 of [RFC3711]. End-to-end replay protection MUST be provided for the duration of the conference. 8.2.3. Delayed Playout Attack A delayed playout attack is one where media is received and held by a Media Distributor and then forwarded to Endpoints at a later point in time. This attack is possible even if E2E replay protection is in place. Because the Media Distributor is allowed to select a subset of streams and not forward the rest to a receiver, such as in forwarding only the most active speakers, the receiver has to accept gaps in the E2E packet sequence. The issue with this is that a Media Distributor can select to not deliver a particular stream for a while. While the Media Distributor can purposely stop forwarding media flows, it can also select an arbitrary starting point to resume forwarding those media flow, perhaps forwarding old packets rather than current packets. As a consequence, what the media source sent Jones, et al. Expires December 7, 2019 [Page 22] Internet-Draft Private Media Framework June 2019 can be substantially delayed at the receiver with the receiver believing that newly arriving packets are delayed only by transport delay when the packets may actually be minutes or hours old. While this attack cannot be eliminated entirely, its effectiveness can be reduced by re-keying the conference periodically since significantly-delayed media encrypted with expired keys would not be decrypted by Endpoints. 8.2.4. Splicing Attack A splicing attack is an attack where a Media Distributor receiving multiple media sources splices one media stream into the other. If the Media Distributor were able to change the SSRC without the receiver having any method for verifying the original source ID, then the Media Distributor could first deliver stream A and then later forward stream B under the same SSRC as stream A was previously using. By including the SSRC in the integrity check for each packet, both HBH and E2E, PERC prevents splicing attacks. 8.2.5. RTCP Attacks PERC does not provide end-to-end protection of RTCP messages. This allows a compromised Media Distributor to impact any message that might be transmitted via RTCP, including media statistics, picture requests, or loss indication. It is also possible for a compromised Media Distributor to forge requests, such as requests to the Endpoint to send a new picture. Such requests can consume significant bandwidth and impair conference performance. 8.3. Key Distributor Attacks As stated in Section 3.2.2, the Key Distributor needs to be secured since exploiting the Key Server can allow an adversary to gain access to the keying material for one or more conferences. Having access to that keying material would then allow the adversary to decrypt media sent from any Endpoint in the conference. As a first line of defense, the Key Distributor authenticates every security association, both associations with Endpoints and Media Distributors. The Key Distributor knows which entities are authorized to have access to which keys and inspection of certificates will substantially reduce the risk of providing keys to an adversary. Both physical and network access to the Key Distributor should be severely restricted. This may be more difficult to achieve when the Key Distributor is embedded within and Endpoint, for example. Jones, et al. Expires December 7, 2019 [Page 23] Internet-Draft Private Media Framework June 2019 Nonetheless, consideration should be given to shielding the Key Distributor from unauthorized access or any access that is not strictly necessary for the support of an ongoing conference. Consideration should be given to whether access to the keying material will be needed beyond the conclusion of a conference. If not needed, the Key Distributor's policy should be to destroy the keying material once the conference concludes or when keying material changes during the course of the conference. If keying material is needed beyond the lifetime of the conference, further consideration should be given to protecting keying material from future exposure. While it might be obvious, it is worth stating to avoid any doubt that if an adversary were to record the media packets transmitted during a conference and then gain unauthorized access to the keying material left unsecured on the Key Distributor even years later, the adversary could decrypt the content every packet transmitted during the conference. 8.4. Endpoint Attacks A Trusted Endpoint is so named because conference confidentiality relies heavily on the security and integrity of the Endpoint. If an adversary successfully exploits a vulnerability in an Endpoint, it might be possible for the adversary to obtain all of the keying material used in the conference. With that keying material, an adversary could decrypt any of the media flows received from any other Endpoint, either in real-time or at a later point in time (assuming the adversary makes a copy of the media packets). Additionally, if an adversary successfully exploits an Endpoint, the adversary could inject media into the conference. One way an adversary could do that is by manipulating the RTP or SRTP software to transmit whatever media the adversary wishes to send. This could involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing endpoint. This is made possible since all conference participants share the same KEK. Only a single SRTP cipher suite defined provides source authentication properties that allow an endpoint to cryptographically assert that it sent a particular E2E protected packet (namely, TESLA [RFC4383]), and its usage is presently not defined for PERC. The suite defined in PERC only allows an Endpoint to determine that whoever sent a packet had received the KEK. However, attacks on the endpoint are not limited to the PERC-specific software within the Endpoint. An attacker could inject media or record media by manipulating the software that sits between the PERC- enabled application and the hardware microphone of video camera, for example. Likewise, an attacker could potentially access confidential Jones, et al. Expires December 7, 2019 [Page 24] Internet-Draft Private Media Framework June 2019 media by accessing memory, cache, disk storage, etc. if the endpoint is no secured. 9. IANA Considerations There are no IANA considerations for this document. 10. Acknowledgments The authors would like to thank Mo Zanaty, Christian Oien, and Richard Barnes for invaluable input on this document. Also, we would like to acknowledge Nermeen Ismail for serving on the initial versions of this document as a co-author. We would also like to acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for providing some of the text in the document, including much of the original text in the security considerations section. 11. References 11.1. Normative References [I-D.ietf-perc-double] Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Double Encryption Procedures", draft-ietf-perc-double-10 (work in progress), October 2018. [I-D.ietf-perc-srtp-ekt-diet] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress), October 2018. [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, . Jones, et al. Expires December 7, 2019 [Page 25] Internet-Draft Private Media Framework June 2019 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.ietf-perc-dtls-tunnel] Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05 (work in progress), April 2019. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [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, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [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, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [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, . Jones, et al. Expires December 7, 2019 [Page 26] Internet-Draft Private Media Framework June 2019 [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, . [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, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [W3C.CR-webrtc-20180927] Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium CR CR-webrtc-20180927, September 2018, . Authors' Addresses Paul E. Jones Cisco 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 USA Phone: +1 919 476 2048 Email: paulej@packetizer.com David Benham Independent Email: dabenham@gmail.com Jones, et al. Expires December 7, 2019 [Page 27] Internet-Draft Private Media Framework June 2019 Christian Groves Independent Melbourne Australia Email: cngroves.std@gmail.com Jones, et al. Expires December 7, 2019 [Page 28] ./draft-ietf-pce-inter-area-as-applicability-08.txt0000644000764400076440000016154713510736114021420 0ustar iustyiustyPCE Working Group D. King Internet Draft Old Dog Consulting Intended status: Informational H. Zheng Expires: January 9, 2020 Huawei Technologies July 8, 2019 Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering draft-ietf-pce-inter-area-as-applicability-08 Abstract The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. 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 https://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 9, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 King, et al. Expires January, 2020 [Page 1] Internet-Draft Inter-Area-AS Applicability July 2019 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.................................................3 1.1. Domains.................................................4 1.2. Path Computation........................................4 1.2.1 PCE-based Path Computation Procedure.................5 1.3. Traffic Engineering Aggregation and Abstraction.........6 1.4. Traffic Engineered Label Switched Paths.................6 1.5. Inter-area and Inter-AS Capable PCE Discovery...........6 1.6. Objective Functions.....................................6 2. Terminology..................................................7 3. Issues and Considerations....................................7 3.1 Multi-homing.............................................7 3.2 Destination Location.....................................8 3.3 Domain Confidentiality ..................................8 4. Domain Topologies............................................8 4.1 Selecting Domain Paths...................................8 4.2 Domain Sizes.............................................9 4.3 Domain Diversity.........................................9 4.4 Synchronized Path Computations...........................9 4.5 Domain Inclusion or Exclusion............................9 5. Applicability of the PCE to Inter-area Traffic Engineering...10 5.1. Inter-area Routing......................................11 5.1.1. Area Inclusion and Exclusion..........................11 5.1.2. Strict Explicit Path and Loose Path...................11 5.1.3. Inter-Area Diverse Path Computation...................11 6. Applicability of the PCE to Inter-AS Traffic Engineering.....12 6.1. Inter-AS Routing........................................12 6.1.1. AS Inclusion and Exclusion............................12 6.2. Inter-AS Bandwidth Guarantees...........................12 6.3. Inter-AS Recovery.......................................13 6.4. Inter-AS PCE Peering Policies...........................13 7. Multi-Domain PCE Deployment..................................13 7.1 Traffic Engineering Database.............................13 7.1.1. Applicability of BGP-LS to PCE........................14 7.2 Pre-Planning and Management-Based Solutions..............14 8. Domain Confidentiality.......................................15 8.1 Loose Hops...............................................15 8.2 Confidential Path Segments and Path Keys.................15 9. Point-to-Multipoint..........................................16 10. Optical Domains.............................................16 10.1 Abstraction and Control of TE Networks (ACTN)...........17 11. Policy......................................................17 King, et al. Expires January, 2020 [Page 2] Internet-Draft Inter-Area-AS Applicability July 2019 12. Manageability Considerations................................18 12.1 Control of Function and Policy...........................18 12.2 Information and Data Models..............................18 12.3 Liveness Detection and Monitoring........................19 12.4 Verifying Correct Operation..............................19 12.5 Impact on Network Operation..............................19 13. Security Considerations.....................................19 13.1 Multi-domain Security....................................19 14. IANA Considerations.........................................20 15. Acknowledgements............................................20 16. References..................................................20 16.1. Normative References....................................20 16.2. Informative References..................................21 17. Contributors................................................24 18. Author's Addresses..........................................25 1. Introduction Computing paths across large multi-domain environments may require special computational components and cooperation between entities in different domains capable of complex path computation. Issues that may exist when routing in multi-domain networks include: o Often there is a lack of full topology and TE information across domains; o No single node has the full visibility to determine an optimal or even feasible end-to-end path across domains; o How to evaluate and select the exit point and next domain boundary from a domain? o How might the ingress node determine which domains should be used for the end-to-end path? Often information exchange across multiple domains is limited due to the lack of trust relationship, security issues, or scalability issues even if there is a trust relationship between domains. The Path Computation Element (PCE) [RFC4655] provides an architecture and a set of functional components to address the problem space, and issues highlighted above. A PCE may be used to compute end-to-end paths across multi-domain environments using a per-domain path computation technique [RFC5152]. The so called backward recursive path computation (BRPC) mechanism [RFC5441] defines a PCE-based path computation procedure to compute inter-domain constrained Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. However, King, et al. Expires January, 2020 [Page 3] Internet-Draft Inter-Area-AS Applicability July 2019 both per-domain and BRPC techniques assume that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means. In more advanced deployments (including multi-area and multi- Autonomous System (multi-AS) environments) the sequence of domains may not be known in advance and the choice of domains in the end-to- end domain sequence might be critical to the determination of an optimal end-to-end path. In this case the use of the Hierarchical PCE [RFC6805] architecture and mechanisms may be used to discover the intra-area path and select the optimal end-to-end domain sequence. This document describes the processes and procedures available when using the PCE architecture and protocols, for computing inter-area and inter-AS MPLS and GMPLS Traffic Engineered paths. This document scope does not include discussion on stateful PCE, active PCE, remotely initiated PCE, or PCE as a central controller (PCECC) deployment scenarios. 1.1 Domains Generally, a domain can be defined as a separate administrative, geographic, or switching environment within the network. A domain may be further defined as a zone of routing or computational ability. Under these definitions a domain might be categorized as an Autonomous System (AS) or an Interior Gateway Protocol (IGP) area (as per [RFC4726] and [RFC4655]). For the purposes of this document, a domain is considered to be a collection of network elements within an area or AS that has a common sphere of address management or path computational responsibility. Wholly or partially overlapping domains are not within the scope of this document. In the context of GMPLS, a particularly important example of a domain is the Automatically Switched Optical Network (ASON) subnetwork [G-8080]. In this case, computation of an end-to-end path requires the selection of nodes and links within a parent domain where some nodes may, in fact, be subnetworks. Furthermore, a domain might be an ASON routing area [G-7715]. A PCE may perform the path computation function of an ASON routing controller as described in [G-7715-2]. It is assumed that the PCE architecture is not applied to a large group of domains, such as the Internet. 1.2 Path Computation King, et al. Expires January, 2020 [Page 4] Internet-Draft Inter-Area-AS Applicability July 2019 For the purpose of this document, it is assumed that the path computation is the sole responsibility of the PCE as per the architecture defined in [RFC4655]. When a path is required the Path Computation Client (PCC) will send a request to the PCE. The PCE will apply the required constraints and compute a path and return a response to the PCC. In the context of this document it may be necessary for the PCE to co-operate with other PCEs in adjacent domains (as per BRPC [RFC5441]) or cooperate with a Parent PCE (as per [RFC6805]). It is entirely feasible that an operator could compute a path across multiple domains without the use of a PCE if the relevant domain information is available to the network planner or network management platform. The definition of what relevant information is required to perform this network planning operation and how that information is discovered and applied is outside the scope of this document. 1.2.1 PCE-based Path Computation Procedure As highlighted, the PCE is an entity capable of computing an inter-domain TE path upon receiving a request from a PCC. There could be a single PCE per domain, or single PCE responsible for all domains. A PCE may or may not reside on the same node as the requesting PCC. A path may be computed by either a single PCE node or a set of distributed PCE nodes that collaborate during path computation. [RFC4655] defines that a PCC should send a path computation request to a particular PCE, using [RFC5440] (PCC-to-PCE communication). This negates the need to broadcast a request to all the PCEs. Each PCC can maintain information about the computation capabilities of the PCEs, it is aware of. The PCC-PCE capability awareness can be configured using static configurations or by automatic and dynamic PCE discovery procedures. If a network path is required, the PCC will send a path computation request to the PCE. A PCE may then compute the end-to-end path if it is aware of the topology and TE information required to compute the entire path. If the PCE is unable to compute the entire path, the PCE architecture provides co-operative PCE mechanisms for the resolution of path computation requests when an individual PCE does not have sufficient TE visibility. End-to-end path segments may be kept confidential through the application of path keys, to protect partial or full path information. A path key that is a token that replaces a path segment in an explicit route. The path key mechanism is described in [RFC5520] King, et al. Expires January, 2020 [Page 5] Internet-Draft Inter-Area-AS Applicability July 2019 1.3 Traffic Engineering Aggregation and Abstraction Networks are often constructed from multiple areas or ASes that are interconnected via multiple interconnect points. To maintain network confidentiality and scalability TE properties of each area and AS are not generally advertized outside each specific area or AS. TE aggregation or abstraction provide mechanism to hide information but may cause failed path setups or the selection of suboptimal end-to-end paths [RFC4726]. The aggregation process may also have significant scaling issues for networks with many possible routes and multiple TE metrics. Flooding TE information breaks confidentiality and does not scale in the routing protocol. The PCE architecture and associated mechanisms provide a solution to avoid the use of TE aggregation and abstraction. 1.4 Traffic Engineered Label Switched Paths This document highlights the PCE techniques and mechanisms that exist for establishing TE packet and optical LSPs across multiple areas (inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and within the remainder of this document, we consider all LSPs to be constraint-based and traffic engineered. Three signaling options are defined for setting up an inter-area or inter-AS LSP [RFC4726]: o Contiguous LSP o Stitched LSP o Nested LSP All three signaling methods are applicable to the architectures and procedures discussed in this document. 1.5 Inter-area and Inter-AS Capable PCE Discovery When using a PCE-based approach for inter-area and inter-AS path computation, a PCE in one area or AS may need to learn information related to inter-AS capable PCEs located in other ASes. The PCE discovery mechanism defined in [RFC5088] and [RFC5089] facilitates the discovery of PCEs, and disclosure of information related to inter-area and inter-AS capable PCEs. 1.6 Objective Functions An Objective Function (OF) [RFC5541], or set of OFs, specifies the intentions of the path computation and so defines the "optimality", King, et al. Expires January, 2020 [Page 6] Internet-Draft Inter-Area-AS Applicability July 2019 in the context of the computation request. An OF specifies the desired outcome of a computation. An OF does not describe or specify the algorithm to use. Also, an implementation may apply any algorithm, or set of algorithms, to achieve the result indicated by the OF. A number of general OFs are specified in [RFC5541]. Various OFs may be included in the PCE computation request to satisfy the policies encoded or configured at the PCC, and a PCE may be subject to policy in determining whether it meets the OFs included in the computation request or applies its own OFs. During inter-domain path computation, the selection of a domain sequence, the computation of each (per-domain) path fragment, and the determination of the end-to-end path may each be subject to different OFs and policy. 2. Terminology This document also uses the terminology defined in [RFC4655] and [RFC5440]. Additional terminology is defined below: ABR: IGP Area Border Router, a router that is attached to more than one IGP area. ASBR: Autonomous System Border Router, a router used to connect together ASes of a different or the same Service Provider via one or more inter-AS links. Inter-area TE LSP: A TE LSP whose path transits through two or more IGP areas. Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or more ASes or sub-ASes (BGP confederations SRLG: Shared Risk Link Group. TED: Traffic Engineering Database, which contains the topology and resource information of the domain. The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means. 3. Issues and Considerations 3.1 Multi-homing King, et al. Expires January, 2020 [Page 7] Internet-Draft Inter-Area-AS Applicability July 2019 Networks constructed from multi-areas or multi-AS environments may have multiple interconnect points (multi-homing). End-to-end path computations may need to use different interconnect points to avoid a single point failure disrupting both primary and backup services. 3.2 Destination Location The PCC asking for an inter-domain path computation is typically aware of the identity of the destination node. If the PCC is aware of the destination domain, it may supply the destination domain information as part of the path computation request. However, if the PCC does not know the destination domain this information must be determined by another method. 3.3 Domain Confidentiality Where the end-to-end path crosses multiple domains, it may be possible that each domain (AS or area) 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. If confidentiality is required between domains (ASes and areas) belonging to different Service Providers, then cooperating PCEs cannot exchange path segments or else the receiving PCE or PCC will be able to see the individual hops through another domain. This topic is discussed further in Section 8 of this document. 4. Domain Topologies Constraint-based inter-domain path computation is a fundamental requirement for operating traffic engineered MPLS [RFC3209] and GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain) environments. Path computation across multi-domain networks is complex and requires computational co-operational entities like the PCE. 4.1 Selecting Domain Paths Where the sequence of domains is known a priori, various techniques can be employed to derive an optimal multi-domain path. If the domains are connected to a simple path with no branches and single links between all domains, or if the preferred points of interconnection is also known, the Per-Domain Path Computation [RFC5152] technique may be used. Where there are multiple connections between domains and there is no preference for the choice of points King, et al. Expires January, 2020 [Page 8] Internet-Draft Inter-Area-AS Applicability July 2019 of interconnection, BRPC [RFC5441] can be used to derive an optimal path. When the sequence of domains is not known in advance, or the end-to-end path will have to navigate a mesh of small domains (especially typical in optical networks), the optimum path may be derived through the application of a Hierarchical PCE [RFC6805]. 4.2 Domain Sizes Very frequently network domains are composed of dozens or hundreds of network elements. These network elements are usually interconnected in a partial-mesh fashion, to provide survivability against dual failures, and to benefit from the traffic engineering capabilities from MPLS and GMPLS protocols. Network operator feedback in the development of the document highlighted that node degree (the number of neighbors per node) typically ranges from 3 to 10 (4-5 is quite common). 4.3 Domain Diversity Domain and path diversity may also be required when computing end-to-end paths. Domain diversity should facilitate the selection of paths that share ingress and egress domains, but do not share transit domains. Therefore, there must be a method allowing the inclusion or exclusion of specific domains when computing end-to-end paths. 4.4 Synchronized Path Computations In some scenarios, it would be beneficial for the operator to rely on the capability of the PCE to perform synchronized path computation. Synchronized path computations, known as Synchronization VECtors (SVECs) are used for dependent path computations. SVECs are defined in [RFC5440] and [RFC6007] provides an overview for the use of the PCE SVEC list for synchronized path computations when computing dependent requests. In H-PCE deployments, a child PCE will be able to request both dependent and synchronized domain diverse end to end paths from its parent PCE. 4.5 Domain Inclusion or Exclusion A domain sequence is an ordered sequence of domains traversed to reach the destination domain. A domain sequence may be supplied during path computation to guide the PCEs or derived via the use of King, et al. Expires January, 2020 [Page 9] Internet-Draft Inter-Area-AS Applicability July 2019 Hierarchical PCE (H-PCE). During multi-domain path computation, a PCC may request specific domains to be included or excluded in the domain sequence using the Include Route Object (IRO) [RFC5440] and Exclude Route Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an abstract node representing a domain is defined in [RFC3209]. [RFC7897] specifies new sub-objects to include or exclude domains such as an IGP area or a 4-Byte AS number. An operator may also need to avoid a path that uses specified nodes for administrative reasons, or if a specific connectivity service required to have a 1+1 protection capability, two completely disjoint paths must be established. A mechanism known as Shared Risk Link Group (SRLG) information may be used to ensure path diversity. 5. Applicability of the PCE to Inter-area Traffic Engineering As networks increase in size and complexity, it may be required to introduce scaling methods to reduce the amount of information flooded within the network and make the network more manageable. An IGP hierarchy is designed to improve IGP scalability by dividing the IGP domain into areas and limiting the flooding scope of topology information to within area boundaries. This restricts visibility of the area to routers in a single area. If a router needs to compute the route to a destination located in another area, a method would be required to compute a path across area boundaries. In order to support multiple vendors in a network, in cases where data or control plane technologies cannot interoperate, it is useful to divide the network into vendor domains. Each vendor domain is an IGP area, and the flooding scope of the topology (as well as any other relevant information) is limited to the area boundaries. Per-domain path computation [RFC5152] exists to provide a method of inter-area path computation. The per-domain solution is based on loose hop routing with an Explicit Route Object (ERO) expansion on each Area Border Router (ABR). This allows an LSP to be established using a constrained path, however at least two issues exist: o This method does not guarantee an optimal constrained path. o The method may require several crankback signaling messages, as per [RFC4920], increasing signaling traffic and delaying the LSP setup. The PCE-based architecture [RFC4655] is designed to solve inter-area King, et al. Expires January, 2020 [Page 10] Internet-Draft Inter-Area-AS Applicability July 2019 path computation problems. The issue of limited topology visibility is resolved by introducing path computation entities that are able to cooperate in order to establish LSPs with source and destinations located in different areas. 5.1. Inter-area Routing An inter-area 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 for scaling and privacy purposes, a node in one area will not be able to compute an end-to-end path across multiple areas without the use of a PCE. 5.1.1. Area Inclusion and Exclusion The BRPC method [RFC5441] of path computation provides a more optimal method to specify inclusion or exclusion of an ABR. Using the BRPC procedure an end-to-end path is recursively computed in reverse from the destination domain, towards the source domain. Using this method, an operator might decide if an area must be included or excluded from the inter-area path computation. 5.1.2. Strict Explicit Path and Loose Path A strict explicit Path is defined as a set of strict hops, while a loose path is defined as a set of at least one loose hop and zero or more strict hops. It may be useful to indicate, during the path computation request, if a strict explicit path is required or not. An inter-area path may be strictly explicit or loose (e.g., a list of ABRs as loose hops). A PCC request to a PCE does allow the indication of whether a strict explicit path across specific areas ([RFC7897]) is required or desired, or if the path request is loose. 5.1.3. Inter-Area Diverse Path Computation It may be necessary to compute a path that is partially or entirely diverse, from a previously computed path, to avoid fate sharing of a primary service with a corresponding backup service. There are various levels of diversity in the context of an inter-area network: o Per-area diversity (intra-area path segments are link, node or SRLG disjoint. o Inter-area diversity (end-to-end inter-area paths are link, node or SRLG disjoint). King, et al. Expires January, 2020 [Page 11] Internet-Draft Inter-Area-AS Applicability July 2019 Note that two paths may be disjoint in the backbone area but non- disjoint in peripheral areas. Also, two paths may be node disjoint within areas but may share ABRs, in which case path segments within an area is node disjoint, but end-to-end paths are not node-disjoint. Per-Domain [RFC5152], BRPC [RFC5441] and H-PCE [RFC6805] mechanisms all support the capability to compute diverse paths across multi-area topologies. 6. Applicability of the PCE to Inter-AS Traffic Engineering As discussed in section 4 (Applicability of the PCE to Inter-area Traffic Engineering) it is necessary to divide the network into smaller administrative domains, or ASes. If an LSR within an AS needs to compute a path across an AS boundary, it must also use an inter-AS computation technique. [RFC5152] defines mechanisms for the computation of inter-domain TE LSPs using network elements along the signaling paths to compute per-domain constrained path segments. The PCE was designed to be capable of computing MPLS and GMPLS paths across AS boundaries. This section outlines the features of a PCE-enabled solution for computing inter-AS paths. 6.1 Inter-AS Routing 6.1.1. AS Inclusion and Exclusion [RFC5441] allows the specifying of inclusion or exclusion of an AS or an ASBR. Using this method, an operator might decide if an AS must be include or exclude from the inter-AS path computation. Exclusion and/or inclusion could also be specified at any step in the LSP path computation process by a PCE (within the BRPC algorithm) but the best practice would be to specify them at the edge. In opposition to the strict and loose path, AS inclusion or exclusion doesn't impose topology disclosure as ASes are public entity as well as their interconnection. 6.2 Inter-AS Bandwidth Guarantees Many operators with multi-AS domains will have deployed MPLS-TE DiffServ either across their entire network or at the domain edges on CE-PE links. In situations where strict QOS bounds are required, admission control inside the network may also be required. When the propagation delay can be bounded, the performance targets, such as maximum one-way transit delay may be guaranteed by providing bandwidth guarantees along the DiffServ-enabled path, these requirements are described in [RFC4216]. King, et al. Expires January, 2020 [Page 12] Internet-Draft Inter-Area-AS Applicability July 2019 One typical example of the requirements in [RFC4216] is to provide bandwidth guarantees over an end-to-end path for VoIP traffic classified as EF (Expedited Forwarding) class in a DiffServ-enabled network. In the case where the EF path is extended across multiple ASes, inter-AS bandwidth guarantee would be required. Another case for inter-AS bandwidth guarantee is the requirement for guaranteeing a certain amount of transit bandwidth across one or multiple ASes. 6.3 Inter-AS Recovery During a path computation process, a PCC request may contain the requirement to compute a backup LSP for protecting the primary LSP, 1+1 protection. A single LSP or multiple backup LSPs may also be used for a group of primary LSPs, this is typically known as m:n protection. Other inter-AS recovery mechanisms include [RFC4090] which adds fast re-route (FRR) protection to an LSP. So, the PCE could be used to trigger computation of backup tunnels in order to protect Inter-AS connectivity. Inter-AS recovery clearly requires backup LSPs for service protection but it would also be advisable to have multiple PCEs deployed for path computation redundancy, especially for service restoration in the event of catastrophic network failure. 6.4 Inter-AS PCE Peering Policies Like BGP peering policies, inter-AS PCE peering policies is a requirement for operator. In inter-AS BRPC process, PCE must cooperate in order to compute the end-to-end LSP. So, the AS path must not only follow technical constraints, e.g. bandwidth availability, but also policies defined by the operator. Typically PCE interconnections at an AS level must follow agreed contract obligations, also known as peering agreements. The PCE peering policies are the result of the contract negotiation and govern the relation between the different PCE. 7. Multi-domain PCE Deployment Options 7.1 Traffic Engineering Database and Synchronization An optimal path computation requires knowledge of the available network resources, including nodes and links, constraints, King, et al. Expires January, 2020 [Page 13] Internet-Draft Inter-Area-AS Applicability July 2019 link connectivity, available bandwidth, and link costs. The PCE operates on a view of the network topology as presented by a TED. As discussed in [RFC4655] the TED used by a PCE may be learnt by the relevant IGP extensions. Thus, the PCE may operate its TED is by participating in the IGP running in the network. In an MPLS-TE network, this would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS network it would utilize the GMPLS extensions to OSPF and IS-IS defined in [RFC4203] and [RFC5307]. Inter-as connectivity information may be populated via [RFC5316] and [RFC5392]. An alternative method to provide network topology and resource information is offered by [RFC7752], which is described in the following section. 7.1.1 Applicability of BGP-LS to PCE The concept of exchange of TE information between Autonomous Systems (ASes) is discussed in [RFC7752]. The information exchanged in this way could be the full TE information from the AS, an aggregation of that information, or a representation of the potential connectivity across the AS. Furthermore, that information could be updated frequently (for example, for every new LSP that is set up across the AS) or only at threshold-crossing events. In an H-PCE deployment, the parent PCE will require the inter-domain topology and link status between child domains. This information may be learnt by a BGP-LS speaker and provided to the parent PCE, furthermore link-state performance including delay, available bandwidth and utilized bandwidth may also be provided to the parent PCE for optimal path link selection. 7.2 Pre-Planning and Management-Based Solutions Offline path computation is performed ahead of time, before the LSP setup is requested. That means that it is requested by, or performed as part of, an Operation Support System (OSS) management application. This model can be seen in Section 5.5 of [RFC4655]. The offline model is particularly appropriate to long-lived LSPs (such as those present in a transport network) or for planned responses to network failures. In these scenarios, more planning is normally a feature of LSP provisioning. The management system may also use a PCE and BRPC to pre-plan an AS sequence, and the source domain PCE and per-domain path computation to be used when the actual end-to-end path is King, et al. Expires January, 2020 [Page 14] Internet-Draft Inter-Area-AS Applicability July 2019 required. This model may also be used where the operator wishes to retain full manual control of the placement of LSPs, using the PCE only as a computation tool to assist the operator, not as part of an automated network. In environments where operators peer with each other to provide end- to-end paths, the operator responsible for each domain must agree to what extent paths must be pre-planned or manually controlled. 8. Domain Confidentiality This section discusses the techniques that co-operating PCEs can use to compute inter-domain paths without each domain disclosing sensitive internal topology information (such as explicit nodes or links within the domain) to the other domains. Confidentiality typically applies to inter-provider (inter-AS) PCE communication. Where the TE LSP crosses multiple domains (ASes or areas), the path may be computed by multiple PCEs that cooperate together. With each local PCE responsible for computing a segment of the path. In situations where ASes are administered by separate Service Providers, it would break confidentiality rules for a PCE to supply a path segment details to a PCE responsible another domain, thus disclosing AS-internal or area topology information. 8.1 Loose Hops A method for preserving the confidentiality of the path segment is for the PCE to return a path containing a loose hop in place of the segment that must be kept confidential. The concept of loose and strict hops for the route of a TE LSP is described in [RFC3209]. [RFC5440] supports the use of paths with loose hops, and it is a local policy decision at a PCE whether it returns a full explicit path with strict hops or uses loose hops. A path computation request may require an explicit path with strict hops, or may allow loose hops as detailed in [RFC5440]. 8.2 Confidential Path Segments and Path Keys [RFC5520] defines the concept and mechanism of Path-Key. A Path-Key is a token that replaces the path segment information in an explicit route. The Path-Key allows the explicit route information to be encoded and in the PCEP ([RFC5440]) messages exchanged between the King, et al. Expires January, 2020 [Page 15] Internet-Draft Inter-Area-AS Applicability July 2019 PCE and PCC. This Path-Key technique allows explicit route information to be used for end-to-end path computation, without disclosing internal topology information between domains. 9. Point-to-Multipoint For inter-domain point-to-multipoint application scenarios using MPLS-TE LSPs, the complexity of domain sequences, domain policies, choice and number of domain interconnects is magnified compared to point-to-point path computations. As the size of the network grows, the number of leaves and branches increase, further increasing the complexity of the overall path computation problem. A solution for managing point-to-multipoint path computations may be achieved using the PCE inter-domain point-to-multipoint path computation [RFC7334] procedure. 10. Optical Domains The International Telecommunications Union (ITU) defines the ASON architecture in [G-8080]. [G-7715] defines the routing architecture for ASON and introduces a hierarchical architecture. In this architecture, the Routing Areas (RAs) have a hierarchical relationship between different routing levels, which means a parent (or higher level) RA can contain multiple child RAs. The interconnectivity of the lower RAs is visible to the higher-level RA. In the ASON framework, a path computation request is termed a Route Query. This query is executed before signaling is used to establish an LSP termed a Switched Connection (SC) or a Soft Permanent Connection (SPC). [G-7715-2] defines the requirements and architecture for the functions performed by Routing Controllers (RC) during the operation of remote route queries - an RC is synonymous with a PCE. In the ASON routing environment, an RC responsible for an RA may communicate with its neighbor RC to request the computation of an end-to-end path across several RAs. The path computation components and sequences are defined as follows: o Remote route query. An operation where a routing controller communicates with another routing controller, which does not have the same set of layer resources, in order to compute a routing path in a collaborative manner. King, et al. Expires January, 2020 [Page 16] Internet-Draft Inter-Area-AS Applicability July 2019 o Route query requester. The connection controller or RC that sends a route query message to a routing controller requesting for one or more routing paths that satisfy a set of routing constraints. o Route query responder. An RC that performs path computation upon reception of a route query message from a routing controller or connection controller, sending a response back at the end of computation. When computing an end-to-end connection, the route may be computed by a single RC or multiple RCs in a collaborative manner and the two scenarios can be considered a centralized remote route query model and distributed remote route query model. RCs in an ASON environment can also use the hierarchical PCE [RFC6805] model to match fully the ASON hierarchical routing model. 10.1 Abstraction and Control of TE Networks (ACTN) Where a single operator operates multiple TE domains (including optical environments) then Abstraction and Control of TE Networks (ACTN) framework [RFC8453] may be used to create an abstracted (virtualized network) view of underlay interconnected domains. This underlay connectivity then be exposed to higher-layer control entities and applications. ACTN describes the method and procedure for coordinating the underlay per-domain Physical Network Controllers (PNCs), which may be PCEs, via a hierarchical model to facilitate setup of end-to-end connections across inter-connected TE domains. 11. Policy Policy is important in the deployment of new services and the operation of the network. [RFC5394] provides a framework for PCE- based policy-enabled path computation. This framework is based on the Policy Core Information Model (PCIM) as defined in [RFC3060] and further extended by [RFC3460]. When using a PCE to compute inter-domain paths, policy may be invoked by specifying: o Each PCC must select which computations will be requested to a PCE; o Each PCC must select which PCEs it will use; o Each PCE must determine which PCCs are allowed to use its services and for what computations; King, et al. Expires January, 2020 [Page 17] Internet-Draft Inter-Area-AS Applicability July 2019 o The PCE must determine how to collect the information in its TED, whom to trust for that information, and how to refresh/update the information; o Each PCE must determine which objective functions and which algorithms to apply. 12. Manageability Considerations General PCE management considerations are discussed in [RFC4655]. In the case of multi-domains within a single service provider network, the management responsibility for each PCE would most likely be handled by the same service provider. In the case of multiple ASes within different service provider networks, it will likely be necessary for each PCE to be configured and managed separately by each participating service provider, with policy being implemented based on a previously agreed set of principles. 12.1 Control of Function and Policy As per PCEP [RFC5440] implementation allow the user to configure a number of PCEP session parameters. These are detailed in section 8.1 of [RFC5440]. In H-PCE deployments the administrative entity responsible for the management of the parent PCEs for multi-areas would typically be a single service provider. In the multiple ASes (managed by different service providers), it may be necessary for a third party to manage the parent PCE. 12.2 Information and Data Models A PCEP MIB module is defined in [RFC7420] that describes managed objects for modeling of PCEP communication including: o PCEP client configuration and status, o PCEP peer configuration and information, o PCEP session configuration and information, o Notifications to indicate PCEP session changes. A YANG module for PCEP has also been proposed [PCEP-YANG]. An H-PCE MIB module, or YANG data model, will be required to report parent PCE and child PCE information, including: King, et al. Expires January, 2020 [Page 18] Internet-Draft Inter-Area-AS Applicability July 2019 o parent PCE configuration and status, o child PCE configuration and information, o notifications to indicate session changes between parent PCEs and child PCEs, and o notification of parent PCE TED updates and changes. 12.3 Liveness Detection and Monitoring PCEP includes a keepalive mechanism to check the liveliness of a PCEP peer and a notification procedure allowing a PCE to advertise its overloaded state to a PCC. In a multi-domain environment [RFC5886] provides the procedures necessary to monitor the liveliness and performances of a given PCE chain. 12.4 Verifying Correct Operation It is important to verify the correct operation of PCEP, [RFC5440] specifies the monitoring of key parameters. These parameters are detailed in [RFC5520]. 12.5 Impact on Network Operation [RFC5440] states that in order to avoid any unacceptable impact on network operations, a PCEP implementation should allow a limit to be placed on the number of sessions that can be set up on a PCEP speaker, it may also be practical to place a limit on the rate of messages sent by a PCC and received my the PCE. 13. Security Considerations PCEP Security considerations are discussed in [RFC5440] and [RFC6952] Potential vulnerabilities include spoofing, snooping, falsification and using PCEP as a mechanism for denial of service attacks. As PCEP operates over TCP, it may make use of TCP security encryption mechanisms, such as Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO). Usage of these security mechanisms for PCEP is described in [RFC8253], and recommendations and best current practices in [RFC7525]. 13.1 Multi-domain Security Any multi-domain operation necessarily involves the exchange of information across domain boundaries. This does represent King, et al. Expires January, 2020 [Page 19] Internet-Draft Inter-Area-AS Applicability July 2019 significant security and confidentiality risk. It is expected that PCEP is used between PCCs and PCEs belonging to the same administrative authority, and using one of the aforementioned encryption mechanisms. Furthermore, PCEP allows individual PCEs to maintain confidentiality of their domain path information using path-keys. 14. IANA Considerations This document makes no requests for IANA action. 15. Acknowledgements The author would like to thank Adrian Farrel for his review, and Meral Shirazipour and Francisco Javier Jimenex Chico for their comments. 16. References 16.1. Normative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter- Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", King, et al. Expires January, 2020 [Page 20] Internet-Draft Inter-Area-AS Applicability July 2019 RFC 5152, February 2008. [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter- domain Traffic Engineering Label Switched Paths", RFC5441, April 2009. [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. [RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC5541, December 2008. [RFC6805] King, D. and A. Farrel, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS", RFC6805, July 2010. 16.2. Informative References [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi- Protocol Label Switching (GMPLS)", RFC 4203, October 2005. King, et al. Expires January, 2020 [Page 21] Internet-Draft Inter-Area-AS Applicability July 2019 [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", December 2008. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009. [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path ComputationElement (PCE)-Based Architecture", RFC 5886, June 2010. [RFC6007] Nishioka, I., King, D., "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC6007, September 2010. [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for the automatically switched optical network (ASON). [G-7715] ITU-T Recommendation G.7715 (2002), Architecture King, et al. Expires January, 2020 [Page 22] Internet-Draft Inter-Area-AS Applicability July 2019 and Requirements for the Automatically Switched Optical Network (ASON). [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing architecture and requirements for remote route query. [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013. [RFC7334] Zhao, Q., Dhody, D., Ali Z., King, D., Casellas, R., "PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths", August 2014. [RFC7420] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE Communication Protocol (PCEP) Management Information Base", December 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, May 2015. [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", March 2016. [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)", June 2016. [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, October 2017. [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC8453, August 2018. [PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", work in progress, October 2018. King, et al. Expires January, 2020 [Page 23] Internet-Draft Inter-Area-AS Applicability July 2019 17. Contributors Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Julien Meuric France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex Email: julien.meuric@orange-ftgroup.com Olivier Dugeon France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex Email: olivier.dugeon@orange-ftgroup.com Jon Hardwick Metaswitch Networks 100 Church Street Enfield, Middlesex United Kingdom Email: jonathan.hardwick@metaswitch.com Oscar Gonzalez de Dios Telefonica I+D Emilio Vargas 6, Madrid Spain Email: ogondio@tid.es King, et al. Expires January, 2020 [Page 24] Internet-Draft Inter-Area-AS Applicability July 2019 18. Author's Addresses Daniel King Old Dog Consulting UK Email: daniel@olddog.co.uk Haomian Zheng Huawei Technologies F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China Email: zhenghaomian@huawei.com King, et al. Expires January, 2020 [Page 25]./draft-ietf-tsvwg-rlc-fec-scheme-16.txt0000644000764400076440000027067013502234055017317 0ustar iustyiusty TSVWG V. Roca Internet-Draft B. Teibi Intended status: Standards Track INRIA Expires: December 20, 2019 June 18, 2019 Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME draft-ietf-tsvwg-rlc-fec-scheme-16 Abstract This document describes two fully-specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over the Galois Field (A.K.A. Finite Field) GF(2), a second one for RLC over the Galois Field GF(2^^8), each time with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes. These sliding window FEC codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these sliding window FEC codes offer key advantages with real- time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities. 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 https://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 20, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Roca & Teibi Expires December 20, 2019 [Page 1] Internet-Draft RLC FEC Scheme June 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Limits of Block Codes with Real-Time Flows . . . . . . . 4 1.2. Lower Latency and Better Protection of Real-Time Flows with the Sliding Window RLC Codes . . . . . . . . . . . . 4 1.3. Small Transmission Overheads with the Sliding Window RLC FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 3. Common Procedures . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Codec Parameters . . . . . . . . . . . . . . . . . . . . 7 3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 9 3.3. Encoding Window Management . . . . . . . . . . . . . . . 10 3.4. Source Symbol Identification . . . . . . . . . . . . . . 11 3.5. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 11 3.6. Coding Coefficients Generation Function . . . . . . . . . 13 3.7. Finite Fields Operations . . . . . . . . . . . . . . . . 15 3.7.1. Finite Field Definitions . . . . . . . . . . . . . . 15 3.7.2. Linear Combination of Source Symbols Computation . . 15 4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary Packet Flows . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 16 4.1.1. FEC Framework Configuration Information . . . . . . . 16 4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 18 4.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 18 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 20 5. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary Packet Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 20 5.1.1. FEC Framework Configuration Information . . . . . . . 20 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 20 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 20 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 21 6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 21 6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 22 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 Roca & Teibi Expires December 20, 2019 [Page 2] Internet-Draft RLC FEC Scheme June 2019 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 23 8.1.1. Access to Confidential Content . . . . . . . . . . . 23 8.1.2. Content Corruption . . . . . . . . . . . . . . . . . 23 8.2. Attacks Against the FEC Parameters . . . . . . . . . . . 23 8.3. When Several Source Flows are to be Protected Together . 25 8.4. Baseline Secure FEC Framework Operation . . . . . . . . . 25 8.5. Additional Security Considerations for Numerical Computations . . . . . . . . . . . . . . . . . . . . . . 25 9. Operations and Management Considerations . . . . . . . . . . 26 9.1. Operational Recommendations: Finite Field GF(2) Versus GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 26 9.2. Operational Recommendations: Coding Coefficients Density Threshold . . . . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. TinyMT32 Validation Criteria (Normative) . . . . . . 30 Appendix B. Assessing the PRNG Adequacy (Informational) . . . . 31 Appendix C. Possible Parameter Derivation (Informational) . . . 33 C.1. Case of a CBR Real-Time Flow . . . . . . . . . . . . . . 34 C.2. Other Types of Real-Time Flow . . . . . . . . . . . . . . 36 C.3. Case of a Non Real-Time Flow . . . . . . . . . . . . . . 37 Appendix D. Decoding Beyond Maximum Latency Optimization (Informational) . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction Application-Level Forward Erasure Correction (AL-FEC) codes, or simply FEC codes, are a key element of communication systems. They are used to recover from packet losses (or erasures) during content delivery sessions to a potentially large number of receivers (multicast/broadcast transmissions). This is the case with the FLUTE/ALC protocol [RFC6726] when used for reliable file transfers over lossy networks, and the FECFRAME protocol [RFC6363] when used for reliable continuous media transfers over lossy networks. The present document only focuses on the FECFRAME protocol, used in multicast/broadcast delivery mode, in particular for contents that feature stringent real-time constraints: each source packet has a maximum validity period after which it will not be considered by the destination application. Roca & Teibi Expires December 20, 2019 [Page 3] Internet-Draft RLC FEC Scheme June 2019 1.1. Limits of Block Codes with Real-Time Flows With FECFRAME, there is a single FEC encoding point (either an end- host/server (source) or a middlebox) and a single FEC decoding point per receiver (either an end-host (receiver) or middlebox). In this context, currently standardized AL-FEC codes for FECFRAME like Reed- Solomon [RFC6865], LDPC-Staircase [RFC6816], or Raptor/RaptorQ [RFC6681], are all linear block codes: they require the data flow to be segmented into blocks of a predefined maximum size. To define this block size, it is required to find an appropriate balance between robustness and decoding latency: the larger the block size, the higher the robustness (e.g., in case of long packet erasure bursts), but also the higher the maximum decoding latency (i.e., the maximum time required to recover a lost (erased) packet thanks to FEC protection). Therefore, with a multicast/broadcast session where different receivers experience different packet loss rates, the block size should be chosen by considering the worst communication conditions one wants to support, but without exceeding the desired maximum decoding latency. This choice then impacts the FEC-related latency of all receivers, even those experiencing a good communication quality, since no FEC encoding can happen until all the source data of the block is available at the sender, which directly depends on the block size. 1.2. Lower Latency and Better Protection of Real-Time Flows with the Sliding Window RLC Codes This document introduces two fully-specified FEC Schemes that do not follow the block code approach: the Sliding Window Random Linear Codes (RLC) over either Galois Fields (A.K.A. Finite Fields) GF(2) (the "binary case") or GF(2^^8), each time with the possibility of controlling the code density. These FEC Schemes are used to protect arbitrary media streams along the lines defined by FECFRAME extended to sliding window FEC codes [fecframe-ext]. These FEC Schemes, and more generally Sliding Window FEC codes, are recommended for instance, with media that feature real-time constraints sent within a multicast/broadcast session [Roca17]. The RLC codes belong to the broad class of sliding-window AL-FEC codes (A.K.A. convolutional codes) [RFC8406]. The encoding process is based on an encoding window that slides over the set of source packets (in fact source symbols as we will see in Section 3.2), this window being either of fixed size or variable size (A.K.A. an elastic window). Repair symbols are generated on-the-fly, by computing a random linear combination of the source symbols present in the current encoding window, and passed to the transport layer. Roca & Teibi Expires December 20, 2019 [Page 4] Internet-Draft RLC FEC Scheme June 2019 At the receiver, a linear system is managed from the set of received source and repair packets. New variables (representing source symbols) and equations (representing the linear combination carried by each repair symbol received) are added upon receiving new packets. Variables and the equations they are involved in are removed when they are too old with respect to their validity period (real-time constraints). Lost source symbols are then recovered thanks to this linear system whenever its rank permits to solve it (at least partially). The protection of any multicast/broadcast session needs to be dimensioned by considering the worst communication conditions one wants to support. This is also true with RLC (more generally any sliding window) code. However, the receivers experiencing a good to medium communication quality will observe a reduced FEC-related latency compared to block codes [Roca17] since an isolated lost source packet is quickly recovered with the following repair packet. On the opposite, with a block code, recovering an isolated lost source packet always requires waiting for the first repair packet to arrive after the end of the block. Additionally, under certain situations (e.g., with a limited FEC-related latency budget and with constant bitrate transmissions after FECFRAME encoding), sliding window codes can more efficiently achieve a target transmission quality (e.g., measured by the residual loss after FEC decoding) by sending fewer repair packets (i.e., higher code rate) than block codes. 1.3. Small Transmission Overheads with the Sliding Window RLC FEC Scheme The Sliding Window RLC FEC Scheme is designed to limit the packet header overhead. The main requirement is that each repair packet header must enable a receiver to reconstruct the set of source symbols plus the associated coefficients used during the encoding process. In order to minimize packet overhead, the set of source symbols in the encoding window as well as the set of coefficients over GF(2^^m) (where m is 1 or 8, depending on the FEC Scheme) used in the linear combination are not individually listed in the repair packet header. Instead, each FEC Repair Packet header contains: o the Encoding Symbol Identifier (ESI) of the first source symbol in the encoding window as well as the number of symbols (since this number may vary with a variable size, elastic window). These two pieces of information enable each receiver to reconstruct the set of source symbols considered during encoding, the only constraint being that there cannot be any gap; o the seed and density threshold parameters used by a coding coefficients generation function (Section 3.6). These two pieces Roca & Teibi Expires December 20, 2019 [Page 5] Internet-Draft RLC FEC Scheme June 2019 of information enable each receiver to generate the same set of coding coefficients over GF(2^^m) as the sender; Therefore, no matter the number of source symbols present in the encoding window, each FEC Repair Packet features a fixed 64-bit long header, called Repair FEC Payload ID (Figure 8). Similarly, each FEC Source Packet features a fixed 32-bit long trailer, called Explicit Source FEC Payload ID (Figure 6), that contains the ESI of the first source symbol (Section 3.2). 1.4. Document Organization This fully-specified FEC Scheme follows the structure required by [RFC6363], section 5.6. "FEC Scheme Requirements", namely: 3. Procedures: This section describes procedures specific to this FEC Scheme, namely: RLC parameters derivation, ADUI and source symbols mapping, pseudo-random number generator, and coding coefficients generation function; 4. Formats and Codes: This section defines the Source FEC Payload ID and Repair FEC Payload ID formats, carrying the signaling information associated to each source or repair symbol. It also defines the FEC Framework Configuration Information (FFCI) carrying signaling information for the session; 5. FEC Code Specification: Finally this section provides the code specification. 2. Definitions and Abbreviations 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following definitions and abbreviations: a^^b a to the power of b GF(q) denotes a finite field (also known as the Galois Field) with q elements. We assume that q = 2^^m in this document m defines the length of the elements in the finite field, in bits. In this document, m is equal to 1 or 8 ADU: Application Data Unit ADUI: Application Data Unit Information (includes the F, L and padding fields in addition to the ADU) E: size of an encoding symbol (i.e., source or repair symbol), assumed fixed (in bytes) Roca & Teibi Expires December 20, 2019 [Page 6] Internet-Draft RLC FEC Scheme June 2019 br_in: transmission bitrate at the input of the FECFRAME sender, assumed fixed (in bits/s) br_out: transmission bitrate at the output of the FECFRAME sender, assumed fixed (in bits/s) max_lat: maximum FEC-related latency within FECFRAME (a decimal number expressed in seconds) cr: RLC coding rate, ratio between the total number of source symbols and the total number of source plus repair symbols ew_size: encoding window current size at a sender (in symbols) ew_max_size: encoding window maximum size at a sender (in symbols) dw_max_size: decoding window maximum size at a receiver (in symbols) ls_max_size: linear system maximum size (or width) at a receiver (in symbols) WSR: window size ratio parameter used to derive ew_max_size (encoder) and ls_max_size (decoder). PRNG: pseudo-random number generator TinyMT32: PRNG used in this specification. DT: coding coefficients density threshold, an integer between 0 and 15 (inclusive) the controls the fraction of coefficients that are non zero 3. Common Procedures This section introduces the procedures that are used by these FEC Schemes. 3.1. Codec Parameters A codec implementing the Sliding Window RLC FEC Scheme relies on several parameters: Maximum FEC-related latency budget, max_lat (a decimal number expressed in seconds) with real-time flows: a source ADU flow can have real-time constraints, and therefore any FECFRAME related operation should take place within the validity period of each ADU (Appendix D describes an exception to this rule). When there are multiple flows with different real- time constraints, we consider the most stringent constraints (see [RFC6363], Section 10.2, item 6, for recommendations when several flows are globally protected). The maximum FEC-related latency budget, max_lat, accounts for all sources of latency added by FEC encoding (at a sender) and FEC decoding (at a receiver). Other sources of latency (e.g., added by network communications) are out of scope and must be considered separately (said differently, they have already been deducted from max_lat). max_lat can be regarded as the latency budget permitted for all FEC-related operations. This is an input parameter that enables a FECFRAME sender to derive other internal parameters (see Appendix C); Roca & Teibi Expires December 20, 2019 [Page 7] Internet-Draft RLC FEC Scheme June 2019 Encoding window current (resp. maximum) size, ew_size (resp. ew_max_size) (in symbols): at a FECFRAME sender, during FEC encoding, a repair symbol is computed as a linear combination of the ew_size source symbols present in the encoding window. The ew_max_size is the maximum size of this window, while ew_size is the current size. For example, in the common case at session start, upon receiving new source ADUs, the ew_size progressively increases until it reaches its maximum value, ew_max_size. We have: 0 < ew_size <= ew_max_size Decoding window maximum size, dw_max_size (in symbols): at a FECFRAME receiver, dw_max_size is the maximum number of received or lost source symbols that are still within their latency budget; Linear system maximum size, ls_max_size (in symbols): at a FECFRAME receiver, the linear system maximum size, ls_max_size, is the maximum number of received or lost source symbols in the linear system (i.e., the variables). It SHOULD NOT be smaller than dw_max_size since it would mean that, even after receiving a sufficient number of FEC Repair Packets, a lost ADU may not be recovered just because the associated source symbols have been prematurely removed from the linear system, which is usually counter-productive. On the opposite, the linear system MAY grow beyond the dw_max_size (Appendix D); Symbol size, E (in bytes): the E parameter determines the source and repair symbol sizes (necessarily equal). This is an input parameter that enables a FECFRAME sender to derive other internal parameters, as explained below. An implementation at a sender MUST fix the E parameter and MUST communicate it as part of the FEC Scheme-Specific Information (Section 4.1.1.2). Code rate, cr: The code rate parameter determines the amount of redundancy added to the flow. More precisely the cr is the ratio between the total number of source symbols and the total number of source plus repair symbols and by definition: 0 < cr <= 1. This is an input parameter that enables a FECFRAME sender to derive other internal parameters, as explained below. However, there is no need to communicate the cr parameter per see (it's not required to process a repair symbol at a receiver). This code rate parameter can be static. However, in specific use-cases (e.g., with unicast transmissions in presence of a feedback mechanism that estimates the communication quality, out of scope of FECFRAME), the code rate may be adjusted dynamically. Appendix C proposes non normative techniques to derive those parameters, depending on the use-case specificities. Roca & Teibi Expires December 20, 2019 [Page 8] Internet-Draft RLC FEC Scheme June 2019 3.2. ADU, ADUI and Source Symbols Mappings At a sender, an ADU coming from the application is not directly mapped to source symbols. When multiple source flows (e.g., media streams) are mapped onto the same FECFRAME instance, each flow is assigned its own Flow ID value (see below). This Flow ID is then prepended to each ADU before FEC encoding. This way, FEC decoding at a receiver also recovers this Flow ID and the recovered ADU can be assigned to the right source flow (note that the 5-tuple used to identify the right source flow of a received ADU is absent with a recovered ADU since it is not FEC protected). Additionally, since ADUs are of variable size, padding is needed so that each ADU (with its flow identifier) contribute to an integral number of source symbols. This requires adding the original ADU length to each ADU before doing FEC encoding. Because of these requirements, an intermediate format, the ADUI, or ADU Information, is considered [RFC6363]. For each incoming ADU, an ADUI MUST created as follows. First of all, 3 bytes are prepended (Figure 1): Flow ID (F) (8-bit field): this unsigned byte contains the integer identifier associated to the source ADU flow to which this ADU belongs. It is assumed that a single byte is sufficient, which implies that no more than 256 flows will be protected by a single FECFRAME session instance. Length (L) (16-bit field): this unsigned integer contains the length of this ADU, in network byte order (i.e., big endian). This length is for the ADU itself and does not include the F, L, or Pad fields. Then, zero padding is added to the ADU if needed: Padding (Pad) (variable size field): this field contains zero padding to align the F, L, ADU and padding up to a size that is multiple of E bytes (i.e., the source and repair symbol length). The data unit resulting from the ADU and the F, L, and Pad fields is called ADUI. Since ADUs can have different sizes, this is also the case for ADUIs. However, an ADUI always contributes to an integral number of source symbols. Roca & Teibi Expires December 20, 2019 [Page 9] Internet-Draft RLC FEC Scheme June 2019 symbol length, E E E < ------------------ >< ------------------ >< ------------------ > +-+--+---------------------------------------------+-------------+ |F| L| ADU | Pad | +-+--+---------------------------------------------+-------------+ Figure 1: ADUI Creation example (here 3 source symbols are created for this ADUI). Note that neither the initial 3 bytes nor the optional padding are sent over the network. However, they are considered during FEC encoding, and a receiver who lost a certain FEC Source Packet (e.g., the UDP datagram containing this FEC Source Packet when UDP is used as the transport protocol) will be able to recover the ADUI if FEC decoding succeeds. Thanks to the initial 3 bytes, this receiver will get rid of the padding (if any) and identify the corresponding ADU flow. 3.3. Encoding Window Management Source symbols and the corresponding ADUs are removed from the encoding window: o when the sliding encoding window has reached its maximum size, ew_max_size. In that case the oldest symbol MUST be removed before adding a new symbol, so that the current encoding window size always remains inferior or equal to the maximum size: ew_size <= ew_max_size; o when an ADU has reached its maximum validity duration in case of a real-time flow. When this happens, all source symbols corresponding to the ADUI that expired SHOULD be removed from the encoding window; Source symbols are added to the sliding encoding window each time a new ADU arrives, once the ADU-to-source symbols mapping has been performed (Section 3.2). The current size of the encoding window, ew_size, is updated after adding new source symbols. This process may require to remove old source symbols so that: ew_size <= ew_max_size. Note that a FEC codec may feature practical limits in the number of source symbols in the encoding window (e.g., for computational complexity reasons). This factor may further limit the ew_max_size value, in addition to the maximum FEC-related latency budget (Section 3.1). Roca & Teibi Expires December 20, 2019 [Page 10] Internet-Draft RLC FEC Scheme June 2019 3.4. Source Symbol Identification Each source symbol is identified by an Encoding Symbol ID (ESI), an unsigned integer. The ESI of source symbols MUST start with value 0 for the first source symbol and MUST be managed sequentially. Wrapping to zero happens after reaching the maximum value made possible by the ESI field size (this maximum value is FEC Scheme dependant, for instance, 2^32-1 with FEC Schemes XXX and YYY). No such consideration applies to repair symbols. 3.5. Pseudo-Random Number Generator (PRNG) In order to compute coding coefficients (see Section 3.6), the RLC FEC Schemes rely on the TinyMT32 PRNG defined in [tinymt32] with two additional functions defined in this section. This PRNG MUST first be initialized with a 32-bit unsigned integer, used as a seed, with: void tinymt32_init (tinymt32_t * s, uint32_t seed); With the FEC Schemes defined in this document, the seed is in practice restricted to a value between 0 and 0xFFFF inclusive (note that this PRNG accepts a seed value equal to 0), since this is the Repair_Key 16-bit field value of the Repair FEC Payload ID (Section 4.1.3). In practice, how to manage the seed and Repair_Key values (both are equal) is left to the implementer, using a monotonically increasing counter being one possibility (Section 6.1). In addition to the seed, this function takes as parameter a pointer to an instance of a tinymt32_t structure that is used to keep the internal state of the PRNG. Then, each time a new pseudo-random integer between 0 and 15 inclusive (4-bit pseudo-random integer) is needed, the following function is used: uint32_t tinymt32_rand16 (tinymt32_t * s); This function takes as parameter a pointer to the same tinymt32_t structure (that is left unchanged between successive calls to the function). Similarly, each time a new pseudo-random integer between 0 and 255 inclusive (8-bit pseudo-random integer) is needed, the following function is used: uint32_t tinymt32_rand256 (tinymt32_t * s); Roca & Teibi Expires December 20, 2019 [Page 11] Internet-Draft RLC FEC Scheme June 2019 These two functions keep respectively the 4 or 8 less significant bits of the 32-bit pseudo-random number generated by the tinymt32_generate_uint32() function of [tinymt32]. This is done by computing the result of a binary AND between the tinymt32_generate_uint32() output and respectively the 0xF or 0xFF constants, using 32-bit unsigned integer operations. Figure 2 shows a possible implementation. This is a C language implementation, written for C99 [C99]. Test results discussed in Appendix B show that this simple technique, applied to this PRNG, is in line with the RLC FEC Schemes needs. /** * This function outputs a pseudo-random integer in [0 .. 15] range. * * @param s pointer to tinymt internal state. * @return unsigned integer between 0 and 15 inclusive. */ uint32_t tinymt32_rand16(tinymt32_t *s) { return (tinymt32_generate_uint32(s) & 0xF); } /** * This function outputs a pseudo-random integer in [0 .. 255] range. * * @param s pointer to tinymt internal state. * @return unsigned integer between 0 and 255 inclusive. */ uint32_t tinymt32_rand256(tinymt32_t *s) { return (tinymt32_generate_uint32(s) & 0xFF); } Figure 2: 4-bit and 8-bit mapping functions for TinyMT32 Any implementation of this PRNG MUST have the same output as that provided by the reference implementation of [tinymt32]. In order to increase the compliancy confidence, three criteria are proposed: the one described in [tinymt32] (for the TinyMT32 32-bit unsigned integer generator), and the two others detailed in Appendix A (for the mapping to 4-bit and 8-bit intervals). Because of the way the mapping functions work, it is unlikely that an implementation that fulfills the first criterion fails to fulfill the two others. Roca & Teibi Expires December 20, 2019 [Page 12] Internet-Draft RLC FEC Scheme June 2019 3.6. Coding Coefficients Generation Function The coding coefficients, used during the encoding process, are generated at the RLC encoder by the generate_coding_coefficients() function each time a new repair symbol needs to be produced. The fraction of coefficients that are non zero (i.e., the density) is controlled by the DT (Density Threshold) parameter. DT has values between 0 (the minimum value) and 15 (the maximum value), and the average probability of having a non zero coefficient equals (DT + 1) / 16. In particular, when DT equals 15 the function guaranties that all coefficients are non zero (i.e., maximum density). These considerations apply to both the RLC over GF(2) and RLC over GF(2^^8), the only difference being the value of the m parameter. With the RLC over GF(2) FEC Scheme (Section 5), m is equal to 1. With RLC over GF(2^^8) FEC Scheme (Section 4), m is equal to 8. Figure 3 shows the reference generate_coding_coefficients() implementation. This is a C language implementation, written for C99 [C99]. #include /* * Fills in the table of coding coefficients (of the right size) * provided with the appropriate number of coding coefficients to * use for the repair symbol key provided. * * (in) repair_key key associated to this repair symbol. This * parameter is ignored (useless) if m=1 and dt=15 * (in/out) cc_tab pointer to a table of the right size to store * coding coefficients. All coefficients are * stored as bytes, regardless of the m parameter, * upon return of this function. * (in) cc_nb number of entries in the cc_tab table. This * value is equal to the current encoding window * size. * (in) dt integer between 0 and 15 (inclusive) that * controls the density. With value 15, all * coefficients are guaranteed to be non zero * (i.e. equal to 1 with GF(2) and equal to a * value in {1,... 255} with GF(2^^8)), otherwise * a fraction of them will be 0. * (in) m Finite Field GF(2^^m) parameter. In this * document only values 1 and 8 are considered. * (out) returns 0 in case of success, an error code * different than 0 otherwise. Roca & Teibi Expires December 20, 2019 [Page 13] Internet-Draft RLC FEC Scheme June 2019 */ int generate_coding_coefficients (uint16_t repair_key, uint8_t* cc_tab, uint16_t cc_nb, uint8_t dt, uint8_t m) { uint32_t i; tinymt32_t s; /* PRNG internal state */ if (dt > 15) { return -1; /* error, bad dt parameter */ } switch (m) { case 1: if (dt == 15) { /* all coefficients are 1 */ memset(cc_tab, 1, cc_nb); } else { /* here coefficients are either 0 or 1 */ tinymt32_init(&s, repair_key); for (i = 0 ; i < cc_nb ; i++) { cc_tab[i] = (tinymt32_rand16(&s) <= dt) ? 1 : 0; } } break; case 8: tinymt32_init(&s, repair_key); if (dt == 15) { /* coefficient 0 is avoided here in order to include * all the source symbols */ for (i = 0 ; i < cc_nb ; i++) { do { cc_tab[i] = (uint8_t) tinymt32_rand256(&s); } while (cc_tab[i] == 0); } } else { /* here a certain number of coefficients should be 0 */ for (i = 0 ; i < cc_nb ; i++) { if (tinymt32_rand16(&s) <= dt) { do { cc_tab[i] = (uint8_t) tinymt32_rand256(&s); } while (cc_tab[i] == 0); } else { cc_tab[i] = 0; } } Roca & Teibi Expires December 20, 2019 [Page 14] Internet-Draft RLC FEC Scheme June 2019 } break; default: return -2; /* error, bad parameter m */ } return 0; /* success */ } Figure 3: Coding Coefficients Generation Function Reference Implementation 3.7. Finite Fields Operations 3.7.1. Finite Field Definitions The two RLC FEC Schemes specified in this document reuse the Finite Fields defined in [RFC5510], section 8.1. More specifically, the elements of the field GF(2^^m) are represented by polynomials with binary coefficients (i.e., over GF(2)) and degree lower or equal to m-1. The addition between two elements is defined as the addition of binary polynomials in GF(2), which is equivalent to a bitwise XOR operation on the binary representation of these elements. With GF(2^^8), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 8. The following irreducible polynomial is used for GF(2^^8): x^^8 + x^^4 + x^^3 + x^^2 + 1 With GF(2), multiplication corresponds to a logical AND operation. 3.7.2. Linear Combination of Source Symbols Computation The two RLC FEC Schemes require the computation of a linear combination of source symbols, using the coding coefficients produced by the generate_coding_coefficients() function and stored in the cc_tab[] array. With the RLC over GF(2^^8) FEC Scheme, a linear combination of the ew_size source symbol present in the encoding window, say src_0 to src_ew_size_1, in order to generate a repair symbol, is computed as follows. For each byte of position i in each source and the repair symbol, where i belongs to [0; E-1], compute: repair[i] = cc_tab[0] * src_0[i] XOR cc_tab[1] * src_1[i] XOR ... XOR cc_tab[ew_size - 1] * src_ew_size_1[i] Roca & Teibi Expires December 20, 2019 [Page 15] Internet-Draft RLC FEC Scheme June 2019 where * is the multiplication over GF(2^^8). In practice various optimizations need to be used in order to make this computation efficient (see in particular [PGM13]). With the RLC over GF(2) FEC Scheme (binary case), a linear combination is computed as follows. The repair symbol is the XOR sum of all the source symbols corresponding to a coding coefficient cc_tab[j] equal to 1 (i.e., the source symbols corresponding to zero coding coefficients are ignored). The XOR sum of the byte of position i in each source is computed and stored in the corresponding byte of the repair symbol, where i belongs to [0; E-1]. In practice, the XOR sums will be computed several bytes at a time (e.g., on 64 bit words, or on arrays of 16 or more bytes when using SIMD CPU extensions). With both FEC Schemes, the details of how to optimize the computation of these linear combinations are of high practical importance but out of scope of this document. 4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary Packet Flows This fully-specified FEC Scheme defines the Sliding Window Random Linear Codes (RLC) over GF(2^^8). 4.1. Formats and Codes 4.1.1. FEC Framework Configuration Information Following the guidelines of [RFC6363], section 5.6, this section provides the FEC Framework Configuration Information (or FFCI). This FCCI needs to be shared (e.g., using SDP) between the FECFRAME sender and receiver instances in order to synchronize them. It includes a FEC Encoding ID, mandatory for any FEC Scheme specification, plus scheme-specific elements. 4.1.1.1. FEC Encoding ID o FEC Encoding ID: the value assigned to this fully specified FEC Scheme MUST be XXXX, as assigned by IANA (Section 10). When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in the 'encoding-id' parameter. Roca & Teibi Expires December 20, 2019 [Page 16] Internet-Draft RLC FEC Scheme June 2019 4.1.1.2. FEC Scheme-Specific Information The FEC Scheme-Specific Information (FSSI) includes elements that are specific to the present FEC Scheme. More precisely: Encoding symbol size (E): a non-negative integer that indicates the size of each encoding symbol in bytes; Window Size Ratio (WSR) parameter: a non-negative integer between 0 and 255 (both inclusive) used to initialize window sizes. A value of 0 indicates this parameter is not considered (e.g., a fixed encoding window size may be chosen). A value between 1 and 255 inclusive is required by certain of the parameter derivation techniques described in Appendix C; This element is required both by the sender (RLC encoder) and the receiver(s) (RLC decoder). When SDP is used to communicate the FFCI, this FEC Scheme-specific information is carried in the 'fssi' parameter in textual representation as specified in [RFC6364]. For instance: fssi=E:1400,WSR:191 In that case the name values "E" and "WSR" are used to convey the E and WSR parameters respectively. If another mechanism requires the FSSI to be carried as an opaque octet string, the encoding format consists of the following three octets, where the E field is carried in "big-endian" or "network order" format, that is, most significant byte first: Encoding symbol length (E): 16-bit field; Window Size Ratio Parameter (WSR): 8-bit field. These three octets can be communicated as such, or for instance, be subject to an additional Base64 encoding. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding Symbol Length (E) | WSR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: FSSI Encoding Format Roca & Teibi Expires December 20, 2019 [Page 17] Internet-Draft RLC FEC Scheme June 2019 4.1.2. Explicit Source FEC Payload ID A FEC Source Packet MUST contain an Explicit Source FEC Payload ID that is appended to the end of the packet as illustrated in Figure 5. +--------------------------------+ | IP Header | +--------------------------------+ | Transport Header | +--------------------------------+ | ADU | +--------------------------------+ | Explicit Source FEC Payload ID | +--------------------------------+ Figure 5: Structure of an FEC Source Packet with the Explicit Source FEC Payload ID More precisely, the Explicit Source FEC Payload ID is composed of the following field, carried in "big-endian" or "network order" format, that is, most significant byte first (Figure 6): Encoding Symbol ID (ESI) (32-bit field): this unsigned integer identifies the first source symbol of the ADUI corresponding to this FEC Source Packet. The ESI is incremented for each new source symbol, and after reaching the maximum value (2^32-1), wrapping to zero occurs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding Symbol ID (ESI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Source FEC Payload ID Encoding Format 4.1.3. Repair FEC Payload ID A FEC Repair Packet MAY contain one or more repair symbols. When there are several repair symbols, all of them MUST have been generated from the same encoding window, using Repair_Key values that are managed as explained below. A receiver can easily deduce the number of repair symbols within a FEC Repair Packet by comparing the received FEC Repair Packet size (equal to the UDP payload size when UDP is the underlying transport protocol) and the symbol size, E, communicated in the FFCI. Roca & Teibi Expires December 20, 2019 [Page 18] Internet-Draft RLC FEC Scheme June 2019 A FEC Repair Packet MUST contain a Repair FEC Payload ID that is prepended to the repair symbol as illustrated in Figure 7. +--------------------------------+ | IP Header | +--------------------------------+ | Transport Header | +--------------------------------+ | Repair FEC Payload ID | +--------------------------------+ | Repair Symbol | +--------------------------------+ Figure 7: Structure of an FEC Repair Packet with the Repair FEC Payload ID More precisely, the Repair FEC Payload ID is composed of the following fields where all integer fields are carried in "big-endian" or "network order" format, that is, most significant byte first (Figure 8): Repair_Key (16-bit field): this unsigned integer is used as a seed by the coefficient generation function (Section 3.6) in order to generate the desired number of coding coefficients. This repair key may be a monotonically increasing integer value that loops back to 0 after reaching 65535 (see Section 6.1). When a FEC Repair Packet contains several repair symbols, this repair key value is that of the first repair symbol. The remaining repair keys can be deduced by incrementing by 1 this value, up to a maximum value of 65535 after which it loops back to 0. Density Threshold for the coding coefficients, DT (4-bit field): this unsigned integer carries the Density Threshold (DT) used by the coding coefficient generation function Section 3.6. More precisely, it controls the probability of having a non zero coding coefficient, which equals (DT+1) / 16. When a FEC Repair Packet contains several repair symbols, the DT value applies to all of them; Number of Source Symbols in the encoding window, NSS (12-bit field): this unsigned integer indicates the number of source symbols in the encoding window when this repair symbol was generated. When a FEC Repair Packet contains several repair symbols, this NSS value applies to all of them; ESI of First Source Symbol in the encoding window, FSS_ESI (32-bit field): this unsigned integer indicates the ESI of the first source symbol in the encoding window when this repair symbol was generated. Roca & Teibi Expires December 20, 2019 [Page 19] Internet-Draft RLC FEC Scheme June 2019 When a FEC Repair Packet contains several repair symbols, this FSS_ESI value applies to all of them; 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Repair_Key | DT |NSS (# src symb in ew) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FSS_ESI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Repair FEC Payload ID Encoding Format 4.2. Procedures All the procedures of Section 3 apply to this FEC Scheme. 5. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary Packet Flows This fully-specified FEC Scheme defines the Sliding Window Random Linear Codes (RLC) over GF(2) (binary case). 5.1. Formats and Codes 5.1.1. FEC Framework Configuration Information 5.1.1.1. FEC Encoding ID o FEC Encoding ID: the value assigned to this fully specified FEC Scheme MUST be YYYY, as assigned by IANA (Section 10). When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in the 'encoding-id' parameter. 5.1.1.2. FEC Scheme-Specific Information All the considerations of Section 4.1.1.2 apply here. 5.1.2. Explicit Source FEC Payload ID All the considerations of Section 4.1.2 apply here. 5.1.3. Repair FEC Payload ID All the considerations of Section 4.1.3 apply here, with the only exception that the Repair_Key field is useless if DT = 15 (indeed, in that case all the coefficients are necessarily equal to 1 and the coefficient generation function does not use any PRNG). When DT = 15 Roca & Teibi Expires December 20, 2019 [Page 20] Internet-Draft RLC FEC Scheme June 2019 the FECFRAME sender MUST set the Repair_Key field to zero on transmission and a receiver MUST ignore it on receipt. 5.2. Procedures All the procedures of Section 3 apply to this FEC Scheme. 6. FEC Code Specification 6.1. Encoding Side This section provides a high level description of a Sliding Window RLC encoder. Whenever a new FEC Repair Packet is needed, the RLC encoder instance first gathers the ew_size source symbols currently in the sliding encoding window. Then it chooses a repair key, which can be a monotonically increasing integer value, incremented for each repair symbol up to a maximum value of 65535 (as it is carried within a 16-bit field) after which it loops back to 0. This repair key is communicated to the coefficient generation function (Section 3.6) in order to generate ew_size coding coefficients. Finally, the FECFRAME sender computes the repair symbol as a linear combination of the ew_size source symbols using the ew_size coding coefficients (Section 3.7). When E is small and when there is an incentive to pack several repair symbols within the same FEC Repair Packet, the appropriate number of repair symbols are computed. In that case the repair key for each of them MUST be incremented by 1, keeping the same ew_size source symbols, since only the first repair key will be carried in the Repair FEC Payload ID. The FEC Repair Packet can then be passed to the transport layer for transmission. The source versus repair FEC packet transmission order is out of scope of this document and several approaches exist that are implementation-specific. Other solutions are possible to select a repair key value when a new FEC Repair Packet is needed, for instance, by choosing a random integer between 0 and 65535. However, selecting the same repair key as before (which may happen in case of a random process) is only meaningful if the encoding window has changed, otherwise the same FEC Repair Packet will be generated. In any case, choosing the repair key is entirely at the discretion of the sender, since it is communicated to the receiver(s) in each Repair FEC Payload ID. A receiver should not make any assumption on the way the repair key is managed. Roca & Teibi Expires December 20, 2019 [Page 21] Internet-Draft RLC FEC Scheme June 2019 6.2. Decoding Side This section provides a high level description of a Sliding Window RLC decoder. A FECFRAME receiver needs to maintain a linear system whose variables are the received and lost source symbols. Upon receiving a FEC Repair Packet, a receiver first extracts all the repair symbols it contains (in case several repair symbols are packed together). For each repair symbol, when at least one of the corresponding source symbols it protects has been lost, the receiver adds an equation to the linear system (or no equation if this repair packet does not change the linear system rank). This equation of course re-uses the ew_size coding coefficients that are computed by the same coefficient generation function (Section 3.6), using the repair key and encoding window descriptions carried in the Repair FEC Payload ID. Whenever possible (i.e., when a sub-system covering one or more lost source symbols is of full rank), decoding is performed in order to recover lost source symbols. Gaussian elimination is one possible algorithm to solve this linear system. Each time an ADUI can be totally recovered, padding is removed (thanks to the Length field, L, of the ADUI) and the ADU is assigned to the corresponding application flow (thanks to the Flow ID field, F, of the ADUI). This ADU is finally passed to the corresponding upper application. Received FEC Source Packets, containing an ADU, MAY be passed to the application either immediately or after some time to guaranty an ordered delivery to the application. This document does not mandate any approach as this is an operational and management decision. With real-time flows, a lost ADU that is decoded after the maximum latency or an ADU received after this delay has no value to the application. This raises the question of deciding whether or not an ADU is late. This decision MAY be taken within the FECFRAME receiver (e.g., using the decoding window, see Section 3.1) or within the application (e.g., using RTP timestamps within the ADU). Deciding which option to follow and whether or not to pass all ADUs, including those assumed late, to the application are operational decisions that depend on the application and are therefore out of scope of this document. Additionally, Appendix D discusses a backward compatible optimization whereby late source symbols MAY still be used within the FECFRAME receiver in order to improve transmission robustness. 7. Implementation Status Editor's notes: RFC Editor, please remove this section motivated by RFC 6982 before publishing the RFC. Thanks. Roca & Teibi Expires December 20, 2019 [Page 22] Internet-Draft RLC FEC Scheme June 2019 An implementation of the Sliding Window RLC FEC Scheme for FECFRAME exists: o Organisation: Inria o Description: This is an implementation of the Sliding Window RLC FEC Scheme limited to GF(2^^8). It relies on a modified version of our OpenFEC (http://openfec.org) FEC code library. It is integrated in our FECFRAME software (see [fecframe-ext]). o Maturity: prototype. o Coverage: this software complies with the Sliding Window RLC FEC Scheme. o Licensing: proprietary. o Contact: vincent.roca@inria.fr 8. Security Considerations The FEC Framework document [RFC6363] provides a fairly comprehensive analysis of security considerations applicable to FEC Schemes. Therefore, the present section follows the security considerations section of [RFC6363] and only discusses specific topics. 8.1. Attacks Against the Data Flow 8.1.1. Access to Confidential Content The Sliding Window RLC FEC Scheme specified in this document does not change the recommendations of [RFC6363]. To summarize, if confidentiality is a concern, it is RECOMMENDED that one of the solutions mentioned in [RFC6363] is used with special considerations to the way this solution is applied (e.g., is encryption applied before or after FEC protection, within the end-system or in a middlebox), to the operational constraints (e.g., performing FEC decoding in a protected environment may be complicated or even impossible) and to the threat model. 8.1.2. Content Corruption The Sliding Window RLC FEC Scheme specified in this document does not change the recommendations of [RFC6363]. To summarize, it is RECOMMENDED that one of the solutions mentioned in [RFC6363] is used on both the FEC Source and Repair Packets. 8.2. Attacks Against the FEC Parameters The FEC Scheme specified in this document defines parameters that can be the basis of attacks. More specifically, the following parameters of the FFCI may be modified by an attacker who targets receivers (Section 4.1.1.2): Roca & Teibi Expires December 20, 2019 [Page 23] Internet-Draft RLC FEC Scheme June 2019 o FEC Encoding ID: changing this parameter leads a receiver to consider a different FEC Scheme. The consequences are severe, the format of the Explicit Source FEC Payload ID and Repair FEC Payload ID of received packets will probably differ, leading to various malfunctions. Even if the original and modified FEC Schemes share the same format, FEC decoding will either fail or lead to corrupted decoded symbols. This will happen if an attacker turns value YYYY (i.e., RLC over GF(2)) to value XXXX (RLC over GF(2^^8)), an additional consequence being a higher processing overhead at the receiver. In any case, the attack results in a form of Denial of Service (DoS) or corrupted content. o Encoding symbol length (E): setting this E parameter to a different value will confuse a receiver. If the size of a received FEC Repair Packet is no longer multiple of the modified E value, a receiver quickly detects a problem and SHOULD reject the packet. If the new E value is a sub-multiple of the original E value (e.g., half the original value), then receivers may not detect the problem immediately. For instance, a receiver may think that a received FEC Repair Packet contains more repair symbols (e.g., twice as many if E is reduced by half), leading to malfunctions whose nature depends on implementation details. Here also, the attack always results in a form of DoS or corrupted content. It is therefore RECOMMENDED that security measures be taken to guarantee the FFCI integrity, as specified in [RFC6363]. How to achieve this depends on the way the FFCI is communicated from the sender to the receiver, which is not specified in this document. Similarly, attacks are possible against the Explicit Source FEC Payload ID and Repair FEC Payload ID. More specifically, in case of a FEC Source Packet, the following value can be modified by an attacker who targets receivers: o Encoding Symbol ID (ESI): changing the ESI leads a receiver to consider a wrong ADU, resulting in severe consequences, including corrupted content passed to the receiving application; And in case of a FEC Repair Packet: o Repair Key: changing this value leads a receiver to generate a wrong coding coefficient sequence, and therefore any source symbol decoded using the repair symbols contained in this packet will be corrupted; o DT: changing this value also leads a receiver to generate a wrong coding coefficient sequence, and therefore any source symbol decoded using the repair symbols contained in this packet will be corrupted. In addition, if the DT value is significantly Roca & Teibi Expires December 20, 2019 [Page 24] Internet-Draft RLC FEC Scheme June 2019 increased, it will generate a higher processing overhead at a receiver. In case of very large encoding windows, this may impact the terminal performance; o NSS: changing this value leads a receiver to consider a different set of source symbols, and therefore any source symbol decoded using the repair symbols contained in this packet will be corrupted. In addition, if the NSS value is significantly increased, it will generate a higher processing overhead at a receiver, which may impact the terminal performance; o FSS_ESI: changing this value also leads a receiver to consider a different set of source symbols and therefore any source symbol decoded using the repair symbols contained in this packet will be corrupted. It is therefore RECOMMENDED that security measures are taken to guarantee the FEC Source and Repair Packets as stated in [RFC6363]. 8.3. When Several Source Flows are to be Protected Together The Sliding Window RLC FEC Scheme specified in this document does not change the recommendations of [RFC6363]. 8.4. Baseline Secure FEC Framework Operation The Sliding Window RLC FEC Scheme specified in this document does not change the recommendations of [RFC6363] concerning the use of the IPsec/ESP security protocol as a mandatory to implement (but not mandatory to use) security scheme. This is well suited to situations where the only insecure domain is the one over which the FEC Framework operates. 8.5. Additional Security Considerations for Numerical Computations In addition to the above security considerations, inherited from [RFC6363], the present document introduces several formulae, in particular in Appendix C.1. It is RECOMMENDED to check that the computed values stay within reasonable bounds since numerical overflows, caused by an erroneous implementation or an erroneous input value, may lead to hazardous behaviours. However, what "reasonable bounds" means is use-case and implementation dependent and is not detailed in this document. Appendix C.2 also mentions the possibility of "using the timestamp field of an RTP packet header" when applicable. A malicious attacker may deliberately corrupt this header field in order to trigger hazardous behaviours at a FECFRAME receiver. Protection against this type of content corruption can be addressed with the above recommendations on a baseline secure operation. In addition, it is Roca & Teibi Expires December 20, 2019 [Page 25] Internet-Draft RLC FEC Scheme June 2019 also RECOMMENDED to check that the timestamp value be within reasonable bounds. 9. Operations and Management Considerations The FEC Framework document [RFC6363] provides a fairly comprehensive analysis of operations and management considerations applicable to FEC Schemes. Therefore, the present section only discusses specific topics. 9.1. Operational Recommendations: Finite Field GF(2) Versus GF(2^^8) The present document specifies two FEC Schemes that differ on the Finite Field used for the coding coefficients. It is expected that the RLC over GF(2^^8) FEC Scheme will be mostly used since it warrants a higher packet loss protection. In case of small encoding windows, the associated processing overhead is not an issue (e.g., we measured decoding speeds between 745 Mbps and 2.8 Gbps on an ARM Cortex-A15 embedded board in [Roca17] depending on the code rate and the channel conditions, using an encoding window of size 18 or 23 symbols; see the above article for the details). Of course the CPU overhead will increase with the encoding window size, because more operations in the GF(2^^8) finite field will be needed. The RLC over GF(2) FEC Scheme offers an alternative. In that case operations symbols can be directly XOR-ed together which warrants high bitrate encoding and decoding operations, and can be an advantage with large encoding windows. However, packet loss protection is significantly reduced by using this FEC Scheme. 9.2. Operational Recommendations: Coding Coefficients Density Threshold In addition to the choice of the Finite Field, the two FEC Schemes define a coding coefficient density threshold (DT) parameter. This parameter enables a sender to control the code density, i.e., the proportion of coefficients that are non zero on average. With RLC over GF(2^^8), it is usually appropriate that small encoding windows be associated to a density threshold equal to 15, the maximum value, in order to warrant a high loss protection. On the opposite, with larger encoding windows, it is usually appropriate that the density threshold be reduced. With large encoding windows, an alternative can be to use RLC over GF(2) and a density threshold equal to 7 (i.e., an average density equal to 1/2) or smaller. Note that using a density threshold equal to 15 with RLC over GF(2) is equivalent to using an XOR code that computes the XOR sum of all Roca & Teibi Expires December 20, 2019 [Page 26] Internet-Draft RLC FEC Scheme June 2019 the source symbols in the encoding window. In that case: (1) only a single repair symbol can be produced for any encoding window, and (2) the repair_key parameter becomes useless (the coding coefficients generation function does not rely on the PRNG). 10. IANA Considerations This document registers two values in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry [RFC6363] as follows: o YYYY refers to the Sliding Window Random Linear Codes (RLC) over GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in Section 5 of this document. o XXXX refers to the Sliding Window Random Linear Codes (RLC) over GF(2^^8) FEC Scheme for Arbitrary Packet Flows, as defined in Section 4 of this document. 11. Acknowledgments The authors would like to thank the three TSVWG chairs, Wesley Eddy, our shepherd, David Black and Gorry Fairhurst, as well as Spencer Dawkins, our responsible AD, and all those who provided comments, namely (alphabetical order) Alan DeKok, Jonathan Detchart, Russ Housley, Emmanuel Lochin, Marie-Jose Montpetit, and Greg Skinner. Last but not least, the authors are really grateful to the IESG members, in particular Benjamin Kaduk, Mirja Kuhlewind, Eric Rescorla, Adam Roach, and Roman Danyliw for their highly valuable feedbacks that greatly contributed to improve this specification. 12. References 12.1. Normative References [C99] "Programming languages - C: C99, correction 3:2007", International Organization for Standardization, ISO/IEC 9899:1999/Cor 3:2007, November 2007. [fecframe-ext] Roca, V. and A. Begen, "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes", Transport Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext (Work in Progress), January 2019, . Roca & Teibi Expires December 20, 2019 [Page 27] Internet-Draft RLC FEC Scheme June 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, . [RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, DOI 10.17487/RFC6364, October 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [tinymt32] Saito, M., Matsumoto, M., Roca, V., and E. Baccelli, "TinyMT32 Pseudo Random Number Generator (PRNG)", Transport Area Working Group (TSVWG) draft-roca-tsvwg- tinymt32 (Work in Progress), February 2019, . 12.2. Informative References [PGM13] Plank, J., Greenan, K., and E. Miller, "A Complete Treatment of Software Implementations of Finite Field Arithmetic for Erasure Coding Applications", University of Tennessee Technical Report UT-CS-13-717, http://web.eecs.utk.edu/~plank/plank/papers/ UT-CS-13-717.html, October 2013, . [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes", RFC 5170, DOI 10.17487/RFC5170, June 2008, . [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, DOI 10.17487/RFC5510, April 2009, . Roca & Teibi Expires December 20, 2019 [Page 28] Internet-Draft RLC FEC Scheme June 2019 [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward Error Correction (FEC) Schemes for FECFRAME", RFC 6681, DOI 10.17487/RFC6681, 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, . [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6816, DOI 10.17487/RFC6816, December 2012, . [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. Matsuzono, "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6865, DOI 10.17487/RFC6865, February 2013, . [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, . [Roca16] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. Thienot, "Block or Convolutional AL-FEC Codes? A Performance Comparison for Robust Low-Latency Communications", HAL open-archive document,hal-01395937 https://hal.inria.fr/hal-01395937/en/, November 2016, . [Roca17] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. Thienot, "Less Latency and Better Protection with AL-FEC Sliding Window Codes: a Robust Multimedia CBR Broadcast Case Study", 13th IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob17), October 2017 https://hal.inria.fr/hal-01571609v1/en/, October 2017, . Roca & Teibi Expires December 20, 2019 [Page 29] Internet-Draft RLC FEC Scheme June 2019 Appendix A. TinyMT32 Validation Criteria (Normative) PRNG determinism, for a given seed, is a requirement. Consequently, in order to validate an implementation of the TinyMT32 PRNG, the following criteria MUST be met. The first criterion focusses on the tinymt32_rand256(), where the 32-bit integer of the core TinyMT32 PRNG is scaled down to an 8-bit integer. Using a seed value of 1, the first 50 values returned by: tinymt32_rand256() as 8-bit unsigned integers MUST be equal to values provided in Figure 9, to be read line by line. 37 225 177 176 21 246 54 139 168 237 211 187 62 190 104 135 210 99 176 11 207 35 40 113 179 214 254 101 212 211 226 41 234 232 203 29 194 211 112 107 217 104 197 135 23 89 210 252 109 166 Figure 9: First 50 decimal values (to be read per line) returned by tinymt32_rand256() as 8-bit unsigned integers, with a seed value of 1. The second criterion focusses on the tinymt32_rand16(), where the 32-bit integer of the core TinyMT32 PRNG is scaled down to a 4-bit integer. Using a seed value of 1, the first 50 values returned by: tinymt32_rand16() as 4-bit unsigned integers MUST be equal to values provided in Figure 10, to be read line by line. 5 1 1 0 5 6 6 11 8 13 3 11 14 14 8 7 2 3 0 11 15 3 8 1 3 6 14 5 4 3 2 9 10 8 11 13 2 3 0 11 9 8 5 7 7 9 2 12 13 6 Figure 10: First 50 decimal values (to be read per line) returned by tinymt32_rand16() as 4-bit unsigned integers, with a seed value of 1. Roca & Teibi Expires December 20, 2019 [Page 30] Internet-Draft RLC FEC Scheme June 2019 Appendix B. Assessing the PRNG Adequacy (Informational) This annex discusses the adequacy of the TinyMT32 PRNG and the tinymt32_rand16() and tinymt32_rand256() functions, to the RLC FEC Schemes. The goal is to assess the adequacy of these two functions in producing coding coefficients that are sufficiently different from one another, across various repair symbols with repair key values in sequence (we can expect this approach to be commonly used by implementers, see Section 6.1). This section is purely informational and does not claim to be a solid evaluation. The two RLC FEC Schemes use the PRNG to produce pseudo-random coding coefficients (Section 3.6), each time a new repair symbol is needed. A different repair key is used for each repair symbol, usually by incrementing the repair key value (Section 6.1). For each repair symbol, a limited number of pseudo-random numbers is needed, depending on the DT and encoding window size (Section 3.6), using either tinymt32_rand16() or tinymt32_rand256(). Therefore we are more interested in the randomness of small sequences of random numbers mapped to 4-bit or 8-bit integers, than in the randomness of a very large sequence of random numbers which is not representative of the usage of the PRNG. Evaluation of tinymt32_rand16(): We first generate a huge number (1,000,000,000) of small sequences (20 pseudo-random numbers per sequence), increasing the seed value for each sequence, and perform statistics on the number of occurrences of each of the 16 possible values across all sequences. In this first test we consider 32-bit seed values in order to assess the PRNG quality after output truncation to 4 bits. Roca & Teibi Expires December 20, 2019 [Page 31] Internet-Draft RLC FEC Scheme June 2019 value occurrences percentage (%) (total of 20000000000) 0 1250036799 6.2502 1 1249995831 6.2500 2 1250038674 6.2502 3 1250000881 6.2500 4 1250023929 6.2501 5 1249986320 6.2499 6 1249995587 6.2500 7 1250020363 6.2501 8 1249995276 6.2500 9 1249982856 6.2499 10 1249984111 6.2499 11 1250009551 6.2500 12 1249955768 6.2498 13 1249994654 6.2500 14 1250000569 6.2500 15 1249978831 6.2499 Figure 11: tinymt32_rand16(): occurrence statistics across a huge number (1,000,000,000) of small sequences (20 pseudo-random numbers per sequence), with 0 as the first PRNG seed. The results (Figure 11) show that all possible values are almost equally represented, or said differently, that the tinymt32_rand16() output converges to a uniform distribution where each of the 16 possible values would appear exactly 1 / 16 * 100 = 6.25% of times. Since the RLC FEC Schemes use of this PRNG will be limited to 16-bit seed values, we carried out the same test for the first 2^^16 seed values only. The distribution (not shown) is of course less uniform, with value occurences ranging between 6.2121% (i.e., 81,423 occurences out of a total of 65536*20=1,310,720) and 6.2948% (i.e., 82,507 occurences). However, we do not believe it significantly impacts the RLC FEC Scheme behavior. Other types of biases may exist that may be visible with smaller tests, for instance to evaluate the convergence speed to a uniform distribution. We therefore perform 200 tests, each of them consisting in producing 200 sequences, keeping only the first value of each sequence. We use non overlapping repair keys for each sequence, starting with value 0 and increasing it after each use. Roca & Teibi Expires December 20, 2019 [Page 32] Internet-Draft RLC FEC Scheme June 2019 value min occurrences max occurrences average occurrences 0 4 21 6.3675 1 4 22 6.0200 2 4 20 6.3125 3 5 23 6.1775 4 5 24 6.1000 5 4 21 6.5925 6 5 30 6.3075 7 6 22 6.2225 8 5 26 6.1750 9 3 21 5.9425 10 5 24 6.3175 11 4 22 6.4300 12 5 21 6.1600 13 5 22 6.3100 14 4 26 6.3950 15 4 21 6.1700 Figure 12: tinymt32_rand16(): occurrence statistics across 200 tests, each of them consisting in 200 sequences of 1 pseudo-random number each, with non overlapping PRNG seeds in sequence starting from 0. Figure 12 shows across all 200 tests, for each of the 16 possible pseudo-random number values, the minimum (resp. maximum) number of times it appeared in a test, as well as the average number of occurrences across the 200 tests. Although the distribution is not perfect, there is no major bias. On the opposite, in the same conditions, the Park-Miller linear congruential PRNG of [RFC5170] with a result scaled down to 4-bit values, using seeds in sequence starting from 1, returns systematically 0 as the first value during some time, then after a certain repair key value threshold, it systematically returns 1, etc. Evaluation of tinymt32_rand256(): The same approach is used here. Results (not shown) are similar: occurrences vary between 7,810,3368 (i.e., 0.3905%) and 7,814,7952 (i.e., 0.3907%). Here also we see a convergence to the theoretical uniform distribution where each of the 256 possible values would appear exactly 1 / 256 * 100 = 0.390625% of times. Appendix C. Possible Parameter Derivation (Informational) Section 3.1 defines several parameters to control the encoder or decoder. This annex proposes techniques to derive these parameters according to the target use-case. This annex is informational, in the sense that using a different derivation technique will not prevent the encoder and decoder to interoperate: a decoder can still recover an erased source symbol without any error. However, in case Roca & Teibi Expires December 20, 2019 [Page 33] Internet-Draft RLC FEC Scheme June 2019 of a real-time flow, an inappropriate parameter derivation may lead to the decoding of erased source packets after their validity period, making them useless to the target application. This annex proposes an approach to reduce this risk, among other things. The FEC Schemes defined in this document can be used in various manners, depending on the target use-case: o the source ADU flow they protect may or may not have real-time constraints; o the source ADU flow may be a Constant Bitrate (CBR) or Variable BitRate (VBR) flow; o with a VBR source ADU flow, the flow's minimum and maximum bitrates may or may not be known; o and the communication path between encoder and decoder may be a CBR communication path (e.g., as with certain LTE-based broadcast channels) or not (general case, e.g., with Internet). The parameter derivation technique should be suited to the use-case, as described in the following sections. C.1. Case of a CBR Real-Time Flow In the following, we consider a real-time flow with max_lat latency budget. The encoding symbol size, E, is constant. The code rate, cr, is also constant, its value depending on the expected communication loss model (this choice is out of scope of this document). In a first configuration, the source ADU flow bitrate at the input of the FECFRAME sender is fixed and equal to br_in (in bits/s), and this value is known by the FECFRAME sender. It follows that the transmission bitrate at the output of the FECFRAME sender will be higher, depending on the added repair flow overhead. In order to comply with the maximum FEC-related latency budget, we have: dw_max_size = (max_lat * br_in) / (8 * E) assuming that the encoding and decoding times are negligible with respect to the target max_lat. This is a reasonable assumption in many situations (e.g., see Section 9.1 in case of small window sizes). Otherwise the max_lat parameter should be adjusted in order to avoid the problem. In any case, interoperability will never be compromized by choosing a too large value. In a second configuration, the FECFRAME sender generates a fixed bitrate flow, equal to the CBR communication path bitrate equal to br_out (in bits/s), and this value is known by the FECFRAME sender, Roca & Teibi Expires December 20, 2019 [Page 34] Internet-Draft RLC FEC Scheme June 2019 as in [Roca17]. The maximum source flow bitrate needs to be such that, with the added repair flow overhead, the total transmission bitrate remains inferior or equal to br_out. We have: dw_max_size = (max_lat * br_out * cr) / (8 * E) assuming here also that the encoding and decoding times are negligible with respect to the target max_lat. For decoding to be possible within the latency budget, it is required that the encoding window maximum size be smaller than or at most equal to the decoding window maximum size. The ew_max_size is the main parameter at a FECFRAME sender, but its exact value has no impact on the the FEC-related latency budget. The ew_max_size parameter is computed as follows: ew_max_size = dw_max_size * WSR / 255 In line with [Roca17], WSR = 191 is considered as a reasonable value (the resulting encoding to decoding window size ratio is then close to 0.75), but other values between 1 and 255 inclusive are possible, depending on the use-case. The dw_max_size is computed by a FECFRAME sender but not explicitly communicated to a FECFRAME receiver. However, a FECFRAME receiver can easily evaluate the ew_max_size by observing the maximum Number of Source Symbols (NSS) value contained in the Repair FEC Payload ID of received FEC Repair Packets (Section 4.1.3). A receiver can then easily compute dw_max_size: dw_max_size = max_NSS_observed * 255 / WSR A receiver can then chose an appropriate linear system maximum size: ls_max_size >= dw_max_size It is good practice to use a larger value for ls_max_size as explained in Appendix D, which does not impact maximum latency nor interoperability. In any case, for a given use-case (i.e., for target encoding and decoding devices and desired protection levels in front of communication impairments) and for the computed ew_max_size, dw_max_size and ls_max_size values, it is RECOMMENDED to check that the maximum encoding time and maximum memory requirements at a FECFRAME sender, and maximum decoding time and maximum memory requirements at a FECFRAME receiver, stay within reasonable bounds. When assuming that the encoding and decoding times are negligible Roca & Teibi Expires December 20, 2019 [Page 35] Internet-Draft RLC FEC Scheme June 2019 with respect to the target max_lat, this should be verified as well, otherwise the max_lat SHOULD be adjusted accordingly. The particular case of session start needs to be managed appropriately since the ew_size, starting at zero, increases each time a new source ADU is received by the FECFRAME sender, until it reaches the ew_max_size value. Therefore a FECFRAME receiver SHOULD continuously observe the received FEC Repair Packets, since the NSS value carried in the Repair FEC Payload ID will increase too, and adjust its ls_max_size accordingly if need be. With a CBR flow, session start is expected to be the only moment when the encoding window size will increase. Similarly, with a CBR real-time flow, the session end is expected to be the only moment when the encoding window size will progressively decrease. No adjustment of the ls_max_size is required at the FECFRAME receiver in that case. C.2. Other Types of Real-Time Flow In the following, we consider a real-time source ADU flow with a max_lat latency budget and a variable bitrate (VBR) measured at the entry of the FECFRAME sender. A first approach consists in considering the smallest instantaneous bitrate of the source ADU flow, when this parameter is known, and to reuse the derivation of Appendix C.1. Considering the smallest bitrate means that the encoding and decoding window maximum size estimations are pessimistic: these windows have the smallest size required to enable on-time decoding at a FECFRAME receiver. If the instantaneous bitrate is higher than this smallest bitrate, this approach leads to an encoding window that is unnecessarily small, which reduces robustness in front of long erasure bursts. Another approach consists in using ADU timing information (e.g., using the timestamp field of an RTP packet header, or registering the time upon receiving a new ADU). From the global FEC-related latency budget, the FECFRAME sender can derive a practical maximum latency budget for encoding operations, max_lat_for_encoding. For the FEC Schemes specified in this document, this latency budget SHOULD be computed with: max_lat_for_encoding = max_lat * WSR / 255 It follows that any source symbols associated to an ADU that has timed-out with respect to max_lat_for_encoding SHOULD be removed from the encoding window. With this approach there is no pre-determined ew_size value: this value fluctuates over the time according to the instantaneous source ADU flow bitrate. For practical reasons, a FECFRAME sender may still require that ew_size does not increase beyond a maximum value (Appendix C.3). Roca & Teibi Expires December 20, 2019 [Page 36] Internet-Draft RLC FEC Scheme June 2019 With both approaches, and no matter the choice of the FECFRAME sender, a FECFRAME receiver can still easily evaluate the ew_max_size by observing the maximum Number of Source Symbols (NSS) value contained in the Repair FEC Payload ID of received FEC Repair Packets. A receiver can then compute dw_max_size and derive an appropriate ls_max_size as explained in Appendix C.1. When the observed NSS fluctuates significantly, a FECFRAME receiver may want to adapt its ls_max_size accordingly. In particular when the NSS is significantly reduced, a FECFRAME receiver may want to reduce the ls_max_size too in order to limit computation complexity. A balance must be found between using an ls_max_size "too large" (which increases computation complexity and memory requirements) and the opposite (which reduces recovery performance). C.3. Case of a Non Real-Time Flow Finally there are configurations where a source ADU flow has no real- time constraints. FECFRAME and the FEC Schemes defined in this document can still be used. The choice of appropriate parameter values can be directed by practical considerations. For instance, it can derive from an estimation of the maximum memory amount that could be dedicated to the linear system at a FECFRAME receiver, or the maximum computation complexity at a FECFRAME receiver, both of them depending on the ls_max_size parameter. The same considerations also apply to the FECFRAME sender, where the maximum memory amount and computation complexity depend on the ew_max_size parameter. Here also, the NSS value contained in FEC Repair Packets is used by a FECFRAME receiver to determine the current coding window size and ew_max_size by observing its maximum value over the time. Appendix D. Decoding Beyond Maximum Latency Optimization (Informational) This annex introduces non normative considerations. It is provided as suggestions, without any impact on interoperability. For more information see [Roca16]. With a real-time source ADU flow, it is possible to improve the decoding performance of sliding window codes without impacting maximum latency, at the cost of extra memory and CPU overhead. The optimization consists, for a FECFRAME receiver, to extend the linear system beyond the decoding window maximum size, by keeping a certain number of old source symbols whereas their associated ADUs timed-out: ls_max_size > dw_max_size Roca & Teibi Expires December 20, 2019 [Page 37] Internet-Draft RLC FEC Scheme June 2019 Usually the following choice is a good trade-off between decoding performance and extra CPU overhead: ls_max_size = 2 * dw_max_size When the dw_max_size is very small, it may be preferable to keep a minimum ls_max_size value (e.g., LS_MIN_SIZE_DEFAULT = 40 symbols). Going below this threshold will not save a significant amount of memory nor CPU cycles. Therefore: ls_max_size = max(2 * dw_max_size, LS_MIN_SIZE_DEFAULT) Finally, it is worth noting that a receiver that benefits from an FEC protection significantly higher than what is required to recover from packet losses, can choose to reduce the ls_max_size. In that case lost ADUs will be recovered without relying on this optimization. ls_max_size /---------------------------------^-------------------------------\ late source symbols (pot. decoded but not delivered) dw_max_size /--------------^-----------------\ /--------------^---------------\ src0 src1 src2 src3 src4 src5 src6 src7 src8 src9 src10 src11 src12 Figure 13: Relationship between parameters to decode beyond maximum latency. It means that source symbols, and therefore ADUs, may be decoded even if the added latency exceeds the maximum value permitted by the application (the "late source symbols" of Figure 13). It follows that the corresponding ADUs will not be useful to the application. However, decoding these "late symbols" significantly improves the global robustness in bad reception conditions and is therefore recommended for receivers experiencing bad communication conditions [Roca16]. In any case whether or not to use this optimization and what exact value to use for the ls_max_size parameter are local decisions made by each receiver independently, without any impact on the other receivers nor on the source. Authors' Addresses Vincent Roca INRIA Univ. Grenoble Alpes France EMail: vincent.roca@inria.fr Roca & Teibi Expires December 20, 2019 [Page 38] Internet-Draft RLC FEC Scheme June 2019 Belkacem Teibi INRIA Univ. Grenoble Alpes France EMail: belkacem.teibi@gmail.com Roca & Teibi Expires December 20, 2019 [Page 39] ./draft-ietf-taps-minset-11.txt0000644000764400076440000033550313353121522015624 0ustar iustyiusty TAPS M. Welzl Internet-Draft S. Gjessing Intended status: Informational University of Oslo Expires: March 31, 2019 September 27, 2018 A Minimal Set of Transport Services for End Systems draft-ietf-taps-minset-11 Abstract This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. 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 https://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 31, 2019. Copyright Notice Copyright (c) 2018 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 (https://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. Welzl & Gjessing Expires March 31, 2019 [Page 1] Internet-Draft Minimal Transport Services September 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deriving the minimal set . . . . . . . . . . . . . . . . . . 5 4. The Reduced Set of Transport Features . . . . . . . . . . . . 6 4.1. CONNECTION Related Transport Features . . . . . . . . . . 7 4.2. DATA Transfer Related Transport Features . . . . . . . . 8 4.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 9 4.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 9 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Sending Messages, Receiving Bytes . . . . . . . . . . . . 10 5.2. Stream Schedulers Without Streams . . . . . . . . . . . . 11 5.3. Early Data Transmission . . . . . . . . . . . . . . . . . 11 5.4. Sender Running Dry . . . . . . . . . . . . . . . . . . . 12 5.5. Capacity Profile . . . . . . . . . . . . . . . . . . . . 13 5.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 13 5.7. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 14 6. The Minimal Set of Transport Features . . . . . . . . . . . . 14 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 14 6.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 18 6.2.1. Connection groups . . . . . . . . . . . . . . . . . . 18 6.2.2. Individual connections . . . . . . . . . . . . . . . 20 6.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 20 6.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 20 6.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. The Superset of Transport Features . . . . . . . . . 25 A.1. CONNECTION Related Transport Features . . . . . . . . . . 26 A.2. DATA Transfer Related Transport Features . . . . . . . . 42 A.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . 42 A.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . 46 A.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix B. Revision information . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction Currently, the set of transport services that most applications use is based on TCP and UDP (and protocols that are layered on top of them); this limits the ability for the network stack to make use of features of other transport protocols. For example, if a protocol Welzl & Gjessing Expires March 31, 2019 [Page 2] Internet-Draft Minimal Transport Services September 2018 supports out-of-order message delivery but applications always assume that the network provides an ordered bytestream, then the network stack can not immediately deliver a message that arrives out-of- order: doing so would break a fundamental assumption of the application. The net result is unnecessary head-of-line blocking delay. By exposing the transport services of multiple transport protocols, a transport system can make it possible for applications to use these services without being statically bound to a specific transport protocol. The first step towards the design of such a system was taken by [RFC8095], which surveys a large number of transports, and [RFC8303] as well as [RFC8304], which identify the specific transport features that are exposed to applications by the protocols TCP, MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control mechanism. LEDBAT was included as the only congestion control mechanism in this list because the "low extra delay background transport" service that it offers is significantly different from the typical service provided by other congestion control mechanisms. This memo is based on these documents and follows the same terminology (also listed below). Because the considered transport protocols conjointly cover a wide range of transport features, there is reason to hope that the resulting set (and the reasoning that led to it) will also apply to many aspects of other transport protocols that may be in use today, or may be designed in the future. By decoupling applications from transport protocols, a transport system provides a different abstraction level than the Berkeley sockets interface [POSIX]. As with high- vs. low-level programming languages, a higher abstraction level allows more freedom for automation below the interface, yet it takes some control away from the application programmer. This is the design trade-off that a transport system developer is facing, and this document provides guidance on the design of this abstraction level. Some transport features are currently rarely offered by APIs, yet they must be offered or they can never be used. Other transport features are offered by the APIs of the protocols covered here, but not exposing them in an API would allow for more freedom to automate protocol usage in a transport system. The minimal set presented here is an effort to find a middle ground that can be recommended for transport systems to implement, on the basis of the transport features discussed in [RFC8303]. Applications use a wide variety of APIs today. While this document was created to ensure the API developed in the Transport Services (TAPS) Working Group ([I-D.ietf-taps-interface]) includes the most important transport features, the minimal set presented here must be reflected in *all* network APIs in order for the underlying Welzl & Gjessing Expires March 31, 2019 [Page 3] Internet-Draft Minimal Transport Services September 2018 functionality to become usable everywhere. For example, it does not help an application that talks to a library which offers its own communication interface if the underlying Berkeley Sockets API is extended to offer "unordered message delivery", but the library only exposes an ordered bytestream. Both the Berkeley Sockets API and the library would have to expose the "unordered message delivery" transport feature (alternatively, there may be ways for certain types of libraries to use this transport feature without exposing it, based on knowledge about the applications -- but this is not the general case). Similarly, transport protocols such as SCTP offer multi- streaming, which cannot be utilized, e.g., to prioritize messages between streams, unless applications communicate the priorities and the group of connections upon which these priorities should be applied. In most situations, in the interest of being as flexible and efficient as possible, the best choice will be for a library to expose at least all of the transport features that are recommended as a "minimal set" here. This "minimal set" can be implemented "one-sided" over TCP. This means that a sender-side transport system can talk to a standard TCP receiver, and a receiver-side transport system can talk to a standard TCP sender. If certain limitations are put in place, the "minimal set" can also be implemented "one-sided" over UDP. While the possibility of such "one-sided" implementation may help deployment, it comes at the cost of limiting the set to services that can also be provided by TCP (or, with further limitations, UDP). Thus, the minimal set of transport features here is applicable for many, but not all, applications: some application protocols have requirements that are not met by this "minimal set". Note that, throughout this document, protocols are meant to be used natively. For example, when transport features of UDP, or "implementation over" UDP is discussed, this refers to native usage of UDP. 2. Terminology Transport 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. Welzl & Gjessing Expires March 31, 2019 [Page 4] Internet-Draft Minimal Transport Services September 2018 Application: an entity that uses a transport layer interface for end-to-end delivery of data across the network (this may also be an upper layer protocol or tunnel encapsulation). Application-specific knowledge: knowledge that only applications have. End system: an entity that communicates with one or more other end systems using a transport protocol. An end system provides a transport layer interface to applications. Connection: shared state of two or more end systems that persists across messages that are transmitted between these end systems. Connection Group: a set of connections which share the same configuration (configuring one of them causes all other connections in the same group to be configured in the same way). We call connections that belong to a connection group "grouped", while "ungrouped" connections are not a part of a connection group. Socket: the combination of a destination IP address and a destination port number. Moreover, throughout the document, the protocol name "UDP(-Lite)" is used when discussing transport features that are equivalent for UDP and UDP-Lite; similarly, the protocol name "TCP" refers to both TCP and MPTCP. 3. Deriving the minimal set We assume that applications have no specific requirements that need knowledge about the network, e.g. regarding the choice of network interface or the end-to-end path. Even with these assumptions, there are certain requirements that are strictly kept by transport protocols today, and these must also be kept by a transport system. Some of these requirements relate to transport features that we call "Functional". Functional transport features provide functionality that cannot be used without the application knowing about them, or else they violate assumptions that might cause the application to fail. For example, ordered message delivery is a functional transport feature: it cannot be configured without the application knowing about it because the application's assumption could be that messages always arrive in order. Failure includes any change of the application behavior that is not performance oriented, e.g. security. "Change DSCP" and "Disable Nagle algorithm" are examples of transport features that we call "Optimizing": if a transport system autonomously decides to enable or disable them, an application will not fail, but a transport system may be able to communicate more efficiently if the application is in control of this optimizing Welzl & Gjessing Expires March 31, 2019 [Page 5] Internet-Draft Minimal Transport Services September 2018 transport feature. These transport features require application- specific knowledge (e.g., about delay/bandwidth requirements or the length of future data blocks that are to be transmitted). The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be utilized by a transport system on its own without involving the application are called "Automatable". We approach the construction of a minimal set of transport features in the following way: 1. Categorization (Appendix A): the superset of transport features from [RFC8303] is presented, and transport features are categorized as Functional, Optimizing or Automatable for later reduction. 2. Reduction (Section 4): a shorter list of transport features is derived from the categorization in the first step. This removes all transport features that do not require application-specific knowledge or would result in semantically incorrect behavior if they were implemented over TCP or UDP. 3. Discussion (Section 5): the resulting list shows a number of peculiarities that are discussed, to provide a basis for constructing the minimal set. 4. Construction (Section 6): Based on the reduced set and the discussion of the transport features therein, a minimal set is constructed. Following [RFC8303] and retaining its terminology, we divide the transport features into two main groups as follows: 1. CONNECTION related transport features - ESTABLISHMENT - AVAILABILITY - MAINTENANCE - TERMINATION 2. DATA Transfer related transport features - Sending Data - Receiving Data - Errors 4. The Reduced Set of Transport Features By hiding automatable transport features from the application, a transport system can gain opportunities to automate the usage of network-related functionality. This can facilitate using the Welzl & Gjessing Expires March 31, 2019 [Page 6] Internet-Draft Minimal Transport Services September 2018 transport system for the application programmer and it allows for optimizations that may not be possible for an application. For instance, system-wide configurations regarding the usage of multiple interfaces can better be exploited if the choice of the interface is not entirely up to the application. Therefore, since they are not strictly necessary to expose in a transport system, we do not include automatable transport features in the reduced set of transport features. This leaves us with only the transport features that are either optimizing or functional. A transport system should be able to communicate via TCP or UDP if alternative transport protocols are found not to work. For many transport features, this is possible -- often by simply not doing anything when a specific request is made. For some transport features, however, it was identified that direct usage of neither TCP nor UDP is possible: in these cases, even not doing anything would incur semantically incorrect behavior. Whenever an application would make use of one of these transport features, this would eliminate the possibility to use TCP or UDP. Thus, we only keep the functional and optimizing transport features for which an implementation over either TCP or UDP is possible in our reduced set. The following list contains the transport features from Appendix A, reduced using these rules. The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. In the list, we therefore precede a transport feature with "T:" if an implementation over TCP is possible, "U:" if an implementation over UDP is possible, and "T,U:" if an implementation over either TCP or UDP is possible. 4.1. CONNECTION Related Transport Features ESTABLISHMENT: o T,U: Connect o T,U: Specify number of attempts and/or timeout for the first establishment message o T,U: Disable MPTCP o T: Configure authentication o T: Hand over a message to reliably transfer (possibly multiple times) before connection establishment o T: Hand over a message to reliably transfer during connection establishment AVAILABILITY: o T,U: Listen o T,U: Disable MPTCP Welzl & Gjessing Expires March 31, 2019 [Page 7] Internet-Draft Minimal Transport Services September 2018 o T: Configure authentication MAINTENANCE: o T: Change timeout for aborting connection (using retransmit limit or time value) o T: Suggest timeout to the peer o T,U: Disable Nagle algorithm o T,U: Notification of Excessive Retransmissions (early warning below abortion threshold) o T,U: Specify DSCP field o T,U: Notification of ICMP error message arrival o T: Change authentication parameters o T: Obtain authentication information o T,U: Set Cookie life value o T,U: Choose a scheduler to operate between streams of an association o T,U: Configure priority or weight for a scheduler o T,U: Disable checksum when sending o T,U: Disable checksum requirement when receiving o T,U: Specify checksum coverage used by the sender o T,U: Specify minimum checksum coverage required by receiver o T,U: Specify DF field o T,U: Get max. transport-message size that may be sent using a non- fragmented IP packet from the configured interface o T,U: Get max. transport-message size that may be received from the configured interface o T,U: Obtain ECN field o T,U: Enable and configure a "Low Extra Delay Background Transfer" TERMINATION: o T: Close after reliably delivering all remaining data, causing an event informing the application on the other side o T: Abort without delivering remaining data, causing an event informing the application on the other side o T,U: Abort without delivering remaining data, not causing an event informing the application on the other side o T,U: Timeout event when data could not be delivered for too long 4.2. DATA Transfer Related Transport Features 4.2.1. Sending Data o T: Reliably transfer data, with congestion control o T: Reliably transfer a message, with congestion control o T,U: Unreliably transfer a message o T: Configurable Message Reliability Welzl & Gjessing Expires March 31, 2019 [Page 8] Internet-Draft Minimal Transport Services September 2018 o T: Ordered message delivery (potentially slower than unordered) o T,U: Unordered message delivery (potentially faster than ordered) o T,U: Request not to bundle messages o T: Specifying a key id to be used to authenticate a message o T,U: Request not to delay the acknowledgement (SACK) of a message 4.2.2. Receiving Data o T,U: Receive data (with no message delimiting) o U: Receive a message o T,U: Information about partial message arrival 4.2.3. Errors This section describes sending failures that are associated with a specific call to in the "Sending Data" category (Appendix A.2.1). o T,U: Notification of send failures o T,U: Notification that the stack has no more user data to send o T,U: Notification to a receiver that a partial message delivery has been aborted 5. Discussion The reduced set in the previous section exhibits a number of peculiarities, which we will discuss in the following. This section focuses on TCP because, with the exception of one particular transport feature ("Receive a message" -- we will discuss this in Section 5.1), the list shows that UDP is strictly a subset of TCP. We can first try to understand how to build a transport system that can run over TCP, and then narrow down the result further to allow that the system can always run over either TCP or UDP (which effectively means removing everything related to reliability, ordering, authentication and closing/aborting with a notification to the peer). Note that, because the functional transport features of UDP are -- with the exception of "Receive a message" -- a subset of TCP, TCP can be used as a replacement for UDP whenever an application does not need message delimiting (e.g., because the application-layer protocol already does it). This has been recognized by many applications that already do this in practice, by trying to communicate with UDP at first, and falling back to TCP in case of a connection failure. Welzl & Gjessing Expires March 31, 2019 [Page 9] Internet-Draft Minimal Transport Services September 2018 5.1. Sending Messages, Receiving Bytes For implementing a transport system over TCP, there are several transport features related to sending, but only a single transport feature related to receiving: "Receive data (with no message delimiting)" (and, strangely, "information about partial message arrival"). Notably, the transport feature "Receive a message" is also the only non-automatable transport feature of UDP(-Lite) for which no implementation over TCP is possible. To support these TCP receiver semantics, we define an "Application- Framed Bytestream" (AFra-Bytestream). AFra-Bytestreams allow senders to operate on messages while minimizing changes to the TCP socket API. In particular, nothing changes on the receiver side - data can be accepted via a normal TCP socket. In an AFra-Bytestream, the sending application can optionally inform the transport about message boundaries and required properties per message (configurable order and reliability, or embedding a request not to delay the acknowledgement of a message). Whenever the sending application specifies per-message properties that relax the notion of reliable in-order delivery of bytes, it must assume that the receiving application is 1) able to determine message boundaries, provided that messages are always kept intact, and 2) able to accept these relaxed per-message properties. Any signaling of such information to the peer is up to an application-layer protocol and considered out of scope of this document. For example, if an application requests to transfer fixed-size messages of 100 bytes with partial reliability, this needs the receiving application to be prepared to accept data in chunks of 100 bytes. If, then, some of these 100-byte messages are missing (e.g., if SCTP with Configurable Reliability is used), this is the expected application behavior. With TCP, no messages would be missing, but this is also correct for the application, and the possible retransmission delay is acceptable within the best-effort service model (see [RFC7305], Section 3.5). Still, the receiving application would separate the byte stream into 100-byte chunks. Note that this usage of messages does not require all messages to be equal in size. Many application protocols use some form of Type- Length-Value (TLV) encoding, e.g. by defining a header including length fields; another alternative is the use of byte stuffing methods such as COBS [COBS]. If an application needs message numbers, e.g. to restore the correct sequence of messages, these must also be encoded by the application itself, as the sequence number related transport features of SCTP are not provided by the "minimum set" (in the interest of enabling usage of TCP). Welzl & Gjessing Expires March 31, 2019 [Page 10] Internet-Draft Minimal Transport Services September 2018 5.2. Stream Schedulers Without Streams We have already stated that multi-streaming does not require application-specific knowledge. Potential benefits or disadvantages of, e.g., using two streams of an SCTP association versus using two separate SCTP associations or TCP connections are related to knowledge about the network and the particular transport protocol in use, not the application. However, the transport features "Choose a scheduler to operate between streams of an association" and "Configure priority or weight for a scheduler" operate on streams. Here, streams identify communication channels between which a scheduler operates, and they can be assigned a priority. Moreover, the transport features in the MAINTENANCE category all operate on assocations in case of SCTP, i.e. they apply to all streams in that assocation. With only these semantics necessary to represent, the interface to a transport system becomes easier if we assume that connections may be not only a transport protocol's connection or association, but could also be a stream of an existing SCTP association, for example. We only need to allow for a way to define a possible grouping of connections. Then, all MAINTENANCE transport features can be said to operate on connection groups, not connections, and a scheduler operates on the connections within a group. To be compatible with multiple transport protocols and uniformly allow access to both transport connections and streams of a multi- streaming protocol, the semantics of opening and closing need to be the most restrictive subset of all of the underlying options. For example, TCP's support of half-closed connections can be seen as a feature on top of the more restrictive "ABORT"; this feature cannot be supported because not all protocols used by a transport system (including streams of an association) support half-closed connections. 5.3. Early Data Transmission There are two transport features related to transferring a message early: "Hand over a message to reliably transfer (possibly multiple times) before connection establishment", which relates to TCP Fast Open [RFC7413], and "Hand over a message to reliably transfer during connection establishment", which relates to SCTP's ability to transfer data together with the COOKIE-Echo chunk. Also without TCP Fast Open, TCP can transfer data during the handshake, together with the SYN packet -- however, the receiver of this data may not hand it over to the application until the handshake has completed. Also, different from TCP Fast Open, this data is not delimited as a message by TCP (thus, not visible as a ``message''). This functionality is Welzl & Gjessing Expires March 31, 2019 [Page 11] Internet-Draft Minimal Transport Services September 2018 commonly available in TCP and supported in several implementations, even though the TCP specification does not explain how to provide it to applications. A transport system could differentiate between the cases of transmitting data "before" (possibly multiple times) or "during" the handshake. Alternatively, it could also assume that data that are handed over early will be transmitted as early as possible, and "before" the handshake would only be used for messages that are explicitly marked as "idempotent" (i.e., it would be acceptable to transfer them multiple times). The amount of data that can successfully be transmitted before or during the handshake depends on various factors: the transport protocol, the use of header options, the choice of IPv4 and IPv6 and the Path MTU. A transport system should therefore allow a sending application to query the maximum amount of data it can possibly transmit before (or, if exposed, during) connection establishment. 5.4. Sender Running Dry The transport feature "Notification that the stack has no more user data to send" relates to SCTP's "SENDER DRY" notification. Such notifications can, in principle, be used to avoid having an unnecessarily large send buffer, yet ensure that the transport sender always has data available when it has an opportunity to transmit it. This has been found to be very beneficial for some applications [WWDC2015]. However, "SENDER DRY" truly means that the entire send buffer (including both unsent and unacknowledged data) has emptied -- i.e., when it notifies the sender, it is already too late, the transport protocol already missed an opportunity to send data. Some modern TCP implementations now include the unspecified "TCP_NOTSENT_LOWAT" socket option that was proposed in [WWDC2015], which limits the amount of unsent data that TCP can keep in the socket buffer; this allows to specify at which buffer filling level the socket becomes writable, rather than waiting for the buffer to run empty. SCTP allows to configure the sender-side buffer too: the automatable Transport Feature "Configure send buffer size" provides this functionality, but only for the complete buffer, which includes both unsent and unacknowledged data. SCTP does not allow to control these two sizes separately. It therefore makes sense for a transport system to allow for uniform access to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification. Welzl & Gjessing Expires March 31, 2019 [Page 12] Internet-Draft Minimal Transport Services September 2018 5.5. Capacity Profile The transport features: o Disable Nagle algorithm o Enable and configure a "Low Extra Delay Background Transfer" o Specify DSCP field all relate to a QoS-like application need such as "low latency" or "scavenger". In the interest of flexibility of a transport system, they could therefore be offered in a uniform, more abstract way, where a transport system could e.g. decide by itself how to use combinations of LEDBAT-like congestion control and certain DSCP values, and an application would only specify a general "capacity profile" (a description of how it wants to use the available capacity). A need for "lowest possible latency at the expense of overhead" could then translate into automatically disabling the Nagle algorithm. In some cases, the Nagle algorithm is best controlled directly by the application because it is not only related to a general profile but also to knowledge about the size of future messages. For fine-grain control over Nagle-like functionality, the "Request not to bundle messages" is available. 5.6. Security Both TCP and SCTP offer authentication. TCP authenticates complete segments. SCTP allows to configure which of SCTP's chunk types must always be authenticated -- if this is exposed as such, it creates an undesirable dependency on the transport protocol. For compatibility with TCP, a transport system should only allow to configure complete transport layer packets, including headers, IP pseudo-header (if any) and payload. Security is discussed in a separate document [I-D.ietf-taps-transport-security]. The minimal set presented in the present document excludes all security related transport features from Appendix A: "Configure authentication", "Change authentication parameters", "Obtain authentication information" and "Set Cookie life value" as well as "Specifying a key id to be used to authenticate a message". It also excludes security transport features not listed in Appendix A, including content privacy to in-path devices. Welzl & Gjessing Expires March 31, 2019 [Page 13] Internet-Draft Minimal Transport Services September 2018 5.7. Packet Size UDP(-Lite) has a transport feature called "Specify DF field". This yields an error message in case of sending a message that exceeds the Path MTU, which is necessary for a UDP-based application to be able to implement Path MTU Discovery (a function that UDP-based applications must do by themselves). The "Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface" transport feature yields an upper limit for the Path MTU (minus headers) and can therefore help to implement Path MTU Discovery more efficiently. 6. The Minimal Set of Transport Features Based on the categorization, reduction, and discussion in Section 3, this section describes a minimal set of transport features that end systems should offer. Any configuration based the described minimum set of transport feature can always be realized over TCP but also gives the transport system flexibility to choose another transport if implemented. In the text of this section, "not UDP" is used to indicate elements of the system that cannot be implemented over UDP. Conversely, all elements of the system that are not marked with "not UDP" can also be implemented over UDP. The arguments laid out in Section 5 ("discussion") were used to make the final representation of the minimal set as short, simple and general as possible. There may be situations where these arguments do not apply -- e.g., implementers may have specific reasons to expose multi-streaming as a visible functionality to applications, or the restrictive open / close semantics may be problematic under some circumstances. In such cases, the representation in Section 4 ("reduction") should be considered. As in Section 3, Section 4 and [RFC8303], we categorize the minimal set of transport features as 1) CONNECTION related (ESTABLISHMENT, AVAILABILITY, MAINTENANCE, TERMINATION) and 2) DATA Transfer related (Sending Data, Receiving Data, Errors). Here, the focus is on connections that the transport system offers as an abstraction to the application, as opposed to connections of transport protocols that the transport system uses. 6.1. ESTABLISHMENT, AVAILABILITY and TERMINATION A connection must first be "created" to allow for some initial configuration to be carried out before the transport system can actively or passively establish communication with a remote end system. As a configuration of the newly created connection, an application can choose to disallow usage of MPTCP. Furthermore, all Welzl & Gjessing Expires March 31, 2019 [Page 14] Internet-Draft Minimal Transport Services September 2018 configuration parameters in Section 6.2 can be used initially, although some of them may only take effect when a connection has been established with a chosen transport protocol. Configuring a connection early helps a transport system make the right decisions. For example, grouping information can influence the transport system to implement a connection as a stream of a multi-streaming protocol's existing association or not. For ungrouped connections, early configuration is necessary because it allows the transport system to know which protocols it should try to use. In particular, a transport system that only makes a one-time choice for a particular protocol must know early about strict requirements that must be kept, or it can end up in a deadlock situation (e.g., having chosen UDP and later be asked to support reliable transfer). As an example description of how to correctly handle these cases, we provide the following decision tree (this is derived from Section 4.1 excluding authentication, as explained in Section 9): Welzl & Gjessing Expires March 31, 2019 [Page 15] Internet-Draft Minimal Transport Services September 2018 - Will it ever be necessary to offer any of the following? * Reliably transfer data * Notify the peer of closing/aborting * Preserve data ordering Yes: SCTP or TCP can be used. - Is any of the following useful to the application? * Choosing a scheduler to operate between connections in a group, with the possibility to configure a priority or weight per connection * Configurable message reliability * Unordered message delivery * Request not to delay the acknowledgement (SACK) of a message Yes: SCTP is preferred. No: - Is any of the following useful to the application? * Hand over a message to reliably transfer (possibly multiple times) before connection establishment * Suggest timeout to the peer * Notification of Excessive Retransmissions (early warning below abortion threshold) * Notification of ICMP error message arrival Yes: TCP is preferred. No: SCTP and TCP are equally preferable. No: all protocols can be used. - Is any of the following useful to the application? * Specify checksum coverage used by the sender * Specify minimum checksum coverage required by receiver Yes: UDP-Lite is preferred. No: UDP is preferred. Note that this decision tree is not optimal for all cases. For example, if an application wants to use "Specify checksum coverage used by the sender", which is only offered by UDP-Lite, and "Configure priority or weight for a scheduler", which is only offered by SCTP, the above decision tree will always choose UDP-Lite, making it impossible to use SCTP's schedulers with priorities between grouped connections. Also, several other factors may influence the decisions for or against a protocol -- e.g. penetration rates, the ability to work through NATs, etc. We caution implementers to be aware of the full set of trade-offs, for which we recommend Welzl & Gjessing Expires March 31, 2019 [Page 16] Internet-Draft Minimal Transport Services September 2018 consulting the list in Section 4.1 when deciding how to initialize a connection. To summarize, the following parameters serve as input for the transport system to help it choose and configure a suitable protocol: o Reliability: a boolean that should be set to true when any of the following will be useful to the application: reliably transfer data; notify the peer of closing/aborting; preserve data ordering. o Checksum coverage: a boolean to specify whether it will be useful to the application to specify checksum coverage when sending or receiving. o Configure message priority: a boolean that should be set to true when any of the following per-message configuration or prioritization mechanisms will be useful to the application: choosing a scheduler to operate between grouped connections, with the possibility to configure a priority or weight per connection; configurable message reliability; unordered message delivery; requesting not to delay the acknowledgement (SACK) of a message. o Early message timeout notifications: a boolean that should be set to true when any of the following will be useful to the application: hand over a message to reliably transfer (possibly multiple times) before connection establishment; suggest timeout to the peer; notification of excessive retransmissions (early warning below abortion threshold); notification of ICMP error message arrival. Once a connection is created, it can be queried for the maximum amount of data that an application can possibly expect to have reliably transmitted before or during transport connection establishment (with zero being a possible answer) (see Section 6.2.1). An application can also give the connection a message for reliable transmission before or during connection establishment (not UDP); the transport system will then try to transmit it as early as possible. An application can facilitate sending a message particularly early by marking it as "idempotent" (see Section 6.3.1); in this case, the receiving application must be prepared to potentially receive multiple copies of the message (because idempotent messages are reliably transferred, asking for idempotence is not necessary for systems that support UDP). After creation, a transport system can actively establish communication with a peer, or it can passively listen for incoming connection requests. Note that active establishment may or may not trigger a notification on the listening side. It is possible that the first notification on the listening side is the arrival of the first data that the active side sends (a receiver-side transport system could handle this by continuing to block a "Listen" call, Welzl & Gjessing Expires March 31, 2019 [Page 17] Internet-Draft Minimal Transport Services September 2018 immediately followed by issuing "Receive", for example; callback- based implementations could simply skip the equivalent of "Listen"). This also means that the active opening side is assumed to be the first side sending data. A transport system can actively close a connection, i.e. terminate it after reliably delivering all remaining data to the peer (if reliable data delivery was requested earlier (not UDP)), in which case the peer is notified that the connection is closed. Alternatively, a connection can be aborted without delivering outstanding data to the peer. In case reliable or partially reliable data delivery was requested earlier (not UDP), the peer is notified that the connection is aborted. A timeout can be configured to abort a connection when data could not be delivered for too long (not UDP); however, timeout- based abortion does not notify the peer application that the connection has been aborted. Because half-closed connections are not supported, when a host implementing a transport system receives a notification that the peer is closing or aborting the connection (not UDP), its peer may not be able to read outstanding data. This means that unacknowledged data residing in a transport system's send buffer may have to be dropped from that buffer upon arrival of a "close" or "abort" notification from the peer. 6.2. MAINTENANCE A transport system must offer means to group connections, but it cannot guarantee truly grouping them using the transport protocols that it uses (e.g., it cannot be guaranteed that connections become multiplexed as streams on a single SCTP association when SCTP may not be available). The transport system must therefore ensure that group- versus non-group-configurations are handled correctly in some way (e.g., by applying the configuration to all grouped connections even when they are not multiplexed, or informing the application about grouping success or failure). As a general rule, any configuration described below should be carried out as early as possible to aid the transport system's decision making. 6.2.1. Connection groups The following transport features and notifications (some directly from Section 4, some new or changed, based on the discussion in Section 5) automatically apply to all grouped connections: (not UDP) Configure a timeout: this can be done with the following parameters: Welzl & Gjessing Expires March 31, 2019 [Page 18] Internet-Draft Minimal Transport Services September 2018 o A timeout value for aborting connections, in seconds o A timeout value to be suggested to the peer (if possible), in seconds o The number of retransmissions after which the application should be notifed of "Excessive Retransmissions" Configure urgency: this can be done with the following parameters: o A number to identify the type of scheduler that should be used to operate between connections in the group (no guarantees given). Schedulers are defined in [RFC8260]. o A "capacity profile" number to identify how an application wants to use its available capacity. Choices can be "lowest possible latency at the expense of overhead" (which would disable any Nagle-like algorithm), "scavenger", or values that help determine the DSCP value for a connection (e.g. similar to table 1 in [I-D.ietf-tsvwg-rtcweb-qos]). o A buffer limit (in bytes); when the sender has less than the provided limit of bytes in the buffer, the application may be notified. Notifications are not guaranteed, and it is optional for a transport system to support buffer limit values greater than 0. Note that this limit and its notification should operate across the buffers of the whole transport system, i.e. also any potential buffers that the transport system itself may use on top of the transport's send buffer. Following Section 5.7, these properties can be queried: o The maximum message size that may be sent without fragmentation via the configured interface. This is optional for a transport system to offer, and may return an error ("not available"). It can aid applications implementing Path MTU Discovery. o The maximum transport message size that can be sent, in bytes. Irrespective of fragmentation, there is a size limit for the messages that can be handed over to SCTP or UDP(-Lite); because the service provided by a transport system is independent of the transport protocol, it must allow an application to query this value -- the maximum size of a message in an Application-Framed- Bytestream (see Section 5.1). This may also return an error when data is not delimited ("not available"). o The maximum transport message size that can be received from the configured interface, in bytes (or "not available"). o The maximum amount of data that can possibly be sent before or during connection establishment, in bytes. In addition to the already mentioned closing / aborting notifications and possible send errors, the following notifications can occur: Welzl & Gjessing Expires March 31, 2019 [Page 19] Internet-Draft Minimal Transport Services September 2018 o Excessive Retransmissions: the configured (or a default) number of retransmissions has been reached, yielding this early warning below an abortion threshold. o ICMP Arrival (parameter: ICMP message): an ICMP packet carrying the conveyed ICMP message has arrived. o ECN Arrival (parameter: ECN value): a packet carrying the conveyed ECN value has arrived. This can be useful for applications implementing congestion control. o Timeout (parameter: s seconds): data could not be delivered for s seconds. o Drain: the send buffer has either drained below the configured buffer limit or it has become completely empty. This is a generic notification that tries to enable uniform access to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification (as discussed in Section 5.4 -- SCTP's "SENDER DRY" is a special case where the threshold (for unsent data) is 0 and there is also no more unacknowledged data in the send buffer). 6.2.2. Individual connections Configure priority or weight for a scheduler, as described in [RFC8260]. Configure checksum usage: this can be done with the following parameters, but there is no guarantee that any checksum limitations will indeed be enforced (the default behavior is "full coverage, checksum enabled"): o A boolean to enable / disable usage of a checksum when sending o The desired coverage (in bytes) of the checksum used when sending o A boolean to enable / disable requiring a checksum when receiving o The required minimum coverage (in bytes) of the checksum when receiving 6.3. DATA Transfer 6.3.1. Sending Data When sending a message, no guarantees are given about the preservation of message boundaries to the peer; if message boundaries are needed, the receiving application at the peer must know about them beforehand (or the transport system cannot use TCP). Note that an application should already be able to hand over data before the transport system establishes a connection with a chosen transport protocol. Regarding the message that is being handed over, the following parameters can be used: Welzl & Gjessing Expires March 31, 2019 [Page 20] Internet-Draft Minimal Transport Services September 2018 o Reliability: this parameter is used to convey a choice of: fully reliable with congestion control (not UDP), unreliable without congestion control, unreliable with congestion control (not UDP), partially reliable with congestion control (see [RFC3758] and [RFC7496] for details on how to specify partial reliability) (not UDP). The latter two choices are optional for a transport system to offer and may result in full reliability. Note that applications sending unreliable data without congestion control should themselves perform congestion control in accordance with [RFC8085]. o (not UDP) Ordered: this boolean parameter lets an application choose between ordered message delivery (true) and possibly unordered, potentially faster message delivery (false). o Bundle: a boolean that expresses a preference for allowing to bundle messages (true) or not (false). No guarantees are given. o DelAck: a boolean that, if false, lets an application request that the peer would not delay the acknowledgement for this message. o Fragment: a boolean that expresses a preference for allowing to fragment messages (true) or not (false), at the IP level. No guarantees are given. o (not UDP) Idempotent: a boolean that expresses whether a message is idempotent (true) or not (false). Idempotent messages may arrive multiple times at the receiver (but they will arrive at least once). When data is idempotent it can be used by the receiver immediately on a connection establishment attempt. Thus, if data is handed over before the transport system establishes a connection with a chosen transport protocol, stating that a message is idempotent facilitates transmitting it to the peer application particularly early. An application can be notified of a failure to send a specific message. There is no guarantee of such notifications, i.e. send failures can also silently occur. 6.3.2. Receiving Data A receiving application obtains an "Application-Framed Bytestream" (AFra-Bytestream); this concept is further described in Section 5.1). In line with TCP's receiver semantics, an AFra-Bytestream is just a stream of bytes to the receiver. If message boundaries were specified by the sender, a receiver-side transport system implementing only the minimum set of transport services defined here will still not inform the receiving application about them (this limitation is only needed for transport systems that are implemented to directly use TCP). Different from TCP's semantics, if the sending application has allowed that messages are not fully reliably transferred, or Welzl & Gjessing Expires March 31, 2019 [Page 21] Internet-Draft Minimal Transport Services September 2018 delivered out of order, then such re-ordering or unreliability may be reflected per message in the arriving data. Messages will always stay intact - i.e. if an incomplete message is contained at the end of the arriving data block, this message is guaranteed to continue in the next arriving data block. 7. Acknowledgements The authors would like to thank all the participants of the TAPS Working Group and the NEAT and MAMI research projects for valuable input to this document. We especially thank Michael Tuexen for help with connection connection establishment/teardown, Gorry Fairhurst for his suggestions regarding fragmentation and packet sizes, and Spencer Dawkins for his extremely detailed and constructive review. This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations Authentication, confidentiality protection, and integrity protection are identified as transport features by [RFC8095]. Often, these features are provided by a protocol or layer on top of the transport protocol; none of the full-featured standards-track transport protocols in [RFC8303], which this document is based upon, provides all of these transport features on its own. Therefore, they are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply. The minimum requirements for a secure transport system are discussed in a separate document (Section 5 on Security Features and Transport Dependencies of [I-D.ietf-taps-transport-security]). 10. References 10.1. Normative References [I-D.ietf-taps-transport-security] Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey of Transport Security Protocols", draft-ietf-taps- transport-security-02 (work in progress), June 2018. Welzl & Gjessing Expires March 31, 2019 [Page 22] Internet-Draft Minimal Transport Services September 2018 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, . [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, . 10.2. Informative References [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte Stuffing", IEEE/ACM Transactions on Networking Vol. 7, No. 2, April 1999. [I-D.ietf-taps-interface] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An Abstract Application Layer Interface to Transport Services", draft-ietf-taps-interface-01 (work in progress), July 2018. [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-18 (work in progress), August 2016. [LBE-draft] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Internet-draft draft-tsvwg-le-phb-03, February 2018. [POSIX] "IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008), January 2018, . [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, . Welzl & Gjessing Expires March 31, 2019 [Page 23] Internet-Draft Minimal Transport Services September 2018 [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, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, . [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [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, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, DOI 10.17487/RFC8260, November 2017, . [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, . Welzl & Gjessing Expires March 31, 2019 [Page 24] Internet-Draft Minimal Transport Services September 2018 [SCTP-stream-1] Weinrank, F. and M. Tuexen, "Transparent Flow Mapping for NEAT", IFIP NETWORKING Workshop on Future of Internet Transport (FIT 2017), June 2017. [SCTP-stream-2] Welzl, M., Niederbacher, F., and S. Gjessing, "Beneficial Transparent Deployment of SCTP", IEEE GlobeCom 2011, December 2011. [WWDC2015] Lakhera, P. and S. Cheshire, "Your App and Next Generation Networks", Apple Worldwide Developers Conference 2015, San Francisco, USA, June 2015, . Appendix A. The Superset of Transport Features In this description, transport features are presented following the nomenclature "CATEGORY.[SUBCATEGORY].FEATURENAME.PROTOCOL", equivalent to "pass 2" in [RFC8303]. We also sketch how functional or optimizing transport features can be implemented by a transport system. The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. Hence, for all transport features that are categorized as "functional" or "optimizing", and for which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on how to implement them over TCP and/or UDP is included. We designate some transport features as "automatable" on the basis of a broader decision that affects multiple transport features: o Most transport features that are related to multi-streaming were designated as "automatable". This was done because the decision on whether to use multi-streaming or not does not depend on application-specific knowledge. This means that a connection that is exhibited to an application could be implemented by using a single stream of an SCTP association instead of mapping it to a complete SCTP association or TCP connection. This could be achieved by using more than one stream when an SCTP association is first established (CONNECT.SCTP parameter "outbound stream count"), maintaining an internal stream number, and using this stream number when sending data (SEND.SCTP parameter "stream number"). Closing or aborting a connection could then simply free the stream number for future use. This is discussed further in Section 5.2. o With the exception of "Disable MPTCP", all transport features that are related to using multiple paths or the choice of the network Welzl & Gjessing Expires March 31, 2019 [Page 25] Internet-Draft Minimal Transport Services September 2018 interface were designated as "automatable". For example, "Listen" could always listen on all available interfaces and "Connect" could use the default interface for the destination IP address. Finally, in three cases, transport features are aggregated and/or slightly changed from [RFC8303] in the description below. These transport features are marked as "CHANGED FROM RFC8303". These do not add any new functionality but just represent a simple refactoring step that helps to streamline the derivation process (e.g., by removing a choice of a parameter for the sake of applications that may not care about this choice). The corresponding transport features are automatable, and they are listed immediately below the "CHANGED FROM RFC8303" transport feature. A.1. CONNECTION Related Transport Features ESTABLISHMENT: o Connect Protocols: TCP, SCTP, UDP(-Lite) Functional because the notion of a connection is often reflected in applications as an expectation to be able to communicate after a "Connect" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol. Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- Lite). o Specify which IP Options must always be used Protocols: TCP, UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Request multiple streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge (example implementations of using multi-streaming without involving the application are described in [SCTP-stream-1] and [SCTP-stream-2]). Implementation: see Section 5.2. o Limit the number of inbound streams Protocols: SCTP Welzl & Gjessing Expires March 31, 2019 [Page 26] Internet-Draft Minimal Transport Services September 2018 Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 5.2. o Specify number of attempts and/or timeout for the first establishment message Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery for data that is sent before or during connection establishment. Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. Implementation over UDP: Do nothing (this is irrelevant in case of UDP because there, reliable data delivery is not assumed). o Obtain multiple sockets Protocols: SCTP Automatable because the non-parallel usage of multiple paths to communicate between the same end hosts relates to knowledge about the network, not the application. o Disable MPTCP Protocols: MPTCP Optimizing because the parallel usage of multiple paths to communicate between the same end hosts can improve performance. Whether to use this feature depends on knowledge about the network as well as application-specific knowledge (see Section 3.1 of [RFC6897]). Implementation: via a boolean parameter in CONNECT.MPTCP. Implementation over TCP: Do nothing. Implementation over UDP: Do nothing. o Configure authentication Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. With TCP, this allows to configure Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows to specify which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of security that is not supported by TCP; to be compatible, this should therefore only allow to authenticate all chunk types. Key Welzl & Gjessing Expires March 31, 2019 [Page 27] Internet-Draft Minimal Transport Services September 2018 material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: Not possible (UDP does not offer this functionality). o Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. Implementation: via a parameter in CONNECT.SCTP. Implementation over TCP: not possible (TCP does not offer this functionality). Implementation over UDP: not possible (UDP does not offer this functionality). o Request to negotiate interleaving of user messages Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: controlled via a parameter in CONNECT.SCTP. One possible implementation is to always try to enable interleaving. o Hand over a message to reliably transfer (possibly multiple times) before connection establishment Protocols: TCP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via a parameter in CONNECT.TCP. Implementation over UDP: not possible (UDP does not provide reliability). o Hand over a message to reliably transfer during connection establishment Protocols: SCTP Functional because this can only work if the message is limited in size, making it closely tied to properties of the data that an application sends or expects to receive. Implementation: via a parameter in CONNECT.SCTP. Welzl & Gjessing Expires March 31, 2019 [Page 28] Internet-Draft Minimal Transport Services September 2018 Implementation over TCP: not possible (TCP does not allow identification of message boundaries because it provides a byte stream service) Implementation over UDP: not possible (UDP is unreliable). o Enable UDP encapsulation with a specified remote UDP port number Protocols: SCTP Automatable because UDP encapsulation relates to knowledge about the network, not the application. AVAILABILITY: o Listen Protocols: TCP, SCTP, UDP(-Lite) Functional because the notion of accepting connection requests is often reflected in applications as an expectation to be able to communicate after a "Listen" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol. CHANGED FROM RFC8303. This differs from the 3 automatable transport features below in that it leaves the choice of interfaces for listening open. Implementation: by listening on all interfaces via LISTEN.TCP (not providing a local IP address) or LISTEN.SCTP (providing SCTP port number / address pairs for all local IP addresses). LISTEN.UDP(- Lite) supports both methods. o Listen, 1 specified local interface Protocols: TCP, SCTP, UDP(-Lite) Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Listen, N specified local interfaces Protocols: SCTP Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. Welzl & Gjessing Expires March 31, 2019 [Page 29] Internet-Draft Minimal Transport Services September 2018 o Listen, all local interfaces Protocols: TCP, SCTP, UDP(-Lite) Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Specify which IP Options must always be used Protocols: TCP, UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Disable MPTCP Protocols: MPTCP Optimizing because the parallel usage of multiple paths to communicate between the same end hosts can improve performance. Whether to use this feature depends on knowledge about the network as well as application-specific knowledge (see Section 3.1 of [RFC6897]). Implementation: via a boolean parameter in LISTEN.MPTCP. Implementation over TCP: Do nothing. Implementation over UDP: Do nothing. o Configure authentication Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. Implementation over TCP: With TCP, this allows to configure Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows to specify which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of security that is not supported by TCP; to be compatible, this should therefore only allow to authenticate all chunk types. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: not possible (UDP does not offer authentication). o Obtain requested number of streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Welzl & Gjessing Expires March 31, 2019 [Page 30] Internet-Draft Minimal Transport Services September 2018 Implementation: see Section 5.2. o Limit the number of inbound streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 5.2. o Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. Implementation: via a parameter in LISTEN.SCTP. Implementation over TCP: not possible (TCP does not offer this functionality). Implementation over UDP: not possible (UDP does not offer this functionality). o Request to negotiate interleaving of user messages Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: via a parameter in LISTEN.SCTP. MAINTENANCE: o Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP. Implementation over UDP: not possible (UDP is unreliable and there is no connection timeout). o Suggest timeout to the peer Protocols: TCP Welzl & Gjessing Expires March 31, 2019 [Page 31] Internet-Draft Minimal Transport Services September 2018 Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE_TIMEOUT.TCP. Implementation over UDP: not possible (UDP is unreliable and there is no connection timeout). o Disable Nagle algorithm Protocols: TCP, SCTP Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them. Implementation: via DISABLE_NAGLE.TCP and DISABLE_NAGLE.SCTP. Implementation over UDP: do nothing (UDP does not implement the Nagle algorithm). o Request an immediate heartbeat, returning success/failure Protocols: SCTP Automatable because this informs about network-specific knowledge. o Notification of Excessive Retransmissions (early warning below abortion threshold) Protocols: TCP Optimizing because it is an early warning to the application, informing it of an impending functional event. Implementation: via ERROR.TCP. Implementation over UDP: do nothing (there is no abortion threshold). o Add path Protocols: MPTCP, SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port SCTP Parameters: local IP address Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application. o Remove path Protocols: MPTCP, SCTP Welzl & Gjessing Expires March 31, 2019 [Page 32] Internet-Draft Minimal Transport Services September 2018 MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port SCTP Parameters: local IP address Automatable because the choice of paths to communicate between the same end host relates to knowledge about the network, not the application. o Set primary path Protocols: SCTP Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application. o Suggest primary path to the peer Protocols: SCTP Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application. o Configure Path Switchover Protocols: SCTP Automatable because the choice of paths to communicate between the same end hosts relates to knowledge about the network, not the application. o Obtain status (query or notification) Protocols: SCTP, MPTCP SCTP parameters: association connection state; destination transport address list; destination transport address reachability states; current local and peer receiver window size; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other destination addresses; MTU per path; interleaving supported yes/no MPTCP parameters: subflow-list (identified by source-IP; source- Port; destination-IP; destination-Port) Automatable because these parameters relate to knowledge about the network, not the application. Welzl & Gjessing Expires March 31, 2019 [Page 33] Internet-Draft Minimal Transport Services September 2018 o Specify DSCP field Protocols: TCP, SCTP, UDP(-Lite) Optimizing because choosing a suitable DSCP value requires application-specific knowledge. Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(- Lite) o Notification of ICMP error message arrival Protocols: TCP, UDP(-Lite) Optimizing because these messages can inform about success or failure of functional transport features (e.g., host unreachable relates to "Connect") Implementation: via ERROR.TCP or ERROR.UDP(-Lite). o Obtain information about interleaving support Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: via STATUS.SCTP. o Change authentication parameters Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via SET_AUTH.TCP and SET_AUTH.SCTP. Implementation over TCP: With SCTP, this allows to adjust key_id, key, and hmac_id. With TCP, this allows to change the preferred outgoing MKT (current_key) and the preferred incoming MKT (rnext_key), respectively, for a segment that is sent on the connection. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: not possible (UDP does not offer authentication). o Obtain authentication information Protocols: SCTP Functional because authentication decisions may have been made by the peer, and this has an influence on the necessary application- level measures to provide a certain level of security. Implementation: via GET_AUTH.SCTP. Welzl & Gjessing Expires March 31, 2019 [Page 34] Internet-Draft Minimal Transport Services September 2018 Implementation over TCP: With SCTP, this allows to obtain key_id and a chunk list. With TCP, this allows to obtain current_key and rnext_key from a previously received segment. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: not possible (UDP does not offer authentication). o Reset Stream Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 5.2. o Notification of Stream Reset Protocols: STCP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 5.2. o Reset Association Protocols: SCTP Automatable because deciding to reset an association does not require application-specific knowledge. Implementation: via RESET_ASSOC.SCTP. o Notification of Association Reset Protocols: STCP Automatable because this notification does not relate to application-specific knowledge. o Add Streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 5.2. o Notification of Added Stream Protocols: STCP Welzl & Gjessing Expires March 31, 2019 [Page 35] Internet-Draft Minimal Transport Services September 2018 Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Section 5.2. o Choose a scheduler to operate between streams of an association Protocols: SCTP Optimizing because the scheduling decision requires application- specific knowledge. However, if a transport system would not use this, or wrongly configure it on its own, this would only affect the performance of data transfers; the outcome would still be correct within the "best effort" service model. Implementation: using SET_STREAM_SCHEDULER.SCTP. Implementation over TCP: do nothing (streams are not available in TCP, but no guarantee is given that this transport feature has any effect). Implementation over UDP: do nothing (streams are not available in UDP, but no guarantee is given that this transport feature has any effect). o Configure priority or weight for a scheduler Protocols: SCTP Optimizing because the priority or weight requires application- specific knowledge. However, if a transport system would not use this, or wrongly configure it on its own, this would only affect the performance of data transfers; the outcome would still be correct within the "best effort" service model. Implementation: using CONFIGURE_STREAM_SCHEDULER.SCTP. Implementation over TCP: do nothing (streams are not available in TCP, but no guarantee is given that this transport feature has any effect). Implementation over UDP: do nothing (streams are not available in UDP, but no guarantee is given that this transport feature has any effect). o Configure send buffer size Protocols: SCTP Automatable because this decision relates to knowledge about the network and the Operating System, not the application (see also the discussion in Section 5.4). o Configure receive buffer (and rwnd) size Welzl & Gjessing Expires March 31, 2019 [Page 36] Internet-Draft Minimal Transport Services September 2018 Protocols: SCTP Automatable because this decision relates to knowledge about the network and the Operating System, not the application. o Configure message fragmentation Protocols: SCTP Automatable because this relates to knowledge about the network and the Operating System, not the application. Note that this SCTP feature does not control IP-level fragmentation, but decides on fragmentation of messages by SCTP, in the end system. Implementation: by always enabling it with CONFIG_FRAGMENTATION.SCTP and auto-setting the fragmentation size based on network or Operating System conditions. o Configure PMTUD Protocols: SCTP Automatable because Path MTU Discovery relates to knowledge about the network, not the application. o Configure delayed SACK timer Protocols: SCTP Automatable because the receiver-side decision to delay sending SACKs relates to knowledge about the network, not the application (it can be relevant for a sending application to request not to delay the SACK of a message, but this is a different transport feature). o Set Cookie life value Protocols: SCTP Functional because it relates to security (possibly weakened by keeping a cookie very long) versus the time between connection establishment attempts. Knowledge about both issues can be application-specific. Implementation over TCP: the closest specified TCP functionality is the cookie in TCP Fast Open; for this, [RFC7413] states that the server "can expire the cookie at any time to enhance security" and section 4.1.2 describes an example implementation where updating the key on the server side causes the cookie to expire. Alternatively, for implementations that do not support TCP Fast Welzl & Gjessing Expires March 31, 2019 [Page 37] Internet-Draft Minimal Transport Services September 2018 Open, this transport feature could also affect the validity of SYN cookies (see Section 3.6 of [RFC4987]). Implementation over UDP: not possible (UDP does not offer this functionality). o Set maximum burst Protocols: SCTP Automatable because it relates to knowledge about the network, not the application. o Configure size where messages are broken up for partial delivery Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation over TCP: not possible (TCP does not offer identification of message boundaries). Implementation over UDP: not possible (UDP does not fragment messages). o Disable checksum when sending Protocols: UDP Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity with respect to random corruption. Implementation: via SET_CHECKSUM_ENABLED.UDP. Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result). o Disable checksum requirement when receiving Protocols: UDP Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity with respect to random corruption. Implementation: via SET_CHECKSUM_REQUIRED.UDP. Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result). o Specify checksum coverage used by the sender Welzl & Gjessing Expires March 31, 2019 [Page 38] Internet-Draft Minimal Transport Services September 2018 Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity with respect to random corruption. Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result). Implementation over UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum when sending". o Specify minimum checksum coverage required by receiver Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity with respect to random corruption. Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result). Implementation over UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum requirement when receiving". o Specify DF field Protocols: UDP(-Lite) Optimizing because the DF field can be used to carry out Path MTU Discovery, which can lead an application to choose message sizes that can be transmitted more efficiently. Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and SEND_FAILURE.UDP(-Lite). Implementation over TCP: do nothing (with TCP, the sending application is not in control of transport message sizes, making this functionality irrelevant). o Get max. transport-message size that may be sent using a non- fragmented IP packet from the configured interface Protocols: UDP(-Lite) Optimizing because this can lead an application to choose message sizes that can be transmitted more efficiently. Welzl & Gjessing Expires March 31, 2019 [Page 39] Internet-Draft Minimal Transport Services September 2018 Implementation over TCP: do nothing (this information is not available with TCP). o Get max. transport-message size that may be received from the configured interface Protocols: UDP(-Lite) Optimizing because this can, for example, influence an application's memory management. Implementation over TCP: do nothing (this information is not available with TCP). o Specify TTL/Hop count field Protocols: UDP(-Lite) Automatable because a transport system can use a large enough system default to avoid communication failures. Allowing an application to configure it differently can produce notifications of ICMP error message arrivals that yield information which only relates to knowledge about the network, not the application. o Obtain TTL/Hop count field Protocols: UDP(-Lite) Automatable because the TTL/Hop count field relates to knowledge about the network, not the application. o Specify ECN field Protocols: UDP(-Lite) Automatable because the ECN field relates to knowledge about the network, not the application. o Obtain ECN field Protocols: UDP(-Lite) Optimizing because this information can be used by an application to better carry out congestion control (this is relevant when choosing a data transmission transport service that does not already do congestion control). Implementation over TCP: do nothing (this information is not available with TCP). Welzl & Gjessing Expires March 31, 2019 [Page 40] Internet-Draft Minimal Transport Services September 2018 o Specify IP Options Protocols: UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Obtain IP Options Protocols: UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Enable and configure a "Low Extra Delay Background Transfer" Protocols: A protocol implementing the LEDBAT congestion control mechanism Optimizing because whether this feature is appropriate or not depends on application-specific knowledge. However, wrongly using this will only affect the speed of data transfers (albeit including other transfers that may compete with the transport system's transfer in the network), so it is still correct within the "best effort" service model. Implementation: via CONFIGURE.LEDBAT and/or SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) [LBE-draft]. Implementation over TCP: do nothing (TCP does not support LEDBAT congestion control, but not implementing this functionality will not yield a semantically wrong behavior). Implementation over UDP: do nothing (UDP does not offer congestion control). TERMINATION: o Close after reliably delivering all remaining data, causing an event informing the application on the other side Protocols: TCP, SCTP Functional because the notion of a connection is often reflected in applications as an expectation to have all outstanding data delivered and no longer be able to communicate after a "Close" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol. Implementation: via CLOSE.TCP and CLOSE.SCTP. Implementation over UDP: not possible (UDP is unreliable and hence does not know when all remaining data is delivered; it does also not offer to cause an event related to closing at the peer). Welzl & Gjessing Expires March 31, 2019 [Page 41] Internet-Draft Minimal Transport Services September 2018 o Abort without delivering remaining data, causing an event informing the application on the other side Protocols: TCP, SCTP Functional because the notion of a connection is often reflected in applications as an expectation to potentially not have all outstanding data delivered and no longer be able to communicate after an "Abort" succeeded. On both sides of a connection, an application protocol may define a communication sequence relating to this transport feature. Implementation: via ABORT.TCP and ABORT.SCTP. Implementation over UDP: not possible (UDP does not offer to cause an event related to aborting at the peer). o Abort without delivering remaining data, not causing an event informing the application on the other side Protocols: UDP(-Lite) Functional because the notion of a connection is often reflected in applications as an expectation to potentially not have all outstanding data delivered and no longer be able to communicate after an "Abort" succeeded. On both sides of a connection, an application protocol may define a communication sequence relating to this transport feature. Implementation: via ABORT.UDP(-Lite). Implementation over TCP: stop using the connection, wait for a timeout. o Timeout event when data could not be delivered for too long Protocols: TCP, SCTP Functional because this notifies that potentially assumed reliable data delivery is no longer provided. Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP. Implementation over UDP: do nothing (this event will not occur with UDP). A.2. DATA Transfer Related Transport Features A.2.1. Sending Data o Reliably transfer data, with congestion control Protocols: TCP, SCTP Welzl & Gjessing Expires March 31, 2019 [Page 42] Internet-Draft Minimal Transport Services September 2018 Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.TCP and SEND.SCTP. Implementation over UDP: not possible (UDP is unreliable). o Reliably transfer a message, with congestion control Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Implementation over TCP: via SEND.TCP. With SEND.TCP, message boundaries will not be identifiable by the receiver, because TCP provides a byte stream service. Implementation over UDP: not possible (UDP is unreliable). o Unreliably transfer a message Protocols: SCTP, UDP(-Lite) Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. CHANGED FROM RFC8303. This differs from the 2 automatable transport features below in that it leaves the choice of congestion control open. Implementation: via SEND.SCTP or SEND.UDP(-Lite). Implementation over TCP: use SEND.TCP. With SEND.TCP, messages will be sent reliably, and message boundaries will not be identifiable by the receiver. o Unreliably transfer a message, with congestion control Protocols: SCTP Automatable because congestion control relates to knowledge about the network, not the application. o Unreliably transfer a message, without congestion control Protocols: UDP(-Lite) Automatable because congestion control relates to knowledge about the network, not the application. Welzl & Gjessing Expires March 31, 2019 [Page 43] Internet-Draft Minimal Transport Services September 2018 o Configurable Message Reliability Protocols: SCTP Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. Implementation: via SEND.SCTP. Implementation over TCP: By using SEND.TCP and ignoring this configuration: based on the assumption of the best-effort service model, unnecessarily delivering data does not violate application expectations. Moreover, it is not possible to associate the requested reliability to a "message" in TCP anyway. Implementation over UDP: not possible (UDP is unreliable). o Choice of stream Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see Section 5.2. o Choice of path (destination address) Protocols: SCTP Automatable because it requires using multiple sockets, but obtaining multiple sockets in the CONNECTION.ESTABLISHMENT category is automatable. o Ordered message delivery (potentially slower than unordered) Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Implementation over TCP: By using SEND.TCP. With SEND.TCP, messages will not be identifiable by the receiver. Implementation over UDP: not possible (UDP does not offer any guarantees regarding ordering). o Unordered message delivery (potentially faster than ordered) Protocols: SCTP, UDP(-Lite) Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Welzl & Gjessing Expires March 31, 2019 [Page 44] Internet-Draft Minimal Transport Services September 2018 Implementation over TCP: By using SEND.TCP and always sending data ordered: based on the assumption of the best-effort service model, ordered delivery may just be slower and does not violate application expectations. Moreover, it is not possible to associate the requested delivery order to a "message" in TCP anyway. o Request not to bundle messages Protocols: SCTP Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them. Implementation: via SEND.SCTP. Implementation over TCP: By using SEND.TCP and DISABLE_NAGLE.TCP to disable the Nagle algorithm when the request is made and enable it again when the request is no longer made. Note that this is not fully equivalent because it relates to the time of issuing the request rather than a specific message. Implementation over UDP: do nothing (UDP never bundles messages). o Specifying a "payload protocol-id" (handed over as such by the receiver) Protocols: SCTP Functional because it allows to send extra application data with every message, for the sake of identification of data, which by itself is application-specific. Implementation: SEND.SCTP. Implementation over TCP: not possible (this functionality is not available in TCP). Implementation over UDP: not possible (this functionality is not available in UDP). o Specifying a key id to be used to authenticate a message Protocols: SCTP Functional because this has a direct influence on security. Implementation: via a parameter in SEND.SCTP. Implementation over TCP: This could be emulated by using SET_AUTH.TCP before and after the message is sent. Note that this is not fully equivalent because it relates to the time of issuing the request rather than a specific message. Implementation over UDP: not possible (UDP does not offer authentication). Welzl & Gjessing Expires March 31, 2019 [Page 45] Internet-Draft Minimal Transport Services September 2018 o Request not to delay the acknowledgement (SACK) of a message Protocols: SCTP Optimizing because only an application knows for which message it wants to quickly be informed about success / failure of its delivery. Implementation over TCP: do nothing (TCP does not offer this functionality, but ignoring this request from the application will not yield a semantically wrong behavior). Implementation over UDP: do nothing (UDP does not offer this functionality, but ignoring this request from the application will not yield a semantically wrong behavior). A.2.2. Receiving Data o Receive data (with no message delimiting) Protocols: TCP Functional because a transport system must be able to send and receive data. Implementation: via RECEIVE.TCP. Implementation over UDP: do nothing (UDP only works on messages; these can be handed over, the application can still ignore the message boundaries). o Receive a message Protocols: SCTP, UDP(-Lite) Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via RECEIVE.SCTP and RECEIVE.UDP(-Lite). Implementation over TCP: not possible (TCP does not support identification of message boundaries). o Choice of stream to receive from Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see Section 5.2. o Information about partial message arrival Protocols: SCTP Welzl & Gjessing Expires March 31, 2019 [Page 46] Internet-Draft Minimal Transport Services September 2018 Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via RECEIVE.SCTP. Implementation over TCP: do nothing (this information is not available with TCP). Implementation over UDP: do nothing (this information is not available with UDP). A.2.3. Errors This section describes sending failures that are associated with a specific call to in the "Sending Data" category (Appendix A.2.1). o Notification of send failures Protocols: SCTP, UDP(-Lite) Functional because this notifies that potentially assumed reliable data delivery is no longer provided. CHANGED FROM RFC8303. This differs from the 2 automatable transport features below in that it does not distinugish between unsent and unacknowledged messages. Implementation: via SENDFAILURE-EVENT.SCTP and SEND_FAILURE.UDP(- Lite). Implementation over TCP: do nothing (this notification is not available and will therefore not occur with TCP). o Notification of an unsent (part of a) message Protocols: SCTP, UDP(-Lite) Automatable because the distinction between unsent and unacknowledged does not relate to application-specific knowledge. o Notification of an unacknowledged (part of a) message Protocols: SCTP Automatable because the distinction between unsent and unacknowledged does not relate to application-specific knowledge. o Notification that the stack has no more user data to send Protocols: SCTP Welzl & Gjessing Expires March 31, 2019 [Page 47] Internet-Draft Minimal Transport Services September 2018 Optimizing because reacting to this notification requires the application to be involved, and ensuring that the stack does not run dry of data (for too long) can improve performance. Implementation over TCP: do nothing (see the discussion in Section 5.4). Implementation over UDP: do nothing (this notification is not available and will therefore not occur with UDP). o Notification to a receiver that a partial message delivery has been aborted Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation over TCP: do nothing (this notification is not available and will therefore not occur with TCP). Implementation over UDP: do nothing (this notification is not available and will therefore not occur with UDP). Appendix B. Revision information XXX RFC-Ed please remove this section prior to publication. -02: implementation suggestions added, discussion section added, terminology extended, DELETED category removed, various other fixes; list of Transport Features adjusted to -01 version of [RFC8303] except that MPTCP is not included. -03: updated to be consistent with -02 version of [RFC8303]. -04: updated to be consistent with -03 version of [RFC8303]. Reorganized document, rewrote intro and conclusion, and made a first stab at creating a real "minimal set". -05: updated to be consistent with -05 version of [RFC8303] (minor changes). Fixed a mistake regarding Cookie Life value. Exclusion of security related transport features (to be covered in a separate document). Reorganized the document (now begins with the minset, derivation is in the appendix). First stab at an abstract API for the minset. draft-ietf-taps-minset-00: updated to be consistent with -08 version of [RFC8303] ("obtain message delivery number" was removed, as this has also been removed in [RFC8303] because it was a mistake in Welzl & Gjessing Expires March 31, 2019 [Page 48] Internet-Draft Minimal Transport Services September 2018 RFC4960. This led to the removal of two more transport features that were only designated as functional because they affected "obtain message delivery number"). Fall-back to UDP incorporated (this was requested at IETF-99); this also affected the transport feature "Choice between unordered (potentially faster) or ordered delivery of messages" because this is a boolean which is always true for one fall-back protocol, and always false for the other one. This was therefore now divided into two features, one for ordered, one for unordered delivery. The word "reliably" was added to the transport features "Hand over a message to reliably transfer (possibly multiple times) before connection establishment" and "Hand over a message to reliably transfer during connection establishment" to make it clearer why this is not supported by UDP. Clarified that the "minset abstract interface" is not proposing a specific API for all TAPS systems to implement, but it is just a way to describe the minimum set. Author order changed. WG -01: "fall-back to" (TCP or UDP) replaced (mostly with "implementation over"). References to post-sockets removed (these were statments that assumed that post-sockets requires two-sided implementation). Replaced "flow" with "TAPS Connection" and "frame" with "message" to avoid introducing new terminology. Made sections 3 and 4 in line with the categorization that is already used in the appendix and [RFC8303], and changed style of section 4 to be even shorter and less interface-like. Updated reference draft-ietf-tsvwg- sctp-ndata to RFC8260. WG -02: rephrased "the TAPS system" and "TAPS connection" etc. to more generally talk about transport after the intro (mostly replacing "TAPS system" with "transport system" and "TAPS connection" with "connection". Merged sections 3 and 4 to form a new section 3. WG -03: updated sentence referencing [I-D.ietf-taps-transport-security] to say that "the minimum security requirements for a taps system are discussed in a separate security document", wrote "example" in the paragraph introducing the decision tree. Removed reference draft-grinnemo-taps-he-03 and the sentence that referred to it. WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As part of that, removed "TAPS" as a term everywhere (abstract, intro, ..). WG -05: addressed comments from Spencer Dawkins. WG -06: Fixed nits. WG -07: Addressed Genart comments from Robert Sparks. Welzl & Gjessing Expires March 31, 2019 [Page 49] Internet-Draft Minimal Transport Services September 2018 WG -08: Addressed one more Genart comment from Robert Sparks. WG -09: Addressed comments from Mirja Kuehlewind, Alvaro Retana, Ben Campbell, Benjamin Kaduk and Eric Rescorla. WG -10: Addressed comments from Benjamin Kaduk and Eric Rescorla. WG -11: Addressed comments from Alissa Cooper. Authors' Addresses Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Stein Gjessing University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 44 Email: steing@ifi.uio.no Welzl & Gjessing Expires March 31, 2019 [Page 50] ./draft-ietf-rtgwg-enterprise-pa-multihoming-12.txt0000644000764400076440000041256613520710334021627 0ustar iustyiusty Routing Working Group F. Baker Internet-Draft Intended status: Informational C. Bowers Expires: February 1, 2020 Juniper Networks J. Linkova Google July 31, 2019 Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions draft-ietf-rtgwg-enterprise-pa-multihoming-12 Abstract Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs. This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies. It covers the behavior of routers to forward traffic taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator. 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 https://datatracker.ietf.org/drafts/current/. Baker, et al. Expires February 1, 2020 [Page 1] Internet-Draft Enterprise PA Multihoming July 2019 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 1, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Enterprise Multihoming Use Cases . . . . . . . . . . . . . . 8 4.1. Simple ISP Connectivity with Connected SERs . . . . . . . 8 4.2. Simple ISP Connectivity Where SERs Are Not Directly Connected . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Enterprise Network Operator Expectations . . . . . . . . 12 4.4. More complex ISP connectivity . . . . . . . . . . . . . . 14 4.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 16 4.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 17 5. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 17 6. Mechanisms For Hosts To Choose Good Default Source Addresses In A Multihomed Site . . . . . . . . . . . . . . . . . . . . 24 6.1. Default Source Address Selection Algorithm on Hosts . . . 26 6.2. Selecting Default Source Address When Both Uplinks Are Working . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2.1. Distributing Default Address Selection Policy Table with DHCPv6 . . . . . . . . . . . . . . . . . . . . . 29 6.2.2. Controlling Default Source Address Selection With Router Advertisements . . . . . . . . . . . . . . . . 30 6.2.3. Controlling Default Source Address Selection With ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . 32 6.2.4. Summary of Methods For Controlling Default Source Baker, et al. Expires February 1, 2020 [Page 2] Internet-Draft Enterprise PA Multihoming July 2019 Address Selection To Implement Routing Policy . . . . 33 6.3. Selecting Default Source Address When One Uplink Has Failed . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3.1. Controlling Default Source Address Selection With DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.2. Controlling Default Source Address Selection With Router Advertisements . . . . . . . . . . . . . . . . 36 6.3.3. Controlling Default Source Address Selection With ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . 37 6.3.4. Summary Of Methods For Controlling Default Source Address Selection On The Failure Of An Uplink . . . . 38 6.4. Selecting Default Source Address Upon Failed Uplink Recovery . . . . . . . . . . . . . . . . . . . . . . . . 38 6.4.1. Controlling Default Source Address Selection With DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 38 6.4.2. Controlling Default Source Address Selection With Router Advertisements . . . . . . . . . . . . . . . . 39 6.4.3. Controlling Default Source Address Selection With ICMP . . . . . . . . . . . . . . . . . . . . . . . . 39 6.4.4. Summary Of Methods For Controlling Default Source Address Selection Upon Failed Uplink Recovery . . . . 40 6.5. Selecting Default Source Address When All Uplinks Failed 40 6.5.1. Controlling Default Source Address Selection With DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 40 6.5.2. Controlling Default Source Address Selection With Router Advertisements . . . . . . . . . . . . . . . . 40 6.5.3. Controlling Default Source Address Selection With ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . 41 6.5.4. Summary Of Methods For Controlling Default Source Address Selection When All Uplinks Failed . . . . . . 41 6.6. Summary Of Methods For Controlling Default Source Address Selection . . . . . . . . . . . . . . . . . . . . . . . . 41 6.7. Solution Limitations . . . . . . . . . . . . . . . . . . 43 6.7.1. Connections Preservation . . . . . . . . . . . . . . 43 6.8. Other Configuration Parameters . . . . . . . . . . . . . 44 6.8.1. DNS Configuration . . . . . . . . . . . . . . . . . . 44 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 45 7.1. Deploying SADR Domain . . . . . . . . . . . . . . . . . . 46 7.2. Hosts-Related Considerations . . . . . . . . . . . . . . 46 8. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 47 8.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 47 8.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 47 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 12.1. Normative References . . . . . . . . . . . . . . . . . . 49 Baker, et al. Expires February 1, 2020 [Page 3] Internet-Draft Enterprise PA Multihoming July 2019 12.2. Informative References . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction Site multihoming, the connection of a subscriber network to multiple upstream networks using redundant uplinks, is a common enterprise architecture for improving the reliability of its Internet connectivity. If the site uses provider-independent (PI) addresses, all traffic originating from the enterprise can use source addresses from the PI address space. Site multihoming with PI addresses is commonly used with both IPv4 and IPv6, and does not present any new technical challenges. It may be desirable for an enterprise site to connect to multiple ISPs using provider-assigned (PA) addresses, instead of PI addresses. Multihoming with provider-assigned addresses is typically less expensive for the enterprise relative to using provider-independent addresses as it does not require obtaining and maintaining PI address space as well as running BGP between the enterprise and the ISPs (for small/meduim networks running BGP might be not just undesirable but impossible, especially if residential-type ISP connections are used). PA multihoming is also a practice that should be facilitated and encouraged because it does not add to the size of the Internet routing table, whereas PI multihoming does. Note that PA is also used to mean "provider-aggregatable". In this document we assume that provider-assigned addresses are always provider-aggregatable. With PA multihoming, for each ISP connection, the site is assigned a prefix from within an address block allocated to that ISP by its National or Regional Internet Registry. In the simple case of two ISPs (ISP-A and ISP-B), the site will have two different prefixes assigned to it (prefix-A and prefix-B). This arrangement is problematic. First, packets with the "wrong" source address may be dropped by one of the ISPs. In order to limit denial of service attacks using spoofed source addresses, BCP38 [RFC2827] recommends that ISPs filter traffic from customer sites to only allow traffic with a source address that has been assigned by that ISP. So a packet sent from a multihomed site on the uplink to ISP-B with a source address in prefix-A may be dropped by ISP-B. However, even if ISP-B does not implement BCP38 or ISP-B adds prefix-A to its list of allowed source addresses on the uplink from the multihomed site, two-way communication may still fail. If the packet with source address in prefix-A was sent to ISP-B because the uplink to ISP-A failed, then if ISP-B does not drop the packet and the packet reaches its destination somewhere on the Internet, the return packet will be sent back with a destination address in prefix- Baker, et al. Expires February 1, 2020 [Page 4] Internet-Draft Enterprise PA Multihoming July 2019 A. The return packet will be routed over the Internet to ISP-A, but it will not be delivered to the multihomed site because the site uplink with ISP-A has failed. Two-way communication would require some arrangement for ISP-B to advertise prefix-A when the uplink to ISP-A fails. Note that the same may be true with a provider that does not implement BCP 38, if his upstream provider does, or has no corresponding route to deliver the ingress traffic to the multihomed site. The issue is not that the immediate provider implements ingress filtering; it is that someone upstream does (so egress traffic is blocked), or lacks a route (causing blackholing of the ingress traffic). Another issue with asymmetric traffic flow (when the egress traffic leaves the site via one ISP but the return traffic enters the site via another uplink) is related to stateful firewalls/middleboxes. Keeping state in that case might be problematic, even impossible. With IPv4, this problem is commonly solved by using [RFC1918] private address space within the multi-homed site and Network Address Translation (NAT) or Network Address/Port Translation (NAPT) on the uplinks to the ISPs. However, one of the goals of IPv6 is to eliminate the need for and the use of NAT or NAPT. Therefore, requiring the use of NAT or NAPT for an enterprise site to multihome with provider-assigned addresses is not an attractive solution. [RFC6296] describes a translation solution specifically tailored to meet the requirements of multi-homing with provider-assigned IPv6 addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) solution, within the site an enterprise can use Unique Local Addresses [RFC4193] or the prefix assigned by one of the ISPs. As traffic leaves the site on an uplink to an ISP, the source address gets translated to an address within the prefix assigned by the ISP on that uplink in a predictable and reversible manner. [RFC6296] is currently classified as Experimental, and it has been implemented by several vendors. See Section 8.2, for more discussion of NPTv6. This document defines routing requirements for enterprise multihoming This document focuses on the following general class of solutions. Each host at the enterprise has multiple addresses, at least one from each ISP-assigned prefix. Each host, as discussed in Section 6.1 and [RFC6724], is responsible for choosing the source address applied to each packet it sends. A host is expected to be able respond dynamically to the failure of an uplink to a given ISP by no longer sending packets with the source address corresponding to that ISP. Potential mechanisms for the communication of changes in the network Baker, et al. Expires February 1, 2020 [Page 5] Internet-Draft Enterprise PA Multihoming July 2019 to the host are Neighbor Discovery Router Advertisements ([RFC4861]), DHCPv6 ([RFC8415]), and ICMPv6 ([RFC4443]). The routers in the enterprise network are responsible for ensuring that packets are delivered to the "correct" ISP uplink based on source address. This requires that at least some routers in the site network are able to take into account the source address of a packet when deciding how to route it. That is, some routers must be capable of some form of Source Address Dependent Routing (SADR), if only as described in the section 4.3 of [RFC3704]. At a minimum, the routers connected to the ISP uplinks (the site exit routers or SERs) must be capable of Source Address Dependent Routing. Expanding the connected domain of routers capable of SADR from the site exit routers deeper into the site network will generally result in more efficient routing of traffic with external destinations. This document is organized as follows. Section 4 looks in more detail at the enterprise networking environments in which this solution is expected to operate. The discussion of Section 4 uses the concepts of source-prefix-scoped routing advertisements and forwarding tables and provides a description of how source-prefix- scoped routing advertisements are used to generate source-prefix- scoped forwarding tables. Instead, this detailed description is provided in Section 5. Section 6 discusses existing and proposed mechanisms for hosts to select the default source address to be used by applications. It also discusses the requirements for routing that are needed to support these enterprise network scenarios and the mechanisms by which hosts are expected to update default source addresses based on network state. Section 7 discusses deployment considerations, while Section 8 discusses other solutions. 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology PA (provider-assigned or provider-aggregatable) address space: a block of IP addresses assigned by an Regional Internet Registry (RIR) to a Local Internet Registry (LIR), used to create allocations to end sites. Can be aggregated and present in the routing table as one route. Baker, et al. Expires February 1, 2020 [Page 6] Internet-Draft Enterprise PA Multihoming July 2019 PI (provider-independent) address space: a block of IP addresses assigned by an Regional Internet Registry (RIR) directly to end site/ end customer. ISP: Internet Service Provider. LIR (Local Internet Registry): an organisation (usually an ISP or an enterprise/academic) which receives IP addresses allocation from its Regional Internet Regsitry, then assign parts of that allocation to its customers. RIR (Regional Internet Registry): an organization which manages the Internet number resources (such as IP addresses and AS numbers) within a geographical region of the world. SADR (Source Address Dependent Routing): Routing which takes into account the source address of a packet in addition to the packet destination address. SADR domain: a routing domain where some (or all) routers exchange source-dependent routing information. Source-Prefix-Scoped Routing/Forwarding Table: a routing (or forwarding) table which contains routing (or forwarding) information which is applicable to packets with source addresses from the specific prefix only. Unscoped Routing/Forwarding Table: a routing (or forwarding) table which can be used to route/forward packets with any source addresses. SER (Site Edge Router): a router which connects the site to an ISP (terminates an ISP uplink).. LLA (Link-Local Address): IPv6 Unicast Address from fe80::/10 prefix ([RFC4291]). ULA (Unique Local IPv6 Unicast Address): IPv6 unicast addresses from FC00::/7 prefix. They are globally unique and intended for local communications ([RFC4193]). GUA (Global Unicast Address): globally routable IPv6 addresses of the global scope ([RFC4291]). SLAAC (IPv6 Stateless Address Autoconfiguration): a stateless process of configuring network stack on IPv6 hosts ([RFC4862]). Baker, et al. Expires February 1, 2020 [Page 7] Internet-Draft Enterprise PA Multihoming July 2019 RA (Router Advertisement): a message sent by an IPv6 router to advertise its presence to hosts together with various network-related parameters required for hosts to perform SLAAC ([RFC4861]). PIO (Prefix Information Option): a part of RA message containing information about IPv6 prefixes which could be used by hosts to generate global IPv6 addresses ([RFC4862]). RIO (Route Information Option): a part of RA message containing information about more specific IPv6 prefixes reachable via the advertising router ([RFC4191]). 4. Enterprise Multihoming Use Cases 4.1. Simple ISP Connectivity with Connected SERs We start by looking at a scenario in which a site has connections to two ISPs, as shown in Figure 1. The site is assigned the prefix 2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP- B. We consider three hosts in the site. H31 and H32 are on a LAN that has been assigned subnets 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64. H31 has been assigned the addresses 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different subnet that has been assigned 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. Baker, et al. Expires February 1, 2020 [Page 8] Internet-Draft Enterprise PA Multihoming July 2019 2001:db8:0:1234::101 H101 | | 2001:db8:0:a010::31 -------- 2001:db8:0:b010::31 ,-----. / \ +--+ +--+ +----+ ,' `. : : +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : H31--+ +--+ +--+ | +----+ `. ,' : : | | `-----' : Internet : | | : : | | : : | | : : | | ,-----. : : H32--+ +--+ | +----+ ,' `. : : +---|R2|----------+---|SERb|-+ ISP-B +--+-- : +--+ | +----+ `. ,' : : | `-----' : : | : : +--+ +--+ +--+ \ / H41------|R3|--|R5|--|R6| -------- +--+ +--+ +--+ 2001:db8:0:a020::41 2001:db8:0:b020::41 Figure 1: Simple ISP Connectivity With Connected SERs We refer to a router that connects the site to an ISP as a site edge router (SER). Several other routers provide connectivity among the internal hosts (H31, H32, and H41), as well as connecting the internal hosts to the Internet through SERa and SERb. In this example SERa and SERb share a direct connection to each other. In Section 4.2, we consider a scenario where this is not the case. For the moment, we assume that the hosts are able to make good choices about which source addresses through some mechanism that doesn't involve the routers in the site network. Here, we focus on primary task of the routed site network, which is to get packets efficiently to their destinations, while sending a packet to the ISP that assigned the prefix that matches the source address of the packet. In Section 6, we examine what role the routed network may play in helping hosts make good choices about source addresses for packets. With this solution, routers will need some form of Source Address Dependent Routing, which will be new functionality. It would be useful if an enterprise site does not need to upgrade all routers to Baker, et al. Expires February 1, 2020 [Page 9] Internet-Draft Enterprise PA Multihoming July 2019 support the new SADR functionality in order to support PA multi- homing. We consider if this is possible and what are the tradeoffs of not having all routers in the site support SADR functionality. In the topology in Figure 1, it is possible to support PA multihoming with only SERa and SERb being capable of SADR. The other routers can continue to forward based only on destination address, and exchange routes that only consider destination address. In this scenario, SERa and SERb communicate source-scoped routing information across their shared connection. When SERa receives a packet with a source address matching prefix 2001:db8:0:b000::/52 , it forwards the packet to SERb, which forwards it on the uplink to ISP-B. The analogous behaviour holds for traffic that SERb receives with a source address matching prefix 2001:db8:0:a000::/52. In Figure 1, when only SERa and SERb are capable of source address dependent routing, PA multi-homing will work. However, the paths over which the packets are sent will generally not be the shortest paths. The forwarding paths will generally be more efficient as more routers are capable of SADR. For example, if R4, R2, and R6 are upgraded to support SADR, then can exchange source-scoped routes with SERa and SERb. They will then know to send traffic with a source address matching prefix 2001:db8:0:b000::/52 directly to SERb, without sending it to SERa first. 4.2. Simple ISP Connectivity Where SERs Are Not Directly Connected In Figure 2, we modify the topology slightly by inserting R7, so that SERa and SERb are no longer directly connected. With this topology, it is not enough to just enable SADR routing on SERa and SERb to support PA multi-homing. There are two solutions to enable PA multihoming in this topology. Baker, et al. Expires February 1, 2020 [Page 10] Internet-Draft Enterprise PA Multihoming July 2019 2001:db8:0:1234::101 H101 | | 2001:db8:0:a010::31 -------- 2001:db8:0:b010::31 ,-----. / \ +--+ +--+ +----+ ,' `. : : +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : H31--+ +--+ +--+ | +----+ `. ,' : : | | `-----' : Internet : | +--+ : : | |R7| : : | +--+ : : | | ,-----. : : H32--+ +--+ | +----+ ,' `. : : +---|R2|----------+---|SERb|-+ ISP-B +--+-- : +--+ | +----+ `. ,' : : | `-----' : : | : : +--+ +--+ +--+ \ / H41------|R3|--|R5|--|R6| -------- +--+ +--+ +--+ | | 2001:db8:0:a020::41 2001:db8:0:5678::501 H501 2001:db8:0:b020::41 Figure 2: Simple ISP Connectivity Where SERs Are Not Directly Connected One option is to effectively modify the topology by creating a logical tunnel between SERa and SERb, using GRE ([RFC7676]) for example. Although SERa and SERb are not directly connected physically in this topology, they can be directly connected logically by a tunnel. The other option is to enable SADR functionality on R7. In this way, R7 will exchange source-scoped routes with SERa and SERb, making the three routers act as a single SADR domain. This illustrates the basic principle that the minimum requirement for the routed site network to support PA multi-homing is having all of the site exit routers be part of a connected SADR domain. Extending the connected SADR domain beyond that point can produce more efficient forwarding paths. Baker, et al. Expires February 1, 2020 [Page 11] Internet-Draft Enterprise PA Multihoming July 2019 4.3. Enterprise Network Operator Expectations Before considering a more complex scenario, let's look in more detail at the reasonably simple multihoming scenario in Figure 2 to understand what can reasonably be expected from this solution. As a general guiding principle, we assume an enterprise network operator will expect a multihomed network to behave as close as to a single- homed network as possible. So a solution that meets those expectations where possible is a good thing. For traffic between internal hosts and traffic from outside the site to internal hosts, an enterprise network operator would expect there be no visible change in the path taken by this traffic, since this traffic does not need to be routed in a way that depends on source address. It is also reasonable to expect that internal hosts should be able to communicate with each other using either of their source addresses without restriction. For example, H31 should be able to communicate with H41 using a packet with S=2001:db8:0:a010::31, D=2001:db8:0:b020::41, regardless of the state of uplink to ISP-B. These goals can be accomplished by having all of the routers in the network continue to originate normal unscoped destination routes for their connected networks. If we can arrange so that these unscoped destination routes get used for forwarding this traffic, then we will have accomplished the goal of keeping forwarding of traffic destined for internal hosts, unaffected by the multihoming solution. For traffic destined for external hosts, it is reasonable to expect that traffic with a source address from the prefix assigned by ISP-A to follow the path to that the traffic would follow if there is no connection to ISP-B. This can be accomplished by having SERa originate a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0) . If all of the routers in the site support SADR, then the path of traffic exiting via ISP-A can match that expectation. If some routers don't support SADR, then it is reasonable to expect that the path for traffic exiting via ISP-A may be different within the site. This is a tradeoff that the enterprise network operator may decide to make. It is important to understand how this multihoming solution behaves when an uplink to one of the ISPs fails. To simplify this discussion, we assume that all routers in the site support SADR. We first start by looking at how the network operates when the uplinks to both ISP-A and ISP-B are functioning properly. SERa originates a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0), and SERb is originates a source-scoped route of the form (S=2001:db8:0:b000::/52, D=::/0). These routes are distributed through the routers in the site, and they establish within the Baker, et al. Expires February 1, 2020 [Page 12] Internet-Draft Enterprise PA Multihoming July 2019 routers two set of forwarding paths for traffic leaving the site. One set of forwarding paths is for packets with source address in 2001:db8:0:a000::/52. The other set of forwarding paths is for packets with source address in 2001:db8:0:b000::/52. The normal destination routes which are not scoped to these two source prefixes play no role in the forwarding. Whether a packet exits the site via SERa or via SERb is completely determined by the source address applied to the packet by the host. So for example, when host H31 sends a packet to host H101 with (S=2001:db8:0:a010::31, D=2001:db8:0:1234::101), the packet will only be sent out the link from SERa to ISP-A. Now consider what happens when the uplink from SERa to ISP-A fails. The only way for the packets from H31 to reach H101 is for H31 to start using the source address for ISP-B. H31 needs to send the following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101). This behavior is very different from the behavior that occurs with site multihoming using PI addresses or with PA addresses using NAT. In these other multi-homing solutions, hosts do not need to react to network failures several hops away in order to regain Internet access. Instead, a host can be largely unaware of the failure of an uplink to an ISP. When multihoming with PA addresses and NAT, existing sessions generally need to be re-established after a failure since the external host will receive packets from the internal host with a new source address. However, new sessions can be established without any action on the part of the hosts. Multihoming with PA addresses and NAT has created the expectation of a fairly quick and simple recovery from network failures. Alternatives should to be evaluated in terms of the speed and complexity of the recovery mechanism. Another example where the behavior of this multihoming solution differs significantly from that of multihoming with PI address or with PA addresses using NAT is in the ability of the enterprise network operator to route traffic over different ISPs based on destination address. We still consider the fairly simple network of Figure 2 and assume that uplinks to both ISPs are functioning. Assume that the site is multihomed using PA addresses and NAT, and that SERa and SERb each originate a normal destination route for D=::/0, with the route origination dependent on the state of the uplink to the respective ISP. Now suppose it is observed that an important application running between internal hosts and external host H101 experience much better performance when the traffic passes through ISP-A (perhaps because ISP-A provides lower latency to H101.) When multihoming this site with PI addresses or with PA addresses and NAT, the enterprise Baker, et al. Expires February 1, 2020 [Page 13] Internet-Draft Enterprise PA Multihoming July 2019 network operator can configure SERa to originate into the site network a normal destination route for D=2001:db8:0:1234::/64 (the destination prefix to reach H101) that depends on the state of the uplink to ISP-A. When the link to ISP-A is functioning, the destination route D=2001:db8:0:1234::/64 will be originated by SERa, so traffic from all hosts will use ISP-A to reach H101 based on the longest destination prefix match in the route lookup. Implementing the same routing policy is more difficult with the PA multihoming solution described in this document since it doesn't use NAT. By design, the only way to control where a packet exits this network is by setting the source address of the packet. Since the network cannot modify the source address without NAT, the host must set it. To implement this routing policy, each host needs to use the source address from the prefix assigned by ISP-A to send traffic destined for H101. Mechanisms have been proposed to allow hosts to choose the source address for packets in a fine grained manner. We will discuss these proposals in Section 6. However, interacting with host operating systems in some manner to ensure a particular source address is chosen for a particular destination prefix is not what an enterprise network administrator would expect to have to do to implement this routing policy. 4.4. More complex ISP connectivity The previous sections considered two variations of a simple multihoming scenario where the site is connected to two ISPs offering only Internet connectivity. It is likely that many actual enterprise multihoming scenarios will be similar to this simple example. However, there are more complex multihoming scenarios that we would like this solution to address as well. It is fairly common for an ISP to offer a service in addition to Internet access over the same uplink. Two variations of this are reflected in Figure 3. In addition to Internet access, ISP-A offers a service which requires the site to access host H51 at 2001:db8:0:5555::51. The site has a single physical and logical connection with ISP-A, and ISP-A only allows access to H51 over that connection. So when H32 needs to access the service at H51 it needs to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) and those packets need to be forward out the link from SERa to ISP-A. Baker, et al. Expires February 1, 2020 [Page 14] Internet-Draft Enterprise PA Multihoming July 2019 2001:db8:0:1234::101 H101 | | 2001:db8:0:a010::31 -------- 2001:db8:0:b010::31 ,-----. / \ +--+ +--+ +----+ ,' `. : : +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : H31--+ +--+ +--+ | +----+ `. ,' : : | | `-----' : Internet : | | | : : | | H51 : : | | 2001:db8:0:5555::51 : : | +--+ : : | |R7| : : | +--+ : : | | : : | | ,-----. : : H32--+ +--+ | +-----+ ,' `. : : +---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- : +--+ | +-----+ `. ,' : : +--+ `--|--' : : 2001:db8:0:a010::32 |R8| | \ / +--+ ,--|--. -------- | +-----+ ,' `. | +-------|SERb2|-+ ISP-B | | | +-----+ `. ,' H501 | `-----' 2001:db8:0:5678 | | ::501 +--+ +--+ H61 H41------|R3|--|R5| 2001:db8:0:6666::61 +--+ +--+ 2001:db8:0:a020::41 2001:db8:0:b020::41 Figure 3: Internet access and services offered by ISP-A and ISP-B ISP-B illustrates a variation on this scenario. In addition to Internet access, ISP-B also offers a service which requires the site to access host H61. The site has two connections to two different parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects Internet traffic to use the uplink from SERb1, while it expects traffic destined for the service at H61 to use the uplink from SERb2. For either uplink, ISP-B expects the ingress traffic to have a source address matching the prefix it assigned to the site, 2001:db8:0:b000::/52. Baker, et al. Expires February 1, 2020 [Page 15] Internet-Draft Enterprise PA Multihoming July 2019 As discussed before, we rely completely on the internal host to set the source address of the packet properly. In the case of a packet sent by H31 to access the service in ISP-B at H61, we expect the packet to have the following addresses: (S=2001:db8:0:b010::31, D=2001:db8:0:6666::61). The routed network has two potential ways of distributing routes so that this packet exits the site on the uplink at SERb2. We could just rely on normal destination routes, without using source-prefix scoped routes. If we have SERb2 originate a normal unscoped destination route for D=2001:db8:0:6666::/64, the packets from H31 to H61 will exit the site at SERb2 as desired. We should not have to worry about SERa needing to originate the same route, because ISP-B should choose a globally unique prefix for the service at H61. The alternative is to have SERb2 originate a source-prefix-scoped destination route of the form (S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64). From a forwarding point of view, the use of the source-prefix-scoped destination route would result in traffic with source addresses corresponding only to ISP-B being sent to SERb2. Instead, the use of the unscoped destination route would result in traffic with source addresses corresponding to ISP-A and ISP-B being sent to SERb2, as long as the destination address matches the destination prefix. It seems like either forwarding behavior would be acceptable. However, from the point of view of the enterprise network administrator trying to configure, maintain, and trouble-shoot this multihoming solution, it seems much clearer to have SERb2 originate the source-prefix-scoped destination route correspond to the service offered by ISP-B. In this way, all of the traffic leaving the site is determined by the source-prefix-scoped routes, and all of the traffic within the site or arriving from external hosts is determined by the unscoped destination routes. Therefore, for this multihoming solution we choose to originate source-prefix-scoped routes for all traffic leaving the site. 4.5. ISPs and Provider-Assigned Prefixes While we expect that most site multihoming involves connecting to only two ISPs, this solution allows for connections to an arbitrary number of ISPs to be supported. However, when evaluating scalable implementations of the solution, it would be reasonable to assume that the maximum number of ISPs that a site would connect to is five (topologies with two redundant routers each having two uplinks to different ISPs plus a tunnel to a headoffice acting as fifth one are not unheard of). Baker, et al. Expires February 1, 2020 [Page 16] Internet-Draft Enterprise PA Multihoming July 2019 It is also useful to note that the prefixes assigned to the site by different ISPs will not overlap. This must be the case, since the provider-assigned addresses have to be globally unique. 4.6. Simplified Topologies The topologies of many enterprise sites using this multihoming solution may in practice be simpler than the examples that we have used. The topology in Figure 1 could be further simplified by having all hosts directly connected to the LAN connecting the two site exit routers, SERa and SERb. The topology could also be simplified by having the uplinks to ISP-A and ISP-B both connected to the same site exit router. However, it is the aim of this document to provide a solution that applies to a broad a range of enterprise site network topologies, so this document focuses on providing a solution to the more general case. The simplified cases will also be supported by this solution, and there may even be optimizations that can be made for simplified cases. This solution however needs to support more complex topologies. We are starting with the basic assumption that enterprise site networks can be quite complex from a routing perspective. However, even a complex site network can be multihomed to different ISPs with PA addresses using IPv4 and NAT. It is not reasonable to expect an enterprise network operator to change the routing topology of the site in order to deploy IPv6. 5. Generating Source-Prefix-Scoped Forwarding Tables So far we have described in general terms how the routers in this solution that are capable of Source Address Dependent Routing will forward traffic using both normal unscoped destination routes and source-prefix-scoped destination routes. Here we give a precise method for generating a source-prefix-scoped forwarding table on a router that supports SADR. 1. Compute the next-hops for the source-prefix-scoped destination prefixes using only routers in the connected SADR domain. These are the initial source-prefix-scoped forwarding table entries. 2. Compute the next-hops for the unscoped destination prefixes using all routers in the IGP. This is the unscoped forwarding table. 3. For a given source-prefix-scoped forwarding table T (scoped to source prefix P), consider a source-prefix-scoped forwarding table T', whose source prefix P' contains P. We call T the more specific source-prefix-scoped forwarding table, and T' the less specific source-prefix-scoped forwarding table. We select Baker, et al. Expires February 1, 2020 [Page 17] Internet-Draft Enterprise PA Multihoming July 2019 entries in the less specific source-prefix-scoped forwarding table to augment the more specific source-prefix-scoped forwarding table based on the following rules. If a destination prefix of an entry in the less specific source-prefix-scoped forwarding table exactly matches the destination prefix of an existing entry in the more specific source-prefix-scoped forwarding table (including destination prefix length), then do not add the entry to the more specific source-prefix-scoped forwarding table. If the destination prefix does NOT match an existing entry, then add the entry to the more specific source- prefix-scoped forwarding table. As the unscoped forwarding table is considered to be scoped to ::/0, this process will propagate routes from the unscoped forwarding table to the more specific source-prefix-scoped forwarding table. If there exist multiple source-prefix-scoped forwarding tables whose source prefixes contain P, these source-prefix-scoped forwarding tables should be processed in order from most specific to least specific. The forwarding tables produced by this process are used in the following way to forward packets. 1. Select the most specific (longest prefix match) source-prefix- scoped forwarding table that matches the source address of the packet (again, the unscoped forwarding table is considered to be scoped to ::/0). 2. Look up the destination address of the packet in the selected forwarding table to determine the next-hop for the packet. The following example illustrates how this process is used to create a forwarding table for each provider-assigned source prefix. We consider the multihomed site network in Figure 3. Initially we assume that all of the routers in the site network support SADR. Figure 4 shows the routes that are originated by the routers in the site network. Baker, et al. Expires February 1, 2020 [Page 18] Internet-Draft Enterprise PA Multihoming July 2019 Routes originated by SERa: (S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64) (S=2001:db8:0:a000::/52, D=::/0) (D=2001:db8:0:5555::/64) (D=::/0) Routes originated by SERb1: (S=2001:db8:0:b000::/52, D=::/0) (D=::/0) Routes originated by SERb2: (S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64) (D=2001:db8:0:6666::/64) Routes originated by R1: (D=2001:db8:0:a010::/64) (D=2001:db8:0:b010::/64) Routes originated by R2: (D=2001:db8:0:a010::/64) (D=2001:db8:0:b010::/64) Routes originated by R3: (D=2001:db8:0:a020::/64) (D=2001:db8:0:b020::/64) Figure 4: Routes Originated by Routers in the Site Network Each SER originates destination routes which are scoped to the source prefix assigned by the ISP that the SER connects to. Note that the SERs also originate the corresponding unscoped destination route. This is not needed when all of the routers in the site support SADR. However, it is required when some routers do not support SADR. This will be discussed in more detail later. We focus on how R8 constructs its source-prefix-scoped forwarding tables from these route advertisements. R8 computes the next hops for destination routes which are scoped to the source prefix 2001:db8:0:a000::/52. The results are shown in the first table in Figure 5. (In this example, the next hops are computed assuming that all links have the same metric.) Then, R8 computes the next hops for destination routes which are scoped to the source prefix 2001:db8:0:b000::/52. The results are shown in the second table in Figure 5 . Finally, R8 computes the next hops for the unscoped destination prefixes. The results are shown in the third table in Figure 5. Baker, et al. Expires February 1, 2020 [Page 19] Internet-Draft Enterprise PA Multihoming July 2019 forwarding entries scoped to source prefix = 2001:db8:0:a000::/52 ============================================ D=2001:db8:0:5555/64 NH=R7 D=::/0 NH=R7 forwarding entries scoped to source prefix = 2001:db8:0:b000::/52 ============================================ D=2001:db8:0:6666/64 NH=SERb2 D=::/0 NH=SERb1 unscoped forwarding entries ============================================ D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:6666::/64 NH=SERb2 D=::/0 NH=SERb1 Figure 5: Forwarding Entries Computed at R8 The final step is for R8 to augment the more specific source-prefix- scoped forwarding tables with entries from less specific source- prefix-scoped forwarding tables. The unscoped forwarding table is considered as being scoped to ::/0, so both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 are more specific prefixes of ::/0. Therefore, entries in the unscoped forwarding table will be evaluated to be added to these two more specific source-prefix-scoped forwarding tables. If a forwarding entry from the less specific source-prefix- scoped forwarding table has the exact same destination prefix (including destination prefix length) as the forwarding entry from the more specific source-prefix-scoped forwarding table, then the existing forwarding entry in the more specific source-prefix-scoped forwarding table wins. As an example of how the source scoped forwarding entries are augmented, we consider how the two entries in the first table in Figure 5 (the table for source prefix = 2001:db8:0:a000::/52) are augmented with entries from the third table in Figure 5 (the table of unscoped or scoped to ::/0 forwarding entries). The first four unscoped forwarding entries (D=2001:db8:0:a010::/64, D=2001:db8:0:b010::/64, D=2001:db8:0:a020::/64, and D=2001:db8:0:b020::/64) are not an exact match for any of the existing entries in the forwarding table for source prefix 2001:db8:0:a000::/52. Therefore, these four entries are added to the Baker, et al. Expires February 1, 2020 [Page 20] Internet-Draft Enterprise PA Multihoming July 2019 final forwarding table for source prefix 2001:db8:0:a000::/52. The result of adding these entries is reflected in the first four entries the first table in Figure 6. The next less specific scoped (scope is ::/0) forwarding table entry is for D=2001:db8:0:5555::/64. This entry is an exact match for the existing entry in the forwarding table for the more specific source prefix 2001:db8:0:a000::/52. Therefore, we do not replace the existing entry with the entry from the unscoped forwarding table. This is reflected in the fifth entry in the first table in Figure 6. (Note that since both scoped and unscoped entries have R7 as the next hop, the result of applying this rule is not visible.) The next less specific prefix scoped (scope is ::/0) forwarding table entry is for D=2001:db8:0:6666::/64. This entry is not an exact match for any existing entries in the forwarding table for source prefix 2001:db8:0:a000::/52. Therefore, we add this entry. This is reflected in the sixth entry in the first table in Figure 6. The next less specific prefix scoped (scope is ::/0) forwarding table entry is for D=::/0. This entry is an exact match for the existing entry in the forwarding table for more specific source prefix 2001:db8:0:a000::/52. Therefore, we do not overwrite the existing source-prefix-scoped entry, as can be seen in the last entry in the first table in Figure 6. Baker, et al. Expires February 1, 2020 [Page 21] Internet-Draft Enterprise PA Multihoming July 2019 if source address matches 2001:db8:0:a000::/52 then use this forwarding table ============================================ D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:6666::/64 NH=SERb2 D=::/0 NH=R7 else if source address matches 2001:db8:0:b000::/52 then use this forwarding table ============================================ D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:6666::/64 NH=SERb2 D=::/0 NH=SERb1 else if source address matches ::/0 use this forwarding table ============================================ D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:6666::/64 NH=SERb2 D=::/0 NH=SERb1 Figure 6: Complete Forwarding Tables Computed at R8 The forwarding tables produced by this process at R8 have the desired properties. A packet with a source address in 2001:db8:0:a000::/52 will be forwarded based on the first table in Figure 6. If the packet is destined for the Internet at large or the service at D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa. If the packet is destined for an internal host, then the first four entries will send it to R2 or R5 as expected. Note that if this packet has a destination address corresponding to the service offered by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to SERb2. It will be dropped by SERb2 or by ISP-B, since the packet has a source address that was not assigned by ISP-B. However, this is expected behavior. In order to use the service offered by ISP-B, the host needs to originate the packet with a source address assigned by ISP-B. Baker, et al. Expires February 1, 2020 [Page 22] Internet-Draft Enterprise PA Multihoming July 2019 In this example, a packet with a source address that doesn't match 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated from an external host. Such a packet will use the unscoped forwarding table (the last table in Figure 6). These packets will flow exactly as they would in absence of multihoming. We can also modify this example to illustrate how it supports deployments where not all routers in the site support SADR. Continuing with the topology shown in Figure 3, suppose that R3 and R5 do not support SADR. Instead they are only capable of understanding unscoped route advertisements. The SADR routers in the network will still originate the routes shown in Figure 4. However, R3 and R5 will only understand the unscoped routes as shown in Figure 7. Routes originated by SERa: (D=2001:db8:0:5555::/64) (D=::/0) Routes originated by SERb1: (D=::/0) Routes originated by SERb2: (D=2001:db8:0:6666::/64) Routes originated by R1: (D=2001:db8:0:a010::/64) (D=2001:db8:0:b010::/64) Routes originated by R2: (D=2001:db8:0:a010::/64) (D=2001:db8:0:b010::/64) Routes originated by R3: (D=2001:db8:0:a020::/64) (D=2001:db8:0:b020::/64) Figure 7: Routes Advertisements Understood by Routers that do no Support SADR With these unscoped route advertisements, R5 will produce the forwarding table shown in Figure 8. Baker, et al. Expires February 1, 2020 [Page 23] Internet-Draft Enterprise PA Multihoming July 2019 forwarding table ============================================ D=2001:db8:0:a010::/64 NH=R8 D=2001:db8:0:b010::/64 NH=R8 D=2001:db8:0:a020::/64 NH=R3 D=2001:db8:0:b020::/64 NH=R3 D=2001:db8:0:5555::/64 NH=R8 D=2001:db8:0:6666::/64 NH=SERb2 D=::/0 NH=R8 Figure 8: Forwarding Table For R5, Which Doesn't Understand Source- Prefix-Scoped Routes As all SERs belong to the SADR domain any traffic that needs to exit the site will eventually hit a SADR-capable router. To prevent routing loops involving SADR-capable and non-SADR-capable routers, traffic that enters the SADR-capable domain does not leave the domain until it exits the site. Therefore all SADR-capable routers within the domain MUST be logically connected. Note that the mechanism described here for converting source-prefix- scoped destination prefix routing advertisements into forwarding state is somewhat different from that proposed in [I-D.ietf-rtgwg-dst-src-routing]. The method described in the current document is functionally equivalent, but it is based on application of existing mechanisms for the described scenarios. 6. Mechanisms For Hosts To Choose Good Default Source Addresses In A Multihomed Site Until this point, we have made the assumption that hosts are able to choose the correct source address using some unspecified mechanism. This has allowed us to just focus on what the routers in a multihomed site network need to do in order to forward packets to the correct ISP based on source address. Now we look at possible mechanisms for hosts to choose the correct source address. We also look at what role, if any, the routers may play in providing information that helps hosts to choose source addresses. It should be noted that this section discussed how hosts could select the default source address for new connections. Any connection which already exists on a host is bound to the specific source address which can not be changed. Section 6.7 discusses the connections preservation issue in more details. Any host that needs to be able to send traffic using the uplinks to a given ISP is expected to be configured with an address from the prefix assigned by that ISP. The host will control which ISP is used Baker, et al. Expires February 1, 2020 [Page 24] Internet-Draft Enterprise PA Multihoming July 2019 for its traffic by selecting one of the addresses configured on the host as the source address for outgoing traffic. It is the responsibility of the site network to ensure that a packet with the source address from an ISP is now sent on an uplink to that ISP. If all of the ISP uplinks are working, the choice of source address by the host may be driven by the desire to load share across ISP uplinks, or it may be driven by the desire to take advantage of certain properties of a particular uplink or ISP (if some information about various path properties has been made availabe to the host somehow - see [I-D.ietf-intarea-provisioning-domains] as an example). If any of the ISP uplinks is not working, then the choice of source address by the host can cause packets to get dropped. How a host should make good decisions about source address selection in a multihomed site is not a solved problem. We do not attempt to solve this problem in this document. Instead we discuss the current state of affairs with respect to standardized solutions and implementation of those solutions. We also look at proposed solutions for this problem. An external host initiating communication with a host internal to a PA multihomed site will need to know multiple addresses for that host in order to communicate with it using different ISPs to the multihomed site (knowing just one address would undermine all benefits of redundant connectivity provided by multihoming). These addresses are typically learned through DNS. (For simplicity, we assume that the external host is single-homed.) The external host chooses the ISP that will be used at the remote multihomed site by setting the destination address on the packets it transmits. For a session originated from an external host to an internal host, the choice of source address used by the internal host is simple. The internal host has no choice but to use the destination address in the received packet as the source address of the transmitted packet. For a session originated by a host inside the multi-homed site, the decision of what source address to select is more complicated. We consider three main methods for hosts to get information about the network. The two proactive methods are Neighbor Discovery Router Advertisements and DHCPv6. The one reactive method we consider is ICMPv6. Note that we are explicitly excluding the possibility of having hosts participate in or even listen directly to routing protocol advertisements. First we look at how a host is currently expected to select the default source and destination addresses to be used for a new connection. Baker, et al. Expires February 1, 2020 [Page 25] Internet-Draft Enterprise PA Multihoming July 2019 6.1. Default Source Address Selection Algorithm on Hosts [RFC6724] defines the algorithms that hosts are expected to use to select source and destination addresses for packets. It defines an algorithm for selecting a source address and a separate algorithm for selecting a destination address. Both of these algorithms depend on a policy table. [RFC6724] defines a default policy which produces certain behavior. The rules in the two algorithms in [RFC6724] depend on many different properties of addresses. While these are needed for understanding how a host should choose addresses in an arbitrary environment, most of the rules are not relevant for understanding how a host should choose among multiple source addresses in multihomed environment when sending a packet to a remote host. Returning to the example in Figure 3, we look at what the default algorithms in [RFC6724] say about the source address that internal host H31 should use to send traffic to external host H101, somewhere on the Internet. There is no choice to be made with respect to destination address. H31 needs to send a packet with D=2001:db8:0:1234::101 in order to reach H101. So H31 have to choose between using S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 as the source address for this packet. We go through the rules for source address selection in Section 5 of [RFC6724]. Rule 1 (Prefer same address) is not useful to break the tie between source addresses, because neither the candidate source addresses equals the destination address. Rule 2 (Prefer appropriate scope) is also not used in this scenario, because both source addresses and the destination address have global scope. Rule 3 (Avoid deprecated addresses) applies to an address that has been autoconfigured by a host using stateless address autoconfiguration as defined in [RFC4862]. An address autoconfigured by a host has a preferred lifetime and a valid lifetime. The address is preferred until the preferred lifetime expires, after which it becomes deprecated. A deprecated address is not used if there is a preferred address of the appropriate scope available. When the valid lifetime expires, the address cannot be used at all. The preferred and valid lifetimes for an autoconfigured address are set based on the corresponding lifetimes in the Prefix Information Option in Neighbor Discovery Router Advertisements. So a possible tool to control source address selection in this scenario would be for a host to make an address deprecated by having routers on that link, R1 and R2 in Figure 3, send a Router Advertisement message containing a Baker, et al. Expires February 1, 2020 [Page 26] Internet-Draft Enterprise PA Multihoming July 2019 Prefix Information Option for the source prefix to be discouraged (or prohibited) with the preferred lifetime set to zero. This is a rather blunt tool, because it discourages or prohibits the use of that source prefix for all destinations. However, it may be useful in some scenarios. For example, if all uplinks to a particular ISP fail, it is desirable to prevent hosts from using source addresses from that ISP address space. Rule 4 (Avoid home addresses) does not apply here because we are not considering Mobile IP. Rule 5 (Prefer outgoing interface) is not useful in this scenario, because both source addresses are assigned to the same interface. Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is not useful in the scenario when both R1 and R2 will advertise both source prefixes. However potentially this rule may allow a host to select the correct source prefix by selecting a next-hop. The most obvious way would be to make R1 to advertise itself as a default router and send PIO for 2001:db8:0:a010::/64, while R2 is advertising itself as a default router and sending PIO for 2001:db8:0:b010::/64. We'll discuss later how Rule 5.5 can be used to influence a source address selection in single-router topologies (e.g. when H41 is sending traffic using R3 as a default gateway). Rule 6 (Prefer matching label) refers to the Label value determined for each source and destination prefix as a result of applying the policy table to the prefix. With the default policy table defined in Section 2.1 of [RFC6724], Label(2001:db8:0:a010::31) = 5, Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) = 5. So with the default policy, Rule 6 does not break the tie. However, the algorithms in [RFC6724] are defined in such a way that non- default address selection policy tables can be used. [RFC7078] defines a way to distribute a non-default address selection policy table to hosts using DHCPv6. So even though the application of rule 6 to this scenario using the default policy table is not useful, rule 6 may still be a useful tool. Rule 7 (Prefer temporary addresses) has to do with the technique described in [RFC4941] to periodically randomize the interface portion of an IPv6 address that has been generated using stateless address autoconfiguration. In general, if H31 were using this technique, it would use it for both source addresses, for example creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and 2001:db8:0:b010:4838:f483:8384:3208, in addition to 2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would prefer the two temporary addresses, but it would not break the tie between the two source prefixes from ISP-A and ISP-B. Baker, et al. Expires February 1, 2020 [Page 27] Internet-Draft Enterprise PA Multihoming July 2019 Rule 8 (Use longest matching prefix) dictates that between two candidate source addresses the one which has longest common prefix length with the destination address. For example, if H31 were selecting the source address for sending packets to H101, this rule would not be a tie breaker as for both candidate source addresses 2001:db8:0:a101::31 and 2001:db8:0:b101::31 the common prefix length with the destination is 48. However if H31 were selecting the source address for sending packets H41 address 2001:db8:0:a020::41, then this rule would result in using 2001:db8:0:a101::31 as a source (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix 2001:db8:0:a000::/58, while for 2001:db8:0:b101::31 and 2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51). Therefore rule 8 might be useful for selecting the correct source address in some but not all scenarios (for example if ISP-B services belong to 2001:db8:0:b000::/59 then H31 would always use 2001:db8:0:b010::31 to access those destinations). So we can see that of the 8 source selection address rules from [RFC6724], four actually apply to our basic site multihoming scenario. The rules that are relevant to this scenario are summarized below. o Rule 3: Avoid deprecated addresses. o Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. o Rule 6: Prefer matching label. o Rule 8: Prefer longest matching prefix. The two methods that we discuss for controlling the source address selection through the four relevant rules above are SLAAC Router Advertisement messages and DHCPv6. We also consider a possible role for ICMPv6 for getting traffic- driven feedback from the network. With the source address selection algorithm discussed above, the goal is to choose the correct source address on the first try, before any traffic is sent. However, another strategy is to choose a source address, send the packet, get feedback from the network about whether or not the source address is correct, and try another source address if it is not. We consider four scenarios where a host needs to select the correct source address. The first is when both uplinks are working. The second is when one uplink has failed. The third one is a situation when one failed uplink has recovered. The last one is failure of both (all) uplinks. Baker, et al. Expires February 1, 2020 [Page 28] Internet-Draft Enterprise PA Multihoming July 2019 It should be noted that [RFC6724] only defines the behavior of IPv6 hosts to select default addresses that applications and upper-layer protocols can use. Applications and upper-layer protocols can make their own choices on selecting source addresses. The mechanism proposed in this document attempts to ensure that the subset of source addresses available for applications and upper-layer protocols is selected with the up-to-date network state in mind. The rest of the document discusses various aspects of the default source address selection defined in [RFC6724], calling it for the sake of brevity "the source address selection". 6.2. Selecting Default Source Address When Both Uplinks Are Working Again we return to the topology in Figure 3. Suppose that the site administrator wants to implement a policy by which all hosts need to use ISP-A to reach H101 at D=2001:db8:0:1234::101. So for example, H31 needs to select S=2001:db8:0:a010::31. 6.2.1. Distributing Default Address Selection Policy Table with DHCPv6 This policy can be implemented by using DHCPv6 to distribute an address selection policy table that assigns the same label to destination address that match 2001:db8:0:1234::/64 as it does to source addresses that match 2001:db8:0:a000::/52. The following two entries accomplish this. Prefix Precedence Label 2001:db8:0:1234::/64 50 33 2001:db8:0:a000::/52 50 33 Figure 9: Policy table entries to implement a routing policy This requires that the hosts implement [RFC6724], the basic source and destination address framework, along with [RFC7078], the DHCPv6 extension for distributing a non-default policy table. Note that it does NOT require that the hosts use DHCPv6 for address assignment. The hosts could still use stateless address autoconfiguration for address configuration, while using DHCPv6 only for policy table distribution (see [RFC8415]). However this method has a number of disadvantages: o DHCPv6 support is not a mandatory requirement for IPv6 hosts ([RFC6434]), so this method might not work for all devices. o Network administrators are required to explicitly configure the desired network access policies on DHCPv6 servers. While it might be feasible in the scenario of a single multihomed network, such approach might have some scalability issues, especially if the Baker, et al. Expires February 1, 2020 [Page 29] Internet-Draft Enterprise PA Multihoming July 2019 centralized DHCPv6 solution is deployed to serve a large number of multiomed sites. 6.2.2. Controlling Default Source Address Selection With Router Advertisements Neighbor Discovery currently has two mechanisms to communicate prefix information to hosts. The base specification for Neighbor Discovery (see [RFC4861]) defines the Prefix Information Option (PIO) in the Router Advertisement (RA) message. When a host receives a PIO with the A-flag set, it can use the prefix in the PIO as source prefix from which it assigns itself an IP address using stateless address autoconfiguration (SLAAC) procedures described in [RFC4862]. In the example of Figure 3, if the site network is using SLAAC, we would expect both R1 and R2 to send RA messages with PIOs for both source prefixes 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64 with the A-flag set. H31 would then use the SLAAC procedure to configure itself with the 2001:db8:0:a010::31 and 2001:db8:0:b010::31. Whereas a host learns about source prefixes from PIO messages, hosts can learn about a destination prefix from a Router Advertisement containing Route Information Option (RIO), as specified in [RFC4191]. The destination prefixes in RIOs are intended to allow a host to choose the router that it uses as its first hop to reach a particular destination prefix. As currently standardized, neither PIO nor RIO options contained in Neighbor Discovery Router Advertisements can communicate the information needed to implement the desired routing policy. PIO's communicate source prefixes, and RIO communicate destination prefixes. However, there is currently no standardized way to directly associate a particular destination prefix with a particular source prefix. [I-D.pfister-6man-sadr-ra] proposes a Source Address Dependent Route Information option for Neighbor Discovery Router Advertisements which would associate a source prefix and with a destination prefix. The details of [I-D.pfister-6man-sadr-ra] might need tweaking to address this use case. However, in order to be able to use Neighbor Discovery Router Advertisements to implement this routing policy, an extension that allows R1 and R2 to explicitly communicate to H31 an association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64 would be needed. However, Rule 5.5 of the default source address selection algorithm (discussed in Section 6.1 above), together with default router preference (specified in [RFC4191]) and RIO can be used to influence a source address selection on a host as described below. Let's look Baker, et al. Expires February 1, 2020 [Page 30] Internet-Draft Enterprise PA Multihoming July 2019 at source address selection on the host H41. It receives RAs from R3 with PIOs for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that point all traffic would use the same next-hop (R3 link-local address) so Rule 5.5 does not apply. Now let's assume that R3 supports SADR and has two scoped forwarding tables, one scoped to S=2001:db8:0:a000::/52 and another scoped to S=2001:db8:0:b000::/52. If R3 generates two different link-local addresses for its interface facing H41 (one for each scoped forwarding table, LLA_A and LLA_B) and starts sending two different RAs: one is sent from LLA_A and includes PIO for 2001:db8:0:a020::/64, another is sent from LLA_B and includes PIO for 2001:db8:0:b020::/64. Now it is possible to influence H41 source address selection for destinations which follow the default route by setting default router preference in RAs. If it is desired that H41 reaches H101 (or any destinations in the Internet) via ISP-A, then RAs sent from LLA_A should have default router preference set to 01 (high priority), while RAs sent from LLA_B should have preference set to 11 (low). Then LLA_A would be chosen as a next-hop for H101 and therefore (as per rule 5.5) 2001:db8:0:a020::41 would be selected as the source address. If, at the same time, it is desired that H61 is accessible via ISP-B then R3 should include a RIO for 2001:db8:0:6666::/64 to its RA sent from LLA_B. H41 would chose LLA_B as a next-hop for all traffic to H61 and then as per Rule 5.5, 2001:db8:0:b020::41 would be selected as a source address. If in the above mentioned scenario it is desirable that all Internet traffic leaves the network via ISP-A and the link to ISP-B is used for accessing ISP-B services only (not as ISP-A link backup), then RAs sent by R3 from LLA_B should have Router Lifetime set to 0 and should include RIOs for ISP-B address space. It would instruct H41 to use LLA_A for all Internet traffic but use LLA_B as a next-hop while sending traffic to ISP-B addresses. The description of the mechanism above assumes SADR support by the first-hop routers as well as SERs. However, a first-hop router can still provide a less flexible version of this mechanism even without implementing SADR. This could be done by providing configuration knobs on the first-hop router that allow it to generate different link-local addresses and to send individual RAs for each prefix. The mechanism described above relies on Rule 5.5 of the default source address selection algorithm defined in [RFC6724]. [RFC8028] states that "A host SHOULD select default routers for each prefix it is assigned an address in". It also recommends that hosts should implement Rule 5.5. of [RFC6724]. Hosts following the recommendations specified in [RFC8028] therefore should be able to benefit from the solution described in this document. No standards need to be updated in regards to host behavior. Baker, et al. Expires February 1, 2020 [Page 31] Internet-Draft Enterprise PA Multihoming July 2019 6.2.3. Controlling Default Source Address Selection With ICMPv6 We now discuss how one might use ICMPv6 to implement the routing policy to send traffic destined for H101 out the uplink to ISP-A, even when uplinks to both ISPs are working. If H31 started sending traffic to H101 with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the uplink to ISP-B. SERb1 could recognize that this traffic is not following the desired routing policy and react by sending an ICMPv6 message back to H31. In this example, we could arrange things so that SERb1 drops the packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and then sends to H31 an ICMPv6 Destination Unreachable message with Code 5 (Source address failed ingress/egress policy). When H31 receives this packet, it would then be expected to try another source address to reach the destination. In this example, H31 would then send a packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which will reach SERa and be forwarded out the uplink to ISP-A. However, we would also want it to be the case that SERb1 does not enforce this routing policy when the uplink from SERa to ISP-A has failed. This could be accomplished by having SERa originate a source-prefix-scoped route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) and have SERb1 monitor the presence of that route. If that route is not present (because SERa has stopped originating it), then SERb1 will not enforce the routing policy, and it will forward packets with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101 out its uplink to ISP-B. We can also use this source-prefix-scoped route originated by SERa to communicate the desired routing policy to SERb1. We can define an EXCLUSIVE flag to be advertised together with the IGP route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This would allow SERa to communicate to SERb that SERb should reject traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination Unreachable Code 5 message, as long as the route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. The definition of an EXCLUSIVE flag for SADR advertisements in IGPs would require future standardization work. Finally, if we are willing to extend ICMPv6 to support this solution, then we could create a mechanism for SERb1 to tell the host what source address it should be using to successfully forward packets that meet the policy. In its current form, when SERb1 sends an ICMPv6 Destination Unreachable Code 5 message, it is basically saying, "This source address is wrong. Try another source address." In the absence of a clear indication which address to try next, the Baker, et al. Expires February 1, 2020 [Page 32] Internet-Draft Enterprise PA Multihoming July 2019 host will iterate over all addresses assigned to the interface (e.g. various privacy addresses) which would lead to significant delays and degraded user experience. It would be better is if the ICMPv6 message could say, "This source address is wrong. Instead use a source address in S=2001:db8:0:a000::/52.". However using ICMPv6 for signaling source address information back to hosts introduces new challenges. Most routers currently have software or hardware limits on generating ICMP messages. A site administrator deploying a solution that relies on the SERs generating ICMP messages could try to improve the performance of SERs for generating ICMP messages. However, in a large network, it is still likely that ICMP message generation limits will be reached. As a result hosts would not receive ICMPv6 back which in turn leads to traffic blackholing and poor user experience. To improve the scalability of ICMPv6-based signaling hosts SHOULD cache the preferred source address (or prefix) for the given destination (which in turn might cause issues in case of the corresponding ISP uplinks failure - see Section 6.3). In addition, the same source prefix SHOULD be used for other destinations in the same /64 as the original destination address. The source prefix to the destination mapping SHOULD have a specific lifetime. Expiration of the lifetime SHOULD trigger the source address selection algorithm again. Using ICMPv6 Destination Unreachable Messages with Code 5 to influence source address selection introduces some security challenges which are discussed in Section 10. As currently standardized in [RFC4443], the ICMPv6 Destination Unreachable Message with Code 5 would allow for the iterative approach to retransmitting packets using different source addresses. As currently defined, the ICMPv6 message does not provide a mechanism to communication information about which source prefix should be used for a retransmitted packet. The current document does not define such a mechanism but it might be a useful extension to define in a different document. However this approach has some security implications such as an ability for an attacker to send spoofed ICMPv6 messages to signal invalid/unreachable source prefix causing DoS-type attack. 6.2.4. Summary of Methods For Controlling Default Source Address Selection To Implement Routing Policy So to summarize this section, we have looked at three methods for implementing a simple routing policy where all traffic for a given destination on the Internet needs to use a particular ISP, even when the uplinks to both ISPs are working. Baker, et al. Expires February 1, 2020 [Page 33] Internet-Draft Enterprise PA Multihoming July 2019 The default source address selection policy cannot distinguish between the source addresses needed to enforce this policy, so a non- default policy table using associating source and destination prefixes using Label values would need to be installed on each host. A mechanism exists for DHCPv6 to distribute a non-default policy table but such solution would heavily rely on DHCPv6 support by host operating system. Moreover there is no mechanism to translate desired routing/traffic engineering policies into policy tables on DHCPv6 servers. Therefore using DHCPv6 for controlling address selection policy table is not recommended and SHOULD NOT be used. At the same time Router Advertisements provide a reliable mechanism to influence source address selection process via PIO, RIO and default router preferences. As all those options have been standardized by IETF and are supported by various operating systems no changes are required on hosts. First-hop routers in the enterprise network need to be able of sending different RAs for different SLAAC prefixes (either based on scoped forwarding tables or based on pre-configured policies). SERs can enforce the routing policy by sending ICMPv6 Destination Unreachable messages with Code 5 (Source address failed ingress/ egress policy) for traffic that is being sent with the wrong source address. The policy distribution could be automated by defining an EXCLUSIVE flag for the source-prefix-scoped route which can be set on the SER that originates the route. As ICMPv6 message generation can be rate-limited on routers, it SHOULD NOT be used as the only mechanism to influence source address selection on hosts. While hosts SHOULD select the correct source address for a given destination the network SHOULD signal any source address issues back to hosts using ICMPv6 error messages. 6.3. Selecting Default Source Address When One Uplink Has Failed Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements, and ICMPv6 can help a host choose the right source address when an uplink to one of the ISPs has failed. Again we look at the scenario in Figure 3. This time we look at traffic from H31 destined for external host H501 at D=2001:db8:0:5678::501. We initially assume that the uplink from SERa to ISP-A is working and that the uplink from SERb1 to ISP-B is working. We assume there is no particular routing policy desired, so H31 is free to send packets with S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 and have them delivered to H501. For this example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that the packets exit via SERb to ISP-B. Now we see what happens when the link from SERb1 to ISP-B fails. How should H31 learn that it needs Baker, et al. Expires February 1, 2020 [Page 34] Internet-Draft Enterprise PA Multihoming July 2019 to start sending the packet to H501 with S=2001:db8:0:a010::31 in order to start using the uplink to ISP-A? We need to do this in a way that doesn't prevent H31 from still sending packets with S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61. 6.3.1. Controlling Default Source Address Selection With DHCPv6 For this example we assume that the site network in Figure 3 has a centralized DHCP server and all routers act as DHCP relay agents. We assume that both of the addresses assigned to H31 were assigned via DHCP. We could try to have the DHCP server monitor the state of the uplink from SERb1 to ISP-B in some manner and then tell H31 that it can no longer use S=2001:db8:0:b010::31 by settings its valid lifetime to zero. The DHCP server could initiate this process by sending a Reconfigure Message to H31 as described in Section 18.3 of [RFC8415]. Or the DHCP server can assign addresses with short lifetimes in order to force clients to renew them often. This approach would prevent H31 from using S=2001:db8:0:b010::31 to reach a host on the Internet. However, it would also prevent H31 from using S=2001:db8:0:b010::31 to reach H61 at D=2001:db8:0:6666::61, which is not desirable. Another potential approach is to have the DHCP server monitor the uplink from SERb1 to ISP-B and control the choice of source address on H31 by updating its address selection policy table via the mechanism in [RFC7078]. The DHCP server could initiate this process by sending a Reconfigure Message to H31. Note that [RFC8415] requires that Reconfigure Message use DHCP authentication. DHCP authentication could be avoided by using short address lifetimes to force clients to send Renew messages to the server often. If the host is not obtaining its IP addresses from the DHCP server, then it would need to use the Information Refresh Time option defined in [RFC8415]. If the following policy table can be installed on H31 after the failure of the uplink from SERb1, then the desired routing behavior should be achieved based on source and destination prefix being matched with label values. Baker, et al. Expires February 1, 2020 [Page 35] Internet-Draft Enterprise PA Multihoming July 2019 Prefix Precedence Label ::/0 50 44 2001:db8:0:a000::/52 50 44 2001:db8:0:6666::/64 50 55 2001:db8:0:b000::/52 50 55 Figure 10: Policy Table Needed On Failure Of Uplink From SERb1 The described solution has a number of significant drawbacks, some of them already discussed in Section 6.2.1. o DHCPv6 support is not required for an IPv6 host and there are operating systems which do not support DHCPv6. Besides that, it does not appear that [RFC7078] has been widely implemented on host operating systems. o [RFC7078] does not clearly specify this kind of a dynamic use case where address selection policy needs to be updated quickly in response to the failure of a link. In a large network it would present scalability issues as many hosts need to be reconfigured in very short period of time. o Updating DHCPv6 server configuration each time an ISP uplink changes its state introduces some scalability issues, especially for mid/large distributed scale enterprise networks. In addition to that, the policy table needs to be manually configured by administrators which makes that solution prone to human error. o No mechanism exists for making DHCPv6 servers aware of network topology/routing changes in the network. In general DHCPv6 servers monitoring network-related events sounds like a bad idea as completely new functionality beyond the scope of DHCPv6 role is required. 6.3.2. Controlling Default Source Address Selection With Router Advertisements The same mechanism as discussed in Section 6.2.2 can be used to control the source address selection in the case of an uplink failure. If a particular prefix should not be used as a source for any destinations, then the router needs to send RA with Preferred Lifetime field for that prefix set to 0. Let's consider a scenario when all uplinks are operational and H41 receives two different RAs from R3: one from LLA_A with PIO for 2001:db8:0:a020::/64, default router preference set to 11 (low) and another one from LLA_B with PIO for 2001:db8:0:a020::/64, default Baker, et al. Expires February 1, 2020 [Page 36] Internet-Draft Enterprise PA Multihoming July 2019 router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64. As a result H41 is using 2001:db8:0:b020::41 as a source address for all Internet traffic and those packets are sent by SERs to ISP-B. If SERb1 uplink to ISP-B failed, the desired behavior is that H41 stops using 2001:db8:0:b020::41 as a source address for all destinations but H61. To achieve that R3 should react to SERb1 uplink failure (which could be detected as the scoped route (S=2001:db8:0:b000::/52, D=::/0) disappearance) by withdrawing itself as a default router. R3 sends a new RA from LLA_B with Router Lifetime value set to 0 (which means that it should not be used as default router). That RA still contains PIO for 2001:db8:0:b020::/64 (for SLAAC purposes) and RIO for 2001:db8:0:6666::/64 so H41 can reach H61 using LLA_B as a next- hop and 2001:db8:0:b020::41 as a source address. For all traffic following the default route, LLA_A will be used as a next-hop and 2001:db8:0:a020::41 as a source address. If all uplinks to ISP-B have failed and therefore source addresses from ISP-B address space should not be used at all, the forwarding table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can be instructed to stop using source addresses from that block by sending RAs containing PIO with Preferred Lifetime set to 0. 6.3.3. Controlling Default Source Address Selection With ICMPv6 Now we look at how ICMPv6 messages can provide information back to H31. We assume again that at the time of the failure H31 is sending packets to H501 using (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails, SERb1 would stop originating its source-prefix-scoped route for the default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its unscoped default destination route. With these routes no longer in the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501) would end up at SERa based on the unscoped default destination route being originated by SERa. Since that traffic has the wrong source address to be forwarded to ISP-A, SERa would drop it and send a Destination Unreachable message with Code 5 (Source address failed ingress/egress policy) back to H31. H31 would then know to use another source address for that destination and would try with (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be forwarded to SERa based on the source-prefix-scoped default destination route still being originated by SERa, and SERa would forward it to ISP-A. As discussed above, if we are willing to extend ICMPv6, SERa can even tell H31 what source address it should use to reach that destination. The expected host behaviour has been discussed in Section 6.2.3. Using ICMPv6 would have the same scalability/rate limiting issues discussed in Section 6.2.3. ISP-B uplink failure immediately makes source addresses from 2001:db8:0:b000::/52 unsuitable for external communication and might Baker, et al. Expires February 1, 2020 [Page 37] Internet-Draft Enterprise PA Multihoming July 2019 trigger a large number of ICMPv6 packets being sent to hosts in that subnet. 6.3.4. Summary Of Methods For Controlling Default Source Address Selection On The Failure Of An Uplink It appears that DHCPv6 is not particularly well suited to quickly changing the source address used by a host in the event of the failure of an uplink, which eliminates DHCPv6 from the list of potential solutions. On the other hand Router Advertisements provides a reliable mechanism to dynamically provide hosts with a list of valid prefixes to use as source addresses as well as prevent particular prefixes to be used. While no additional new features are required to be implemented on hosts, routers need to be able to send RAs based on the state of scoped forwarding tables entries and to react to network topology changes by sending RAs with particular parameters set. The use of ICMPv6 Destination Unreachable messages generated by the SER (or any SADR-capable) routers seem like they have the potential to provide a support mechanism together with RAs to signal source address selection errors back to hosts, however scalability issues may arise in large networks in case of sudden topology change. Therefore it is highly desirable that hosts are able to select the correct source address in case of uplinks failure with ICMPv6 being an additional mechanism to signal unexpected failures back to hosts. The current behavior of different host operating system when receiving ICMPv6 Destination Unreachable message with code 5 (Source address failed ingress/egress policy) is not clear to the authors. Information from implementers, users, and testing would be quite helpful in evaluating this approach. 6.4. Selecting Default Source Address Upon Failed Uplink Recovery The next logical step is to look at the scenario when a failed uplink on SERb1 to ISP-B is coming back up, so hosts can start using source addresses belonging to 2001:db8:0:b000::/52 again. 6.4.1. Controlling Default Source Address Selection With DHCPv6 The mechanism to use DHCPv6 to instruct the hosts (H31 in our example) to start using prefixes from ISP-B space (e.g. S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is quite similar to one discussed in Section 6.3.1 and shares the same drawbacks. Baker, et al. Expires February 1, 2020 [Page 38] Internet-Draft Enterprise PA Multihoming July 2019 6.4.2. Controlling Default Source Address Selection With Router Advertisements Let's look at the scenario discussed in Section 6.3.2. If the uplink(s) failure caused the complete withdrawal of prefixes from 2001:db8:0:b000::/52 address space by setting Preferred Lifetime value to 0, then the recovery of the link should just trigger new RA being sent with non-zero Preferred Lifetime. In another scenario discussed in Section 6.3.2, the SERb1 uplink to ISP-B failure leads to disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from the forwarding table scoped to S=2001:db8:0:b000::/52 and, in turn, caused R3 to send RAs from LLA_B with Router Lifetime set to 0. The recovery of the SERb1 uplink to ISP-B leads to (S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re- appearance and instructs R3 that it should advertise itself as a default router for ISP-B address space domain (send RAs from LLA_B with non-zero Router Lifetime). 6.4.3. Controlling Default Source Address Selection With ICMP It looks like ICMPv6 provides a rather limited functionality to signal back to hosts that particular source addresses have become valid again. Unless the changes in the uplink state a particular (S,D) pair, hosts can keep using the same source address even after an ISP uplink has come back up. For example, after the uplink from SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as described in Section 6.3.3) and allegedly started using (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now when the SERb1 uplink comes back up, the packets with that (S,D) pair are still routed to SERa1 and sent to the Internet. Therefore H31 is not informed that it should stop using 2001:db8:0:a010::31 and start using 2001:db8:0:b010::31 again. Unless SERa has a policy configured to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and send ICMPv6 back if SERb1 uplink to ISP-B is up, H31 will be unaware of the network topology change and keep using S=2001:db8:0:a010::31 for Internet destinations, including H51. One of the possible option may be using a scoped route with EXCLUSIVE flag as described in Section 6.2.3. SERa1 uplink recovery would cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to reappear in the routing table. In the absence of that route packets to H101 which were sent to ISP-B (as ISP-A uplink was down) with source addresses from 2001:db8:0:b000::/52. When the route re- appears SERb1 would reject those packets and sends ICMPv6 back as discussed in Section 6.2.3. Practically it might lead to scalability issues which have been already discussed in Section 6.2.3 and Section 6.4.3. Baker, et al. Expires February 1, 2020 [Page 39] Internet-Draft Enterprise PA Multihoming July 2019 6.4.4. Summary Of Methods For Controlling Default Source Address Selection Upon Failed Uplink Recovery Once again DHCPv6 does not look like reasonable choice to manipulate source address selection process on a host in the case of network topology changes. Using Router Advertisement provides the flexible mechanism to dynamically react to network topology changes (if routers are able to use routing changes as a trigger for sending out RAs with specific parameters). ICMPv6 could be considered as a supporting mechanism to signal incorrect source address back to hosts but should not be considered as the only mechanism to control the address selection in multihomed environments. 6.5. Selecting Default Source Address When All Uplinks Failed One particular tricky case is a scenario when all uplinks have failed. In that case there is no valid source address to be used for any external destinations while it might be desirable to have intra- site connectivity. 6.5.1. Controlling Default Source Address Selection With DHCPv6 From DHCPv6 perspective uplinks failure should be treated as two independent failures and processed as described in Section 6.3.1. At this stage it is quite obvious that it would result in quite complicated policy table which needs to be explicitly configured by administrators and therefore seems to be impractical. 6.5.2. Controlling Default Source Address Selection With Router Advertisements As discussed in Section 6.3.2 an uplink failure causes the scoped default entry to disappear from the scoped forwarding table and triggers RAs with zero Router Lifetime. Complete disappearance of all scoped entries for a given source prefix would cause the prefix being withdrawn from hosts by setting Preferred Lifetime value to zero in PIO. If all uplinks (SERa, SERb1 and SERb2) failed, hosts either lost their default routers and/or have no global IPv6 addresses to use as a source. (Note that 'uplink failure' might mean 'IPv6 connectivity failure with IPv4 still being reachable', in which case hosts might fall back to IPv4 if there is IPv4 connectivity to destinations). As a result, intra-site connectivity is broken. One of the possible way to solve it is to use ULAs. All hosts have ULA addresses assigned in addition to GUAs and used for intra-site communication even if there is no GUA assigned to a host. To avoid accidental leaking of packets with ULA sources SADR- capable routers SHOULD have a scoped forwarding table for ULA source Baker, et al. Expires February 1, 2020 [Page 40] Internet-Draft Enterprise PA Multihoming July 2019 for internal routes but MUST NOT have an entry for D=::/0 in that table. In the absence of (S=ULA_Prefix; D=::/0) first-hop routers will send dedicated RAs from a unique link-local source LLA_ULA with PIO from ULA address space, RIO for the ULA prefix and Router Lifetime set to zero. The behaviour is consistent with the situation when SERb1 lost the uplink to ISP-B (so there is no Internet connectivity from 2001:db8:0:b000::/52 sources) but those sources can be used to reach some specific destinations. In the case of ULA there is no Internet connectivity from ULA sources but they can be used to reach another ULA destinations. Note that ULA usage could be particularly useful if all ISPs assign prefixes via DHCP-PD. In the absence of ULAs, upon the all uplinks failure hosts would lost all their GUAs upon prefix lifetime expiration which again makes intra- site communication impossible. It should be noted that the Rule 5.5 (prefer a prefix advertised by the selected next-hop) takes precedence over the Rule 6 (prefer matching label, which ensures that GUA source addresses are preferred over ULAs for GUA destinations). Therefore if ULAs are used, the network administrator needs to ensure that while the site has an Internet connectivity, hosts do not select a router which advertises ULA prefixes as their default router. 6.5.3. Controlling Default Source Address Selection With ICMPv6 In case of all uplinks failure all SERs will drop outgoing IPv6 traffic and respond with ICMPv6 error message. In the large network when many hosts are trying to reach Internet destinations it means that SERs need to generate an ICMPv6 error to every packet they receive from hosts which presents the same scalability issues discussed in Section 6.3.3 6.5.4. Summary Of Methods For Controlling Default Source Address Selection When All Uplinks Failed Again, combining SADR with Router Advertisements seems to be the most flexible and scalable way to control the source address selection on hosts. 6.6. Summary Of Methods For Controlling Default Source Address Selection To summarize the scenarios and options discussed above: While DHCPv6 allows administrators to manipulate source address selection policy tables, this method has a number of significant disadvantages which eliminates DHCPv6 from a list of potential solutions: Baker, et al. Expires February 1, 2020 [Page 41] Internet-Draft Enterprise PA Multihoming July 2019 1. It required hosts to support DHCPv6 and its extension (RFC7078); 2. DHCPv6 server needs to monitor network state and detect routing changes. 3. The use of policy tables requires manual configuration and might be extremely complicated, especially in the case of distributed network when large number of remote sites are being served by centralized DHCPv6 servers. 4. Network topology/routing policy changes could trigger simultaneous re-configuration of large number of hosts which present serious scalability issues. The use of Router Advertisements to influence the source address selection on hosts seem to be the most reliable, flexible and scalable solution. It has the following benefits: 1. no new (non-standard) functionality needs to be implemented on hosts (except for [RFC4191] RIO support, which remains at the time of this writing not widely implemented); 2. no changes in RA format; 3. routers can react to routing table changes by sending RAs which would minimize the failover time in the case of network topology changes; 4. information required for source address selection is broadcast to all affected hosts in case of topology change event which improves the scalability of the solution (comparing to DHCPv6 reconfiguration or ICMPv6 error messages). To fully benefit from the RA-based solution, first-hop routers need to implement SADR, belong to the SADR domain and be able to send dedicated RAs per scoped forwarding table as discussed above, reacting to network changes with sending new RAs. It should be noted that the proposed solution would work even if first-hop routers are not SADR-capable but still able to send individual RAs for each ISP prefix and react to topology changes as discussed above (e.g. via configuration knobs). The RA-based solution relies heavily on hosts correctly implementing default address selection algorithm as defined in [RFC6724]. While the basic (and most common) multihoming scenario (two or more Internet uplinks, no 'walled gardens') would work for any host supporting the minimal implementation of [RFC6724], more complex use cases (such as "walled garden" and other scenarios when some ISP Baker, et al. Expires February 1, 2020 [Page 42] Internet-Draft Enterprise PA Multihoming July 2019 resources can only be reached from that ISP address space) require that hosts support Rule 5.5 of the default address selection algorithm. There is some evidence that not all host OSes have that rule implemented currently. However it should be noted that [RFC8028] states that Rule 5.5 should be implemented. ICMPv6 Code 5 error message SHOULD be used to complement RA-based solution to signal incorrect source address selection back to hosts, but it SHOULD NOT be considered as the stand-alone solution. To prevent scenarios when hosts in multihomed envinronments incorrectly identify onlink/offlink destinations, hosts SHOULD treat ICMPv6 Redirects as discussed in [RFC8028]. 6.7. Solution Limitations 6.7.1. Connections Preservation The proposed solution is not designed to preserve connection state in case of an uplink failure. When all uplinks to an ISP go down all transport connections established to/from that ISP address space will be interrupted (unless the transport protocol has specific multihoming support). That behaviour is similar to the scenario of IPv4 multihoming with NAT when an uplink failure causes all connections to be NATed to completely different public IPv4 addresses. While it does sound suboptimal, it is determined by the nature of PA address space: if all uplinks to the particular ISP have failed, there is no path for the ingress traffic to reach the site and the egress traffic is supposed to be dropped by the BCP38 [RFC2827] ingress filters. The only potential way to overcome this limitation would be running BGP with all ISPs and advertise all site prefixes to all uplinks - a solution which shares all drawbacks of using PI address space without having its benefits. Networks willing and capable of running BGP and using PI are out of scope of this document. It should be noted that in case of IPv4 NAT-based multihoming uplink recovery could cause connection interruptions as well (unless packet forwarding is integrated with existing NAT sessions tracking so the egress interface for the existing sessions is not changed). However the proposed solution has a benefit of preserving the existing sessions during/after the failed uplink restoration. Unlike the uplink failure event which causes all addresses from the affected prefix to be deprecated the recovery would just add new preferred addresses to a host without making any addresses unavailable. Therefore connections estavlished to/from those addresses do not have to be interrupted. Baker, et al. Expires February 1, 2020 [Page 43] Internet-Draft Enterprise PA Multihoming July 2019 While it's desirable for active connections to survive ISP failover events, for sites using PA address space such events affect the reachability of IP addresses assigned to hosts. Unless the transport (or even higher level protocols) are capable of suviving the host renumbering, the active connections will be broken. The proposed solution focuses on minimizing the impact of failover for new connections and for multipath-aware protocols. Another way to preserve connection state would be using multipath transport as discussed in Section 8.3. 6.8. Other Configuration Parameters 6.8.1. DNS Configuration In mutihomed envinronment each ISP might provide their own list of DNS servers. For example, in the topology shown in Figure 3, ISP-A might provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B might provide H61 2001:db8:0:6666::61 as a recursive DNS server. [RFC8106] defines 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. Using RDNSS together with 'scoped' RAs as described above would allow a first-hop router (R3 in the Figure 3) to send DNS server addresses and search lists provided by each ISP (or the corporate DNS servers addresses if the enterprise is running its own DNS servers - as discussed below DNS split-horizon problem is to hard to solve without running a local DNS server). As discussed in Section 6.5.2, failure of all ISP uplinks would cause deprecation of all addresses assigned to a host from the address space of all ISPs. If any intra-site IPv6 connectivity is still desirable (most likely to be the case for any mid/large scare network), then ULAs should be used as discussed in Section 6.5.2. In such a scenario, the enterprise network should run its own recursive DNS server(s) and provide its ULA addresses to hosts via RDNSS in RAs send for ULA-scoped forwarding table as described in Section 6.5.2. There are some scenarios when the final outcome of the name resolution might be different depending on: o which DNS server is used; o which source address the client uses to send a DNS query to the server (DNS split horizon). There is no way currently to instruct a host to use a particular DNS server out of the configured servers list for resolving a particular name. Therefore it does not seem feasible to solve the problem of Baker, et al. Expires February 1, 2020 [Page 44] Internet-Draft Enterprise PA Multihoming July 2019 DNS server selection on the host (it should be noted that this particular issue is protocol-agnostic and happens for IPv4 as well). In such a scenario it is recommended that the enterprise runs its own local recursive DNS server. To influence host source address selection for packets sent to a particular DNS server the following requirements must be met: o the host supports RIO as defined in [RFC4191]; o the routers send RIO for routes to DNS server addresses. For example, if it is desirable that host H31 reaches the ISP-A DNS server H51 2001:db8:0:5555::51 using its source address 2001:db8:0:a010::31, then both R1 and R2 should send the RIO containing the route to 2001:db8:0:5555::51 (or covering route) in their 'scoped' RAs, containing LLA_A as the default router address and the PO for SLAAC prefix 2001:db8:0:a010::/64. In that case the host H31 (if it supports the Rule 5.5) would select LLA_A as a next- hop and then chose 2001:db8:0:a010::31 as the source address for packets to the DNS server. It should be noted that [RFC6106] explicitly prohibits using DNS information if the RA router Lifetime expired: "An RDNSS address or a DNSSL domain name MUST be used only as long as both the RA router Lifetime (advertised by a Router Advertisement message) and the corresponding option Lifetime have not expired.". Therefore hosts might ignore RDNSS information provided in ULA-scoped RAs as those RAs would have router lifetime set to 0. However the updated version of RFC6106 ([RFC8106]) has that requirement removed. As discussed above the DNS split-horizon problem and selecting the correct DNS server in a multihomed envinroment is not an easy one to solve. The proper solution would require hosts to support the concept of multiple Provisioning Domains (PvD, a set of configuration information associated with a network, [RFC7556]). 7. Deployment Considerations The solution described in this document requires certain mechanisms to be supported by the network infrastructure and hosts. It requires some routers in the enterprise site to support some form of Source Address Dependent Routing (SADR). It also requires hosts to be able to learn when the uplink to an ISP changes its state so the corresponding source addresses should (or should not) be used. Ongoing work to create mechanisms to accomplish this are discussed in this document, but they are still a work in progress. Baker, et al. Expires February 1, 2020 [Page 45] Internet-Draft Enterprise PA Multihoming July 2019 7.1. Deploying SADR Domain The proposed solution provides does not prescribe particular details regarding deploying an SADR domain within a multihomed enterprise network. However the following guidelines could be applied: o The SADR domain is usually limited by the multihomed site border. o The minimal deployable scenario requires enabling SADR on all SERs and including them into a single SADR domain. o As discussed in Section 4.2, extending the connected SADR domain beyond that point down to the first-hop routers can produce more efficient forwarding paths and allow the network to fully benefit from SADR. it would also simplify the operation of the SADR domain. o During the incremental SADR domain expansion from the SERs down towards first-hop routers it's important to ensure that at any moment of time all SADR-capable routers within the domain are logically connected (see Section 5). 7.2. Hosts-Related Considerations The solution discussed in this document relies on the default address selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] considers this rule as optional, the recent [RFC8028] states that "A host SHOULD select default routers for each prefix it is assigned an address in". It also recommends that hosts should implement Rule 5.5. of [RFC6724]. Therefore while RFC8028-compliant hosts already have mechanism to learn about ISP uplinks state changes and selecting the source addresses accordingly, many hosts do not have such mechanism supported yet. It should be noted that multihomed enterprise network utilizing multiple ISP prefixes can be considered as a typical multiple provisioning domain (mPVD) scenario, as described in [RFC7556]. This document defines a way for the network to provide the PVD information to hosts indirectly, using the existing mechanisms. At the same time [I-D.ietf-intarea-provisioning-domains] takes one step further and describes a comprehensive mechanism for hosts to discover the whole set of configuration information associated with different PVD/ISPs. [I-D.ietf-intarea-provisioning-domains] complements this document in terms of making hosts being able to learn about ISP uplink states and selecting the corresponding source addresses. Baker, et al. Expires February 1, 2020 [Page 46] Internet-Draft Enterprise PA Multihoming July 2019 8. Other Solutions 8.1. Shim6 The Shim6 working group specified the Shim6 protocol [RFC5533] which allows a host at a multihomed site to communicate with an external host and exchange information about possible source and destination address pairs that they can use to communicate. It also specified the REAP protocol [RFC5534] to detect failures in the path between working address pairs and find new working address pairs. A fundamental requirement for Shim6 is that both internal and external hosts need to support Shim6. That is, both the host internal to the multihomed site and the host external to the multihomed site need to support Shim6 in order for there to be any benefit for the internal host to run Shim6. The Shim6 protocol specification was published in 2009, but it has not been widely implemented. Therefore Shim6 is not considered as a viable solution for enterprise multihoming. 8.2. IPv6-to-IPv6 Network Prefix Translation IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the focus of this document. NPTv6 suffers from the same fundamental issue as any other address translation approaches: it breaks end-to- end connectivity. Therefore NPTv6 is not considered as desirable solution and this document intentionally focuses on solving enterprise multihoming problem without any form of address translations. With increasing interest and ongoing work in bringing path awareness to transport and application layer protocols hosts might be able to determine the properties of the various network paths and choose among paths available to them. As selecting the correct source address is one of the possible mechanisms path-aware hosts may utilize, address translation negatively affects hosts path-awareness which makes NTPv6 even more undesirable solution. 8.3. Multipath Transport Using multipath transport (such as MPTCP, [RFC6824] or multipath capabilities in QUIC) might solve the problems discussed in Section 6 since it would allow hosts to use multiple source addresses for a single connection and switch between source addresses when a particular address becomes unavailable or a new address gets assigned to the host interface. Therefore if all hosts in the enterprise network are only using multipath transport for all connections, the signaling solution described in Section 6 might not be needed (it should be noted that the Source Address Dependent Routing would still be required to deliver packets to the correct uplinks). At the time Baker, et al. Expires February 1, 2020 [Page 47] Internet-Draft Enterprise PA Multihoming July 2019 this document was written, multipath transport alone could not be considered a solution for the problem of selecting the source address in a multihomed environment. There are significant number of hosts which do not use multipath transport currently and it seems unlikely that the situation is going to change in any foreseeable future (even if new releases of operatin systems get multipath protocols support there will be a long tail of legacy hosts). The solution for enterprise multihoming needs to work for the least common denominator: hosts without multipath transport support. In addition, not all protocols are using multipath transport. While multipath transport would complement the solution described in Section 6, it could not be considered as a sole solution to the problem of source address selection in multihomed environments. On the other hand PA-based multihoming could provide additional benefits for multipath protocol, should those protocols be deployed in the network. Multipath protocols could leverage source address selection to achieve maximum path diversity (and potentially improved performance). Therefore deploying multipath protocols could not be considered as an alternative to the approach proposed in this document. Instead both solutions complement each other so deploying multipath protocols in PA-based multihomed network proves mutually beneficial. 9. IANA Considerations This memo asks the IANA for no new parameters. 10. Security Considerations Section 6.2.3 discusses a mechanism for controlling source address selection on hosts using ICMPv6 messages. Using ICMPv6 to influence source address selection allows an attacker to exhaust the list of candidate source addresses on the host by sending spoofed ICMPv6 Code 5 for all prefixes known on the network (therefore preventing a victim from establishing a communication with the destination host). Another possible attack vector is using ICMPv6 Destination Unreachable Messages with Code 5 to steer the egress tra ffic towards the particular ISP (for example if the attacker has the ability of doing traffic sniffing or man-in-the-middle attack in that ISP network). To prevent those attacks hosts SHOULD verify that the original packet header included into ICMPv6 error message was actually sent by the host (to ensure that the ICMPv6 message was triggered by a packet sent by the host). Baker, et al. Expires February 1, 2020 [Page 48] Internet-Draft Enterprise PA Multihoming July 2019 As ICMPv6 Destination Unreachable Messages with Code 5 could be originated by any SADR-capable router within the domain (or even come from the Internet), GTSM ([RFC5082]) can not be applied. Filtering such ICMOv6 messages at the site border can not be recommended as it would break the legitimate end2end error signalling mechanism ICMPv6 is designed for. The security considerations of using stateless address autoconfiguration are discussed in [RFC4862]. 11. Acknowledgements The original outline was suggested by Ole Troan. The authors would like to thank the following people (in alphabetical order) for their review and feedback: Olivier Bonaventure, Deborah Brungard, Brian E Carpenter, Lorenzo Colitti, Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja Kuhlewind, David Lamparter, Nicolai Leymann, Acee Lindem, Philip Matthewsu, Robert Raszuk, Alvaro Retana, Pete Resnick, Dave Thaler, Michael Tuxen, Martin Vigoureux, Eric Vyncke, Magnus Westerlund. 12. References 12.1. Normative References [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, . [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, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . Baker, et al. Expires February 1, 2020 [Page 49] Internet-Draft Enterprise PA Multihoming July 2019 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [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, . [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, DOI 10.17487/RFC6106, November 2010, . [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, . [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, . [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, DOI 10.17487/RFC7078, January 2014, . [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, . [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . Baker, et al. Expires February 1, 2020 [Page 50] Internet-Draft Enterprise PA Multihoming July 2019 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . 12.2. Informative References [I-D.ietf-intarea-provisioning-domains] Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", draft-ietf-intarea-provisioning-domains-05 (work in progress), June 2019. [I-D.ietf-rtgwg-dst-src-routing] Lamparter, D. and A. Smirnov, "Destination/Source Routing", draft-ietf-rtgwg-dst-src-routing-07 (work in progress), March 2019. [I-D.pfister-6man-sadr-ra] Pfister, P., "Source Address Dependent Route Information Option for Router Advertisements", draft-pfister-6man- sadr-ra-01 (work in progress), June 2015. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 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, . Baker, et al. Expires February 1, 2020 [Page 51] Internet-Draft Enterprise PA Multihoming July 2019 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, . [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, DOI 10.17487/RFC5534, June 2009, . [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2011, . [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, . [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, . Authors' Addresses Fred Baker Santa Barbara, California 93117 USA Email: FredBaker.IETF@gmail.com Chris Bowers Juniper Networks Sunnyvale, California 94089 USA Email: cbowers@juniper.net Jen Linkova Google 1 Darling Island Rd Pyrmont, NSW 2009 AU Email: furry@google.com Baker, et al. Expires February 1, 2020 [Page 52] ./draft-ietf-softwire-map-radius-26.txt0000644000764400076440000022665513500732705017304 0ustar iustyiusty Softwire S. Jiang, Ed. Internet-Draft Huawei Technologies Co., Ltd Intended status: Standards Track Y. Fu, Ed. Expires: December 16, 2019 CNNIC C. Xie China Telecom T. Li Tsinghua University M. Boucadair, Ed. Orange June 14, 2019 RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms draft-ietf-softwire-map-radius-26 Abstract IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 co-existence period. DHCPv6 options have been defined for configuring clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation, and Mapping of Address and Port using Translation unicast softwire mechanisms, and also multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting server which utilizes the RADIUS protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly. This document defines new RADIUS attributes to carry Address plus Port based softwire configuration parameters from an Authentication, Authorization, and Accounting server to a Broadband Network Gateway. Both unicast and multicast attributes are covered. 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 https://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 Jiang, Ed., et al. Expires December 16, 2019 [Page 1] Internet-Draft A+P RADIUS Attributes June 2019 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 16, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 6 3.1. Softwire46-Configuration Attribute . . . . . . . . . . . 7 3.1.1. Softwire46 Attributes . . . . . . . . . . . . . . . . 8 3.1.1.1. Softwire46-MAP-E Attribute . . . . . . . . . . . 10 3.1.1.2. Softwire46-MAP-T Attribute . . . . . . . . . . . 10 3.1.1.3. Softwire46-Lightweight-4over6 Attribute . . . . . 11 3.1.2. Softwire46 Sub-Attributes . . . . . . . . . . . . . . 11 3.1.3. Specification of the Softwire46 Sub-Attributes . . . 12 3.1.3.1. Softwire46-Rule Attribute . . . . . . . . . . . . 12 3.1.3.2. Softwire46-BR Attribute . . . . . . . . . . . . . 13 3.1.3.3. Softwire46-DMR Attribute . . . . . . . . . . . . 14 3.1.3.4. Softwire46-V4V6Bind Attribute . . . . . . . . . . 14 3.1.3.5. Softwire46-PORTPARAMS Attribute . . . . . . . . . 15 3.1.4. Sub-Attributes for Sofwtire46-Rule . . . . . . . . . 16 3.1.4.1. Rule-IPv6-Prefix Attribute . . . . . . . . . . . 16 3.1.4.2. Rule-IPv4-Prefix Attribute . . . . . . . . . . . 17 3.1.4.3. EA-Length Attribute . . . . . . . . . . . . . . . 17 3.1.5. Attributes for Softwire46-v4v6Bind . . . . . . . . . 18 3.1.5.1. IPv4-Address Attribute . . . . . . . . . . . . . 18 3.1.5.2. Bind-IPv6-Prefix Attribute . . . . . . . . . . . 18 3.1.6. Attributes for Softwire46-PORTPARAMS . . . . . . . . 19 3.1.6.1. PSID-Offset Attribute . . . . . . . . . . . . . . 19 3.1.6.2. PSID-Len Attribute . . . . . . . . . . . . . . . 20 3.1.6.3. PSID Attribute . . . . . . . . . . . . . . . . . 20 Jiang, Ed., et al. Expires December 16, 2019 [Page 2] Internet-Draft A+P RADIUS Attributes June 2019 3.2. Softwire46-Priority Attribute . . . . . . . . . . . . . . 21 3.2.1. Softwire46-Option-Code . . . . . . . . . . . . . . . 22 3.3. Softwire46-Multicast Attribute . . . . . . . . . . . . . 23 3.3.1. ASM-Prefix64 Attribute . . . . . . . . . . . . . . . 24 3.3.2. SSM-Prefix64 Attribute . . . . . . . . . . . . . . . 25 3.3.3. U-Prefix64 Attribute . . . . . . . . . . . . . . . . 25 4. A Sample Configuration Process with RADIUS . . . . . . . . . 25 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7.1. New RADIUS Attributes . . . . . . . . . . . . . . . . . . 30 7.2. RADIUS Softwire46 Configuration and Multicast Attributes 31 7.3. Softwire46 Mechanisms and Their Identifying Option Codes 32 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. DHCPv6 to RADIUS Field Mappings . . . . . . . . . . 37 A.1. OPTION_S46_RULE (89) to Softwire46-Rule Sub-TLV Field Mappings . . . . . . . . . . . . . . . . . . . . . . . . 37 A.2. OPTION_S46_BR (90) to Softwire46-BR Field Mappings . . . 38 A.3. OPTION_S46_DMR (91) to Softwire46-DMR . . . . . . . . . . 38 A.4. OPTION_S46_V4V6BIND (92) to Softwire46-V4V6Bind . . . . . 38 A.5. OPTION_S46_PORTPARAMS (93) to Softwire46-PORTPARAMS Field Mappings . . . . . . . . . . . . . . . . . . . . . . . . 38 A.6. OPTION_S46_PRIORITY (111) to Softwire46-PORTPARAMS Field Mappings . . . . . . . . . . . . . . . . . . . . . . . . 39 A.7. OPTION_V6_PREFIX64 (113) to Softwire46-Multicast Attribute Field Mappings . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction Providers have started deploying and transitioning to IPv6. Several IPv4 service continuity mechanisms based on the Address plus Port (A+P) [RFC6346] have been proposed for providing unicast IPv4 over IPv6-only infrastructure, such as Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], Mapping of Address and Port using Translation (MAP-T) [RFC7599], and Lightweight 4over6 [RFC7596]. Also, [RFC8114] specifies a generic solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. For each of these mechanisms, DHCPv6 options have been specified for client configuration. In many networks, user configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server. AAA servers generally communicate using the Remote Authentication Dial In Jiang, Ed., et al. Expires December 16, 2019 [Page 3] Internet-Draft A+P RADIUS Attributes June 2019 User Service (RADIUS) [RFC2865] protocol. In a fixed broadband network, a Broadband Network Gateway (BNG) acts as the access gateway for users. That is, the BNG acts as both an AAA client to the AAA server, and a DHCPv6 server for DHCPv6 messages sent by clients. Throughout this document, the term BNG describes a device implementing both the AAA client and DHCPv6 server functions. Since IPv4-in-IPv6 softwire configuration information is stored in an AAA server, and user configuration information is mainly transmitted through DHCPv6 between the BNGs and Customer Premises Equipment (CEs, a.k.a., CPE), new RADIUS attributes are needed to propagate the information from the AAA servers to BNGs so that they can be provided to CEs using the existing DHCPv6 options. The RADIUS attributes defined in this document provide configuration to populate the corresponding DHCPv6 options for unicast and multicast softwire configuration, specifically: o "Mapping of Address and Port with Encapsulation (MAP-E)" [RFC7597] (DHCPv6 options defined in [RFC7598]). o "Mapping of Address and Port using Translation (MAP-T)" [RFC7599] (DHCPv6 options defined in [RFC7598]). o "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture" [RFC7596] (DHCPv6 options defined in [RFC7598]). o "Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism" [RFC8026]. o "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network" [RFC8114] (DHCPv6 options defined in [RFC8115]). The contents of the attributes defined in this document have a 1:1 mapping into the fields of the various DHCPv6 options in [RFC7598], [RFC8026], and [RFC8115]. Table 1 shows how the DHCPv6 options map to the corresponding RADIUS attribute. For detailed mappings between each DHCPv6 option field and the corresponding RADIUS Attribute or field, see Appendix A. Jiang, Ed., et al. Expires December 16, 2019 [Page 4] Internet-Draft A+P RADIUS Attributes June 2019 +----------------------------+--------------------------------+ | DHCPv6 Option | RADIUS Attribute | +----------------------------+--------------------------------+ | OPTION_S46_RULE (89) | Softwire46-Rule | | OPTION_S46_BR (90) | Softwire46-BR | | OPTION_S46_DMR (91) | Softwire46-DMR | | OPTION_S46_V4V6BIND (92) | Softwire46-V4V6Bind | | OPTION_S46_PORTPARAMS (93) | Softwire46-PORTPARAMS | | OPTION_S46_PRIORITY (111) | Softwire46-Priority | | OPTION_V6_PREFIX64 (113) | Softwire46-Multicast | +----------------------------+--------------------------------+ Table 1: Mapping between DHCPv6 Options and RADIUS Attributes A RADIUS attribute for Dual-Stack Lite [RFC6333] is defined in [RFC6519]. This document targets deployments where a trusted relationship is in place between the RADIUS client and server. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the concepts and terms defined in [RFC7596], [RFC7597], [RFC7599], and [RFC8026]. The terms "multicast Basic Bridging BroadBand" element (mB4) and "multicast Address Family Transition Router" element (mAFTR) are defined in [RFC8114]. Softwire46 (S46) is used throughout to denote any of the IPv4-in-IPv6 softwire mechanisms listed above. Additionally, the following abbreviations are used within the document: o BNG: Broadband Network Gateway o BR: Border Relay o CE: Customer Edge o DMR: Default Mapping Rule o lwAFTR: Lightweight AFTR Jiang, Ed., et al. Expires December 16, 2019 [Page 5] Internet-Draft A+P RADIUS Attributes June 2019 o PSID: Port Set Identifier o TLV: Type, Length, Value o MAP-E: Mapping of Address and Port with Encapsulation o MAP-T: Mapping of Address and Port using Translation 3. New RADIUS Attributes This section defines the following attributes: 1. Softwire46-Configuration Attribute (Section 3.1): This attribute carries the configuration information for MAP-E, MAP-T, and Lightweight 4over6. The configuration information for each Softwire46 mechanism is carried in the corresponding Softwire46 attributes. Different attributes are required for each Softwire46 mechanism. 2. Softwire46-Priority Attribute (Section 3.2): Depending on the deployment scenario, a client may support several different Softwire46 mechanisms. Therefore, a client may request configuration for more than one Softwire46 mechanism at a time. The Softwire46-Priority Attribute contains information allowing the client to prioritize which mechanism to use, corresponding to OPTION_S46_PRIORITY defined in [RFC8026]. 3. Softwire46-Multicast Attribute (Section 3.3): This attribute conveys the IPv6 prefixes to be used in [RFC8114] to synthesize IPv4-embedded IPv6 addresses. The BNG uses the IPv6 prefixes returned in the RADIUS Softwire46-Multicast Attribute to populate the DHCPv6 PREFIX64 Option [RFC8115]. All of these attributes are allocated from the RADIUS "Extended Type" code space per [RFC6929]. All of these attribute designs follow [RFC6158] and [RFC6929]. This document adheres to [RFC8044] for defining the new RADIUS attributes. Jiang, Ed., et al. Expires December 16, 2019 [Page 6] Internet-Draft A+P RADIUS Attributes June 2019 3.1. Softwire46-Configuration Attribute This attribute is of type "tlv", as defined in the RADIUS Protocol Extensions [RFC6929]. It contains some sub-attributes, with the following requirements: The Softwire46-Configuration Attribute MUST contain one or more of the following attributes: Softwire46-MAP-E, Softwire46-MAP-T, and/ or Softwire46-Lightweight-4over6. The Softwire46-Configuration Attribute conveys the configuration information for MAP-E, MAP-T, or Lightweight 4over6. The BNG SHALL use the configuration information returned in the RADIUS attribute to populate the DHCPv6 Softwire46 Container Option(s) defined in Section 5 of [RFC7598]. The Softwire46-Configuration Attribute MAY appear in an Access- Accept packet. It MAY also appear in an Access-Request packet to indicate a preferred Softwire46 configuration. However, the server is not required to honor such a preference. The Softwire46-Configuration Attribute MAY appear in a CoA-Request packet. The Softwire46-Configuration Attribute MAY appear in an Accounting-Request packet. The Softwire46-Configuration Attribute MUST NOT appear in any other RADIUS packet. The Softwire46-Configuration Attribute is structured as follows: Jiang, Ed., et al. Expires December 16, 2019 [Page 7] Internet-Draft A+P RADIUS Attributes June 2019 Type 241 (To be confirmed by IANA). Length 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 attributes. Extended-Type TBD1 Value Contains one or more of the following attributes. Each attribute type may appear at most once: Softwire46-MAP-E For configuring MAP-E clients. For the construction of this attribute, refer to Section 3.1.1.1. Softwire46-MAP-T For configuring MAP-T clients. For the construction of this attribute, refer to Section 3.1.1.2. Softwire46-Lightweight-4over6 For configuring Lightweight 4over6 clients. For the construction of this attribute, refer to Section 3.1.1.3. The Softwire46-Configuration Attribute is associated with the following identifier: 241.Extended-Type(TBD1). 3.1.1. Softwire46 Attributes The Softwire46 attributes can only be encapsulated in the Softwire46-Configuration Attribute. Depending on the deployment scenario, a client might request for more than one transition mechanism at a time. There MUST be at least one Softwire46 attribute encapsulated in one Softwire46-Configuration Attribute. There MUST be at most one instance of each type of Softwire46 attribute encapsulated in one Softwire46-Configuration Attribute. There are three types of Softwire46 attributes, namely: 1. Softwire46-MAP-E (Section 3.1.1.1) 2. Softwire46-MAP-T (Section 3.1.1.2) 3. Softwire46-Lightweight 4over6 (Section 3.1.1.3) Jiang, Ed., et al. Expires December 16, 2019 [Page 8] Internet-Draft A+P RADIUS Attributes June 2019 Each type of Softwire46 attribute contains a number of sub- attributes, defined in Section 3.1.3. The hierarchy of the Softwire46 attributes is shown in Figure 1. Section 3.1.2 describes which sub-attributes are mandatory, optional, or not permitted for each defined Softwire46 attribute. /1.Rule-IPv6-Prefix S / | o / | 1.Softwire46-Rule -----+ 2.Rule-IPv4-Prefix f | Softwire46-MAP-E--+ | t | | 2.Softwire46-BR | 3.EA Length w | | \ i | | /1.PSID-Offset r | | | e | | 3.Softwire46-PORTPARAMS -----+ 2.PSID-Len - | \ | C | | 3.PSID o | \ n | f | /1.Rule-IPv6-Prefix i | / | g | | 1.Softwire46-Rule------+ 2.Rule-IPv4-Prefix u | Softwire46-MAP-T--+ | r | | 2.Softwire46-DMR | 3.EA Length a | | \ t | | /1.PSID-Offset i | | | o | | 3.Softwire46-PORTPARAMS------+ 2.PSID-Len n | \ | | | 3.PSID A | \ t | t | /1.IPv4-Address r | / | i | | 1.Softwire46-V4V6Bind -----+ 2.Bind-IPv6-Prefix b | Softwire46- | \ u | Lightweight-4over6+ 2.Softwire46-BR /1.PSID-Offset t \ | | e | 3.Softwire46-PORTPARAMS ----+ 2.PSID-Len \ | | 3.PSID \ Figure 1: Softwire46 Attributes Hierarchy Jiang, Ed., et al. Expires December 16, 2019 [Page 9] Internet-Draft A+P RADIUS Attributes June 2019 3.1.1.1. Softwire46-MAP-E Attribute Softwire46-MAP-E attribute is designed for carrying the configuration information for MAP-E. The structure of Softwire46-MAP-E is shown below: TLV-Type 1 TLV-Length Indicates the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields. TLV-Value Contains a set of sub-attributes, with the following requirements: It MUST contain Softwire46-Rule, defined in Section 3.1.3.1. It MUST contain Softwire46-BR, defined in Section 3.1.3.2. It MAY contain Softwire46-PORTPARAMS, defined in Section 3.1.3.5. 3.1.1.2. Softwire46-MAP-T Attribute Softwire46-MAP-T attribute is designed for carrying the configuration information for MAP-T. The structure of Softwire46-MAP-T is shown below: TLV-Type 2 TLV-Length Indicates the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields. TLV-Value Contains a set of sub-attributes, with the following requirements: It MUST contain Softwire46-Rule, defined in Section 3.1.3.1. It MUST contain Softwire46-DMR, defined in Section 3.1.3.3. It MAY contain Softwire46-PORTPARAMS, defined in Section 3.1.3.5. Jiang, Ed., et al. Expires December 16, 2019 [Page 10] Internet-Draft A+P RADIUS Attributes June 2019 3.1.1.3. Softwire46-Lightweight-4over6 Attribute Softwire46-Lightweight-4over6 attribute is designed for carrying the configuration information for Lightweight 4over6. The structure of Softwire46-Lightweight-4over6 is shown below: TLV-Type 3 TLV-Length Indicates the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields. TLV-Value Contains a set of sub-attributes as follows: It MUST contain Softwire46-BR, defined in Section 3.1.3.2. It MUST contain Softwire46-V4V6Bind, defined in Section 3.1.3.4. It MAY contain Softwire46-PORTPARAMS, defined in Section 3.1.3.5. 3.1.2. Softwire46 Sub-Attributes Table 2 shows which encapsulated sub-attributes are mandatory, optional, or not permitted for each defined Softwire46 attribute. +-----------------------+-------+-------+--------------------+ | Sub-Attributes | MAP-E | MAP-T | Lightweight 4over6 | +-----------------------+-------+-------+--------------------+ | Softwire46-BR | 1+ | 0 | 1+ | | Softwire46-Rule | 1 | 1 | 0 | | Softwire46-DMR | 0 | 1 | 0 | | Softwire46-V4V6Bind | 0 | 0 | 1 | | Softwire46-PORTPARAMS | 0-1 | 0-1 | 0-1 | +-----------------------+-------+-------+--------------------+ Table 2: Softwire46 Sub-Attributes The following table defines the meaning of Table 2 entries. Jiang, Ed., et al. Expires December 16, 2019 [Page 11] Internet-Draft A+P RADIUS Attributes June 2019 0 Not Permitted 0-1 Optional, zero or one instance of the attribute may be present. 1 Mandatory, only one instance of the attribute must be present. 1+ Mandatory, one or more instances of the attribute may be present. 3.1.3. Specification of the Softwire46 Sub-Attributes 3.1.3.1. Softwire46-Rule Attribute Softwire46-Rule can only be encapsulated in Softwire46-MAP-E (Section 3.1.1.1) or Softwire46-MAP-T (Section 3.1.1.2). Depending on the deployment scenario, one Basic Mapping Rule (BMR) and zero or more Forwarding Mapping Rules (FMRs) MUST be included in one Softwire46-MAP-E or Softwire46-MAP-T. Each type of Softwire46-Rule also contains a number of sub- attributes, including Rule-IPv6-Prefix, Rule-IPv4-Prefix, and EA- Length. The structure of the sub-attributes for Softwire46-Rule is defined in Section 3.1.4. Defining multiple TLV-types achieves the same design goals as the "Softwire46 Rule Flags" defined in Section 4.1 of [RFC7598]. Using TLV-type set to 5 is equivalent to setting the F-flag in the OPTION_S46_RULE S46 Rule Flags field. Jiang, Ed., et al. Expires December 16, 2019 [Page 12] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 4 Basic Mapping Rule only (not to be used for forwarding) 5 Forwarding Permitted Mapping Rule TLV-Length Indicates the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields. Data Type The attribute Softwire46-Rule is of type tlv (Section 3.13 of [RFC8044]). TLV-Value This field contains a set of attributes as follows: Rule-IPv6-Prefix This attribute contains the IPv6 prefix for use in the MAP rule. Refer to Section 3.1.4.1. Rule-IPv4-Prefix This attribute contains the IPv4 prefix for use in the MAP rule. Refer to Section 3.1.4.2. EA-Length This attribute contains the Embedded-Address (EA) bit length. Refer to Section 3.1.4.3. 3.1.3.2. Softwire46-BR Attribute Softwire46-BR can only be encapsulated in Softwire46-MAP-E (Section 3.1.1.1) or Softwire46-Lightweight-4over6 (Section 3.1.1.3). There MUST be at least one Softwire46-BR included in each Softwire46-MAP-E or Softwire46-Lightweight-4over6. The structure of Softwire46-BR is shown below: Jiang, Ed., et al. Expires December 16, 2019 [Page 13] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 6 TLV-Length 18 octets Data Type The attribute Softwire46-BR is of type ip6addr (Section 3.9 of [RFC8044]). TLV-Value br-ipv6-address. A fixed-length field of 16 octets that specifies the IPv6 address for the Softwire46 Border Relay (BR). 3.1.3.3. Softwire46-DMR Attribute Softwire46-DMR may only appear in Softwire46-MAP-T (Section 3.1.1.2). There MUST be exactly one Softwire46-DMR included in one Softwire46- MAP-T. The structure of Softwire46-DMR is shown below: TLV-Type 7 TLV-Length 4 + length of dmr-ipv6-prefix specified in octets. Data Type The attribute Softwire46-DMR is of type ipv6pref (Section 3.10 of [RFC8044]). TLV-Value A variable-length (dmr-prefix6-len) field specifying the IPv6 prefix (dmr-ipv6-prefix) for the BR. This field is right-padded with zeros to the nearest octet boundary when dmr-prefix6-len is not divisible by 8. Prefixes with length from 0 to 96 are allowed. 3.1.3.4. Softwire46-V4V6Bind Attribute Softwire46-V4V6Bind may only be encapsulated in Softwire46- Lightweight-4over6 (Section 3.1.1.3). There MUST be exactly one Softwire46-V4V6Bind included in each Softwire46-Lightweight-4over6. The structure of Softwire46-V4V6Bind is shown below: Jiang, Ed., et al. Expires December 16, 2019 [Page 14] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 8 TLV-Length Indicates the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields. Data Type The attribute Softwire46-V4V6Bind is of type tlv (Section 3.13 of [RFC8044]). TLV-Value This field contains a set of attributes as follows: IPv4-Address This attribute contains an IPv4 address, used to specify the full or shared IPv4 address of the CE. Refer to Section 3.1.5.1. Bind-IPv6-Prefix This attribute contains an IPv6 prefix used to indicate which configured prefix the Softwire46 CE should use for constructing the softwire. Refer to Section 3.1.5.2. 3.1.3.5. Softwire46-PORTPARAMS Attribute Softwire46-PORTPARAMS is optional. It is used to specify port set information for IPv4 address sharing between clients. Softwire46-PORTPARAMS MAY be included in any of the Softwire46 attributes. The structure of Softwire46-PORTPARAMS is shown below: Jiang, Ed., et al. Expires December 16, 2019 [Page 15] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 9 TLV-Length Indicates the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields. Data Type The attribute Softwire46-PORTPARAMS is of type tlv (Section 3.13 of [RFC8044]). TLV-Value This field contains a set of attributes as follows: PSID-Offset This attribute specifies the numeric value for the Softwire46 algorithm's excluded port range/offset bits (a bits). Refer to Section 3.1.6.1. PSID-Len This attribute specifies the number of significant bits in the PSID field (also known as 'k'). Refer to Section 3.1.6.2. PSID This attribute specifies PSID value. Refer to Section 3.1.6.3. 3.1.4. Sub-Attributes for Sofwtire46-Rule There are two types of Softwire46-Rule: the Basic Mapping Rule and the Forwarding Mapping Rule, indicated by the value in the TLV-Type field of Softwire46-Rule (Section 3.1.3.1). Each type of Softwire46-Rule also contains a number of Sub-attributes as detailed in the following sub-sections. 3.1.4.1. Rule-IPv6-Prefix Attribute Rule-IPv6-Prefix is REQUIRED for every Softwire46-Rule. There MUST be exactly one Rule-IPv6-Prefix encapsulated in each type of Softwire46-Rule. Rule-IPv6-Prefix follows the framed IPv6 prefix designed in [RFC3162] and [RFC8044]. The structure of Rule-IPv6-Prefix is shown below: Jiang, Ed., et al. Expires December 16, 2019 [Page 16] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 10 TLV-Length 4 + length of rule-ipv6-prefix specified in octets. Data Type The attribute Rule-IPv6-Prefix is of type ipv6pref (Section 3.10 of [RFC8044]). TLV-Value A variable-length field that specifies an IPv6 prefix (rule-ipv6-prefix) appearing in the MAP rule. 3.1.4.2. Rule-IPv4-Prefix Attribute This attribute is used to convey the MAP Rule IPv4 prefix. The structure of Rule-IPv4-Prefix is shown below: TLV-Type 11 TLV-Length 4 + length of rule-ipv4-prefix specified in octets. Data Type The attribute Rule-IPv4-Prefix is of type ipv4pref (Section 3.11 of [RFC8044]). TLV-Value A variable-length field that specifies an IPv4 prefix (rule-ipv4-prefix) appearing in the MAP rule. 3.1.4.3. EA-Length Attribute This attribute is used to convey the Embedded-Address (EA) bit length. The structure of EA-Length is shown below: Jiang, Ed., et al. Expires December 16, 2019 [Page 17] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 12 TLV-Length 6 octets Data Type The attribute EA-Length is of type integer (Section 3.1 of [RFC8044]). TLV-Value EA-len; 32-bits long. Specifies the Embedded-Address (EA) bit length. Allowed values range from 0 to 48. 3.1.5. Attributes for Softwire46-v4v6Bind 3.1.5.1. IPv4-Address Attribute The IPv4-Address MAY be used to specify the full or shared IPv4 address of the CE. The structure of IPv4-Address is shown below: TLV-Type 13 TLV-Length 6 octets Data Type The attribute IPv4-Address is of type ipv4addr (Section 3.8 of [RFC8044]). TLV-Value 32-bits long. Specifies the IPv4 address (ipv4-address) to appear in Softwire46-V4V6Bind (Section 3.1.3.4). 3.1.5.2. Bind-IPv6-Prefix Attribute The Bind-IPv6-Prefix is used by the CE to identify the correct IPv6 prefix to be used as the tunnel source. The structure of Bind-IPv6-Prefix is shown below: Jiang, Ed., et al. Expires December 16, 2019 [Page 18] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 14 TLV-Length 4 + length of bind-ipv6-prefix specified in octets. Data Type The attribute Bind-IPv6-Prefix is of type ipv6pref (Section 3.10 of [RFC8044]). TLV-Value A variable-length field specifying the IPv6 prefix or address for the Softwire46 CE (bind-ipv6-prefix). This field is right-padded with zeros to the nearest octet boundary when the prefix length is not divisible by 8. 3.1.6. Attributes for Softwire46-PORTPARAMS 3.1.6.1. PSID-Offset Attribute This attribute is used to convey the Port Set Identifier offset as defined in [RFC7597]. This attribute is encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158]. The structure of PSID-Offset is shown below: TLV-Type 15 TLV-Length 6 octets Data Type The attribute PSID-Offset is of type integer (Section 3.1 of [RFC8044]). TLV-Value Contains the PSID-Offset (8-bits) right justified, and the unused bits in this field MUST be set to zero. This field specifies the numeric value for the Softwire46 algorithm's excluded port range/offset bits (a bits), as per Section 5.1 of [RFC7597]. Default values for this field are specific to the Softwire mechanism being implemented and are defined in the relevant specification document. Jiang, Ed., et al. Expires December 16, 2019 [Page 19] Internet-Draft A+P RADIUS Attributes June 2019 3.1.6.2. PSID-Len Attribute This attribute is used to convey the PSID length as defined in [RFC7597]. This attribute is encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158]. The structure of PSID-Len is shown below: TLV-Type 16 TLV-Length 6 octets Data Type The attribute PSID-Len is of type integer (Section 3.1 of [RFC8044]). TLV-Value Contains the PSID-len (8-bits) right justified, and the unused bits in this field MUST be set to zero. This field specifies the number of significant bits in the PSID field (also known as 'k'). When set to 0, the PSID field is to be ignored. After the first 'a' bits, there are k bits in the port number representing the value of the PSID. Subsequently, the address sharing ratio would be 2^k. 3.1.6.3. PSID Attribute This attribute is used to convey the PSID as defined in [RFC7597]. This attribute is encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158]. The structure of PSID is shown below: Jiang, Ed., et al. Expires December 16, 2019 [Page 20] Internet-Draft A+P RADIUS Attributes June 2019 TLV-Type 17 TLV-Length 6 octets Data Type The attribute PSID is of type integer (Section 3.1 of [RFC8044]). TLV-Value Contains the PSID (16-bits) right justified, and the unused bits in this field MUST be set to zero. The PSID value algorithmically identifies a set of ports assigned to a CE. The first k bits on the left of this 2-octet field is the PSID value. The remaining (16-k) bits on the right are padding zeros. 3.2. Softwire46-Priority Attribute The Softwire46-Priority Attribute includes an ordered list of Softwire46 mechanisms allowing the client to prioritize which mechanism to use, corresponding to OPTION_S46_PRIORITY defined in [RFC8026]. The following requirements apply: The Softwire46-Priority Attribute MAY appear in an Access-Accept packet. It MAY also appear in an Access-Request packet. The Softwire46-Priority Attribute MAY appear in a CoA-Request packet. The Softwire46-Priority Attribute MAY appear in an Accounting- Request packet. The Softwire46-Priority Attribute MUST NOT appear in any other RADIUS packet. The Softwrie46-Priority Attribute is structured as follows: Jiang, Ed., et al. Expires December 16, 2019 [Page 21] Internet-Draft A+P RADIUS Attributes June 2019 Type 241 (To be confirmed by IANA) Length Indicates the length of this attribute, including the Type, Length, Extended-Type and Value fields. Extended-Type TBD5 TLV-Value The attribute includes one or more Softwire46-Option-Code TLVs: A Softwire46-Priority Attribute MUST contain at least one Softwire46-Option-Code TLV (Section 3.2.1). Softwire46 mechanisms are prioritized in the appearance order of the in the Softwire46-Priority Attribute. That is, the first-appearing mechanism is most preferred. The Softwire46-Priority Attribute is associated with the following identifier: 241.Extended-Type (TBD5). 3.2.1. Softwire46-Option-Code This attribute is used to convey an option code assigned to a Softwire46 mechanism [RFC8026]. This attribute is encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158]. The structure of Softwire46-Option-Code is shown below: TLV-Type 18 TLV-Length 6 octets Data Type The attribute Softwire46-Option-Code is of type integer (Section 3.1 of [RFC8044]). TLV-Value A 32-bit IANA-registered option code representing a Softwire46 mechanism (Softwire46-option-code). The codes and their corresponding Softwire46 mechanisms are listed in Section 7.3. Jiang, Ed., et al. Expires December 16, 2019 [Page 22] Internet-Draft A+P RADIUS Attributes June 2019 3.3. Softwire46-Multicast Attribute The Softwire46-Multicast Attribute conveys the IPv6 prefixes to be used to synthesize multicast and unicast IPv4-embedded IPv6 addresses as per [RFC8114]. This attribute is of type "tlv" and contains additional TLVs. The following requirements apply: The BNG SHALL use the IPv6 prefixes returned in the RADIUS Softwire46-Multicast Attribute to populate the DHCPv6 PREFIX64 Option [RFC8115]. This attribute MAY be used in Access-Request packets as a hint to the RADIUS server. For example, if the BNG is pre-configured for Softwire46-Multicast, these prefixes may be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the BNG, and it MAY assign a different Softwire46-Multicast Attribute. The Softwire46-Multicast Attribute MAY appear in an Access- Request, Access-Accept, CoA-Request, and Accounting-Request packet. The Softwire46-Multicast Attribute MUST NOT appear in any other RADIUS packet. The Softwire46-Multicast Attribute MAY contain ASM-Prefix64 (Section 3.3.1), SSM-Prefix64 (Section 3.3.2), and U-Prefix64 (Section 3.3.3). The Softwire46-Multicast Attribute MUST include ASM-Prefix64 or SSM-Prefix64, and it MAY include both. The U-Prefix64 MUST be present when SSM-Prefix64 is present. U-Prefix64 MAY be present when ASM-Prefix64 is present. The Softwire46-Multicast Attribute is structured as follows: Jiang, Ed., et al. Expires December 16, 2019 [Page 23] Internet-Draft A+P RADIUS Attributes June 2019 Type 241 (To be confirmed by IANA) 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 attributes. Extended-Type TBD6 Value This field contains a set of attributes as follows: ASM-Prefix64 This attribute contains the Any-Source Multicast (ASM) IPv6 prefix. Refer to Section 3.3.1. SSM-Prefix64 This attribute contains the Source-Source Multicast (SSM) IPv6 prefix. Refer to Section 3.3.2. U-Prefix64 This attribute contains the IPv4 prefix used for address translation. Refer to Section 3.3.3. The Softwire46-Multicast Attribute is associated with the following identifier: 241.Extended-Type(TBD6). 3.3.1. ASM-Prefix64 Attribute The ASM-Prefix64 attribute is structured as follows: TLV-Type 19 TLV-Length 16 octets. The length of asm-prefix64 must be /96 [RFC8115]. Data Type The attribute ASM-Prefix64 is of type ipv6prefix (Section 3.10 of [RFC8044]). TLV-Value This field specifies the IPv6 multicast prefix (asm-prefix64) to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the ASM mode. The conveyed multicast IPv6 prefix MUST belong to the ASM range. Jiang, Ed., et al. Expires December 16, 2019 [Page 24] Internet-Draft A+P RADIUS Attributes June 2019 3.3.2. SSM-Prefix64 Attribute The SSM-Prefix64 attribute is structured as follows: Type 20 TLV-Length 16 octets. The length of ssm-prefix64 must be /96 [RFC8115]. Data Type The attribute SSM-Prefix64 is of type ipv6prefix (Section 3.10 of [RFC8044]). TLV-Type This field specifies the IPv6 multicast prefix (ssm-prefix64) to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the SSM mode. The conveyed multicast IPv6 prefix MUST belong to the SSM range. 3.3.3. U-Prefix64 Attribute The structure of U-Prefix64 is shown below: TLV-Type 21 TLV-Length 4 + length of unicast-prefix. As specified in [RFC6052], the unicast-prefix prefix-length MUST be set to 32, 40, 48, 56, 64, or 96. Data Type The attribute U-Prefix64 is of type ipv6prefix (Section 3.10 of [RFC8044]). TLV-Value This field identifies the IPv6 unicast prefix (u-prefix64) to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. It may also be used to extract the IPv4 address from the received multicast data flows. 4. A Sample Configuration Process with RADIUS Figure 2 illustrates how the RADIUS and DHCPv6 protocols interwork to provide CE with softwire configuration information. Jiang, Ed., et al. Expires December 16, 2019 [Page 25] Internet-Draft A+P RADIUS Attributes June 2019 CE BNG AAA Server | | | |-------1.DHCPv6 Solicit------->| | |(ORO with unicast and/or m'cast| | | container option code(s)) | | | | | | |-------2.Access-Request------->| | | (Softwire46-Configuration | | | Attribute and/or | | |Softwire46-Multicast Attribute)| | | | | |<------3.Access-Accept---------| | | (Softwire46-Configuration | | | Attribute and/or | | |Softwire46-Multicast Attribute)| | | | |<----4.DHCPv6 Advertisement----| | | (container option(s)) | | | | | |-------5.DHCPv6 Request------>| | | (container Option(s)) | | | | | |<--------6.DHCPv6 Reply--------| | | (container option(s)) | | | | | DHCPv6 RADIUS Figure 2: Interaction between DHCPv6 and AAA Server with RADIUS authentication 1. The CE creates a DHCPv6 Solicit message. For unicast softwire configuration, the message includes an OPTION_REQUEST_OPTION (6) with the Softwire46 Container option code(s) as defined in [RFC7598]. OPTION_S46_CONT_MAPE (94) should be included for MAP- E, OPTION_S46_CONT_MAPT (95) for MAP-T, and OPTION_S46_CONT_LW (96) for Lightweight 4over6. For multicast configuration, the option number for OPTION_V6_PREFIX64 (113) is included in the client's ORO. The message is sent to the BNG. 2. On receipt of the Solicit message, the BNG constructs a RADIUS Access-Request message containing a User-Name Attribute (1) (containing either a CE MAC address, interface-id, or both), a User-Password Attribute (2) (with a pre-configured shared password between the CE and AAA server as defined in [RFC2865]). The Softwire46-Configuration Attribute and/or Softwire46-Multicast Attribute are also included (as requested by the client). The resulting message is sent to the AAA server. Jiang, Ed., et al. Expires December 16, 2019 [Page 26] Internet-Draft A+P RADIUS Attributes June 2019 3. The AAA server authenticates the request. If this is successful, and suitable configuration is available, an Access-Accept message is sent to the BNG containing the requested Softwire46-Configuration Attribute or Softwire46-Multicast Attribute. It is the responsibility of the AAA server to ensure the consistency of the provided configuration. 4. The BNG maps the received softwire configuration into the corresponding fields in the DHCPv6 softwire configuration option(s). These are included in the DHCPv6 Advertise message which is sent to the CE. 5. The CE sends a DHCPv6 Request message. In the ORO, the option code(s) of any of the required softwire options that were received in the Advertise message are included. 6. The BNG sends a DHCPv6 Reply message to the client containing the softwire container option(s) enumerated in the ORO. The authorization operation could be done independently, after the authentication process. In this case, steps 1-5 are completed as above, then the following steps are performed: 6a. When the BNG receives the DHCPv6 Request, it constructs a RADIUS Access-Request message, which contains a Service-Type Attribute (6) with the value "Authorize Only" (17), the corresponding Softwire46-Configuration Attribute, and a State Attribute obtained from the previous authentication process according to [RFC5080]. The resulting message is sent to the AAA server. 7a. The AAA checks the authorization request. If it is approved, an Access-Accept message is returned to the BNG with the corresponding Softwire46-Configuration Attribute. 8a. The BNG sends a Reply message to the client containing the softwire container options enumerated in the ORO. In addition to the above, the following points need to be considered: o In the configuration message flows described above the Message- Authenticator (type 80) [RFC2869] should be used to protect both Access-Request and Access-Accept messages. o If the BNG does not receive the corresponding Softwire46-Configuration Attribute in the Access-Accept message it may fall back to creating the DHCPv6 softwire configuration options using pre-configured Softwire46 configuration, if this is present. Jiang, Ed., et al. Expires December 16, 2019 [Page 27] Internet-Draft A+P RADIUS Attributes June 2019 o If the BNG receives an Access-Reject from the AAA server, then Softwire46 configuration must not be supplied to the client. o As specified in [RFC8415], Section 18.2.5, "Creation and Transmission of Rebind Messages", if the DHCPv6 server to which the DHCPv6 Renew message was sent at time T1 has not responded by time T2, the CE (DHCPv6 client) should enter the Rebind state and attempt to contact any available server. In this situation, a secondary BNG receiving the DHCPv6 message must initiate a new Access-Request message towards the AAA server. The secondary BNG includes the Softwire46-Configuration Attribute in this Access- Request message. o For Lightweight 4over6, the CE's binding state needs to be synchronized between the clients and the Lightweight AFTR (lwAFTR)/BR. This can be achieved in two ways: static pre- configuration of the bindings on both the AAA server and lwAFTR, or on-demand whereby the AAA server updates the lwAFTR with the CE's binding state as it is created or deleted. In some deployments, the DHCP server may use the Accounting-Request to report to a AAA server the softwire configuration returned to a requesting host. It is the responsibility of the DHCP server to ensure the consistency of the configuration provided to requesting hosts. Reported data to a AAA server may be required for various operational purposes (e.g., regulatory). A configuration change (e.g., BR address) may result in an exchange of CoA-Requests between the BNG and the AAA server as shown in Figure 3. Concretely, when the BNG receives a CoA-Request message containing Softwire46 attributes, it sends a DHCPv6 Reconfigure message to the appropriate CE to inform that CE that an updated configuration is available. Upon receipt of such message, the CE sends a DHCPv6 Renew or Information-Request in order to receive the updated Softwire46 configuration. In deployments where the BNG embeds a DHCPv6 relay, CoA-Requests can be used following the procedure specified in [RFC6977]. Jiang, Ed., et al. Expires December 16, 2019 [Page 28] Internet-Draft A+P RADIUS Attributes June 2019 CE BNG AAA Server | | | |---DHCPv6 Solicit--------->| | | |---Access-Request---------->| | |<--Access-Accept------------| | |(Softwire46-Configuration | | | Attribute ...) | .... | | | | |<-----CoA-Request-----------| | |(Softwire46-Configuration | | | Attribute ...) | | |------CoA-Response--------->| |<--DHCPv6 Reconfigure------| | | | | .... Figure 3: Change of Configuration Example 5. Table of Attributes This document specifies three new RADIUS attributes, and their formats are as follows: o Softwire46-Configuration Attribute: 241.TBD1 o Softwire46-Priority Attribute: 241.TBD5 o Softwire46-Multicast Attribute: 241.TBD6 Table 3 describes which attributes may be found, in which kinds of packets and in what quantity. Request Accept Reject Challenge Acct CoA- # Attribute Req Req 0-1 0-1 0 0 0-1 0-1 241.TBD1 Softwire46- Configuration 0-1 0-1 0 0 0-1 0-1 241.TBD5 Softwire46- Priority 0-1 0-1 0 0 0-1 0-1 241.TBD6 Softwire46- Multicast Table 3: Table of Attributes Jiang, Ed., et al. Expires December 16, 2019 [Page 29] Internet-Draft A+P RADIUS Attributes June 2019 6. Security Considerations Section 9 of [RFC7596] discusses security issues related to Lightweight 4over6, Section 10 of [RFC7597] discusses security issues related to MAP-E, Section 13 of [RFC7599] discusses security issues related to MAP-T, and Section 9 of [RFC8114] discusses security issues related to the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. This document does not introduce any security issues inherently different from those already identified in Section 8 of [RFC2865] and Section 6 of [RFC5176] for CoA messages. Known security vulnerabilities of the RADIUS protocol discussed in Section 7 of [RFC2607] and Section 7 of [RFC2869] apply to this specification. These well-established properties of the RADIUS protocol place some limitations on how it can safely be used, since there is some inherent requirement to trust the counterparty to not misbehave. Accordingly, 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]. The use of IPsec [RFC4301] for providing security when RADIUS is carried in IPv6 is discussed in [RFC3162]. Security considerations for interactions between a Softwire46 CE and the BNG are discussed in Section 9 of [RFC7598] (DHCPv6 options for configuration of softwire46 address and port-mapped clients), Section 3 of [RFC8026] (DHCPv6-based Softwire46 prioritization mechanism), and Section 5 of [RFC8115] (DHCPv6 options for configuration of IPv4-embedded IPv6 prefixes). 7. IANA Considerations IANA is requested to make new code point assignments for RADIUS attributes as described in the following subsections. The assignments should use the RADIUS registry available at https://www.iana.org/assignments/radius-types/. 7.1. New RADIUS Attributes This document requests IANA to assign the Attribute Types defined in this document from the RADIUS namespace as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC8126]. This document requests that IANA register three new RADIUS attributes, from the "Short Extended Space" of [RFC6929]. The Jiang, Ed., et al. Expires December 16, 2019 [Page 30] Internet-Draft A+P RADIUS Attributes June 2019 attributes are: Softwire46-Configuration Attribute, Softwire46-Priority Attribute, and Softwire46-Multicast Attribute: Type Description Data Type Reference ---- ----------- --------- --------- 241.TBD1 Softwire46-Configuration tlv Section 3.1 241.TBD5 Softwire46-Priority tlv Section 3.2 241.TBD6 Softwire46-Multicast tlv Section 3.3 7.2. RADIUS Softwire46 Configuration and Multicast Attributes IANA is requested to create a new registry called "RADIUS Softwire46 Configuration and Multicast Attributes". All attributes in this registry have one or more parent RADIUS attributes in nesting (refer to [RFC6929]). This registry must be initially populated with the following values: Value Description Data Type Reference ----- ----------- --------- --------- 0 Reserved 1 Softwire46-MAP-E tlv Section 3.1.1.1 2 Softwire46-MAP-T tlv Section 3.1.1.2 3 Softwire46-Lightweight-4over6 tlv Section 3.1.1.3 4 Softwire46-Rule (BMR) tlv Section 3.1.3.1 5 Softwire46-Rule (FMR) tlv Section 3.1.3.1 6 Softwire46-BR ipv6addr Section 3.1.3.2 7 Softwire46-DMR ipv6prefix Section 3.1.3.3 8 Softwire46-V4V6Bind tlv Section 3.1.3.4 9 Softwire46-PORTPARAMS tlv Section 3.1.3.5 10 Rule-IPv6-Prefix ipv6prefix Section 3.1.4.1 11 Rule-IPv4-Prefix ipv4prefix Section 3.1.4.2 12 EA-Length integer Section 3.1.4.3 13 IPv4-Address ipv4addr Section 3.1.5.1 14 Bind-IPv6-Prefix ipv6prefix Section 3.1.5.2 15 PSID-Offset integer Section 3.1.6.1 16 PSID-Len integer Section 3.1.6.2 17 PSID integer Section 3.1.6.3 18 Softwire46-Option-Code integer Section 3.2.1 19 ASM-Prefix64 ipv6prefix Section 3.3.1 20 SSM-Prefix64 ipv6prefix Section 3.3.2 21 U-Prefix64 ipv6prefix Section 3.3.3 22-255 Unassigned The registration procedure for this registry is Standards Action as defined in [RFC8126]. Jiang, Ed., et al. Expires December 16, 2019 [Page 31] Internet-Draft A+P RADIUS Attributes June 2019 7.3. Softwire46 Mechanisms and Their Identifying Option Codes The Softwire46-Priority Attribute conveys an ordered list of option codes assigned to Softwire46 mechanisms, for which IANA is requested to create and maintain a new registry entitled "Option Codes Permitted in the Softwire46-Priority Attribute". Table 4 shows the initial version of allowed option codes, and the Softwire46 mechanisms that they represent. The option code for DS- Lite is derived from the IANA allocated RADIUS Attribute Type value for DS-Lite [RFC6519]. The option codes for MAP-E, MAP-T, and Lightweight 4over6 are the TLV-Type values for the MAP-E, MAP-T, and Lightweight 4over6 attributes defined in Section 3.1.1. +-----------+--------------------+-----------+ |Option Code|Softwire46 Mechanism| Reference | +-----------+--------------------+-----------+ | 1 | MAP-E | RFC7597 | | 2 | MAP-T | RFC7599 | | 3 | Lightweight 4over6 | RFC7596 | | 144 | DS-Lite | RFC6519 | +-----------+--------------------+-----------+ Table 4: Option Codes to S46 Mechanisms Additional option codes may be added to this list in the future using the IETF Review process described in Section 4.8 of [RFC8126]. 8. Contributing Authors Bing Liu Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: leo.liubing@huawei.com Peter Deacon IEA Software, Inc. P.O. Box 1170 Veradale, WA 99037 USA Email: peterd@iea-software.com Qiong Sun China Telecom Jiang, Ed., et al. Expires December 16, 2019 [Page 32] Internet-Draft A+P RADIUS Attributes June 2019 Beijing China Email: sunqiong@ctbri.com.cn Qi Sun Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: sunqibupt@gmail.com Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 Email: cathy.zhou@huawei.com Tina Tsou Huawei Technologies(USA) 2330 Central Expressway Santa Clara, CA 95050 USA Email: Tina.Tsou.Zouting@huawei.com ZiLong Liu Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: liuzilong8266@126.com Yong Cui Tsinghua University Beijing 100084 P.R.China Phone: +86-10-62603059 Email: yong@csnet1.cs.tsinghua.edu.cn Jiang, Ed., et al. Expires December 16, 2019 [Page 33] Internet-Draft A+P RADIUS Attributes June 2019 9. Acknowledgements The authors would like to thank the valuable comments made by Peter Lothberg, Wojciech Dec, Ian Farrer, Suresh Krishnan, Qian Wang, Wei Meng, Cui Wang, Alan Dekok, Stefan Winter, and Yu Tianpeng to this document. This document was merged with [I-D.sun-softwire-lw4over6-radext] and [I-D.wang-radext-multicast-radius-ext], thanks to everyone who contributed to this document. This document was produced using the xml2rfc tool [RFC7991]. Many thanks to Al Morton, Bernie Volz, Joel Halpern, and Donald Eastlake for the review. 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, . [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, . [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, DOI 10.17487/RFC3162, August 2001, . [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, DOI 10.17487/RFC3575, July 2003, . [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, . Jiang, Ed., et al. Expires December 16, 2019 [Page 34] Internet-Draft A+P RADIUS Attributes June 2019 [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, . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, . [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, . [RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, November 2016, . [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, DOI 10.17487/RFC8044, January 2017, . [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . Jiang, Ed., et al. Expires December 16, 2019 [Page 35] Internet-Draft A+P RADIUS Attributes June 2019 10.2. Informative References [I-D.sun-softwire-lw4over6-radext] Xie, C., Sun, Q., Qiong, Q., Zhou, C., Tsou, T., and Z. Liu, "Radius Extension for Lightweight 4over6", draft-sun- softwire-lw4over6-radext-01 (work in progress), March 2014. [I-D.wang-radext-multicast-radius-ext] Wang, Q., Meng, W., Wang, C., and M. Boucadair, "RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", draft-wang-radext-multicast-radius-ext-00 (work in progress), December 2015. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, DOI 10.17487/RFC2607, June 1999, . [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [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, . [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, . [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February 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, . Jiang, Ed., et al. Expires December 16, 2019 [Page 36] Internet-Draft A+P RADIUS Attributes June 2019 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 Reconfiguration from Relay Agents", RFC 6977, DOI 10.17487/RFC6977, July 2013, . [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, . [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, . [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, . [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, . [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, . [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network", RFC 8114, DOI 10.17487/RFC8114, March 2017, . Appendix A. DHCPv6 to RADIUS Field Mappings The following sections detail the mappings between the softwire DHCPv6 option fields and the relevant RADIUS attributes as defined in this document. A.1. OPTION_S46_RULE (89) to Softwire46-Rule Sub-TLV Field Mappings Jiang, Ed., et al. Expires December 16, 2019 [Page 37] Internet-Draft A+P RADIUS Attributes June 2019 +---------------------+----------------------+----------------------+ | OPTION_S46_RULE | Softwire46-Rule Name | TLV Subfield | | Field | | | +---------------------+----------------------+----------------------+ | flags | N/A | TLV-type (TBD7, | | | | TBD8) | | ea-len | EA-Length | EA-len | | prefix4-len | Rule-IPv4-Prefix | Prefix-Length | | ipv4-prefix | Rule-IPv4-Prefix | rule-ipv4-prefix | | prefix6-len | Rule-IPv6-Prefix | Prefix-Length | | ipv6-prefix | Rule-IPv6-Prefix | rule-ipv6-prefix | +---------------------+----------------------+----------------------+ A.2. OPTION_S46_BR (90) to Softwire46-BR Field Mappings +---------------------+------------------------+ | OPTION_S46_BR Field | Softwire46-BR Subfield | +---------------------+------------------------+ | br-ipv6-address | br-ipv6-address | +---------------------+------------------------+ A.3. OPTION_S46_DMR (91) to Softwire46-DMR +---------------------+-------------------------+ | OPTION_S46_BR Field | Softwire46-DMR Subfield | +---------------------+-------------------------+ | dmr-prefix6-len | dmr-prefix6-len | | dmr-ipv6-prefix | dmr-ipv6-prefix | +---------------------+-------------------------+ A.4. OPTION_S46_V4V6BIND (92) to Softwire46-V4V6Bind +-----------------------+------------------------+------------------+ | OPTION_S46_V4V6BIND | Softwire46-V4V6Bind | TLV Subfield | | Field | Name | | +-----------------------+------------------------+------------------+ | ipv4-address | IPv4-Address | ipv4-address | | bindprefix6-len | Bind-IPv6-Prefix | Prefix-Length | | bind-ipv6-prefix | Bind-IPv6-Prefix | bind-ipv6-prefix | +-----------------------+------------------------+------------------+ A.5. OPTION_S46_PORTPARAMS (93) to Softwire46-PORTPARAMS Field Mappings Jiang, Ed., et al. Expires December 16, 2019 [Page 38] Internet-Draft A+P RADIUS Attributes June 2019 +--------------------------+--------------------------+-------------+ | OPTION_S46_PORTPARAMS | Softwire46-PORTPARAMS | TLV | | Field | Name | Subfield | +--------------------------+--------------------------+-------------+ | offset | PSID-Offset | PSID-Offset | | PSID-len | PSID-Len | PSID-len | | PSID | PSID | PSID | +--------------------------+--------------------------+-------------+ A.6. OPTION_S46_PRIORITY (111) to Softwire46-PORTPARAMS Field Mappings +---------------------------+---------------------------------------+ | OPTION_S46_PRIORITY Field | Softwire46-Priority Attribute | | | Subfield | +---------------------------+---------------------------------------+ | s46-option-code | Softwire46-option-code | +---------------------------+---------------------------------------+ A.7. OPTION_V6_PREFIX64 (113) to Softwire46-Multicast Attribute Field Mappings +--------------------+------------------------------+---------------+ | OPTION_V6_PREFIX64 | Softwire46-Multicast | TLV Subfield | | Field | Attribute TLV Name | | +--------------------+------------------------------+---------------+ | asm-length | ASM-Prefix64 | Prefix-Length | | ASM_mPrefix64 | ASM-Prefix64 | asm-prefix64 | | ssm-length | SSM-Prefix64 | Prefix-Length | | SSM_mPrefix64 | SSM-Prefix64 | ssm-prefix64 | | unicast-length | U-Prefix64 | Prefix-Length | | uPrefix64 | U-Prefix64 | u-prefix64 | +--------------------+------------------------------+---------------+ Authors' Addresses Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Jiang, Ed., et al. Expires December 16, 2019 [Page 39] Internet-Draft A+P RADIUS Attributes June 2019 Yu Fu CNNIC No.4 South 4th Street, Zhongguancun Hai-Dian District, Beijing, 100190 P.R. China Email: eleven711711@foxmail.com Chongfeng Xie China Telecom Beijing P.R. China Email: xiechf.bri@chinatelecom.cn Tianxiang Li Tsinghua University Beijing 100084 P.R.China Email: peter416733@gmail.com Mohamed Boucadair (editor) Orange Rennes, 35000 France Email: mohamed.boucadair@orange.com Jiang, Ed., et al. Expires December 16, 2019 [Page 40] ./draft-ietf-spring-segment-routing-central-epe-10.txt0000644000764400076440000010532313216751155022207 0ustar iustyiusty Network Working Group C. Filsfils, Ed. Internet-Draft S. Previdi Intended status: Informational G. Dawra, Ed. Expires: June 24, 2018 Cisco Systems, Inc. E. Aries Juniper Networks D. Afanasiev Yandex December 21, 2017 Segment Routing Centralized BGP Egress Peer Engineering draft-ietf-spring-segment-routing-central-epe-10 Abstract Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction topological or service-based. SR allows to enforce a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols. This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software Defined Network, SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. 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 https://datatracker.ietf.org/drafts/current/. Filsfils, et al. Expires June 24, 2018 [Page 1] Internet-Draft Segment Routing Centralized EPE December 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 June 24, 2018. 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 (https://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. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 3. Distribution of Topology and TE Information using BGP-LS . . 6 3.1. PeerNode SID to D . . . . . . . . . . . . . . . . . . . . 7 3.2. PeerNode SID to E . . . . . . . . . . . . . . . . . . . . 7 3.3. PeerNode SID to F . . . . . . . . . . . . . . . . . . . . 8 3.4. First PeerAdj to F . . . . . . . . . . . . . . . . . . . 8 3.5. Second PeerAdj to F . . . . . . . . . . . . . . . . . . . 9 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 4. BGP-EPE Controller . . . . . . . . . . . . . . . . . . . . . 10 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 5.3. At a Router - BGP Labeled Unicast route (RFC8277) . . . . 14 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15 Filsfils, et al. Expires June 24, 2018 [Page 2] Internet-Draft Segment Routing Centralized EPE December 2017 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The document is structured as follows: o Section 1 states the BGP-EPE problem statement and provides the key references. o Section 2 defines the different BGP Peering Segments and the semantic associated to them. o Section 3 describes the automated allocation of BGP Peering Segment-IDs (SIDs) by the BGP-EPE enabled egress border router and the automated signaling of the external peering topology and the related BGP Peering SID's to the collector [I-D.ietf-idr-bgpls-segment-routing-epe]. o Section 4 overviews the components of a centralized BGP-EPE controller. The definition of the BGP-EPE controller is outside the scope of this document. o Section 5 overviews the methods that could be used by the centralized BGP-EPE controller to implement a BGP-EPE policy at an ingress border router or at a source host within the domain. The exhaustive definition of all the means to program an BGP-EPE input policy is outside the scope of this document. For editorial reasons, the solution is described with IPv6 addresses and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS SIDs and also to IPv6 with native IPv6 SIDs. 1.1. Problem Statement The BGP-EPE problem statement is defined in [RFC7855]. A centralized controller should be able to instruct an ingress Provider Edge router (PE) or a content source within the domain to Filsfils, et al. Expires June 24, 2018 [Page 3] Internet-Draft Segment Routing Centralized EPE December 2017 use a specific egress PE and a specific external interface/neighbor to reach a particular destination. Let's call this solution "BGP-EPE" for "BGP Egress Peer Engineering". The centralized controller is called the "BGP-EPE Controller". The egress border router where the BGP-EPE traffic steering functionality is implemented is called a BGP-EPE enabled border router. The input policy programmed at an ingress border router or at a source host is called a BGP-EPE policy. The requirements that have motivated the solution described in this document are listed here below: o The solution MUST apply to the Internet use-case where the Internet routes are assumed to use IPv4 unlabeled or IPv6 unlabeled. It is not required to place the Internet routes in a VRF and allocate labels on a per route, or on a per-path basis. o The solution MUST support any deployed iBGP schemes (RRs, confederations or iBGP full meshes). o The solution MUST be applicable to both routers with external and internal peers. o The solution should minimize the need for new BGP capabilities at the ingress PEs. o The solution MUST accommodate an ingress BGP-EPE policy at an ingress PE or directly at a source within the domain. o The solution MAY support automated Fast Reroute (FRR) and fast convergence mechanisms. The following reference diagram is used throughout this document. +---------+ +------+ | | | | | H B------D G | | +---/| AS 2 |\ +------+ | |/ +------+ \ | |---L/8 A AS1 C---+ \| | | |\\ \ +------+ /| AS 4 |---M/8 | | \\ +-E |/ +------+ | X | \\ | K | | +===F AS 3 | +---------+ +------+ Figure 1: Reference Diagram Filsfils, et al. Expires June 24, 2018 [Page 4] Internet-Draft Segment Routing Centralized EPE December 2017 IP addressing: o C's interface to D: 2001:db8:cd::c/64, D's interface: 2001:db8:cd::d/64 o C's interface to E: 2001:db8:ce::c/64, E's interface: 2001:db8:ce::e/64 o C's upper interface to F: 2001:db8:cf1::c/64, F's interface: 2001:db8:cf1::f/64 o C's lower interface to F: 2001:db8:cf2::c/64, F's interface: 2001:db8:cf2::f/64 o BGP router-ID of C: 192.0.2.3 o BGP router-ID of D: 192.0.2.4 o BGP router-ID of E: 192.0.2.5 o BGP router-ID of F: 192.0.2.6 o Loopback of F used for eBGP multi-hop peering to C: 2001:db8:f::f/128 o C's loopback is 2001:db8:c::c/128 with SID 64 C's BGP peering: o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) o Single-hop eBGP peering with neighbor 2001:db8:ce::e (E) o Multi-hop eBGP peering with F on IP address 2001:db8:f::f (F) C's resolution of the multi-hop eBGP session to F: o Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f o Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f C is configured with local policy that defines a BGP PeerSet as the set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F) X is the BGP-EPE controller within AS1 domain. H is a content source within AS1 domain. Filsfils, et al. Expires June 24, 2018 [Page 5] Internet-Draft Segment Routing Centralized EPE December 2017 2. BGP Peering Segments As defined in [I-D.ietf-spring-segment-routing], certain segments are defined by a BGP-EPE capable node and corresponding to its attached peers. These segments are called BGP peering segments or BGP Peering SIDs. They enable the expression of source-routed inter-domain paths. An ingress border router of an AS may compose a list of segments to steer a flow along a selected path within the AS, towards a selected egress border router C of the AS and through a specific peer. At minimum, a BGP Egress Peering Engineering policy applied at an ingress EPE involves two segments: the Node SID of the chosen egress EPE and then the BGP Peering Segment for the chosen egress EPE peer or peering interface. [I-D.ietf-spring-segment-routing] defines three types of BGP peering segments/SIDs: PeerNode SID, PeerAdj SID and PeerSet SID. A Peer Node Segment is a segment describing a peer, including the SID (PeerNode SID) allocated to it. A Peer Adjacency Segment is a segment describing a link, including the SID (PeerAdj SID) allocated to it. A Peer Set Segment is a segment describing a link or a node that is part of the set, including the SID (PeerSet SID) allocated to the set. 3. Distribution of Topology and TE Information using BGP-LS In ships-in-the-night mode with respect to the pre-existing iBGP design, a BGP-LS [RFC7752] session is established between the BGP-EPE enabled border router and the BGP-EPE controller. As a result of its local configuration and according to the behavior described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C allocates the following BGP Peering Segments ([I-D.ietf-spring-segment-routing]): o A PeerNode segment for each of its defined peer (D: 1012, E: 1022 and F: 1052). o A PeerAdj segment for each recursing interface to a multi-hop peer (e.g.: the upper and lower interfaces from C to F in figure 1). Filsfils, et al. Expires June 24, 2018 [Page 6] Internet-Draft Segment Routing Centralized EPE December 2017 o A PeerSet segment to the set of peers (E and F). In this case the PeerSet represents a set of peers (E, F) belonging to the same AS (AS 3). C programs its forwarding table accordingly: Incoming Outgoing Label Operation Interface ------------------------------------ 1012 POP link to D 1022 POP link to E 1032 POP upper link to F 1042 POP lower link to F 1052 POP load balance on any link to F 1060 POP load balance on any link to E or to F C signals the related BGP-LS NLRI's to the BGP-EPE controller. Each such BGP-LS route is described in the following subsections according to the encoding details defined in [I-D.ietf-idr-bgpls-segment-routing-epe]. 3.1. PeerNode SID to D Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cd::c, 2001:db8:cd::d Attributes: o PeerNode SID: 1012 3.2. PeerNode SID to E Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:ce::c, 2001:db8:ce::e Filsfils, et al. Expires June 24, 2018 [Page 7] Internet-Draft Segment Routing Centralized EPE December 2017 Attributes: o PeerNode SID: 1022 o PeerSetSID: 1060 o Link Attributes: see section 3.3.2 of [RFC7752] 3.3. PeerNode SID to F Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:c::c, 2001:db8:f::f Attributes: o PeerNode SID: 1052 o PeerSetSID: 1060 3.4. First PeerAdj to F Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cf1::c, 2001:db8:cf1::f Attributes: o PeerAdj-SID: 1032 o LinkAttributes: see section 3.3.2 of [RFC7752] Filsfils, et al. Expires June 24, 2018 [Page 8] Internet-Draft Segment Routing Centralized EPE December 2017 3.5. Second PeerAdj to F Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3 , AS1 o Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cf2::c, 2001:db8:cf2::f Attributes: o PeerAdj-SID: 1042 o LinkAttributes: see section 3.3.2 of [RFC7752] 3.6. Fast Reroute (FRR) A BGP-EPE enabled border router MAY allocate a FRR backup entry on a per BGP Peering SID basis. One example is as follows: o PeerNode SID 1. If multi-hop, backup via the remaining PeerADJ SIDs (if available) to the same peer. 2. Else backup via another PeerNode SID to the same AS. 3. Else pop the PeerNode SID and perform an IP lookup. o PeerAdj SID 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs (if available) to the same peer. 2. Else backup via a PeerNode SID to the same AS. 3. Else pop the PeerNode SID and perform an IP lookup. o PeerSet SID 1. Backup via remaining PeerNode SIDs in the same PeerSet. 2. Else pop the PeerNode SID and IP lookup. Filsfils, et al. Expires June 24, 2018 [Page 9] Internet-Draft Segment Routing Centralized EPE December 2017 Let's illustrate different types of possible backups using the reference diagram and considering the Peering SIDs allocated by C. PeerNode SID 1052, allocated by C for peer F: o Upon the failure of the upper connected link CF, C can reroute all the traffic onto the lower CF link to the same peer (F). PeerNode SID 1022, allocated by C for peer E: o Upon the failure of the connected link CE, C can reroute all the traffic onto the link to PeerNode SID 1052 (F). PeerNode SID 1012, allocated by C for peer D: o Upon the failure of the connected link CD, C can pop the PeerNode SID and lookup the IP destination address in its FIB and route accordingly. PeerSet SID 1060, allocated by C for the set of peers E and F: o Upon the failure of a connected link in the group, the traffic to PeerSet SID 1060 is rerouted on any other member of the group. For specific business reasons, the operator might not want the default FRR behavior applied to a PeerNode SID or any of its dependent PeerADJ SID. The operator should be able to associate a specific backup PeerNode SID for a PeerNode SID: e.g., 1022 (E) must be backed up by 1012 (D) which overrules the default behavior which would have preferred F as a backup for E. 4. BGP-EPE Controller In this section, Let's provide a non-exhaustive set of inputs that a BGP-EPE controller would likely collect such as to perform the BGP- EPE policy decision. The exhaustive definition is outside the scope of this document. 4.1. Valid Paths From Peers The BGP-EPE controller should collect all the BGP paths (i.e.: IP destination prefixes) advertised by all the BGP-EPE enabled border router. Filsfils, et al. Expires June 24, 2018 [Page 10] Internet-Draft Segment Routing Centralized EPE December 2017 This could be realized by setting an iBGP session with the BGP-EPE enabled border router, with the router configured to advertise all paths using BGP add-path [RFC7911] and the original next-hop preserved. In this case, C would advertise the following Internet routes to the BGP-EPE controller: o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:cd::d, AS Path {AS 2, 4} * X (i.e.: the BGP-EPE controller) knows that C receives a path to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2. o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:ce::e, AS Path {AS 3, 4} * X knows that C receives a path to 2001:db8:abcd::/48 via neighbor 2001:db8:ce::e of AS2. o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:f::f, AS Path {AS 3, 4} * X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3 via neighbor 2001:db8:f::f An alternative option would be for a BGP-EPE collector to use BGP Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP- EPE enabled border routers. 4.2. Intra-Domain Topology The BGP-EPE controller should collect the internal topology and the related IGP SIDs. This could be realized by collecting the IGP LSDB of each area or running a BGP-LS session with a node in each IGP area. 4.3. External Topology Thanks to the collected BGP-LS routes described in section 2, the BGP-EPE controller is able to maintain an accurate description of the egress topology of node C. Furthermore, the BGP-EPE controller is able to associate BGP Peering SIDs to the various components of the external topology. Filsfils, et al. Expires June 24, 2018 [Page 11] Internet-Draft Segment Routing Centralized EPE December 2017 4.4. SLA characteristics of each peer The BGP-EPE controller might collect SLA characteristics across peers. This requires an BGP-EPE solution as the SLA probes need to be steered via non-best-path peers. Unidirectional SLA monitoring of the desired path is likely required. This might be possible when the application is controlled at the source and the receiver side. Unidirectional monitoring dissociates the SLA characteristic of the return path (which cannot usually be controlled) from the forward path (the one of interest for pushing content from a source to a consumer and the one which can be controlled). Alternatively, Extended Metrics, as defined in [RFC7810] could also be advertised using BGP-LS ([I-D.ietf-idr-te-pm-bgp]). 4.5. Traffic Matrix The BGP-EPE controller might collect the traffic matrix to its peers or the final destinations. IPFIX [RFC7011] is a likely option. An alternative option consists in collecting the link utilization statistics of each of the internal and external links, also available in the current definition of [RFC7752]. 4.6. Business Policies The BGP-EPE controller should be configured or collect business policies through any desired mechanisms. These mechanisms by which these policies are configured or collected are outside the scope of this document. 4.7. BGP-EPE Policy On the basis of all these inputs (and likely others), the BGP-EPE Controller decides to steer some demands away from their best BGP path. The BGP-EPE policy is likely expressed as a two-entry segment list where the first element is the IGP prefix SID of the selected egress border router and the second element is a BGP Peering SID at the selected egress border router. A few examples are provided hereafter: o Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the SID of PE C as defined in Section 1.1. Filsfils, et al. Expires June 24, 2018 [Page 12] Internet-Draft Segment Routing Centralized EPE December 2017 o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:ce::e, {64, 1022}. o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f, {64, 1052}. o Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f of multi-hop eBGP peer 2001:db8:f::f, {64, 1042}. o Prefer egress PE C and any interface to any peer in the group 1060: {64, 1060}. Note that the first SID could be replaced by a list of segments. This is useful when an explicit path within the domain is required for traffic engineering purposes. For example, if the Prefix SID of node B is 60 and the BGP-EPE controller would like to steer the traffic from A to C via B then through the external link to peer D then the segment list would be {60, 64, 1012}. 5. Programming an input policy The detailed/exhaustive description of all the means to implement an BGP-EPE policy are outside the scope of this document. A few examples are provided in this section. 5.1. At a Host A static IP/MPLS route can be programmed at the host H. The static route would define a destination prefix, a next-hop and a label stack to push. Assuming a global SRGB, at least on all access routers connecting the hosts, the same policy can be programmed across all hosts, which is convenient. 5.2. At a router - SR Traffic Engineering tunnel The BGP-EPE controller can configure the ingress border router with an SR traffic engineering tunnel T1 and a steering-policy S1 which causes a certain class of traffic to be mapped on the tunnel T1. The tunnel T1 would be configured to push the required segment list. The tunnel and the steering policy could be configured via multiple means. A few examples are given below: o PCEP according to [I-D.ietf-pce-segment-routing] and [I-D.ietf-pce-pce-initiated-lsp]. o Netconf ([RFC6241]). Filsfils, et al. Expires June 24, 2018 [Page 13] Internet-Draft Segment Routing Centralized EPE December 2017 o Other static or ephemeral APIs Example: at router A (Figure 1). Tunnel T1: push {64, 1042} IP route L/8 set next-hop T1 5.3. At a Router - BGP Labeled Unicast route (RFC8277) The BGP-EPE Controller could build a BGP Labeled Unicast route [RFC8277]) route (from scratch) and send it to the ingress router: o NLRI: the destination prefix to engineer: e.g., L/8. o Next-Hop: the selected egress border router: C. o Label: the selected egress peer: 1042. o AS path: reflecting the selected valid AS path. o Some BGP policy to ensure it will be selected as best by the ingress router. Note that as discussed in RFC 8277 section 5, the comparison of labeled and unlabeled unicast BGP route is implementation dependent and hence may require an implementation specific policy on each ingress router. This BGP Labeled unicast route (RFC8277) "overwrites" an equivalent or less-specific "best path". As the best-path is changed, this BGP- EPE input policy option may influence the path propagated to the upstream peer/customers. Indeed, implementations treating the SAFI-1 and SAFI-4 routes for a given prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 route to their BGP upstream peers. 5.4. At a Router - VPN policy route The BGP-EPE Controller could build a VPNv4 route (from scratch) and send it to the ingress router: o NLRI: the destination prefix to engineer: e.g., L/8. o Next-Hop: the selected egress border router: C. o Label: the selected egress peer: 1042. o Route-Target: selecting the appropriate VRF at the ingress router. o AS path: reflecting the selected valid AS path. Filsfils, et al. Expires June 24, 2018 [Page 14] Internet-Draft Segment Routing Centralized EPE December 2017 o Some BGP policy to ensure it will be selected as best by the ingress router in the related VRF. The related VRF must be preconfigured. A VRF fallback to the main FIB might be beneficial to avoid replicating all the "normal" Internet paths in each VRF. 6. IPv6 Dataplane The described solution is applicable to IPv6, either with MPLS-based or IPv6-Native segments. In both cases, the same three steps of the solution are applicable: o BGP-LS-based signaling of the external topology and BGP Peering Segments to the BGP-EPE controller. o Collection of various inputs by the BGP-EPE controller to come up with a policy decision. o Programming at an ingress router or source host of the desired BGP-EPE policy which consists in a list of segments to push on a defined traffic class. 7. Benefits The BGP-EPE solutions described in this document have the following benefits: o No assumption on the iBGP design within AS1. o Next-Hop-Self on the Internet routes propagated to the ingress border routers is possible. This is a common design rule to minimize the number of IGP routes and to avoid importing external churn into the internal routing domain. o Consistent support for traffic engineering within the domain and at the external edge of the domain. o Support both host and ingress border router BGP-EPE policy programming. o BGP-EPE functionality is only required on the BGP-EPE enabled egress border router and the BGP-EPE controller: an ingress policy can be programmed at the ingress border router without any new functionality. Filsfils, et al. Expires June 24, 2018 [Page 15] Internet-Draft Segment Routing Centralized EPE December 2017 o Ability to deploy the same input policy across hosts connected to different routers (assuming the global property of IGP prefix SIDs). 8. IANA Considerations This document does not request any IANA allocations. 9. Manageability Considerations The BGP-EPE use-case described in this document requires BGP-LS ([RFC7752]) extensions that are described in [I-D.ietf-idr-bgpls-segment-routing-epe]. The required extensions consists of additional BGP-LS descriptors and TLVs that will follow the same. Manageability functions of BGP-LS, described in [RFC7752] also apply to the extensions required by the EPE use-case. Additional Manageability considerations are described in [I-D.ietf-idr-bgpls-segment-routing-epe]. 10. Security Considerations [RFC7752] defines BGP-LS NLRIs and their associated security aspects. [I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS extensions required by the BGP-EPE mechanisms described in this document. BGP-EPE BGP-LS extensions also include the related security. 11. Contributors Daniel Ginsburg substantially contributed to the content of this document. 12. Acknowledgements The authors would like to thank Acee Lindem for his comments and contribution. 13. References 13.1. Normative References [I-D.ietf-idr-bgpls-segment-routing-epe] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", draft-ietf-idr-bgpls-segment-routing- epe-14 (work in progress), December 2017. Filsfils, et al. Expires June 24, 2018 [Page 16] Internet-Draft Segment Routing Centralized EPE December 2017 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-14 (work in progress), December 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . 13.2. Informative References [I-D.ietf-idr-te-pm-bgp] Ginsberg, L., Previdi, S., Wu, Q., Gredler, H., Ray, S., Tantsura, J., and C. Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions", draft-ietf-idr-te-pm-bgp-08 (work in progress), August 2017. [I-D.ietf-pce-pce-initiated-lsp] 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-11 (work in progress), October 2017. [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-11 (work in progress), November 2017. [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, . [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, . Filsfils, et al. Expires June 24, 2018 [Page 17] Internet-Draft Segment Routing Centralized EPE December 2017 [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, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . Authors' Addresses Clarence Filsfils (editor) Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Stefano Previdi Cisco Systems, Inc. Italy Email: stefano@previdi.net Gaurav Dawra (editor) Cisco Systems, Inc. USA Email: gdawra.ietf@gmail.com Filsfils, et al. Expires June 24, 2018 [Page 18] Internet-Draft Segment Routing Centralized EPE December 2017 Ebben Aries Juniper Networks 1133 Innovation Way Sunnyvale CA 94089 US Email: exa@juniper.net Dmitry Afanasiev Yandex RU Email: fl0w@yandex-team.ru Filsfils, et al. Expires June 24, 2018 [Page 19] ./draft-ietf-spring-segment-routing-ldp-interop-15.txt0000644000764400076440000013617713343052557022266 0ustar iustyiusty Network Working Group A. Bashandy, Ed. Internet-Draft Individual Intended status: Standards Track C. Filsfils, Ed. Expires: March 6, 2019 S. Previdi Cisco Systems, Inc. B. Decraene S. Litkowski Orange September 02, 2018 Segment Routing interworking with LDP draft-ietf-spring-segment-routing-ldp-interop-15 Abstract A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. 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 https://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 Bashandy, et al. Expires March 6, 2019 [Page 1] Internet-Draft Segment Routing and LDP September 2018 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 6, 2019. Copyright Notice Copyright (c) 2018 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 (https://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. SR/LDP Ships-in-the-night coexistence . . . . . . . . . . . . 3 2.1. MPLS2MPLS, MPLS2IP and IP2MPLS co-existence . . . . . . . 5 3. SR and LDP Interworking . . . . . . . . . . . . . . . . . . . 6 3.1. LDP to SR . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. LDP to SR Behavior . . . . . . . . . . . . . . . . . 7 3.2. SR to LDP . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Segment Routing Mapping Server (SRMS) . . . . . . . . 9 3.2.2. SR to LDP Behavior . . . . . . . . . . . . . . . . . 10 3.2.3. Interoperability of Multiple SRMSes and Prefix-SID advertisements . . . . . . . . . . . . . . . . . . . 11 4. SR/LDP Interworking Use Cases . . . . . . . . . . . . . . . . 12 4.1. SR Protection of LDP-based Traffic . . . . . . . . . . . 12 4.2. Eliminating Targeted LDP Session . . . . . . . . . . . . 14 4.3. Guaranteed FRR coverage . . . . . . . . . . . . . . . . . 15 4.4. Inter-AS Option C, Carrier's Carrier . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Manageability Considerations . . . . . . . . . . . . . . . . 17 6.1. SR and LDP co-existence . . . . . . . . . . . . . . . . . 17 6.2. Dataplane Verification . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 20 Bashandy, et al. Expires March 6, 2019 [Page 2] Internet-Draft Segment Routing and LDP September 2018 Appendix A. Migration from LDP to SR . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Segment Routing, as described in [I-D.ietf-spring-segment-routing], can be used on top of the MPLS data plane without any modification as described in [I-D.ietf-spring-segment-routing-mpls]. Segment Routing control plane can co-exist with current label distribution protocols such as LDP ([RFC5036]). This document outlines the mechanisms through which SR interworks with LDP in cases where a mix of SR-capable and non-SR-capable routers co-exist within the same network and more precisely in the same routing domain. Section 2 describes the co-existence of SR with other MPLS Control Plane protocols. Section 3 documents the interworking between SR and LDP in the case of non-homogeneous deployment. Section 4 describes how a partial SR deployment can be used to provide SR benefits to LDP-based traffic including a possible application of SR in the context of inter-domain MPLS use-cases. Appendix A documents a method to migrate from LDP to SR-based MPLS tunneling. Typically, an implementation will allow an operator to select (through configuration) which of the described modes of SR and LDP co-existence to use. 2. SR/LDP Ships-in-the-night coexistence "MPLS Control Plane Client (MCC)" refers to any control plane protocol installing forwarding entries in the MPLS data plane. SR, LDP [RFC5036], RSVP-TE [RFC3209], BGP [RFC8277], etc are examples of MCCs. An MCC, operating at node N, must ensure that the incoming label it installs in the MPLS data plane of Node N has been uniquely allocated to himself. Segment Routing makes use of the Segment Routing Global Block (SRGB, as defined in [I-D.ietf-spring-segment-routing]) for the label allocation. The use of the SRGB allows SR to co-exist with any other MCC. This is clearly the case for the adjacency segment: it is a local label allocated by the label manager, as for any MCC. Bashandy, et al. Expires March 6, 2019 [Page 3] Internet-Draft Segment Routing and LDP September 2018 This is clearly the case for the prefix segment: the label manager allocates the SRGB set of labels to the SR MCC client and the operator ensures the unique allocation of each global prefix segment/ label within the allocated SRGB set. Note that this static label allocation capability of the label manager has existed for many years across several vendors and hence is not new. Furthermore, note that the label-manager ability's to statically allocate a range of labels to a specific application is not new either. This is required for MPLS-TP operation. In this case, the range is reserved by the label manager and it is the MPLS- TP ([RFC5960]) NMS (acting as an MCC) that ensures the unique allocation of any label within the allocated range and the creation of the related MPLS forwarding entry. Let us illustrate an example of ship-in-the-night (SIN) coexistence. PE2 PE4 \ / PE1----A----B---C---PE3 Figure 1: SIN coexistence The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN service is supported by PE1 and PE3. The operator wants to tunnel the ODD service via LDP and the EVEN service via SR. This can be achieved in the following manner: The operator configures PE1, PE2, PE3, PE4 with respective loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, 192.0.2.204/32. These PE's advertised their VPN routes with next- hop set on their respective loopback address. The operator configures A, B, C with respective loopbacks 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. The operator configures PE2, A, B, C and PE4 with SRGB [100, 300]. The operator attaches the respective Node Segment Identifiers (Node-SID's, as defined in [I-D.ietf-spring-segment-routing]): 202, 101, 102, 103 and 204 to the loopbacks of nodes PE2, A, B, C and PE4. The Node-SID's are configured to request penultimate- hop-popping. PE1, A, B, C and PE3 are LDP capable. Bashandy, et al. Expires March 6, 2019 [Page 4] Internet-Draft Segment Routing and LDP September 2018 PE1 and PE3 are not SR capable. PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN label 10001. From an LDP viewpoint: PE1 received an LDP label binding (1037) for a forwarding equivalence class (FEC) 192.0.2.203/32 from its next-hop A. A received an LDP label binding (2048) for that FEC from its next-hop B. B received an LDP label binding (3059) for that FEC from its next-hop C. C received implicit-null LDP binding from its next- hop PE3. As a result, PE1 sends its traffic to the ODD service route advertised by PE3 to next-hop A with two labels: the top label is 1037 and the bottom label is 10001. Node A swaps 1037 with 2048 and forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 3059 and forwards to PE3. PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN label 10002. From an SR viewpoint: PE2 maps the IGP route 192.0.2.204/32 onto Node-SID 204; node A swaps 204 with 204 and forwards to B; B swaps 204 with 204 and forwards to C; C pops 204 and forwards to PE4. As a result, PE2 sends its traffic to the VPN service route advertised by PE4 to next-hop A with two labels: the top label is 204 and the bottom label is 10002. Node A swaps 204 with 204 and forwards to B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to PE4. The two modes of MPLS tunneling co-exist. The ODD service is tunneled from PE1 to PE3 through a continuous LDP LSP traversing A, B and C. The EVEN service is tunneled from PE2 to PE4 through a continuous SR node segment traversing A, B and C. 2.1. MPLS2MPLS, MPLS2IP and IP2MPLS co-existence MPLS2MPLS refers to the forwarding behavior where a router receives a labeled packet and switches it out as a labeled packet. Several MPLS2MPLS entries may be installed in the data plane for the same prefix. Let us examine A's MPLS forwarding table as an example: Bashandy, et al. Expires March 6, 2019 [Page 5] Internet-Draft Segment Routing and LDP September 2018 Incoming label: 1037 - outgoing label: 2048 - outgoing next-hop: B Note: this entry is programmed by LDP for 192.0.2.203/32 Incoming label: 203 - outgoing label: 203 - outgoing next-hop: B Note: this entry is programmed by SR for 192.0.2.203/32 These two entries can co-exist because their incoming label is unique. The uniqueness is guaranteed by the label manager allocation rules. The same applies for the MPLS2IP forwarding entries. MPLS2IP is the forwarding behavior where a router receives a label IPv4/IPv6 packet with one label only, pops the label, and switches the packet out as IPv4/IPv6. For IP2MPLS coexistence, refer to Section 6.1. 3. SR and LDP Interworking This section analyzes the case where SR is available in one part of the network and LDP is available in another part. It describes how a continuous MPLS tunnel can be built throughout the network. PE2 PE4 \ / PE1----P5--P6--P7--P8---PE3 Figure 2: SR and LDP Interworking Let us analyze the following example: P6, P7, P8, PE4 and PE3 are LDP capable. PE1, PE2, P5 and P6 are SR capable. PE1, PE2, P5 and P6 are configured with SRGB (100, 200) and respectively with node segments 101, 102, 105 and 106. A service flow must be tunneled from PE1 to PE3 over a continuous MPLS tunnel encapsulation and hence SR and LDP need to interwork. Bashandy, et al. Expires March 6, 2019 [Page 6] Internet-Draft Segment Routing and LDP September 2018 3.1. LDP to SR In this section, a right-to-left traffic flow is analyzed. PE3 has learned a service route whose next-hop is PE1. PE3 has an LDP label binding from the next-hop P8 for the FEC "PE1". Hence PE3 sends its service packet to P8 as per classic LDP behavior. P8 has an LDP label binding from its next-hop P7 for the FEC "PE1" and hence P8 forwards to P7 as per classic LDP behavior. P7 has an LDP label binding from its next-hop P6 for the FEC "PE1" and hence P7 forwards to P6 as per classic LDP behavior. P6 does not have an LDP binding from its next-hop P5 for the FEC "PE1". However P6 has an SR node segment to the IGP route "PE1". Hence, P6 forwards the packet to P5 and swaps its local LDP-label for FEC "PE1" by the equivalent node segment (i.e. 101). P5 pops 101 (assuming PE1 advertised its node segment 101 with the penultimate-pop flag set) and forwards to PE1. PE1 receives the tunneled packet and processes the service label. The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6 and the related node segment from P6 to PE1. 3.1.1. LDP to SR Behavior It has to be noted that no additional signaling or state is required in order to provide interworking in the direction LDP to SR. A SR node having LDP neighbors MUST create LDP bindings for each Prefix-SID learned in the SR domain by treating SR learned labels as if they were learned through an LDP neighbot. In addition for each FEC, the SR node stitches the incoming LDP label to the outgoing SR label. This has to be done in both LDP independent and ordered label distribution control modes as defined in [RFC5036]. 3.2. SR to LDP In this section, the left-to-right traffic flow is analyzed. This section defines the Segment Routing Mapping Server (SRMS). The SRMS is a IGP node advertising mapping between Segment Identifiers (SID) and prefixes advertised by other IGP nodes. The SRMS uses a dedicated IGP extension (IS-IS, OSPFv2 and OSPFv3) which is protocol specific and defined in [I-D.ietf-isis-segment-routing-extensions], Bashandy, et al. Expires March 6, 2019 [Page 7] Internet-Draft Segment Routing and LDP September 2018 [I-D.ietf-ospf-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The SRMS function of a SR capable router allows distribution of mappings for prefixes not locally attached to the advertising router and therefore allows advertisement of mappings on behalf of non-SR capable routers. The SRMS is a control plane only function which may be located anywhere in the IGP flooding scope. At least one SRMS server MUST exist in a routing domain to advertise prefix-SIDs on behalf non-SR nodes, thereby allowing non-LDP routers to send and receive labeled traffic from LDP-only routers. Multiple SRMSs may be present in the same network (for redundancy). This implies that there are multiple ways a prefix-to-SID mapping can be advertised. Conflicts resulting from inconsistent advertisements are addressed by [I-D.ietf-spring-segment-routing-mpls]. The example diagram depicted in Figure 2 assumes that the operator configures P5 to act as a Segment Routing Mapping Server (SRMS) and advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103) and (PE4, 104). The mappings advertised by one or more SRMSs result from local policy information configured by the operator. If PE3 had been SR capable, the operator would have configured PE3 with node segment 103. Instead, as PE3 is not SR capable, the operator configures that policy at the SRMS and it is the latter which advertises the mapping. The mapping server advertisements are only understood by SR capable routers. The SR capable routers install the related node segments in the MPLS data plane exactly like the node segments had been advertised by the nodes themselves. For example, PE1 installs the node segment 103 with next-hop P5 exactly as if PE3 had advertised node segment 103. PE1 has a service route whose next-hop is PE3. PE1 has a node segment for that IGP route: 103 with next-hop P5. Hence PE1 sends its service packet to P5 with two labels: the bottom label is the service label and the top label is 103. P5 swaps 103 for 103 and forwards to P6. P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not advertise the SR capability). However, P6 has an LDP label binding Bashandy, et al. Expires March 6, 2019 [Page 8] Internet-Draft Segment Routing and LDP September 2018 from that next-hop for the same FEC (e.g. LDP label 1037). Hence, P6 swaps 103 for 1037 and forwards to P7. P7 swaps this label with the LDP-label received from P8 and forwards to P8. P8 pops the LDP label and forwards to PE3. PE3 receives the tunneled packet and processes the service label. The end-to-end MPLS tunnel is built from an SR node segment from PE1 to P6 and an LDP LSP from P6 to PE3. SR mapping advertisement for a given prefix provides no information about the Penultimate Hop Popping. Other mechanisms, such as IGP specific mechanisms ([I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]), MAY be used to determine the Penultimate Hop Popping in such case. Note: In the previous example, Penultimate Hop Popping is not performed at the SR/LDP border for segment 103 (PE3), because none of the routers in the SR domain is Penultimate Hop for segment 103. In this case P6 requires the presence of the segment 103 such as to map it to the LDP label 1037. 3.2.1. Segment Routing Mapping Server (SRMS) This section specifies the concept and externally visible functionality of a segment routing mapping server (SRMS). The purpose of a SRMS functionality is to support the advertisement of prefix-SIDs to a prefix without the need to explicitly advertise such assignment within a prefix reachability advertisment. Examples of explicit prefix-SID advertisment are the prefix-SID sub-TLVs defined in ([I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). The SRMS functionality allows assigning of prefix-SIDs to prefixes owned by non-SR-capable routers as well as to prefixes owned by SR capable nodes. It is the former capability which is essential to the SR-LDP interworking described later in this section The SRMS functionality consists of two functional blocks: the Mapping Server (MS) and Mapping Client (MC). Bashandy, et al. Expires March 6, 2019 [Page 9] Internet-Draft Segment Routing and LDP September 2018 A MS is a node that advertises an SR mappings. Advertisements sent by an MS define the assignment of a prefix-SID to a prefix independent of the advertisment of reachability to the prefix itself. An MS MAY advertise SR mappings for any prefix whether or not it advertises reachability for the prefix and irrespective of whether that prefix is advertised by or even reachable through any router in the network. An MC is a node that receives and uses the MS mapping advertisments. Note that a node may be both an MS and an MC. An MC interprets the SR mapping advertisment as an assignment of a prefix-SID to a prefix. For a given prefix, if an MC receives an SR mapping advertisement from a mapping server and also has received a prefix-SID advertisement for that same prefix in a prefix reachability advertisement, then the MC MUST prefer the SID advertised in the prefix reachability advertisement over the mapping server advertisement i.e., the mapping server advertisment MUST be ignored for that prefix. Hence assigning a prefix-SID to a prefix using the SRMS functionality does not preclude assigning the same or different prefix-SID(s) to the same prefix using explict prefix-SID advertisement such as the aforementioned prefix-SID sub-TLVs. For example consider an IPv4 prefix advertisement received by an IS- IS router in the extended IP reachability TLV (TLV 135). Suppose TLV 135 contained the prefix-SID sub-TLV. If the router that receives TLV 135 with the prefix-SID sub-TLV also received an SR mapping advertisement for the same prefix through the SID/label binding TLV, then the receiving router must prefer the prefix-SID sub-TLV over the SID/label binding TLV for that prefix. Refer to ([I-D.ietf-isis-segment-routing-extensions], for details about the prefix-SID sub-TLV and SID/label binding TLV. 3.2.2. SR to LDP Behavior SR to LDP interworking requires a SRMS as defined above. Each SR capable router installs in the MPLS data plane Node-SIDs learned from the SRMS exactly like if these SIDs had been advertised by the nodes themselves. A SR node having LDP neighbors MUST stitch the incoming SR label (whose SID is advertised by the SRMS) to the outgoing LDP label. It has to be noted that the SR to LDP behavior does not propagate the status of the LDP FEC which was signaled if LDP was configured to use the ordered mode. Bashandy, et al. Expires March 6, 2019 [Page 10] Internet-Draft Segment Routing and LDP September 2018 It has to be noted that in the case of SR to LDP, the label binding is equivalent to the independent LDP Label Distribution Control Mode ([RFC5036]) where a label in bound to a FEC independently from the received binding for the same FEC. 3.2.3. Interoperability of Multiple SRMSes and Prefix-SID advertisements In the case of SR/LDP interoperability through the use of a SRMS, mappings are advertised by one or more SRMS. SRMS function is implemented in the link-state protocol (such as IS- IS and OSPF). Link-state protocols allow propagation of updates across area boundaries and therefore SRMS advertisements are propagated through the usual inter-area advertisement procedures in link-state protocols. Multiple SRMSs can be provisioned in a network for redundancy. Moreover, a preference mechanism may also be used among SRMSs so to deploy a primary/secondary SRMS scheme allowing controlled modification or migration of SIDs. The content of SRMS advertisement (i.e.: mappings) are a matter of local policy determined by the operator. When multiple SRMSs are active, it is necessary that the information (mappings) advertised by the different SRMSs is aligned and consistent. The following mechanism is applied to determine the preference of SRMS advertisements: If a node acts as an SRMS, it MAY advertise a preference to be associated with all SRMS SID advertisements sent by that node. The means of advertising the preference is defined in the protocol specific drafts e.g.,[I-D.ietf-isis-segment-routing-extensions] , [I-D.ietf-ospf-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The preference value is an unsigned 8 bit integer with the following properties: 0 - Reserved value indicating advertisements from that node MUST NOT be used. 1 - 255 Preference value (255 is most preferred) Advertisement of a preference value is optional. Nodes which do not advertise a preference value are assigned a preference value of 128. A MCC on a node receiving one or more SRMS mapping advertisements applies them as follows Bashandy, et al. Expires March 6, 2019 [Page 11] Internet-Draft Segment Routing and LDP September 2018 - For any prefix for which it did not receive a prefix-SID advertisement, the MCC applies the SRMS mapping advertisments with the highest preference. The mechanism by which a prefix-SID is advertised for a given prefix is defined in the protocol specification , [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions] - If there is an incoming label collision as specified in [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified in [I-D.ietf-spring-segment-routing-mpls] to resolve the collision. When the SRMS advertise mappings, an implementation should provide a mechanism through which the operator determines which of the IP2MPLS mappings are preferred among the one advertised by the SRMS and the ones advertised by LDP. 4. SR/LDP Interworking Use Cases SR can be deployed such as to enhance LDP transport. The SR deployment can be limited to the network region where the SR benefits are most desired. 4.1. SR Protection of LDP-based Traffic In Figure 4, let us assume: All link costs are 10 except FG which is 30. All routers are LDP capable. X, Y and Z are PE's participating to an important service S. The operator requires 50msec link-based Fast Reroute (FRR) for service S. A, B, C, D, E, F and G are SR capable. X, Y, Z are not SR capable, e.g. as part of a staged migration from LDP to SR, the operator deploys SR first in a sub-part of the network and then everywhere. Bashandy, et al. Expires March 6, 2019 [Page 12] Internet-Draft Segment Routing and LDP September 2018 X | Y--A---B---E--Z | | \ D---C--F--G 30 Figure 3: SR/LDP interworking example The operator would like to resolve the following issues: To protect the link BA along the shortest-path of the important flow XY, B requires a Remote Loop-Free alternate (RLFA, [RFC7490]) repair tunnel to D and hence a targeted LDP session from B to D. Typically, network operators prefer avoiding these dynamically established multi-hop LDP sessions in order to reduce the number of protocols running in the network and hence simplify network operations. There is no LFA/RLFA solution to protect the link BE along the shortest path of the important flow XZ. The operator wants a guaranteed link-based FRR solution. The operator can meet these objectives by deploying SR only on A, B, C, D, E, F and G: The operator configures A, B, C, D, E, F and G with SRGB [100, 200] and respective node segments 101, 102, 103, 104, 105, 106 and 107. The operator configures D as an SR Mapping Server with the following policy mapping: (X, 201), (Y, 202), (Z, 203). Each SR node automatically advertises local adjacency segment for its IGP adjacencies. Specifically, F advertises adjacency segment 9001 for its adjacency FG. A, B, C, D, E, F and G keep their LDP capability and hence the flows XY and XZ are transported over end-to-end LDP LSP's. For example, LDP at B installs the following MPLS data plane entries: Incoming label: local LDP label bound by B for FEC Y Outgoing label: LDP label bound by A for FEC Y Outgoing next-hop: A Incoming label: local LDP label bound by B for FEC Z Outgoing label: LDP label bound by E for FEC Z Bashandy, et al. Expires March 6, 2019 [Page 13] Internet-Draft Segment Routing and LDP September 2018 Outgoing next-hop: E The novelty comes from how the backup chains are computed for these LDP-based entries. While LDP labels are used for the primary next- hop and outgoing labels, SR information is used for the FRR construction. In steady state, the traffic is transported over LDP LSP. In transient FRR state, the traffic is backup thanks to the SR enhanced capabilities. The RLFA paths are dynamically pre-computed as defined in [RFC7490]. Typically, implementations allow to enable RLFA mechanism through a simple configuration command that triggers both the pre-computation and installation of the repair path. The details on how RLFA mechanisms are implemented and configured is outside the scope of this document and not relevant to the aspects of SR/LDP interwork explained in this document. This helps meet the requirements of the operator: Eliminate targeted LDP session. Guaranteed FRR coverage. Keep the traffic over LDP LSP in steady state. Partial SR deployment only where needed. 4.2. Eliminating Targeted LDP Session B's MPLS entry to Y becomes: - Incoming label: local LDP label bound by B for FEC Y Outgoing label: LDP label bound by A for FEC Y Backup outgoing label: SR node segment for Y {202} Outgoing next-hop: A Backup next-hop: repair tunnel: node segment to D {104} with outgoing next-hop: C It has to be noted that D is selected as Remote Loop-Free Alternate (RLFA) as defined in [RFC7490]. In steady-state, X sends its Y-destined traffic to B with a top label which is the LDP label bound by B for FEC Y. B swaps that top label for the LDP label bound by A for FEC Y and forwards to A. A pops the LDP label and forwards to Y. Upon failure of the link BA, B swaps the incoming top-label with the node segment for Y (202) and sends the packet onto a repair tunnel to Bashandy, et al. Expires March 6, 2019 [Page 14] Internet-Draft Segment Routing and LDP September 2018 D (node segment 104). Thus, B sends the packet to C with the label stack {104, 202}. C pops the node segment 104 and forwards to D. D swaps 202 for 202 and forwards to A. A's next-hop to Y is not SR capable and hence node A swaps the incoming node segment 202 to the LDP label announced by its next-hop (in this case, implicit null). After IGP convergence, B's MPLS entry to Y will become: - Incoming label: local LDP label bound by B for FEC Y Outgoing label: LDP label bound by C for FEC Y Outgoing next-hop: C And the traffic XY travels again over the LDP LSP. Conclusion: the operator has eliminated the need for targeted LDP sessions (no longer required) and the steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits are required. Despite that in general, an implementation would not require a manual configuration of LDP Targeted sessions however, it is always a gain if the operator is able to reduce the set of protocol sessions running on the network infrastructure. 4.3. Guaranteed FRR coverage As mentioned in Section 4.1 above, in the example topology described in Figure 4, there is no RLFA-based solution for protecting the traffic flow YZ against the failure of link BE because there is no intersection between the extended P-space and Q-space (see [RFC7490] for details). However: - G belongs to the Q space of Z. - G can be reached from B via a "repair SR path" {106, 9001} that is not affected by failure of link BE (The method by which G and the repair tunnel to it from B are identified are out of scope of this document.) B's MPLS entry to Z becomes: Bashandy, et al. Expires March 6, 2019 [Page 15] Internet-Draft Segment Routing and LDP September 2018 - Incoming label: local LDP label bound by B for FEC Z Outgoing label: LDP label bound by E for FEC Z Backup outgoing label: SR node segment for Z {203} Outgoing next-hop: E Backup next-hop: repair tunnel to G: {106, 9001} G is reachable from B via the combination of a node segment to F {106} and an adjacency segment FG {9001} Note that {106, 107} would have equally work. Indeed, in many case, P's shortest path to Q is over the link PQ. The adjacency segment from P to Q is required only in very rare topologies where the shortest-path from P to Q is not via the link PQ. In steady-state, X sends its Z-destined traffic to B with a top label which is the LDP label bound by B for FEC Z. B swaps that top label for the LDP label bound by E for FEC Z and forwards to E. E pops the LDP label and forwards to Z. Upon failure of the link BE, B swaps the incoming top-label with the node segment for Z (203) and sends the packet onto a repair tunnel to G (node segment 106 followed by adjacency segment 9001). Thus, B sends the packet to C with the label stack {106, 9001, 203}. C pops the node segment 106 and forwards to F. F pops the adjacency segment 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's next-hop to Z is not SR capable and hence E swaps the incoming node segment 203 for the LDP label announced by its next-hop (in this case, implicit null). After IGP convergence, B's MPLS entry to Z will become: - Incoming label: local LDP label bound by B for FEC Z Outgoing label: LDP label bound by C for FEC Z Outgoing next-hop: C And the traffic XZ travels again over the LDP LSP. Conclusions: - the operator has eliminated its second problem: guaranteed FRR coverage is provided. The steady-state traffic is still transported over LDP. The SR deployment is confined to the area where these benefits are required. Bashandy, et al. Expires March 6, 2019 [Page 16] Internet-Draft Segment Routing and LDP September 2018 - FRR coverage has been achieved without any signaling for setting up the repair LSP and without setting up a targeted LDP session between B and G. 4.4. Inter-AS Option C, Carrier's Carrier In inter-AS Option C [RFC4364], two interconnected ASes sets up inter-AS MPLS connectivity. SR may be independently deployed in each AS. PE1---R1---B1---B2---R2---PE2 <-----------> <-----------> AS1 AS2 Figure 4: Inter-AS Option C In Inter-AS Option C, B2 advertises to B1 a labeled BGP route [RFC8277] for PE2 and B1 reflects it to its internal peers, such as PE1. PE1 learns from a service route reflector a service route whose next-hop is PE2. PE1 resolves that service route on the labeled BGP route to PE2. That labeled BGP route to PE2 is itself resolved on the AS1 IGP route to B1. If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the node segment from PE1 to B1. PE1 sends a service packet with three labels: the top one is the node segment to B1, the next-one is the label in the labeled BGP route provided by B1 for the route "PE2" and the bottom one is the service label allocated by PE2. 5. IANA Considerations This document does not introduce any new codepoint. 6. Manageability Considerations 6.1. SR and LDP co-existence When both SR and LDP co-exist, the following applies: - If both SR and LDP propose an IP2MPLS entry for the same IP prefix, then by default the LDP route SHOULD be selected. This is because it is expected that SR is introduced into network that contain routers that do not support SR. Hence by having a behavior that prefers LDP over SR, traffic flow is unlikely to be disrupted Bashandy, et al. Expires March 6, 2019 [Page 17] Internet-Draft Segment Routing and LDP September 2018 - A local policy on a router MUST allow to prefer the SR-provided IP2MPLS entry. - Note that this policy MAY be locally defined. There is no requirement that all routers use the same policy. 6.2. Dataplane Verification When Label switch paths (LSPs) are defined by stitching LDP LSPs with SR LSPs, it is necessary to have mechanisms allowing the verification of the LSP connectivity as well as validation of the path. These mechanisms are described in [RFC8287]. 7. Security Considerations This document does not introduce any change to the MPLS dataplane [RFC3031] and therefore no additional security of the MPLS dataplane is required. This document introduces another form of label binding advertisements. The security associated with these advertisements is part of the security applied to routing protocols such as IS-IS [RFC5304] and OSPF [RFC5709] which both optionally make use of cryptographic authentication mechanisms. This form of advertisement is more centralized, on behalf of the node advertising the IP reachability, which presents a different risk profile. This document also specifies a mechanism by which the ill effects of advertising conflicting label bindings can be mitigated. In particular, advertisements from the node advertising the IP reachability is more preferred than the centralized one. Because this document recognizes that reachability, which presents a different risk profile. This document miscofiguration and/or programming may result in false or conflicting also specifies a mechanism by which the ill effects of advertising label binding advertisements, thereby compromising traffic conflicting label bindings can be mitigated. In particular, forwarding, the document recommends strict configuration/ advertisements from the node advertising the IP reachability is more programmability control as well as montoring the SID advertised and preferred than the centralized one. log/error messages by the operator to avoid or at least significantly minimize the possibility of such risk. 8. Acknowledgements The authors would like to thank Pierre Francois, Ruediger Geib and Alexander Vainshtein for their contribution to the content of this document. Bashandy, et al. Expires March 6, 2019 [Page 18] Internet-Draft Segment Routing and LDP September 2018 9. Contributors' Addresses Edward Crabbe Individual Email: edward.crabbe@gmail.com Igor Milojevic Email: milojevicigor@gmail.com Saku Ytti TDC Email: saku@ytti.fi Rob Shakir Google Email: robjs@google.com Martin Horneffer Deutsche Telekom Email: Martin.Horneffer@telekom.de Wim Henderickx Nokia Email: wim.henderickx@nokia.com Jeff Tantsura Individual Email: jefftant@gmail.com Les Ginseberg Cisco Systems Email: ginsberg@cisco.com 10. References 10.1. Normative References [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", January 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-13 (work in progress), April 2018. Bashandy, et al. Expires March 6, 2019 [Page 19] Internet-Draft Segment Routing and LDP September 2018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . 10.2. Informative References [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf-isis- segment-routing-extensions-19 (work in progress), July 2018. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., Filsfils, C., Previdi, S., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- segment-routing-extensions-11 (work in progress), January 2018. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-24 (work in progress), December 2017. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC3209] Awduche, D., Berger, L., Gan, G., Li, T., Srinivasan, V., and G. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . Bashandy, et al. Expires March 6, 2019 [Page 20] Internet-Draft Segment Routing and LDP September 2018 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, . [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, DOI 10.17487/RFC5960, August 2010, . [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, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", October 2017. [RFC8287] Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/ Traceroute for Segment Routing (SR) IGP-Prefix and IGP- Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", December 2017. [RFC8355] Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", March 2018. Appendix A. Migration from LDP to SR PE2 PE4 \ / PE1----P5--P6--P7---PE3 Figure 5: Migration Several migration techniques are possible. The technique described here is inspired by the commonly used method to migrate from one IGP to another. At time T0, all the routers run LDP. Any service is tunneled from an ingress PE to an egress PE over a continuous LDP LSP. At time T1, all the routers are upgraded to SR. They are configured with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6 and P7 are respectively configured with the node segments 101, 102, 103, 104, 105, 106 and 107 (attached to their service-recursing loopback). Bashandy, et al. Expires March 6, 2019 [Page 21] Internet-Draft Segment Routing and LDP September 2018 At this time, the service traffic is still tunneled over LDP LSP. For example, PE1 has an SR node segment to PE3 and an LDP LSP to PE3 but by default, as seen earlier, the LDP IP2MPLS encapsulation is preferred. However, it has to be noted that the SR infrastructure is usable, e.g. for Fast Reroute (FRR) or IGP Loop Free Convergence to protect existing IP and LDP traffic. FRR mechanisms are described in and [RFC8355]. At time T2, the operator enables the local policy at PE1 to prefer SR IP2MPLS encapsulation over LDP IP2MPLS. The service from PE1 to any other PE is now riding over SR. All other service traffic is still transported over LDP LSP. At time T3, gradually, the operator enables the preference for SR IP2MPLS encapsulation across all the edge routers. All the service traffic is now transported over SR. LDP is still operational and services could be reverted to LDP. At time T4, LDP is unconfigured from all routers. Authors' Addresses Ahmed Bashandy (editor) Individual USA Email: abashandy.ietf@gmail.com Clarence Filsfils (editor) Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Stefano Previdi Cisco Systems, Inc. IT Email: stefano@previdi.net Bashandy, et al. Expires March 6, 2019 [Page 22] Internet-Draft Segment Routing and LDP September 2018 Bruno Decraene Orange FR Email: bruno.decraene@orange.com Stephane Litkowski Orange FR Email: stephane.litkowski@orange.com Bashandy, et al. Expires March 6, 2019 [Page 23] ./draft-ietf-spring-segment-routing-mpls-22.txt0000644000764400076440000022072413462357050020770 0ustar iustyiustyNetwork Working Group A. Bashandy, Ed. Internet Draft Arrcus Intended status: Standards Track C. Filsfils, Ed. Expires: November 2019 S. Previdi, Cisco Systems, Inc. B. Decraene S. Litkowski Orange R. Shakir Google May 1, 2019 Segment Routing with MPLS data plane draft-ietf-spring-segment-routing-mpls-22 Abstract Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS dataplane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS dataplane. 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 1, 2019. Filsfils, et al. Expires November 1, 2019 [Page 1] Internet-Draft Segment Routing with MPLS May 2019 Copyright Notice Copyright (c) 2019 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. MPLS Instantiation of Segment Routing..........................4 2.1. Multiple Forwarding Behaviors for the Same Prefix.........4 2.2. SID Representation in the MPLS Forwarding Plane...........5 2.3. Segment Routing Global Block and Local Block..............5 2.4. Mapping a SID Index to an MPLS label......................6 2.5. Incoming Label Collision..................................7 2.5.1. Tie-breaking Rules..................................10 2.5.2. Redistribution between Routing Protocol Instances...13 2.5.2.1. Illustration...................................13 2.5.2.2. Illustration 2.................................14 2.6. Effect of Incoming Label Collision on Outgoing Label Programming...................................................14 2.7. PUSH, CONTINUE, and NEXT.................................15 2.7.1. PUSH................................................15 2.7.2. CONTINUE............................................15 2.7.3. NEXT................................................15 2.7.3.1. Mirror SID.....................................16 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs...16 2.9. Active Segment...........................................16 2.10. Forwarding behavior for Global SIDs.....................16 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs....17 2.10.2. Forwarding for NEXT Operation for Global SIDs......18 2.11. Forwarding Behavior for Local SIDs......................18 2.11.1. Forwarding for PUSH Operation on Local SIDs........19 2.11.2. Forwarding for CONTINUE Operation for Local SIDs...19 2.11.3. Outgoing label for NEXT Operation for Local SIDs...19 3. IANA Considerations...........................................19 Filsfils, et al. Expires November 1, 2019 [Page 2] Internet-Draft Segment Routing with MPLS May 2019 4. Manageability Considerations..................................20 5. Security Considerations.......................................20 6. Contributors..................................................20 7. Acknowledgements..............................................20 8. References....................................................21 8.1. Normative References.....................................21 8.2. Informative References...................................22 9. Authors' Addresses............................................24 Appendix A. Examples.............................................26 A.1. IGP Segments Example.....................................26 A.2. Incoming Label Collision Examples........................28 A.2.1. Example 1...........................................28 A.2.2. Example 2...........................................29 A.2.3. Example 3...........................................30 A.2.4. Example 4...........................................30 A.2.5. Example 5...........................................31 A.2.6. Example 6...........................................31 A.2.7. Example 7...........................................32 A.2.8. Example 8...........................................32 A.2.9. Example 9...........................................33 A.2.10. Example 10.........................................33 A.2.11. Example 11.........................................34 A.2.12. Example 12.........................................35 A.2.13. Example 13.........................................35 A.2.14. Example 14.........................................36 A.3. Examples for the Effect of Incoming Label Collision on Outgoing Label................................................36 A.3.1. Example 1...........................................36 A.3.2. Example 2...........................................37 1. Introduction The Segment Routing architecture RFC8402 can be directly applied to the MPLS architecture with no change in the MPLS forwarding plane. This document specifies the forwarding plane behavior to allow Segment Routing to operate on top of the MPLS data plane. This document does not address the control plane behavior. Control plane behavior is specified in other documents such as [I-D.ietf-isis- segment-routing-extensions], [I-D.ietf-ospf-segment-routing- extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The Segment Routing problem statement is described in [RFC7855]. Co-existence of SR over MPLS forwarding plane with LDP [RFC5036] is specified in [I-D.ietf-spring-segment-routing-ldp-interop]. Filsfils, et al. Expires November 1, 2019 [Page 3] Internet-Draft Segment Routing with MPLS May 2019 Policy routing and traffic engineering using segment routing can be found in [I-D.ietf-spring-segment-routing-policy] 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. MPLS Instantiation of Segment Routing MPLS instantiation of Segment Routing fits in the MPLS architecture as defined in [RFC3031] both from a control plane and forwarding plane perspective: o From a control plane perspective, [RFC3031] does not mandate a single signaling protocol. Segment Routing makes use of various control plane protocols such as link state IGPs [I-D.ietf-isis- segment-routing-extensions], [I-D.ietf-ospf-segment-routing- extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding mechanisms of link state IGPs fit very well with label stacking on ingress. Future control layer protocol and/or policy/configuration can be used to specify the label stack. o From a forwarding plane perspective, Segment Routing does not require any change to the forwarding plane because Segment IDs (SIDs) are instantiated as MPLS labels and the Segment routing header instantiated as a stack of MPLS labels. We call "MPLS Control Plane Client (MCC)" any control plane entity installing forwarding entries in the MPLS data plane. Local configuration and policies applied on a router are examples of MCCs. In order to have a node segment reach the node, a network operator SHOULD configure at least one node segment per routing instance, topology, or algorithm. Otherwise, the node is not reachable within the routing instance, topology or along the routing algorithm, which restrict its ability to be used by a SR policy, including for TI-LFA. 2.1. Multiple Forwarding Behaviors for the Same Prefix The SR architecture does not prohibit having more than one SID for the same prefix. In fact, by allowing multiple SIDs for the same prefix, it is possible to have different forwarding behaviors (such Filsfils, et al. Expires November 1, 2019 [Page 4] Internet-Draft Segment Routing with MPLS May 2019 as different paths, different ECMP/UCMP behaviors,...,etc) for the same destination. Instantiating Segment routing over the MPLS forwarding plane fits seamlessly with this principle. An operator may assign multiple MPLS labels or indices to the same prefix and assign different forwarding behaviors to each label/SID. The MCC in the network downloads different MPLS labels/SIDs to the FIB for different forwarding behaviors. The MCC at the entry of an SR domain or at any point in the domain can choose to apply a particular forwarding behavior to a particular packet by applying the PUSH action to that packet using the corresponding SID. 2.2. SID Representation in the MPLS Forwarding Plane When instantiating SR over the MPLS forwarding plane, a SID is represented by an MPLS label or an index [RFC8402]. A global segment is a label, or an index which may be mapped to an MPLS label within the Segment Routing Global Block (SRGB) of the node installing the global segment in its FIB/receiving the labeled packet. Section 2.4 specifies the procedure to map a global segment represented by an index to an MPLS label within the SRGB. The MCC MUST ensure that any label value corresponding to any SID it installs in the forwarding plane follows the following rules: o The label value MUST be unique within the router on which the MCC is running. i.e. the label MUST only be used to represent the SID and MUST NOT be used to represent more than one SID or for any other forwarding purpose on the router. o The label value MUST NOT come from the range of special purpose labels [RFC7274]. Labels allocated in this document are considered per platform down- stream allocated labels [RFC3031]. 2.3. Segment Routing Global Block and Local Block The concepts of Segment Routing Global Block (SRGB) and global SID are explained in [RFC8402]. In general, the SRGB need not be a contiguous range of labels. For the rest of this document, the SRGB is specified by the list of MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] where Ll(i) =< Lh(i). Filsfils, et al. Expires November 1, 2019 [Page 5] Internet-Draft Segment Routing with MPLS May 2019 The following rules apply to the list of MPLS ranges representing the SRGB o The list of ranges comprising the SRGB MUST NOT overlap. o Every range in the list of ranges specifying the SRGB MUST NOT cover or overlap with a reserved label value or range [RFC7274], respectively. o If the SRGB of a node does not conform to the structure specified in this section or to the previous two rules, then this SRGB MUST be completely ignored by all routers in the routing domain and the node MUST be treated as if it does not have an SRGB. o The list of label ranges MUST only be used to instantiate global SIDs into the MPLS forwarding plane A Local segment MAY be allocated from the Segment Routing Local Block (SRLB) [RFC8402] or from any unused label as long as it does not use a special purpose label. The SRLB consists of the range of local labels reserved by the node for certain local segments. In a controller-driven network, some controllers or applications MAY use the control plane to discover the available set of local SIDs on a particular router [I-D.ietf-spring-segment-routing-policy]. The rules applicable to the SRGB are also applicable to the SRLB, except the rule that says that the SRGB MUST only be used to instantiate global SIDs into the MPLS forwarding plane. The recommended, minimum, or maximum size of the SRGB and/or SRLB is a matter of future study 2.4. Mapping a SID Index to an MPLS label This sub-section specifies how the MPLS label value is calculated given the index of a SID. The value of the index is determined by an MCC such as IS-IS [I-D.ietf-isis-segment-routing-extensions] or OSPF [I-D.ietf-ospf-segment-routing-extensions]. This section only specifies how to map the index to an MPLS label. The calculated MPLS label is downloaded to the FIB, sent out with a forwarded packet, or both. Consider a SID represented by the index "I". Consider an SRGB as specified in Section 2.3. The total size of the SRGB, represented by the variable "Size", is calculated according to the formula: size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 The following rules MUST be applied by the MCC when calculating the MPLS label value corresponding the SID index value "I". Filsfils, et al. Expires November 1, 2019 [Page 6] Internet-Draft Segment Routing with MPLS May 2019 o 0 =< I < size. If the index "I" does not satisfy the previous inequality, then the label cannot be calculated. o The label value corresponding to the SID index "I" is calculated as follows o j = 1 , temp = 0 o While temp + Lh(j)- Ll(j) < I . temp = temp + Lh(j)- Ll(j) + 1 . j = j+1 o label = I - temp + Ll(j) An example for how a router calculates labels and forwards traffic based on the procedure described in this section can be found in Appendix A.1. 2.5. Incoming Label Collision The MPLS Architecture [RFC3031] defines the term Forwarding Equivalence Class (FEC) as the set of packets with similar and / or identical characteristics which are forwarded the same way and are bound to the same MPLS incoming (local) label. In Segment-Routing MPLS, a local label serves as the SID for given FEC. We define Segment Routing (SR) FEC as one of the following [RFC8402]: Filsfils, et al. Expires November 1, 2019 [Page 7] Internet-Draft Segment Routing with MPLS May 2019 o (Prefix, Routing Instance, Topology, Algorithm [RFC8402]), where a topology identifies a set of links with metrics. For the purpose of incoming label collision resolution, the same Topology numerical value SHOULD be used on all routers to identify the same set of links with metrics. For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zero MUST be used for these two fields. For the purpose of incoming label collision resolution, a routing instance is identified by a single incoming label downloader to FIB. Two MCCs running on the same router are considered different routing instances if the only way the two instances can know about the other's incoming labels is through redistribution. The numerical value used to identify a routing instance MAY be derived from other configuration or MAY be explicitly configured. If it is derived from other configuration, then the same numerical value SHOULD be derived from the same configuration as long as the configuration survives router reload. If the derived numerical value varies for the same configuration, then an implementation SHOULD make numerical value used to identify a routing instance configurable. o (next-hop, outgoing interface), where the outgoing interface is physical or virtual. o (number of adjacencies, list of next-hops, list of outgoing interfaces IDs in ascending numerical order). This FEC represents parallel adjacencies [RFC8402] o (Endpoint, Color) representing an SR policy [RFC8402] o (Mirrored SID) The Mirrored SID [RFC8402, Section 5.1] is the IP address advertised by the advertising node to identify the mirror- SID. The IP address is encoded as specified in Section 2.5.1. This section covers the RECOMMENDED procedure to handle the scenario where, because of an error/misconfiguration, more than one SR FEC as defined in this section, map to the same incoming MPLS label. Examples illustrating the behavior specified in this section can be found in Appendix A.2. An incoming label collision occurs if the SIDs of the set of FECs {FEC1, FEC2,..., FECk} map to the same incoming SR MPLS label "L1". Suppose an anycast prefix is advertised with a prefix-SID by some, but not all, of the nodes that advertise that prefix. If the prefix- SID sub-TLVs result in mapping that anycast prefix to the same incoming label, then the advertisement of the prefix-SID by some, but Filsfils, et al. Expires November 1, 2019 [Page 8] Internet-Draft Segment Routing with MPLS May 2019 not all, of advertising nodes MUST NOT be treated as a label collision. An implementation MUST NOT allow the MCCs belonging to the same router to assign the same incoming label to more than one SR FEC. The objective of the following steps is to deterministically install in the MPLS Incoming Label Map, also known as label FIB, a single FEC with the incoming label "L1". By "deterministically install" we mean if the set of FECs {FEC1, FEC2,..., FECk} map to the same incoming SR MPLS label "L1", then the steps below assign the same FEC to the label "L1" irrespective of the order by which the mappings of this set of FECs to the label "L1" are received. For example, a first- come-first-serve tie-breaking is not allowed. The remaining FECs may be installed in the IP FIB without incoming label. The procedure in this section relies completely on the local FEC and label database within a given router. The collision resolution procedure is as follows 1. Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to the same MPLS label "L1". 2. Within an MCC, apply tie-breaking rules to select one FEC only and assign the label to it. The losing FECs are handled as if no labels are attached to them. The losing FECs with algorithms other than the shortest path first [RFC8402] are not installed in the FIB. a. If the same set of FECs are attached to the same label "L1", then the tie-breaking rules MUST always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, the tie-breaking rule MUST be deterministic. 3. If there is still collision between the FECs belonging to different MCCs, then re-apply the tie-breaking rules to the remaining FECs to select one FEC only and assign the label to that FEC 4. Install into the IP FIB the selected FEC and its incoming label in the label FIB. Filsfils, et al. Expires November 1, 2019 [Page 9] Internet-Draft Segment Routing with MPLS May 2019 5. The remaining FECs with the default algorithm (see the specification of prefix-SID algorithm [RFC8402]) may be installed in the FIB natively, such as pure IP entries in case of Prefix FEC, without any incoming labels corresponding to their SIDs. The remaining FECs with algorithms other than the shortest path first [RFC8402] are not installed in the FIB. 2.5.1. Tie-breaking Rules The default tie-breaking rules are specified as follows: 1. if FECi has the lowest FEC administrative distance among the competing FECs as defined in this section below, filter away all the competing FECs with higher administrative distance. 2. if more than one competing FEC remains after step 1, select the smallest numerical FEC value. The numerical value of the FEC is determined according to the FEC encoding described later in this section. These rules deterministically select the FEC to install in the MPLS forwarding plane for the given incoming label. This document defines the default tie breaking rules that SHOULD be implemented. An implementation MAY choose to support different tie- breaking rules and MAY use one of the these instead of the default tie-breaking rules. To maximize MPLS forwarding consistency in case of SID configuration error, the network operator MUST deploy, within an IGP flooding area, routers implementing the same tie-breaking rules. Each FEC is assigned an administrative distance. The FEC administrative distance is encoded as an 8-bit value. The lower the value, the better the administrative distance. The default FEC administrative distance order starting from the lowest value SHOULD be: o Explicit SID assignment to a FEC that maps to a label outside the SRGB irrespective of the owner MCC. An explicit SID assignment is a static assignment of a label to a FEC such that the assignment survives router reboot. o An example of explicit SID allocation is static assignment of a specific label to an adj-SID. Filsfils, et al. Expires November 1, 2019 [Page 10] Internet-Draft Segment Routing with MPLS May 2019 o An implementation of explicit SID assignment MUST guarantee collision freeness on the same router o Dynamic SID assignment: o For all FEC types except for SR policy, the FEC types are ordered using the default administrative distance ordering defined by the implementation. o Binding SID [RFC8402] assigned to SR Policy always has a higher default administrative distance than the default administrative distance of any other FEC type To maximize MPLS forwarding consistency, If a same FEC is advertised in more than one protocol, a user MUST ensure that the administrative distance preference between protocols is the same on all routers of the IGP flooding domain. Note that this is not really new as this already applies to IP forwarding. The numerical sort across FECs SHOULD be performed as follows: o Each FEC is assigned a FEC type encoded in 8 bits. The following are the type code point for each SR FEC defined at the beginning of this Section: o 120: (Prefix, Routing Instance, Topology, Algorithm) o 130: (next-hop, outgoing interface) o 140: Parallel Adjacency [RFC8402] o 150: an SR policy [RFC8402]. o 160: Mirror SID [RFC8402] o The numerical values above are mentioned to guide implementation. If other numerical values are used, then the numerical values must maintain the same greater-than ordering of the numbers mentioned here. o The fields of each FEC are encoded as follows o All fields in all FECs are encoded in big endian Filsfils, et al. Expires November 1, 2019 [Page 11] Internet-Draft Segment Routing with MPLS May 2019 o Routing Instance ID represented by 16 bits. For routing instances that are identified by less than 16 bits, encode the Instance ID in the least significant bits while the most significant bits are set to zero o Address Family represented by 8 bits, where IPv4 encoded as 100 and IPv6 is encoded as 110. These numerical values are mentioned to guide implementations. If other numerical values are used, then the numerical value of IPv4 MUST be less than the numerical value for IPv6 o All addresses are represented in 128 bits as follows . IPv6 address is encoded natively . IPv4 address is encoded in the most significant bits and the remaining bits are set to zero o All prefixes are represented by (8 + 128) bits. . A prefix is encoded in the most significant bits and the remaining bits are set to zero. . The prefix length is encoded before the prefix in a field of size 8 bits. o Topology ID is represented by 16 bits. For routing instances that identify topologies using less than 16 bits, encode the topology ID in the least significant bits while the most significant bits are set to zero o Algorithm is encoded in a 16 bits field. o The Color ID is encoded using 32 bits o Choose the set of FECs of the smallest FEC type code point o Out of these FECs, choose the FECs with the smallest address family code point o Encode the remaining set of FECs as follows o (Prefix, Routing Instance, Topology, Algorithm) is encoded as (Prefix Length, Prefix, routing_instance_id, Topology, SR Algorithm) Filsfils, et al. Expires November 1, 2019 [Page 12] Internet-Draft Segment Routing with MPLS May 2019 o (next-hop, outgoing interface) is encoded as (next-hop, outgoing_interface_id) o (number of adjacencies, list of next-hops in ascending numerical order, list of outgoing interface IDs in ascending numerical order). This encoding is used to encode a parallel adjacency [RFC8402] o (Endpoint, Color) is encoded as (Endpoint_address, Color_id) o (IP address): This is the encoding for a mirror SID FEC. The IP address is encoded as described above in this section o Select the FEC with the smallest numerical value The numerical values mentioned in this section are for guidance only. If other numerical values are used then the other numerical values MUST maintain the same numerical ordering among different SR FECs. 2.5.2. Redistribution between Routing Protocol Instances The following rule SHOULD be applied when redistributing SIDs with prefixes between routing protocol instances: o If the receiving instance's SRGB is the same as the SRGB of origin instance, then o the index is redistributed with the route o Else o the index is not redistributed and if the receiving instance decides to advertise an index with the redistributed route, it is the duty of the receiving instance to allocate a fresh index relative to its own SRGB. Note that in this case the receiving instance MUST compute the local label it assignes to the route according to section 2.4 and install it in FIB. It is outside the scope of this document to define local node behaviors that would allow to map the original index into a new index in the receiving instance via the addition of an offset or other policy means. 2.5.2.1. Illustration A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001) Filsfils, et al. Expires November 1, 2019 [Page 13] Internet-Draft Segment Routing with MPLS May 2019 Consider the simple topology above. o A and B are in the IS-IS domain with SRGB [16000-17000] o B and C are in OSPF domain with SRGB [20000-21000] o B redistributes 192.0.2.1/32 into IS-IS domain o In that case A learns 192.0.2.1/32 as an IP leaf connected to B as usual for IP prefix redistribution o However, according to the redistribution rule above rule, B decides not to advertise any index with 192.0.2.1/32 into IS-IS because the SRGB is not the same. 2.5.2.2. Illustration 2 Consider the example in the illustration described in Section 2.5.2.1. When router B redistributes the prefix 192.0.2.1/32, router B decides to allocate and advertise the same index 1 with the prefix 192.0.2.1/32 Within the SRGB of the IS-IS domain, index 1 corresponds to the local label 16001 o Hence according to the redistribution rule above, router B programs the incoming label 16001 in its FIB to match traffic arriving from the IS-IS domain destined to the prefix 192.0.2.1/32. 2.6. Effect of Incoming Label Collision on Outgoing Label Programming For the determination of the outgoing label to use, the ingress node pushing new segments, and hence a stack of MPLS labels, MUST use, for a given FEC, the same label that has been selected by the node receiving the packet with that label exposed as top label. So in case of incoming label collision on this receiving node, the ingress node MUST resolve this collision using this same "Incoming Label Collision resolution procedure", using the data of the receiving node. In the general case, the ingress node may not have exactly the same data of the receiving node, so the result may be different. This is under the responsibility of the network operator. But in typical case, e.g. where a centralized node or a distributed link state IGP Filsfils, et al. Expires November 1, 2019 [Page 14] Internet-Draft Segment Routing with MPLS May 2019 is used, all nodes would have the same database. However to minimize the chance of misforwarding, a FEC that loses its incoming label to the tie-breaking rules specified in Section 2.5 MUST NOT be installed in FIB with an outgoing segment routing label based on the SID corresponding to the lost incoming label. Examples for the behavior specified in this section can be found in Appendix A.3. 2.7. PUSH, CONTINUE, and NEXT PUSH, NEXT, and CONTINUE are operations applied by the forwarding plane. The specifications of these operations can be found in [RFC8402]. This sub-section specifies how to implement each of these operations in the MPLS forwarding plane. 2.7.1. PUSH As described in [RFC8402], PUSH corresponds to pushing one or more labels on top of an incoming packet then sending it out of a particular physical interface or virtual interface, such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817], towards a particular next-hop. When pushing labels onto a packet's label stack, the Time- to-Live (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field ([RFC3032], [RFC5462]) of each label stack entry must, of course, be set. This document does not specify any set of rules for setting these fields; that is a matter of local policy. Sections 2.10 and 2.11 specify additional details about forwarding behavior. 2.7.2. CONTINUE As described in [RFC8402], the CONTINUE operation corresponds to swapping the incoming label with an outgoing label. The value of the outgoing label is calculated as specified in Sections 2.10 and 2.11. 2.7.3. NEXT As described in [RFC8402], NEXT corresponds to popping the topmost label. The action before and/or after the popping depends on the instruction associated with the active SID on the received packet prior to the popping. For example suppose the active SID in the received packet was an Adj-SID [RFC8402], then on receiving the packet, the node applies NEXT operation, which corresponds to popping the top most label, and then sends the packet out of the physical or virtual interface (e.g. UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]) towards the next-hop corresponding to the adj-SID. Filsfils, et al. Expires November 1, 2019 [Page 15] Internet-Draft Segment Routing with MPLS May 2019 2.7.3.1. Mirror SID If the active SID in the received packet was a Mirror SID [RFC8402, Section 5.1] allocated by the receiving router, then the receiving router applies NEXT operation, which corresponds to popping the top most label, then performs a lookup using the contents of the packet after popping the outer most label in the mirrored forwarding table. The method by which the lookup is made, and/or the actions applied to the packet after the lookup in the mirror table depends on the contents of the packet and the mirror table. Note that the packet exposed after popping the top most label may or may not be an MPLS packet. A mirror SID can be viewed as a generalization of the context label in [RFC5331] because a mirror SID does not make any assumptions about the packet underneath the top label. 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs The label corresponding to the global SID "Si" represented by the global index "I" downloaded to FIB is used to match packets whose active segment (and hence topmost label) is "Si". The value of this label is calculated as specified in Section 2.4. For Local SIDs, the MCC is responsible for downloading the correct label value to FIB. For example, an IGP with SR extensions [I-D.ietf- isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing- extensions] downloads the MPLS label corresponding to an Adj-SID [RFC8402]. 2.9. Active Segment When instantiated in the MPLS domain, the active segment on a packet corresponds to the topmost label on the packet that is calculated according to the procedure specified in Sections 2.10 and 2.11. When arriving at a node, the topmost label corresponding to the active SID matches the MPLS label downloaded to FIB as specified in Section 2.4. 2.10. Forwarding behavior for Global SIDs This section specifies forwarding behavior, including the calculation of outgoing labels, that corresponds to a global SID when applying PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. This document covers the calculation of the outgoing label for the top label only. The case where the outgoing label is not the top label and is part of a stack of labels that instantiates a routing policy or a traffic engineering tunnel is outside the scope of this Filsfils, et al. Expires November 1, 2019 [Page 16] Internet-Draft Segment Routing with MPLS May 2019 document and may be covered in other documents such as [I-D.ietf- spring-segment-routing-policy]. 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs Suppose an MCC on a router "R0" determines that PUSH or CONTINUE operation is to be applied to an incoming packet related to the global SID "Si" represented by the global index "I" and owned by the router Ri before sending the packet towards a neighbor "N" directly connected to "R0" through a physical or virtual interface such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. The method by which the MCC on router "R0" determines that PUSH or CONTINUE operation must be applied using the SID "Si" is beyond the scope of this document. An example of a method to determine the SID "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis- segment-routing-extensions] receives the prefix-SID "Si" sub-TLV advertised with prefix "P/m" in TLV 135 and the destination address of the incoming IPv4 packet is covered by the prefix "P/m". For CONTINUE operation, an example of a method to determine the SID "Si" is the case where IS-IS [I-D.ietf-isis-segment-routing- extensions] receives the prefix-SID "Si" sub-TLV advertised with prefix "P" in TLV 135 and the top label of the incoming packet matches the MPLS label in FIB corresponding to the SID "Si" on the router "R0". The forwarding behavior for PUSH and CONTINUE corresponding to the SID "Si" o If the neighbor "N" does not support SR or advertises an invalid SRGB or a SRGB that is too small for the SID "Si" o If it is possible to send the packet towards the neighbor "N" using standard MPLS forwarding behavior as specified in [RFC3031] and [RFC3032], then forward the packet. The method by which a router decides whether it is possible to send the packet to "N" or not is beyond the scope of this document. For example, the router "R0" can use the downstream label determined by another MCC, such as LDP [RFC5036], to send the packet. Filsfils, et al. Expires November 1, 2019 [Page 17] Internet-Draft Segment Routing with MPLS May 2019 o Else if there are other useable next-hops, then use other next- hops to forward the incoming packet. The method by which the router "R0" decides on the possibility of using other next- hops is beyond the scope of this document. For example, the MCC on "R0" may chose the send an IPv4 packet without pushing any label to another next-hop. o Otherwise drop the packet. o Else o Calculate the outgoing label as specified in Section 2.4 using the SRGB of the neighbor "N" o If the operation is PUSH . Push the calculated label according to the MPLS label pushing rules specified in [RFC3032] o Else . swap the incoming label with the calculated label according to the label swapping rules in [RFC3032] o Send the packet towards the neighbor "N" 2.10.2. Forwarding for NEXT Operation for Global SIDs As specified in Section 2.7.3 NEXT operation corresponds to popping the top most label. The forwarding behavior is as follows o Pop the topmost label o Apply the instruction associated with the incoming label that has been popped The action on the packet after popping the topmost label depends on the instruction associated with the incoming label as well as the contents of the packet right underneath the top label that got popped. Examples of NEXT operation are described in Appendix A.1. 2.11. Forwarding Behavior for Local SIDs This section specifies the forwarding behavior for local SIDs when SR is instantiated over the MPLS forwarding plane. Filsfils, et al. Expires November 1, 2019 [Page 18] Internet-Draft Segment Routing with MPLS May 2019 2.11.1. Forwarding for PUSH Operation on Local SIDs Suppose an MCC on a router "R0" determines that PUSH operation is to be applied to an incoming packet using the local SID "Si" before sending the packet towards a neighbor "N" directly connected to R0 through a physical or virtual interface such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. An example of such local SID is an Adj-SID allocated and advertised by IS-IS [I-D.ietf-isis-segment-routing-extensions]. The method by which the MCC on "R0" determines that PUSH operation is to be applied to the incoming packet is beyond the scope of this document. An example of such method is backup path used to protect against a failure using TI-LFA [I-D.bashandy-rtgwg-segment-routing-ti-lfa]. As mentioned in [RFC8402], a local SID is specified by an MPLS label. Hence the PUSH operation for a local SID is identical to label push operation [RFC3032] using any MPLS label. The forwarding action after pushing the MPLS label corresponding to the local SID is also determined by the MCC. For example, if the PUSH operation was done to forward a packet over a backup path calculated using TI-LFA, then the forwarding action may be sending the packet to a certain neighbor that will in turn continue to forward the packet along the backup path 2.11.2. Forwarding for CONTINUE Operation for Local SIDs A local SID on a router "R0" corresponds to a local label. In such scenario, the outgoing label towards a next-hop "N" is determined by the MCC running on the router "R0"and the forwarding behavior for CONTINUE operation is identical to swap operation [RFC3032] on an MPLS label. 2.11.3. Outgoing label for NEXT Operation for Local SIDs NEXT operation for Local SIDs is identical to NEXT operation for global SIDs specified in Section 2.10.2. 3. IANA Considerations This document does not make any request to IANA. Filsfils, et al. Expires November 1, 2019 [Page 19] Internet-Draft Segment Routing with MPLS May 2019 4. Manageability Considerations This document describes the applicability of Segment Routing over the MPLS data plane. Segment Routing does not introduce any change in the MPLS data plane. Manageability considerations described in [RFC8402] applies to the MPLS data plane when used with Segment Routing. SR OAM use cases for the MPLS data plane are defined in [RFC8403]. SR OAM procedures for the MPLS data plane are defined in [RFC8287]. 5. Security Considerations This document does not introduce additional security requirements and mechanisms other than the ones described in [RFC8402]. 6. Contributors The following contributors have substantially helped the definition and editing of the content of this document: Martin Horneffer Deutsche Telekom Email: Martin.Horneffer@telekom.de Wim Henderickx Nokia Email: wim.henderickx@nokia.com Jeff Tantsura Email: jefftant@gmail.com Edward Crabbe Email: edward.crabbe@gmail.com Igor Milojevic Email: milojevicigor@gmail.com Saku Ytti Email: saku@ytti.fi 7. Acknowledgements The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on this document. Filsfils, et al. Expires November 1, 2019 [Page 20] Internet-Draft Segment Routing with MPLS May 2019 This document was prepared using 2-Word-v2.0.template.dot. 8. References 8.1. Normative References [RFC8402] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402 July 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 0.17487/RFC2119, March 1997, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [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, . [RFC3443] P. Agarwal, P. and Akyol, B. "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, . [RFC5462] Andersson, L., and Asati, R., " Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, . [RFC7274] K. Kompella, L. Andersson, and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC7274 DOI 10.17487/RFC7274, May 2014 [RFC8174] B. Leiba, " Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC8174 DOI 10.17487/RFC8174, May 2017 Filsfils, et al. Expires November 1, 2019 [Page 21] Internet-Draft Segment Routing with MPLS May 2019 8.2. Informative References [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and j. jefftant@gmail.com, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing-extensions-13 (work in progress), June 2017. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- extensions-09 (work in progress), March 2017. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft- ietf-ospf-segment-routing-extensions-16 (work in progress), May 2017. [I-D.ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment- routing-ldp-interop-08 (work in progress), June 2017. [I-D.bashandy-rtgwg-segment-routing-ti-lfa], Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Francois, P., Voyer, P. Clad, F., and Camarillo, P., "Topology Independent Fast Reroute using Segment Routing", draft-bashandy-rtgwg- segment-routing-ti-lfa-05 (work in progress), October 2018, [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . [RFC5036] Andersson, L., Acreo, AB, Minei, I., Thomas, B., " LDP Specification", RFC5036, DOI 10.17487/RFC5036, October 2007, [RFC5331] Aggarwal, R., Rekhter, Y., Rosen, E., " MPLS Upstream Label Assignment and Context-Specific Label Space", RFC5331 DOI 10.17487/RFC5331, August 2008, . Filsfils, et al. Expires November 1, 2019 [Page 22] Internet-Draft Segment Routing with MPLS May 2019 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., Young, T., "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC4817, DOI 10.17487/RFC4817, March 2007, [RFC8287] N. Kumar, C. Pignataro, G. Swallow, N. Akiya, S. Kini, and M. Chen " Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes" RFC8287, DOI 10.17487/RFC8287, December 2017, https://www.rfc- editor.org/info/rfc8287 [RFC8403] R. Geib, C. Filsfils, C. Pignataro, N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC8403, DOI 10.17487/RFC8403, July 2018, [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., Raza, K., Liste, J. , Clad, F., Voyer, D., Bogdanov, A., Mattes, P., " Segment Routing Policy for Traffic Engineering", draft-ietf-spring-segment-routing-policy-01 (work in progress), June 2018 Filsfils, et al. Expires November 1, 2019 [Page 23] Internet-Draft Segment Routing with MPLS May 2019 9. Authors' Addresses Ahmed Bashandy (editor) Arrcus Email: abashandy.ietf@gmail.com Clarence Filsfils (editor) Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Stefano Previdi Cisco Systems, Inc. Italy Email: stefano@previdi.net Bruno Decraene Orange FR Email: bruno.decraene@orange.com Filsfils, et al. Expires November 1, 2019 [Page 24] Internet-Draft Segment Routing with MPLS May 2019 Stephane Litkowski Orange FR Email: stephane.litkowski@orange.com Rob Shakir Google US Email: robjs@google.com Filsfils, et al. Expires November 1, 2019 [Page 25] Internet-Draft Segment Routing with MPLS May 2019 Appendix A. Examples A.1. IGP Segments Example Consider the network diagram of Figure 1 and the IP address and IGP Segment allocation of Figure 2. Assume that the network is running IS-IS with SR extensions [I-D.ietf-isis-segment-routing-extensions] and all links have the same metric. The following examples can be constructed. +--------+ / \ R0-----R1-----R2----------R3-----R8 | \ / | | +--R4--+ | | | +-----R5-----+ Figure 1: IGP Segments - Illustration Filsfils, et al. Expires November 1, 2019 [Page 26] Internet-Draft Segment Routing with MPLS May 2019 +-----------------------------------------------------------+ | IP address allocated by the operator: | | 192.0.2.1/32 as a loopback of R1 | | 192.0.2.2/32 as a loopback of R2 | | 192.0.2.3/32 as a loopback of R3 | | 192.0.2.4/32 as a loopback of R4 | | 192.0.2.5/32 as a loopback of R5 | | 192.0.2.8/32 as a loopback of R8 | | 198.51.100.9/32 as an anycast loopback of R4 | | 198.51.100.9/32 as an anycast loopback of R5 | | | | SRGB defined by the operator as 1000-5000 | | | | Global IGP SID indices allocated by the operator: | | 1 allocated to 192.0.2.1/32 | | 2 allocated to 192.0.2.2/32 | | 3 allocated to 192.0.2.3/32 | | 4 allocated to 192.0.2.4/32 | | 8 allocated to 192.0.2.8/32 | | 1009 allocated to 198.51.100.9/32 | | | | Local IGP SID allocated dynamically by R2 | | for its "north" adjacency to R3: 9001 | | for its "east" adjacency to R3 : 9002 | | for its "south" adjacency to R3: 9003 | | for its only adjacency to R4 : 9004 | | for its only adjacency to R1 : 9005 | +-----------------------------------------------------------+ Figure 2: IGP Address and Segment Allocation - Illustration Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1 needs to apply PUSH operation to the IPv4 packet. Remember that the SID index "8" is a global IGP segment attached to the IP prefix 192.0.2.8/32. Its semantic is global within the IGP domain: any router forwards a packet received with active segment 8 to the next-hop along the ECMP-aware shortest-path to the related prefix. R2 is the next-hop along the shortest path towards R8. By applying the steps in Section 2.8 the outgoing label downloaded to R1's FIB corresponding to the global SID index 8 is 1008 because the SRGB of R2 is [1000,5000] as shown in Figure 2. Filsfils, et al. Expires November 1, 2019 [Page 27] Internet-Draft Segment Routing with MPLS May 2019 Because the packet is IPv4, R1 applies the PUSH operation using the label value 1008 as specified in Section 2.10.1. The resulting MPLS header will have the "S" bit [RFC3032] set because it is followed directly by an IPv4 packet. The packet arrives at router R2. Because the top label 1008 corresponds to the IGP SID "8", which is the prefix-SID attached to the prefix 192.0.2.8/32 owned by the node R8, then the instruction associated with the SID is "forward the packet using all ECMP/UCMP interfaces and all ECMP/UCMP next-hop(s) along the shortest/useable path(s) towards R8". Because R2 is not the penultimate hop, R2 applies the CONTINUE operation to the packet and sends it to R3 using one of the two links connected to R3 with top label 1008 as specified in Section 2.10.1. R3 receives the packet with top label 1008. Because the top label 1008 corresponds to the IGP SID "8", which is the prefix-SID attached to the prefix 192.0.2.8/32 owned by the node R8, then the instruction associated with the SID is "send the packet using all ECMP interfaces and all next-hop(s) along the shortest path towards R8". Because R3 is the penultimate hop, we assume that R3 performs penumtimate hop popping, which corresponds to the NEXT operation, then sends the packet to R8. The NEXT operation results in popping the outer label and sending the packet as a pure IPv4 packet to R8. In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- awareness ensures that the traffic be load-shared between any ECMP path, in this case the two links between R2 and R3. A.2. Incoming Label Collision Examples This section describes few examples to illustrate the handling of label collision described in Section 2.5. For the examples in this section, we assume that Node A has the following: o OSPF default admin distance for implementation=50 o ISIS default admin distance for implementation=60 A.2.1. Example 1 Illustration of incoming label collision resolution for the same FEC type using MCC administrative distance. Filsfils, et al. Expires November 1, 2019 [Page 28] Internet-Draft Segment Routing with MPLS May 2019 FEC1: o OSPF prefix SID advertisement from node B for 198.51.100.5/32 with index=5 o OSPF SRGB on node A = [1000,1999] o Incoming label=1005 FEC2: o ISIS prefix SID advertisement from node C for 203.0.113.105/32 with index=5 o ISIS SRGB on node A = [1000,1999] o Incoming label=1005 FEC1 and FEC2 both use dynamic SID assignment. Since neither ofthe FEC types is SR Policy, we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins. A.2.2. Example 2 Illustration of incoming label collision resolution for different FEC types using the MCC administrative distance. FEC1: o Node A receives an OSPF prefix sid advertisement from node B for 198.51.100.6/32 with index=6 o OSPF SRGB on node A = [1000,1999] o Hence the incoming label on node A corresponding to 198.51.100.6/32 is 1006 FEC2: ISIS on node A assigns the label 1006 to the globally significant adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID sub-TLV as described in [I-D.ietf-isis-segment-routing-extensions]) towards one of its neighbors. Hence the incoming label corresponding to this adj-SID 1006. Assume Node A allocates this adj-SID dynamically, and it may differ across router reboots. Filsfils, et al. Expires November 1, 2019 [Page 29] Internet-Draft Segment Routing with MPLS May 2019 FEC1 and FEC2 both use dynamic SID assignment. Since neither of the FEC types is SR Policy, we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins. A.2.3. Example 3 Illustration of incoming label collision resolution based on preferring static over dynamic SID assignment FEC1: OSPF on node A receives a prefix SID advertisement from node B for 198.51.100.7/32 with index=7. Assuming that the OSPF SRGB on node A is [1000,1999], then incoming label corresponding to 198.51.100.7/32 is 1007 FEC2: The operator on node A configures ISIS on node A to assign the label 1007 to the globally significant adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID sub-TLV as described in [I-D.ietf- isis-segment-routing-extensions]) towards one of its neighbor advertisement from node A with label=1007 Node A assigns this adj-SID explicitly via configuration, so the adj- SID survives router reboots. FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID assignment. So FEC2 wins. A.2.4. Example 4 Illustration of incoming label collision resolution using FEC type default administrative distance FEC1: OSPF on node A receives a prefix SID advertisement from node B for 198.51.100.8/32 with index=8. Assuming that OSPF SRGB on node A = [1000,1999], the incoming label corresponding to 198.51.100.8/32 is 1008. FEC2: Suppose the SR Policy advertisement from controller to node A for the policy identified by (Endpoint = 192.0.2.208, color = 100) and Filsfils, et al. Expires November 1, 2019 [Page 30] Internet-Draft Segment Routing with MPLS May 2019 consisting of SID-List = assigns the globally significant Binding-SID label 1008 From the point of view of node A, FEC1 and FEC2 both use dynamic SID assignment. Based on the default administrative distance outlined in Section 2.5.1, the binding SID has a higher administrative distance than the prefix-SID and hence FEC1 wins. A.2.5. Example 5 Illustration of incoming label collision resolution based on FEC type preference FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.110/32 with index=10. Assuming that the ISIS SRGB on node A is [1000,1999], then incoming label corresponding to 203.0.113.110/32 is 1010. FEC2: ISIS on node A assigns the label 1010 to the globally significant adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID sub-TLV as described in [I-D.ietf-isis-segment-routing-extensions]) towards one of its neighbors). Node A allocates this adj-SID dynamically, and it may differ across router reboots. Hence both FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. FEC1 has FEC type code-point=120, while FEC2 has FEC type code-point=130. Therefore, FEC1 wins. A.2.6. Example 6 Illustration of incoming label collision resolution based on address family preference. FEC1: ISIS on node A receives prefix SID advertisement from node B for 203.0.113.111/32 with index 11. Assuming that the ISIS SRGB on node A is [1000,1999], the incoming label on node A for 203.0.113.111/32 is 1011. Filsfils, et al. Expires November 1, 2019 [Page 31] Internet-Draft Segment Routing with MPLS May 2019 FEC2: ISIS on node A prefix SID advertisement from node C for 2001:DB8:1000::11/128 with index=11. Assuming that the ISIS SRGB on node A is [1000,1999], the incoming label on node A for 2001:DB8:1000::11/128 is 1011 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. Both FECs have FEC type code-point=120. So we compare address family. Since IPv4 is preferred over IPv6, FEC1 wins. A.2.7. Example 7 Illustration incoming label collision resolution based on prefix length. FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.112/32 with index 12. Assuming that ISIS SRGB on node A is [1000,1999], the incoming label for 203.0.113.112/32 on node A is 1012. FEC2: ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.128/30 with index 12. Assuming that the ISIS SRGB on node A is [1000,1999], then incoming label for 203.0.113.128/30 on node A is 1012 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. Both FECs have FEC type code-point=120. So we compare address family. Both are IPv4 address family, so we compare prefix length. FEC1 has prefix length=32, and FEC2 has prefix length=30, so FEC2 wins. A.2.8. Example 8 Illustration of incoming label collision resolution based on the numerical value of the FECs. FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.113/32 with index 13. Assuming that ISIS SRGB on node A is Filsfils, et al. Expires November 1, 2019 [Page 32] Internet-Draft Segment Routing with MPLS May 2019 [1000,1999], then the incoming label for 203.0.113.113/32 on node A is 1013 FEC2: ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.213/32 with index 13. Assuming that ISIS SRGB on node A is [1000,1999], then the incoming label for 203.0.113.213/32 on node A is 1013 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. Both FECs have FEC type code-point=120. So we compare address family. Both are IPv4 address family, so we compare prefix length. Prefix lengths are the same, so we compare prefix. FEC1 has the lower prefix, so FEC1 wins. A.2.9. Example 9 Illustration of incoming label collision resolution based on routing instance ID. FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.114/32 with index 14. Assume that this ISIS instance on node A has the Routing Instance ID 1000 and SRGB [1000,1999]. Hence the incoming label for 203.0.113.114/32 on node A is 1014 FEC2: ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.114/32 with index=14. Assume that this is another instance of ISIS on node A with a different routing Instance ID 2000 but the same SRGB [1000,1999]. Hence incoming label for 203.0.113.114/32 on node A 1014 These two FECs match all the way through the prefix length and prefix. So Routing Instance ID breaks the tie, with FEC1 winning. A.2.10. Example 10 Illustration of incoming label collision resolution based on topology ID. FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.115/32 with index=15. Assume that this ISIS instance on Filsfils, et al. Expires November 1, 2019 [Page 33] Internet-Draft Segment Routing with MPLS May 2019 node A has Routing Instance ID 1000. Assume that the prefix advertisement of 203.0.113.115/32 was received in ISIS Multi-topology advertisement with ID = 50. If the ISIS SRGB for this routing instance on node A is [1000,1999], then incoming label of 203.0.113.115/32 for topology 50 on node A is 1015 FEC2: ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.115/32 with index 15. Assume that it is the same routing Instance ID = 1000 but 203.0.113.115/32 was advertised with a different ISIS Multi-topology ID = 40. If the ISIS SRGB on node A is [1000,1999], then incoming label of 203.0.113.115/32 for topology 40 on node A is also 1015 These two FECs match all the way through the prefix length, prefix, and Routing Instance ID. We compare ISIS Multi-topology ID, so FEC2 wins. A.2.11. Example 11 Illustration of incoming label collision for resolution based on algorithm ID. FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.116/32 with index=16 Assume that ISIS on node A has Routing Instance ID = 1000. Assume that node B advertised 203.0.113.116/32 with ISIS Multi-topology ID = 50 and SR algorithm = 0. Assume that the ISIS SRGB on node A = [1000,1999]. Hence the incoming label corresponding to this advertisement of 203.0.113.116/32 is 1016. FEC2: ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.116/32 with index=16. Assume that it is the same ISIS instance on node A with Routing Instance ID = 1000. Also assume that node C advertised 203.0.113.116/32 with ISIS Multi-topology ID = 50 but with SR algorithm = 22. Since it is the same routing instance, the SRGB on node A = [1000,1999]. Hence the incoming label corresponding to this advertisement of 203.0.113.116/32 by node C is also 1016. Filsfils, et al. Expires November 1, 2019 [Page 34] Internet-Draft Segment Routing with MPLS May 2019 These two FECs match all the way through the prefix length, prefix, and Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so FEC1 wins. A.2.12. Example 12 Illustration of incoming label collision resolution based on FEC numerical value and independent of how the SID assigned to the colliding FECs. FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.117/32 with index 17. Assume that the ISIS SRGB on node A is [1000,1999], then the incoming label is 1017 FEC2: Suppose there is an ISIS mapping server advertisement (SID/Label Binding TLV) from node D has Range 100 and Prefix = 203.0.113.1/32. Suppose this mapping server advertisement generates 100 mappings, one of which maps 203.0.113.17/32 to index 17. Assuming that it is the same ISIS instance, then the SRGB is [1000,1999] and hence the incoming label for 1017. The fact that FEC1 comes from a normal prefix SID advertisement and FEC2 is generated from a mapping server advertisement is not used as a tie-breaking parameter. Both FECs use dynamic SID assignment, are from the same MCC, have the same FEC type code-point=120. Their prefix lengths are the same as well. FEC2 wins based on lower numerical prefix value, since 203.0.113.17 is less than 203.0.113.117. A.2.13. Example 13 Illustration of incoming label collision resolution based on address family preference FEC1: SR Policy advertisement from controller to node A. Endpoint address=2001:DB8:3000::100, color=100, SID-List= and the Binding-SID label=1020 FEC2: SR Policy advertisement from controller to node A. Endpoint address=192.0.2.60, color=100, SID-List= and the Binding-SID label=1020 Filsfils, et al. Expires November 1, 2019 [Page 35] Internet-Draft Segment Routing with MPLS May 2019 The FECs match through the tie-breaks up to and including having the same FEC type code-point=140. FEC2 wins based on IPv4 address family being preferred over IPv6. A.2.14. Example 14 Illustration of incoming label resolution based on numerical value of the policy endpoint. FEC1: SR Policy advertisement from controller to node A. Endpoint address=192.0.2.70, color=100, SID-List= and Binding-SID label=1021 FEC2: SR Policy advertisement from controller to node A Endpoint address=192.0.2.71, color=100, SID-List= and Binding-SID label=1021 The FECs match through the tie-breaks up to and including having the same address family. FEC1 wins by having the lower numerical endpoint address value. A.3. Examples for the Effect of Incoming Label Collision on Outgoing Label This section presents examples to illustrate the effect of incoming label collision on the selection of the outgoing label described in Section 2.6. A.3.1. Example 1 Illustration of the effect of incoming label resolution on the outgoing label FEC1: ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.122/32 with index 22. Assuming that the ISIS SRGB on node A is [1000,1999] the corresponding incoming label is 1022. FEC2: ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.222/32 with index=22 Assuming that the ISIS SRGB on node A is [1000,1999] the corresponding incoming label is 1022. Filsfils, et al. Expires November 1, 2019 [Page 36] Internet-Draft Segment Routing with MPLS May 2019 FEC1 wins based on lowest numerical prefix value. This means that node A installs a transit MPLS forwarding entry to SWAP incoming label 1022, with outgoing label N and use outgoing interface I. N is determined by the index associated with FEC1 (index 22) and the SRGB advertised by the next-hop node on the shortest path to reach 203.0.113.122/32. Node A will generally also install an imposition MPLS forwarding entry corresponding to FEC1 for incoming prefix=203.0.113.122/32 pushing outgoing label N, and using outgoing interface I. The rule in Section 2.6 means node A MUST NOT install an ingress MPLS forwarding entry corresponding to FEC2 (the losing FEC, which would be for prefix 203.0.113.222/32). A.3.2. Example 2 Illustration of the effect of incoming label collision resolution on outgoing label programming on node A FEC1: o SR Policy advertisement from controller to node A o Endpoint address=192.0.2.80, color=100, SID-List= o Binding-SID label=1023 FEC2: o SR Policy advertisement from controller to node A o Endpoint address=192.0.2.81, color=100, SID-List= o Binding-SID label=1023 FEC1 wins by having the lower numerical endpoint address value. This means that node A installs a transit MPLS forwarding entry to SWAP incoming label=1023, with outgoing labels and outgoing interface determined by the SID-List for FEC1. In this example, we assume that node A receives two BGP/VPN routes: o R1 with VPN label=V1, BGP next-hop = 192.0.2.80, and color=100, o R2 with VPN label=V2, BGP next-hop = 192.0.2.81, and color=100, Filsfils, et al. Expires November 1, 2019 [Page 37] Internet-Draft Segment Routing with MPLS May 2019 We also assume that A has a BGP policy which matches on color=100 that allows that its usage as SLA steering information. In this case, node A will install a VPN route with label stack = (corresponding to FEC1). The rule described in section 2.6 means that node A MUST NOT install a VPN route with label stack = (corresponding to FEC2.) Filsfils, et al. Expires November 1, 2019 [Page 38] ./draft-ietf-spring-segment-routing-msdc-11.txt0000644000764400076440000013077613400064434020741 0ustar iustyiusty Network Working Group C. Filsfils, Ed. Internet-Draft S. Previdi Intended status: Informational Cisco Systems, Inc. Expires: June 2, 2019 G. Dawra LinkedIn E. Aries Juniper Networks P. Lapukhov Facebook November 29, 2018 BGP-Prefix Segment in large-scale data centers draft-ietf-spring-segment-routing-msdc-11 Abstract This document describes the motivation and benefits for applying segment routing in BGP-based large-scale data-centers. It describes the design to deploy segment routing in those data-centers, for both the MPLS and IPv6 dataplanes. 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 https://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 2, 2019. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Filsfils, et al. Expires June 2, 2019 [Page 1] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 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. Large Scale Data Center Network Design Summary . . . . . . . 3 2.1. Reference design . . . . . . . . . . . . . . . . . . . . 4 3. Some open problems in large data-center networks . . . . . . 5 4. Applying Segment Routing in the DC with MPLS dataplane . . . 6 4.1. BGP Prefix Segment (BGP-Prefix-SID) . . . . . . . . . . . 6 4.2. eBGP Labeled Unicast (RFC8277) . . . . . . . . . . . . . 6 4.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 8 4.2.3. Network Design Variation . . . . . . . . . . . . . . 9 4.2.4. Global BGP Prefix Segment through the fabric . . . . 10 4.2.5. Incremental Deployments . . . . . . . . . . . . . . . 10 4.3. iBGP Labeled Unicast (RFC8277) . . . . . . . . . . . . . 11 5. Applying Segment Routing in the DC with IPv6 dataplane . . . 13 6. Communicating path information to the host . . . . . . . . . 13 7. Additional Benefits . . . . . . . . . . . . . . . . . . . . . 14 7.1. MPLS Dataplane with operational simplicity . . . . . . . 14 7.2. Minimizing the FIB table . . . . . . . . . . . . . . . . 14 7.3. Egress Peer Engineering . . . . . . . . . . . . . . . . . 15 7.4. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Preferred SRGB Allocation . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Manageability Considerations . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Segment Routing (SR), as described in [I-D.ietf-spring-segment-routing] leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path while Filsfils, et al. Expires June 2, 2019 [Page 2] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the MPLS and IPv6 data-planes. The use-cases described in this document should be considered in the context of the BGP-based large-scale data-center (DC) design described in [RFC7938]. This document extends it by applying SR both with IPv6 and MPLS dataplane. 2. Large Scale Data Center Network Design Summary This section provides a brief summary of the informational document [RFC7938] that outlines a practical network design suitable for data- centers of various scales: o Data-center networks have highly symmetric topologies with multiple parallel paths between two server attachment points. The well-known Clos topology is most popular among the operators (as described in [RFC7938]). In a Clos topology, the minimum number of parallel paths between two elements is determined by the "width" of the "Tier-1" stage. See Figure 1 below for an illustration of the concept. o Large-scale data-centers commonly use a routing protocol, such as BGP-4 [RFC4271] in order to provide endpoint connectivity. Recovery after a network failure is therefore driven either by local knowledge of directly available backup paths or by distributed signaling between the network devices. o Within data-center networks, traffic is load-shared using the Equal Cost Multipath (ECMP) mechanism. With ECMP, every network device implements a pseudo-random decision, mapping packets to one of the parallel paths by means of a hash function calculated over certain parts of the packet, typically a combination of various packet header fields. The following is a schematic of a five-stage Clos topology, with four devices in the "Tier-1" stage. Notice that number of paths between Node1 and Node12 equals to four: the paths have to cross all of Tier-1 devices. At the same time, the number of paths between Node1 and Node2 equals two, and the paths only cross Tier-2 devices. Other topologies are possible, but for simplicity only the topologies that have a single path from Tier-1 to Tier-3 are considered below. The rest could be treated similarly, with a few modifications to the logic. Filsfils, et al. Expires June 2, 2019 [Page 3] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 2.1. Reference design Tier-1 +-----+ |NODE | +->| 5 |--+ | +-----+ | Tier-2 | | Tier-2 +-----+ | +-----+ | +-----+ +------------>|NODE |--+->|NODE |--+--|NODE |-------------+ | +-----| 3 |--+ | 6 | +--| 9 |-----+ | | | +-----+ +-----+ +-----+ | | | | | | | | +-----+ +-----+ +-----+ | | | +-----+---->|NODE |--+ |NODE | +--|NODE |-----+-----+ | | | | +---| 4 |--+->| 7 |--+--| 10 |---+ | | | | | | | +-----+ | +-----+ | +-----+ | | | | | | | | | | | | | | +-----+ +-----+ | +-----+ | +-----+ +-----+ |NODE | |NODE | Tier-3 +->|NODE |--+ Tier-3 |NODE | |NODE | | 1 | | 2 | | 8 | | 11 | | 12 | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | A O B O <- Servers -> Z O O O Figure 1: 5-stage Clos topology In the reference topology illustrated in Figure 1, It is assumed: o Each node is its own AS (Node X has AS X). 4-byte AS numbers are recommended ([RFC6793]). * For simple and efficient route propagation filtering, Node5, Node6, Node7 and Node8 use the same AS, Node3 and Node4 use the same AS, Node9 and Node10 use the same AS. * In case of 2-byte autonomous system numbers are used and for efficient usage of the scarce 2-byte Private Use AS pool, different Tier-3 nodes might use the same AS. * Without loss of generality, these details will be simplified in this document and assume that each node has its own AS. o Each node peers with its neighbors with a BGP session. If not specified, eBGP is assumed. In a specific use-case, iBGP will be used but this will be called out explicitly in that case. Filsfils, et al. Expires June 2, 2019 [Page 4] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 o Each node originates the IPv4 address of its loopback interface into BGP and announces it to its neighbors. * The loopback of Node X is 192.0.2.x/32. In this document, the Tier-1, Tier-2 and Tier-3 nodes are referred to respectively as Spine, Leaf and ToR (top of rack) nodes. When a ToR node acts as a gateway to the "outside world", it is referred to as a border node. 3. Some open problems in large data-center networks The data-center network design summarized above provides means for moving traffic between hosts with reasonable efficiency. There are few open performance and reliability problems that arise in such design: o ECMP routing is most commonly realized per-flow. This means that large, long-lived "elephant" flows may affect performance of smaller, short-lived "mouse" flows and reduce efficiency of per- flow load-sharing. In other words, per-flow ECMP does not perform efficiently when flow lifetime distribution is heavy-tailed. Furthermore, due to hash-function inefficiencies it is possible to have frequent flow collisions, where more flows get placed on one path over the others. o Shortest-path routing with ECMP implements an oblivious routing model, which is not aware of the network imbalances. If the network symmetry is broken, for example due to link failures, utilization hotspots may appear. For example, if a link fails between Tier-1 and Tier-2 devices (e.g. Node5 and Node9), Tier-3 devices Node1 and Node2 will not be aware of that, since there are other paths available from perspective of Node3. They will continue sending roughly equal traffic to Node3 and Node4 as if the failure didn't exist which may cause a traffic hotspot. o Isolating faults in the network with multiple parallel paths and ECMP-based routing is non-trivial due to lack of determinism. Specifically, the connections from HostA to HostB may take a different path every time a new connection is formed, thus making consistent reproduction of a failure much more difficult. This complexity scales linearly with the number of parallel paths in the network, and stems from the random nature of path selection by the network devices. First, it will be explained how to apply SR in the DC, for MPLS and IPv6 data-planes. Filsfils, et al. Expires June 2, 2019 [Page 5] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 4. Applying Segment Routing in the DC with MPLS dataplane 4.1. BGP Prefix Segment (BGP-Prefix-SID) A BGP Prefix Segment is a segment associated with a BGP prefix. A BGP Prefix Segment is a network-wide instruction to forward the packet along the ECMP-aware best path to the related prefix. The BGP Prefix Segment is defined as the BGP-Prefix-SID Attribute in [I-D.ietf-idr-bgp-prefix-sid] which contains an index. Throughout this document the BGP Prefix Segment Attribute is referred as the BGP-Prefix-SID and the encoded index as the label-index. In this document, the network design decision has been made to assume that all the nodes are allocated the same SRGB (Segment Routing Global Block), e.g. [16000, 23999]. This provides operational simplification as explained in Section 8, but this is not a requirement. For illustration purpose, when considering an MPLS data-plane, it is assumed that the label-index allocated to prefix 192.0.2.x/32 is X. As a result, a local label (16000+x) is allocated for prefix 192.0.2.x/32 by each node throughout the DC fabric. When IPv6 data-plane is considered, it is assumed that Node X is allocated IPv6 address (segment) 2001:DB8::X. 4.2. eBGP Labeled Unicast (RFC8277) Referring to Figure 1 and [RFC7938], the following design modifications are introduced: o Each node peers with its neighbors via a eBGP session with extensions defined in [RFC8277] (named "eBGP8277" throughout this document) and with the BGP-Prefix-SID attribute extension as defined in [I-D.ietf-idr-bgp-prefix-sid]. o The forwarding plane at Tier-2 and Tier-1 is MPLS. o The forwarding plane at Tier-3 is either IP2MPLS (if the host sends IP traffic) or MPLS2MPLS (if the host sends MPLS- encapsulated traffic). Figure 2 zooms into a path from server A to server Z within the topology of Figure 1. Filsfils, et al. Expires June 2, 2019 [Page 6] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 +-----+ +-----+ +-----+ +---------->|NODE | |NODE | |NODE | | | 4 |--+->| 7 |--+--| 10 |---+ | +-----+ +-----+ +-----+ | | | +-----+ +-----+ |NODE | |NODE | | 1 | | 11 | +-----+ +-----+ | | A <- Servers -> Z Figure 2: Path from A to Z via nodes 1, 4, 7, 10 and 11 Referring to Figure 1 and Figure 2 and assuming the IP address with the AS and label-index allocation previously described, the following sections detail the control plane operation and the data plane states for the prefix 192.0.2.11/32 (loopback of Node11) 4.2.1. Control Plane Node11 originates 192.0.2.11/32 in BGP and allocates to it a BGP- Prefix-SID with label-index: index11 [I-D.ietf-idr-bgp-prefix-sid]. Node11 sends the following eBGP8277 update to Node10: . IP Prefix: 192.0.2.11/32 . Label: Implicit-Null . Next-hop: Node11's interface address on the link to Node10 . AS Path: {11} . BGP-Prefix-SID: Label-Index 11 Node10 receives the above update. As it is SR capable, Node10 is able to interpret the BGP-Prefix-SID and hence understands that it should allocate the label from its own SRGB block, offset by the Label-Index received in the BGP-Prefix-SID (16000+11 hence 16011) to the NLRI instead of allocating a non-deterministic label out of a dynamically allocated portion of the local label space. The implicit-null label in the NLRI tells Node10 that it is the penultimate hop and must pop the top label on the stack before forwarding traffic for this prefix to Node11. Then, Node10 sends the following eBGP8277 update to Node7: Filsfils, et al. Expires June 2, 2019 [Page 7] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 . IP Prefix: 192.0.2.11/32 . Label: 16011 . Next-hop: Node10's interface address on the link to Node7 . AS Path: {10, 11} . BGP-Prefix-SID: Label-Index 11 Node7 receives the above update. As it is SR capable, Node7 is able to interpret the BGP-Prefix-SID and hence allocates the local (incoming) label 16011 (16000 + 11) to the NLRI (instead of allocating a "dynamic" local label from its label manager). Node7 uses the label in the received eBGP8277 NLRI as the outgoing label (the index is only used to derive the local/incoming label). Node7 sends the following eBGP8277 update to Node4: . IP Prefix: 192.0.2.11/32 . Label: 16011 . Next-hop: Node7's interface address on the link to Node4 . AS Path: {7, 10, 11} . BGP-Prefix-SID: Label-Index 11 Node4 receives the above update. As it is SR capable, Node4 is able to interpret the BGP-Prefix-SID and hence allocates the local (incoming) label 16011 to the NLRI (instead of allocating a "dynamic" local label from its label manager). Node4 uses the label in the received eBGP8277 NLRI as outgoing label (the index is only used to derive the local/incoming label). Node4 sends the following eBGP8277 update to Node1: . IP Prefix: 192.0.2.11/32 . Label: 16011 . Next-hop: Node4's interface address on the link to Node1 . AS Path: {4, 7, 10, 11} . BGP-Prefix-SID: Label-Index 11 Node1 receives the above update. As it is SR capable, Node1 is able to interpret the BGP-Prefix-SID and hence allocates the local (incoming) label 16011 to the NLRI (instead of allocating a "dynamic" local label from its label manager). Node1 uses the label in the received eBGP8277 NLRI as outgoing label (the index is only used to derive the local/incoming label). 4.2.2. Data Plane Referring to Figure 1, and assuming all nodes apply the same advertisement rules described above and all nodes have the same SRGB Filsfils, et al. Expires June 2, 2019 [Page 8] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 (16000-23999), here are the IP/MPLS forwarding tables for prefix 192.0.2.11/32 at Node1, Node4, Node7 and Node10. ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | 16011 | ECMP{3, 4} 192.0.2.11/32 | 16011 | ECMP{3, 4} ------------------+----------------+----------- Figure 3: Node1 Forwarding Table ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | 16011 | ECMP{7, 8} 192.0.2.11/32 | 16011 | ECMP{7, 8} ------------------+----------------+----------- Figure 4: Node4 Forwarding Table ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | 16011 | 10 192.0.2.11/32 | 16011 | 10 ------------------+----------------+----------- Figure 5: Node7 Forwarding Table ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | POP | 11 192.0.2.11/32 | N/A | 11 ------------------+----------------+----------- Node10 Forwarding Table 4.2.3. Network Design Variation A network design choice could consist of switching all the traffic through Tier-1 and Tier-2 as MPLS traffic. In this case, one could Filsfils, et al. Expires June 2, 2019 [Page 9] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 filter away the IP entries at Node4, Node7 and Node10. This might be beneficial in order to optimize the forwarding table size. A network design choice could consist in allowing the hosts to send MPLS-encapsulated traffic based on the Egress Peer Engineering (EPE) use-case as defined in [I-D.ietf-spring-segment-routing-central-epe]. For example, applications at HostA would send their Z-destined traffic to Node1 with an MPLS label stack where the top label is 16011 and the next label is an EPE peer segment ([I-D.ietf-spring-segment-routing-central-epe]) at Node11 directing the traffic to Z. 4.2.4. Global BGP Prefix Segment through the fabric When the previous design is deployed, the operator enjoys global BGP- Prefix-SID and label allocation throughout the DC fabric. A few examples follow: o Normal forwarding to Node11: a packet with top label 16011 received by any node in the fabric will be forwarded along the ECMP-aware BGP best-path towards Node11 and the label 16011 is penultimate-popped at Node10 (or at Node 9). o Traffic-engineered path to Node11: an application on a host behind Node1 might want to restrict its traffic to paths via the Spine node Node5. The application achieves this by sending its packets with a label stack of {16005, 16011}. BGP Prefix SID 16005 directs the packet up to Node5 along the path (Node1, Node3, Node5). BGP- Prefix-SID 16011 then directs the packet down to Node11 along the path (Node5, Node9, Node11). 4.2.5. Incremental Deployments The design previously described can be deployed incrementally. Let us assume that Node7 does not support the BGP-Prefix-SID and let us show how the fabric connectivity is preserved. From a signaling viewpoint, nothing would change: even though Node7 does not support the BGP-Prefix-SID, it does propagate the attribute unmodified to its neighbors. From a label allocation viewpoint, the only difference is that Node7 would allocate a dynamic (random) label to the prefix 192.0.2.11/32 (e.g. 123456) instead of the "hinted" label as instructed by the BGP- Prefix-SID. The neighbors of Node7 adapt automatically as they always use the label in the BGP8277 NLRI as outgoing label. Filsfils, et al. Expires June 2, 2019 [Page 10] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 Node4 does understand the BGP-Prefix-SID and hence allocates the indexed label in the SRGB (16011) for 192.0.2.11/32. As a result, all the data-plane entries across the network would be unchanged except the entries at Node7 and its neighbor Node4 as shown in the figures below. The key point is that the end-to-end Label Switched Path (LSP) is preserved because the outgoing label is always derived from the received label within the BGP8277 NLRI. The index in the BGP-Prefix- SID is only used as a hint on how to allocate the local label (the incoming label) but never for the outgoing label. ------------------------------------------ Incoming label | outgoing | Outgoing or IP destination | label | Interface -------------------+---------------------- 12345 | 16011 | 10 Figure 7: Node7 Forwarding Table ------------------------------------------ Incoming label | outgoing | Outgoing or IP destination | label | Interface -------------------+---------------------- 16011 | 12345 | 7 Figure 8: Node4 Forwarding Table The BGP-Prefix-SID can thus be deployed incrementally one node at a time. When deployed together with a homogeneous SRGB (same SRGB across the fabric), the operator incrementally enjoys the global prefix segment benefits as the deployment progresses through the fabric. 4.3. iBGP Labeled Unicast (RFC8277) The same exact design as eBGP8277 is used with the following modifications: All nodes use the same AS number. Each node peers with its neighbors via an internal BGP session (iBGP) with extensions defined in [RFC8277] (named "iBGP8277" throughout this document). Filsfils, et al. Expires June 2, 2019 [Page 11] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 Each node acts as a route-reflector for each of its neighbors and with the next-hop-self option. Next-hop-self is a well known operational feature which consists of rewriting the next-hop of a BGP update prior to send it to the neighbor. Usually, it's a common practice to apply next-hop-self behavior towards iBGP peers for eBGP learned routes. In the case outlined in this section it is proposed to use the next-hop-self mechanism also to iBGP learned routes. Cluster-1 +-----------+ | Tier-1 | | +-----+ | | |NODE | | | | 5 | | Cluster-2 | +-----+ | Cluster-3 +---------+ | | +---------+ | Tier-2 | | | | Tier-2 | | +-----+ | | +-----+ | | +-----+ | | |NODE | | | |NODE | | | |NODE | | | | 3 | | | | 6 | | | | 9 | | | +-----+ | | +-----+ | | +-----+ | | | | | | | | | | | | | | +-----+ | | +-----+ | | +-----+ | | |NODE | | | |NODE | | | |NODE | | | | 4 | | | | 7 | | | | 10 | | | +-----+ | | +-----+ | | +-----+ | +---------+ | | +---------+ | | | +-----+ | | |NODE | | Tier-3 | | 8 | | Tier-3 +-----+ +-----+ | +-----+ | +-----+ +-----+ |NODE | |NODE | +-----------+ |NODE | |NODE | | 1 | | 2 | | 11 | | 12 | +-----+ +-----+ +-----+ +-----+ Figure 9: iBGP Sessions with Reflection and Next-Hop-Self For simple and efficient route propagation filtering and as illustrated in Figure 9: Node5, Node6, Node7 and Node8 use the same Cluster ID (Cluster- 1) Filsfils, et al. Expires June 2, 2019 [Page 12] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 Node3 and Node4 use the same Cluster ID (Cluster-2) Node9 and Node10 use the same Cluster ID (Cluster-3) The control-plane behavior is mostly the same as described in the previous section: the only difference is that the eBGP8277 path propagation is simply replaced by an iBGP8277 path reflection with next-hop changed to self. The data-plane tables are exactly the same. 5. Applying Segment Routing in the DC with IPv6 dataplane The design described in [RFC7938] is reused with one single modification. It is highlighted using the example of the reachability to Node11 via spine node Node5. Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID for IPv6 packets destined to segment 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]). Node11 originates 2001:DB8::11/128 with the attached BGP-Prefix-SID advertising the support of the SRH for IPv6 packets destined to segment 2001:DB8::11. The control-plane and data-plane processing of all the other nodes in the fabric is unchanged. Specifically, the routes to 2001:DB8::5 and 2001:DB8::11 are installed in the FIB along the eBGP best-path to Node5 (spine node) and Node11 (ToR node) respectively. An application on HostA which needs to send traffic to HostZ via only Node5 (spine node) can do so by sending IPv6 packets with a Segment Routing header (SRH, [I-D.ietf-6man-segment-routing-header]). The destination address and active segment is set to 2001:DB8::5. The next and last segment is set to 2001:DB8::11. The application must only use IPv6 addresses that have been advertised as capable for SRv6 segment processing (e.g. for which the BGP prefix segment capability has been advertised). How applications learn this (e.g.: centralized controller and orchestration) is outside the scope of this document. 6. Communicating path information to the host There are two general methods for communicating path information to the end-hosts: "proactive" and "reactive", aka "push" and "pull" models. There are multiple ways to implement either of these methods. Here, it is noted that one way could be using a centralized Filsfils, et al. Expires June 2, 2019 [Page 13] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 controller: the controller either tells the hosts of the prefix-to- path mappings beforehand and updates them as needed (network event driven push), or responds to the hosts making request for a path to specific destination (host event driven pull). It is also possible to use a hybrid model, i.e., pushing some state from the controller in response to particular network events, while the host pulls other state on demand. It is also noted, that when disseminating network-related data to the end-hosts a trade-off is made to balance the amount of information Vs. the level of visibility in the network state. This applies both to push and pull models. In the extreme case, the host would request path information on every flow, and keep no local state at all. On the other end of the spectrum, information for every prefix in the network along with available paths could be pushed and continuously updated on all hosts. 7. Additional Benefits 7.1. MPLS Dataplane with operational simplicity As required by [RFC7938], no new signaling protocol is introduced. The BGP-Prefix-SID is a lightweight extension to BGP Labeled Unicast [RFC8277]. It applies either to eBGP or iBGP based designs. Specifically, LDP and RSVP-TE are not used. These protocols would drastically impact the operational complexity of the Data Center and would not scale. This is in line with the requirements expressed in [RFC7938]. Provided the same SRGB is configured on all nodes, all nodes use the same MPLS label for a given IP prefix. This is simpler from an operation standpoint, as discussed in Section 8 7.2. Minimizing the FIB table The designer may decide to switch all the traffic at Tier-1 and Tier- 2's based on MPLS, hence drastically decreasing the IP table size at these nodes. This is easily accomplished by encapsulating the traffic either directly at the host or the source ToR node by pushing the BGP- Prefix-SID of the destination ToR for intra-DC traffic, or the BGP- Prefix-SID for the the border node for inter-DC or DC-to-outside- world traffic. Filsfils, et al. Expires June 2, 2019 [Page 14] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 7.3. Egress Peer Engineering It is straightforward to combine the design illustrated in this document with the Egress Peer Engineering (EPE) use-case described in [I-D.ietf-spring-segment-routing-central-epe]. In such case, the operator is able to engineer its outbound traffic on a per host-flow basis, without incurring any additional state at intermediate points in the DC fabric. For example, the controller only needs to inject a per-flow state on the HostA to force it to send its traffic destined to a specific Internet destination D via a selected border node (say Node12 in Figure 1 instead of another border node, Node11) and a specific egress peer of Node12 (say peer AS 9999 of local PeerNode segment 9999 at Node12 instead of any other peer which provides a path to the destination D). Any packet matching this state at host A would be encapsulated with SR segment list (label stack) {16012, 9999}. 16012 would steer the flow through the DC fabric, leveraging any ECMP, along the best path to border node Node12. Once the flow gets to border node Node12, the active segment is 9999 (because of PHP on the upstream neighbor of Node12). This EPE PeerNode segment forces border node Node12 to forward the packet to peer AS 9999, without any IP lookup at the border node. There is no per-flow state for this engineered flow in the DC fabric. A benefit of segment routing is the per-flow state is only required at the source. As well as allowing full traffic engineering control such a design also offers FIB table minimization benefits as the Internet-scale FIB at border node Node12 is not required if all FIB lookups are avoided there by using EPE. 7.4. Anycast The design presented in this document preserves the availability and load-balancing properties of the base design presented in [I-D.ietf-spring-segment-routing]. For example, one could assign an anycast loopback 192.0.2.20/32 and associate segment index 20 to it on the border Node11 and Node12 (in addition to their node-specific loopbacks). Doing so, the EPE controller could express a default "go-to-the-Internet via any border node" policy as segment list {16020}. Indeed, from any host in the DC fabric or from any ToR node, 16020 steers the packet towards the border Node11 or Node12 leveraging ECMP where available along the best paths to these nodes. Filsfils, et al. Expires June 2, 2019 [Page 15] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 8. Preferred SRGB Allocation In the MPLS case, it is recommend to use same SRGBs at each node. Different SRGBs in each node likely increase the complexity of the solution both from an operational viewpoint and from a controller viewpoint. From an operation viewpoint, it is much simpler to have the same global label at every node for the same destination (the MPLS troubleshooting is then similar to the IPv6 troubleshooting where this global property is a given). From a controller viewpoint, this allows us to construct simple policies applicable across the fabric. Let us consider two applications A and B respectively connected to Node1 and Node2 (ToR nodes). A has two flows FA1 and FA2 destined to Z. B has two flows FB1 and FB2 destined to Z. The controller wants FA1 and FB1 to be load-shared across the fabric while FA2 and FB2 must be respectively steered via Node5 and Node8. Assuming a consistent unique SRGB across the fabric as described in the document, the controller can simply do it by instructing A and B to use {16011} respectively for FA1 and FB1 and by instructing A and B to use {16005 16011} and {16008 16011} respectively for FA2 and FB2. Let us assume a design where the SRGB is different at every node and where the SRGB of each node is advertised using the Originator SRGB TLV of the BGP-Prefix-SID as defined in [I-D.ietf-idr-bgp-prefix-sid]: SRGB of Node K starts at value K*1000 and the SRGB length is 1000 (e.g. Node1's SRGB is [1000, 1999], Node2's SRGB is [2000, 2999], ...). In this case, not only the controller would need to collect and store all of these different SRGB's (e.g., through the Originator SRGB TLV of the BGP-Prefix-SID), furthermore it would need to adapt the policy for each host. Indeed, the controller would instruct A to use {1011} for FA1 while it would have to instruct B to use {2011} for FB1 (while with the same SRGB, both policies are the same {16011}). Even worse, the controller would instruct A to use {1005, 5011} for FA1 while it would instruct B to use {2011, 8011} for FB1 (while with the same SRGB, the second segment is the same across both policies: 16011). When combining segments to create a policy, one need to carefully update the label of each segment. This is obviously more error-prone, more complex and more difficult to troubleshoot. Filsfils, et al. Expires June 2, 2019 [Page 16] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 9. IANA Considerations This document does not make any IANA request. 10. Manageability Considerations The design and deployment guidelines described in this document are based on the network design described in [RFC7938]. The deployment model assumed in this document is based on a single domain where the interconnected DCs are part of the same administrative domain (which, of course, is split into different autonomous systems). The operator has full control of the whole domain and the usual operational and management mechanisms and procedures are used in order to prevent any information related to internal prefixes and topology to be leaked outside the domain. As recommended in [I-D.ietf-spring-segment-routing], the same SRGB should be allocated in all nodes in order to facilitate the design, deployment and operations of the domain. When EPE ([I-D.ietf-spring-segment-routing-central-epe]) is used (as explained in Section 7.3, the same operational model is assumed. EPE information is originated and propagated throughout the domain towards an internal server and unless explicitly configured by the operator, no EPE information is leaked outside the domain boundaries. 11. Security Considerations This document proposes to apply Segment Routing to a well known scalability requirement expressed in [RFC7938] using the BGP-Prefix- SID as defined in [I-D.ietf-idr-bgp-prefix-sid]. It has to be noted, as described in Section 10 that the design illustrated in [RFC7938] and in this document, refer to a deployment model where all nodes are under the same administration. In this context, it is assumed that the operator doesn't want to leak outside of the domain any information related to internal prefixes and topology. The internal information includes prefix-sid and EPE information. In order to prevent such leaking, the standard BGP mechanisms (filters) are applied on the boundary of the domain. Therefore, the solution proposed in this document does not introduce any additional security concerns from what expressed in [RFC7938] and [I-D.ietf-idr-bgp-prefix-sid]. It is assumed that the security and confidentiality of the prefix and topology information is preserved by outbound filters at each peering point of the domain as described in Section 10. Filsfils, et al. Expires June 2, 2019 [Page 17] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 12. Acknowledgements The authors would like to thank Benjamin Black, Arjun Sreekantiah, Keyur Patel, Acee Lindem and Anoop Ghanwani for their comments and review of this document. 13. Contributors Gaya Nagarajan Facebook US Email: gaya@fb.com Gaurav Dawra Cisco Systems US Email: gdawra.ietf@gmail.com Dmitry Afanasiev Yandex RU Email: fl0w@yandex-team.ru Tim Laberge Cisco US Email: tlaberge@cisco.com Edet Nkposong Salesforce.com Inc. US Email: enkposong@salesforce.com Mohan Nanduri Microsoft US Email: mnanduri@microsoft.com Filsfils, et al. Expires June 2, 2019 [Page 18] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 James Uttaro ATT US Email: ju1738@att.com Saikat Ray Unaffiliated US Email: raysaikat@gmail.com Jon Mitchell Unaffiliated US Email: jrmitche@puck.nether.net 14. References 14.1. Normative References [I-D.ietf-idr-bgp-prefix-sid] Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix SID extensions for BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), June 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-central-epe] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", draft-ietf-spring-segment-routing-central- epe-10 (work in progress), December 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Filsfils, et al. Expires June 2, 2019 [Page 19] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 [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, . [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . 14.2. Informative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-15 (work in progress), October 2018. [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . Authors' Addresses Clarence Filsfils (editor) Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Stefano Previdi Cisco Systems, Inc. Italy Email: stefano@previdi.net Filsfils, et al. Expires June 2, 2019 [Page 20] Internet-Draft BGP-Prefix SID in large-scale DCs November 2018 Gaurav Dawra LinkedIn USA Email: gdawra.ietf@gmail.com Ebben Aries Juniper Networks 1133 Innovation Way Sunnyvale CA 94089 US Email: exa@juniper.net Petr Lapukhov Facebook US Email: petr@fb.com Filsfils, et al. Expires June 2, 2019 [Page 21] ./draft-ietf-teas-yang-te-topo-22.txt0000644000764400076440000144604213502434540016644 0ustar iustyiustyTEAS Working Group Xufeng Liu Internet Draft Volta Networks Intended status: Standards Track Igor Bryskin Huawei Technologies Vishnu Pavan Beeram Tarek Saad Juniper Networks Himanshu Shah Ciena Oscar Gonzalez De Dios Telefonica Expires: December 19, 2019 June 19, 2019 YANG Data Model for Traffic Engineering (TE) Topologies draft-ietf-teas-yang-te-topo-22 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), 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 December 19, 2019. Copyright Notice Copyright (c) 2019 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 Liu, et al Expires December 19, 2019 [Page 1] Internet-Draft YANG - TE Topology June 2019 (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. Abstract This document defines a YANG data model for representing, retrieving and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology specific TE Topology models can augment. Conventions used in this document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................4 1.2. Tree Structure............................................4 1.3. Prefixes in Data Node Names...............................5 2. Characterizing TE Topologies...................................5 3. Modeling Abstractions and Transformations......................7 3.1. TE Topology...............................................7 3.2. TE Node...................................................7 3.3. TE Link...................................................8 3.4. Transitional TE Link for Multi-Layer Topologies...........8 3.5. TE Link Termination Point (LTP)..........................10 3.6. TE Tunnel Termination Point (TTP)........................10 3.7. TE Node Connectivity Matrix..............................11 3.8. TTP Local Link Connectivity List (LLCL)..................11 3.9. TE Path..................................................11 3.10. TE Inter-Layer Lock.....................................12 3.11. Underlay TE topology....................................13 3.12. Overlay TE topology.....................................13 3.13. Abstract TE topology....................................13 4. Model Applicability...........................................14 4.1. Native TE Topologies.....................................14 Liu, et al Expires December 19, 2019 [Page 2] Internet-Draft YANG - TE Topology June 2019 4.2. Customized TE Topologies.................................16 4.3. Merging TE Topologies Provided by Multiple Providers.....19 4.4. Dealing with Multiple Abstract TE Topologies Provided by the Same Provider.................................................22 5. Modeling Considerations.......................................25 5.1. Network topology building blocks.........................25 5.2. Technology agnostic TE Topology model....................25 5.3. Model Structure..........................................26 5.4. Topology Identifiers.....................................27 5.5. Generic TE Link Attributes...............................27 5.6. Generic TE Node Attributes...............................28 5.7. TED Information Sources..................................29 5.8. Overlay/Underlay Relationship............................30 5.9. Templates................................................31 5.10. Scheduling Parameters...................................32 5.11. Notifications...........................................33 6. Guidance for Writing Technology Specific TE Topology Augmentations .................................................................33 7. TE Topology YANG Module.......................................46 8. Security Considerations.......................................92 9. IANA Considerations...........................................94 10. References...................................................95 10.1. Normative References....................................95 10.2. Informative References..................................96 11. Acknowledgments.............................................100 Appendix A. Complete Model Tree Structure.......................101 Appendix B. Companion YANG Model for Non-NMDA Compliant Implementations.................................................163 Appendix C. Example: YANG Model for Technology Specific Augmentations ................................................................172 Contributors....................................................210 Authors' Addresses..............................................210 1. Introduction The Traffic Engineering Database (TED) is an essential component of Traffic Engineered (TE) systems that are based on MPLS-TE [RFC2702] and GMPLS [RFC3945]. The TED is a collection of all TE information about all TE nodes and TE links in the network. The TE Topology is a schematic arrangement of TE nodes and TE links present in a given TED. There could be one or more TE Topologies present in a given Traffic Engineered system. A TE Topology is the topology on which path computational algorithms are run to compute Traffic Engineered Paths (TE Paths). This document defines a YANG [RFC7950] data model for representing and manipulating TE Topologies. This model contains technology Liu, et al Expires December 19, 2019 [Page 3] Internet-Draft YANG - TE Topology June 2019 agnostic TE Topology building blocks that can be augmented and used by other technology-specific TE Topology models. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The reader is assumed to be familiar with general body of work captured in currently available TE related RFCs. [RFC7926] serves as a good starting point for those who may be less familiar with Traffic Engineering related RFCs. Some of the key terms used in this document are: TED: The Traffic Engineering Database is a collection of all TE information about all TE nodes and TE links in a given network. TE-Topology: The TE Topology is a schematic arrangement of TE nodes and TE links in a given TED. It forms the basis for a graph suitable for TE path computations. Native TE Topology: Native TE Topology is a topology that is native to a given provider network. Native TE topology could be discovered via various routing protocols and/or subscribe/publish techniques. This is the topology on which path computational algorithms are run to compute TE Paths. Customized TE Topology: Customized TE Topology is a custom topology that is produced by a provider for a given client. This topology typically makes abstractions on the provider's Native TE Topology, and is provided to the client. The client receives the Customized TE Topology, and merges it into the client's Native TE Topology. The client's path computational algorithms aren't typically run on the Customized TE Topology; they are run on the client's Native TE Topology after the merge. 1.2. Tree Structure A simplified graphical representation of the data model is presented in Appendix A. of this document. The tree format defined in [RFC8340] is used for the YANG data model tree representation. Liu, et al Expires December 19, 2019 [Page 4] Internet-Draft YANG - TE Topology June 2019 1.3. Prefixes in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in Table 1. +----------+-----------------------+-------------------------+ | Prefix | YANG module | Reference | +----------+-----------------------+-------------------------+ | yang | ietf-yang-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] | | nw | ietf-network | [RFC6991] | | nt | ietf-network-topology | [RFC8345] | | te-types | ietf-te-types | [I-D.ietf-teas-yang-te | | | | -types] | +----------+-----------------------+-------------------------+ Table 1: Prefixes and corresponding YANG modules 2. Characterizing TE Topologies The data model proposed by this document takes the following characteristics of TE Topologies into account: - TE Topology is an abstract control-plane representation of the data-plane topology. Hence attributes specific to the data-plane must make their way into the corresponding TE Topology modeling. The TE Topology comprises of dynamic auto-discovered data as well as fairly static data associated with data-plane nodes and links. The dynamic data may change frequently, such as unreserved bandwidth available on data-plane links. The static data rarely changes, such as layer network identification, switching and adaptation capabilities and limitations, fate sharing, and administrative colors. It is possible for a single TE Topology to encompass TE information at multiple switching layers. - TE Topologies are protocol independent. Information about topological elements may be learnt via link-state protocols, but the topology can exist without being dependent on any particular protocol. - TE Topology may not be congruent to the routing topology in a given TE System. The routing topology is constructed based on routing adjacencies. There isn't always a one-to-one association between a TE-link and a routing adjacency. For example, the presence of a TE link between a pair of nodes doesn't necessarily imply the existence of a routing-adjacency between these nodes. To Liu, et al Expires December 19, 2019 [Page 5] Internet-Draft YANG - TE Topology June 2019 learn more, see [I-D.ietf-teas-te-topo-and-tunnel-modeling] and [I-D.ietf-teas-yang-l3-te-topo]. - Each TE Topological element has at least one information source associated with it. In some scenarios, there could be more than one information source associated with any given topological element. - TE Topologies can be hierarchical. Each node and link of a given TE Topology can be associated with respective underlay topology. This means that each node and link of a given TE Topology can be associated with an independent stack of supporting TE Topologies. - TE Topologies can be customized. TE topologies of a given network presented by the network provider to its client could be customized on per-client request basis. This customization could be performed by provider, by client or by provider/client negotiation. The relationship between a customized topology and provider's native topology could be captured as hierarchical (overlay-underlay), but otherwise the two topologies are decoupled from each other. A customized topology is presented to the client, while provider's native topology is known in its entirety to the provider itself. Liu, et al Expires December 19, 2019 [Page 6] Internet-Draft YANG - TE Topology June 2019 3. Modeling Abstractions and Transformations | +---+ __ | | | TE Node \/ TTP o LTP | +---+ | | ----- TE Link | ***** Node Connectivity Matrix, | TTP Local Link Connectivity | @@@@@ TE Tunnel o---------------------------------- Node-1 Node-3 +------------+ +------------+ | TTP-1 | | TTP-1 | |LTP __ | TE-Tunel-1 | __ | |-6 \/@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\/ | o * * oLTP-1 Node-2 LTP-6o * * o | * * | +------------+ | * * | | * TTP-2* | | | | * TTP-2* | | * __ * |LTP-2 LTP-6| |LTP-1 LTP-5| * __ * | o* \/ *o-----------o************o-----------o* \/ *o |LTP * * | Link-12 | * | Link-23 | * * | |-5 * * | LTP-5| * |LTP-2 | * * | +--o------o--+ o************o +--o------o--+ LTP-4 LTP-3 | * * * | LTP-4 LTP-3 | ** * | +--o------o--+ LTP-4 LTP-3 Figure 1: TE Topology Modeling Abstractions 3.1. TE Topology TE topology is a traffic engineering representation of one or more layers of network topologies. TE topology is comprised of TE nodes (TE graph vertices) interconnected via TE links (TE graph edges). A TE topology is mapped to a TE graph. 3.2. TE Node TE node is an element of a TE topology, presented as a vertex on TE graph. TE node represents one or several nodes, or a fraction of a node, which can be a switch or router that is physical or virtual. TE node belongs to and is fully defined in exactly one TE topology. TE node is assigned a unique ID within the TE topology scope. TE node attributes include information related to the data plane aspects of Liu, et al Expires December 19, 2019 [Page 7] Internet-Draft YANG - TE Topology June 2019 the associated node(s) (e.g. connectivity matrix), as well as configuration data (such as TE node name). A given TE node can be reached on the TE graph over one of TE links terminated by the TE node. Multi-layer TE nodes providing switching functions at multiple network layers are an example where a physical node can be decomposed into multiple logical TE nodes, which are fractions of the physical node. Some of these (logical) TE nodes may reside in the client layer TE topology while the remaining TE nodes belong to the server layer TE topology. In Figure 1, Node-1, Node-2, and Node-3 are TE nodes. 3.3. TE Link TE link is an element of a TE topology, presented as an edge on TE graph. The arrows on an edge indicate one or both directions of the TE link. When there are a pair of parallel links of opposite directions, an edge without arrows is also used. TE link represents one or several (physical) links or a fraction of a link. TE link belongs to and is fully defined in exactly one TE topology. TE link is assigned a unique ID within the TE topology scope. TE link attributes include parameters related to the data plane aspects of the associated link(s) (e.g. unreserved bandwidth, resource maps/pools, etc.), as well as the configuration data (such as remote node/link IDs, SRLGs, administrative colors, etc.). TE link is connected to TE node, terminating the TE link via exactly one TE link termination point (LTP). In Figure 1, Link-12 and Link-23 are TE links. 3.4. Transitional TE Link for Multi-Layer Topologies Networks are typically composed of multiple network layers where one or multiple signals in the client layer network can be multiplexed and encapsulated into a server layer signal [RFC5212] [G.805]. The server layer signal can be carried in the server layer network across multiple nodes until the server layer signal is terminated and the client layer signals reappear in the node that terminates the server layer signal. Examples of multi-layer networks are: IP over MPLS over Ethernet, low order Optical Data Unit-k (ODUk) signals multiplexed into a high order ODUl (l>k) carried over an Optical Channel (OCh) signal in an optical transport network as defined in [G.872] and [G.709]. Liu, et al Expires December 19, 2019 [Page 8] Internet-Draft YANG - TE Topology June 2019 TE links as defined in Section 3.3. can be used to represent links within a network layer. In case of a multi-layer network, TE nodes and TE links only allow representation of each network layer as a separate TE topology. Each of these single layer TE topologies would be isolated from their client and their server layer TE topology, if present. The highest and the lowest network layer in the hierarchy only have a single adjacent layer below or above, respectively. Multiplexing of client layer signals and encapsulating them into a server layer signal requires a function that is provided inside a node (typically realized in hardware). This function is also called layer transition. One of the key requirements for path computation is to be able to calculate a path between two endpoints across a multi-layer network based on the TE topology representing this multi-layer network. This means that an additional TE construct is needed that represents potential layer transitions in the multi-layer TE-topology that connects the TE-topologies representing each separate network layer. The so-called transitional TE link is such a construct and it represents the layer transition function residing inside a node that is decomposed into multiple logical nodes that are represented as TE nodes (see also the transitional link definition in [G.8080] for the optical transport network). Hence, a transitional TE link connects a client layer node with a server layer node. A TE link as defined in 3.3. has LTPs of exactly the same kind on each link end whereas the transitional TE link has client layer LTPs on the client side of the transitional link and in most cases a single server layer LTP on the server side. It should be noted that transitional links are a helper construct in the multi-layer TE topology and they only exist as long as they are not in use, as they represent potential connectivity. When the server layer trail has been established between the server layer LTP of two transitional links in the server layer network, the resulting client layer link in the data plane will be represented as a normal TE link in the client layer topology. The transitional TE links will re-appear when the server layer trail has been torn down. Liu, et al Expires December 19, 2019 [Page 9] Internet-Draft YANG - TE Topology June 2019 | | | +---+ --- | | | TE Node \ / Transitional | +---+ | Link | | ----- Client Layer Link | ===== Server Layer Link | ***** Layer Boundary o---------------------------------- +------------------+ | +------+ | +------+ -----|Client|------+ | Client -----|Client| | |Layer |---+ | | Layer |Layer | -----|Switch|-+ | | | Links -----|Node | | +------+ | | | | +------+ | | | | | Client | | | | | | ---_| Layer --- --- ***|**********|*| \ /*|***************************\ /*\ /**** | --- | | Server Transitional | | | Layer \ / | | Layer Links | | | Term. | | | | | | | | | | | | +------+ | +------+ =============|Server|===== Server ====|Server|==== | |Layer | | Layer |Layer | =============|Switch|===== Links ====|Node |==== | +------+ | +------+ +------------------+ Physical Node View TE-Topology View Figure 2: Modeling a Multi-Layer Node (Dual-Layer Example) 3.5. TE Link Termination Point (LTP) TE link termination point (LTP) is a conceptual point of connection of a TE node to one of the TE links, terminated by the TE node. Cardinality between an LTP and the associated TE link is 1:0..1. In Figure 1, Node-2 has six LTPs: LTP-1 to LTP-6. 3.6. TE Tunnel Termination Point (TTP) TE tunnel termination point (TTP) is an element of TE topology representing one or several of potential transport service termination points (i.e. service client adaptation points such as Liu, et al Expires December 19, 2019 [Page 10] Internet-Draft YANG - TE Topology June 2019 WDM/OCh transponder). TTP is associated with (hosted by) exactly one TE node. TTP is assigned a unique ID within the TE node scope. Depending on the TE node's internal constraints, a given TTP hosted by the TE node could be accessed via one, several or all TE links terminated by the TE node. In Figure 1, Node-1 has two TTPs: TTP-1 and TTP-2. 3.7. TE Node Connectivity Matrix TE node connectivity matrix is a TE node's attribute describing the TE node's switching limitations in a form of valid switching combinations of the TE node's LTPs (see below). From the point of view of a potential TE path arriving at the TE node at a given inbound LTP, the node's connectivity matrix describes valid (permissible) outbound LTPs for the TE path to leave the TE node from. In Figure 1, the connectivity matrix on Node-2 is: {, , , , } 3.8. TTP Local Link Connectivity List (LLCL) TTP Local Link Connectivity List (LLCL) is a List of TE links terminated by the TTP hosting TE node (i.e. list of the TE link LTPs), which the TTP could be connected to. From the point of view of a potential TE path, LLCL provides a list of valid TE links the TE path needs to start/stop on for the connection, taking the TE path, to be successfully terminated on the TTP in question. In Figure 1, the LLCL on Node-1 is: {, , , } 3.9. TE Path TE path is an ordered list of TE links and/or TE nodes on the TE topology graph, inter-connecting a pair of TTPs to be taken by a potential connection. TE paths, for example, could be a product of successful path computation performed for a given transport service. In Figure 1, the TE Path for TE-Tunnel-1 is: {Node-1:TTP-1, Link-12, Node-2, Link-23, Node-3:TTP1} Liu, et al Expires December 19, 2019 [Page 11] Internet-Draft YANG - TE Topology June 2019 3.10. TE Inter-Layer Lock TE inter-layer lock is a modeling concept describing client-server layer adaptation relationships and hence important for the multi- layer traffic engineering. It is an association of M client layer LTPs and N server layer TTPs, within which data arriving at any of the client layer LTPs could be adopted onto any of the server layer TTPs. TE inter-layer lock is identified by inter-layer lock ID, which is unique across all TE topologies provided by the same provider. The client layer LTPs and the server layer TTPs associated within a given TE inter-layer lock are annotated with the same inter-layer lock ID attribute. | +---+ __ | | | TE Node \/ TTP o LTP | +---+ | | ----- TE Link | ***** TTP Local Link Connectivity o---------------------------------- (IL-1) C-LTP-1 +------------+ C-LTP-2 (IL-1) --------O (IL-1) O-------- (IL-1) C-LTP-3 | S-TTP-1 | C-LTP-4 (IL-1) --------O __ 0-------- (IL-1) C-LTP-5 | *\/* | C-LTP-5 (IL-1) --------O * * O-------- | *(IL-1)* | S-LTP-3 | * S-TTP-2* | S-LTP-4 --------o* __ *o-------- | *\/* | | * * | +--o------o--+ S-LTP-1 | | S-LTP-2 Figure 3: TE Inter-Layer Lock ID Associations On the picture above a TE inter-layer lock with IL_1 ID associates 6 client layer LTPs (C-LTP-1 - C-LTP-6) with two server layer TTPs (S- TTP-1 and S-TTP-2). They all have the same attribute - TE inter-layer lock ID: IL-1, which is the only thing that indicates the association. A given LTP may have 0, 1 or more inter-layer lock IDs. In the latter case this means that the data arriving at the LTP may be adopted onto any of TTPs associated with all specified inter-layer locks. For example, C-LTP-1 could have two inter-layer lock IDs - IL- 1 and IL-2. This would mean that C-LTP-1 for adaptation purposes could use not just TTPs associated with inter-layer lock IL-1 (i.e. Liu, et al Expires December 19, 2019 [Page 12] Internet-Draft YANG - TE Topology June 2019 S-TTP-1 and S-TTP-2 on the picture), but any of TTPs associated with inter-layer lock IL-2 as well. Likewise, a given TTP may have one or more inter-layer lock IDs, meaning that it can offer the adaptation service to any of client layer LTPs with inter-layer lock ID matching one of its own. Additionally, each TTP has an attribute - Unreserved Adaptation Bandwidth, which announces its remaining adaptation resources sharable between all potential client LTPs. LTPs and TTPs associated within the same TE inter-layer lock may be hosted by the same (hybrid, multi-layer) TE node or multiple TE nodes located in the same or separate TE topologies. The latter is especially important since TE topologies of different layer networks could be modeled by separate augmentations of the basic (common to all layers) TE topology model. 3.11. Underlay TE topology Underlay TE topology is a TE topology that serves as a base for constructing of overlay TE topologies 3.12. Overlay TE topology Overlay TE topology is a TE topology constructed based on one or more underlay TE topologies. Each TE node of the overlay TE topology represents an arbitrary segment of an underlay TE topology; each TE link of the overlay TE topology represents an arbitrary TE path in one of the underlay TE topologies. The overlay TE topology and the supporting underlay TE topologies may represent distinct layer networks (e.g. OTN/ODUk and WDM/OCh respectively) or the same layer network. 3.13. Abstract TE topology Abstract TE topology is a topology that contains abstract topological elements (nodes, links, tunnel termination points). Abstract TE topology is an overlay TE topology created by a topology provider and customized for a topology provider's client based on one or more of the provider's native TE topologies (underlay TE topologies), the provider's policies and the client's preferences. For example, a first level topology provider (such as Domain Controller) can create an abstract TE topology for its client (e.g. Multi-Domain Service Coordinator) based on the provider's one or more native TE topologies, local policies/profiles and the client's TE topology configuration requests Figure 4 shows an example of abstract TE topology. Liu, et al Expires December 19, 2019 [Page 13] Internet-Draft YANG - TE Topology June 2019 | +---+ | | | TE Node | +---+ | ----- TE Link o---------------------------------- +---+ +---+ |s31|--------------|S5 | +---+\ / +---+ \ / \ / \+---+/ +---+ /|AN1|\----------------|S8 | / +---+ \ +---+ +---+ / \ +---+ |S9 |-------------|S11| +---+ +---+ Abstract TE Topology +---+ +---+ |S1 |--------------------|S2 | +---+ +---+ / \ / \ +---+ / +---+ \ +---+ |s3 |--------------------|S4 |---------|S5 | +---+\ +---+ +---+ \ \ \ \ \ \ \+---+ +---+ +---+ /|S6 |\ |S7 |---------|S8 | / +---+ \ +---+\ /+---+ +---+ / \ +---+ +---+ / |S9 |-------------|S10|--------------|S11|/ +---+ +---+ +---+ Native TE Topology Figure 4: Abstract TE Topology 4. Model Applicability 4.1. Native TE Topologies The model discussed in this draft can be used to represent and retrieve native TE topologies on a given TE system. Liu, et al Expires December 19, 2019 [Page 14] Internet-Draft YANG - TE Topology June 2019 | +---+ | | | TE Node | +---+ | ----- TE Link o---------------------------------- +---+ +---+ +---+ +---+ +---+ | R1|-------| R2|--------| R3|---------| R4|---------| R5| +---+ +---+ +---+ +---+ +---+ | / \ / \ / | / \ / \ / | / \ / \ / | / \ / \ / | / \ / \ / +---+ +---+ +---+ +---+ | R6|-------------| R7| | R8|---------| R9| +---+ +---+ +---+ +---+ Figure 5a: Example Network Topology Consider the network topology depicted in Figure 5a. R1 .. R9 are nodes representing routers. An implementation MAY choose to construct a native TE Topology using all nodes and links present in the given TED as depicted in Figure 5b. The data model proposed in this document can be used to retrieve/represent this TE topology. --------------- | Native | | [ ] TE Node | TE-Topology | | +++ TE Link --------------- o-------------- [R1] ++++ [R2] ++++ [R3] ++++ [R4] ++++ [R5] + + + + + + + + + + + + + + ++ ++ [R6] +++++++++ [R7] [R8] ++++ [R9] Figure 5b: Native TE Topology as seen on Node R3 Consider the case of the topology being split in a way that some nodes participate in OSPF-TE while others participate in ISIS-TE (Figure 6a). An implementation MAY choose to construct separate TE Topologies based on the information source. The native TE Topologies constructed using only nodes and links that were learnt via a specific information source are depicted in Figure 6b. The data model proposed in this document can be used to retrieve/represent these TE topologies. Liu, et al Expires December 19, 2019 [Page 15] Internet-Draft YANG - TE Topology June 2019 Similarly, the data model can be used to represent/retrieve a TE Topology that is constructed using only nodes and links that belong to a particular technology layer. The data model is flexible enough to retrieve and represent many such native TE Topologies. : TE info distributed via ISIS-TE : TE info distributed via OSPF-TE : +---+ +---+ +---+ +---+ +---+ | R1|-------| R2|--------| R3|---------| R4|---------| R5| +---+ +---+ +---+ +---+ +---+ | / : \ / \ / | / : \ / \ / | / : \ / \ / | / : \ / \ / | / : \ / \ / +---+ +---+ : +---+ +---+ | R6|-------------| R7| : | R8|---------| R9| +---+ +---+ : +---+ +---+ : Figure 6a: Example Network Topology ----------------------- : ----------------------- |Native TE Topology | : |Native TE Topology | |Info-Source: ISIS-TE | : |Info-Source: OSPF-TE | ----------------------- : ----------------------- : [R1] ++++ [R2] ++++ [R3] : [R3'] ++++ [R4] ++++ [R5] + + : + + + + + + : + + + + + + : ++ ++ [R6] +++++++++ [R7] : [R8] ++++ [R9] Figure 6b: Native TE Topologies as seen on Node R3 4.2. Customized TE Topologies Customized TE topology is a topology that was modified by the provider to honor a particular client's requirements or preferences. The model discussed in this draft can be used to represent, retrieve and manipulate customized TE Topologies. The model allows the provider to present the network in abstract TE Terms on a per client Liu, et al Expires December 19, 2019 [Page 16] Internet-Draft YANG - TE Topology June 2019 basis. These customized topologies contain sufficient information for the path computing client to select paths according to its policies. | +---+ /-\ | | | Router ( ) WDM | +---+ Node \-/ node | o---------------------------- +---+ /-\ /-\ /-\ +---+ | R1|-------( A )--------( C )---------( E )---------| R3| +---+ \-/ \-/ \-/ +---+ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ /-\ /-\ /-\ +---+ | R2|---------( B )---------( D )---------( F )---------| R4| +---+ \-/ \-/ \-/ +---+ Figure 7: Example packet optical topology Consider the network topology depicted in Figure 7. This is a typical packet optical transport deployment scenario where the WDM layer network domain serves as a Server Network Domain providing transport connectivity to the packet layer network Domain (Client Network Domain). Nodes R1, R2, R3 and R4 are IP routers that are connected to an Optical WDM transport network. A, B, C, D, E and F are WDM nodes that constitute the Server Network Domain. | ***** B-F WDM Path | @@@@@ B-E WDM Path | $$$$$ A-E WDM Path o-------------------- +---+ /-\ $$$$$$$$ /-\ $$$$$$$$$ /-\ +---+ | R1|-------( A )--------( C )---------( E )---------| R3| +---+ \-/ @\-/ @@@@@@@@@ \-/ +---+ @/ \ / \ @/ \ / \ @/ \ / \ @/ \ / \ @/ \ / \ +---+ /-\ ********* /-\ ********* /-\ +---+ | R2|---------( B )---------( D )---------( F )---------| R4| +---+ \-/ \-/ \-/ +---+ Liu, et al Expires December 19, 2019 [Page 17] Internet-Draft YANG - TE Topology June 2019 Figure 8a: Paths within the provider domain ++++++++ [A] ++++++++++++++++++++ [E] +++++++++ +++++ ++++ ++++ ++++ ++++ ++++++++ [B] ++++++++++++++++++++ [F] +++++++++ Figure 8b: Customized TE Topology provided to the Client The goal here is to augment the Client TE Topology with a customized TE Topology provided by the WDM network. Given the availability of the paths A-E, B-F and B-E (Figure 8a), a customized TE Topology as depicted in Figure 8b is provided to the Client. This customized TE Topology is merged with the Client's Native TE Topology and the resulting topology is depicted in Figure 8c. [R1] ++++++++ [A] ++++++++++++++++++++ [E] +++++++++ [R3] +++++ ++++ ++++ ++++ ++++ [R2] ++++++++ [B] ++++++++++++++++++++ [F] +++++++++ [R4] Figure 8c: Customized TE Topology merged with the Client's Native TE Topology The data model proposed in this document can be used to retrieve/represent/manipulate the customized TE Topology depicted in Figure 8b. A customized TE topology is not necessarily an abstract TE topology. The provider may produce, for example, an abstract TE topology of certain type (e.g. single-abstract-node-with-connectivity-matrix topology, a border-nodes-connected-via-mesh-of-abstract-links topology, etc.) and expose it to all/some clients in expectation that the clients will use it without customization. On the other hand, a client may request a customized version of the provider's native TE topology (e.g. by requesting removal of TE links Liu, et al Expires December 19, 2019 [Page 18] Internet-Draft YANG - TE Topology June 2019 which belong to certain layers, are too slow, not protected and/or have a certain affinity). Note that the resulting TE topology will not be abstract (because it will not contain abstract elements), but customized (modified upon client's instructions). The client ID field in the TE topology identifier (Section 5.4. ) indicates which client the TE topology is customized for. Although an authorized client MAY receive a TE topology with the client ID field matching some other client, the client can customize only TE topologies with the client ID field either 0 or matching the ID of the client in question. If the client starts reconfiguration of a topology its client ID will be automatically set in the topology ID field for all future configurations and updates wrt. the topology in question. The provider MAY tell the client that a given TE topology cannot be re-negotiated, by setting its own (provider's) ID in the client ID field of the topology ID. Even though this data model allows to access TE topology information across clients, implementations MAY restrict access for particular clients to particular data fields. The Network Configuration Access Control Model (NACM) [RFC8341] provides such a mechanism. 4.3. Merging TE Topologies Provided by Multiple Providers A client may receive TE topologies provided by multiple providers, each of which managing a separate domain of multi-domain network. In order to make use of said topologies, the client is expected to merge the provided TE topologies into one or more client's native TE topologies, each of which homogeneously representing the multi-domain network. This makes it possible for the client to select end-to-end TE paths for its services traversing multiple domains. In particular, the process of merging TE topologies includes: - Identifying neighboring domains and locking their topologies horizontally by connecting their inter-domain open-ended TE links; - Renaming TE node, link, and SRLG IDs to ones allocated from a separate name space; this is necessary because all TE topologies are considered to be, generally speaking, independent with a possibility of clashes among TE node, link or SRLG IDs; - Locking, vertically, TE topologies associated with different layer networks, according to provided topology inter-layer locks; this is to facilitate inter-layer path computations across multiple TE topologies provided by the same topology provider. Liu, et al Expires December 19, 2019 [Page 19] Internet-Draft YANG - TE Topology June 2019 /---\ +---+ +---+ +---+ +---+ /---\ |s3 |------|S13|----|S15|------|S23|----|S25|------|C21| \---/ +---+\ +---+ +---+ /+---+ \---/ \ / \ / \+---+ +---+/ +---+ /---\ |S18|------|S24| |S28|------|C22| +---+ +---+\ /+---+ \---/ \/ /\ /---\ +---+ +---+ +---+/ \+---+ /---\ |C12|------|S19|----|S17|------|S29|----|S27|------|C23| \---/ +---+ +---+ +---+ +---+ \---/ Domain 1 TE Topology Domain 2 TE Topology +---+ +---+ +---+ +---+ -----|S13|----|S15|---- ----|S23|----|S25|---- +---+\ +---+ +---+ /+---+ \ / \ / \+---+ +---+/ +---+ |S18|---- ----|S24| |S28|---- +---+ +---+\ /+---+ \/ /\ +---+ +---+ +---+/ \+---+ -----|S19|----|S17|---- ----|S29|----|S27|---- +---+ +---+ +---+ +---+ Figure 9: Merging Domain TE Topologies Figure 9 illustrates the process of merging, by the client, of TE topologies provided by the client's providers. In the Figure, each of the two providers caters to the client (abstract or native) TE topology, describing the network domain under the respective provider's control. The client, by consulting the attributes of the inter-domain TE links - such as inter-domain plug IDs or remote TE node/link IDs (as defined by the TE Topology model) - is able to determine that: a) the two domains are adjacent and are inter-connected via three inter-domain TE links, and; Liu, et al Expires December 19, 2019 [Page 20] Internet-Draft YANG - TE Topology June 2019 b) each domain is connected to a separate customer site, connecting the left domain in the Figure to customer devices C-11 and C-12, and the right domain to customer devices C-21, C-22 and C-23. Therefore, the client inter-connects the open-ended TE links, as shown on the upper part of the Figure. As mentioned, one way to inter-connect the open-ended inter-domain TE links of neighboring domains is to mandate the providers to specify remote nodeID/linkID attribute in the provided inter-domain TE links. This, however, may prove to be not flexible. For example, the providers may not know the respective remote nodeIDs/ linkIDs. More importantly, this option does not allow for the client to mix-n-match multiple (more than one) topologies catered by the same providers (see below). Another, more flexible, option to resolve the open-ended inter-domain TE links is by annotating them with the inter-domain plug ID attribute. Inter-domain plug ID is a network-wide unique number that identifies on the network a connectivity supporting a given inter-domain TE link. Instead of specifying remote node ID/link ID, an inter-domain TE link may provide a non-zero inter-domain plug ID. It is expected that two neighboring domain TE topologies (provided by separate providers) will have each at least one open- ended inter-domain TE link with an inter-domain plug ID matching to one provided by its neighbor. For example, the inter-domain TE link originating from node S15 of the Domain 1 TE topology (Figure 9) and the inter-domain TE link coming from node S23 of Domain 2 TE topology may specify matching inter-domain plug ID (e.g. 175344). This allows for the client to identify adjacent nodes in the separate neighboring TE topologies and resolve the inter-domain TE links connecting them regardless of their respective nodeIDs/linkIDs (which, as mentioned, could be allocated from independent name spaces). Inter-domain plug IDs may be assigned and managed by a central network authority. Alternatively, inter-domain plug IDs could be dynamically auto- discovered (e.g. via LMP protocol). Furthermore, the client renames the TE nodes, links and SRLGs offered in the abstract TE topologies by assigning to them IDs allocated from a separate name space managed by the client. Such renaming is necessary, because the two abstract TE topologies may have their own name spaces, generally speaking, independent one from another; hence, ID overlaps/clashes are possible. For example, both TE topologies have TE nodes named S7, which, after renaming, appear in the merged TE topology as S17 and S27, respectively. Once the merging process is complete, the client can use the merged TE topology for path computations across both domains, for example, to compute a TE path connecting C-11 to C-23. Liu, et al Expires December 19, 2019 [Page 21] Internet-Draft YANG - TE Topology June 2019 4.4. Dealing with Multiple Abstract TE Topologies Provided by the Same Provider Domain 1 Abstract TE Topology 1 Domain 2 Abstract TE Topology 1 +---+ +---+ +---+ +---+ -----|S13|----|S15|---- ----|S23|----|S25|---- +---+\ +---+ +---+ /+---+ \ / \ / \+---+ +---+/ +---+ |S18|---- ----|S24| |S28|---- +---+ +---+\ /+---+ \/ /\ +---+ +---+ +---+/ \+---+ -----|S19|----|S17|---- ----|S29|----|S27|---- +---+ +---+ +---+ +---+ Domain 1 Abstract TE Topology 1 Domain 2 Abstract TE Topology 1 +------------+ +------------+ -----| |---- ----| |---- | | | | | AN1 |---- ----| AN1 |---- | | | | -----| |---- ----| |---- +------------+ +------------+ Figure 10: Merging Domain TE Topologies Based on local configuration, templates and/or policies pushed by the client, a given provider may expose more than one abstract TE topology to the client. For example, one abstract TE topology could be optimized based on a lowest-cost criterion, while another one could be based on best possible delay metrics, while yet another one could be based on maximum bandwidth availability for the client services. Furthermore, the client may request all or some providers to expose additional abstract TE topologies, possibly of a different type and/or optimized differently, as compared to already-provided TE topologies. In any case, the client should be prepared for a provider to offer to the client more than one abstract TE topology. It should be up to the client (based on the client's local configuration and/or policies conveyed to the client by the client's Liu, et al Expires December 19, 2019 [Page 22] Internet-Draft YANG - TE Topology June 2019 clients) to decide how to mix-and-match multiple abstract TE topologies provided by each or some of the providers, as well as how to merge them into the client's native TE topologies. The client also decides how many such merged TE topologies it needs to produce and maintain. For example, in addition to the merged TE topology depicted in the upper part of Figure 9, the client may merge the abstract TE topologies received from the two providers, as shown in Figure 10, into the client's additional native TE topologies, as shown in Figure 11. Note that allowing for the client mix-n-matching of multiple TE topologies assumes that inter-domain plug IDs (rather than remote nodeID/linkID) option is used for identifying neighboring domains and inter-domain TE link resolution. Liu, et al Expires December 19, 2019 [Page 23] Internet-Draft YANG - TE Topology June 2019 Client's Merged TE Topology 2 /---\ +------------+ +------------+ /---\ |s3 |------| |------| |------|C21| \---/ | | | | \---/ | | | | | | | | | | | | /---\ | AN11 |------| AN21 |------|C22| | | | | \---/ | | | | | | | | /---\ | | | | /---\ |C12|------| |------| |------|C23| \---/ +------------+ +------------+ \---/ Client's Merged TE Topology 3 /---\ +------------+ +---+ +---+ /---\ |s3 |------| |------|S23|----|S25|------|C21| \---/ | | +---+ /+---+ \---/ | | / | | / | | +---+/ +---+ /---\ | AN11 |------|S24| |S28|------|C22| | | +---+\ /+---+ \---/ | | \/ | | /\ /---\ | | +---+/ \+---+ /---\ |C12|------| |------|S29|----|S27|------|C23| \---/ +------------+ +---+ +---+ \---/ Figure 11: Multiple Native (Merged) Client's TE Topologies It is important to note that each of the three native (merged) TE topologies could be used by the client for computing TE paths for any of the multi-domain services. The choice as to which topology to use for a given service depends on the service parameters/requirements and the topology's style, optimization criteria and the level of details. Liu, et al Expires December 19, 2019 [Page 24] Internet-Draft YANG - TE Topology June 2019 5. Modeling Considerations 5.1. Network topology building blocks The network topology building blocks are discussed in [RFC8345]. The TE Topology model proposed in this document augments and uses the ietf-network-topology module defined in [RFC8345]. +------------------------+ | | | Network Topology Model | | (ietf-network-topology)| +------------------------+ | | | V +------------------------+ | TE Topology | | Model | | | +------------------------+ Figure 12: Augmenting the Network Topology Model 5.2. Technology agnostic TE Topology model The TE Topology model proposed in this document is meant to be network technology agnostic. Other technology specific TE Topology models can augment and use the building blocks provided by the proposed model. Liu, et al Expires December 19, 2019 [Page 25] Internet-Draft YANG - TE Topology June 2019 +-----------------------------+ | TE Topology Model | | (Defined in This Document) | +-----------------------------+ | +-------------+-------------+-------------+ | | | | V V V V +------------+ +------------+ | Technology | | Technology | | Specific | ...................... | Specific | | TE Topology| | TE Topology| | Model 1 | | Model n | +------------+ +------------+ Figure 13: Augmenting the Technology agnostic TE Topology model 5.3. Model Structure The high-level model structure proposed by this document is as shown below: module: ietf-te-topology augment /nw:networks/nw:network/nw:network-types: +--rw te-topology! augment /nw:networks: +--rw te! +--rw templates +--rw node-template* [name] {template}? | ............ +--rw link-template* [name] {template}? ............ augment /nw:networks/nw:network: +--rw te-topology-identifier | +--rw provider-id? te-global-id | +--rw client-id? te-global-id | +--rw topology-id? te-topology-id +--rw te! | ............ augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! | ............ +--rw tunnel-termination-point* [tunnel-tp-id] Liu, et al Expires December 19, 2019 [Page 26] Internet-Draft YANG - TE Topology June 2019 +--rw tunnel-tp-id binary | ............ +--rw supporting-tunnel-termination-point* [node-ref tunnel- tp-ref] | ............ augment /nw:networks/nw:network/nt:link: +--rw te! | .......... augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te-tp-id? te-types:te-tp-id +--rw te! | ............ 5.4. Topology Identifiers The TE-Topology is uniquely identified by a key that has 3 constituents - topology-id, provider-id and client-id. The combination of provider-id and topology-id uniquely identifies a native TE Topology on a given provider. The client-id is used only when Customized TE Topologies come into play; a value of "0" is used as the client-id for native TE Topologies. augment /nw:networks/nw:network: +--rw te-topology-identifier | +--rw provider-id? te-global-id | +--rw client-id? te-global-id | +--rw topology-id? te-topology-id +--rw te! | ............ 5.5. Generic TE Link Attributes The model covers the definitions for generic TE Link attributes - bandwidth, admin groups, SRLGs, switching capabilities, TE metric extensions etc. +--rw te-link-attributes ..................... +--rw admin-status? te-admin-status | ..................... +--rw link-index? uint64 +--rw administrative-group? te-types:admin-groups +--rw link-protection-type? enumeration +--rw max-link-bandwidth? te-bandwidth Liu, et al Expires December 19, 2019 [Page 27] Internet-Draft YANG - TE Topology June 2019 +--rw max-resv-link-bandwidth? te-bandwidth +--rw unreserved-bandwidth* [priority] | ..................... +--rw te-default-metric? uint32 | ..................... +--rw te-srlgs +--rw te-nsrlgs {nsrlg}? ..................... 5.6. Generic TE Node Attributes The model covers the definitions for generic TE Node attributes. The definition of a generic connectivity matrix is shown below: +--rw te-node-attributes ........... +--rw connectivity-matrices ........... | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | | +--rw label-restrictions | | +--rw to | | | +--rw tp-ref? leafref | | | +--rw label-restrictions | | +--rw is-allowed? boolean ........... | | +--rw underlay! {te-topology-hierarchy}? ........... | | +--rw path-constraints ........... | | +--rw optimizations ........... | | +--ro path-properties ........... The definition of a TTP Local Link Connectivity List is shown below: +--rw tunnel-termination-point* [tunnel-tp-id] +--rw tunnel-tp-id binary +--rw admin-status? te-types:te-admin-status +--rw name? string +--rw switching-capability? identityref +--rw encoding? identityref +--rw inter-layer-lock-id* uint32 Liu, et al Expires December 19, 2019 [Page 28] Internet-Draft YANG - TE Topology June 2019 +--rw protection-type? Identityref +--rw client-layer-adaptation ........... +--rw local-link-connectivities ........... | +--rw local-link-connectivity* [link-tp-ref] | +--rw link-tp-ref leafref | +--rw label-restrictions ........... | +--rw is-allowed? boolean | +--rw underlay {te-topology-hierarchy}? ........... | +--rw path-constraints ........... | +--rw optimizations ........... | +--ro path-properties ........... +--rw supporting-tunnel-termination-point* [node-ref tunnel-tp- ref] +--rw node-ref inet:uri +--rw tunnel-tp-ref binary The attributes directly under container connectivity-matrices are the default attributes for all connectivity-matrix entries when the per entry corresponding attribute is not specified. When a per entry attribute is specified, it overrides the corresponding attribute directly under the container connectivity-matrices. The same rule applies to the attributes directly under container local-link- connectivities. Each TTP (Tunnel Termination Point) MAY be supported by one or more supporting TTPs. If the TE node hosting the TTP in question refers to a supporting TE node, then the supporting TTPs are hosted by the supporting TE node. If the TE node refers to an underlay TE topology, the supporting TTPs are hosted by one or more specified TE nodes of the underlay TE topology. 5.7. TED Information Sources The model allows each TE topological element to have multiple TE information sources (OSPF-TE, ISIS-TE, BGP-LS, User-Configured, System-Processed, Other). Each information source is associated with a credibility preference to indicate precedence. In scenarios where a customized TE Topology is merged into a Client's native TE Topology, the merged topological elements would point to the corresponding customized TE Topology as its information source. Liu, et al Expires December 19, 2019 [Page 29] Internet-Draft YANG - TE Topology June 2019 augment /nw:networks/nw:network/nw:node: +--rw te! ........... +--ro information-source? te-info-source +--ro information-source-instance? string +--ro information-source-state | +--ro credibility-preference? uint16 | +--ro logical-network-element? string | +--ro network-instance? string | +--ro topology | +--ro node-ref? leafref | +--ro network-ref? leafref +--ro information-source-entry* | [information-source information-source-instance] | +--ro information-source te-info-source | +--ro information-source-instance string ............ augment /nw:networks/nw:network/nt:link: +--rw te! ........... +--ro information-source? te-info-source +--ro information-source-instance? string +--ro information-source-state | +--ro credibility-preference? uint16 | +--ro logical-network-element? string | +--ro network-instance? string | +--ro topology | +--ro link-ref? leafref | +--ro network-ref? leafref +--ro information-source-entry* | [information-source information-source-instance] | +--ro information-source te-info-source | +--ro information-source-instance string ............ 5.8. Overlay/Underlay Relationship The model captures overlay and underlay relationship for TE nodes/links. For example - in networks where multiple TE Topologies are built hierarchically, this model allows the user to start from a specific topological element in the top most topology and traverse all the way down to the supporting topological elements in the bottom most topology. This relationship is captured via the "underlay-topology" field for the node and via the "underlay" field for the link. The use of these Liu, et al Expires December 19, 2019 [Page 30] Internet-Draft YANG - TE Topology June 2019 fields is optional and this functionality is tagged as a "feature" ("te-topology-hierarchy"). augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! +--rw te-node-template* leafref {template}? +--rw te-node-attributes | +--rw admin-status? te-types:te-admin-status | | .................... | +--rw underlay-topology {te-topology-hierarchy}? | +--rw network-ref? leafref augment /nw:networks/nw:network/nt:link: +--rw te! +--rw te-link-attributes | .................... | +--rw underlay {te-topology-hierarchy}? | | +--rw enabled? boolean | | +--rw primary-path | | | +--rw network-ref? leafref | | | .................... | | +--rw backup-path* [index] | | | +--rw index uint32 | | | +--rw network-ref? leafref | | | .................... | | +--rw protection-type? identityref | | +--rw tunnel-termination-points | | | +--rw source? binary | | | +--rw destination? binary | | +--rw tunnels | | | .................... 5.9. Templates The data model provides the users with the ability to define templates and apply them to link and node configurations. The use of "template" configuration is optional and this functionality is tagged as a "feature" ("template"). augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! +--rw te-node-template* | -> ../../../../te/templates/node-template/name | {template}? Liu, et al Expires December 19, 2019 [Page 31] Internet-Draft YANG - TE Topology June 2019 augment /nw:networks/nw:network/nt:link: +--rw te! +--rw te-link-template* | -> ../../../../te/templates/link-template/name | {template}? augment /nw:networks: +--rw te! +--rw templates +--rw node-template* [name] {template}? | +--rw name | | te-types:te-template-name | +--rw priority? uint16 | +--rw reference-change-policy? enumeration | +--rw te-node-attributes .......... +--rw link-template* [name] {template}? +--rw name | te-types:te-template-name +--rw priority? uint16 +--rw reference-change-policy? enumeration +--rw te-link-attributes .......... Multiple templates can be specified to a configuration element. When two or more templates specify values for the same configuration field, the value from the template with the highest priority is used. The range of the priority is from 0 to 65535, with a lower number indicating a higher priority. The reference-change-policy specifies the action that needs to be taken when the template changes on a configuration element that has a reference to this template. The choices of action include taking no action, rejecting the change to the template and applying the change to the corresponding configuration. 5.10. Scheduling Parameters The model allows time scheduling parameters to be specified for each topological element or for the topology as a whole. These parameters allow the provider to present different topological views to the client at different time slots. The use of "scheduling parameters" is optional. The YANG data model for configuration scheduling is defined in [I-D.liu-netmod-yang-schedule], which allows specifying configuration schedules without altering this data model. Liu, et al Expires December 19, 2019 [Page 32] Internet-Draft YANG - TE Topology June 2019 5.11. Notifications Notifications are a key component of any topology data model. [I-D.ietf-netconf-subscribed-notifications] and [I-D.ietf-netconf-yang-push] define a subscription and push mechanism for YANG datastores. This mechanism currently allows the user to: - Subscribe notifications on a per client basis - Specify subtree filters or xpath filters so that only interested contents will be sent. - Specify either periodic or on-demand notifications. 6. Guidance for Writing Technology Specific TE Topology Augmentations The TE topology model defined in this document is technology agnostic as it defines concepts, abstractions and attributes that are common across multiple network technologies. It is envisioned that this base model will be widely used when defining technology specific TE topology models for various layer networks. [I-D.ietf-ccamp-wson-yang], [I-D.ietf-ccamp-otn-topo-yang], and [I-D.ietf-teas-yang-l3-te-topo] are some examples of technology specific TE Topology models. Writers of such models are encouraged to augment the basic TE topology model's containers, such as TE Topology, TE Node, TE Link, Link Termination Point (LTP), Tunnel Termination Point (TTP), Bandwidth and Label with the layer specific attributes instead of defining new containers. Consider the following technology specific example-topology model: module: example-topology augment /nw:networks/nw:network/nw:network-types/tet:te-topology: +--rw example-topology! augment /nw:networks/nw:network/tet:te: +--rw attributes +--rw attribute-1? uint8 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes: +--rw attributes +--rw attribute-2? uint8 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices: +--rw attributes +--rw attribute-3? uint8 augment /nw:networks/nw:network/nw:node/tet:te Liu, et al Expires December 19, 2019 [Page 33] Internet-Draft YANG - TE Topology June 2019 /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix: +--rw attributes +--rw attribute-3? uint8 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point: +--rw attributes +--rw attribute-4? uint8 augment /nw:networks/nw:network/nw:node/nt:termination-point /tet:te: +--rw attributes +--rw attribute-5? uint8 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes: +--rw attributes +--rw attribute-6? uint8 The technology specific TE bandwidth for this example topology can be specified using the following augment statements: augment /nw:networks/tet:te/tet:templates/tet:link-template /tet:te-link-attributes /tet:interface-switching-capability/tet:max-lsp-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/tet:te/tet:templates/tet:link-template /tet:te-link-attributes/tet:max-link-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/tet:te/tet:templates/tet:link-template /tet:te-link-attributes/tet:max-resv-link-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/tet:te/tet:templates/tet:link-template Liu, et al Expires December 19, 2019 [Page 34] Internet-Draft YANG - TE Topology June 2019 /tet:te-link-attributes/tet:unreserved-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:path-constraints/tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:path-constraints /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:path-constraints/tet:te-bandwidth/tet:technology: +--:(example) +--ro example +--ro bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:path-constraints /tet:te-bandwidth/tet:technology: +--:(example) +--ro example +--ro bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point/tet:client-layer-adaptation /tet:switching-capability/tet:te-bandwidth /tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities/tet:path-constraints Liu, et al Expires December 19, 2019 [Page 35] Internet-Draft YANG - TE Topology June 2019 /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities /tet:local-link-connectivity/tet:path-constraints /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes /tet:interface-switching-capability/tet:max-lsp-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/tet:max-link-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/tet:max-resv-link-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:information-source-entry /tet:interface-switching-capability/tet:max-lsp-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--ro example +--ro bandwidth-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:information-source-entry/tet:max-link-bandwidth /tet:te-bandwidth/tet:technology: Liu, et al Expires December 19, 2019 [Page 36] Internet-Draft YANG - TE Topology June 2019 +--:(example) +--ro example +--ro bandwidth-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:information-source-entry/tet:max-resv-link-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--ro example +--ro bandwidth-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:information-source-entry/tet:unreserved-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--ro example +--ro bandwidth-1? uint32 augment /nw:networks/nw:network/nw:node/nt:termination-point/tet:te /tet:interface-switching-capability/tet:max-lsp-bandwidth /tet:te-bandwidth/tet:technology: +--:(example) +--rw example +--rw bandwidth-1? uint32 The technology specific TE label for this example topology can be specified using the following augment statements: augment /nw:networks/tet:te/tet:templates/tet:link-template /tet:te-link-attributes/tet:underlay/tet:primary-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/tet:te/tet:templates/tet:link-template /tet:te-link-attributes/tet:underlay/tet:backup-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/tet:te/tet:templates/tet:link-template Liu, et al Expires December 19, 2019 [Page 37] Internet-Draft YANG - TE Topology June 2019 /tet:te-link-attributes/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/tet:te/tet:templates/tet:link-template /tet:te-link-attributes/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:label-restrictions/tet:label-restriction /tet:label-start/tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:label-restrictions/tet:label-restriction /tet:label-end/tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:underlay/tet:primary-path/tet:path-element/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:underlay/tet:backup-path/tet:path-element/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 Liu, et al Expires December 19, 2019 [Page 38] Internet-Draft YANG - TE Topology June 2019 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:path-properties/tet:path-route-objects /tet:path-route-object/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:from/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:from/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:to/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:to/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te Liu, et al Expires December 19, 2019 [Page 39] Internet-Draft YANG - TE Topology June 2019 /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:underlay/tet:primary-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:underlay/tet:backup-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:te-node-attributes/tet:connectivity-matrices /tet:connectivity-matrix/tet:path-properties /tet:path-route-objects/tet:path-route-object/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:label-restrictions/tet:label-restriction /tet:label-start/tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:label-restrictions/tet:label-restriction /tet:label-end/tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:underlay/tet:primary-path/tet:path-element/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: Liu, et al Expires December 19, 2019 [Page 40] Internet-Draft YANG - TE Topology June 2019 +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:underlay/tet:backup-path/tet:path-element/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:path-properties/tet:path-route-objects /tet:path-route-object/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:from/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:from/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:to/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--ro example Liu, et al Expires December 19, 2019 [Page 41] Internet-Draft YANG - TE Topology June 2019 +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:to/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:underlay/tet:primary-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:underlay/tet:backup-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:information-source-entry/tet:connectivity-matrices /tet:connectivity-matrix/tet:path-properties /tet:path-route-objects/tet:path-route-object/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 Liu, et al Expires December 19, 2019 [Page 42] Internet-Draft YANG - TE Topology June 2019 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities/tet:underlay /tet:primary-path/tet:path-element/tet:type/tet:label /tet:label-hop/tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities/tet:underlay /tet:backup-path/tet:path-element/tet:type/tet:label /tet:label-hop/tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities/tet:path-properties /tet:path-route-objects/tet:path-route-object/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities /tet:local-link-connectivity/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 Liu, et al Expires December 19, 2019 [Page 43] Internet-Draft YANG - TE Topology June 2019 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities /tet:local-link-connectivity/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities /tet:local-link-connectivity/tet:underlay /tet:primary-path/tet:path-element/tet:type/tet:label /tet:label-hop/tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities /tet:local-link-connectivity/tet:underlay/tet:backup-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nw:node/tet:te /tet:tunnel-termination-point /tet:local-link-connectivities /tet:local-link-connectivity/tet:path-properties /tet:path-route-objects/tet:path-route-object/tet:type /tet:label/tet:label-hop/tet:te-label/tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) Liu, et al Expires December 19, 2019 [Page 44] Internet-Draft YANG - TE Topology June 2019 +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/tet:underlay/tet:primary-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:te-link-attributes/tet:underlay/tet:backup-path /tet:path-element/tet:type/tet:label/tet:label-hop /tet:te-label/tet:technology: +--:(example) +--rw example +--rw label-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:information-source-entry/tet:label-restrictions /tet:label-restriction/tet:label-start/tet:te-label /tet:technology: +--:(example) +--ro example +--ro label-1? uint32 augment /nw:networks/nw:network/nt:link/tet:te /tet:information-source-entry/tet:label-restrictions /tet:label-restriction/tet:label-end/tet:te-label /tet:technology: +--:(example) +--ro example +--ro label-1? uint32 The YANG module to implement the above example topology can be seen in Appendix C. Liu, et al Expires December 19, 2019 [Page 45] Internet-Draft YANG - TE Topology June 2019 7. TE Topology YANG Module This module references [RFC1195], [RFC3209], [RFC3272], [RFC3471], [RFC3630], [RFC3785], [RFC4201], [RFC4202], [RFC4203], [RFC4206], [RFC4872], [RFC5152], [RFC5212], [RFC5305], [RFC5316], [RFC5329], [RFC5392], [RFC6001], [RFC6241], [RFC6991], [RFC7308], [RFC7471], [RFC7579], [RFC7752], [RFC8345], and [I-D.ietf-teas-yang-te-types]. file "ietf-te-topology@2019-02-07.yang" module ietf-te-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology"; prefix "tet"; import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-te-types { prefix "te-types"; reference "I-D.ietf-teas-yang-te-types: Traffic Engineering Common YANG Types"; } import ietf-network { prefix "nw"; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-network-topology { prefix "nt"; reference "RFC 8345: A YANG Data Model for Network Topologies"; } Liu, et al Expires December 19, 2019 [Page 46] Internet-Draft YANG - TE Topology June 2019 organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Igor Bryskin Editor: Vishnu Pavan Beeram Editor: Tarek Saad Editor: Himanshu Shah Editor: Oscar Gonzalez De Dios "; description "TE topology model for representing and manipulating technology agnostic TE Topologies. Copyright (c) 2019 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 Liu, et al Expires December 19, 2019 [Page 47] Internet-Draft YANG - TE Topology June 2019 RFC itself for full legal notices."; revision "2019-02-07" { description "Initial revision"; reference "RFC XXXX: YANG Data Model for TE Topologies"; // RFC Ed.: replace XXXX with actual RFC number and remove // this note } /* * Features */ feature nsrlg { description "This feature indicates that the system supports NSRLG (Not Sharing Risk Link Group)."; } feature te-topology-hierarchy { description "This feature indicates that the system allows underlay and/or overlay TE topology hierarchy."; } feature template { description "This feature indicates that the system supports template configuration."; } /* * Typedefs */ typedef geographic-coordinate-degree { type decimal64 { fraction-digits 8; } description "Decimal degree (DD) used to express latitude and longitude geographic coordinates."; } // geographic-coordinate-degree Liu, et al Expires December 19, 2019 [Page 48] Internet-Draft YANG - TE Topology June 2019 typedef te-info-source { type enumeration { enum "unknown" { description "The source is unknown."; } enum "locally-configured" { description "Configured entity."; } enum "ospfv2" { description "OSPFv2."; } enum "ospfv3" { description "OSPFv3."; } enum "isis" { description "ISIS."; } enum "bgp-ls" { description "BGP-LS."; reference "RFC 7752: North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP"; } enum "system-processed" { description "System processed entity."; } enum "other" { description "Other source."; } } description "Describining the type of source that has provided the related information, and the source credibility."; } // te-info-source /* * Groupings */ grouping connectivity-matrix-entry-path-attributes { description Liu, et al Expires December 19, 2019 [Page 49] Internet-Draft YANG - TE Topology June 2019 "Attributes of connectivity matrix entry."; leaf is-allowed { type boolean; description "true - switching is allowed, false - switching is disallowed."; } container underlay { if-feature te-topology-hierarchy; description "Attributes of the te-link underlay."; reference "RFC 4206: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"; uses te-link-underlay-attributes; } // underlay uses te-types:generic-path-constraints; uses te-types:generic-path-optimization; uses te-types:generic-path-properties; } // connectivity-matrix-entry-path-attributes grouping geolocation-container { description "A container containing a GPS location."; container geolocation{ config false; description "A container containing a GPS location."; leaf altitude { type int64; units millimeter; description "Distance above the sea level."; } leaf latitude { type geographic-coordinate-degree { range "-90..90"; } description Liu, et al Expires December 19, 2019 [Page 50] Internet-Draft YANG - TE Topology June 2019 "Relative position north or south on the Earth's surface."; } leaf longitude { type geographic-coordinate-degree { range "-180..180"; } description "Angular distance east or west on the Earth's surface."; } } // gps-location } // geolocation-container grouping information-source-state-attributes { description "The attributes identifying source that has provided the related information, and the source credibility."; leaf credibility-preference { type uint16; description "The preference value to calculate the traffic engineering database credibility value used for tie-break selection between different information-source values. Higher value is more preferable."; } leaf logical-network-element { type string; description "When applicable, this is the name of a logical network element from which the information is learned."; } // logical-network-element leaf network-instance { type string; description "When applicable, this is the name of a network-instance from which the information is learned."; } // network-instance } // information-source-state-attributes grouping information-source-per-link-attributes { description Liu, et al Expires December 19, 2019 [Page 51] Internet-Draft YANG - TE Topology June 2019 "Per node container of the attributes identifying source that has provided the related information, and the source credibility."; leaf information-source { type te-info-source; config false; description "Indicates the type of the information source."; } leaf information-source-instance { type string; config false; description "The name indicating the instance of the information source."; } container information-source-state { config false; description "The container contains state attributes related to the information source."; uses information-source-state-attributes; container topology { description "When the information is processed by the system, the attributes in this container indicate which topology is used to process to generate the result information."; uses nt:link-ref; } // topology } // information-source-state } // information-source-per-link-attributes grouping information-source-per-node-attributes { description "Per node container of the attributes identifying source that has provided the related information, and the source credibility."; leaf information-source { type te-info-source; config false; description Liu, et al Expires December 19, 2019 [Page 52] Internet-Draft YANG - TE Topology June 2019 "Indicates the type of the information source."; } leaf information-source-instance { type string; config false; description "The name indicating the instance of the information source."; } container information-source-state { config false; description "The container contains state attributes related to the information source."; uses information-source-state-attributes; container topology { description "When the information is processed by the system, the attributes in this container indicate which topology is used to process to generate the result information."; uses nw:node-ref; } // topology } // information-source-state } // information-source-per-node-attributes grouping interface-switching-capability-list { description "List of Interface Switching Capabilities Descriptors (ISCD)"; list interface-switching-capability { key "switching-capability encoding"; description "List of Interface Switching Capabilities Descriptors (ISCD) for this link."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description. RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)."; leaf switching-capability { type identityref { base te-types:switching-capabilities; Liu, et al Expires December 19, 2019 [Page 53] Internet-Draft YANG - TE Topology June 2019 } description "Switching Capability for this interface."; } leaf encoding { type identityref { base te-types:lsp-encoding-types; } description "Encoding supported by this interface."; } uses te-link-iscd-attributes; } // interface-switching-capability } // interface-switching-capability-list grouping statistics-per-link { description "Statistics attributes per TE link."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } /* Administrative attributes */ leaf disables { type yang:counter32; description "Number of times that link was disabled."; } leaf enables { type yang:counter32; description "Number of times that link was enabled."; } leaf maintenance-clears { type yang:counter32; Liu, et al Expires December 19, 2019 [Page 54] Internet-Draft YANG - TE Topology June 2019 description "Number of times that link was put out of maintenance."; } leaf maintenance-sets { type yang:counter32; description "Number of times that link was put in maintenance."; } leaf modifies { type yang:counter32; description "Number of times that link was modified."; } /* Operational attributes */ leaf downs { type yang:counter32; description "Number of times that link was set to operational down."; } leaf ups { type yang:counter32; description "Number of times that link was set to operational up."; } /* Recovery attributes */ leaf fault-clears { type yang:counter32; description "Number of times that link experienced fault clear event."; } leaf fault-detects { type yang:counter32; description "Number of times that link experienced fault detection."; } leaf protection-switches { type yang:counter32; description "Number of times that link experienced protection switchover."; } Liu, et al Expires December 19, 2019 [Page 55] Internet-Draft YANG - TE Topology June 2019 leaf protection-reverts { type yang:counter32; description "Number of times that link experienced protection reversion."; } leaf restoration-failures { type yang:counter32; description "Number of times that link experienced restoration failure."; } leaf restoration-starts { type yang:counter32; description "Number of times that link experienced restoration start."; } leaf restoration-successes { type yang:counter32; description "Number of times that link experienced restoration success."; } leaf restoration-reversion-failures { type yang:counter32; description "Number of times that link experienced restoration reversion failure."; } leaf restoration-reversion-starts { type yang:counter32; description "Number of times that link experienced restoration reversion start."; } leaf restoration-reversion-successes { type yang:counter32; description "Number of times that link experienced restoration reversion success."; Liu, et al Expires December 19, 2019 [Page 56] Internet-Draft YANG - TE Topology June 2019 } } // statistics-per-link grouping statistics-per-node { description "Statistics attributes per TE node."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container node { description "Containing TE node level statistics attributes."; leaf disables { type yang:counter32; description "Number of times that node was disabled."; } leaf enables { type yang:counter32; description "Number of times that node was enabled."; } leaf maintenance-sets { type yang:counter32; description "Number of times that node was put in maintenance."; } leaf maintenance-clears { type yang:counter32; description "Number of times that node was put out of maintenance."; } leaf modifies { type yang:counter32; Liu, et al Expires December 19, 2019 [Page 57] Internet-Draft YANG - TE Topology June 2019 description "Number of times that node was modified."; } } // node container connectivity-matrix-entry { description "Containing connectivity matrix entry level statistics attributes."; leaf creates { type yang:counter32; description "Number of times that a connectivity matrix entry was created."; reference "RFC 6241. Section 7.2 for 'create' operation. "; } leaf deletes { type yang:counter32; description "Number of times that a connectivity matrix entry was deleted."; reference "RFC 6241. Section 7.2 for 'delete' operation. "; } leaf disables { type yang:counter32; description "Number of times that a connectivity matrix entry was disabled."; } leaf enables { type yang:counter32; description "Number of times that a connectivity matrix entry was enabled."; } leaf modifies { type yang:counter32; description "Number of times that a connectivity matrix entry was modified."; Liu, et al Expires December 19, 2019 [Page 58] Internet-Draft YANG - TE Topology June 2019 } } // connectivity-matrix-entry } // statistics-per-node grouping statistics-per-ttp { description "Statistics attributes per TE TTP (Tunnel Termination Point)."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container tunnel-termination-point { description "Containing TE TTP (Tunnel Termination Point) level statistics attributes."; /* Administrative attributes */ leaf disables { type yang:counter32; description "Number of times that TTP was disabled."; } leaf enables { type yang:counter32; description "Number of times that TTP was enabled."; } leaf maintenance-clears { type yang:counter32; description "Number of times that TTP was put out of maintenance."; } leaf maintenance-sets { type yang:counter32; description "Number of times that TTP was put in maintenance."; Liu, et al Expires December 19, 2019 [Page 59] Internet-Draft YANG - TE Topology June 2019 } leaf modifies { type yang:counter32; description "Number of times that TTP was modified."; } /* Operational attributes */ leaf downs { type yang:counter32; description "Number of times that TTP was set to operational down."; } leaf ups { type yang:counter32; description "Number of times that TTP was set to operational up."; } leaf in-service-clears { type yang:counter32; description "Number of times that TTP was taken out of service (TE tunnel was released)."; } leaf in-service-sets { type yang:counter32; description "Number of times that TTP was put in service by a TE tunnel (TE tunnel was set up)."; } } // tunnel-termination-point container local-link-connectivity { description "Containing TE LLCL (Local Link Connectivity List) level statistics attributes."; leaf creates { type yang:counter32; description "Number of times that an LLCL entry was created."; reference "RFC 6241. Section 7.2 for 'create' operation."; Liu, et al Expires December 19, 2019 [Page 60] Internet-Draft YANG - TE Topology June 2019 } leaf deletes { type yang:counter32; description "Number of times that an LLCL entry was deleted."; reference "RFC 6241. Section 7.2 for 'delete' operation."; } leaf disables { type yang:counter32; description "Number of times that an LLCL entry was disabled."; } leaf enables { type yang:counter32; description "Number of times that an LLCL entry was enabled."; } leaf modifies { type yang:counter32; description "Number of times that an LLCL entry was modified."; } } // local-link-connectivity } // statistics-per-ttp grouping te-link-augment { description "Augmentation for TE link."; uses te-link-config; uses te-link-state-derived; container statistics { config false; description "Statistics data."; uses statistics-per-link; } // statistics } // te-link-augment grouping te-link-config { description Liu, et al Expires December 19, 2019 [Page 61] Internet-Draft YANG - TE Topology June 2019 "TE link configuration grouping."; choice bundle-stack-level { description "The TE link can be partitioned into bundled links, or component links."; case bundle { container bundled-links { description "A set of bundled links."; reference "RFC 4201: Link Bundling in MPLS Traffic Engineering (TE)."; list bundled-link { key "sequence"; description "Specify a bundled interface that is further partitioned."; leaf sequence { type uint32; description "Identify the sequence in the bundle."; } } // list bundled-link } } case component { container component-links { description "A set of component links"; list component-link { key "sequence"; description "Specify a component interface that is sufficient to unambiguously identify the appropriate resources"; leaf sequence { type uint32; description "Identify the sequence in the bundle."; } Liu, et al Expires December 19, 2019 [Page 62] Internet-Draft YANG - TE Topology June 2019 leaf src-interface-ref { type string; description "Reference to component link interface on the source node."; } leaf des-interface-ref { type string; description "Reference to component link interface on the destinatioin node."; } } } } } // bundle-stack-level leaf-list te-link-template { if-feature template; type leafref { path "../../../../te/templates/link-template/name"; } description "The reference to a TE link template."; } uses te-link-config-attributes; } // te-link-config grouping te-link-config-attributes { description "Link configuration attributes in a TE topology."; container te-link-attributes { description "Link attributes in a TE topology."; leaf access-type { type te-types:te-link-access-type; description "Link access type, which can be point-to-point or multi-access."; } container external-domain { description Liu, et al Expires December 19, 2019 [Page 63] Internet-Draft YANG - TE Topology June 2019 "For an inter-domain link, specify the attributes of the remote end of link, to facilitate the signalling at local end."; uses nw:network-ref; leaf remote-te-node-id { type te-types:te-node-id; description "Remote TE node identifier, used together with remote-te-link-id to identify the remote link termination point in a different domain."; } leaf remote-te-link-tp-id { type te-types:te-tp-id; description "Remote TE link termination point identifier, used together with remote-te-node-id to identify the remote link termination point in a different domain."; } } leaf is-abstract { type empty; description "Present if the link is abstract."; } leaf name { type string; description "Link Name."; } container underlay { if-feature te-topology-hierarchy; description "Attributes of the te-link underlay."; reference "RFC 4206: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"; uses te-link-underlay-attributes; } // underlay leaf admin-status { type te-types:te-admin-status; description "The administrative state of the link."; Liu, et al Expires December 19, 2019 [Page 64] Internet-Draft YANG - TE Topology June 2019 } uses te-link-info-attributes; } // te-link-attributes } // te-link-config-attributes grouping te-link-info-attributes { description "Advertised TE information attributes."; leaf link-index { type uint64; description "The link identifier. If OSPF is used, this represents an ospfLsdbID. If IS-IS is used, this represents an isisLSPID. If a locally configured link is used, this object represents a unique value, which is locally defined in a router."; } leaf administrative-group { type te-types:admin-groups; description "Administrative group or color of the link. This attribute covers both administrative group (defined in RFC 3630, RFC 5305 and RFC 5329), and extended administrative group (defined in RFC 7308)."; } uses interface-switching-capability-list; uses te-types:label-set-info; leaf link-protection-type { type identityref { base te-types:link-protection-type; } description "Link Protection Type desired for this link."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)."; } container max-link-bandwidth { Liu, et al Expires December 19, 2019 [Page 65] Internet-Draft YANG - TE Topology June 2019 uses te-types:te-bandwidth; description "Maximum bandwidth that can be seen on this link in this direction. Units in bytes per second."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2. RFC 5305: IS-IS Extensions for Traffic Engineering."; } container max-resv-link-bandwidth { uses te-types:te-bandwidth; description "Maximum amount of bandwidth that can be reserved in this direction in this link. Units in bytes per second."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2. RFC 5305: IS-IS Extensions for Traffic Engineering."; } list unreserved-bandwidth { key "priority"; max-elements "8"; description "Unreserved bandwidth for 0-7 priority levels. Units in bytes per second."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2. RFC 5305: IS-IS Extensions for Traffic Engineering."; leaf priority { type uint8 { range "0..7"; } description "Priority."; } uses te-types:te-bandwidth; } leaf te-default-metric { type uint32; description "Traffic engineering metric."; Liu, et al Expires December 19, 2019 [Page 66] Internet-Draft YANG - TE Topology June 2019 reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2. RFC 5305: IS-IS Extensions for Traffic Engineering."; } leaf te-delay-metric { type uint32; description "Traffic engineering delay metric."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions."; } leaf te-igp-metric { type uint32; description "IGP metric used for traffic engineering."; reference "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a Second MPLS Traffic Engineering (TE) Metric."; } container te-srlgs { description "Containing a list of SLRGs."; leaf-list value { type te-types:srlg; description "SRLG value."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)."; } } container te-nsrlgs { if-feature nsrlg; description "Containing a list of NSRLGs (Not Sharing Risk Link Groups). When an abstract TE link is configured, this list specifies the request that underlay TE paths need to be mutually disjoint with other TE links in the same groups."; leaf-list id { type uint32; Liu, et al Expires December 19, 2019 [Page 67] Internet-Draft YANG - TE Topology June 2019 description "NSRLG ID, uniquely configured within a topology."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } } } // te-link-info-attributes grouping te-link-iscd-attributes { description "TE link ISCD (Interface Switching Capability Descriptor) attributes."; reference "Sec 1.4, RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). Section 1.4."; list max-lsp-bandwidth { key "priority"; max-elements "8"; description "Maximum LSP Bandwidth at priorities 0-7."; leaf priority { type uint8 { range "0..7"; } description "Priority."; } uses te-types:te-bandwidth; } } // te-link-iscd-attributes grouping te-link-state-derived { description "Link state attributes in a TE topology."; leaf oper-status { type te-types:te-oper-status; config false; description "The current operational state of the link."; } Liu, et al Expires December 19, 2019 [Page 68] Internet-Draft YANG - TE Topology June 2019 leaf is-transitional { type empty; config false; description "Present if the link is transitional, used as an alternative approach in lieu of inter-layer-lock-id for path computation in a TE topology covering multiple layers or multiple regions."; reference "RFC 5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN). RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)."; } uses information-source-per-link-attributes; list information-source-entry { key "information-source information-source-instance"; config false; description "A list of information sources learned, including the one used."; uses information-source-per-link-attributes; uses te-link-info-attributes; } container recovery { config false; description "Status of the recovery process."; leaf restoration-status { type te-types:te-recovery-status; description "Restoration status."; } leaf protection-status { type te-types:te-recovery-status; description "Protection status."; } } container underlay { if-feature te-topology-hierarchy; Liu, et al Expires December 19, 2019 [Page 69] Internet-Draft YANG - TE Topology June 2019 config false; description "State attributes for te-link underlay."; leaf dynamic { type boolean; description "true if the underlay is dynamically created."; } leaf committed { type boolean; description "true if the underlay is committed."; } } } // te-link-state-derived grouping te-link-underlay-attributes { description "Attributes for te-link underlay."; reference "RFC 4206: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"; leaf enabled { type boolean; description "'true' if the underlay is enabled. 'false' if the underlay is disabled."; } container primary-path { description "The service path on the underlay topology that supports this link."; uses nw:network-ref; list path-element { key "path-element-id"; description "A list of path elements describing the service path."; leaf path-element-id { type uint32; description "To identify the element in a path."; } uses te-path-element; Liu, et al Expires December 19, 2019 [Page 70] Internet-Draft YANG - TE Topology June 2019 } } // primary-path list backup-path { key "index"; description "A list of backup service paths on the underlay topology that protect the underlay primary path. If the primary path is not protected, the list contains zero elements. If the primary path is protected, the list contains one or more elements."; leaf index { type uint32; description "A sequence number to identify a backup path."; } uses nw:network-ref; list path-element { key "path-element-id"; description "A list of path elements describing the backup service path"; leaf path-element-id { type uint32; description "To identify the element in a path."; } uses te-path-element; } } // underlay-backup-path leaf protection-type { type identityref { base te-types:lsp-protection-type; } description "Underlay protection type desired for this link."; } container tunnel-termination-points { description "Underlay TTP(Tunnel Termination Points) desired for this link."; leaf source { type binary; Liu, et al Expires December 19, 2019 [Page 71] Internet-Draft YANG - TE Topology June 2019 description "Source tunnel termination point identifier."; } leaf destination { type binary; description "Destination tunnel termination point identifier."; } } container tunnels { description "Underlay TE tunnels supporting this TE link."; leaf sharing { type boolean; default true; description "'true' if the underlay tunnel can be shared with other TE links; 'false' if the underlay tunnel is dedicated to this TE link. This leaf is the default option for all TE tunnels, and may be overridden by the per TE tunnel value."; } list tunnel { key "tunnel-name"; description "Zero, one or more underlay TE tunnels that support this TE link."; leaf tunnel-name { type string; description "A tunnel name uniquely identifies an underlay TE tunnel, used together with the source-node of this link. The detailed information of this tunnel can be retrieved from the ietf-te model."; reference "RFC 3209"; } leaf sharing { type boolean; description "'true' if the underlay tunnel can be shared with other Liu, et al Expires December 19, 2019 [Page 72] Internet-Draft YANG - TE Topology June 2019 TE links; 'false' if the underlay tunnel is dedicated to this TE link."; } } // tunnel } // tunnels } // te-link-underlay-attributes grouping te-node-augment { description "Augmentation for TE node."; uses te-node-config; uses te-node-state-derived; container statistics { config false; description "Statistics data."; uses statistics-per-node; } // statistics list tunnel-termination-point { key "tunnel-tp-id"; description "A termination point can terminate a tunnel."; leaf tunnel-tp-id { type binary; description "Tunnel termination point identifier."; } uses te-node-tunnel-termination-point-config; leaf oper-status { type te-types:te-oper-status; config false; description "The current operational state of the tunnel termination point."; } uses geolocation-container; container statistics { config false; Liu, et al Expires December 19, 2019 [Page 73] Internet-Draft YANG - TE Topology June 2019 description "Statistics data."; uses statistics-per-ttp; } // statistics // Relations to other tunnel termination points list supporting-tunnel-termination-point { key "node-ref tunnel-tp-ref"; description "Identifies the tunnel termination points, that this tunnel termination point is depending on."; leaf node-ref { type inet:uri; description "This leaf identifies the node in which the supporting tunnel termination point is present. This node is either the supporting node or a node in an underlay topology."; } leaf tunnel-tp-ref { type binary; description "Reference to a tunnel terminiation point, which is either in the supporting node or a node in an underlay topology."; } } // supporting-tunnel-termination-point } // tunnel-termination-point } // te-node-augment grouping te-node-config { description "TE node configuration grouping."; leaf-list te-node-template { if-feature template; type leafref { path "../../../../te/templates/node-template/name"; } description "The reference to a TE node template."; } uses te-node-config-attributes; Liu, et al Expires December 19, 2019 [Page 74] Internet-Draft YANG - TE Topology June 2019 } // te-node-config grouping te-node-config-attributes { description "Configuration node attributes in a TE topology."; container te-node-attributes { description "Containing node attributes in a TE topology."; leaf admin-status { type te-types:te-admin-status; description "The administrative state of the link."; } uses te-node-connectivity-matrices; uses te-node-info-attributes; } // te-node-attributes } // te-node-config-attributes grouping te-node-config-attributes-template { description "Configuration node attributes for template in a TE topology."; container te-node-attributes { description "Containing node attributes in a TE topology."; leaf admin-status { type te-types:te-admin-status; description "The administrative state of the link."; } uses te-node-info-attributes; } // te-node-attributes } // te-node-config-attributes-template grouping te-node-connectivity-matrices { description "Connectivity matrix on a TE node."; container connectivity-matrices { description "Containing connectivity matrix on a TE node."; leaf number-of-entries { type uint16; description "The number of connectivity matrix entries. If this number is specified in the configuration request, the number is requested number of entries, which may not Liu, et al Expires December 19, 2019 [Page 75] Internet-Draft YANG - TE Topology June 2019 all be listed in the list; if this number is reported in the state data, the number is the current number of operational entries."; } uses te-types:label-set-info; uses connectivity-matrix-entry-path-attributes; list connectivity-matrix { key "id"; description "Represents node's switching limitations, i.e. limitations in interconnecting network TE links across the node."; reference "RFC 7579: General Network Element Constraint Encoding for GMPLS-Controlled Networks."; leaf id { type uint32; description "Identifies the connectivity-matrix entry."; } } // connectivity-matrix } // connectivity-matrices } // te-node-connectivity-matrices grouping te-node-connectivity-matrix-attributes { description "Termination point references of a connectivity matrix entry."; container from { description "Reference to source link termination point."; leaf tp-ref { type leafref { path "../../../../../../nt:termination-point/nt:tp-id"; } description "Relative reference to a termination point."; } uses te-types:label-set-info; } container to { description "Reference to destination link termination point."; leaf tp-ref { Liu, et al Expires December 19, 2019 [Page 76] Internet-Draft YANG - TE Topology June 2019 type leafref { path "../../../../../../nt:termination-point/nt:tp-id"; } description "Relative reference to a termination point."; } uses te-types:label-set-info; } uses connectivity-matrix-entry-path-attributes; } // te-node-connectivity-matrix-attributes grouping te-node-info-attributes { description "Advertised TE information attributes."; leaf domain-id { type uint32; description "Identifies the domain that this node belongs. This attribute is used to support inter-domain links."; reference "RFC 5152: A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs). RFC 5392: OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering. RFC 5316: ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering."; } leaf is-abstract { type empty; description "Present if the node is abstract, not present if the node is actual."; } leaf name { type string; description "Node name."; } leaf-list signaling-address { type inet:ip-address; description "Node signaling address."; Liu, et al Expires December 19, 2019 [Page 77] Internet-Draft YANG - TE Topology June 2019 } container underlay-topology { if-feature te-topology-hierarchy; description "When an abstract node encapsulates a topology, the attributes in this container point to said topology."; uses nw:network-ref; } } // te-node-info-attributes grouping te-node-state-derived { description "Node state attributes in a TE topology."; leaf oper-status { type te-types:te-oper-status; config false; description "The current operational state of the node."; } uses geolocation-container; leaf is-multi-access-dr { type empty; config false; description "The presence of this attribute indicates that this TE node is a pseudonode elected as a designated router."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2. RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments."; } uses information-source-per-node-attributes; list information-source-entry { key "information-source information-source-instance"; config false; description "A list of information sources learned, including the one used."; uses information-source-per-node-attributes; uses te-node-connectivity-matrices; uses te-node-info-attributes; Liu, et al Expires December 19, 2019 [Page 78] Internet-Draft YANG - TE Topology June 2019 } } // te-node-state-derived grouping te-node-tunnel-termination-point-config { description "Termination capability of a tunnel termination point on a TE node."; uses te-node-tunnel-termination-point-config-attributes; container local-link-connectivities { description "Containing local link connectivity list for a tunnel termination point on a TE node."; leaf number-of-entries { type uint16; description "The number of local link connectivity list entries. If this number is specified in the configuration request, the number is requested number of entries, which may not all be listed in the list; if this number is reported in the state data, the number is the current number of operational entries."; } uses te-types:label-set-info; uses connectivity-matrix-entry-path-attributes; } // local-link-connectivities } // te-node-tunnel-termination-point-config grouping te-node-tunnel-termination-point-config-attributes { description "Configuration attributes of a tunnel termination point on a TE node."; leaf admin-status { type te-types:te-admin-status; description "The administrative state of the tunnel termination point."; } leaf name { type string; description "A descriptive name for the tunnel termination point."; } Liu, et al Expires December 19, 2019 [Page 79] Internet-Draft YANG - TE Topology June 2019 leaf switching-capability { type identityref { base te-types:switching-capabilities; } description "Switching Capability for this interface."; } leaf encoding { type identityref { base te-types:lsp-encoding-types; } description "Encoding supported by this interface."; } leaf-list inter-layer-lock-id { type uint32; description "Inter layer lock ID, used for path computation in a TE topology covering multiple layers or multiple regions."; reference "RFC 5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN). RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)."; } leaf protection-type { type identityref { base te-types:lsp-protection-type; } description "The protection type that this tunnel termination point is capable of."; } container client-layer-adaptation { description "Containing capability information to support a client layer adaption in multi-layer topology."; list switching-capability { key "switching-capability encoding"; description Liu, et al Expires December 19, 2019 [Page 80] Internet-Draft YANG - TE Topology June 2019 "List of supported switching capabilities"; reference "RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN). RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)."; leaf switching-capability { type identityref { base te-types:switching-capabilities; } description "Switching Capability for the client layer adaption."; } leaf encoding { type identityref { base te-types:lsp-encoding-types; } description "Encoding supported by the client layer adaption."; } uses te-types:te-bandwidth; } } } // te-node-tunnel-termination-point-config-attributes grouping te-node-tunnel-termination-point-llc-list { description "Local link connectivity list of a tunnel termination point on a TE node."; list local-link-connectivity { key "link-tp-ref"; description "The termination capabilities between tunnel-termination-point and link termination-point. The capability information can be used to compute the tunnel path. The Interface Adjustment Capability Descriptors (IACD) (defined in RFC 6001) on each link-tp can be derived from this local-link-connectivity list."; reference "RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions Liu, et al Expires December 19, 2019 [Page 81] Internet-Draft YANG - TE Topology June 2019 for Multi-Layer and Multi-Region Networks (MLN/MRN)."; leaf link-tp-ref { type leafref { path "../../../../../nt:termination-point/nt:tp-id"; } description "Link termination point."; } uses te-types:label-set-info; uses connectivity-matrix-entry-path-attributes; } // local-link-connectivity } // te-node-tunnel-termination-point-config grouping te-path-element { description "A group of attributes defining an element in a TE path such as TE node, TE link, TE atomic resource or label."; uses te-types:explicit-route-hop; } // te-path-element grouping te-termination-point-augment { description "Augmentation for TE termination point."; leaf te-tp-id { type te-types:te-tp-id; description "An identifier to uniquely identify a TE termination point."; } container te { must "../te-tp-id"; presence "TE support."; description "Indicates TE support."; uses te-termination-point-config; leaf oper-status { type te-types:te-oper-status; config false; description Liu, et al Expires December 19, 2019 [Page 82] Internet-Draft YANG - TE Topology June 2019 "The current operational state of the link termination point."; } uses geolocation-container; } // te } // te-termination-point-augment grouping te-termination-point-config { description "TE termination point configuration grouping."; leaf admin-status { type te-types:te-admin-status; description "The administrative state of the link termination point."; } leaf name { type string; description "A descriptive name for the link termination point."; } uses interface-switching-capability-list; leaf inter-domain-plug-id { type binary; description "A topology-wide unique number that identifies on the network a connectivity supporting a given inter-domain TE link. This is more flexible alternative to specifying remote-te-node-id and remote-te-link-tp-id on a TE link, when the provider does not know remote-te-node-id and remote-te-link-tp-id or need to give client the flexibility to mix-n-match multiple topologies."; } leaf-list inter-layer-lock-id { type uint32; description "Inter layer lock ID, used for path computation in a TE topology covering multiple layers or multiple regions."; reference "RFC 5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN). RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions Liu, et al Expires December 19, 2019 [Page 83] Internet-Draft YANG - TE Topology June 2019 for Multi-Layer and Multi-Region Networks (MLN/MRN)."; } } // te-termination-point-config grouping te-topologies-augment { description "Augmentation for TE topologies."; container te { presence "TE support."; description "Indicates TE support."; container templates { description "Configuration parameters for templates used for TE topology."; list node-template { if-feature template; key "name"; leaf name { type te-types:te-template-name; description "The name to identify a TE node template."; } description "The list of TE node templates used to define sharable and reusable TE node attributes."; uses template-attributes; uses te-node-config-attributes-template; } // node-template list link-template { if-feature template; key "name"; leaf name { type te-types:te-template-name; description "The name to identify a TE link template."; } description Liu, et al Expires December 19, 2019 [Page 84] Internet-Draft YANG - TE Topology June 2019 "The list of TE link templates used to define sharable and reusable TE link attributes."; uses template-attributes; uses te-link-config-attributes; } // link-template } // templates } // te } // te-topologies-augment grouping te-topology-augment { description "Augmentation for TE topology."; uses te-types:te-topology-identifier; container te { must "../te-topology-identifier/provider-id" + " and ../te-topology-identifier/client-id" + " and ../te-topology-identifier/topology-id"; presence "TE support."; description "Indicates TE support."; uses te-topology-config; uses geolocation-container; } // te } // te-topology-augment grouping te-topology-config { description "TE topology configuration grouping."; leaf name { type string; description "Name of the TE topology. This attribute is optional and can be specified by the operator to describe the TE topology, which can be useful when network-id is not descriptive and not modifiable because of being generated by the system."; } leaf preference { type uint8 { Liu, et al Expires December 19, 2019 [Page 85] Internet-Draft YANG - TE Topology June 2019 range "1..255"; } description "Specifies a preference for this topology. A lower number indicates a higher preference."; } leaf optimization-criterion { type identityref { base te-types:objective-function-type; } description "Optimization criterion applied to this topology."; reference "RFC 3272: Overview and Principles of Internet Traffic Engineering."; } list nsrlg { if-feature nsrlg; key "id"; description "List of NSRLGs (Not Sharing Risk Link Groups)."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; leaf id { type uint32; description "Identify the NSRLG entry."; } leaf disjointness { type te-types:te-path-disjointness; description "The type of resource disjointness."; } } // nsrlg } // te-topology-config grouping template-attributes { description "Common attributes for all templates."; Liu, et al Expires December 19, 2019 [Page 86] Internet-Draft YANG - TE Topology June 2019 leaf priority { type uint16; description "The preference value to resolve conflicts between different templates. When two or more templates specify values for one configuration attribute, the value from the template with the highest priority is used. A lower number indicates a higher priority. The highest priority is 0."; } leaf reference-change-policy { type enumeration { enum no-action { description "When an attribute changes in this template, the configuration node referring to this template does not take any action."; } enum not-allowed { description "When any configuration object has a reference to this template, changing this template is not allowed."; } enum cascade { description "When an attribute changes in this template, the configuration object referring to this template applies the new attribute value to the corresponding configuration."; } } description "This attribute specifies the action taken to a configuration node that has a reference to this template."; } } // template-attributes /* * Data nodes */ augment "/nw:networks/nw:network/nw:network-types" { Liu, et al Expires December 19, 2019 [Page 87] Internet-Draft YANG - TE Topology June 2019 description "Introduce new network type for TE topology."; container te-topology { presence "Indicates TE topology."; description "Its presence identifies the TE topology type."; } } augment "/nw:networks" { description "Augmentation parameters for TE topologies."; uses te-topologies-augment; } augment "/nw:networks/nw:network" { when "nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE topology."; uses te-topology-augment; } augment "/nw:networks/nw:network/nw:node" { when "../nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE at node level."; leaf te-node-id { type te-types:te-node-id; description "The identifier of a node in the TE topology. A node is specific to a topology to which it belongs."; } container te { Liu, et al Expires December 19, 2019 [Page 88] Internet-Draft YANG - TE Topology June 2019 must "../te-node-id" { description "te-node-id is mandatory."; } must "count(../nw:supporting-node)<=1" { description "For a node in a TE topology, there cannot be more than 1 supporting node. If multiple nodes are abstracted, the underlay-topology is used."; } presence "TE support."; description "Indicates TE support."; uses te-node-augment; } // te } augment "/nw:networks/nw:network/nt:link" { when "../nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE at link level."; container te { must "count(../nt:supporting-link)<=1" { description "For a link in a TE topology, there cannot be more than 1 supporting link. If one or more link paths are abstracted, the underlay is used."; } presence "TE support."; description "Indicates TE support."; uses te-link-augment; } // te } augment "/nw:networks/nw:network/nw:node/" + "nt:termination-point" { Liu, et al Expires December 19, 2019 [Page 89] Internet-Draft YANG - TE Topology June 2019 when "../../nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE at termination point level."; uses te-termination-point-augment; } augment "/nw:networks/nw:network/nt:link/te/bundle-stack-level/" + "bundle/bundled-links/bundled-link" { when "../../../../nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Augment TE link bundled link."; leaf src-tp-ref { type leafref { path "../../../../../nw:node[nw:node-id = " + "current()/../../../../nt:source/" + "nt:source-node]/" + "nt:termination-point/nt:tp-id"; require-instance true; } description "Reference to another TE termination point on the same source node."; } leaf des-tp-ref { type leafref { path "../../../../../nw:node[nw:node-id = " + "current()/../../../../nt:destination/" + "nt:dest-node]/" + "nt:termination-point/nt:tp-id"; require-instance true; } description Liu, et al Expires December 19, 2019 [Page 90] Internet-Draft YANG - TE Topology June 2019 "Reference to another TE termination point on the same destination node."; } } augment "/nw:networks/nw:network/nw:node/te/" + "information-source-entry/connectivity-matrices/" + "connectivity-matrix" { when "../../../../../nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Augment TE node connectivity-matrix."; uses te-node-connectivity-matrix-attributes; } augment "/nw:networks/nw:network/nw:node/te/te-node-attributes/" + "connectivity-matrices/connectivity-matrix" { when "../../../../../nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Augment TE node connectivity-matrix."; uses te-node-connectivity-matrix-attributes; } augment "/nw:networks/nw:network/nw:node/te/" + "tunnel-termination-point/local-link-connectivities" { when "../../../../nw:network-types/tet:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description Liu, et al Expires December 19, 2019 [Page 91] Internet-Draft YANG - TE Topology June 2019 "Augment TE node tunnel termination point LLCs (Local Link Connectivities)."; uses te-node-tunnel-termination-point-llc-list; } } 8. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: o /nw:networks/nw:network/nw:network-types/tet:te-topology This subtree specifies the TE topology type. Modifying the configurations can make TE topology type invalid. By such modifications, a malicious attacker may disable the TE capabilities on the related networks and cause traffic disrupted or misrouted. o /nw:networks/tet:te This subtree specifies the TE node templates and TE link templates. Modifying the configurations in this subtree will change the related future TE configurations. By such modifications, a malicious attacker may change the TE capabilities scheduled at a future time, to cause traffic disrupted or misrouted. Liu, et al Expires December 19, 2019 [Page 92] Internet-Draft YANG - TE Topology June 2019 o /nw:networks/nw:network This subtree specifies the topology-wide configurations, including the TE topology ID and topology-wide policies. Modifying the configurations in this subtree can add, remove, or modify TE topologies. By adding a TE topology, a malicious attacker may create an unauthorized traffic network. By removing or modifying a TE topology, a malicious attacker may cause traffic disabled or misrouted in the specified TE topology. Such traffic changes may also affect the traffic in the connected TE topologies. o /nw:networks/nw:network/nw:node This subtree specifies the configurations for TE nodes. Modifying the configurations in this subtree can add, remove, or modify TE nodes. By adding a TE node, a malicious attacker may create an unauthorized traffic path. By removing or modifying a TE node, a malicious attacker may cause traffic disabled or misrouted in the specified TE node. Such traffic changes may also affect the traffic on the surrounding TE nodes and TE links in this TE topology and the connected TE topologies. o /nw:networks/nw:network/nt:link/tet:te This subtree specifies the configurations for TE links. Modifying the configurations in this subtree can add, remove, or modify TE links. By adding a TE link, a malicious attacker may create an unauthorized traffic path. By removing or modifying a TE link, a malicious attacker may cause traffic disabled or misrouted on the specified TE link. Such traffic changes may also affect the traffic on the surrounding TE nodes and TE links in this TE topology and the connected TE topologies. o /nw:networks/nw:network/nw:node/nt:termination-point This subtree specifies the configurations of TE link termination points. Modifying the configurations in this subtree can add, remove, or modify TE link termination points. By adding a TE link termination point, a malicious attacker may create an unauthorized traffic path. By removing or modifying a TE link termination point, a malicious attacker may cause traffic disabled or misrouted on the specified TE link termination point. Such traffic changes may also affect the traffic on the surrounding TE nodes and TE links in this TE topology and the connected TE topologies. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: Liu, et al Expires December 19, 2019 [Page 93] Internet-Draft YANG - TE Topology June 2019 o /nw:networks/nw:network/nw:network-types/tet:te-topology Unauthorized access to this subtree can disclose the TE topology type. o /nw:networks/tet:te Unauthorized access to this subtree can disclose the TE node templates and TE link templates. o /nw:networks/nw:network Unauthorized access to this subtree can disclose the topology-wide configurations, including the TE topology ID, the topology-wide policies, and the topology geolocation. o /nw:networks/nw:network/nw:node Unauthorized access to this subtree can disclose the operational state information of TE nodes. o /nw:networks/nw:network/nt:link/tet:te Unauthorized access to this subtree can disclose the operational state information of TE links. o /nw:networks/nw:network/nw:node/nt:termination-point Unauthorized access to this subtree can disclose the operational state information of TE link termination points. 9. IANA Considerations This document registers the following URIs in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-te-topology Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-state Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC7950]. name: ietf-te-topology namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology prefix: tet reference: RFC XXXX Liu, et al Expires December 19, 2019 [Page 94] Internet-Draft YANG - TE Topology June 2019 name: ietf-te-topology-state namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-state prefix: tet-s reference: RFC XXXX 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, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, . [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, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Liu, et al Expires December 19, 2019 [Page 95] Internet-Draft YANG - TE Topology June 2019 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [I-D.ietf-teas-yang-te-types] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "Traffic Engineering Common YANG Types", draft-ietf-teas-yang-te-types-08 (work in progress), April 2019. 10.2. Informative References [G.709] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, June 2016. [G.805] ITU-T, "Generic functional architecture of transport networks", ITU-T Recommendation G.805, March 2000. [G.872] ITU-T, "Architecture of optical transport networks", ITU-T Recommendation G.872, January 2017. [G.8080] ITU-T, "Architecture for the automatically switched optical network", ITU-T Recommendation G.8080, February 2012. Liu, et al Expires December 19, 2019 [Page 96] Internet-Draft YANG - TE Topology June 2019 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, . [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, . [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, . [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, DOI 10.17487/RFC3785, May 2004, . [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, DOI 10.17487/RFC4201, October 2005, . [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, . [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching Liu, et al Expires December 19, 2019 [Page 97] Internet-Draft YANG - TE Topology June 2019 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, . [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, . [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, . [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, . [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, DOI 10.17487/RFC5212, July 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 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, . [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [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, . [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, Liu, et al Expires December 19, 2019 [Page 98] Internet-Draft YANG - TE Topology June 2019 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, . [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, July 2014, . [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, . [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, June 2015, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [I-D.ietf-netconf-subscribed-notifications] Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Customized Subscriptions to a Publisher's Event Streams", draft-ietf-netconf-subscribed- notifications-23 (work in progress), February 2019. [I-D.ietf-netconf-yang-push] Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore Subscription", draft-ietf-netconf-yang-push-22 (work in progress), February 2019. [I-D.liu-netmod-yang-schedule] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "A YANG Data Model for Configuration Scheduling", draft-liu-netmod-yang-schedule-05 (work in progress), Liu, et al Expires December 19, 2019 [Page 99] Internet-Draft YANG - TE Topology June 2019 March 2018. [I-D.ietf-ccamp-wson-yang] Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., King, D., Yoon, B., and R. Vilata, "A Yang Data Model for WSON Optical Networks", draft-ietf-ccamp-wson-yang-20 (work in progress), March 2019. [I-D.ietf-ccamp-otn-topo-yang] zhenghaomian@huawei.com, z., Guo, A., Busi, I., Sharma, A., Liu, X., Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data Model for Optical Transport Network Topology", draft-ietf-ccamp-otn-topo-yang-06 (work in progress), February 2019. [I-D.ietf-teas-yang-l3-te-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model for Layer 3 TE Topologies", draft-ietf-teas-yang-l3-te-topo-04 (work in progress), March 2019. [I-D.ietf-teas-te-topo-and-tunnel-modeling] Bryskin, I., Beeram, V., Saad, T., and X. Liu, "TE Topology and Tunnel Modeling for Transport Networks", draft-ietf-teas-te-topo-and-tunnel-modeling-03 (work in progress), October 2018. 11. Acknowledgments The authors would like to thank Lou Berger, Sue Hares, Mazen Khaddam, Cyril Margaria and Zafar Ali for participating in design discussions and providing valuable insights. Liu, et al Expires December 19, 2019 [Page 100] Internet-Draft YANG - TE Topology June 2019 Appendix A. Complete Model Tree Structure module: ietf-te-topology augment /nw:networks/nw:network/nw:network-types: +--rw te-topology! augment /nw:networks: +--rw te! +--rw templates +--rw node-template* [name] {template}? | +--rw name | | te-types:te-template-name | +--rw priority? uint16 | +--rw reference-change-policy? enumeration | +--rw te-node-attributes | +--rw admin-status? te-types:te-admin-status | +--rw domain-id? uint32 | +--rw is-abstract? empty | +--rw name? string | +--rw signaling-address* inet:ip-address | +--rw underlay-topology {te-topology-hierarchy}? | +--rw network-ref? | -> /nw:networks/network/network-id +--rw link-template* [name] {template}? +--rw name | te-types:te-template-name +--rw priority? uint16 +--rw reference-change-policy? enumeration +--rw te-link-attributes +--rw access-type? | te-types:te-link-access-type +--rw external-domain | +--rw network-ref? | | -> /nw:networks/network/network-id | +--rw remote-te-node-id? te-types:te-node-id | +--rw remote-te-link-tp-id? te-types:te-tp-id +--rw is-abstract? empty +--rw name? string +--rw underlay {te-topology-hierarchy}? | +--rw enabled? boolean | +--rw primary-path | | +--rw network-ref? Liu, et al Expires December 19, 2019 [Page 101] Internet-Draft YANG - TE Topology June 2019 | | | -> /nw:networks/network/network-id | | +--rw path-element* [path-element-id] | | +--rw path-element-id uint32 | | +--rw (type)? | | +--:(numbered-node-hop) | | | +--rw numbered-node-hop | | | +--rw node-id te-node-id | | | +--rw hop-type? te-hop-type | | +--:(numbered-link-hop) | | | +--rw numbered-link-hop | | | +--rw link-tp-id te-tp-id | | | +--rw hop-type? te-hop-type | | | +--rw direction? | | | te-link-direction | | +--:(unnumbered-link-hop) | | | +--rw unnumbered-link-hop | | | +--rw link-tp-id te-tp-id | | | +--rw node-id te-node-id | | | +--rw hop-type? te-hop-type | | | +--rw direction? | | | te-link-direction | | +--:(as-number) | | | +--rw as-number-hop | | | +--rw as-number inet:as-number | | | +--rw hop-type? te-hop-type | | +--:(label) | | +--rw label-hop | | +--rw te-label | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? | | | rt- types:generalized-label | | +--rw direction? | | te-label-direction | +--rw backup-path* [index] | | +--rw index uint32 | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw path-element* [path-element-id] | | +--rw path-element-id uint32 Liu, et al Expires December 19, 2019 [Page 102] Internet-Draft YANG - TE Topology June 2019 | | +--rw (type)? | | +--:(numbered-node-hop) | | | +--rw numbered-node-hop | | | +--rw node-id te-node-id | | | +--rw hop-type? te-hop-type | | +--:(numbered-link-hop) | | | +--rw numbered-link-hop | | | +--rw link-tp-id te-tp-id | | | +--rw hop-type? te-hop-type | | | +--rw direction? | | | te-link-direction | | +--:(unnumbered-link-hop) | | | +--rw unnumbered-link-hop | | | +--rw link-tp-id te-tp-id | | | +--rw node-id te-node-id | | | +--rw hop-type? te-hop-type | | | +--rw direction? | | | te-link-direction | | +--:(as-number) | | | +--rw as-number-hop | | | +--rw as-number inet:as-number | | | +--rw hop-type? te-hop-type | | +--:(label) | | +--rw label-hop | | +--rw te-label | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? | | | rt- types:generalized-label | | +--rw direction? | | te-label-direction | +--rw protection-type? identityref | +--rw tunnel-termination-points | | +--rw source? binary | | +--rw destination? binary | +--rw tunnels | +--rw sharing? boolean | +--rw tunnel* [tunnel-name] | +--rw tunnel-name string | +--rw sharing? boolean Liu, et al Expires December 19, 2019 [Page 103] Internet-Draft YANG - TE Topology June 2019 +--rw admin-status? | te-types:te-admin-status +--rw link-index? uint64 +--rw administrative-group? | te-types:admin-groups +--rw interface-switching-capability* | [switching-capability encoding] | +--rw switching-capability identityref | +--rw encoding identityref | +--rw max-lsp-bandwidth* [priority] | +--rw priority uint8 | +--rw te-bandwidth | +--rw (technology)? | +--:(generic) | +--rw generic? te-bandwidth +--rw label-restrictions | +--rw label-restriction* [index] | +--rw restriction? enumeration | +--rw index uint32 | +--rw label-start | | +--rw te-label | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? | | | rt-types:generalized-label | | +--rw direction? te-label-direction | +--rw label-end | | +--rw te-label | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? | | | rt-types:generalized-label | | +--rw direction? te-label-direction | +--rw label-step | | +--rw (technology)? | | +--:(generic) | | +--rw generic? int32 | +--rw range-bitmap? yang:hex-string +--rw link-protection-type? identityref +--rw max-link-bandwidth | +--rw te-bandwidth Liu, et al Expires December 19, 2019 [Page 104] Internet-Draft YANG - TE Topology June 2019 | +--rw (technology)? | +--:(generic) | +--rw generic? te-bandwidth +--rw max-resv-link-bandwidth | +--rw te-bandwidth | +--rw (technology)? | +--:(generic) | +--rw generic? te-bandwidth +--rw unreserved-bandwidth* [priority] | +--rw priority uint8 | +--rw te-bandwidth | +--rw (technology)? | +--:(generic) | +--rw generic? te-bandwidth +--rw te-default-metric? uint32 +--rw te-delay-metric? uint32 +--rw te-igp-metric? uint32 +--rw te-srlgs | +--rw value* te-types:srlg +--rw te-nsrlgs {nsrlg}? +--rw id* uint32 augment /nw:networks/nw:network: +--rw te-topology-identifier | +--rw provider-id? te-global-id | +--rw client-id? te-global-id | +--rw topology-id? te-topology-id +--rw te! +--rw name? string +--rw preference? uint8 +--rw optimization-criterion? identityref +--rw nsrlg* [id] {nsrlg}? | +--rw id uint32 | +--rw disjointness? te-types:te-path-disjointness +--ro geolocation +--ro altitude? int64 +--ro latitude? geographic-coordinate-degree +--ro longitude? geographic-coordinate-degree augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! +--rw te-node-template* Liu, et al Expires December 19, 2019 [Page 105] Internet-Draft YANG - TE Topology June 2019 | -> ../../../../te/templates/node-template/name | {template}? +--rw te-node-attributes | +--rw admin-status? te-types:te-admin-status | +--rw connectivity-matrices | | +--rw number-of-entries? uint16 | | +--rw label-restrictions | | | +--rw label-restriction* [index] | | | +--rw restriction? enumeration | | | +--rw index uint32 | | | +--rw label-start | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized-label | | | | +--rw direction? te-label-direction | | | +--rw label-end | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized-label | | | | +--rw direction? te-label-direction | | | +--rw label-step | | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? int32 | | | +--rw range-bitmap? yang:hex-string | | +--rw is-allowed? boolean | | +--rw underlay {te-topology-hierarchy}? | | | +--rw enabled? boolean | | | +--rw primary-path | | | | +--rw network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--rw path-element* [path-element-id] | | | | +--rw path-element-id uint32 | | | | +--rw (type)? | | | | +--:(numbered-node-hop) | | | | | +--rw numbered-node-hop | | | | | +--rw node-id te-node-id Liu, et al Expires December 19, 2019 [Page 106] Internet-Draft YANG - TE Topology June 2019 | | | | | +--rw hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--rw numbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw hop-type? te-hop-type | | | | | +--rw direction? te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--rw unnumbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type | | | | | +--rw direction? te-link-direction | | | | +--:(as-number) | | | | | +--rw as-number-hop | | | | | +--rw as-number inet:as-number | | | | | +--rw hop-type? te-hop-type | | | | +--:(label) | | | | +--rw label-hop | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized- label | | | | +--rw direction? | | | | te-label-direction | | | +--rw backup-path* [index] | | | | +--rw index uint32 | | | | +--rw network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--rw path-element* [path-element-id] | | | | +--rw path-element-id uint32 | | | | +--rw (type)? | | | | +--:(numbered-node-hop) | | | | | +--rw numbered-node-hop | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--rw numbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw hop-type? te-hop-type Liu, et al Expires December 19, 2019 [Page 107] Internet-Draft YANG - TE Topology June 2019 | | | | | +--rw direction? te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--rw unnumbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type | | | | | +--rw direction? te-link-direction | | | | +--:(as-number) | | | | | +--rw as-number-hop | | | | | +--rw as-number inet:as-number | | | | | +--rw hop-type? te-hop-type | | | | +--:(label) | | | | +--rw label-hop | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized- label | | | | +--rw direction? | | | | te-label-direction | | | +--rw protection-type? identityref | | | +--rw tunnel-termination-points | | | | +--rw source? binary | | | | +--rw destination? binary | | | +--rw tunnels | | | +--rw sharing? boolean | | | +--rw tunnel* [tunnel-name] | | | +--rw tunnel-name string | | | +--rw sharing? boolean | | +--rw path-constraints | | | +--rw te-bandwidth | | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? te-bandwidth | | | +--rw link-protection? identityref | | | +--rw setup-priority? uint8 | | | +--rw hold-priority? uint8 | | | +--rw signaling-type? identityref | | | +--rw path-metric-bounds | | | | +--rw path-metric-bound* [metric-type] Liu, et al Expires December 19, 2019 [Page 108] Internet-Draft YANG - TE Topology June 2019 | | | | +--rw metric-type identityref | | | | +--rw upper-bound? uint64 | | | +--rw path-affinities-values | | | | +--rw path-affinities-value* [usage] | | | | +--rw usage identityref | | | | +--rw value? admin-groups | | | +--rw path-affinity-names | | | | +--rw path-affinity-name* [usage] | | | | +--rw usage identityref | | | | +--rw affinity-name* [name] | | | | +--rw name string | | | +--rw path-srlgs-lists | | | | +--rw path-srlgs-list* [usage] | | | | +--rw usage identityref | | | | +--rw values* srlg | | | +--rw path-srlgs-names | | | | +--rw path-srlgs-name* [usage] | | | | +--rw usage identityref | | | | +--rw names* string | | | +--rw disjointness? te-path-disjointness | | +--rw optimizations | | | +--rw (algorithm)? | | | +--:(metric) {path-optimization-metric}? | | | | +--rw optimization-metric* [metric-type] | | | | | +--rw metric-type | | | | | | identityref | | | | | +--rw weight? | | | | | | uint8 | | | | | +--rw explicit-route-exclude-objects | | | | | | +--rw route-object-exclude-object* | | | | | | [index] | | | | | | +--rw index | | | | | | | uint32 | | | | | | +--rw (type)? | | | | | | +--:(numbered-node-hop) | | | | | | | +--rw numbered-node-hop | | | | | | | +--rw node-id te-node-id | | | | | | | +--rw hop-type? te-hop-type | | | | | | +--:(numbered-link-hop) | | | | | | | +--rw numbered-link-hop | | | | | | | +--rw link-tp-id te-tp-id Liu, et al Expires December 19, 2019 [Page 109] Internet-Draft YANG - TE Topology June 2019 | | | | | | | +--rw hop-type? | | | | | | | | te-hop-type | | | | | | | +--rw direction? | | | | | | | te-link-direction | | | | | | +--:(unnumbered-link-hop) | | | | | | | +--rw unnumbered-link-hop | | | | | | | +--rw link-tp-id te-tp-id | | | | | | | +--rw node-id | | | | | | | | te-node-id | | | | | | | +--rw hop-type? | | | | | | | | te-hop-type | | | | | | | +--rw direction? | | | | | | | te-link-direction | | | | | | +--:(as-number) | | | | | | | +--rw as-number-hop | | | | | | | +--rw as-number | | | | | | | | inet:as-number | | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--:(label) | | | | | | | +--rw label-hop | | | | | | | +--rw te-label | | | | | | | +--rw (technology)? | | | | | | | | +--:(generic) | | | | | | | | +--rw generic? | | | | | | | | rt- types:generalized-label | | | | | | | +--rw direction? | | | | | | | te-label-direction | | | | | | +--:(srlg) | | | | | | +--rw srlg | | | | | | +--rw srlg? uint32 | | | | | +--rw explicit-route-include-objects | | | | | +--rw route-object-include-object* | | | | | [index] | | | | | +--rw index | | | | | | uint32 | | | | | +--rw (type)? | | | | | +--:(numbered-node-hop) | | | | | | +--rw numbered-node-hop | | | | | | +--rw node-id te-node-id Liu, et al Expires December 19, 2019 [Page 110] Internet-Draft YANG - TE Topology June 2019 | | | | | | +--rw hop-type? te-hop-type | | | | | +--:(numbered-link-hop) | | | | | | +--rw numbered-link-hop | | | | | | +--rw link-tp-id te-tp-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(unnumbered-link-hop) | | | | | | +--rw unnumbered-link-hop | | | | | | +--rw link-tp-id te-tp-id | | | | | | +--rw node-id | | | | | | | te-node-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(as-number) | | | | | | +--rw as-number-hop | | | | | | +--rw as-number | | | | | | | inet:as-number | | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--:(label) | | | | | +--rw label-hop | | | | | +--rw te-label | | | | | +--rw (technology)? | | | | | | +--:(generic) | | | | | | +--rw generic? | | | | | | rt- types:generalized-label | | | | | +--rw direction? | | | | | te-label-direction | | | | +--rw tiebreakers | | | | +--rw tiebreaker* [tiebreaker-type] | | | | +--rw tiebreaker-type identityref | | | +--:(objective-function) | | | {path-optimization-objective-function}? | | | +--rw objective-function | | | +--rw objective-function-type? identityref | | +--ro path-properties Liu, et al Expires December 19, 2019 [Page 111] Internet-Draft YANG - TE Topology June 2019 | | | +--ro path-metric* [metric-type] | | | | +--ro metric-type identityref | | | | +--ro accumulative-value? uint64 | | | +--ro path-affinities-values | | | | +--ro path-affinities-value* [usage] | | | | +--ro usage identityref | | | | +--ro value? admin-groups | | | +--ro path-affinity-names | | | | +--ro path-affinity-name* [usage] | | | | +--ro usage identityref | | | | +--ro affinity-name* [name] | | | | +--ro name string | | | +--ro path-srlgs-lists | | | | +--ro path-srlgs-list* [usage] | | | | +--ro usage identityref | | | | +--ro values* srlg | | | +--ro path-srlgs-names | | | | +--ro path-srlgs-name* [usage] | | | | +--ro usage identityref | | | | +--ro names* string | | | +--ro path-route-objects | | | +--ro path-route-object* [index] | | | +--ro index uint32 | | | +--ro (type)? | | | +--:(numbered-node-hop) | | | | +--ro numbered-node-hop | | | | +--ro node-id te-node-id | | | | +--ro hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--ro numbered-link-hop | | | | +--ro link-tp-id te-tp-id | | | | +--ro hop-type? te-hop-type | | | | +--ro direction? te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--ro unnumbered-link-hop | | | | +--ro link-tp-id te-tp-id | | | | +--ro node-id te-node-id | | | | +--ro hop-type? te-hop-type | | | | +--ro direction? te-link-direction | | | +--:(as-number) | | | | +--ro as-number-hop Liu, et al Expires December 19, 2019 [Page 112] Internet-Draft YANG - TE Topology June 2019 | | | | +--ro as-number inet:as-number | | | | +--ro hop-type? te-hop-type | | | +--:(label) | | | +--ro label-hop | | | +--ro te-label | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? | | | | rt-types:generalized- label | | | +--ro direction? | | | te-label-direction | | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref | | | +--rw label-restrictions | | | +--rw label-restriction* [index] | | | +--rw restriction? enumeration | | | +--rw index uint32 | | | +--rw label-start | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized- label | | | | +--rw direction? | | | | te-label-direction | | | +--rw label-end | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized- label | | | | +--rw direction? | | | | te-label-direction | | | +--rw label-step | | | | +--rw (technology)? | | | | +--:(generic) Liu, et al Expires December 19, 2019 [Page 113] Internet-Draft YANG - TE Topology June 2019 | | | | +--rw generic? int32 | | | +--rw range-bitmap? yang:hex-string | | +--rw to | | | +--rw tp-ref? leafref | | | +--rw label-restrictions | | | +--rw label-restriction* [index] | | | +--rw restriction? enumeration | | | +--rw index uint32 | | | +--rw label-start | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized- label | | | | +--rw direction? | | | | te-label-direction | | | +--rw label-end | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt-types:generalized- label | | | | +--rw direction? | | | | te-label-direction | | | +--rw label-step | | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? int32 | | | +--rw range-bitmap? yang:hex-string | | +--rw is-allowed? boolean | | +--rw underlay {te-topology-hierarchy}? | | | +--rw enabled? boolean | | | +--rw primary-path | | | | +--rw network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--rw path-element* [path-element-id] | | | | +--rw path-element-id uint32 | | | | +--rw (type)? | | | | +--:(numbered-node-hop) Liu, et al Expires December 19, 2019 [Page 114] Internet-Draft YANG - TE Topology June 2019 | | | | | +--rw numbered-node-hop | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--rw numbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw hop-type? te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--rw unnumbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(as-number) | | | | | +--rw as-number-hop | | | | | +--rw as-number inet:as-number | | | | | +--rw hop-type? te-hop-type | | | | +--:(label) | | | | +--rw label-hop | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt- types:generalized-label | | | | +--rw direction? | | | | te-label-direction | | | +--rw backup-path* [index] | | | | +--rw index uint32 | | | | +--rw network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--rw path-element* [path-element-id] | | | | +--rw path-element-id uint32 | | | | +--rw (type)? | | | | +--:(numbered-node-hop) | | | | | +--rw numbered-node-hop | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type Liu, et al Expires December 19, 2019 [Page 115] Internet-Draft YANG - TE Topology June 2019 | | | | +--:(numbered-link-hop) | | | | | +--rw numbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw hop-type? te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--rw unnumbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(as-number) | | | | | +--rw as-number-hop | | | | | +--rw as-number inet:as-number | | | | | +--rw hop-type? te-hop-type | | | | +--:(label) | | | | +--rw label-hop | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt- types:generalized-label | | | | +--rw direction? | | | | te-label-direction | | | +--rw protection-type? identityref | | | +--rw tunnel-termination-points | | | | +--rw source? binary | | | | +--rw destination? binary | | | +--rw tunnels | | | +--rw sharing? boolean | | | +--rw tunnel* [tunnel-name] | | | +--rw tunnel-name string | | | +--rw sharing? boolean | | +--rw path-constraints | | | +--rw te-bandwidth | | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? te-bandwidth Liu, et al Expires December 19, 2019 [Page 116] Internet-Draft YANG - TE Topology June 2019 | | | +--rw link-protection? identityref | | | +--rw setup-priority? uint8 | | | +--rw hold-priority? uint8 | | | +--rw signaling-type? identityref | | | +--rw path-metric-bounds | | | | +--rw path-metric-bound* [metric-type] | | | | +--rw metric-type identityref | | | | +--rw upper-bound? uint64 | | | +--rw path-affinities-values | | | | +--rw path-affinities-value* [usage] | | | | +--rw usage identityref | | | | +--rw value? admin-groups | | | +--rw path-affinity-names | | | | +--rw path-affinity-name* [usage] | | | | +--rw usage identityref | | | | +--rw affinity-name* [name] | | | | +--rw name string | | | +--rw path-srlgs-lists | | | | +--rw path-srlgs-list* [usage] | | | | +--rw usage identityref | | | | +--rw values* srlg | | | +--rw path-srlgs-names | | | | +--rw path-srlgs-name* [usage] | | | | +--rw usage identityref | | | | +--rw names* string | | | +--rw disjointness? | | | te-path-disjointness | | +--rw optimizations | | | +--rw (algorithm)? | | | +--:(metric) {path-optimization-metric}? | | | | +--rw optimization-metric* [metric-type] | | | | | +--rw metric-type | | | | | | identityref | | | | | +--rw weight? | | | | | | uint8 | | | | | +--rw explicit-route-exclude-objects | | | | | | +--rw route-object-exclude-object* | | | | | | [index] | | | | | | +--rw index | | | | | | | uint32 | | | | | | +--rw (type)? Liu, et al Expires December 19, 2019 [Page 117] Internet-Draft YANG - TE Topology June 2019 | | | | | | +--:(numbered-node-hop) | | | | | | | +--rw numbered-node-hop | | | | | | | +--rw node-id | | | | | | | | te-node-id | | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--:(numbered-link-hop) | | | | | | | +--rw numbered-link-hop | | | | | | | +--rw link-tp-id | | | | | | | | te-tp-id | | | | | | | +--rw hop-type? | | | | | | | | te-hop-type | | | | | | | +--rw direction? | | | | | | | te-link-direction | | | | | | +--:(unnumbered-link-hop) | | | | | | | +--rw unnumbered-link-hop | | | | | | | +--rw link-tp-id | | | | | | | | te-tp-id | | | | | | | +--rw node-id | | | | | | | | te-node-id | | | | | | | +--rw hop-type? | | | | | | | | te-hop-type | | | | | | | +--rw direction? | | | | | | | te-link-direction | | | | | | +--:(as-number) | | | | | | | +--rw as-number-hop | | | | | | | +--rw as-number | | | | | | | | inet:as-number | | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--:(label) | | | | | | | +--rw label-hop | | | | | | | +--rw te-label | | | | | | | +--rw (technology)? | | | | | | | | +--:(generic) | | | | | | | | +--rw generic? | | | | | | | | rt- types:generalized-label | | | | | | | +--rw direction? | | | | | | | te-label- direction Liu, et al Expires December 19, 2019 [Page 118] Internet-Draft YANG - TE Topology June 2019 | | | | | | +--:(srlg) | | | | | | +--rw srlg | | | | | | +--rw srlg? uint32 | | | | | +--rw explicit-route-include-objects | | | | | +--rw route-object-include-object* | | | | | [index] | | | | | +--rw index | | | | | | uint32 | | | | | +--rw (type)? | | | | | +--:(numbered-node-hop) | | | | | | +--rw numbered-node-hop | | | | | | +--rw node-id | | | | | | | te-node-id | | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--:(numbered-link-hop) | | | | | | +--rw numbered-link-hop | | | | | | +--rw link-tp-id | | | | | | | te-tp-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(unnumbered-link-hop) | | | | | | +--rw unnumbered-link-hop | | | | | | +--rw link-tp-id | | | | | | | te-tp-id | | | | | | +--rw node-id | | | | | | | te-node-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(as-number) | | | | | | +--rw as-number-hop | | | | | | +--rw as-number | | | | | | | inet:as-number | | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--:(label) | | | | | +--rw label-hop Liu, et al Expires December 19, 2019 [Page 119] Internet-Draft YANG - TE Topology June 2019 | | | | | +--rw te-label | | | | | +--rw (technology)? | | | | | | +--:(generic) | | | | | | +--rw generic? | | | | | | rt- types:generalized-label | | | | | +--rw direction? | | | | | te-label- direction | | | | +--rw tiebreakers | | | | +--rw tiebreaker* [tiebreaker-type] | | | | +--rw tiebreaker-type identityref | | | +--:(objective-function) | | | {path-optimization-objective- function}? | | | +--rw objective-function | | | +--rw objective-function-type? | | | identityref | | +--ro path-properties | | +--ro path-metric* [metric-type] | | | +--ro metric-type identityref | | | +--ro accumulative-value? uint64 | | +--ro path-affinities-values | | | +--ro path-affinities-value* [usage] | | | +--ro usage identityref | | | +--ro value? admin-groups | | +--ro path-affinity-names | | | +--ro path-affinity-name* [usage] | | | +--ro usage identityref | | | +--ro affinity-name* [name] | | | +--ro name string | | +--ro path-srlgs-lists | | | +--ro path-srlgs-list* [usage] | | | +--ro usage identityref | | | +--ro values* srlg | | +--ro path-srlgs-names | | | +--ro path-srlgs-name* [usage] | | | +--ro usage identityref | | | +--ro names* string | | +--ro path-route-objects | | +--ro path-route-object* [index] Liu, et al Expires December 19, 2019 [Page 120] Internet-Draft YANG - TE Topology June 2019 | | +--ro index uint32 | | +--ro (type)? | | +--:(numbered-node-hop) | | | +--ro numbered-node-hop | | | +--ro node-id te-node-id | | | +--ro hop-type? te-hop-type | | +--:(numbered-link-hop) | | | +--ro numbered-link-hop | | | +--ro link-tp-id te-tp-id | | | +--ro hop-type? te-hop-type | | | +--ro direction? | | | te-link-direction | | +--:(unnumbered-link-hop) | | | +--ro unnumbered-link-hop | | | +--ro link-tp-id te-tp-id | | | +--ro node-id te-node-id | | | +--ro hop-type? te-hop-type | | | +--ro direction? | | | te-link-direction | | +--:(as-number) | | | +--ro as-number-hop | | | +--ro as-number inet:as-number | | | +--ro hop-type? te-hop-type | | +--:(label) | | +--ro label-hop | | +--ro te-label | | +--ro (technology)? | | | +--:(generic) | | | +--ro generic? | | | rt- types:generalized-label | | +--ro direction? | | te-label-direction | +--rw domain-id? uint32 | +--rw is-abstract? empty | +--rw name? string | +--rw signaling-address* inet:ip-address | +--rw underlay-topology {te-topology-hierarchy}? | +--rw network-ref? -> /nw:networks/network/network-id +--ro oper-status? te-types:te-oper-status +--ro geolocation Liu, et al Expires December 19, 2019 [Page 121] Internet-Draft YANG - TE Topology June 2019 | +--ro altitude? int64 | +--ro latitude? geographic-coordinate-degree | +--ro longitude? geographic-coordinate-degree +--ro is-multi-access-dr? empty +--ro information-source? te-info-source +--ro information-source-instance? string +--ro information-source-state | +--ro credibility-preference? uint16 | +--ro logical-network-element? string | +--ro network-instance? string | +--ro topology | +--ro node-ref? leafref | +--ro network-ref? -> /nw:networks/network/network-id +--ro information-source-entry* | [information-source information-source-instance] | +--ro information-source te-info-source | +--ro information-source-instance string | +--ro information-source-state | | +--ro credibility-preference? uint16 | | +--ro logical-network-element? string | | +--ro network-instance? string | | +--ro topology | | +--ro node-ref? leafref | | +--ro network-ref? | | -> /nw:networks/network/network-id | +--ro connectivity-matrices | | +--ro number-of-entries? uint16 | | +--ro label-restrictions | | | +--ro label-restriction* [index] | | | +--ro restriction? enumeration | | | +--ro index uint32 | | | +--ro label-start | | | | +--ro te-label | | | | +--ro (technology)? | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized-label | | | | +--ro direction? te-label-direction | | | +--ro label-end | | | | +--ro te-label | | | | +--ro (technology)? Liu, et al Expires December 19, 2019 [Page 122] Internet-Draft YANG - TE Topology June 2019 | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized-label | | | | +--ro direction? te-label-direction | | | +--ro label-step | | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? int32 | | | +--ro range-bitmap? yang:hex-string | | +--ro is-allowed? boolean | | +--ro underlay {te-topology-hierarchy}? | | | +--ro enabled? boolean | | | +--ro primary-path | | | | +--ro network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--ro path-element* [path-element-id] | | | | +--ro path-element-id uint32 | | | | +--ro (type)? | | | | +--:(numbered-node-hop) | | | | | +--ro numbered-node-hop | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--ro numbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--ro unnumbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? te-link-direction | | | | +--:(as-number) | | | | | +--ro as-number-hop | | | | | +--ro as-number inet:as-number | | | | | +--ro hop-type? te-hop-type | | | | +--:(label) | | | | +--ro label-hop | | | | +--ro te-label | | | | +--ro (technology)? Liu, et al Expires December 19, 2019 [Page 123] Internet-Draft YANG - TE Topology June 2019 | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized- label | | | | +--ro direction? | | | | te-label-direction | | | +--ro backup-path* [index] | | | | +--ro index uint32 | | | | +--ro network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--ro path-element* [path-element-id] | | | | +--ro path-element-id uint32 | | | | +--ro (type)? | | | | +--:(numbered-node-hop) | | | | | +--ro numbered-node-hop | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--ro numbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--ro unnumbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? te-link-direction | | | | +--:(as-number) | | | | | +--ro as-number-hop | | | | | +--ro as-number inet:as-number | | | | | +--ro hop-type? te-hop-type | | | | +--:(label) | | | | +--ro label-hop | | | | +--ro te-label | | | | +--ro (technology)? | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized- label | | | | +--ro direction? Liu, et al Expires December 19, 2019 [Page 124] Internet-Draft YANG - TE Topology June 2019 | | | | te-label-direction | | | +--ro protection-type? identityref | | | +--ro tunnel-termination-points | | | | +--ro source? binary | | | | +--ro destination? binary | | | +--ro tunnels | | | +--ro sharing? boolean | | | +--ro tunnel* [tunnel-name] | | | +--ro tunnel-name string | | | +--ro sharing? boolean | | +--ro path-constraints | | | +--ro te-bandwidth | | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? te-bandwidth | | | +--ro link-protection? identityref | | | +--ro setup-priority? uint8 | | | +--ro hold-priority? uint8 | | | +--ro signaling-type? identityref | | | +--ro path-metric-bounds | | | | +--ro path-metric-bound* [metric-type] | | | | +--ro metric-type identityref | | | | +--ro upper-bound? uint64 | | | +--ro path-affinities-values | | | | +--ro path-affinities-value* [usage] | | | | +--ro usage identityref | | | | +--ro value? admin-groups | | | +--ro path-affinity-names | | | | +--ro path-affinity-name* [usage] | | | | +--ro usage identityref | | | | +--ro affinity-name* [name] | | | | +--ro name string | | | +--ro path-srlgs-lists | | | | +--ro path-srlgs-list* [usage] | | | | +--ro usage identityref | | | | +--ro values* srlg | | | +--ro path-srlgs-names | | | | +--ro path-srlgs-name* [usage] | | | | +--ro usage identityref | | | | +--ro names* string | | | +--ro disjointness? te-path-disjointness Liu, et al Expires December 19, 2019 [Page 125] Internet-Draft YANG - TE Topology June 2019 | | +--ro optimizations | | | +--ro (algorithm)? | | | +--:(metric) {path-optimization-metric}? | | | | +--ro optimization-metric* [metric-type] | | | | | +--ro metric-type | | | | | | identityref | | | | | +--ro weight? | | | | | | uint8 | | | | | +--ro explicit-route-exclude-objects | | | | | | +--ro route-object-exclude-object* | | | | | | [index] | | | | | | +--ro index | | | | | | | uint32 | | | | | | +--ro (type)? | | | | | | +--:(numbered-node-hop) | | | | | | | +--ro numbered-node-hop | | | | | | | +--ro node-id te-node-id | | | | | | | +--ro hop-type? te-hop-type | | | | | | +--:(numbered-link-hop) | | | | | | | +--ro numbered-link-hop | | | | | | | +--ro link-tp-id te-tp-id | | | | | | | +--ro hop-type? | | | | | | | | te-hop-type | | | | | | | +--ro direction? | | | | | | | te-link-direction | | | | | | +--:(unnumbered-link-hop) | | | | | | | +--ro unnumbered-link-hop | | | | | | | +--ro link-tp-id te-tp-id | | | | | | | +--ro node-id | | | | | | | | te-node-id | | | | | | | +--ro hop-type? | | | | | | | | te-hop-type | | | | | | | +--ro direction? | | | | | | | te-link-direction | | | | | | +--:(as-number) | | | | | | | +--ro as-number-hop | | | | | | | +--ro as-number | | | | | | | | inet:as-number | | | | | | | +--ro hop-type? | | | | | | | te-hop-type | | | | | | +--:(label) Liu, et al Expires December 19, 2019 [Page 126] Internet-Draft YANG - TE Topology June 2019 | | | | | | | +--ro label-hop | | | | | | | +--ro te-label | | | | | | | +--ro (technology)? | | | | | | | | +--:(generic) | | | | | | | | +--ro generic? | | | | | | | | rt- types:generalized-label | | | | | | | +--ro direction? | | | | | | | te-label-direction | | | | | | +--:(srlg) | | | | | | +--ro srlg | | | | | | +--ro srlg? uint32 | | | | | +--ro explicit-route-include-objects | | | | | +--ro route-object-include-object* | | | | | [index] | | | | | +--ro index | | | | | | uint32 | | | | | +--ro (type)? | | | | | +--:(numbered-node-hop) | | | | | | +--ro numbered-node-hop | | | | | | +--ro node-id te-node-id | | | | | | +--ro hop-type? te-hop-type | | | | | +--:(numbered-link-hop) | | | | | | +--ro numbered-link-hop | | | | | | +--ro link-tp-id te-tp-id | | | | | | +--ro hop-type? | | | | | | | te-hop-type | | | | | | +--ro direction? | | | | | | te-link-direction | | | | | +--:(unnumbered-link-hop) | | | | | | +--ro unnumbered-link-hop | | | | | | +--ro link-tp-id te-tp-id | | | | | | +--ro node-id | | | | | | | te-node-id | | | | | | +--ro hop-type? | | | | | | | te-hop-type | | | | | | +--ro direction? | | | | | | te-link-direction | | | | | +--:(as-number) | | | | | | +--ro as-number-hop | | | | | | +--ro as-number Liu, et al Expires December 19, 2019 [Page 127] Internet-Draft YANG - TE Topology June 2019 | | | | | | | inet:as-number | | | | | | +--ro hop-type? | | | | | | te-hop-type | | | | | +--:(label) | | | | | +--ro label-hop | | | | | +--ro te-label | | | | | +--ro (technology)? | | | | | | +--:(generic) | | | | | | +--ro generic? | | | | | | rt- types:generalized-label | | | | | +--ro direction? | | | | | te-label-direction | | | | +--ro tiebreakers | | | | +--ro tiebreaker* [tiebreaker-type] | | | | +--ro tiebreaker-type identityref | | | +--:(objective-function) | | | {path-optimization-objective-function}? | | | +--ro objective-function | | | +--ro objective-function-type? identityref | | +--ro path-properties | | | +--ro path-metric* [metric-type] | | | | +--ro metric-type identityref | | | | +--ro accumulative-value? uint64 | | | +--ro path-affinities-values | | | | +--ro path-affinities-value* [usage] | | | | +--ro usage identityref | | | | +--ro value? admin-groups | | | +--ro path-affinity-names | | | | +--ro path-affinity-name* [usage] | | | | +--ro usage identityref | | | | +--ro affinity-name* [name] | | | | +--ro name string | | | +--ro path-srlgs-lists | | | | +--ro path-srlgs-list* [usage] | | | | +--ro usage identityref | | | | +--ro values* srlg | | | +--ro path-srlgs-names | | | | +--ro path-srlgs-name* [usage] | | | | +--ro usage identityref | | | | +--ro names* string Liu, et al Expires December 19, 2019 [Page 128] Internet-Draft YANG - TE Topology June 2019 | | | +--ro path-route-objects | | | +--ro path-route-object* [index] | | | +--ro index uint32 | | | +--ro (type)? | | | +--:(numbered-node-hop) | | | | +--ro numbered-node-hop | | | | +--ro node-id te-node-id | | | | +--ro hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--ro numbered-link-hop | | | | +--ro link-tp-id te-tp-id | | | | +--ro hop-type? te-hop-type | | | | +--ro direction? te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--ro unnumbered-link-hop | | | | +--ro link-tp-id te-tp-id | | | | +--ro node-id te-node-id | | | | +--ro hop-type? te-hop-type | | | | +--ro direction? te-link-direction | | | +--:(as-number) | | | | +--ro as-number-hop | | | | +--ro as-number inet:as-number | | | | +--ro hop-type? te-hop-type | | | +--:(label) | | | +--ro label-hop | | | +--ro te-label | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? | | | | rt-types:generalized- label | | | +--ro direction? | | | te-label-direction | | +--ro connectivity-matrix* [id] | | +--ro id uint32 | | +--ro from | | | +--ro tp-ref? leafref | | | +--ro label-restrictions | | | +--ro label-restriction* [index] | | | +--ro restriction? enumeration | | | +--ro index uint32 Liu, et al Expires December 19, 2019 [Page 129] Internet-Draft YANG - TE Topology June 2019 | | | +--ro label-start | | | | +--ro te-label | | | | +--ro (technology)? | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized- label | | | | +--ro direction? | | | | te-label-direction | | | +--ro label-end | | | | +--ro te-label | | | | +--ro (technology)? | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized- label | | | | +--ro direction? | | | | te-label-direction | | | +--ro label-step | | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? int32 | | | +--ro range-bitmap? yang:hex-string | | +--ro to | | | +--ro tp-ref? leafref | | | +--ro label-restrictions | | | +--ro label-restriction* [index] | | | +--ro restriction? enumeration | | | +--ro index uint32 | | | +--ro label-start | | | | +--ro te-label | | | | +--ro (technology)? | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized- label | | | | +--ro direction? | | | | te-label-direction | | | +--ro label-end | | | | +--ro te-label | | | | +--ro (technology)? Liu, et al Expires December 19, 2019 [Page 130] Internet-Draft YANG - TE Topology June 2019 | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt-types:generalized- label | | | | +--ro direction? | | | | te-label-direction | | | +--ro label-step | | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? int32 | | | +--ro range-bitmap? yang:hex-string | | +--ro is-allowed? boolean | | +--ro underlay {te-topology-hierarchy}? | | | +--ro enabled? boolean | | | +--ro primary-path | | | | +--ro network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--ro path-element* [path-element-id] | | | | +--ro path-element-id uint32 | | | | +--ro (type)? | | | | +--:(numbered-node-hop) | | | | | +--ro numbered-node-hop | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--ro numbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? | | | | | te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--ro unnumbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? | | | | | te-link-direction | | | | +--:(as-number) | | | | | +--ro as-number-hop | | | | | +--ro as-number inet:as-number | | | | | +--ro hop-type? te-hop-type Liu, et al Expires December 19, 2019 [Page 131] Internet-Draft YANG - TE Topology June 2019 | | | | +--:(label) | | | | +--ro label-hop | | | | +--ro te-label | | | | +--ro (technology)? | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt- types:generalized-label | | | | +--ro direction? | | | | te-label-direction | | | +--ro backup-path* [index] | | | | +--ro index uint32 | | | | +--ro network-ref? | | | | | -> /nw:networks/network/network-id | | | | +--ro path-element* [path-element-id] | | | | +--ro path-element-id uint32 | | | | +--ro (type)? | | | | +--:(numbered-node-hop) | | | | | +--ro numbered-node-hop | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--ro numbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? | | | | | te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--ro unnumbered-link-hop | | | | | +--ro link-tp-id te-tp-id | | | | | +--ro node-id te-node-id | | | | | +--ro hop-type? te-hop-type | | | | | +--ro direction? | | | | | te-link-direction | | | | +--:(as-number) | | | | | +--ro as-number-hop | | | | | +--ro as-number inet:as-number | | | | | +--ro hop-type? te-hop-type | | | | +--:(label) | | | | +--ro label-hop | | | | +--ro te-label Liu, et al Expires December 19, 2019 [Page 132] Internet-Draft YANG - TE Topology June 2019 | | | | +--ro (technology)? | | | | | +--:(generic) | | | | | +--ro generic? | | | | | rt- types:generalized-label | | | | +--ro direction? | | | | te-label-direction | | | +--ro protection-type? identityref | | | +--ro tunnel-termination-points | | | | +--ro source? binary | | | | +--ro destination? binary | | | +--ro tunnels | | | +--ro sharing? boolean | | | +--ro tunnel* [tunnel-name] | | | +--ro tunnel-name string | | | +--ro sharing? boolean | | +--ro path-constraints | | | +--ro te-bandwidth | | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? te-bandwidth | | | +--ro link-protection? identityref | | | +--ro setup-priority? uint8 | | | +--ro hold-priority? uint8 | | | +--ro signaling-type? identityref | | | +--ro path-metric-bounds | | | | +--ro path-metric-bound* [metric-type] | | | | +--ro metric-type identityref | | | | +--ro upper-bound? uint64 | | | +--ro path-affinities-values | | | | +--ro path-affinities-value* [usage] | | | | +--ro usage identityref | | | | +--ro value? admin-groups | | | +--ro path-affinity-names | | | | +--ro path-affinity-name* [usage] | | | | +--ro usage identityref | | | | +--ro affinity-name* [name] | | | | +--ro name string | | | +--ro path-srlgs-lists | | | | +--ro path-srlgs-list* [usage] | | | | +--ro usage identityref Liu, et al Expires December 19, 2019 [Page 133] Internet-Draft YANG - TE Topology June 2019 | | | | +--ro values* srlg | | | +--ro path-srlgs-names | | | | +--ro path-srlgs-name* [usage] | | | | +--ro usage identityref | | | | +--ro names* string | | | +--ro disjointness? | | | te-path-disjointness | | +--ro optimizations | | | +--ro (algorithm)? | | | +--:(metric) {path-optimization-metric}? | | | | +--ro optimization-metric* [metric-type] | | | | | +--ro metric-type | | | | | | identityref | | | | | +--ro weight? | | | | | | uint8 | | | | | +--ro explicit-route-exclude-objects | | | | | | +--ro route-object-exclude-object* | | | | | | [index] | | | | | | +--ro index | | | | | | | uint32 | | | | | | +--ro (type)? | | | | | | +--:(numbered-node-hop) | | | | | | | +--ro numbered-node-hop | | | | | | | +--ro node-id | | | | | | | | te-node-id | | | | | | | +--ro hop-type? | | | | | | | te-hop-type | | | | | | +--:(numbered-link-hop) | | | | | | | +--ro numbered-link-hop | | | | | | | +--ro link-tp-id | | | | | | | | te-tp-id | | | | | | | +--ro hop-type? | | | | | | | | te-hop-type | | | | | | | +--ro direction? | | | | | | | te-link-direction | | | | | | +--:(unnumbered-link-hop) | | | | | | | +--ro unnumbered-link-hop | | | | | | | +--ro link-tp-id | | | | | | | | te-tp-id | | | | | | | +--ro node-id | | | | | | | | te-node-id Liu, et al Expires December 19, 2019 [Page 134] Internet-Draft YANG - TE Topology June 2019 | | | | | | | +--ro hop-type? | | | | | | | | te-hop-type | | | | | | | +--ro direction? | | | | | | | te-link-direction | | | | | | +--:(as-number) | | | | | | | +--ro as-number-hop | | | | | | | +--ro as-number | | | | | | | | inet:as-number | | | | | | | +--ro hop-type? | | | | | | | te-hop-type | | | | | | +--:(label) | | | | | | | +--ro label-hop | | | | | | | +--ro te-label | | | | | | | +--ro (technology)? | | | | | | | | +--:(generic) | | | | | | | | +--ro generic? | | | | | | | | rt- types:generalized-label | | | | | | | +--ro direction? | | | | | | | te-label- direction | | | | | | +--:(srlg) | | | | | | +--ro srlg | | | | | | +--ro srlg? uint32 | | | | | +--ro explicit-route-include-objects | | | | | +--ro route-object-include-object* | | | | | [index] | | | | | +--ro index | | | | | | uint32 | | | | | +--ro (type)? | | | | | +--:(numbered-node-hop) | | | | | | +--ro numbered-node-hop | | | | | | +--ro node-id | | | | | | | te-node-id | | | | | | +--ro hop-type? | | | | | | te-hop-type | | | | | +--:(numbered-link-hop) | | | | | | +--ro numbered-link-hop | | | | | | +--ro link-tp-id | | | | | | | te-tp-id | | | | | | +--ro hop-type? Liu, et al Expires December 19, 2019 [Page 135] Internet-Draft YANG - TE Topology June 2019 | | | | | | | te-hop-type | | | | | | +--ro direction? | | | | | | te-link-direction | | | | | +--:(unnumbered-link-hop) | | | | | | +--ro unnumbered-link-hop | | | | | | +--ro link-tp-id | | | | | | | te-tp-id | | | | | | +--ro node-id | | | | | | | te-node-id | | | | | | +--ro hop-type? | | | | | | | te-hop-type | | | | | | +--ro direction? | | | | | | te-link-direction | | | | | +--:(as-number) | | | | | | +--ro as-number-hop | | | | | | +--ro as-number | | | | | | | inet:as-number | | | | | | +--ro hop-type? | | | | | | te-hop-type | | | | | +--:(label) | | | | | +--ro label-hop | | | | | +--ro te-label | | | | | +--ro (technology)? | | | | | | +--:(generic) | | | | | | +--ro generic? | | | | | | rt- types:generalized-label | | | | | +--ro direction? | | | | | te-label- direction | | | | +--ro tiebreakers | | | | +--ro tiebreaker* [tiebreaker-type] | | | | +--ro tiebreaker-type identityref | | | +--:(objective-function) | | | {path-optimization-objective- function}? | | | +--ro objective-function | | | +--ro objective-function-type? | | | identityref | | +--ro path-properties | | +--ro path-metric* [metric-type] Liu, et al Expires December 19, 2019 [Page 136] Internet-Draft YANG - TE Topology June 2019 | | | +--ro metric-type identityref | | | +--ro accumulative-value? uint64 | | +--ro path-affinities-values | | | +--ro path-affinities-value* [usage] | | | +--ro usage identityref | | | +--ro value? admin-groups | | +--ro path-affinity-names | | | +--ro path-affinity-name* [usage] | | | +--ro usage identityref | | | +--ro affinity-name* [name] | | | +--ro name string | | +--ro path-srlgs-lists | | | +--ro path-srlgs-list* [usage] | | | +--ro usage identityref | | | +--ro values* srlg | | +--ro path-srlgs-names | | | +--ro path-srlgs-name* [usage] | | | +--ro usage identityref | | | +--ro names* string | | +--ro path-route-objects | | +--ro path-route-object* [index] | | +--ro index uint32 | | +--ro (type)? | | +--:(numbered-node-hop) | | | +--ro numbered-node-hop | | | +--ro node-id te-node-id | | | +--ro hop-type? te-hop-type | | +--:(numbered-link-hop) | | | +--ro numbered-link-hop | | | +--ro link-tp-id te-tp-id | | | +--ro hop-type? te-hop-type | | | +--ro direction? | | | te-link-direction | | +--:(unnumbered-link-hop) | | | +--ro unnumbered-link-hop | | | +--ro link-tp-id te-tp-id | | | +--ro node-id te-node-id | | | +--ro hop-type? te-hop-type | | | +--ro direction? | | | te-link-direction | | +--:(as-number) Liu, et al Expires December 19, 2019 [Page 137] Internet-Draft YANG - TE Topology June 2019 | | | +--ro as-number-hop | | | +--ro as-number inet:as-number | | | +--ro hop-type? te-hop-type | | +--:(label) | | +--ro label-hop | | +--ro te-label | | +--ro (technology)? | | | +--:(generic) | | | +--ro generic? | | | rt- types:generalized-label | | +--ro direction? | | te-label-direction | +--ro domain-id? uint32 | +--ro is-abstract? empty | +--ro name? string | +--ro signaling-address* inet:ip-address | +--ro underlay-topology {te-topology-hierarchy}? | +--ro network-ref? -> /nw:networks/network/network-id +--ro statistics | +--ro discontinuity-time? yang:date-and-time | +--ro node | | +--ro disables? yang:counter32 | | +--ro enables? yang:counter32 | | +--ro maintenance-sets? yang:counter32 | | +--ro maintenance-clears? yang:counter32 | | +--ro modifies? yang:counter32 | +--ro connectivity-matrix-entry | +--ro creates? yang:counter32 | +--ro deletes? yang:counter32 | +--ro disables? yang:counter32 | +--ro enables? yang:counter32 | +--ro modifies? yang:counter32 +--rw tunnel-termination-point* [tunnel-tp-id] +--rw tunnel-tp-id binary +--rw admin-status? | te-types:te-admin-status +--rw name? string +--rw switching-capability? identityref +--rw encoding? identityref +--rw inter-layer-lock-id* uint32 Liu, et al Expires December 19, 2019 [Page 138] Internet-Draft YANG - TE Topology June 2019 +--rw protection-type? identityref +--rw client-layer-adaptation | +--rw switching-capability* | [switching-capability encoding] | +--rw switching-capability identityref | +--rw encoding identityref | +--rw te-bandwidth | +--rw (technology)? | +--:(generic) | +--rw generic? te-bandwidth +--rw local-link-connectivities | +--rw number-of-entries? uint16 | +--rw label-restrictions | | +--rw label-restriction* [index] | | +--rw restriction? enumeration | | +--rw index uint32 | | +--rw label-start | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized-label | | | +--rw direction? te-label-direction | | +--rw label-end | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized-label | | | +--rw direction? te-label-direction | | +--rw label-step | | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? int32 | | +--rw range-bitmap? yang:hex-string | +--rw is-allowed? boolean | +--rw underlay {te-topology-hierarchy}? | | +--rw enabled? boolean | | +--rw primary-path | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id Liu, et al Expires December 19, 2019 [Page 139] Internet-Draft YANG - TE Topology June 2019 | | | +--rw path-element* [path-element-id] | | | +--rw path-element-id uint32 | | | +--rw (type)? | | | +--:(numbered-node-hop) | | | | +--rw numbered-node-hop | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--rw numbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--rw unnumbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(as-number) | | | | +--rw as-number-hop | | | | +--rw as-number inet:as-number | | | | +--rw hop-type? te-hop-type | | | +--:(label) | | | +--rw label-hop | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized- label | | | +--rw direction? | | | te-label-direction | | +--rw backup-path* [index] | | | +--rw index uint32 | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id | | | +--rw path-element* [path-element-id] | | | +--rw path-element-id uint32 | | | +--rw (type)? | | | +--:(numbered-node-hop) | | | | +--rw numbered-node-hop Liu, et al Expires December 19, 2019 [Page 140] Internet-Draft YANG - TE Topology June 2019 | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--rw numbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--rw unnumbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(as-number) | | | | +--rw as-number-hop | | | | +--rw as-number inet:as-number | | | | +--rw hop-type? te-hop-type | | | +--:(label) | | | +--rw label-hop | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized- label | | | +--rw direction? | | | te-label-direction | | +--rw protection-type? identityref | | +--rw tunnel-termination-points | | | +--rw source? binary | | | +--rw destination? binary | | +--rw tunnels | | +--rw sharing? boolean | | +--rw tunnel* [tunnel-name] | | +--rw tunnel-name string | | +--rw sharing? boolean | +--rw path-constraints | | +--rw te-bandwidth | | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? te-bandwidth Liu, et al Expires December 19, 2019 [Page 141] Internet-Draft YANG - TE Topology June 2019 | | +--rw link-protection? identityref | | +--rw setup-priority? uint8 | | +--rw hold-priority? uint8 | | +--rw signaling-type? identityref | | +--rw path-metric-bounds | | | +--rw path-metric-bound* [metric-type] | | | +--rw metric-type identityref | | | +--rw upper-bound? uint64 | | +--rw path-affinities-values | | | +--rw path-affinities-value* [usage] | | | +--rw usage identityref | | | +--rw value? admin-groups | | +--rw path-affinity-names | | | +--rw path-affinity-name* [usage] | | | +--rw usage identityref | | | +--rw affinity-name* [name] | | | +--rw name string | | +--rw path-srlgs-lists | | | +--rw path-srlgs-list* [usage] | | | +--rw usage identityref | | | +--rw values* srlg | | +--rw path-srlgs-names | | | +--rw path-srlgs-name* [usage] | | | +--rw usage identityref | | | +--rw names* string | | +--rw disjointness? te-path-disjointness | +--rw optimizations | | +--rw (algorithm)? | | +--:(metric) {path-optimization-metric}? | | | +--rw optimization-metric* [metric-type] | | | | +--rw metric-type | | | | | identityref | | | | +--rw weight? | | | | | uint8 | | | | +--rw explicit-route-exclude-objects | | | | | +--rw route-object-exclude-object* | | | | | [index] | | | | | +--rw index | | | | | | uint32 | | | | | +--rw (type)? | | | | | +--:(numbered-node-hop) Liu, et al Expires December 19, 2019 [Page 142] Internet-Draft YANG - TE Topology June 2019 | | | | | | +--rw numbered-node-hop | | | | | | +--rw node-id te-node-id | | | | | | +--rw hop-type? te-hop-type | | | | | +--:(numbered-link-hop) | | | | | | +--rw numbered-link-hop | | | | | | +--rw link-tp-id te-tp-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(unnumbered-link-hop) | | | | | | +--rw unnumbered-link-hop | | | | | | +--rw link-tp-id te-tp-id | | | | | | +--rw node-id | | | | | | | te-node-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(as-number) | | | | | | +--rw as-number-hop | | | | | | +--rw as-number | | | | | | | inet:as-number | | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--:(label) | | | | | | +--rw label-hop | | | | | | +--rw te-label | | | | | | +--rw (technology)? | | | | | | | +--:(generic) | | | | | | | +--rw generic? | | | | | | | rt- types:generalized-label | | | | | | +--rw direction? | | | | | | te-label-direction | | | | | +--:(srlg) | | | | | +--rw srlg | | | | | +--rw srlg? uint32 | | | | +--rw explicit-route-include-objects | | | | +--rw route-object-include-object* | | | | [index] Liu, et al Expires December 19, 2019 [Page 143] Internet-Draft YANG - TE Topology June 2019 | | | | +--rw index | | | | | uint32 | | | | +--rw (type)? | | | | +--:(numbered-node-hop) | | | | | +--rw numbered-node-hop | | | | | +--rw node-id te-node-id | | | | | +--rw hop-type? te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--rw numbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--rw unnumbered-link-hop | | | | | +--rw link-tp-id te-tp-id | | | | | +--rw node-id | | | | | | te-node-id | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(as-number) | | | | | +--rw as-number-hop | | | | | +--rw as-number | | | | | | inet:as-number | | | | | +--rw hop-type? | | | | | te-hop-type | | | | +--:(label) | | | | +--rw label-hop | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt- types:generalized-label | | | | +--rw direction? | | | | te-label-direction | | | +--rw tiebreakers | | | +--rw tiebreaker* [tiebreaker-type] Liu, et al Expires December 19, 2019 [Page 144] Internet-Draft YANG - TE Topology June 2019 | | | +--rw tiebreaker-type identityref | | +--:(objective-function) | | {path-optimization-objective-function}? | | +--rw objective-function | | +--rw objective-function-type? identityref | +--ro path-properties | | +--ro path-metric* [metric-type] | | | +--ro metric-type identityref | | | +--ro accumulative-value? uint64 | | +--ro path-affinities-values | | | +--ro path-affinities-value* [usage] | | | +--ro usage identityref | | | +--ro value? admin-groups | | +--ro path-affinity-names | | | +--ro path-affinity-name* [usage] | | | +--ro usage identityref | | | +--ro affinity-name* [name] | | | +--ro name string | | +--ro path-srlgs-lists | | | +--ro path-srlgs-list* [usage] | | | +--ro usage identityref | | | +--ro values* srlg | | +--ro path-srlgs-names | | | +--ro path-srlgs-name* [usage] | | | +--ro usage identityref | | | +--ro names* string | | +--ro path-route-objects | | +--ro path-route-object* [index] | | +--ro index uint32 | | +--ro (type)? | | +--:(numbered-node-hop) | | | +--ro numbered-node-hop | | | +--ro node-id te-node-id | | | +--ro hop-type? te-hop-type | | +--:(numbered-link-hop) | | | +--ro numbered-link-hop | | | +--ro link-tp-id te-tp-id | | | +--ro hop-type? te-hop-type | | | +--ro direction? te-link-direction | | +--:(unnumbered-link-hop) | | | +--ro unnumbered-link-hop Liu, et al Expires December 19, 2019 [Page 145] Internet-Draft YANG - TE Topology June 2019 | | | +--ro link-tp-id te-tp-id | | | +--ro node-id te-node-id | | | +--ro hop-type? te-hop-type | | | +--ro direction? te-link-direction | | +--:(as-number) | | | +--ro as-number-hop | | | +--ro as-number inet:as-number | | | +--ro hop-type? te-hop-type | | +--:(label) | | +--ro label-hop | | +--ro te-label | | +--ro (technology)? | | | +--:(generic) | | | +--ro generic? | | | rt-types:generalized- label | | +--ro direction? | | te-label-direction | +--rw local-link-connectivity* [link-tp-ref] | +--rw link-tp-ref | | -> ../../../../../nt:termination-point/tp-id | +--rw label-restrictions | | +--rw label-restriction* [index] | | +--rw restriction? enumeration | | +--rw index uint32 | | +--rw label-start | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized-label | | | +--rw direction? te-label-direction | | +--rw label-end | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized-label | | | +--rw direction? te-label-direction | | +--rw label-step | | | +--rw (technology)? Liu, et al Expires December 19, 2019 [Page 146] Internet-Draft YANG - TE Topology June 2019 | | | +--:(generic) | | | +--rw generic? int32 | | +--rw range-bitmap? yang:hex-string | +--rw is-allowed? boolean | +--rw underlay {te-topology-hierarchy}? | | +--rw enabled? boolean | | +--rw primary-path | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id | | | +--rw path-element* [path-element-id] | | | +--rw path-element-id uint32 | | | +--rw (type)? | | | +--:(numbered-node-hop) | | | | +--rw numbered-node-hop | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--rw numbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? | | | | te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--rw unnumbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? | | | | te-link-direction | | | +--:(as-number) | | | | +--rw as-number-hop | | | | +--rw as-number inet:as-number | | | | +--rw hop-type? te-hop-type | | | +--:(label) | | | +--rw label-hop | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt- types:generalized-label Liu, et al Expires December 19, 2019 [Page 147] Internet-Draft YANG - TE Topology June 2019 | | | +--rw direction? | | | te-label-direction | | +--rw backup-path* [index] | | | +--rw index uint32 | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id | | | +--rw path-element* [path-element-id] | | | +--rw path-element-id uint32 | | | +--rw (type)? | | | +--:(numbered-node-hop) | | | | +--rw numbered-node-hop | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--rw numbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? | | | | te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--rw unnumbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? | | | | te-link-direction | | | +--:(as-number) | | | | +--rw as-number-hop | | | | +--rw as-number inet:as-number | | | | +--rw hop-type? te-hop-type | | | +--:(label) | | | +--rw label-hop | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt- types:generalized-label | | | +--rw direction? | | | te-label-direction | | +--rw protection-type? identityref Liu, et al Expires December 19, 2019 [Page 148] Internet-Draft YANG - TE Topology June 2019 | | +--rw tunnel-termination-points | | | +--rw source? binary | | | +--rw destination? binary | | +--rw tunnels | | +--rw sharing? boolean | | +--rw tunnel* [tunnel-name] | | +--rw tunnel-name string | | +--rw sharing? boolean | +--rw path-constraints | | +--rw te-bandwidth | | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? te-bandwidth | | +--rw link-protection? identityref | | +--rw setup-priority? uint8 | | +--rw hold-priority? uint8 | | +--rw signaling-type? identityref | | +--rw path-metric-bounds | | | +--rw path-metric-bound* [metric-type] | | | +--rw metric-type identityref | | | +--rw upper-bound? uint64 | | +--rw path-affinities-values | | | +--rw path-affinities-value* [usage] | | | +--rw usage identityref | | | +--rw value? admin-groups | | +--rw path-affinity-names | | | +--rw path-affinity-name* [usage] | | | +--rw usage identityref | | | +--rw affinity-name* [name] | | | +--rw name string | | +--rw path-srlgs-lists | | | +--rw path-srlgs-list* [usage] | | | +--rw usage identityref | | | +--rw values* srlg | | +--rw path-srlgs-names | | | +--rw path-srlgs-name* [usage] | | | +--rw usage identityref | | | +--rw names* string | | +--rw disjointness? | | te-path-disjointness | +--rw optimizations Liu, et al Expires December 19, 2019 [Page 149] Internet-Draft YANG - TE Topology June 2019 | | +--rw (algorithm)? | | +--:(metric) {path-optimization-metric}? | | | +--rw optimization-metric* [metric-type] | | | | +--rw metric-type | | | | | identityref | | | | +--rw weight? | | | | | uint8 | | | | +--rw explicit-route-exclude-objects | | | | | +--rw route-object-exclude-object* | | | | | [index] | | | | | +--rw index | | | | | | uint32 | | | | | +--rw (type)? | | | | | +--:(numbered-node-hop) | | | | | | +--rw numbered-node-hop | | | | | | +--rw node-id | | | | | | | te-node-id | | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--:(numbered-link-hop) | | | | | | +--rw numbered-link-hop | | | | | | +--rw link-tp-id | | | | | | | te-tp-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(unnumbered-link-hop) | | | | | | +--rw unnumbered-link-hop | | | | | | +--rw link-tp-id | | | | | | | te-tp-id | | | | | | +--rw node-id | | | | | | | te-node-id | | | | | | +--rw hop-type? | | | | | | | te-hop-type | | | | | | +--rw direction? | | | | | | te-link-direction | | | | | +--:(as-number) | | | | | | +--rw as-number-hop | | | | | | +--rw as-number | | | | | | | inet:as-number Liu, et al Expires December 19, 2019 [Page 150] Internet-Draft YANG - TE Topology June 2019 | | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--:(label) | | | | | | +--rw label-hop | | | | | | +--rw te-label | | | | | | +--rw (technology)? | | | | | | | +--:(generic) | | | | | | | +--rw generic? | | | | | | | rt- types:generalized-label | | | | | | +--rw direction? | | | | | | te-label- direction | | | | | +--:(srlg) | | | | | +--rw srlg | | | | | +--rw srlg? uint32 | | | | +--rw explicit-route-include-objects | | | | +--rw route-object-include-object* | | | | [index] | | | | +--rw index | | | | | uint32 | | | | +--rw (type)? | | | | +--:(numbered-node-hop) | | | | | +--rw numbered-node-hop | | | | | +--rw node-id | | | | | | te-node-id | | | | | +--rw hop-type? | | | | | te-hop-type | | | | +--:(numbered-link-hop) | | | | | +--rw numbered-link-hop | | | | | +--rw link-tp-id | | | | | | te-tp-id | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(unnumbered-link-hop) | | | | | +--rw unnumbered-link-hop | | | | | +--rw link-tp-id | | | | | | te-tp-id | | | | | +--rw node-id Liu, et al Expires December 19, 2019 [Page 151] Internet-Draft YANG - TE Topology June 2019 | | | | | | te-node-id | | | | | +--rw hop-type? | | | | | | te-hop-type | | | | | +--rw direction? | | | | | te-link-direction | | | | +--:(as-number) | | | | | +--rw as-number-hop | | | | | +--rw as-number | | | | | | inet:as-number | | | | | +--rw hop-type? | | | | | te-hop-type | | | | +--:(label) | | | | +--rw label-hop | | | | +--rw te-label | | | | +--rw (technology)? | | | | | +--:(generic) | | | | | +--rw generic? | | | | | rt- types:generalized-label | | | | +--rw direction? | | | | te-label- direction | | | +--rw tiebreakers | | | +--rw tiebreaker* [tiebreaker-type] | | | +--rw tiebreaker-type identityref | | +--:(objective-function) | | {path-optimization-objective- function}? | | +--rw objective-function | | +--rw objective-function-type? | | identityref | +--ro path-properties | +--ro path-metric* [metric-type] | | +--ro metric-type identityref | | +--ro accumulative-value? uint64 | +--ro path-affinities-values | | +--ro path-affinities-value* [usage] | | +--ro usage identityref | | +--ro value? admin-groups | +--ro path-affinity-names | | +--ro path-affinity-name* [usage] Liu, et al Expires December 19, 2019 [Page 152] Internet-Draft YANG - TE Topology June 2019 | | +--ro usage identityref | | +--ro affinity-name* [name] | | +--ro name string | +--ro path-srlgs-lists | | +--ro path-srlgs-list* [usage] | | +--ro usage identityref | | +--ro values* srlg | +--ro path-srlgs-names | | +--ro path-srlgs-name* [usage] | | +--ro usage identityref | | +--ro names* string | +--ro path-route-objects | +--ro path-route-object* [index] | +--ro index uint32 | +--ro (type)? | +--:(numbered-node-hop) | | +--ro numbered-node-hop | | +--ro node-id te-node-id | | +--ro hop-type? te-hop-type | +--:(numbered-link-hop) | | +--ro numbered-link-hop | | +--ro link-tp-id te-tp-id | | +--ro hop-type? te-hop-type | | +--ro direction? | | te-link-direction | +--:(unnumbered-link-hop) | | +--ro unnumbered-link-hop | | +--ro link-tp-id te-tp-id | | +--ro node-id te-node-id | | +--ro hop-type? te-hop-type | | +--ro direction? | | te-link-direction | +--:(as-number) | | +--ro as-number-hop | | +--ro as-number inet:as-number | | +--ro hop-type? te-hop-type | +--:(label) | +--ro label-hop | +--ro te-label | +--ro (technology)? | | +--:(generic) Liu, et al Expires December 19, 2019 [Page 153] Internet-Draft YANG - TE Topology June 2019 | | +--ro generic? | | rt- types:generalized-label | +--ro direction? | te-label-direction +--ro oper-status? | te-types:te-oper-status +--ro geolocation | +--ro altitude? int64 | +--ro latitude? geographic-coordinate-degree | +--ro longitude? geographic-coordinate-degree +--ro statistics | +--ro discontinuity-time? yang:date-and-time | +--ro tunnel-termination-point | | +--ro disables? yang:counter32 | | +--ro enables? yang:counter32 | | +--ro maintenance-clears? yang:counter32 | | +--ro maintenance-sets? yang:counter32 | | +--ro modifies? yang:counter32 | | +--ro downs? yang:counter32 | | +--ro ups? yang:counter32 | | +--ro in-service-clears? yang:counter32 | | +--ro in-service-sets? yang:counter32 | +--ro local-link-connectivity | +--ro creates? yang:counter32 | +--ro deletes? yang:counter32 | +--ro disables? yang:counter32 | +--ro enables? yang:counter32 | +--ro modifies? yang:counter32 +--rw supporting-tunnel-termination-point* [node-ref tunnel-tp-ref] +--rw node-ref inet:uri +--rw tunnel-tp-ref binary augment /nw:networks/nw:network/nt:link: +--rw te! +--rw (bundle-stack-level)? | +--:(bundle) | | +--rw bundled-links | | +--rw bundled-link* [sequence] | | +--rw sequence uint32 | | +--rw src-tp-ref? leafref Liu, et al Expires December 19, 2019 [Page 154] Internet-Draft YANG - TE Topology June 2019 | | +--rw des-tp-ref? leafref | +--:(component) | +--rw component-links | +--rw component-link* [sequence] | +--rw sequence uint32 | +--rw src-interface-ref? string | +--rw des-interface-ref? string +--rw te-link-template* | -> ../../../../te/templates/link-template/name | {template}? +--rw te-link-attributes | +--rw access-type? | | te-types:te-link-access-type | +--rw external-domain | | +--rw network-ref? | | | -> /nw:networks/network/network-id | | +--rw remote-te-node-id? te-types:te-node-id | | +--rw remote-te-link-tp-id? te-types:te-tp-id | +--rw is-abstract? empty | +--rw name? string | +--rw underlay {te-topology-hierarchy}? | | +--rw enabled? boolean | | +--rw primary-path | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id | | | +--rw path-element* [path-element-id] | | | +--rw path-element-id uint32 | | | +--rw (type)? | | | +--:(numbered-node-hop) | | | | +--rw numbered-node-hop | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--rw numbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--rw unnumbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw node-id te-node-id Liu, et al Expires December 19, 2019 [Page 155] Internet-Draft YANG - TE Topology June 2019 | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(as-number) | | | | +--rw as-number-hop | | | | +--rw as-number inet:as-number | | | | +--rw hop-type? te-hop-type | | | +--:(label) | | | +--rw label-hop | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized- label | | | +--rw direction? | | | te-label-direction | | +--rw backup-path* [index] | | | +--rw index uint32 | | | +--rw network-ref? | | | | -> /nw:networks/network/network-id | | | +--rw path-element* [path-element-id] | | | +--rw path-element-id uint32 | | | +--rw (type)? | | | +--:(numbered-node-hop) | | | | +--rw numbered-node-hop | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | +--:(numbered-link-hop) | | | | +--rw numbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(unnumbered-link-hop) | | | | +--rw unnumbered-link-hop | | | | +--rw link-tp-id te-tp-id | | | | +--rw node-id te-node-id | | | | +--rw hop-type? te-hop-type | | | | +--rw direction? te-link-direction | | | +--:(as-number) | | | | +--rw as-number-hop | | | | +--rw as-number inet:as-number Liu, et al Expires December 19, 2019 [Page 156] Internet-Draft YANG - TE Topology June 2019 | | | | +--rw hop-type? te-hop-type | | | +--:(label) | | | +--rw label-hop | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized- label | | | +--rw direction? | | | te-label-direction | | +--rw protection-type? identityref | | +--rw tunnel-termination-points | | | +--rw source? binary | | | +--rw destination? binary | | +--rw tunnels | | +--rw sharing? boolean | | +--rw tunnel* [tunnel-name] | | +--rw tunnel-name string | | +--rw sharing? boolean | +--rw admin-status? | | te-types:te-admin-status | +--rw link-index? uint64 | +--rw administrative-group? | | te-types:admin-groups | +--rw interface-switching-capability* | | [switching-capability encoding] | | +--rw switching-capability identityref | | +--rw encoding identityref | | +--rw max-lsp-bandwidth* [priority] | | +--rw priority uint8 | | +--rw te-bandwidth | | +--rw (technology)? | | +--:(generic) | | +--rw generic? te-bandwidth | +--rw label-restrictions | | +--rw label-restriction* [index] | | +--rw restriction? enumeration | | +--rw index uint32 | | +--rw label-start | | | +--rw te-label Liu, et al Expires December 19, 2019 [Page 157] Internet-Draft YANG - TE Topology June 2019 | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized-label | | | +--rw direction? te-label-direction | | +--rw label-end | | | +--rw te-label | | | +--rw (technology)? | | | | +--:(generic) | | | | +--rw generic? | | | | rt-types:generalized-label | | | +--rw direction? te-label-direction | | +--rw label-step | | | +--rw (technology)? | | | +--:(generic) | | | +--rw generic? int32 | | +--rw range-bitmap? yang:hex-string | +--rw link-protection-type? identityref | +--rw max-link-bandwidth | | +--rw te-bandwidth | | +--rw (technology)? | | +--:(generic) | | +--rw generic? te-bandwidth | +--rw max-resv-link-bandwidth | | +--rw te-bandwidth | | +--rw (technology)? | | +--:(generic) | | +--rw generic? te-bandwidth | +--rw unreserved-bandwidth* [priority] | | +--rw priority uint8 | | +--rw te-bandwidth | | +--rw (technology)? | | +--:(generic) | | +--rw generic? te-bandwidth | +--rw te-default-metric? uint32 | +--rw te-delay-metric? uint32 | +--rw te-igp-metric? uint32 | +--rw te-srlgs | | +--rw value* te-types:srlg | +--rw te-nsrlgs {nsrlg}? | +--rw id* uint32 Liu, et al Expires December 19, 2019 [Page 158] Internet-Draft YANG - TE Topology June 2019 +--ro oper-status? te-types:te-oper-status +--ro is-transitional? empty +--ro information-source? te-info-source +--ro information-source-instance? string +--ro information-source-state | +--ro credibility-preference? uint16 | +--ro logical-network-element? string | +--ro network-instance? string | +--ro topology | +--ro link-ref? leafref | +--ro network-ref? -> /nw:networks/network/network-id +--ro information-source-entry* | [information-source information-source-instance] | +--ro information-source te-info-source | +--ro information-source-instance string | +--ro information-source-state | | +--ro credibility-preference? uint16 | | +--ro logical-network-element? string | | +--ro network-instance? string | | +--ro topology | | +--ro link-ref? leafref | | +--ro network-ref? | | -> /nw:networks/network/network-id | +--ro link-index? uint64 | +--ro administrative-group? | | te-types:admin-groups | +--ro interface-switching-capability* | | [switching-capability encoding] | | +--ro switching-capability identityref | | +--ro encoding identityref | | +--ro max-lsp-bandwidth* [priority] | | +--ro priority uint8 | | +--ro te-bandwidth | | +--ro (technology)? | | +--:(generic) | | +--ro generic? te-bandwidth | +--ro label-restrictions | | +--ro label-restriction* [index] | | +--ro restriction? enumeration | | +--ro index uint32 | | +--ro label-start Liu, et al Expires December 19, 2019 [Page 159] Internet-Draft YANG - TE Topology June 2019 | | | +--ro te-label | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? | | | | rt-types:generalized-label | | | +--ro direction? te-label-direction | | +--ro label-end | | | +--ro te-label | | | +--ro (technology)? | | | | +--:(generic) | | | | +--ro generic? | | | | rt-types:generalized-label | | | +--ro direction? te-label-direction | | +--ro label-step | | | +--ro (technology)? | | | +--:(generic) | | | +--ro generic? int32 | | +--ro range-bitmap? yang:hex-string | +--ro link-protection-type? identityref | +--ro max-link-bandwidth | | +--ro te-bandwidth | | +--ro (technology)? | | +--:(generic) | | +--ro generic? te-bandwidth | +--ro max-resv-link-bandwidth | | +--ro te-bandwidth | | +--ro (technology)? | | +--:(generic) | | +--ro generic? te-bandwidth | +--ro unreserved-bandwidth* [priority] | | +--ro priority uint8 | | +--ro te-bandwidth | | +--ro (technology)? | | +--:(generic) | | +--ro generic? te-bandwidth | +--ro te-default-metric? uint32 | +--ro te-delay-metric? uint32 | +--ro te-igp-metric? uint32 | +--ro te-srlgs | | +--ro value* te-types:srlg | +--ro te-nsrlgs {nsrlg}? Liu, et al Expires December 19, 2019 [Page 160] Internet-Draft YANG - TE Topology June 2019 | +--ro id* uint32 +--ro recovery | +--ro restoration-status? te-types:te-recovery-status | +--ro protection-status? te-types:te-recovery-status +--ro underlay {te-topology-hierarchy}? | +--ro dynamic? boolean | +--ro committed? boolean +--ro statistics +--ro discontinuity-time? yang:date-and-time +--ro disables? yang:counter32 +--ro enables? yang:counter32 +--ro maintenance-clears? yang:counter32 +--ro maintenance-sets? yang:counter32 +--ro modifies? yang:counter32 +--ro downs? yang:counter32 +--ro ups? yang:counter32 +--ro fault-clears? yang:counter32 +--ro fault-detects? yang:counter32 +--ro protection-switches? yang:counter32 +--ro protection-reverts? yang:counter32 +--ro restoration-failures? yang:counter32 +--ro restoration-starts? yang:counter32 +--ro restoration-successes? yang:counter32 +--ro restoration-reversion-failures? yang:counter32 +--ro restoration-reversion-starts? yang:counter32 +--ro restoration-reversion-successes? yang:counter32 augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te-tp-id? te-types:te-tp-id +--rw te! +--rw admin-status? | te-types:te-admin-status +--rw name? string +--rw interface-switching-capability* | [switching-capability encoding] | +--rw switching-capability identityref | +--rw encoding identityref | +--rw max-lsp-bandwidth* [priority] | +--rw priority uint8 | +--rw te-bandwidth | +--rw (technology)? | +--:(generic) Liu, et al Expires December 19, 2019 [Page 161] Internet-Draft YANG - TE Topology June 2019 | +--rw generic? te-bandwidth +--rw inter-domain-plug-id? binary +--rw inter-layer-lock-id* uint32 +--ro oper-status? | te-types:te-oper-status +--ro geolocation +--ro altitude? int64 +--ro latitude? geographic-coordinate-degree +--ro longitude? geographic-coordinate-degree Liu, et al Expires December 19, 2019 [Page 162] Internet-Draft YANG - TE Topology June 2019 Appendix B. Companion YANG Model for Non-NMDA Compliant Implementations The YANG module ietf-te-topology defined in this document is designed to be used in conjunction with implementations that support the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. In order to allow implementations to use the model even in cases when NMDA is not supported, the following companion module ietf-te-topology-state is defined as a state model, which mirrors the module ietf-te-topology defined earlier in this document. However, all data nodes in the companion module are non-configurable, to represent the applied configuration or the derived operational states. The companion module, ietf-te-topology-state, is redundant and SHOULD NOT be supported by implementations that support NMDA. As the structure of the module ietf-te-topology-state mirrors that of the module ietf-te-topology. The YANG tree of the module ietf-te- topology-state is not depicted separately. B.1. TE Topology State YANG Module This module references [RFC6001], [RFC8345], and [I-D.ietf-teas-yang- te-types]. file "ietf-te-topology-state@2019-02-07.yang" module ietf-te-topology-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-state"; prefix "tet-s"; import ietf-te-types { prefix "te-types"; reference "I-D.ietf-teas-yang-te-types: Traffic Engineering Common YANG Types"; } import ietf-te-topology { prefix "tet"; } import ietf-network-state { Liu, et al Expires December 19, 2019 [Page 163] Internet-Draft YANG - TE Topology June 2019 prefix "nw-s"; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-network-topology-state { prefix "nt-s"; reference "RFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Igor Bryskin Editor: Vishnu Pavan Beeram Editor: Tarek Saad Editor: Himanshu Shah Editor: Oscar Gonzalez De Dios "; description "TE topology state model. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Liu, et al Expires December 19, 2019 [Page 164] Internet-Draft YANG - TE Topology June 2019 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."; revision "2019-02-07" { description "Initial revision"; reference "RFC XXXX: YANG Data Model for TE Topologies"; // RFC Ed.: replace XXXX with actual RFC number and remove // this note } /* * Groupings */ grouping te-node-connectivity-matrix-attributes { description "Termination point references of a connectivity matrix entry."; container from { description "Reference to source link termination point."; leaf tp-ref { type leafref { path "../../../../../../nt-s:termination-point/nt-s:tp-id"; } description "Relative reference to a termination point."; } uses te-types:label-set-info; } container to { description "Reference to destination link termination point."; leaf tp-ref { type leafref { path "../../../../../../nt-s:termination-point/nt-s:tp-id"; Liu, et al Expires December 19, 2019 [Page 165] Internet-Draft YANG - TE Topology June 2019 } description "Relative reference to a termination point."; } uses te-types:label-set-info; } uses tet:connectivity-matrix-entry-path-attributes; } // te-node-connectivity-matrix-attributes grouping te-node-tunnel-termination-point-llc-list { description "Local link connectivity list of a tunnel termination point on a TE node."; list local-link-connectivity { key "link-tp-ref"; description "The termination capabilities between tunnel-termination-point and link termination-point. The capability information can be used to compute the tunnel path. The Interface Adjustment Capability Descriptors (IACD) (defined in RFC 6001) on each link-tp can be derived from this local-link-connectivity list."; reference "RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)."; leaf link-tp-ref { type leafref { path "../../../../../nt-s:termination-point/nt-s:tp-id"; } description "Link termination point."; } uses te-types:label-set-info; uses tet:connectivity-matrix-entry-path-attributes; } // local-link-connectivity } // te-node-tunnel-termination-point-config /* * Data nodes Liu, et al Expires December 19, 2019 [Page 166] Internet-Draft YANG - TE Topology June 2019 */ augment "/nw-s:networks/nw-s:network/nw-s:network-types" { description "Introduce new network type for TE topology."; container te-topology { presence "Indicates TE topology."; description "Its presence identifies the TE topology type."; } } augment "/nw-s:networks" { description "Augmentation parameters for TE topologies."; uses tet:te-topologies-augment; } augment "/nw-s:networks/nw-s:network" { when "nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE topology."; uses tet:te-topology-augment; } augment "/nw-s:networks/nw-s:network/nw-s:node" { when "../nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE at node level."; leaf te-node-id { type te-types:te-node-id; description "The identifier of a node in the TE topology. A node is specific to a topology to which it belongs."; Liu, et al Expires December 19, 2019 [Page 167] Internet-Draft YANG - TE Topology June 2019 } container te { must "../te-node-id" { description "te-node-id is mandatory."; } must "count(../nw-s:supporting-node)<=1" { description "For a node in a TE topology, there cannot be more than 1 supporting node. If multiple nodes are abstracted, the underlay-topology is used."; } presence "TE support."; description "Indicates TE support."; uses tet:te-node-augment; } // te } augment "/nw-s:networks/nw-s:network/nt-s:link" { when "../nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE at link level."; container te { must "count(../nt-s:supporting-link)<=1" { description "For a link in a TE topology, there cannot be more than 1 supporting link. If one or more link paths are abstracted, the underlay is used."; } presence "TE support."; description "Indicates TE support."; uses tet:te-link-augment; } // te } Liu, et al Expires December 19, 2019 [Page 168] Internet-Draft YANG - TE Topology June 2019 augment "/nw-s:networks/nw-s:network/nw-s:node/" + "nt-s:termination-point" { when "../../nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Configuration parameters for TE at termination point level."; uses tet:te-termination-point-augment; } augment "/nw-s:networks/nw-s:network/nt-s:link/te/bundle-stack-level/" + "bundle/bundled-links/bundled-link" { when "../../../../nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Augment TE link bundled link."; leaf src-tp-ref { type leafref { path "../../../../../nw-s:node[nw-s:node-id = " + "current()/../../../../nt-s:source/" + "nt-s:source-node]/" + "nt-s:termination-point/nt-s:tp-id"; require-instance true; } description "Reference to another TE termination point on the same source node."; } leaf des-tp-ref { type leafref { path "../../../../../nw-s:node[nw-s:node-id = " + "current()/../../../../nt-s:destination/" + "nt-s:dest-node]/" + "nt-s:termination-point/nt-s:tp-id"; require-instance true; Liu, et al Expires December 19, 2019 [Page 169] Internet-Draft YANG - TE Topology June 2019 } description "Reference to another TE termination point on the same destination node."; } } augment "/nw-s:networks/nw-s:network/nw-s:node/te/" + "information-source-entry/connectivity-matrices/" + "connectivity-matrix" { when "../../../../../nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Augment TE node connectivity-matrix."; uses te-node-connectivity-matrix-attributes; } augment "/nw-s:networks/nw-s:network/nw-s:node/te/te-node-attributes/" + "connectivity-matrices/connectivity-matrix" { when "../../../../../nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; } description "Augment TE node connectivity-matrix."; uses te-node-connectivity-matrix-attributes; } augment "/nw-s:networks/nw-s:network/nw-s:node/te/" + "tunnel-termination-point/local-link-connectivities" { when "../../../../nw-s:network-types/tet-s:te-topology" { description "Augmentation parameters apply only for networks with TE topology type."; Liu, et al Expires December 19, 2019 [Page 170] Internet-Draft YANG - TE Topology June 2019 } description "Augment TE node tunnel termination point LLCs (Local Link Connectivities)."; uses te-node-tunnel-termination-point-llc-list; } } Liu, et al Expires December 19, 2019 [Page 171] Internet-Draft YANG - TE Topology June 2019 Appendix C. Example: YANG Model for Technology Specific Augmentations This section provides an example YANG module to define a technology specific TE topology model for the example-topology described in Section 6. module example-topology { yang-version 1.1; namespace "http://example.com/example-topology"; prefix "ex-topo"; import ietf-network { prefix "nw"; } import ietf-network-topology { prefix "nt"; } import ietf-te-topology { prefix "tet"; } organization "Example Organization"; contact "Editor: Example Author"; description "This module defines a topology data model for the example technology."; revision 2018-06-15 { description "Initial revision."; reference "Example reference."; } /* * Data nodes Liu, et al Expires December 19, 2019 [Page 172] Internet-Draft YANG - TE Topology June 2019 */ augment "/nw:networks/nw:network/nw:network-types/" + "tet:te-topology" { description "Augment network types to define example topology type."; container example-topology { presence "Introduce new network type for example topology."; description "Its presence identifies the example topology type."; } } augment "/nw:networks/nw:network/tet:te" { when "../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } description "Augment network topology."; container attributes { description "Attributes for example technology."; leaf attribute-1 { type uint8; description "Attribute 1 for example technology."; } } } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes" { when "../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } description "Augment node attributes."; container attributes { description "Attributes for example technology."; Liu, et al Expires December 19, 2019 [Page 173] Internet-Draft YANG - TE Topology June 2019 leaf attribute-2 { type uint8; description "Attribute 2 for example technology."; } } } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices" { when "../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } description "Augment node connectivity matrices."; container attributes { description "Attributes for example technology."; leaf attribute-3 { type uint8; description "Attribute 3 for example technology."; } } } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix" { when "../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } description "Augment node connectivity matrix."; container attributes { description "Attributes for example technology."; leaf attribute-3 { type uint8; description "Attribute 3 for example technology."; } Liu, et al Expires December 19, 2019 [Page 174] Internet-Draft YANG - TE Topology June 2019 } } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point" { when "../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } description "Augment tunnel termination point."; container attributes { description "Attributes for example technology."; leaf attribute-4 { type uint8; description "Attribute 4 for example technology."; } } } augment "/nw:networks/nw:network/nw:node/nt:termination-point/" + "tet:te" { when "../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } description "Augment link termination point."; container attributes { description "Attributes for example technology."; leaf attribute-5 { type uint8; description "Attribute 5 for example technology."; } } } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes" { Liu, et al Expires December 19, 2019 [Page 175] Internet-Draft YANG - TE Topology June 2019 when "../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } description "Augment link attributes."; container attributes { description "Attributes for example technology."; leaf attribute-6 { type uint8; description "Attribute 6 for example technology."; } } } /* * Augment TE bandwidth. */ augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:interface-switching-capability/tet:max-lsp-bandwidth/" + "tet:te-bandwidth/tet:technology" { case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:max-link-bandwidth/" + "tet:te-bandwidth/tet:technology" { case "example" { Liu, et al Expires December 19, 2019 [Page 176] Internet-Draft YANG - TE Topology June 2019 container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:max-resv-link-bandwidth/" + "tet:te-bandwidth/tet:technology" { case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:unreserved-bandwidth/" + "tet:te-bandwidth/tet:technology" { case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; Liu, et al Expires December 19, 2019 [Page 177] Internet-Draft YANG - TE Topology June 2019 } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:path-constraints/tet:te-bandwidth/tet:technology" { when "../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:path-constraints/tet:te-bandwidth/tet:technology" { when "../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } Liu, et al Expires December 19, 2019 [Page 178] Internet-Draft YANG - TE Topology June 2019 } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:path-constraints/tet:te-bandwidth/tet:technology" { when "../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:path-constraints/tet:te-bandwidth/tet:technology" { when "../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; Liu, et al Expires December 19, 2019 [Page 179] Internet-Draft YANG - TE Topology June 2019 } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:client-layer-adaptation/" + "tet:switching-capability/tet:te-bandwidth/tet:technology" { when "../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:path-constraints/tet:te-bandwidth/tet:technology" { when "../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; Liu, et al Expires December 19, 2019 [Page 180] Internet-Draft YANG - TE Topology June 2019 description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:local-link-connectivity/" + "tet:path-constraints/tet:te-bandwidth/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:interface-switching-capability/tet:max-lsp-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { Liu, et al Expires December 19, 2019 [Page 181] Internet-Draft YANG - TE Topology June 2019 description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:max-link-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:max-resv-link-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; Liu, et al Expires December 19, 2019 [Page 182] Internet-Draft YANG - TE Topology June 2019 } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:information-source-entry/" + "tet:interface-switching-capability/tet:max-lsp-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:information-source-entry/" + "tet:max-link-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { Liu, et al Expires December 19, 2019 [Page 183] Internet-Draft YANG - TE Topology June 2019 description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:information-source-entry/" + "tet:max-resv-link-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:information-source-entry/" + "tet:unreserved-bandwidth/" Liu, et al Expires December 19, 2019 [Page 184] Internet-Draft YANG - TE Topology June 2019 + "tet:te-bandwidth/tet:technology" { when "../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } augment "/nw:networks/nw:network/nw:node/nt:termination-point/" + "tet:te/" + "tet:interface-switching-capability/tet:max-lsp-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf bandwidth-1 { type uint32; description "Bandwidth 1 for example technology."; } } } description "Augment TE bandwidth."; } Liu, et al Expires December 19, 2019 [Page 185] Internet-Draft YANG - TE Topology June 2019 /* * Augment TE label. */ augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { case "example" { Liu, et al Expires December 19, 2019 [Page 186] Internet-Draft YANG - TE Topology June 2019 container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/tet:te/tet:templates/" + "tet:link-template/tet:te-link-attributes/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } /* Under te-node-attributes/connectivity-matrices */ augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { Liu, et al Expires December 19, 2019 [Page 187] Internet-Draft YANG - TE Topology June 2019 description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; Liu, et al Expires December 19, 2019 [Page 188] Internet-Draft YANG - TE Topology June 2019 } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:path-properties/tet:path-route-objects/" + "tet:path-route-object/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" Liu, et al Expires December 19, 2019 [Page 189] Internet-Draft YANG - TE Topology June 2019 + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } /* Under te-node-attributes/.../connectivity-matrix */ augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:from/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } Liu, et al Expires December 19, 2019 [Page 190] Internet-Draft YANG - TE Topology June 2019 augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:from/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:to/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; Liu, et al Expires December 19, 2019 [Page 191] Internet-Draft YANG - TE Topology June 2019 } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:to/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { Liu, et al Expires December 19, 2019 [Page 192] Internet-Draft YANG - TE Topology June 2019 container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:path-properties/tet:path-route-objects/" + "tet:path-route-object/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../../nw:network-types/" Liu, et al Expires December 19, 2019 [Page 193] Internet-Draft YANG - TE Topology June 2019 + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } /* Under information-source-entry/connectivity-matrices */ augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } Liu, et al Expires December 19, 2019 [Page 194] Internet-Draft YANG - TE Topology June 2019 augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } Liu, et al Expires December 19, 2019 [Page 195] Internet-Draft YANG - TE Topology June 2019 description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:path-properties/tet:path-route-objects/" + "tet:path-route-object/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; Liu, et al Expires December 19, 2019 [Page 196] Internet-Draft YANG - TE Topology June 2019 description "Label 1 for example technology."; } } } description "Augment TE label."; } /* Under information-source-entry/.../connectivity-matrix */ augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:from/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:from/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with Liu, et al Expires December 19, 2019 [Page 197] Internet-Draft YANG - TE Topology June 2019 example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:to/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/tet:to/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" Liu, et al Expires December 19, 2019 [Page 198] Internet-Draft YANG - TE Topology June 2019 + "tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } Liu, et al Expires December 19, 2019 [Page 199] Internet-Draft YANG - TE Topology June 2019 augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:information-source-entry/tet:connectivity-matrices/" + "tet:connectivity-matrix/" + "tet:path-properties/tet:path-route-objects/" + "tet:path-route-object/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; Liu, et al Expires December 19, 2019 [Page 200] Internet-Draft YANG - TE Topology June 2019 description "Label 1 for example technology."; } } } description "Augment TE label."; } /* Under tunnel-termination-point/local-link-connectivities */ augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../../nw:network-types/tet:te-topology/" + "ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } Liu, et al Expires December 19, 2019 [Page 201] Internet-Draft YANG - TE Topology June 2019 case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description Liu, et al Expires December 19, 2019 [Page 202] Internet-Draft YANG - TE Topology June 2019 "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:path-properties/tet:path-route-objects/" + "tet:path-route-object/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } /* Under tunnel-termination-point/.../local-link-connectivity */ augment "/nw:networks/nw:network/nw:node/tet:te/" Liu, et al Expires December 19, 2019 [Page 203] Internet-Draft YANG - TE Topology June 2019 + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:local-link-connectivity/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:local-link-connectivity/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } Liu, et al Expires December 19, 2019 [Page 204] Internet-Draft YANG - TE Topology June 2019 } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:local-link-connectivity/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:local-link-connectivity/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; Liu, et al Expires December 19, 2019 [Page 205] Internet-Draft YANG - TE Topology June 2019 leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:tunnel-termination-point/tet:local-link-connectivities/" + "tet:local-link-connectivity/" + "tet:path-properties/tet:path-route-objects/" + "tet:path-route-object/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } /* Under te-link-attributes */ augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { Liu, et al Expires December 19, 2019 [Page 206] Internet-Draft YANG - TE Topology June 2019 description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:underlay/tet:primary-path/tet:path-element/tet:type/" Liu, et al Expires December 19, 2019 [Page 207] Internet-Draft YANG - TE Topology June 2019 + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:underlay/tet:backup-path/tet:path-element/tet:type/" + "tet:label/tet:label-hop/tet:te-label/tet:technology" { when "../../../../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } Liu, et al Expires December 19, 2019 [Page 208] Internet-Draft YANG - TE Topology June 2019 /* Under te-link information-source-entry */ augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:information-source-entry/" + "tet:label-restrictions/tet:label-restriction/tet:label-start/" + "tet:te-label/tet:technology" { when "../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } } } description "Augment TE label."; } augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:information-source-entry/" + "tet:label-restrictions/tet:label-restriction/tet:label-end/" + "tet:te-label/tet:technology" { when "../../../../../../../nw:network-types/" + "tet:te-topology/ex-topo:example-topology" { description "Augmentation parameters apply only for networks with example topology type."; } case "example" { container example { description "Attributes for example technology."; leaf label-1 { type uint32; description "Label 1 for example technology."; } Liu, et al Expires December 19, 2019 [Page 209] Internet-Draft YANG - TE Topology June 2019 } } description "Augment TE label."; } } Contributors Sergio Belotti Nokia Email: sergio.belotti@nokia.com Dieter Beller Nokia Email: Dieter.Beller@nokia.com Carlo Perocchio Ericsson Email: carlo.perocchio@ericsson.com Italo Busi Huawei Technologies Email: Italo.Busi@huawei.com Authors' Addresses Xufeng Liu Volta Networks Email: xufeng.liu.ietf@gmail.com Igor Bryskin Huawei Technologies Email: Igor.Bryskin@huawei.com Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net Tarek Saad Juniper Networks Email: tsaad@juniper.net Himanshu Shah Ciena Email: hshah@ciena.com Liu, et al Expires December 19, 2019 [Page 210] Internet-Draft YANG - TE Topology June 2019 Oscar Gonzalez De Dios Telefonica Email: oscar.gonzalezdedios@telefonica.com Liu, et al Expires December 19, 2019 [Page 211] ./draft-ietf-tls-grease-04.txt0000644000764400076440000006663213527551544015452 0ustar iustyiusty Network Working Group D. Benjamin Internet-Draft Google LLC Intended status: Informational August 21, 2019 Expires: February 22, 2020 Applying GREASE to TLS Extensibility draft-ietf-tls-grease-04 Abstract This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. 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 https://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 22, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Benjamin Expires February 22, 2020 [Page 1] Internet-Draft Applying GREASE to TLS Extensibility August 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. GREASE Values . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Client-Initiated Extension Points . . . . . . . . . . . . . . 4 3.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 3.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 4. Server-Initiated Extension Points . . . . . . . . . . . . . . 6 4.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 4.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 7 5. Sending GREASE Values . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The TLS protocol [RFC8446] includes several points of extensibility, including the list of cipher suites and several lists of extensions. The values transmitted in these lists identify implementation capabilities. TLS follows a model where one side, usually the client, advertises capabilities and the peer, usually the server, selects them. The responding side must ignore unknown values so that new capabilities may be introduced to the ecosystem while maintaining interoperability. However, bugs may cause an implementation to reject unknown values. It will interoperate with existing peers, so the mistake may spread through the ecosystem unnoticed. Later, when new values are defined, updated peers will discover that the metaphorical joint in the protocol has rusted shut and that the new values cannot be deployed without interoperability failures. To avoid this problem, this document reserves some currently unused values for TLS implementations to advertise at random. Correctly implemented peers will ignore these values and interoperate. Peers that do not tolerate unknown values will fail to interoperate, revealing the mistake before it is widespread. In keeping with the rusted joint metaphor, this technique is named GREASE (Generate Random Extensions And Sustain Extensibility). Benjamin Expires February 22, 2020 [Page 2] Internet-Draft Applying GREASE to TLS Extensibility August 2019 1.1. Requirements Language 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 [RFC2119][RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. GREASE Values This document reserves a number of TLS protocol values, referred to as GREASE values. These values were allocated sparsely to discourage server implementations from conditioning on them. For convenience, they were also chosen so all types share a number scheme with a consistent pattern while avoiding collisions with any existing applicable registries in TLS. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The values prefaced with {TBD} are suggested values and subject to change prior to final allocation by IANA. The following values are reserved as GREASE values for cipher suites and ALPN [RFC7301] identifiers: {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A} {TBD} {0x2A,0x2A} {TBD} {0x3A,0x3A} {TBD} {0x4A,0x4A} {TBD} {0x5A,0x5A} {TBD} {0x6A,0x6A} {TBD} {0x7A,0x7A} {TBD} {0x8A,0x8A} {TBD} {0x9A,0x9A} {TBD} {0xAA,0xAA} {TBD} {0xBA,0xBA} {TBD} {0xCA,0xCA} {TBD} {0xDA,0xDA} {TBD} {0xEA,0xEA} {TBD} {0xFA,0xFA} The following values are reserved as GREASE values for extensions, named groups, signature algorithms, and versions: {TBD} 0x0A0A {TBD} 0x1A1A {TBD} 0x2A2A {TBD} 0x3A3A Benjamin Expires February 22, 2020 [Page 3] Internet-Draft Applying GREASE to TLS Extensibility August 2019 {TBD} 0x4A4A {TBD} 0x5A5A {TBD} 0x6A6A {TBD} 0x7A7A {TBD} 0x8A8A {TBD} 0x9A9A {TBD} 0xAAAA {TBD} 0xBABA {TBD} 0xCACA {TBD} 0xDADA {TBD} 0xEAEA {TBD} 0xFAFA The values allocated above are thus no longer available for use as TLS or DTLS [RFC6347] version numbers. The following values are reserved as GREASE values for PskKeyExchangeModes. {TBD} 0x0B {TBD} 0x2A {TBD} 0x49 {TBD} 0x68 {TBD} 0x87 {TBD} 0xA6 {TBD} 0xC5 {TBD} 0xE4 3. Client-Initiated Extension Points Most extension points in TLS are offered by the client and selected by the server. This section details client and server behavior around GREASE values for these. 3.1. Client Behavior When sending a ClientHello, a client MAY behave as follows: o A client MAY select one or more GREASE cipher suite values and advertise them in the "cipher_suites" field. o A client MAY select one or more GREASE extension values and advertise them as extensions with varying length and contents. o A client MAY select one or more GREASE named group values and advertise them in the "supported_groups" extension, if sent. It MAY also send KeyShareEntry values for a subset of those selected Benjamin Expires February 22, 2020 [Page 4] Internet-Draft Applying GREASE to TLS Extensibility August 2019 in the "key_share" extension. For each of these, the "key_exchange" field MAY be any value. o A client MAY select one or more GREASE signature algorithm values and advertise them in the "signature_algorithms" or "signature_algorithms_cert" extensions, if sent. o A client MAY select one or more GREASE version values and advertise them in the "supported_versions" extension, if sent. o A client MAY select one or more GREASE PskKeyExchangeMode values and advertise them in the "psk_key_exchange_modes" extension, if sent. o A client MAY select one or more GREASE ALPN identifiers and advertise them in the "application_layer_protocol_negotiation" extension, if sent. Clients MUST reject GREASE values when negotiated by the server. In particular, the client MUST fail the connection if a GREASE value appears any in the following: o The "version" value in a ServerHello or HelloRetryRequest o The "cipher_suite" value in a ServerHello o Any ServerHello extension o Any HelloRetryRequest, EncryptedExtensions, or Certificate extension in TLS 1.3 o The "namedcurve" value in a ServerKeyExchange for an ECDHE cipher in TLS 1.2 [RFC5246] or earlier o The signature algorithm in a ServerKeyExchange signature in TLS 1.2 or earlier o The signature algorithm in a server CertificateVerify signature in TLS 1.3 Note that this can be implemented without special processing on the client. The client is already required to reject unknown server- selected values, so it may leave GREASE values as unknown and reuse the existing logic. Benjamin Expires February 22, 2020 [Page 5] Internet-Draft Applying GREASE to TLS Extensibility August 2019 3.2. Server Behavior When processing a ClientHello, servers MUST NOT treat GREASE values differently from any unknown value. Servers MUST NOT negotiate any GREASE value when offered in a ClientHello. Servers MUST correctly ignore unknown values in a ClientHello and attempt to negotiate with one of the remaining parameters. (There may not be any known parameters remaining, in which case parameter negotiation will fail.) Note that these requirements are restatements or corollaries of existing server requirements in TLS. 4. Server-Initiated Extension Points Some extension points are offered by the server and selected by the client. This section details client and server behavior around GREASE values for these. 4.1. Server Behavior When sending a CertificateRequest in TLS 1.3, a server MAY behave as follows: o A server MAY select one or more GREASE extension values and advertise them as extensions with varying length and contents. o A server MAY select one or more GREASE signature algorithm values and advertise them in the "signature_algorithms" or "signature_algorithms_cert" extensions, if present. When sending a NewSessionTicket message in TLS 1.3, a server MAY select one or more GREASE extension values and advertise them as extensions with varying length and contents. Servers MUST reject GREASE values when negotiated by the client. In particular, the server MUST fail the connection if a GREASE value appears any in the following: o Any Certificate extension in TLS 1.3 o The signature algorithm in a client CertificateVerify signature Note that this can be implemented without special processing on the server. The server is already required to reject unknown client- selected values, so it may leave GREASE values as unknown and reuse the existing logic. Benjamin Expires February 22, 2020 [Page 6] Internet-Draft Applying GREASE to TLS Extensibility August 2019 4.2. Client Behavior When processing a CertificateRequest or NewSessionTicket, clients MUST NOT treat GREASE values differently from any unknown value. Clients MUST NOT negotiate any GREASE value when offered by the server. Clients MUST correctly ignore unknown values offered by the server and attempt to negotiate with one of the remaining parameters. (There may not be any known parameters remaining, in which case parameter negotiation will fail.) Note that these requirements are restatements or corollaries of existing client requirements in TLS. 5. Sending GREASE Values Implementations advertising GREASE values SHOULD select them at random. This is intended to encourage implementations to ignore all unknown values rather than any individual value. Implementations MUST honor protocol specifications when sending GREASE values. For instance, section 4.2 of [RFC8446] forbids duplicate extension types within a single extension block. Implementations sending multiple GREASE extensions in a single block thus must ensure the same value is not selected twice. Implementations SHOULD balance diversity in GREASE advertisements with determinism. For example, a client which randomly varies GREASE value positions for each connection may only fail against a broken server with some probability. This risks the failure being masked by automatic retries. A client which positions GREASE values deterministically over a period of time (such as a single software release) stresses fewer cases but is more likely to detect bugs from those cases. 6. IANA Considerations This document updates the TLS Cipher Suite Registry, available from : Benjamin Expires February 22, 2020 [Page 7] Internet-Draft Applying GREASE to TLS Extensibility August 2019 +---------------+-------------+---------+-------------+-------------+ | Value | Description | DTLS-OK | Recommended | Reference | +---------------+-------------+---------+-------------+-------------+ | {TBD} | Reserved | Y | N | (this | | {0x0A,0x0A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x1A,0x1A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x2A,0x2A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x3A,0x3A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x4A,0x4A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x5A,0x5A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x6A,0x6A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x7A,0x7A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x8A,0x8A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0x9A,0x9A} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0xAA,0xAA} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0xBA,0xBA} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0xCA,0xCA} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0xDA,0xDA} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0xEA,0xEA} | | | | document) | | {TBD} | Reserved | Y | N | (this | | {0xFA,0xFA} | | | | document) | +---------------+-------------+---------+-------------+-------------+ Additions to the TLS Cipher Suite Registry RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The cipher suite numbers listed in the first column are numbers used for interoperability testing and it's suggested that IANA use these values for assignment. This document updates the Supported Groups Registry, available from : Benjamin Expires February 22, 2020 [Page 8] Internet-Draft Applying GREASE to TLS Extensibility August 2019 +------------+-------------+---------+-------------+----------------+ | Value | Description | DTLS-OK | Recommended | Reference | +------------+-------------+---------+-------------+----------------+ | {TBD} 2570 | Reserved | Y | N | (this | | | | | | document) | | {TBD} 6682 | Reserved | Y | N | (this | | | | | | document) | | {TBD} | Reserved | Y | N | (this | | 10794 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 14906 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 19018 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 23130 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 27242 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 31354 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 35466 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 39578 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 43690 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 47802 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 51914 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 56026 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 60138 | | | | document) | | {TBD} | Reserved | Y | N | (this | | 64250 | | | | document) | +------------+-------------+---------+-------------+----------------+ Additions to the Supported Groups Registry RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The named group numbers listed in the first column are numbers used for interoperability testing and it's suggested that IANA use these values for assignment. This document updates the ExtensionType Values registry, available from : Benjamin Expires February 22, 2020 [Page 9] Internet-Draft Applying GREASE to TLS Extensibility August 2019 +----------+--------------+-----------+-------------+---------------+ | Value | Extension | TLS 1.3 | Recommended | Reference | | | name | | | | +----------+--------------+-----------+-------------+---------------+ | {TBD} | Reserved | CH, CR, | N | (this | | 2570 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 6682 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 10794 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 14906 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 19018 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 23130 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 27242 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 31354 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 35466 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 39578 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 43690 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 47802 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 51914 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 56026 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 60138 | | NST | | document) | | {TBD} | Reserved | CH, CR, | N | (this | | 64250 | | NST | | document) | +----------+--------------+-----------+-------------+---------------+ Additions to the ExtensionType Values registry RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The extension numbers listed in the first column are numbers used for interoperability testing and it's suggested that IANA use these values for assignment. This document updates the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry, available from Benjamin Expires February 22, 2020 [Page 10] Internet-Draft Applying GREASE to TLS Extensibility August 2019 : +----------+-------------------------+-----------------+ | Protocol | Identification Sequence | Reference | +----------+-------------------------+-----------------+ | Reserved | {TBD} 0x0A 0x0A | (this document) | | Reserved | {TBD} 0x1A 0x1A | (this document) | | Reserved | {TBD} 0x2A 0x2A | (this document) | | Reserved | {TBD} 0x3A 0x3A | (this document) | | Reserved | {TBD} 0x4A 0x4A | (this document) | | Reserved | {TBD} 0x5A 0x5A | (this document) | | Reserved | {TBD} 0x6A 0x6A | (this document) | | Reserved | {TBD} 0x7A 0x7A | (this document) | | Reserved | {TBD} 0x8A 0x8A | (this document) | | Reserved | {TBD} 0x9A 0x9A | (this document) | | Reserved | {TBD} 0xAA 0xAA | (this document) | | Reserved | {TBD} 0xBA 0xBA | (this document) | | Reserved | {TBD} 0xCA 0xCA | (this document) | | Reserved | {TBD} 0xDA 0xDA | (this document) | | Reserved | {TBD} 0xEA 0xEA | (this document) | | Reserved | {TBD} 0xFA 0xFA | (this document) | +----------+-------------------------+-----------------+ Additions to the ALPN Protocol IDs registry 7. Security Considerations GREASE values cannot be negotiated, so they do not directly impact the security of TLS connections. Historically, when interoperability problems arise in deploying new TLS features, implementations have used a fallback retry on error with the feature disabled. This allows an active attacker to silently disable the new feature. By preventing a class of such interoperability problems, GREASE reduces the need for this kind of fallback. Implementations SHOULD NOT retry with GREASE disabled on connection failure. While allowing an attacker to disable GREASE is unlikely to have immediate security consequences, such a fallback would prevent GREASE from defending against extensibility failures. If an implementation does not select GREASE values at random it is possible it will allow for fingerprinting of the implementation or perhaps even of individual users. This can result in a negative impact to a user's privacy. Benjamin Expires February 22, 2020 [Page 11] Internet-Draft Applying GREASE to TLS Extensibility August 2019 8. Acknowledgments The author would like to thank Adam Langley, Nick Harper, and Steven Valdez for their feedback and suggestions. In addition, the rusted joint metaphor is originally due to Adam Langley. 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, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Author's Address David Benjamin Google LLC Email: davidben@google.com Benjamin Expires February 22, 2020 [Page 12] ./draft-ietf-tram-stunbis-21.txt0000644000764400076440000053752013445206757016034 0ustar iustyiusty TRAM M. Petit-Huguenin Internet-Draft Impedance Mismatch Obsoletes: 5389 (if approved) G. Salgueiro Intended status: Standards Track Cisco Expires: September 22, 2019 J. Rosenberg Five9 D. Wing R. Mahy Unaffiliated P. Matthews Nokia March 21, 2019 Session Traversal Utilities for NAT (STUN) draft-ietf-tram-stunbis-21 Abstract 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 document obsoletes RFC 5389. 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 https://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." Petit-Huguenin, et al. Expires September 22, 2019 [Page 1] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 This Internet-Draft will expire on September 22, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10 6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12 6.1. Forming a Request or an Indication . . . . . . . . . . . 12 6.2. Sending the Request or Indication . . . . . . . . . . . . 13 6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14 6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16 6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 17 6.3.1. Processing a Request . . . . . . . . . . . . . . . . 18 6.3.1.1. Forming a Success or Error Response . . . . . . . 18 6.3.1.2. Sending the Success or Error Response . . . . . . 19 6.3.2. Processing an Indication . . . . . . . . . . . . . . 19 6.3.3. Processing a Success Response . . . . . . . . . . . . 20 6.3.4. Processing an Error Response . . . . . . . . . . . . 20 7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 21 8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21 8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 22 9. Authentication and Message-Integrity Mechanisms . . . . . . . 23 9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 23 9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 24 9.1.2. Forming a Request or Indication . . . . . . . . . . . 24 9.1.3. Receiving a Request or Indication . . . . . . . . . . 24 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 25 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26 Petit-Huguenin, et al. Expires September 22, 2019 [Page 2] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 9.2.1. Bid Down Attack Prevention . . . . . . . . . . . . . 28 9.2.2. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 28 9.2.3. Forming a Request . . . . . . . . . . . . . . . . . . 29 9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 29 9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 29 9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 30 9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 32 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33 11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 35 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 36 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 37 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 38 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 39 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 40 14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 40 14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 40 14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 41 14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 42 14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 42 14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 44 14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 44 14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 44 14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 45 14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 46 14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 46 14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 46 14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 47 15. Operational Considerations . . . . . . . . . . . . . . . . . 47 16. Security Considerations . . . . . . . . . . . . . . . . . . . 47 16.1. Attacks against the Protocol . . . . . . . . . . . . . . 47 16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 47 16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 48 16.1.3. Bid-Down Attacks . . . . . . . . . . . . . . . . . . 49 16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 51 16.2.1. Attack I: Distributed DoS (DDoS) against a Target . 51 16.2.2. Attack II: Silencing a Client . . . . . . . . . . . 52 16.2.3. Attack III: Assuming the Identity of a Client . . . 52 16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 52 16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 52 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 53 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 18.1. STUN Security Features Registry . . . . . . . . . . . . 54 18.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 54 18.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 54 18.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 54 18.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 55 18.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 55 Petit-Huguenin, et al. Expires September 22, 2019 [Page 3] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 18.5. STUN Password Algorithm Registry . . . . . . . . . . . . 55 18.5.1. Password Algorithms . . . . . . . . . . . . . . . . 56 18.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 56 18.5.1.2. SHA-256 . . . . . . . . . . . . . . . . . . . . 56 18.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 56 19. Changes Since RFC 5389 . . . . . . . . . . . . . . . . . . . 57 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 20.1. Normative References . . . . . . . . . . . . . . . . . . 57 20.2. Informative References . . . . . . . . . . . . . . . . . 60 Appendix A. C Snippet to Determine STUN Message Types . . . . . 62 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 63 B.1. Sample Request with Long-Term Authentication with MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 63 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 65 C.1. Modifications between draft-ietf-tram-stunbis-21 and draft-ietf-tram-stunbis-20 . . . . . . . . . . . . . . . 65 C.2. Modifications between draft-ietf-tram-stunbis-20 and draft-ietf-tram-stunbis-19 . . . . . . . . . . . . . . . 65 C.3. Modifications between draft-ietf-tram-stunbis-19 and draft-ietf-tram-stunbis-18 . . . . . . . . . . . . . . . 65 C.4. Modifications between draft-ietf-tram-stunbis-18 and draft-ietf-tram-stunbis-17 . . . . . . . . . . . . . . . 65 C.5. Modifications between draft-ietf-tram-stunbis-17 and draft-ietf-tram-stunbis-16 . . . . . . . . . . . . . . . 65 C.6. Modifications between draft-ietf-tram-stunbis-16 and draft-ietf-tram-stunbis-15 . . . . . . . . . . . . . . . 65 C.7. Modifications between draft-ietf-tram-stunbis-15 and draft-ietf-tram-stunbis-14 . . . . . . . . . . . . . . . 66 C.8. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 66 C.9. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 67 C.10. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 67 C.11. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 67 C.12. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 68 C.13. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 68 C.14. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 69 C.15. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 69 C.16. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 69 C.17. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 69 Petit-Huguenin, et al. Expires September 22, 2019 [Page 4] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 C.18. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 70 C.19. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 70 C.20. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 70 C.21. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 71 C.22. Modifications between draft-salgueiro-tram-stunbis-02 and draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 72 C.23. Modifications between draft-salgueiro-tram-stunbis-02 and draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 72 C.24. Modifications between draft-salgueiro-tram-stunbis-01 and draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 72 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 1. Introduction The protocol defined in this specification, Session Traversal Utilities for NAT, provides a tool for dealing with NATs. It provides a means for an endpoint to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port. It also provides a way for an endpoint to keep a NAT binding alive. With some extensions, the protocol can be used to do connectivity checks between two endpoints [RFC8445], or to relay packets between two endpoints [RFC5766]. In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication. STUN is intended to be used in the context of one or more NAT traversal solutions. These solutions are known as STUN usages. Each usage describes how STUN is utilized to achieve the NAT traversal solution. Typically, a usage indicates when STUN messages get sent, which optional attributes to include, what server is used, and what authentication mechanism is to be used. Interactive Connectivity Establishment (ICE) [RFC8445] is one usage of STUN. SIP Outbound [RFC5626] is another usage of STUN. In some cases, a usage will require extensions to STUN. A STUN extension can be in the form of new methods, attributes, or error response codes. More information on STUN usages can be found in Section 13. Petit-Huguenin, et al. Expires September 22, 2019 [Page 5] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 2. Overview of Operation This section is descriptive only. /-----\ // STUN \\ | Server | \\ // \-----/ +--------------+ Public Internet ................| NAT 2 |....................... +--------------+ +--------------+ Private NET 2 ................| NAT 1 |....................... +--------------+ /-----\ // STUN \\ | Client | \\ // Private NET 1 \-----/ Figure 1: One Possible STUN Configuration One possible STUN configuration is shown in Figure 1. In this configuration, there are two entities (called STUN agents) that implement the STUN protocol. The lower agent in the figure is the client, and is connected to private network 1. This network connects to private network 2 through NAT 1. Private network 2 connects to the public Internet through NAT 2. The upper agent in the figure is the server, and resides on the public Internet. STUN is a client-server protocol. It supports two types of transactions. One is a request/response transaction in which a client sends a request to a server, and the server returns a response. The second is an indication transaction in which either agent -- client or server -- sends an indication that generates no response. Both types of transactions include a transaction ID, which Petit-Huguenin, et al. Expires September 22, 2019 [Page 6] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 is a randomly selected 96-bit number. For request/response transactions, this transaction ID allows the client to associate the response with the request that generated it; for indications, the transaction ID serves as a debugging aid. All STUN messages start with a fixed header that includes a method, a class, and the transaction ID. The method indicates which of the various requests or indications this is; this specification defines just one method, Binding, but other methods are expected to be defined in other documents. The class indicates whether this is a request, a success response, an error response, or an indication. Following the fixed header comes zero or more attributes, which are Type-Length-Value extensions that convey additional information for the specific message. This document defines a single method called Binding. The Binding method can be used either in request/response transactions or in indication transactions. When used in request/response transactions, the Binding method can be used to determine the particular "binding" a NAT has allocated to a STUN client. When used in either request/ response or in indication transactions, the Binding method can also be used to keep these "bindings" alive. In the Binding request/response transaction, a Binding request is sent from a STUN client to a STUN server. When the Binding request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server (in Figure 1, there were two such NATs). As the Binding request message passes through a NAT, the NAT will modify the source transport address (that is, the source IP address and the source port) of the packet. As a result, the source transport address of the request received by the server will be the public IP address and port created by the NAT closest to the server. This is called a reflexive transport address. The STUN server copies that source transport address into an XOR-MAPPED- ADDRESS attribute in the STUN Binding response and sends the Binding response back to the STUN client. As this packet passes back through a NAT, the NAT will modify the destination transport address in the IP header, but the transport address in the XOR-MAPPED-ADDRESS attribute within the body of the STUN response will remain untouched. In this way, the client can learn its reflexive transport address allocated by the outermost NAT with respect to the STUN server. In some usages, STUN must be multiplexed with other protocols (e.g., [RFC8445], [RFC5626]). In these usages, there must be a way to inspect a packet and determine if it is a STUN packet or not. STUN provides three fields in the STUN header with fixed values that can be used for this purpose. If this is not sufficient, then STUN Petit-Huguenin, et al. Expires September 22, 2019 [Page 7] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 packets can also contain a FINGERPRINT value, which can further be used to distinguish the packets. STUN defines a set of optional procedures that a usage can decide to use, called mechanisms. These mechanisms include DNS discovery, a redirection technique to an alternate server, a fingerprint attribute for demultiplexing, and two authentication and message-integrity exchanges. The authentication mechanisms revolve around the use of a username, password, and message-integrity value. Two authentication mechanisms, the long-term credential mechanism and the short-term credential mechanism, are defined in this specification. Each usage specifies the mechanisms allowed with that usage. In the long-term credential mechanism, the client and server share a pre-provisioned username and password and perform a digest challenge/ response exchange inspired by (but differing in details) to the one defined for HTTP [RFC7616]. In the short-term credential mechanism, the client and the server exchange a username and password through some out-of-band method prior to the STUN exchange. For example, in the ICE usage [RFC8445] the two endpoints use out-of-band signaling to exchange a username and password. These are used to integrity protect and authenticate the request and response. There is no challenge or nonce used. 3. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Definitions STUN Agent: A STUN agent is an entity that implements the STUN protocol. The entity can be either a STUN client or a STUN server. STUN Client: A STUN client is an entity that sends STUN requests and receives STUN responses and STUN indications. A STUN client can also send indications. In this specification, the terms STUN client and client are synonymous. STUN Server: A STUN server is an entity that receives STUN requests and STUN indications, and sends STUN responses. A STUN server can also send indications. In this specification, the terms STUN server and server are synonymous. Petit-Huguenin, et al. Expires September 22, 2019 [Page 8] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Transport Address: The combination of an IP address and port number (such as a UDP or TCP port number). Reflexive Transport Address: A transport address learned by a client that identifies that client as seen by another host on an IP network, typically a STUN server. When there is an intervening NAT between the client and the other host, the reflexive transport address represents the mapped address allocated to the client on the public side of the NAT. Reflexive transport addresses are learned from the mapped address attribute (MAPPED-ADDRESS or XOR- MAPPED-ADDRESS) in STUN responses. Mapped Address: Same meaning as reflexive address. This term is retained only for historic reasons and due to the naming of the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes. Long-Term Credential: A username and associated password that represent a shared secret between client and server. Long-term credentials are generally granted to the client when a subscriber enrolls in a service and persist until the subscriber leaves the service or explicitly changes the credential. Long-Term Password: The password from a long-term credential. Short-Term Credential: A temporary username and associated password that represent a shared secret between client and server. Short- term credentials are obtained through some kind of protocol mechanism between the client and server, preceding the STUN exchange. A short-term credential has an explicit temporal scope, which may be based on a specific amount of time (such as 5 minutes) or on an event (such as termination of a Session Initiation Protocol (SIP [RFC3261]) dialog). The specific scope of a short-term credential is defined by the application usage. Short-Term Password: The password component of a short-term credential. STUN Indication: A STUN message that does not receive a response. Attribute: The STUN term for a Type-Length-Value (TLV) object that can be added to a STUN message. Attributes are divided into two types: comprehension-required and comprehension-optional. STUN agents can safely ignore comprehension-optional attributes they don't understand, but cannot successfully process a message if it contains comprehension-required attributes that are not understood. Petit-Huguenin, et al. Expires September 22, 2019 [Page 9] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 RTO: Retransmission TimeOut, which defines the initial period of time between transmission of a request and the first retransmit of that request. 5. STUN Message Structure STUN messages are encoded in binary using network-oriented format (most significant byte or octet first, also commonly known as big- endian). The transmission order is described in detail in Appendix B of [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10). All STUN messages comprise a 20-byte header followed by zero or more Attributes. The STUN header contains a STUN message type, message length, magic cookie, and transaction ID. 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| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of STUN Message Header The most significant 2 bits of every STUN message MUST be zeroes. This can be used to differentiate STUN packets from other protocols when STUN is multiplexed with other protocols on the same port. The message type defines the message class (request, success response, error response, or indication) and the message method (the primary function) of the STUN message. Although there are four message classes, there are only two types of transactions in STUN: request/response transactions (which consist of a request message and a response message) and indication transactions (which consist of a single indication message). Response classes are split into error and success responses to aid in quickly processing the STUN message. The message type field is decomposed further into the following structure: Petit-Huguenin, et al. Expires September 22, 2019 [Page 10] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ |M |M |M|M|M|C|M|M|M|C|M|M|M|M| |11|10|9|8|7|1|6|5|4|0|3|2|1|0| +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of STUN Message Type Field Here the bits in the message type field are shown as most significant (M11) through least significant (M0). M11 through M0 represent a 12-bit encoding of the method. C1 and C0 represent a 2-bit encoding of the class. A class of 0b00 is a request, a class of 0b01 is an indication, a class of 0b10 is a success response, and a class of 0b11 is an error response. This specification defines a single method, Binding. The method and class are orthogonal, so that for each method, a request, success response, error response, and indication are possible for that method. Extensions defining new methods MUST indicate which classes are permitted for that method. For example, a Binding request has class=0b00 (request) and method=0b000000000001 (Binding) and is encoded into the first 16 bits as 0x0001. A Binding response has class=0b10 (success response) and method=0b000000000001, and is encoded into the first 16 bits as 0x0101. Note: This unfortunate encoding is due to assignment of values in [RFC3489] that did not consider encoding Indications, Success, and Errors using bit fields. The magic cookie field MUST contain the fixed value 0x2112A442 in network byte order. In [RFC3489], this field was part of the transaction ID; placing the magic cookie in this location allows a server to detect if the client will understand certain attributes that were added to STUN by [RFC5389]. In addition, it aids in distinguishing STUN packets from packets of other protocols when STUN is multiplexed with those other protocols on the same port. The transaction ID is a 96-bit identifier, used to uniquely identify STUN transactions. For request/response transactions, the transaction ID is chosen by the STUN client for the request and echoed by the server in the response. For indications, it is chosen by the agent sending the indication. It primarily serves to correlate requests with responses, though it also plays a small role in helping to prevent certain types of attacks. The server also uses the transaction ID as a key to identify each transaction uniquely across all clients. As such, the transaction ID MUST be uniformly and randomly chosen from the interval 0 .. 2**96-1, and MUST be Petit-Huguenin, et al. Expires September 22, 2019 [Page 11] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 cryptographically random. Resends of the same request reuse the same transaction ID, but the client MUST choose a new transaction ID for new transactions unless the new request is bit-wise identical to the previous request and sent from the same transport address to the same IP address. Success and error responses MUST carry the same transaction ID as their corresponding request. When an agent is acting as a STUN server and STUN client on the same port, the transaction IDs in requests sent by the agent have no relationship to the transaction IDs in requests received by the agent. The message length MUST contain the size, in bytes, of the message not including the 20-byte STUN header. Since all STUN attributes are padded to a multiple of 4 bytes, the last 2 bits of this field are always zero. This provides another way to distinguish STUN packets from packets of other protocols. Following the STUN fixed portion of the header are zero or more attributes. Each attribute is TLV (Type-Length-Value) encoded. The details of the encoding, and of the attributes themselves are given in Section 14. 6. Base Protocol Procedures This section defines the base procedures of the STUN protocol. It describes how messages are formed, how they are sent, and how they are processed when they are received. It also defines the detailed processing of the Binding method. Other sections in this document describe optional procedures that a usage may elect to use in certain situations. Other documents may define other extensions to STUN, by adding new methods, new attributes, or new error response codes. 6.1. Forming a Request or an Indication When formulating a request or indication message, the agent MUST follow the rules in Section 5 when creating the header. In addition, the message class MUST be either "Request" or "Indication" (as appropriate), and the method must be either Binding or some method defined in another document. The agent then adds any attributes specified by the method or the usage. For example, some usages may specify that the agent use an authentication method (Section 9) or the FINGERPRINT attribute (Section 7). If the agent is sending a request, it SHOULD add a SOFTWARE attribute to the request. Agents MAY include a SOFTWARE attribute in indications, depending on the method. Extensions to STUN should discuss whether SOFTWARE is useful in new indications. Note that the Petit-Huguenin, et al. Expires September 22, 2019 [Page 12] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 inclusion of a SOFTWARE attribute may have security implications; see Section 16.1.2 for details. For the Binding method with no authentication, no attributes are required unless the usage specifies otherwise. All STUN messages sent over UDP or DTLS-over-UDP [RFC6347] SHOULD be less than the path MTU, if known. If the path MTU is unknown for UDP, messages SHOULD be the smaller of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC8200]. This value corresponds to the overall size of the IP packet. Consequently, for IPv4, the actual STUN message would need to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte UDP header, assuming no IP options are used). If the path MTU is unknown for DTLS-over-UDP, the rules described in the previous paragraph need to be adjusted to take into account the size of the (13-byte) DTLS Record header, the MAC size, and the padding size. STUN provides no ability to handle the case where the request is under the MTU but the response would be larger than the MTU. It is not envisioned that this limitation will be an issue for STUN. The MTU limitation is a SHOULD, and not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [RFC5780]. See also [I-D.ietf-tram-stun-pmtud] for a framework that uses STUN to add Path MTU Discovery to protocols that lack one. Outside of this or similar applications, the MTU constraint MUST be followed. 6.2. Sending the Request or Indication The agent then sends the request or indication. This document specifies how to send STUN messages over UDP, TCP, TLS-over-TCP, or DTLS-over-UDP; other transport protocols may be added in the future. The STUN usage must specify which transport protocol is used, and how the agent determines the IP address and port of the recipient. Section 8 describes a DNS-based method of determining the IP address and port of a server that a usage may elect to use. At any time, a client MAY have multiple outstanding STUN requests with the same STUN server (that is, multiple transactions in progress, with different transaction IDs). Absent other limits to the rate of new transactions (such as those specified by ICE for connectivity checks or when STUN is run over TCP), a client SHOULD limit itself to ten outstanding transactions to the same server. Petit-Huguenin, et al. Expires September 22, 2019 [Page 13] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 6.2.1. Sending over UDP or DTLS-over-UDP When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], it is possible that the STUN message might be dropped by the network. Reliability of STUN request/response transactions is accomplished through retransmissions of the request message by the client application itself. STUN indications are not retransmitted; thus, indication transactions over UDP or DTLS-over-UDP are not reliable. A client SHOULD retransmit a STUN request message starting with an interval of RTO ("Retransmission TimeOut"), doubling after each retransmission. The RTO is an estimate of the round-trip time (RTT), and is computed as described in [RFC6298], with two exceptions. First, the initial value for RTO SHOULD be greater or equal to 500 ms. The exception cases for this "SHOULD" are when other mechanisms are used to derive congestion thresholds (such as the ones defined in ICE for fixed rate streams), or when STUN is used in non-Internet environments with known network capacities. In fixed-line access links, a value of 500 ms is RECOMMENDED. Second, the value of RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms accuracy SHOULD be maintained. As with TCP, the usage of Karn's algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means that RTT estimates SHOULD NOT be computed from STUN transactions that result in the retransmission of a request. The value for RTO SHOULD be cached by a client after the completion of the transaction, and used as the starting value for RTO for the next transaction to the same server (based on equality of IP address). The value SHOULD be considered stale and discarded if no transactions have occurred to the same server in the last 10 minutes. Retransmissions continue until a response is received, or until a total of Rc requests have been sent. Rc SHOULD be configurable and SHOULD have a default of 7. If, after the last request, a duration equal to Rm times the RTO has passed without a response (providing ample time to get a response if only this final request actually succeeds), the client SHOULD consider the transaction to have failed. Rm SHOULD be configurable and SHOULD have a default of 16. A STUN transaction over UDP or DTLS-over-UDP is also considered failed if there has been a hard ICMP error [RFC1122]. For example, assuming an RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response after 39500 ms, the client will consider the transaction to have timed out. Petit-Huguenin, et al. Expires September 22, 2019 [Page 14] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 6.2.2. Sending over TCP or TLS-over-TCP For TCP and TLS-over-TCP [RFC5246], the client opens a TCP connection to the server. In some usages of STUN, STUN is sent as the only protocol over the TCP connection. In this case, it can be sent without the aid of any additional framing or demultiplexing. In other usages, or with other extensions, it may be multiplexed with other data over a TCP connection. In that case, STUN MUST be run on top of some kind of framing protocol, specified by the usage or extension, which allows for the agent to extract complete STUN messages and complete application layer messages. The STUN service running on the well- known port or ports discovered through the DNS procedures in Section 8 is for STUN alone, and not for STUN multiplexed with other data. Consequently, no framing protocols are used in connections to those servers. When additional framing is utilized, the usage will specify how the client knows to apply it and what port to connect to. For example, in the case of ICE connectivity checks, this information is learned through out-of-band negotiation between client and server. Reliability of STUN over TCP and TLS-over-TCP is handled by TCP itself, and there are no retransmissions at the STUN protocol level. However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the request message, it considers the transaction to have timed out. Ti SHOULD be configurable and SHOULD have a default of 39.5s. This value has been chosen to equalize the TCP and UDP timeouts for the default initial RTO. In addition, if the client is unable to establish the TCP connection, or the TCP connection is reset or fails before a response is received, any request/response transaction in progress is considered to have failed. The client MAY send multiple transactions over a single TCP (or TLS- over-TCP) connection, and it MAY send another request before receiving a response to the previous request. The client SHOULD keep the connection open until it: o has no further STUN requests or indications to send over that connection, and o has no plans to use any resources (such as a mapped address (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address [RFC5766]) that were learned though STUN requests sent over that connection, and Petit-Huguenin, et al. Expires September 22, 2019 [Page 15] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 o if multiplexing other application protocols over that port, has finished using those other protocols, and o if using that learned port with a remote peer, has established communications with that remote peer, as is required by some TCP NAT traversal techniques (e.g., [RFC6544]). The details of an eventual keep-alive mechanism are left to each STUN Usage. In any case if a transaction fails because an idle TCP connection doesn't work anymore the client SHOULD send an RST and try to open a new TCP connection. At the server end, the server SHOULD keep the connection open, and let the client close it, unless the server has determined that the connection has timed out (for example, due to the client disconnecting from the network). Bindings learned by the client will remain valid in intervening NATs only while the connection remains open. Only the client knows how long it needs the binding. The server SHOULD NOT close a connection if a request was received over that connection for which a response was not sent. A server MUST NOT ever open a connection back towards the client in order to send a response. Servers SHOULD follow best practices regarding connection management in cases of overload. 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP When STUN is run by itself over TLS-over-TCP or DTLS-over-UDP, the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be implemented and other cipher suites MAY be implemented. Perfect Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS cipher suites. Cipher suites with known weaknesses, such as those based on (single) DES and RC4, MUST NOT be used. Implementations MUST disable TLS-level compression. These recommendations are just a part of the recommendations in [BCP195] that implementations and deployments of a STUN Usage using TLS or DTLS MUST follow. When it receives the TLS Certificate message, the client MUST verify the certificate and inspect the site identified by the certificate. If the certificate is invalid or revoked, or if it does not identify the appropriate party, the client MUST NOT send the STUN message or otherwise proceed with the STUN transaction. The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in [RFC6125], with a certificate containing an identifier of type DNS-ID or CN-ID, optionally with a Petit-Huguenin, et al. Expires September 22, 2019 [Page 16] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 wildcard character as leftmost label, but not of type SRV-ID or URI- ID. When STUN is run multiplexed with other protocols over a TLS-over-TCP connection or a DTLS-over-UDP association, the mandatory ciphersuites and TLS handling procedures operate as defined by those protocols. 6.3. Receiving a STUN Message This section specifies the processing of a STUN message. The processing specified here is for STUN messages as defined in this specification; additional rules for backwards compatibility are defined in Section 11. Those additional procedures are optional, and usages can elect to utilize them. First, a set of processing operations is applied that is independent of the class. This is followed by class-specific processing, described in the subsections that follow. When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 5. It checks that the first two bits are 0, that the magic cookie field has the correct value, that the message length is sensible, and that the method value is a supported method. It checks that the message class is allowed for the particular method. If the message class is "Success Response" or "Error Response", the agent checks that the transaction ID matches a transaction that is still in progress. If the FINGERPRINT extension is being used, the agent checks that the FINGERPRINT attribute is present and contains the correct value. If any errors are detected, the message is silently discarded. In the case when STUN is being multiplexed with another protocol, an error may indicate that this is not really a STUN message; in this case, the agent should try to parse the message as a different protocol. The STUN agent then does any checks that are required by a authentication mechanism that the usage has specified (see Section 9). Once the authentication checks are done, the STUN agent checks for unknown attributes and known-but-unexpected attributes in the message. Unknown comprehension-optional attributes MUST be ignored by the agent. Known-but-unexpected attributes SHOULD be ignored by the agent. Unknown comprehension-required attributes cause processing that depends on the message class and is described below. At this point, further processing depends on the message class of the request. Petit-Huguenin, et al. Expires September 22, 2019 [Page 17] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 6.3.1. Processing a Request If the request contains one or more unknown comprehension-required attributes, the server replies with an error response with an error code of 420 (Unknown Attribute), and includes an UNKNOWN-ATTRIBUTES attribute in the response that lists the unknown comprehension- required attributes. Otherwise the server then does any additional checking that the method or the specific usage requires. If all the checks succeed, the server formulates a success response as described below. When run over UDP or DTLS-over-UDP, a request received by the server could be the first request of a transaction, or a retransmission. The server MUST respond to retransmissions such that the following property is preserved: if the client receives the response to the retransmission and not the response that was sent to the original request, the overall state on the client and server is identical to the case where only the response to the original retransmission is received, or where both responses are received (in which case the client will use the first). The easiest way to meet this requirement is for the server to remember all transaction IDs received over UDP or DTLS-over-UDP and their corresponding responses in the last 40 seconds. However, this requires the server to hold state, and will be inappropriate for any requests which are not authenticated. Another way is to reprocess the request and recompute the response. The latter technique MUST only be applied to requests that are idempotent (a request is considered idempotent when the same request can be safely repeated without impacting the overall state of the system) and result in the same success response for the same request. The Binding method is considered to be idempotent. Note that there are certain rare network events that could cause the reflexive transport address value to change, resulting in a different mapped address in different success responses. Extensions to STUN MUST discuss the implications of request retransmissions on servers that do not store transaction state. 6.3.1.1. Forming a Success or Error Response When forming the response (success or error), the server follows the rules of Section 6. The method of the response is the same as that of the request, and the message class is either "Success Response" or "Error Response". For an error response, the server MUST add an ERROR-CODE attribute containing the error code specified in the processing above. The reason phrase is not fixed, but SHOULD be something suitable for the error code. For certain errors, additional attributes are added to Petit-Huguenin, et al. Expires September 22, 2019 [Page 18] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 the message. These attributes are spelled out in the description where the error code is specified. For example, for an error code of 420 (Unknown Attribute), the server MUST include an UNKNOWN- ATTRIBUTES attribute. Certain authentication errors also cause attributes to be added (see Section 9). Extensions may define other errors and/or additional attributes to add in error cases. If the server authenticated the request using an authentication mechanism, then the server SHOULD add the appropriate authentication attributes to the response (see Section 9). The server also adds any attributes required by the specific method or usage. In addition, the server SHOULD add a SOFTWARE attribute to the message. For the Binding method, no additional checking is required unless the usage specifies otherwise. When forming the success response, the server adds a XOR-MAPPED-ADDRESS attribute to the response, where the contents of the attribute are the source transport address of the request message. For UDP or DTLS-over-UDP this is the source IP address and source UDP port of the request message. For TCP and TLS- over-TCP, this is the source IP address and source TCP port of the TCP connection as seen by the server. 6.3.1.2. Sending the Success or Error Response The response (success or error) is sent over the same transport as the request was received on. If the request was received over UDP or DTLS-over-UDP the destination IP address and port of the response are the source IP address and port of the received request message, and the source IP address and port of the response are equal to the destination IP address and port of the received request message. If the request was received over TCP or TLS-over-TCP, the response is sent back on the same TCP connection as the request was received on. The server is allowed to send responses in a different order than it received the requests. 6.3.2. Processing an Indication If the indication contains unknown comprehension-required attributes, the indication is discarded and processing ceases. Otherwise the agent then does any additional checking that the method or the specific usage requires. If all the checks succeed, the agent then processes the indication. No response is generated for an indication. Petit-Huguenin, et al. Expires September 22, 2019 [Page 19] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 For the Binding method, no additional checking or processing is required, unless the usage specifies otherwise. The mere receipt of the message by the agent has refreshed the "bindings" in the intervening NATs. Since indications are not re-transmitted over UDP or DTLS-over-UDP (unlike requests), there is no need to handle re-transmissions of indications at the sending agent. 6.3.3. Processing a Success Response If the success response contains unknown comprehension-required attributes, the response is discarded and the transaction is considered to have failed. Otherwise the client then does any additional checking that the method or the specific usage requires. If all the checks succeed, the client then processes the success response. For the Binding method, the client checks that the XOR-MAPPED-ADDRESS attribute is present in the response. The client checks the address family specified. If it is an unsupported address family, the attribute SHOULD be ignored. If it is an unexpected but supported address family (for example, the Binding transaction was sent over IPv4, but the address family specified is IPv6), then the client MAY accept and use the value. 6.3.4. Processing an Error Response If the error response contains unknown comprehension-required attributes, or if the error response does not contain an ERROR-CODE attribute, then the transaction is simply considered to have failed. Otherwise the client then does any processing specified by the authentication mechanism (see Section 9). This may result in a new transaction attempt. The processing at this point depends on the error code, the method, and the usage; the following are the default rules: o If the error code is 300 through 399, the client SHOULD consider the transaction as failed unless the ALTERNATE-SERVER extension (Section 10) is being used. o If the error code is 400 through 499, the client declares the transaction failed; in the case of 420 (Unknown Attribute), the response should contain a UNKNOWN-ATTRIBUTES attribute that gives additional information. Petit-Huguenin, et al. Expires September 22, 2019 [Page 20] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 o If the error code is 500 through 599, the client MAY resend the request; clients that do so MUST limit the number of times they do this. Unless a specific error code specifies a different value, the number of retransmissions SHOULD be limited to 4. Any other error code causes the client to consider the transaction failed. 7. FINGERPRINT Mechanism This section describes an optional mechanism for STUN that aids in distinguishing STUN messages from packets of other protocols when the two are multiplexed on the same transport address. This mechanism is optional, and a STUN usage must describe if and when it is used. The FINGERPRINT mechanism is not backwards compatible with RFC3489, and cannot be used in environments where such compatibility is required. In some usages, STUN messages are multiplexed on the same transport address as other protocols, such as the Real Time Transport Protocol (RTP). In order to apply the processing described in Section 6, STUN messages must first be separated from the application packets. Section 5 describes three fixed fields in the STUN header that can be used for this purpose. However, in some cases, these three fixed fields may not be sufficient. When the FINGERPRINT extension is used, an agent includes the FINGERPRINT attribute in messages it sends to another agent. Section 14.7 describes the placement and value of this attribute. When the agent receives what it believes is a STUN message, then, in addition to other basic checks, the agent also checks that the message contains a FINGERPRINT attribute and that the attribute contains the correct value. Section 6.3 describes when in the overall processing of a STUN message the FINGERPRINT check is performed. This additional check helps the agent detect messages of other protocols that might otherwise seem to be STUN messages. 8. DNS Discovery of a Server This section describes an optional procedure for STUN that allows a client to use DNS to determine the IP address and port of a server. A STUN usage must describe if and when this extension is used. To use this procedure, the client must know a STUN URI [RFC7064]; the usage must also describe how the client obtains this URI. Hard- coding a STUN URI into software is NOT RECOMMENDED in case the domain name is lost or needs to change for legal or other reasons. Petit-Huguenin, et al. Expires September 22, 2019 [Page 21] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 When a client wishes to locate a STUN server on the public Internet that accepts Binding request/response transactions, the STUN URI scheme is "stun". When it wishes to locate a STUN server that accepts Binding request/response transactions over a TLS, or DTLS session, the URI scheme is "stuns". The syntax of the "stun" and "stuns" URIs are defined in Section 3.1 of [RFC7064]. STUN usages MAY define additional URI schemes. 8.1. STUN URI Scheme Semantics If the part of a "stun" URI contains an IP address, then this IP address is used directly to contact the server. A "stuns" URI containing an IP address MUST be rejected. A future STUN extension or usage may relax this requirement provided it demonstrates how to authenticate the STUN server and prevent man in the middle attacks. If the URI does not contain an IP address, the domain name contained in the part is resolved to a transport address using the SRV procedures specified in [RFC2782]. The DNS SRV service name is the content of the part. The protocol in the SRV lookup is the transport protocol the client will run STUN over: "udp" for UDP and "tcp" for TCP. The procedures of RFC 2782 are followed to determine the server to contact. RFC 2782 spells out the details of how a set of SRV records is sorted and then tried. However, RFC 2782 only states that the client should "try to connect to the (protocol, address, service)" without giving any details on what happens in the event of failure. When following these procedures, if the STUN transaction times out without receipt of a response, the client SHOULD retry the request to the next server in the ordered defined by RFC 2782. Such a retry is only possible for request/response transmissions, since indication transactions generate no response or timeout. In addition, instead of querying either the A or the AAAA resource records for a domain name, a dual-stack IPv4/IPv6 client MUST query both and try the requests with all the IP addresses received, as specified in [RFC8305]. The default port for STUN requests is 3478, for both TCP and UDP. The default port for STUN over TLS and STUN over DTLS requests is 5349. Servers can run STUN over DTLS on the same port as STUN over UDP if the server software supports determining whether the initial message is a DTLS or STUN message. Servers can run STUN over TLS on the same port as STUN over TCP if the server software supports determining whether the initial message is a TLS or STUN message. Petit-Huguenin, et al. Expires September 22, 2019 [Page 22] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Administrators of STUN servers SHOULD use these ports in their SRV records for UDP and TCP. In all cases, the port in DNS MUST reflect the one on which the server is listening. If no SRV records were found, the client performs both an A and AAAA record lookup of the domain name, as described in [RFC8305]. The result will be a list of IP addresses, each of which can be simultaneously contacted at the default port using UDP or TCP, independent of the STUN usage. For usages that require TLS, the client connects to the IP addresses using the default STUN over TLS port. For usages that require DTLS, the client connects to the IP addresses using the default STUN over DTLS port. 9. Authentication and Message-Integrity Mechanisms This section defines two mechanisms for STUN that a client and server can use to provide authentication and message integrity; these two mechanisms are known as the short-term credential mechanism and the long-term credential mechanism. These two mechanisms are optional, and each usage must specify if and when these mechanisms are used. Consequently, both clients and servers will know which mechanism (if any) to follow based on knowledge of which usage applies. For example, a STUN server on the public Internet supporting ICE would have no authentication, whereas the STUN server functionality in an agent supporting connectivity checks would utilize short-term credentials. An overview of these two mechanisms is given in Section 2. Each mechanism specifies the additional processing required to use that mechanism, extending the processing specified in Section 6. The additional processing occurs in three different places: when forming a message, when receiving a message immediately after the basic checks have been performed, and when doing the detailed processing of error responses. Note that agents MUST ignore all attributes that follow MESSAGE- INTEGRITY, with the exception of the MESSAGE-INTEGRITY-SHA256 and FINGERPRINT attributes. Similarly agents MUST ignore all attributes that follow the MESSAGE-INTEGRITY-SHA256 attribute if the MESSAGE- INTEGRITY attribute is not present, with the exception of the FINGERPRINT attribute. 9.1. Short-Term Credential Mechanism The short-term credential mechanism assumes that, prior to the STUN transaction, the client and server have used some other protocol to exchange a credential in the form of a username and password. This credential is time-limited. The time limit is defined by the usage. Petit-Huguenin, et al. Expires September 22, 2019 [Page 23] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 As an example, in the ICE usage [RFC8445], the two endpoints use out- of-band signaling to agree on a username and password, and this username and password are applicable for the duration of the media session. This credential is used to form a message-integrity check in each request and in many responses. There is no challenge and response as in the long-term mechanism; consequently, replay is limited by virtue of the time-limited nature of the credential. 9.1.1. HMAC Key For short-term credentials the HMAC key is defined as follow: key = OpaqueString(password) where the OpaqueString profile is defined in [RFC8265]. The encoding used is UTF-8 [RFC3629]. 9.1.2. Forming a Request or Indication For a request or indication message, the agent MUST include the USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes in the message unless the agent knows from an external indication which message integrity algorithm is supported by both agents. In this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST be included in addition to USERNAME. The HMAC for the MESSAGE- INTEGRITY attribute is computed as described in Section 14.5 and the HMAC for the MESSAGE-INTEGRITY-SHA256 attributes is computed as described in Section 14.6. Note that the password is never included in the request or indication. 9.1.3. Receiving a Request or Indication After the agent has done the basic processing of a message, the agent performs the checks listed below in order specified: o If the message does not contain 1) a MESSAGE-INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute and 2) a USERNAME attribute: * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 400 (Bad Request). * If the message is an indication, the agent MUST silently discard the indication. Petit-Huguenin, et al. Expires September 22, 2019 [Page 24] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 o If the USERNAME does not contain a username value currently valid within the server: * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthenticated). * If the message is an indication, the agent MUST silently discard the indication. o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the value for the message integrity as described in Section 14.6, using the password associated with the username. If the MESSAGE- INTEGRITY-SHA256 attribute is not present, then use the same password to compute the value for the message integrity as described in Section 14.5. If the resulting value does not match the contents of the corresponding attribute (MESSAGE-INTEGRITY- SHA256 or MESSAGE-INTEGRITY): * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthenticated). * If the message is an indication, the agent MUST silently discard the indication. If these checks pass, the agent continues to process the request or indication. Any response generated by a server to a request that contains a MESSAGE-INTEGRITY-SHA256 attribute MUST include the MESSAGE-INTEGRITY-SHA256 attribute, computed using the password utilized to authenticate the request. Any response generated by a server to a request that contains only a MESSAGE-INTEGRITY attribute MUST include the MESSAGE-INTEGRITY attribute, computed using the password utilized to authenticate the request. This means that only one of these attributes can appear in a response. The response MUST NOT contain the USERNAME attribute. If any of the checks fail, a server MUST NOT include a MESSAGE- INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the error response. This is because, in these failure cases, the server cannot determine the shared secret necessary to compute the MESSAGE- INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes. 9.1.4. Receiving a Response The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY- SHA256 attribute in the response. If present and if the client only sent only one of MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 Petit-Huguenin, et al. Expires September 22, 2019 [Page 25] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 attributes in the request (because of the external indication in Section 9.1.2, or this being a subsequent request as defined in Section 9.1.5) the algorithm in the response has to match otherwise the response MUST be discarded. The client then computes the message integrity over the response as defined in Section 14.5 or Section 14.6, respectively, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, respectively, the response is considered authenticated. If the value does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the processing depends on the request been sent over a reliable or an unreliable transport. If the request was sent over an unreliable transport, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue. If all the responses received are discarded then instead of signaling a timeout after ending the transaction the layer MUST signal that the integrity protection was violated. If the request was sent over a reliable transport, the response MUST be discarded and the layer MUST immediately end the transaction and signal that the integrity protection was violated. 9.1.5. Sending Subsequent Requests A client sending subsequent requests to the same server MUST send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute that matches the attribute that was received in the response to the initial request. Here same server means same IP address and port number, not just the same URI or SRV lookup result. 9.2. Long-Term Credential Mechanism The long-term credential mechanism relies on a long-term credential, in the form of a username and password that are shared between client and server. The credential is considered long-term since it is assumed that it is provisioned for a user, and remains in effect until the user is no longer a subscriber of the system, or is changed. This is basically a traditional "log-in" username and password given to users. Because these usernames and passwords are expected to be valid for extended periods of time, replay prevention is provided in the form of a digest challenge. In this mechanism, the client initially sends a request, without offering any credentials or any integrity checks. The server rejects this request, providing the user a realm (used to Petit-Huguenin, et al. Expires September 22, 2019 [Page 26] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 guide the user or agent in selection of a username and password) and a nonce. The nonce provides a limited replay protection. It is a cookie, selected by the server, and encoded in such a way as to indicate a duration of validity or client identity from which it is valid. Only the server needs to know about the internal structure of the cookie. The client retries the request, this time including its username and the realm, and echoing the nonce provided by the server. The client also includes one of the message-integrity attributes defined in this document, which provides an HMAC over the entire request, including the nonce. The server validates the nonce and checks the message integrity. If they match, the request is authenticated. If the nonce is no longer valid, it is considered "stale", and the server rejects the request, providing a new nonce. In subsequent requests to the same server, the client reuses the nonce, username, realm, and password it used previously. In this way, subsequent requests are not rejected until the nonce becomes invalid by the server, in which case the rejection provides a new nonce to the client. Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential or omit authentication and message integrity for them. To indicate that it supports this specification, a server MUST prepend the NONCE attribute value with the character string composed of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648] encoding of the 24 bit STUN Security Features as defined in Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes, with bit 0 as the most significant bit of the first byte and bit 23 as the least significant bit of the third byte. If no security features are used, then a byte array with all 24 bits set to zero MUST be encoded instead. For the remainder of this document the term "nonce cookie" will refer to the complete 13 character string prepended to the NONCE attribute value. Since the long-term credential mechanism is susceptible to offline dictionary attacks, deployments SHOULD utilize passwords that are difficult to guess. In cases where the credentials are not entered by the user, but are rather placed on a client device during device provisioning, the password SHOULD have at least 128 bits of randomness. In cases where the credentials are entered by the user, they should follow best current practices around password structure. Petit-Huguenin, et al. Expires September 22, 2019 [Page 27] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 9.2.1. Bid Down Attack Prevention This document introduces two new security features that provide the ability to choose the algorithm used for password protection as well as the ability to use an anonymous username. Both of these capabilities are optional in order to remain backwards compatible with previous versions of the STUN protocol. These new capabilities are subject to bid-down attacks whereby an attacker in the message path can remove these capabilities and force weaker security properties. To prevent these kinds of attacks from going undetected, the nonce is enhanced with additional information. The value of the "nonce cookie" will vary based on the specific STUN Security Features bit values selected. When this document makes reference to the "nonce cookie" in a section discussing a specific STUN Security Feature it is understood that the corresponding STUN Security Feature bit in the "nonce cookie" is set to 1. For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS security feature, it is implied that the "Password algorithms" bit, as defined in Section 18.1, is set to 1 in the "nonce cookie". 9.2.2. HMAC Key For long-term credentials that do not use a different algorithm, as specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes: key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password)) Where MD5 is defined in [RFC1321] and [RFC6151], and the OpaqueString profile is defined in [RFC8265]. The encoding used is UTF-8 [RFC3629]. The 16-byte key is formed by taking the MD5 hash of the result of concatenating the following five fields: (1) the username, with any quotes and trailing nulls removed, as taken from the USERNAME attribute (in which case OpaqueString has already been applied); (2) a single colon; (3) the realm, with any quotes and trailing nulls removed and after processing using OpaqueString; (4) a single colon; and (5) the password, with any trailing nulls removed and after processing using OpaqueString. For example, if the username was 'user', the realm was 'realm', and the password was 'pass', then the 16-byte HMAC key would be the result of performing an MD5 hash on the string 'user:realm:pass', the resulting hash being 0x8493fbc53ba582fb4c044c456bdc40eb. Petit-Huguenin, et al. Expires September 22, 2019 [Page 28] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP [RFC3261]. Typically, SIP systems utilizing SIP's digest authentication mechanism do not actually store the password in the database. Rather, they store a value called H(A1), which is equal to the key defined above. For example, this mechanism can be used with the authentication extensions defined in [RFC5090]. When a PASSWORD-ALGORITHM is used, the key length and algorithm to use are described in Section 18.5.1. 9.2.3. Forming a Request There are two cases when forming a request. In the first case, this is the first request from the client to the server (as identified by hostname, if the DNS procedures of Section 8 are used, else IP address if not). In the second case, the client is submitting a subsequent request once a previous request/response transaction has completed successfully. Forming a request as a consequence of a 401 or 438 error response is covered in Section 9.2.5 and is not considered a "subsequent request" and thus does not utilize the rules described in Section 9.2.3.2. The difference between a first request and a subsequent request is the presence or absence of some attributes, so omitting or including them is a MUST. 9.2.3.1. First Request If the client has not completed a successful request/response transaction with the server, it MUST omit the USERNAME, USERHASH, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, REALM, NONCE, PASSWORD- ALGORITHMS, and PASSWORD-ALGORITHM attributes. In other words, the first request is sent as if there were no authentication or message integrity applied. 9.2.3.2. Subsequent Requests Once a request/response transaction has completed, the client will have been presented a realm and nonce by the server, and selected a username and password with which it authenticated. The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it MUST include either the USERNAME or USERHASH, REALM, NONCE, and PASSWORD-ALGORITHM attributes with these cached values. It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY- SHA256 attribute, computed as described in Section 14.5 and Section 14.6 using the cached password. The choice between the two Petit-Huguenin, et al. Expires September 22, 2019 [Page 29] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 attributes depends on the attribute received in the response to the first request. 9.2.4. Receiving a Request After the server has done the basic processing of a request, it performs the checks listed below in the order specified. Note that it is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server: o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE- INTEGRITY-SHA256 attribute, the server MUST generate an error response with an error code of 401 (Unauthenticated). This response MUST include a REALM value. The response MUST include a NONCE, selected by the server. The server MUST NOT choose the same NONCE for two requests unless they have the same source IP address and port. The server MAY support alternate password algorithms, in which case it can list them in preferential order in a PASSWORD-ALGORITHMS attribute. If the server adds a PASSWORD-ALGORITHMS attribute it MUST set the STUN Security Feature "Password algorithms" bit set to 1. The server MAY support anonymous username, in which case it MUST set the STUN Security Feature "Username anonymity" bit set to 1. The response SHOULD NOT contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. Note: Reusing a NONCE for different source IP addresses or ports was not explicitly forbidden in [RFC5389]. o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- INTEGRITY-SHA256 attribute, but is missing either the USERNAME or USERHASH, REALM, or NONCE attribute, the server MUST generate an error response with an error code of 400 (Bad Request). This response SHOULD NOT include a USERNAME, USERHASH, NONCE, or REALM. The response cannot contain a MESSAGE-INTEGRITY or MESSAGE- INTEGRITY-SHA256 attribute, as the attributes required to generate them are missing. o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithms" bit set to 1, the server performs these checks in the order specified: * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, then the request is processed as though PASSWORD-ALGORITHM were MD5 (Note that if the PASSWORD- ALGORITHMS attribute is present but does not contain MD5, this will result in a 400 Bad Request in a later step below). Petit-Huguenin, et al. Expires September 22, 2019 [Page 30] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD- ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches the value sent in the response that sent this NONCE, and (3) PASSWORD-ALGORITHM matches one of the entries in PASSWORD- ALGORITHMS, the server MUST generate an error response with an error code of 400 (Bad Request). o If the NONCE is no longer valid and at the same time the MESSAGE- INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute is invalid, the server MUST generate an error response with an error code of 401. This response MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and SHOULD NOT include the USERNAME or USERHASH attribute. The NONCE attribute value MUST be valid. The response MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the previous NONCE to calculate it. o If the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce). This response MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and SHOULD NOT include the USERNAME, USERHASH attribute. The NONCE attribute value MUST be valid. The response MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the previous NONCE to calculate it. Servers can revoke nonces in order to provide additional security. See Section 5.4 of [RFC7616] for guidelines. o If the value of the USERNAME or USERHASH attribute is not valid, the server MUST generate an error response with an error code of 401 (Unauthenticated). This response MUST include a REALM value. The response MUST include a NONCE, selected by the server. The response MUST include a PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a USERNAME, USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- SHA256 attribute, using the previous key to calculate it. o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the value for the message integrity as described in Section 14.6, using the password associated with the username. Else, using the same password, compute the value for the message integrity as described in Section 14.5. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- INTEGRITY-SHA256 attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthenticated). It MUST include REALM and NONCE attributes and SHOULD NOT include the USERNAME, USERHASH, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 attribute. Petit-Huguenin, et al. Expires September 22, 2019 [Page 31] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 If these checks pass, the server continues to process the request. Any response generated by the server MUST include MESSAGE-INTEGRITY- SHA256 attribute, computed using the username and password utilized to authenticate the request, unless the request was processed as though PASSWORD-ALGORITHM was MD5 (because the request contained neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE- INTEGRITY-SHA256 attribute. The REALM, NONCE, USERNAME and USERHASH attributes SHOULD NOT be included. 9.2.5. Receiving a Response If the response is an error response with an error code of 401 (Unauthenticated) or 438 (Stale Nonce), the client MUST test if the NONCE attribute value starts with the "nonce cookie". If the test succeeds and the "nonce cookie" has the STUN Security Feature "Password algorithms" bit set to 1 but no PASSWORD-ALGORITHMS attribute is present, then the client MUST NOT retry the request with a new transaction. If the response is an error response with an error code of 401 (Unauthenticated), the client SHOULD retry the request with a new transaction. This request MUST contain a USERNAME or a USERHASH, determined by the client as the appropriate username for the REALM from the error response. If the "nonce cookie" was present and had the STUN Security Feature "Username anonymity" bit set to 1 then the USERHASH attribute MUST be used, else the USERNAME attribute MUST be used. The request MUST contain the REALM, copied from the error response. The request MUST contain the NONCE, copied from the error response. If the response contains a PASSWORD-ALGORITHMS attribute, the request MUST contain the PASSWORD-ALGORITHMS attribute with the same content. If the response contains a PASSWORD-ALGORITHMS attribute, and this attribute contains at least one algorithm that is supported by the client then the request MUST contain a PASSWORD- ALGORITHM attribute with the first algorithm supported on the list. If the response contains a PASSWORD-ALGORITHMS attribute, and this attribute does not contain any algorithm that is supported by the client, then the client MUST NOT retry the request with a new transaction. The client MUST NOT perform this retry if it is not changing the USERNAME or USERHASH or REALM or its associated password, from the previous attempt. If the response is an error response with an error code of 438 (Stale Nonce), the client MUST retry the request, using the new NONCE attribute supplied in the 438 (Stale Nonce) response. This retry MUST also include either the USERNAME or USERHASH, REALM and either the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes. Petit-Huguenin, et al. Expires September 22, 2019 [Page 32] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 For all other responses, if the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithms" bit set to 1 but PASSWORD-ALGORITHMS is not present, the response MUST be ignored. If the response is an error response with an error code of 400, and does not contains either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- SHA256 attribute then the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue. Note: In that case the 400 will never reach the application, resulting in a timeout. The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- SHA256 attribute in the response (either success or failure). If present, the client computes the message integrity over the response as defined in Section 14.5 or Section 14.6, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered authenticated. If the value does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- SHA256 were absent, the processing depends on the request been sent over a reliable or an unreliable transport. If the request was sent over an unreliable transport, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue. If all the responses received are discarded then instead of signaling a timeout after ending the transaction the layer MUST signal that the integrity protection was violated. If the request was sent over a reliable transport, the response MUST be discarded and the layer MUST immediately end the transaction and signal that the integrity protection was violated. If the response contains a PASSWORD-ALGORITHMS attribute, all the subsequent requests MUST be authenticated using MESSAGE-INTEGRITY- SHA256 only. 10. ALTERNATE-SERVER Mechanism This section describes a mechanism in STUN that allows a server to redirect a client to another server. This extension is optional, and a usage must define if and when this extension is used. The ALTERNATE-SERVER attribute carries an IP address. Petit-Huguenin, et al. Expires September 22, 2019 [Page 33] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 A server using this extension redirects a client to another server by replying to a request message with an error response message with an error code of 300 (Try Alternate). The server MUST include at least one ALTERNATE-SERVER attribute in the error response, which MUST contain an IP address of the same family as the source IP address of the request message. The server SHOULD include an additional ALTERNATE-SERVER attribute, after the mandatory one, that contains an IP address of the other family than the source IP address of the request message. The error response message MAY be authenticated; however, there are use cases for ALTERNATE-SERVER where authentication of the response is not possible or practical. If the transaction uses TLS or DTLS and if the transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute and if the server wants to redirect to a server that uses a different certificate, then it MUST include an ALTERNATE-DOMAIN attribute containing the name inside the subjectAltName of that certificate. This series of conditions on the MESSAGE-INTEGRITY-SHA256 attribute indicates that the transaction is authenticated and that the client implements this specification and therefore can process the ALTERNATE-DOMAIN attribute. A client using this extension handles a 300 (Try Alternate) error code as follows. The client looks for an ALTERNATE-SERVER attribute in the error response. If one is found, then the client considers the current transaction as failed, and reattempts the request with the server specified in the attribute, using the same transport protocol used for the previous request. That request, if authenticated, MUST utilize the same credentials that the client would have used in the request to the server that performed the redirection. If the transport protocol uses TLS or DTLS, then the client looks for an ALTERNATE-DOMAIN attribute. If the attribute is found, the domain MUST be used to validate the certificate using the recommendations in [RFC6125]. The certificate MUST contain an identifier of type DNS-ID or CN-ID, eventually with wildcards, but not of type SRV-ID or URI-ID. If the attribute is not found, the same domain that was used for the original request MUST be used to validate the certificate. If the client has been redirected to a server to which it has already sent this request within the last five minutes, it MUST ignore the redirection and consider the transaction to have failed. This prevents infinite ping-ponging between servers in case of redirection loops. 11. Backwards Compatibility with RFC 3489 In addition to the backward compatibility already described in Section 12 of [RFC5389], DTLS MUST NOT be used with [RFC3489] (also referred to as "classic STUN"). Any STUN request or indication without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST Petit-Huguenin, et al. Expires September 22, 2019 [Page 34] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 be considered invalid: all requests MUST generate a "500 Server Error" error response and indications MUST be ignored. 12. Basic Server Behavior This section defines the behavior of a basic, stand-alone STUN server. Historically, "classic STUN [RFC3489]" only defined the behavior of a server that was providing clients with server reflexive transport addresses by receiving and replying to STUN Binding requests. [RFC5389] redefined the protocol as an extensible framework and the server functionality became the sole STUN Usage defined in that document. This STUN Usage is also known as Basic STUN Server. The STUN server MUST support the Binding method. It SHOULD NOT utilize the short-term or long-term credential mechanism. This is because the work involved in authenticating the request is more than the work in simply processing it. It SHOULD NOT utilize the ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP and TCP. It MAY support STUN over TCP/TLS or STUN over UDP/DTLS; however, DTLS and TLS provide minimal security benefits in this basic mode of operation. It does not require a keep-alive mechanism because a TCP or TLS-over-TCP connection is closed after the end of the Binding transaction. It MAY utilize the FINGERPRINT mechanism but MUST NOT require it. Since the stand-alone server only runs STUN, FINGERPRINT provides no benefit. Requiring it would break compatibility with RFC 3489, and such compatibility is desirable in a stand-alone server. Stand-alone STUN servers SHOULD support backwards compatibility with [RFC3489] clients, as described in Section 11. It is RECOMMENDED that administrators of STUN servers provide DNS entries for those servers as described in Section 8. If both A and AAAA Resource Records are returned then the client can simultaneously send STUN Binding requests to the IPv4 and IPv6 addresses (as specified in [RFC8305]), as the Binding request is idempotent. Note that the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attributes that are returned will not necessarily match the address family of the server address used. A basic STUN server is not a solution for NAT traversal by itself. However, it can be utilized as part of a solution through STUN usages. This is discussed further in Section 13. Petit-Huguenin, et al. Expires September 22, 2019 [Page 35] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 13. STUN Usages STUN by itself is not a solution to the NAT traversal problem. Rather, STUN defines a tool that can be used inside a larger solution. The term "STUN usage" is used for any solution that uses STUN as a component. A STUN usage defines how STUN is actually utilized -- when to send requests, what to do with the responses, and which optional procedures defined here (or in an extension to STUN) are to be used. A usage also defines: o Which STUN methods are used. o What transports are used. If DTLS-over-UDP is used then implementing the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347] is mandatory. o What authentication and message-integrity mechanisms are used. o The considerations around manual vs. automatic key derivation for the integrity mechanism, as discussed in [RFC4107]. o What mechanisms are used to distinguish STUN messages from other messages. When STUN is run over TCP or TLS-over-TCP, a framing mechanism may be required. o How a STUN client determines the IP address and port of the STUN server. o How simultaneous use of IPv4 and IPv6 addresses (Happy Eyeballs [RFC8305]) works with non-idempotent transactions when both address families are found for the STUN server. o Whether backwards compatibility to RFC 3489 is required. o What optional attributes defined here (such as FINGERPRINT and ALTERNATE-SERVER) or in other extensions are required. o If MESSAGE-INTEGRITY-SHA256 truncation is permitted, and the limits permitted for truncation. o The keep-alive mechanism if STUN is run over TCP or TLS-over-TCP. o If Anycast addresses can be used for the server in case TCP or TLS-over-TCP, or authentication are used. Petit-Huguenin, et al. Expires September 22, 2019 [Page 36] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 In addition, any STUN usage must consider the security implications of using STUN in that usage. A number of attacks against STUN are known (see the Security Considerations section in this document), and any usage must consider how these attacks can be thwarted or mitigated. Finally, a usage must consider whether its usage of STUN is an example of the Unilateral Self-Address Fixing approach to NAT traversal, and if so, address the questions raised in RFC 3424 [RFC3424]. 14. STUN Attributes After the STUN header are zero or more attributes. Each attribute MUST be TLV encoded, with a 16-bit type, 16-bit length, and value. Each STUN attribute MUST end on a 32-bit boundary. As mentioned above, all fields in an attribute are transmitted most significant bit first. 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 (variable) .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Format of STUN Attributes The value in the length field MUST contain the length of the Value part of the attribute, prior to padding, measured in bytes. Since STUN aligns attributes on 32-bit boundaries, attributes whose content is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of padding so that its value contains a multiple of 4 bytes. The padding bits MUST be set to zero on sending and MUST be ignored by the receiver. Any attribute type MAY appear more than once in a STUN message. Unless specified otherwise, the order of appearance is significant: only the first occurrence needs to be processed by a receiver, and any duplicates MAY be ignored by a receiver. To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into two ranges. Attributes with type values between 0x0000 and 0x7FFF are comprehension-required attributes, which means that the STUN agent cannot successfully process the message unless it understands the attribute. Attributes with type values between 0x8000 and 0xFFFF are Petit-Huguenin, et al. Expires September 22, 2019 [Page 37] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 comprehension-optional attributes, which means that those attributes can be ignored by the STUN agent if it does not understand them. The set of STUN attribute types is maintained by IANA. The initial set defined by this specification is found in Section 18.3. The rest of this section describes the format of the various attributes defined in this specification. 14.1. MAPPED-ADDRESS The MAPPED-ADDRESS attribute indicates a reflexive transport address of the client. It consists of an 8-bit address family and a 16-bit port, followed by a fixed-length value representing the IP address. If the address family is IPv4, the address MUST be 32 bits. If the address family is IPv6, the address MUST be 128 bits. All fields must be in network byte order. The format of the MAPPED-ADDRESS attribute is: 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| Family | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address (32 bits or 128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Format of MAPPED-ADDRESS Attribute The address family can take on the following values: 0x01:IPv4 0x02:IPv6 The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be ignored by receivers. These bits are present for aligning parameters on natural 32-bit boundaries. This attribute is used only by servers for achieving backwards compatibility with [RFC3489] clients. Petit-Huguenin, et al. Expires September 22, 2019 [Page 38] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 14.2. XOR-MAPPED-ADDRESS The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS attribute, except that the reflexive transport address is obfuscated through the XOR function. The format of the XOR-MAPPED-ADDRESS is: 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| Family | X-Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X-Address (Variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of XOR-MAPPED-ADDRESS Attribute The Family represents the IP address family, and is encoded identically to the Family in MAPPED-ADDRESS. X-Port is computed by XOR'ing the mapped port with the most significant 16 bits of the magic cookie. If the IP address family is IPv4, X-Address is computed by XOR'ing the mapped IP address with the magic cookie. If the IP address family is IPv6, X-Address is computed by XOR'ing the mapped IP address with the concatenation of the magic cookie and the 96-bit transaction ID. In all cases, the XOR operation works on its inputs in network byte order (that is, the order they will be encoded in the message). The rules for encoding and processing the first 8 bits of the attribute's value, the rules for handling multiple occurrences of the attribute, and the rules for processing address families are the same as for MAPPED-ADDRESS. Note: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their encoding of the transport address. The former encodes the transport address by exclusive-or'ing it with the magic cookie. The latter encodes it directly in binary. RFC 3489 originally specified only MAPPED-ADDRESS. However, deployment experience found that some NATs rewrite the 32-bit binary payloads containing the NAT's public IP address, such as STUN's MAPPED-ADDRESS attribute, in the well-meaning but misguided attempt at providing a generic Application Layer Gateway (ALG) function. Such behavior interferes with the operation of STUN and also causes failure of STUN's message-integrity checking. Petit-Huguenin, et al. Expires September 22, 2019 [Page 39] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 14.3. USERNAME The USERNAME attribute is used for message integrity. It identifies the username and password combination used in the message-integrity check. The value of USERNAME is a variable-length value containing the authentication username. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 509 bytes, and MUST have been processed using the UsernameCasePreserved profile [RFC8265]. A compliant implementation MUST be able to parse UTF-8 encoded sequence of 763 or less bytes, to be compatible with [RFC5389] that mistakenly assumed up to 6 bytes per characters encoded. 14.4. USERHASH The USERHASH attribute is used as a replacement for the USERNAME attribute when username anonymity is supported. The value of USERHASH has a fixed length of 32 bytes. The username MUST have been processed using the UsernameCasePreserved profile [RFC8265] and the realm MUST have been processed using the OpaqueString profile [RFC8265] before hashing. The following is the operation that the client will perform to hash the username: userhash = SHA-256(UsernameCasePreserved(username) ":" OpaqueString(realm)) 14.5. MESSAGE-INTEGRITY The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY attribute can be present in any STUN message type. Since it uses the SHA-1 hash, the HMAC will be 20 bytes. The key for the HMAC depends on which credential mechanism is in use. Section 9.1.1 defines the key for the short-term credential mechanism and Section 9.2.2 defines the key for the long-term credential mechanism. Other credential mechanisms MUST define the key that is used for the HMAC. The text used as input to HMAC is the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. The length field of the STUN message header is adjusted to point to the end of the MESSAGE-INTEGRITY attribute. The value of the MESSAGE-INTEGRITY attribute is set to a dummy value. Petit-Huguenin, et al. Expires September 22, 2019 [Page 40] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute is filled in, and the value of the length in the STUN header is set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the length field in the STUN header must be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC over the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. Such adjustment is necessary when attributes, such as FINGERPRINT and MESSAGE-INTEGRITY-SHA256, appear after MESSAGE-INTEGRITY. See also [RFC5769] for examples of such calculations. 14.6. MESSAGE-INTEGRITY-SHA256 The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256 attribute can be present in any STUN message type. The MESSAGE- INTEGRITY-SHA256 attribute contains an initial portion of the HMAC- SHA-256 [RFC2104] of the STUN message. The value will be at most 32 bytes, but MUST be at least 16 bytes, and MUST be a multiple of 4 bytes. The value must be the full 32 bytes unless the STUN Usage explicitly specifies that truncation is allowed. STUN Usages may specify a minimum length longer than 16 bytes. The key for the HMAC depends on which credential mechanism is in use. Section 9.1.1 defines the key for the short-term credential mechanism and Section 9.2.2 defines the key for the long-term credential mechanism. Other credential mechanism MUST define the key that is used for the HMAC. The text used as input to HMAC is the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. The length field of the STUN message header is adjusted to point to the end of the MESSAGE-INTEGRITY-SHA256 attribute. The value of the MESSAGE-INTEGRITY-SHA256 attribute is set to a dummy value. Once the computation is performed, the value of the MESSAGE- INTEGRITY-SHA256 attribute is filled in, and the value of the length in the STUN header is set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY- SHA256, the length field in the STUN header must be adjusted to point to the end of the MESSAGE-INTEGRITY-SHA256 attribute prior to calculating the HMAC over the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY-SHA256. See also Appendix B.1 for examples of such calculations. Petit-Huguenin, et al. Expires September 22, 2019 [Page 41] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 14.7. FINGERPRINT The FINGERPRINT attribute MAY be present in all STUN messages. The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with the 32-bit value 0x5354554e. (The XOR operation ensures that the FINGERPRINT test will not report a false positive on a packet containing a CRC-32 generated by an application protocol.) The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which has a generator polynomial of x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1. See the sample code for the CRC-32 in Section 8 of [RFC1952]. When present, the FINGERPRINT attribute MUST be the last attribute in the message, and thus will appear after MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256. The FINGERPRINT attribute can aid in distinguishing STUN packets from packets of other protocols. See Section 7. As with MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, the CRC used in the FINGERPRINT attribute covers the length field from the STUN message header. Therefore, this value must be correct and include the CRC attribute as part of the message length, prior to computation of the CRC. When using the FINGERPRINT attribute in a message, the attribute is first placed into the message with a dummy value, then the CRC is computed, and then the value of the attribute is updated. If the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute are also present, then they must be present with the correct message- integrity value before the CRC is computed, since the CRC is done over the value of the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 attributes as well. 14.8. ERROR-CODE The ERROR-CODE attribute is used in error response messages. It contains a numeric error code value in the range of 300 to 699 plus a textual reason phrase encoded in UTF-8 [RFC3629], and is consistent in its code assignments and semantics with SIP [RFC3261] and HTTP [RFC7231]. The reason phrase is meant for diagnostic purposes, and can be anything appropriate for the error code. Recommended reason phrases for the defined error codes are included in the IANA registry for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 509 bytes when encoding them or 763 bytes when decoding them). Petit-Huguenin, et al. Expires September 22, 2019 [Page 42] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 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, should be 0 |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: ERROR-CODE Attribute To facilitate processing, the class of the error code (the hundreds digit) is encoded separately from the rest of the code, as shown in Figure 7. The Reserved bits SHOULD be 0, and are for alignment on 32-bit boundaries. Receivers MUST ignore these bits. The Class represents the hundreds digit of the error code. The value MUST be between 3 and 6. The Number represents the binary encoding of the error code modulo 100, and its value MUST be between 0 and 99. The following error codes, along with their recommended reason phrases, are defined: 300 Try Alternate: The client should contact an alternate server for this request. This error response MUST only be sent if the request included either a USERNAME or USERHASH attribute and a valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute; otherwise, it MUST NOT be sent and error code 400 (Bad Request) is suggested. This error response MUST be protected with the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE- INTEGRITY-SHA256 of this response before redirecting themselves to an alternate server. Note: Failure to generate and validate message integrity for a 300 response allows an on-path attacker to falsify a 300 response thus causing subsequent STUN messages to be sent to a victim. 400 Bad Request: The request was malformed. The client SHOULD NOT retry the request without modification from the previous attempt. The server may not be able to generate a valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 for this error, so the client MUST NOT expect a valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute on this response. 401 Unauthenticated: The request did not contain the correct credentials to proceed. The client should retry the request with proper credentials. Petit-Huguenin, et al. Expires September 22, 2019 [Page 43] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 420 Unknown Attribute: The server received a STUN packet containing a comprehension-required attribute that it did not understand. The server MUST put this unknown attribute in the UNKNOWN- ATTRIBUTE attribute of its error response. 438 Stale Nonce: The NONCE used by the client was no longer valid. The client should retry, using the NONCE provided in the response. 500 Server Error: The server has suffered a temporary error. The client should try again. 14.9. REALM The REALM attribute may be present in requests and responses. It contains text that meets the grammar for "realm-value" as described in [RFC3261] but without the double quotes and their surrounding whitespace. That is, it is an unquoted realm-value (and is therefore a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 509 bytes when encoding them and as long as 763 bytes when decoding them), and MUST have been processed using the OpaqueString profile [RFC8265]. Presence of the REALM attribute in a request indicates that long-term credentials are being used for authentication. Presence in certain error responses indicates that the server wishes the client to use a long-term credential in that realm for authentication. 14.10. NONCE The NONCE attribute may be present in requests and responses. It contains a sequence of qdtext or quoted-pair, which are defined in [RFC3261]. Note that this means that the NONCE attribute will not contain the actual surrounding quote characters. See [RFC7616], Section 5.4, for guidance on selection of nonce values in a server. It MUST be less than 128 characters (which can be as long as 509 bytes when encoding them and a long as 763 bytes when decoding them). 14.11. PASSWORD-ALGORITHMS The PASSWORD-ALGORITHMS attribute may be present in requests and responses. It contains the list of algorithms that the server can use to derive the long-term password. The set of known algorithms is maintained by IANA. The initial set defined by this specification is found in Section 18.5. Petit-Huguenin, et al. Expires September 22, 2019 [Page 44] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 The attribute contains a list of algorithm numbers and variable length parameters. The algorithm number is a 16-bit value as defined in Section 18.5. The parameters start with the length (prior to padding) of the parameters as a 16-bit value, followed by the parameters that are specific to each algorithm. The parameters are padded to a 32-bit boundary, in the same manner as an 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm 1 Parameters Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 Parameters (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 2 | Algorithm 2 Parameters Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 2 Parameter (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Figure 8: Format of PASSWORD-ALGORITHMS Attribute 14.12. PASSWORD-ALGORITHM The PASSWORD-ALGORITHM attribute is present only in requests. It contains the algorithms that the server must use to derive a key from the long-term password. The set of known algorithms is maintained by IANA. The initial set defined by this specification is found in Section 18.5. The attribute contains an algorithm number and variable length parameters. The algorithm number is a 16-bit value as defined in Section 18.5. The parameters starts with the length (prior to padding) of the parameters as a 16-bit value, followed by the parameters that are specific to the algorithm. The parameters are padded to a 32-bit boundary, in the same manner as an attribute. Similarly, the padding bits MUST be set to zero on sending and MUST be ignored by the receiver. Petit-Huguenin, et al. Expires September 22, 2019 [Page 45] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | Algorithm Parameters Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm Parameters (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Format of PASSWORD-ALGORITHM Attribute 14.13. UNKNOWN-ATTRIBUTES The UNKNOWN-ATTRIBUTES attribute is present only in an error response when the response code in the ERROR-CODE attribute is 420. The attribute contains a list of 16-bit values, each of which represents an attribute type that was not understood by the server. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 1 Type | Attribute 2 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 3 Type | Attribute 4 Type ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Format of UNKNOWN-ATTRIBUTES Attribute Note: In [RFC3489], this field was padded to 32 by duplicating the last attribute. In this version of the specification, the normal padding rules for attributes are used instead. 14.14. SOFTWARE The SOFTWARE attribute contains a textual description of the software being used by the agent sending the message. It is used by clients and servers. Its value SHOULD include manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of SOFTWARE is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 509 when encoding them and as long as 763 bytes when decoding them). 14.15. ALTERNATE-SERVER The alternate server represents an alternate transport address identifying a different STUN server that the STUN client should try. Petit-Huguenin, et al. Expires September 22, 2019 [Page 46] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a single server by IP address. 14.16. ALTERNATE-DOMAIN The alternate domain represents the domain name that is used to verify the IP address in the ALTERNATE-SERVER attribute when the transport protocol uses TLS or DTLS. The value of ALTERNATE-DOMAIN is variable length. It MUST be a valid DNS name [RFC1123] (including A-labels [RFC5890]) of 255 or less ASCII characters. 15. Operational Considerations STUN MAY be used with anycast addresses, but only with UDP and in STUN Usages where authentication is not used. 16. Security Considerations Implementations and deployments of a STUN Usage using TLS or DTLS MUST follow the recommendations in [BCP195]. Implementations and deployments of a STUN Usage using the Long-Term Credential Mechanism (Section 9.2) MUST follow the recommendations in Section 5 of [RFC7616]. 16.1. Attacks against the Protocol 16.1.1. Outside Attacks An attacker can try to modify STUN messages in transit, in order to cause a failure in STUN operation. These attacks are detected for both requests and responses through the message-integrity mechanism, using either a short-term or long-term credential. Of course, once detected, the manipulated packets will be dropped, causing the STUN transaction to effectively fail. This attack is possible only by an on-path attacker. An attacker that can observe, but not modify, STUN messages in- transit (for example, an attacker present on a shared access medium, such as Wi-Fi), can see a STUN request, and then immediately send a STUN response, typically an error response, in order to disrupt STUN processing. This attack is also prevented for messages that utilize MESSAGE-INTEGRITY. However, some error responses, those related to authentication in particular, cannot be protected by MESSAGE- INTEGRITY. When STUN itself is run over a secure transport protocol (e.g., TLS), these attacks are completely mitigated. Petit-Huguenin, et al. Expires September 22, 2019 [Page 47] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Depending on the STUN usage, these attacks may be of minimal consequence and thus do not require message integrity to mitigate. For example, when STUN is used to a basic STUN server to discover a server reflexive candidate for usage with ICE, authentication and message integrity are not required since these attacks are detected during the connectivity check phase. The connectivity checks themselves, however, require protection for proper operation of ICE overall. As described in Section 13, STUN usages describe when authentication and message integrity are needed. Since STUN uses the HMAC of a shared secret for authentication and integrity protection, it is subject to offline dictionary attacks. When authentication is utilized, it SHOULD be with a strong password that is not readily subject to offline dictionary attacks. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, which is subject to bid-down attacks by an on-path attacker that would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the MESSAGE-INTEGRITY attribute and exploiting a potential vulnerability. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. Timely removal of the support of MESSAGE-INTEGRITY in a future version of STUN is necessary. Note: The use of SHA-256 for password hashing does not meet modern standards, which are aimed at slowing down exhaustive password search by providing a relatively slow minimum time to compute the hash. Although better algorithms such as Argon2 [I-D.irtf-cfrg-argon2] are available, SHA-256 was chosen for consistency with [RFC7616]. 16.1.2. Inside Attacks A rogue client may try to launch a DoS attack against a server by sending it a large number of STUN requests. Fortunately, STUN requests can be processed statelessly by a server, making such attacks hard to launch effectively. A rogue client may use a STUN server as a reflector, sending it requests with a falsified source IP address and port. In such a case, the response would be delivered to that source IP and port. There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. This attack is mitigated by ingress source address filtering. Petit-Huguenin, et al. Expires September 22, 2019 [Page 48] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Revealing the specific software version of the agent through the SOFTWARE attribute might allow them to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make usage of the SOFTWARE attribute a configurable option. 16.1.3. Bid-Down Attacks This document adds the possibility of selecting different algorithms for protecting the confidentiality of the passwords stored on the server side when using the Long-Term Credential Mechanism, while still ensuring compatibility with MD5, which was the algorithm used in a previous version of this protocol. It works by having the server send back to the client the list of algorithms supported in a PASSWORD-ALGORITHMS attribute, and having the client send back a PASSWORD-ALGORITHM attribute containing the algorithm selected. Because the PASSWORD-ALGORITHMS attribute has to be sent in an unauthenticated response, an on-path attacker wanting to exploit an eventual vulnerability in MD5 can just strip the PASSWORD-ALGORITHMS attribute from the unprotected response, thus making the server subsequently act as if the client was implementing a previous version of this protocol. To protect against this attack and other similar bid-down attacks, the nonce is enriched with a set of security bits which indicates which security features are in use. In the case of the selection of the password algorithm the matching bit is set in the nonce returned by the server in the same response that contains the PASSWORD- ALGORITHMS attribute. Because the nonce used in subsequent authenticated transactions is verified by the server to be identical to what was originally sent, it cannot be modified by an on-path attacker. Additionally, the client is mandated to copy the received PASSWORD-ALGORITHMS attribute in the next authenticated transaction to that server. An on-path attack that removes the PASSWORD-ALGORITHMS will be detected because the client will not be able to send it back to the server in the next authenticated transaction. The client will detect that attack because the security bit is set, but the matching attribute is missing, ending the session. A client using an older version of this protocol will not send the PASSWORD-ALGORITHMS back but can only use MD5 anyway, so the attack is inconsequential. The on-path attack may also try to remove the security bit together with the PASSWORD-ALGORITHMS attribute, but the server will discover that when the next authenticated transaction contains an invalid nonce. Petit-Huguenin, et al. Expires September 22, 2019 [Page 49] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 An on-path attack that removes some algorithms from the PASSWORD- ALGORITHMS attribute will be equally defeated because that attribute will be different from the original one when the server verifies it in the subsequent authenticated transaction. Note that the bid-down protection mechanism introduced in this document is inherently limited by the fact that it is not possible to detect an attack until the server receives the second request after the 401 response. SHA-256 was chosen as the new default for password hashing for its compatibility with [RFC7616] but because SHA-256 (like MD5) is a comparatively fast algorithm, it does little to deter brute force attacks. Specifically, this means that if the user has a weak password: o An attacker who captures the server's password file can often determine the user's password and thus impersonate the user to other servers where they have used that password. Note that such an attacker can impersonate the user to the server itself without any brute force attack. o An attacker who captures a single exchange can brute force the user's password and thus potentially impersonate the user to the server and other servers where they have used the same password. A stronger (which is to say slower) algorithm, like Argon2 [I-D.irtf-cfrg-argon2], would help both of these cases, but in the case of the first attack, only after until the database entry for this user is updated to exclusively use that stronger mechanism. The bid-down defenses in this protocol prevent an attacker from forcing the client and server to complete a handshake using weaker algorithms than they jointly support, but only if the weakest joint algorithm is strong enough that it cannot be brute-forced. However, this does not defend against many attacks on those algorithms; specifically, an on-path attacker might perform a bid-down attack on a client which supported both Argon2 [I-D.irtf-cfrg-argon2] and SHA-256 for password hashing and use that to collect a MESSAGE- INTEGRITY-SHA256 value which it uses for an offline brute-force attack. This would be detected when the server receives the second request, but that does not prevent the attacker from obtaining the MESSAGE-INTEGRITY-SHA256 value. Similarly, an attack against the USERHASH mechanism will not succeed in establishing a session as the server will detect that the feature was discarded on-path, but the client would still have been convinced Petit-Huguenin, et al. Expires September 22, 2019 [Page 50] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 to send its username in clear in the USERNAME attribute, thus disclosing it to the attacker. Finally, when the bid-down protection mechanism is employed for a future upgrade of the HMAC algorithm used to protect message, it will offer only a limited protection if the current HMAC algorithm is already compromised. 16.2. Attacks Affecting the Usage This section lists attacks that might be launched against a usage of STUN. Each STUN usage must consider whether these attacks are applicable to it, and if so, discuss counter-measures. Most of the attacks in this section revolve around an attacker modifying the reflexive address learned by a STUN client through a Binding request/response transaction. Since the usage of the reflexive address is a function of the usage, the applicability and remediation of these attacks are usage-specific. In common situations, modification of the reflexive address by an on-path attacker is easy to do. Consider, for example, the common situation where STUN is run directly over UDP. In this case, an on-path attacker can modify the source IP address of the Binding request before it arrives at the STUN server. The STUN server will then return this IP address in the XOR-MAPPED-ADDRESS attribute to the client, and send the response back to that (falsified) IP address and port. If the attacker can also intercept this response, it can direct it back towards the client. Protecting against this attack by using a message-integrity check is impossible, since a message- integrity value cannot cover the source IP address, since the intervening NAT must be able to modify this value. Instead, one solution to preventing the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [RFC8445]. Other usages may use other means to prevent these attacks. 16.2.1. Attack I: Distributed DoS (DDoS) against a Target In this attack, the attacker provides one or more clients with the same faked reflexive address that points to the intended target. This will trick the STUN clients into thinking that their reflexive addresses are equal to that of the target. If the clients hand out that reflexive address in order to receive traffic on it (for example, in SIP messages), the traffic will instead be sent to the target. This attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications. However, it can only be launched against Petit-Huguenin, et al. Expires September 22, 2019 [Page 51] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 targets for which packets from the STUN server to the target pass through the attacker, limiting the cases in which it is possible. 16.2.2. Attack II: Silencing a Client In this attack, the attacker provides a STUN client with a faked reflexive address. The reflexive address it provides is a transport address that routes to nowhere. As a result, the client won't receive any of the packets it expects to receive when it hands out the reflexive address. This exploitation is not very interesting for the attacker. It impacts a single client, which is frequently not the desired target. Moreover, any attacker that can mount the attack could also deny service to the client by other means, such as preventing the client from receiving any response from the STUN server, or even a DHCP server. As with the attack in Section 16.2.1, this attack is only possible when the attacker is on path for packets sent from the STUN server towards this unused IP address. 16.2.3. Attack III: Assuming the Identity of a Client This attack is similar to attack II. However, the faked reflexive address points to the attacker itself. This allows the attacker to receive traffic that was destined for the client. 16.2.4. Attack IV: Eavesdropping In this attack, the attacker forces the client to use a reflexive address that routes to itself. It then forwards any packets it receives to the client. This attack would allow the attacker to observe all packets sent to the client. However, in order to launch the attack, the attacker must have already been able to observe packets from the client to the STUN server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe packets sent to the client. This attack is, as a result, only useful for observing traffic by attackers on the path from the client to the STUN server, but not generally on the path of packets being routed towards the client. Note that this attack can be trivially launched by the STUN server itself, so users of STUN servers should have the same level of trust in them as any other node that can insert themselves into the communication flow. 16.3. Hash Agility Plan This specification uses both HMAC-SHA256 for computation of the message integrity, sometimes in combination with HMAC-SHA1. If, at a Petit-Huguenin, et al. Expires September 22, 2019 [Page 52] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 later time, HMAC-SHA256 is found to be compromised, the following is the remedy that will be applied: o Both a new message-integrity attribute and a new STUN Security Feature bit will be allocated in a Standard Track document. The new message-integrity attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously signal to a STUN client using the Long Term Credential Mechanism that this server supports this new hash algorithm, and will prevent bid-down attacks on the new message- integrity attribute. o STUN Clients and Servers using the Short Term Credential Mechanism will need to update the external mechanism that they use to signal what message-integrity attributes are in use. The bid-down protection mechanism described in this document is new, and thus cannot currently protect against a bid-down attack that lowers the strength of the hash algorithm to HMAC-SHA1. This is why, after a transition period, a new document updating this document will assign a new STUN Security Feature bit for deprecating HMAC-SHA1. When used, this bit will signal that HMAC-SHA1 is deprecated and should no longer be used. Similarly, if SHA256 is found to be compromised, a new user-hash attribute and a new STUN Security Feature bit will be allocated in a Standards Track document. The new user-hash attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously signal to a STUN client using the Long Term Credential Mechanism that this server supports this new hash algorithm for the user-hash attribute, and will prevent bid-down attacks on the new user-hash attribute. 17. IAB Considerations The IAB has studied the problem of Unilateral Self-Address Fixing (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism ([RFC3424]). STUN can be used to perform this function using a Binding request/ response transaction if one agent is behind a NAT and the other is on the public side of the NAT. The IAB has suggested that protocols developed for this purpose document a specific set of considerations. Because some STUN usages provide UNSAF functions (such as ICE [RFC8445] ), and others do not (such as SIP Outbound [RFC5626]), answers to these considerations need to be addressed by the usages themselves. Petit-Huguenin, et al. Expires September 22, 2019 [Page 53] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 18. IANA Considerations 18.1. STUN Security Features Registry A STUN Security Feature set defines 24 bit as flags. IANA is requested to create a new registry containing the STUN Security Features that are protected by the bid-down attack prevention mechanism described in section Section 9.2.1. The initial STUN Security Features are: Bit 0: Password algorithms Bit 1: Username anonymity Bit 2-23: Unassigned Bits are assigned starting from the most significant side of the bit set, so Bit 0 is the leftmost bit and Bit 23 the rightmost bit. New Security Features are assigned by a Standards Action [RFC8126]. 18.2. STUN Methods Registry IANA is requested to update the name for method 0x002 and the reference from RFC 5389 to RFC-to-be for the following STUN methods: 0x000: (Reserved) 0x001: Binding 0x002: (Reserved; prior to [RFC5389] this was SharedSecret) 18.3. STUN Attribute Registry 18.3.1. Updated Attributes IANA is requested to update the names for attributes 0x0002, 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389 to RFC- to-be for the following STUN methods: Petit-Huguenin, et al. Expires September 22, 2019 [Page 54] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Comprehension-required range (0x0000-0x7FFF): 0x0000: (Reserved) 0x0001: MAPPED-ADDRESS 0x0002: (Reserved; prior to [RFC5389] this was RESPONSE-ADDRESS) 0x0004: (Reserved; prior to [RFC5389] this was SOURCE-ADDRESS) 0x0005: (Reserved; prior to [RFC5389] this was CHANGED-ADDRESS) 0x0006: USERNAME 0x0007: (Reserved; prior to [RFC5389] this was PASSWORD) 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000A: UNKNOWN-ATTRIBUTES 0x000B: (Reserved; prior to [RFC5389] this was REFLECTED-FROM) 0x0014: REALM 0x0015: NONCE 0x0020: XOR-MAPPED-ADDRESS Comprehension-optional range (0x8000-0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT 18.3.2. New Attributes IANA is requested to add the following attribute to the STUN Attribute Registry: Comprehension-required range (0x0000-0x7FFF): 0xXXXX: MESSAGE-INTEGRITY-SHA256 0xXXXX: PASSWORD-ALGORITHM 0xXXXX: USERHASH Comprehension-optional range (0x8000-0xFFFF) 0xXXXX: PASSWORD-ALGORITHMS 0xXXXX: ALTERNATE-DOMAIN 18.4. STUN Error Code Registry IANA is requested to update the reference from RFC 5389 to RFC-to-be for the Error Codes given in Section 14.8. IANA is requested to change the name of the 401 Error Code from "Unauthorized" to "Unauthenticated". 18.5. STUN Password Algorithm Registry IANA is requested to create a new registry for Password Algorithm. A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF. Petit-Huguenin, et al. Expires September 22, 2019 [Page 55] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 The initial Password Algorithms are: 0x0000: Reserved 0x0001: MD5 0x0002: SHA-256 0x0003-0xFFFF: Unassigned Password Algorithms in the first half of the range (0x0000 - 0x7FFF) are assigned by IETF Review [RFC8126]. Password Algorithms in the second half of the range (0x8000 - 0xFFFF) are assigned by Designated Expert [RFC8126]. 18.5.1. Password Algorithms 18.5.1.1. MD5 This password algorithm is taken from [RFC1321]. The key length is 16 bytes and the parameters value is empty. Note: This algorithm MUST only be used for compatibility with legacy systems. key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password)) 18.5.1.2. SHA-256 This password algorithm is taken from [RFC7616]. The key length is 32 bytes and the parameters value is empty. key = SHA-256(username ":" OpaqueString(realm) ":" OpaqueString(password)) 18.6. STUN UDP and TCP Port Numbers IANA is requested to update the reference from RFC 5389 to RFC-to-be for the following ports in the Service Name and Transport Protocol Port Number Registry. stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port Petit-Huguenin, et al. Expires September 22, 2019 [Page 56] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 19. Changes Since RFC 5389 This specification obsoletes [RFC5389]. This specification differs from RFC 5389 in the following ways: o Added support for DTLS-over-UDP [RFC6347]. o Made clear that the RTO is considered stale if there is no transactions with the server. o Aligned the RTO calculation with [RFC6298]. o Updated the cipher suites for TLS. o Added support for STUN URI [RFC7064]. o Added support for SHA256 message integrity. o Updated the PRECIS support to [RFC8265]. o Added protocol and registry to choose the password encryption algorithm. o Added support for anonymous username. o Added protocol and registry for preventing biddown attacks. o Sharing a NONCE is no longer permitted. o Added the possibility of using a domain name in the alternate server mechanism. o Added more C snippets. o Added test vector. 20. References 20.1. Normative References [ITU.V42.2002] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, 2002. [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", August 1987. Petit-Huguenin, et al. Expires September 22, 2019 [Page 57] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [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, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . Petit-Huguenin, et al. Expires September 22, 2019 [Page 58] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [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, . [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, . [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- Huguenin, "URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064, November 2013, . [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, . [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, STD 86, DOI 10.17487/RFC8200, July 2017, . Petit-Huguenin, et al. Expires September 22, 2019 [Page 59] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . 20.2. Informative References [BCP195] 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, . [I-D.ietf-tram-stun-pmtud] Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", draft- ietf-tram-stun-pmtud-10 (work in progress), September 2018. [I-D.irtf-cfrg-argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "The memory-hard Argon2 password hash and proof-of-work function", draft-irtf-cfrg-argon2-04 (work in progress), November 2018. [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . [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, . [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, . Petit-Huguenin, et al. Expires September 22, 2019 [Page 60] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, DOI 10.17487/RFC3489, March 2003, . [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, . [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, DOI 10.17487/RFC5090, February 2008, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, . [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, DOI 10.17487/RFC5766, April 2010, . [RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769, April 2010, . [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, DOI 10.17487/RFC5780, May 2010, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . Petit-Huguenin, et al. Expires September 22, 2019 [Page 61] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 [RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, May 2008, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . Appendix A. C Snippet to Determine STUN Message Types Given a 16-bit STUN message type value in host byte order in msg_type parameter, below are C macros to determine the STUN message types: #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) A function to convert method and class into a message type: int type(int method, int cls) { return (method & 0x1F80) << 2 | (method & 0x0070) << 1 | (method & 0x000F) | (cls & 0x0002) << 7 | (cls & 0x0001) << 4; } A function to extract the method from the message type: int method(int type) { return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1 | (type & 0x000F); } A function to extract the class from the message type: Petit-Huguenin, et al. Expires September 22, 2019 [Page 62] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 int cls(int type) { return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; } Appendix B. Test Vectors This section augments the list of test vectors defined in [RFC5769] with MESSAGE-INTEGRITY-SHA256. All the formats and definitions listed in Section 2 of [RFC5769] apply here. B.1. Sample Request with Long-Term Authentication with MESSAGE- INTEGRITY-SHA256 and USERHASH This request uses the following parameters: Username: "" (without quotes) unaffected by OpaqueString [RFC8265] processing Password: "TheMtr" and "TheMatrIX" (without quotes) respectively before and after OpaqueString processing Nonce: "obMatJos2QAAAf//499k954d6OL34oL9FSTvy64sA" (without quotes) Realm: "example.org" (without quotes) Petit-Huguenin, et al. Expires September 22, 2019 [Page 63] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 00 01 00 9c Request type and message length 21 12 a4 42 Magic cookie 78 ad 34 33 } c6 ad 72 c0 } Transaction ID 29 da 41 2e } XX XX 00 20 USERHASH attribute header 4a 3c f3 8f } ef 69 92 bd } a9 52 c6 78 } 04 17 da 0f } Userhash value (32 bytes) 24 81 94 15 } 56 9e 60 b2 } 05 c4 6e 41 } 40 7f 17 04 } 00 15 00 29 NONCE attribute header 6f 62 4d 61 } 74 4a 6f 73 } 32 41 41 41 } 43 66 2f 2f } 34 39 39 6b } Nonce value and padding (3 bytes) 39 35 34 64 } 36 4f 4c 33 } 34 6f 4c 39 } 46 53 54 76 } 79 36 34 73 } 41 00 00 00 } 00 14 00 0b REALM attribute header 65 78 61 6d } 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) 6f 72 67 00 } XX XX 00 20 MESSAGE-INTEGRITY-SHA256 attribute header c4 ec a2 b6 } 24 6f 26 be } bc 2f 77 49 } 07 c2 00 a3 } HMAC-SHA256 value 76 c7 c2 8e } b4 d1 26 60 } bb fe 9f 28 } 0e 85 71 f2 } Note: Before publication, the XX XX placeholder must be replaced by the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to be updated after this. Petit-Huguenin, et al. Expires September 22, 2019 [Page 64] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Appendix C. Release notes This section must be removed before publication as an RFC. C.1. Modifications between draft-ietf-tram-stunbis-21 and draft-ietf- tram-stunbis-20 o Final edits to clean up bid down protection text to address Eric Rescorla's DISCUSS and comments. C.2. Modifications between draft-ietf-tram-stunbis-20 and draft-ietf- tram-stunbis-19 o Updates to address Eric Rescorla's DISCUSS and comments. o Addressed nits raised by Noriyuki Torii C.3. Modifications between draft-ietf-tram-stunbis-19 and draft-ietf- tram-stunbis-18 o Updates following Adam Roach DISCUSS and comments. C.4. Modifications between draft-ietf-tram-stunbis-18 and draft-ietf- tram-stunbis-17 o Nits. C.5. Modifications between draft-ietf-tram-stunbis-17 and draft-ietf- tram-stunbis-16 o Modifications following IESG, GENART and SECDIR reviews. C.6. Modifications between draft-ietf-tram-stunbis-16 and draft-ietf- tram-stunbis-15 o Replace "failure response" with "error response". o Fix wrong section number. o Use "Username anonymity" everywhere. o Align with UTF-8 deprecation. o Fix MESSAGE-INTEGRITY-256. o Update references. o Updates in the IANA sections. Petit-Huguenin, et al. Expires September 22, 2019 [Page 65] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 o s/HMAC-SHA-1/HMAC-SHA1/, s/HMAC-SHA-256/HMAC-SHA256/, s/SHA1/SHA- 1/, and s/SHA256/SHA-256/. o Fixed definitions of STUN clients/servers. o Fixed STUN message structure definition. o Missing text. o Add text explicitly saying that responses do not have to be in the same orders than requests. o /other application/other protocol/ o Add text explicitly saying that the security feature encoding is 4 character. o Fixed discrepancy in section 9.2.3/9.2.3.1. o s/invalidate/revoke/. o Removed sentences about checking USERHASH in responses, as this should not happen. o Specify that ALTERNATE-SERVER carries an IP address. o More modifications following review... C.7. Modifications between draft-ietf-tram-stunbis-15 and draft-ietf- tram-stunbis-14 o Reverted the RFC 2119 boilerplate to what was in RFC 5389. o Reverted the V.42 reference to the 2002 version. o Updated some references. C.8. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf- tram-stunbis-13 o Reorder the paragraphs in section 9.1.4. o The realm is now processed through Opaque in section 9.2.2. o Make clear in section 9.2.4 that it is an exclusive-xor. o Removed text that implied that nonce sharing was explicitly permitted in RFC 5389. Petit-Huguenin, et al. Expires September 22, 2019 [Page 66] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 o In same section, s/username/value/ for USERCASH. o Modify the IANA requests to explicitly say that the reserved codepoints were prior to RFC 5389. C.9. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf- tram-stunbis-12 o Update references. o Fixes some text following Shepherd review. o Update co-author info. C.10. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf- tram-stunbis-11 o Clarifies the procedure to define a new hash algorithm for message-integrity. o Explain the procedure to deprecate SHA1 as message-integrity. o Added procedure for Happy Eyeballs (RFC 6555). o Added verification that Happy Eyeballs works in the STUN Usage checklist. o Add reference to Base64 RFC. o Changed co-author affiliation. C.11. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf- tram-stunbis-10 o Made clear that the same HMAC than received in response of short term credential must be used for subsequent transactions. o s/URL/URI/ o The "nonce cookie" is now mandatory to signal that SHA256 must be used in the next transaction. o s/SHA1/SHA256/ o Changed co-author affiliation. Petit-Huguenin, et al. Expires September 22, 2019 [Page 67] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 C.12. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- tram-stunbis-09 o Removed the reserved value in the security registry, as it does not make sense in a bitset. o Updated change list. o Updated the minimum truncation size for M-I-256 to 16 bytes. o Changed the truncation order to match RFC 7518. o Fixed bugs in truncation boundary text. o Stated that STUN Usages have to explicitly state that they can use truncation. o Removed truncation from the MESSAGE-INTEGRITY attribute. o Add reference to C code in RFC 1952. o Replaced RFC 2818 reference to RFC 6125. C.13. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- tram-stunbis-08 o Packets discarded in a reliable or unreliable transaction triggers an attack error instead of a timeout error. An attack error on a reliable transport is signaled immediately instead of waiting for the timeout. o Explicitly state that a received 400 response without authentication will be dropped until timeout. o Clarify the SHOULD omit/include rules in LTCM. o If the nonce and the hmac are both invalid, then a 401 is sent instead of a 438. o The 401 and 438 error response to subsequent requests may use the previous NONCE/password to authenticate, if they are still available. o Change "401 Unauthorized" to "401 Unauthenticated" o Make clear that in some cases it is impossible to add a MI or MI2 even if the text says SHOULD NOT. Petit-Huguenin, et al. Expires September 22, 2019 [Page 68] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 C.14. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- tram-stunbis-07 o Updated list of changes since RFC 5389. o More examples are automatically generated. o Message integrity truncation is fixed at a multiple of 4 bytes, because the padding will not decrease by more than this. o USERHASH contains the 32 bytes of the hash, not a character string. o Updated the example to use the USERHASH attribute and the modified NONCE attribute. o Updated ICEbis reference. C.15. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- tram-stunbis-06 o Add USERHASH attribute to carry the hashed version of the username. o Add IANA registry and nonce encoding for Security Features that need to be protected from bid-down attacks. o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support truncation limits (pending cryptographic review), C.16. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- tram-stunbis-05 o Changed I-D references to RFC references. o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233). o Added test vector for MESSAGE-INTEGRITY-SHA256. o Address additional review comments from Jonathan Lennox and Brandon Williams. C.17. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- tram-stunbis-04 o Address review comments from Jonathan Lennox and Brandon Williams. Petit-Huguenin, et al. Expires September 22, 2019 [Page 69] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 C.18. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- tram-stunbis-03 o Remove SCTP. o Remove DANE. o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/ o Remove Salted SHA256 password hash. o The RTO delay between transactions is removed. o Make clear that reusing NONCE will trigger a wasted round trip. C.19. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- tram-stunbis-02 o SCTP prefix is now 0b00000101 instead of 0x11. o Add SCTP at various places it was needed. o Update the hash agility plan to take in account HMAC-SHA-256. o Adds the bid-down attack on message-integrity in the security section. C.20. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- tram-stunbis-01 o STUN hash algorithm agility (currently only SHA-1 is allowed). o Clarify terminology, text and guidance for STUN fragmentation. o Clarify whether it's valid to share nonces across TURN allocations. o Prevent the server to allocate the same NONCE to clients with different IP address and/or different port. This prevent sharing the nonce between TURN allocations in TURN. o Add reference to draft-ietf-uta-tls-bcp o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of the ALTERNATE-SERVER after a 300 over (D)TLS. o The RTP delay between transactions applies only to parallel transactions, not to serial transactions. That prevents a 3RTT Petit-Huguenin, et al. Expires September 22, 2019 [Page 70] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 delay between the first transaction and the second transaction with long term authentication. o Add text saying ORIGIN can increase a request size beyond the MTU and so require an SCTPoUDP transport. o Move the Acknowledgments and Contributor sections to the end of the document, in accordance with RFC 7322 section 4. C.21. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- tram-stunbis-00 o Add negotiation mechanism for new password algorithms. o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. o Add support for SCTP to solve the fragmentation problem. o Merge RFC 7350: * Split the "Sending over..." sections in 3. * Add DTLS-over-UDP as transport. * Update the cipher suites and cipher/compression restrictions. * A stuns uri with an IP address is rejected. * Replace most of the RFC 3489 compatibility by a reference to the section in RFC 5389. * Update the STUN Usages list with transport applicability. o Merge RFC 7064: * DNS discovery is done from the URI. * Reorganized the text about default ports. o Add more C snippets. o Make clear that the cached RTO is discarded only if there is no new translations for 10 minutes. Petit-Huguenin, et al. Expires September 22, 2019 [Page 71] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 C.22. Modifications between draft-salgueiro-tram-stunbis-02 and draft- ietf-tram-stunbis-00 o Draft adopted as WG item. C.23. Modifications between draft-salgueiro-tram-stunbis-02 and draft- salgueiro-tram-stunbis-01 o Add definition of MESSAGE-INTEGRITY2. o Update text and reference from RFC 2988 to RFC 6298. o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix section number and make clear that the original domain name is used for the server certificate verification. This is consistent with what RFC 5922 (section 4) is doing. (Errata #2010) o Remove text transitioning from RFC 3489. o Add definition of MESSAGE-INTEGRITY2. o Update text and reference from RFC 2988 to RFC 6298. o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix section number and make clear that the original domain name is used for the server certificate verification. This is consistent with what RFC 5922 (section 4) is doing. (Errata #2010) C.24. Modifications between draft-salgueiro-tram-stunbis-01 and draft- salgueiro-tram-stunbis-00 o Restore the RFC 5389 text. o Add list of open issues. Acknowledgements Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston, Jonathan Lennox, Brandon Williams, Olle Johansson, Martin Thomson, Mihaly Meszaros, Tolga Asveren, Noriyuki Torii, Spencer Dawkins, Dale Worley, Matthew Miller, Peter Saint-Andre, Julien Elie, Mirja Petit-Huguenin, et al. Expires September 22, 2019 [Page 72] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Kuehlewind, Eric Rescorla, Ben Campbell, Adam Roach, Alexey Melnikov, and Benjamin Kaduk for the comments, suggestions, and questions that helped improve this document. The authors of RFC 5389 would like to thank Cedric Aoun, Pete Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for their comments, and Baruch Sterman and Alan Hawrylyshen for initial implementations. Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input on this work. Contributors Christian Huitema and Joel Weinberger were original co-authors of RFC 3489. Authors' Addresses Marc Petit-Huguenin Impedance Mismatch Email: marc@petit-huguenin.org Gonzalo Salgueiro Cisco 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: gsalguei@cisco.com Jonathan Rosenberg Five9 Edison, NJ US Email: jdrosen@jdrosen.net URI: http://www.jdrosen.net Dan Wing Email: dwing-ietf@fuggles.com Petit-Huguenin, et al. Expires September 22, 2019 [Page 73] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2019 Rohan Mahy Unaffiliated Email: rohan.ietf@gmail.com Philip Matthews Nokia 600 March Road Ottawa, Ontario K2K 2T6 Canada Phone: 613-784-3139 Email: philip_matthews@magma.ca Petit-Huguenin, et al. Expires September 22, 2019 [Page 74] ./draft-ietf-tram-turnbis-29.txt0000644000764400076440000071442313516765472016045 0ustar iustyiusty TRAM WG T. Reddy, Ed. Internet-Draft McAfee Obsoletes: 5766, 6156 (if approved) A. Johnston, Ed. Intended status: Standards Track Villanova University Expires: January 28, 2020 P. Matthews Alcatel-Lucent J. Rosenberg jdrosen.net July 27, 2019 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) draft-ietf-tram-turnbis-29 Abstract 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 other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes RFC 5766 and RFC 6156. 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 https://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." Reddy, et al. Expires January 28, 2020 [Page 1] Internet-Draft TURN July 2019 This Internet-Draft will expire on January 28, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 3.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 15 3.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 17 3.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 19 3.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 19 3.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 21 3.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 21 4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 22 4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 22 5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 23 6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 26 7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 26 7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 28 7.3. Receiving an Allocate Success Response . . . . . . . . . 33 7.4. Receiving an Allocate Error Response . . . . . . . . . . 34 8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 36 8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 37 8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 37 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 38 9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 40 10.1. Forming a CreatePermission Request . . . . . . . . . . . 40 10.2. Receiving a CreatePermission Request . . . . . . . . . . 40 Reddy, et al. Expires January 28, 2020 [Page 2] Internet-Draft TURN July 2019 10.3. Receiving a CreatePermission Response . . . . . . . . . 41 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 41 11.1. Forming a Send Indication . . . . . . . . . . . . . . . 41 11.2. Receiving a Send Indication . . . . . . . . . . . . . . 42 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 42 11.4. Receiving a Data Indication . . . . . . . . . . . . . . 43 11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 43 11.6. Receiving a Data Indication with an ICMP attribute . . . 44 12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 45 12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 47 12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 48 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 49 12.4. The ChannelData Message . . . . . . . . . . . . . . . . 49 12.5. Sending a ChannelData Message . . . . . . . . . . . . . 50 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 50 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 51 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 51 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 52 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 53 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 55 14. UDP-to-UDP relay . . . . . . . . . . . . . . . . . . . . . . 55 15. TCP-to-UDP relay . . . . . . . . . . . . . . . . . . . . . . 57 16. UDP-to-TCP relay . . . . . . . . . . . . . . . . . . . . . . 59 17. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 60 18. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 60 18.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 61 18.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 61 18.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 62 18.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 62 18.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 62 18.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 62 18.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 63 18.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 63 18.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 64 18.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 64 18.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 64 18.12. ADDRESS-ERROR-CODE . . . . . . . . . . . . . . . . . . . 64 18.13. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 65 19. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 66 20. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 66 21. Security Considerations . . . . . . . . . . . . . . . . . . . 75 21.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 75 21.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 75 21.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 75 21.1.3. Faked Refreshes and Permissions . . . . . . . . . . 76 21.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 76 21.1.5. Impersonating a Server . . . . . . . . . . . . . . . 77 21.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 77 Reddy, et al. Expires January 28, 2020 [Page 3] Internet-Draft TURN July 2019 21.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 78 21.2. Firewall Considerations . . . . . . . . . . . . . . . . 79 21.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 80 21.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 80 21.2.3. Running Servers on Well-Known Ports . . . . . . . . 80 21.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 80 21.3.1. DoS against TURN Server . . . . . . . . . . . . . . 81 21.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 81 21.3.3. Manipulating Other Allocations . . . . . . . . . . . 81 21.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 81 21.5. Other Considerations . . . . . . . . . . . . . . . . . . 83 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 23. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 84 24. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 85 25. Updates to RFC 6156 . . . . . . . . . . . . . . . . . . . . . 86 26. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 86 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 27.1. Normative References . . . . . . . . . . . . . . . . . . 86 27.2. Informative References . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93 1. Introduction A host behind a NAT may wish to exchange packets with other hosts, some of which may also be behind NATs. To do this, the hosts involved can use "hole punching" techniques (see [RFC5128]) in an attempt discover a direct communication path; that is, a communication path that goes from one host to another through intervening NATs and routers, but does not traverse any relays. As described in [RFC5128] and [RFC4787], hole punching techniques will fail if both hosts are behind NATs that are not well behaved. For example, if both hosts are behind NATs that have a mapping behavior of "address-dependent mapping" or "address- and port- dependent mapping" (Section 4.1 in [RFC4787]), then hole punching techniques generally fail. When a direct communication path cannot be found, it is necessary to use the services of an intermediate host that acts as a relay for the packets. This relay typically sits in the public Internet and relays packets between two hosts that both sit behind NATs. In many enterprise networks, direct UDP transmissions are not permitted between clients on the internal networks and external IP addresses. To permit media sessions in such a situation to use UDP and avoid forcing them through TCP, an Enterprise Firewall can be configured to allow UDP traffic relayed through an Enterprise relay server. WebRTC requires support for this scenario (Section 2.3.5.1 Reddy, et al. Expires January 28, 2020 [Page 4] Internet-Draft TURN July 2019 in [RFC7478]). Some users of SIP or WebRTC want IP location privacy from the remote peer. In this scenario, the client can select a relay server offering IP location privacy and only convey the relayed candidates to the peer for ICE connectivity checks (see Section 4.2.4 in [I-D.ietf-rtcweb-security]). This specification defines a protocol, called TURN, that allows a host behind a NAT (called the TURN client) to request that another host (called the TURN server) act as a relay. The client can arrange for the server to relay packets to and from certain other hosts (called peers) and can control aspects of how the relaying is done. The client does this by obtaining an IP address and port on the server, called the relayed transport address. When a peer sends a packet to the relayed transport address, the server relays the transport protocol data from the packet to the client. The data encapsulated within a message header that allows the client to know the peer from which the transport protocol data was relayed by the server. If the server receives an ICMP error packet, the server also relays certain layer 3/4 header fields from the ICMP header to the client. When the client sends a message to the server, the server identifies the remote peer from the message header and relays the message data to the intended peer. A client using TURN must have some way to communicate the relayed transport address to its peers, and to learn each peer's IP address and port (more precisely, each peer's server-reflexive transport address, see Section 3). How this is done is out of the scope of the TURN protocol. One way this might be done is for the client and peers to exchange email messages. Another way is for the client and its peers to use a special-purpose "introduction" or "rendezvous" protocol (see [RFC5128] for more details). If TURN is used with ICE [RFC8445], then the relayed transport address and the IP addresses and ports of the peers are included in the ICE candidate information that the rendezvous protocol must carry. For example, if TURN and ICE are used as part of a multimedia solution using SIP [RFC3261], then SIP serves the role of the rendezvous protocol, carrying the ICE candidate information inside the body of SIP messages [I-D.ietf-mmusic-ice-sip-sdp]. If TURN and ICE are used with some other rendezvous protocol, then ICE provides guidance on the services the rendezvous protocol must perform. Though the use of a TURN server to enable communication between two hosts behind NATs is very likely to work, it comes at a high cost to the provider of the TURN server, since the server typically needs a high-bandwidth connection to the Internet. As a consequence, it is best to use a TURN server only when a direct communication path cannot be found. When the client and a peer use ICE to determine the Reddy, et al. Expires January 28, 2020 [Page 5] Internet-Draft TURN July 2019 communication path, ICE will use hole punching techniques to search for a direct path first and only use a TURN server when a direct path cannot be found. TURN was originally invented to support multimedia sessions signaled using SIP. Since SIP supports forking, TURN supports multiple peers per relayed transport address; a feature not supported by other approaches (e.g., SOCKS [RFC1928]). However, care has been taken to make sure that TURN is suitable for other types of applications. TURN was designed as one piece in the larger ICE approach to NAT traversal. Implementors of TURN are urged to investigate ICE and seriously consider using it for their application. However, it is possible to use TURN without ICE. TURN is an extension to the STUN (Session Traversal Utilities for NAT) protocol [I-D.ietf-tram-stunbis]. Most, though not all, TURN messages are STUN-formatted messages. A reader of this document should be familiar with STUN. The TURN specification was originally published as [RFC5766], which was updated by [RFC6156] to add IPv6 support. This document supersedes and obsoletes both [RFC5766] and [RFC6156]. 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with [I-D.ietf-tram-stunbis] and the terms defined there. The following terms are used in this document: TURN: The protocol spoken between a TURN client and a TURN server. It is an extension to the STUN protocol [I-D.ietf-tram-stunbis]. The protocol allows a client to allocate and use a relayed transport address. TURN client: A STUN client that implements this specification. TURN server: A STUN server that implements this specification. It relays data between a TURN client and its peer(s). Reddy, et al. Expires January 28, 2020 [Page 6] Internet-Draft TURN July 2019 Peer: A host with which the TURN client wishes to communicate. The TURN server relays traffic between the TURN client and its peer(s). The peer does not interact with the TURN server using the protocol defined in this document; rather, the peer receives data sent by the TURN server and the peer sends data towards the TURN server. Transport Address: The combination of an IP address and a port. Host Transport Address: A transport address on a client or a peer. Server-Reflexive Transport Address: A transport address on the "external side" of a NAT. This address is allocated by the NAT to correspond to a specific host transport address. Relayed Transport Address: A transport address on the TURN server that is used for relaying packets between the client and a peer. A peer sends to this address on the TURN server, and the packet is then relayed to the client. TURN Server Transport Address: A transport address on the TURN server that is used for sending TURN messages to the server. This is the transport address that the client uses to communicate with the server. Peer Transport Address: The transport address of the peer as seen by the server. When the peer is behind a NAT, this is the peer's server-reflexive transport address. Allocation: The relayed transport address granted to a client through an Allocate request, along with related state, such as permissions and expiration timers. 5-tuple: The combination (client IP address and port, server IP address and port, and transport protocol (currently one of UDP, TCP, DTLS/UDP or TLS/TCP) used to communicate between the client and the server. The 5-tuple uniquely identifies this communication stream. The 5-tuple also uniquely identifies the Allocation on the server. Transport Protocol: The protocol above IP that carries TURN Requests, Responses, and Indications as well as providing identifiable flows using a 5-tuple. In this specification, UDP and TCP are defined as transport protocols, as well as their combination with a security layer using DTLS and TLS respectively. Channel: A channel number and associated peer transport address. Once a channel number is bound to a peer's transport address, the Reddy, et al. Expires January 28, 2020 [Page 7] Internet-Draft TURN July 2019 client and server can use the more bandwidth-efficient ChannelData message to exchange data. Permission: The IP address and transport protocol (but not the port) of a peer that is permitted to send traffic to the TURN server and have that traffic relayed to the TURN client. The TURN server will only forward traffic to its client from peers that match an existing permission. Realm: A string used to describe the server or a context within the server. The realm tells the client which username and password combination to use to authenticate requests. Nonce: A string chosen at random by the server and included in the server response. To prevent replay attacks, the server should change the nonce regularly. (D)TLS: This term is used for statements that apply to both Transport Layer Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 3. Overview of Operation This section gives an overview of the operation of TURN. It is non- normative. In a typical configuration, a TURN client is connected to a private network [RFC1918] and through one or more NATs to the public Internet. On the public Internet is a TURN server. Elsewhere in the Internet are one or more peers with which the TURN client wishes to communicate. These peers may or may not be behind one or more NATs. The client uses the server as a relay to send packets to these peers and to receive packets from these peers. Reddy, et al. Expires January 28, 2020 [Page 8] Internet-Draft TURN July 2019 Peer A Server-Reflexive +---------+ Transport Address | | 192.0.2.150:32102 | | | /| | TURN | / ^| Peer A | Client's Server | / || | Host Transport Transport | // || | Address Address | // |+---------+ 198.51.100.2:49721 192.0.2.15:3478 |+-+ // Peer A | | ||N| / Host Transport | +-+ | ||A|/ Address | | | | v|T| 203.0.113.2:49582 | | | | /+-+ +---------+| | | |+---------+ / +---------+ | || |N| || | // | | | TURN |v | | v| TURN |/ | | | Client |----|A|----------| Server |------------------| Peer B | | | | |^ | |^ ^| | | | |T|| | || || | +---------+ | || +---------+| |+---------+ | || | | | || | | +-+| | | | | | | | | Client's | Peer B Server-Reflexive Relayed Transport Transport Address Transport Address Address 192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191 Figure 1 Figure 1 shows a typical deployment. In this figure, the TURN client and the TURN server are separated by a NAT, with the client on the private side and the server on the public side of the NAT. This NAT is assumed to be a "bad" NAT; for example, it might have a mapping property of "address-and-port-dependent mapping" (see [RFC4787]). The client talks to the server from a (IP address, port) combination called the client's HOST TRANSPORT ADDRESS. (The combination of an IP address and port is called a TRANSPORT ADDRESS.) The client sends TURN messages from its host transport address to a transport address on the TURN server that is known as the TURN SERVER TRANSPORT ADDRESS. The client learns the TURN server transport address through some unspecified means (e.g., configuration), and this address is typically used by many clients simultaneously. Reddy, et al. Expires January 28, 2020 [Page 9] Internet-Draft TURN July 2019 Since the client is behind a NAT, the server sees packets from the client as coming from a transport address on the NAT itself. This address is known as the client's SERVER-REFLEXIVE transport address; packets sent by the server to the client's server-reflexive transport address will be forwarded by the NAT to the client's host transport address. The client uses TURN commands to create and manipulate an ALLOCATION on the server. An allocation is a data structure on the server. This data structure contains, amongst other things, the RELAYED TRANSPORT ADDRESS for the allocation. The relayed transport address is the transport address on the server that peers can use to have the server relay data to the client. An allocation is uniquely identified by its relayed transport address. Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the intended peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data. Since the TURN message always contains an indication of which peer the client is communicating with, the client can use a single allocation to communicate with multiple peers. When the peer is behind a NAT, then the client must identify the peer using its server-reflexive transport address rather than its host transport address. For example, to send application data to Peer A in the example above, the client must specify 192.0.2.150:32102 (Peer A's server-reflexive transport address) rather than 203.0.113.2:49582 (Peer A's host transport address). Each allocation on the server belongs to a single client and has either one or two relayed transport addresses that are used only by that allocation. Thus, when a packet arrives at a relayed transport address on the server, the server knows for which client the data is intended. The client may have multiple allocations on a server at the same time. Reddy, et al. Expires January 28, 2020 [Page 10] Internet-Draft TURN July 2019 3.1. Transports TURN, as defined in this specification, always uses UDP between the server and the peer. However, this specification allows the use of any one of UDP, TCP, Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP to carry the TURN messages between the client and the server. +----------------------------+---------------------+ | TURN client to TURN server | TURN server to peer | +----------------------------+---------------------+ | UDP | UDP | | TCP | UDP | | TLS-over-TCP | UDP | | DTLS-over-UDP | UDP | +----------------------------+---------------------+ If TCP or TLS-over-TCP is used between the client and the server, then the server will convert between these transports and UDP transport when relaying data to/from the peer. Since this version of TURN only supports UDP between the server and the peer, it is expected that most clients will prefer to use UDP between the client and the server as well. That being the case, some readers may wonder: Why also support TCP and TLS-over-TCP? TURN supports TCP transport between the client and the server because some firewalls are configured to block UDP entirely. These firewalls block UDP but not TCP, in part because TCP has properties that make the intention of the nodes being protected by the firewall more obvious to the firewall. For example, TCP has a three-way handshake that makes in clearer that the protected node really wishes to have that particular connection established, while for UDP the best the firewall can do is guess which flows are desired by using filtering rules. Also, TCP has explicit connection teardown; while for UDP, the firewall has to use timers to guess when the flow is finished. TURN supports TLS-over-TCP transport and DTLS-over-UDP transport between the client and the server because (D)TLS provides additional security properties not provided by TURN's default digest authentication; properties that some clients may wish to take advantage of. In particular, (D)TLS provides a way for the client to ascertain that it is talking to the correct server, and provides for confidentiality of TURN control messages. If (D)TLS transport is used between the TURN client and the TURN server, the cipher suites, server certificate validation and authentication of TURN server are discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis]. The guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. TURN Reddy, et al. Expires January 28, 2020 [Page 11] Internet-Draft TURN July 2019 does not require (D)TLS because the overhead of using (D)TLS is higher than that of digest authentication; for example, using (D)TLS likely means that most application data will be doubly encrypted (once by (D)TLS and once to ensure it is still encrypted in the UDP datagram). There is an extension to TURN for TCP transport between the server and the peers [RFC6062]. For this reason, allocations that use UDP between the server and the peers are known as UDP allocations, while allocations that use TCP between the server and the peers are known as TCP allocations. This specification describes only UDP allocations. In some applications for TURN, the client may send and receive packets other than TURN packets on the host transport address it uses to communicate with the server. This can happen, for example, when using TURN with ICE. In these cases, the client can distinguish TURN packets from other packets by examining the source address of the arriving packet: those arriving from the TURN server will be TURN packets. The algorithm of demultiplexing packets received from multiple protocols on the host transport address is discussed in [RFC7983]. 3.2. Allocations To create an allocation on the server, the client uses an Allocate transaction. The client sends an Allocate request to the server, and the server replies with an Allocate success response containing the allocated relayed transport address. The client can include attributes in the Allocate request that describe the type of allocation it desires (e.g., the lifetime of the allocation). Since relaying data has security implications, the server requires that the client authenticate itself, typically using STUN's long-term credential mechanism or the STUN Extension for Third-Party Authorization [RFC7635], to show that it is authorized to use the server. Once a relayed transport address is allocated, a client must keep the allocation alive. To do this, the client periodically sends a Refresh request to the server. TURN deliberately uses a different method (Refresh rather than Allocate) for refreshes to ensure that the client is informed if the allocation vanishes for some reason. The frequency of the Refresh transaction is determined by the lifetime of the allocation. The default lifetime of an allocation is 10 minutes -- this value was chosen to be long enough so that refreshing is not typically a burden on the client, while expiring allocations where the client has unexpectedly quit in a timely Reddy, et al. Expires January 28, 2020 [Page 12] Internet-Draft TURN July 2019 manner. However, the client can request a longer lifetime in the Allocate request and may modify its request in a Refresh request, and the server always indicates the actual lifetime in the response. The client must issue a new Refresh transaction within "lifetime" seconds of the previous Allocate or Refresh transaction. Once a client no longer wishes to use an allocation, it should delete the allocation using a Refresh request with a requested lifetime of 0. Both the server and client keep track of a value known as the 5-TUPLE. At the client, the 5-tuple consists of the client's host transport address, the server transport address, and the transport protocol used by the client to communicate with the server. At the server, the 5-tuple value is the same except that the client's host transport address is replaced by the client's server-reflexive address, since that is the client's address as seen by the server. Both the client and the server remember the 5-tuple used in the Allocate request. Subsequent messages between the client and the server use the same 5-tuple. In this way, the client and server know which allocation is being referred to. If the client wishes to allocate a second relayed transport address, it must create a second allocation using a different 5-tuple (e.g., by using a different client host address or port). NOTE: While the terminology used in this document refers to 5-tuples, the TURN server can store whatever identifier it likes that yields identical results. Specifically, an implementation may use a file-descriptor in place of a 5-tuple to represent a TCP connection. Reddy, et al. Expires January 28, 2020 [Page 13] Internet-Draft TURN July 2019 TURN TURN Peer Peer client server A B |-- Allocate request --------------->| | | | (invalid or missing credentials) | | | | | | | |<--------------- Allocate failure --| | | | (401 Unauthenticated) | | | | | | | |-- Allocate request --------------->| | | | (valid credentials) | | | | | | | |<---------- Allocate success resp --| | | | (192.0.2.15:50000) | | | // // // // | | | | |-- Refresh request ---------------->| | | | | | | |<----------- Refresh success resp --| | | | | | | Figure 2 In Figure 2, the client sends an Allocate request to the server with invalid or missing credentials. Since the server requires that all requests be authenticated using STUN's long-term credential mechanism, the server rejects the request with a 401 (Unauthorized) error code. The client then tries again, this time including credentials. This time, the server accepts the Allocate request and returns an Allocate success response containing (amongst other things) the relayed transport address assigned to the allocation. Sometime later, the client decides to refresh the allocation and thus sends a Refresh request to the server. The refresh is accepted and the server replies with a Refresh success response. 3.3. Permissions To ease concerns amongst enterprise IT administrators that TURN could be used to bypass corporate firewall security, TURN includes the notion of permissions. TURN permissions mimic the address-restricted filtering mechanism of NATs that comply with [RFC4787]. An allocation can have zero or more permissions. Each permission consists of an IP address and a lifetime. When the server receives a UDP datagram on the allocation's relayed transport address, it first checks the list of permissions. If the source IP address of the datagram matches a permission, the application data is relayed to the client, otherwise the UDP datagram is silently discarded. Reddy, et al. Expires January 28, 2020 [Page 14] Internet-Draft TURN July 2019 A permission expires after 5 minutes if it is not refreshed, and there is no way to explicitly delete a permission. This behavior was selected to match the behavior of a NAT that complies with [RFC4787]. The client can install or refresh a permission using either a CreatePermission request or a ChannelBind request. Using the CreatePermission request, multiple permissions can be installed or refreshed with a single request -- this is important for applications that use ICE. For security reasons, permissions can only be installed or refreshed by transactions that can be authenticated; thus, Send indications and ChannelData messages (which are used to send data to peers) do not install or refresh any permissions. Note that permissions are within the context of an allocation, so adding or expiring a permission in one allocation does not affect other allocations. 3.4. Send Mechanism There are two mechanisms for the client and peers to exchange application data using the TURN server. The first mechanism uses the Send and Data methods, the second mechanism uses channels. Common to both mechanisms is the ability of the client to communicate with multiple peers using a single allocated relayed transport address; thus, both mechanisms include a means for the client to indicate to the server which peer should receive the data, and for the server to indicate to the client which peer sent the data. The Send mechanism uses Send and Data indications. Send indications are used to send application data from the client to the server, while Data indications are used to send application data from the server to the client. When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication. In the reverse direction, UDP datagrams arriving at the relayed transport address on the TURN server are converted into Data indications and sent to the client, with the server-reflexive transport address of the peer included in an XOR-PEER-ADDRESS attribute and the data itself in a DATA attribute. Since the relayed Reddy, et al. Expires January 28, 2020 [Page 15] Internet-Draft TURN July 2019 transport address uniquely identified the allocation, the server knows which client should receive the data. Some ICMP (Internet Control Message Protocol) packets arriving at the relayed transport address on the TURN server may be converted into Data indications and sent to the client, with the transport address of the peer included in an XOR-PEER-ADDRESS attribute and the ICMP type and code in a ICMP attribute. ICMP attribute forwarding always uses Data indications containing the XOR-PEER-ADDRESS and ICMP attributes, even when using the channel mechanism to forward UDP data. Send and Data indications cannot be authenticated, since the long- term credential mechanism of STUN does not support authenticating indications. This is not as big an issue as it might first appear, since the client-to-server leg is only half of the total path to the peer. Applications that want end-to-end security should encrypt the data sent between the client and a peer. Because Send indications are not authenticated, it is possible for an attacker to send bogus Send indications to the server, which will then relay these to a peer. To partly mitigate this attack, TURN requires that the client install a permission towards a peer before sending data to it using a Send indication. The technique to fully mitigate the attack is discussed in Section 21.1.4. TURN TURN Peer Peer client server A B | | | | |-- CreatePermission req (Peer A) -->| | | |<-- CreatePermission success resp --| | | | | | | |--- Send ind (Peer A)-------------->| | | | |=== data ===>| | | | | | | |<== data ====| | |<-------------- Data ind (Peer A) --| | | | | | | | | | | |--- Send ind (Peer B)-------------->| | | | | dropped | | | | | | | |<== data ==================| | dropped | | | | | | | Figure 3 Reddy, et al. Expires January 28, 2020 [Page 16] Internet-Draft TURN July 2019 In Figure 3, the client has already created an allocation and now wishes to send data to its peers. The client first creates a permission by sending the server a CreatePermission request specifying Peer A's (server-reflexive) IP address in the XOR-PEER- ADDRESS attribute; if this was not done, the server would not relay data between the client and the server. The client then sends data to Peer A using a Send indication; at the server, the application data is extracted and forwarded in a UDP datagram to Peer A, using the relayed transport address as the source transport address. When a UDP datagram from Peer A is received at the relayed transport address, the contents are placed into a Data indication and forwarded to the client. Later, the client attempts to exchange data with Peer B; however, no permission has been installed for Peer B, so the Send indication from the client and the UDP datagram from the peer are both dropped by the server. 3.5. Channels For some applications (e.g., Voice over IP), the 36 bytes of overhead that a Send indication or Data indication adds to the application data can substantially increase the bandwidth required between the client and the server. To remedy this, TURN offers a second way for the client and server to associate data with a specific peer. This second way uses an alternate packet format known as the ChannelData message. The ChannelData message does not use the STUN header used by other TURN messages, but instead has a 4-byte header that includes a number known as a channel number. Each channel number in use is bound to a specific peer and thus serves as a shorthand for the peer's host transport address. To bind a channel to a peer, the client sends a ChannelBind request to the server, and includes an unbound channel number and the transport address of the peer. Once the channel is bound, the client can use a ChannelData message to send the server data destined for the peer. Similarly, the server can relay data from that peer towards the client using a ChannelData message. Channel bindings last for 10 minutes unless refreshed -- this lifetime was chosen to be longer than the permission lifetime. Channel bindings are refreshed by sending another ChannelBind request rebinding the channel to the peer. Like permissions (but unlike allocations), there is no way to explicitly delete a channel binding; the client must simply wait for it to time out. Reddy, et al. Expires January 28, 2020 [Page 17] Internet-Draft TURN July 2019 TURN TURN Peer Peer client server A B | | | | |-- ChannelBind req ---------------->| | | | (Peer A to 0x4001) | | | | | | | |<---------- ChannelBind succ resp --| | | | | | | |-- (0x4001) data ------------------>| | | | |=== data ===>| | | | | | | |<== data ====| | |<------------------ (0x4001) data --| | | | | | | |--- Send ind (Peer A)-------------->| | | | |=== data ===>| | | | | | | |<== data ====| | |<------------------ (0x4001) data --| | | | | | | Figure 4 Figure 4 shows the channel mechanism in use. The client has already created an allocation and now wishes to bind a channel to Peer A. To do this, the client sends a ChannelBind request to the server, specifying the transport address of Peer A and a channel number (0x4001). After that, the client can send application data encapsulated inside ChannelData messages to Peer A: this is shown as "(0x4001) data" where 0x4001 is the channel number. When the ChannelData message arrives at the server, the server transfers the data to a UDP datagram and sends it to Peer A (which is the peer bound to channel number 0x4001). In the reverse direction, when Peer A sends a UDP datagram to the relayed transport address, this UDP datagram arrives at the server on the relayed transport address assigned to the allocation. Since the UDP datagram was received from Peer A, which has a channel number assigned to it, the server encapsulates the data into a ChannelData message when sending the data to the client. Once a channel has been bound, the client is free to intermix ChannelData messages and Send indications. In the figure, the client later decides to use a Send indication rather than a ChannelData message to send additional data to Peer A. The client might decide to do this, for example, so it can use the DONT-FRAGMENT attribute (see the next section). However, once a channel is bound, the server will always use a ChannelData message, as shown in the call flow. Reddy, et al. Expires January 28, 2020 [Page 18] Internet-Draft TURN July 2019 Note that ChannelData messages can only be used for peers to which the client has bound a channel. In the example above, Peer A has been bound to a channel, but Peer B has not, so application data to and from Peer B would use the Send mechanism. 3.6. Unprivileged TURN Servers This version of TURN is designed so that the server can be implemented as an application that runs in user space under commonly available operating systems without requiring special privileges. This design decision was made to make it easy to deploy a TURN server: for example, to allow a TURN server to be integrated into a peer-to-peer application so that one peer can offer NAT traversal services to another peer and to use (D)TLS to secure the TURN connection. This design decision has the following implications for data relayed by a TURN server: o The value of the Diffserv field may not be preserved across the server; o The Time to Live (TTL) field may be reset, rather than decremented, across the server; o The Explicit Congestion Notification (ECN) field may be reset by the server; o There is no end-to-end fragmentation, since the packet is re- assembled at the server. Future work may specify alternate TURN semantics that address these limitations. 3.7. Avoiding IP Fragmentation For reasons described in [Frag-Harmful], applications, especially those sending large volumes of data, should avoid having their packets fragmented. [I-D.ietf-intarea-frag-fragile] discusses issues associated with IP fragmentation and proposes alternatives to IP fragmentation. Applications using TCP can more or less ignore this issue because fragmentation avoidance is now a standard part of TCP, but applications using UDP (and thus any application using this version of TURN) need to avoid IP fragmentation by sending sufficiently small messages or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]. Note that the UDP fragmentation option needs to be supported by both endpoints, and at the time of writing Reddy, et al. Expires January 28, 2020 [Page 19] Internet-Draft TURN July 2019 of this document, UDP fragmentation support is under discussion and is not deployed. The application running on the client and the peer can take one of two approaches to avoid IP fragmentation until UDP fragmentation support is available. The first uses messages that are limited to a predetermined fixed maximum and the second relies on network feedback to adapt that maximum. The first approach is to avoid sending large amounts of application data in the TURN messages/UDP datagrams exchanged between the client and the peer. This is the approach taken by most VoIP (Voice-over- IP) applications. In this approach, the application MUST assume a PMTU of 1280 bytes, as IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater as specified in [RFC8200]. If IPv4 support on legacy or otherwise unusual networks is a consideration, the application MAY assume an effective MTU of 576 bytes for IPv4 datagrams, as every IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes as discussed in [RFC0791] and [RFC1122]. The exact amount of application data that can be included while avoiding fragmentation depends on the details of the TURN session between the client and the server: whether UDP, TCP, or (D)TLS transport is used, whether ChannelData messages or Send/Data indications are used, and whether any additional attributes (such as the DONT-FRAGMENT attribute) are included. Another factor, which is hard to determine, is whether the MTU is reduced somewhere along the path for other reasons, such as the use of IP-in-IP tunneling. As a guideline, sending a maximum of 500 bytes of application data in a single TURN message (by the client on the client-to-server leg) or a UDP datagram (by the peer on the peer-to-server leg) will generally avoid IP fragmentation. To further reduce the chance of fragmentation, it is recommended that the client use ChannelData messages when transferring significant volumes of data, since the overhead of the ChannelData message is less than Send and Data indications. The second approach the client and peer can take to avoid fragmentation is to use a path MTU discovery algorithm to determine the maximum amount of application data that can be sent without fragmentation. The classic path MTU discovery algorithm defined in [RFC1191] may not be able to discover the MTU of the transmission path between the client and the peer since: - a probe packet with DF bit in the IPv4 header set to test a path for a larger MTU can be dropped by routers, or Reddy, et al. Expires January 28, 2020 [Page 20] Internet-Draft TURN July 2019 - ICMP error messages can be dropped by middle boxes. As a result, the client and server need to use a path MTU discovery algorithm that does not require ICMP messages. The Packetized Path MTU Discovery algorithm defined in [RFC4821] is one such algorithm. [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that uses STUN to discover the path MTU, and so might be a suitable approach to be used in conjunction with a TURN server that supports the DONT-FRAGMENT attribute. When the client includes the DONT- FRAGMENT attribute in a Send indication, this tells the server to set the DF bit in the resulting UDP datagram that it sends to the peer. Since some servers may be unable to set the DF bit, the client should also include this attribute in the Allocate request -- any server that does not support the DONT-FRAGMENT attribute will indicate this by rejecting the Allocate request. If the TURN server carrying out packet translation from IPv4-to-IPv6 is unable to access the state of Don't Fragment (DF) bit in the IPv4 header, it MUST reject the Allocate request with DONT-FRAGMENT attribute. 3.8. RTP Support One of the envisioned uses of TURN is as a relay for clients and peers wishing to exchange real-time data (e.g., voice or video) using RTP. To facilitate the use of TURN for this purpose, TURN includes some special support for older versions of RTP. Old versions of RTP [RFC3550] required that the RTP stream be on an even port number and the associated RTP Control Protocol (RTCP) stream, if present, be on the next highest port. To allow clients to work with peers that still require this, TURN allows the client to request that the server allocate a relayed transport address with an even port number, and to optionally request the server reserve the next-highest port number for a subsequent allocation. 3.9. Happy Eyeballs for TURN If an IPv4 path to reach a TURN server is found, but the TURN server's IPv6 path is not working, a dual-stack TURN client can experience a significant connection delay compared to an IPv4-only TURN client. To overcome these connection setup problems, the TURN client needs to query both A and AAAA records for the TURN server specified using a domain name and try connecting to the TURN server using both IPv6 and IPv4 addresses in a fashion similar to the Happy Eyeballs mechanism defined in [RFC8305]. The TURN client performs the following steps based on the transport protocol being used to connect to the TURN server. Reddy, et al. Expires January 28, 2020 [Page 21] Internet-Draft TURN July 2019 o For TCP or TLS-over-TCP, the results of the Happy Eyeballs procedure [RFC8305] are used by the TURN client for sending its TURN messages to the server. o For clear text UDP, send TURN Allocate requests to both IP address families as discussed in [RFC8305], without authentication information. If the TURN server requires authentication, it will send back a 401 unauthenticated response and the TURN client uses the first UDP connection on which a 401 error response is received. If a 401 error response is received from both IP address families then the TURN client can silently abandon the UDP connection on the IP address family with lower precedence. If the TURN server does not require authentication (as described in Section 9 of [RFC8155]), it is possible for both Allocate requests to succeed. In this case, the TURN client sends a Refresh with LIFETIME value of 0 on the allocation using the IP address family with lower precedence to delete the allocation. o For DTLS over UDP, initiate DTLS handshake to both IP address families as discussed in [RFC8305] and use the first DTLS session that is established. If the DTLS session is established on both IP address families then the client sends DTLS close_notify alert to terminate the DTLS session using the IP address family with lower precedence. If TURN over DTLS server has been configured to require a cookie exchange (Section 4.2 in [RFC6347]) and HelloVerifyRequest is received from the TURN servers on both IP address families then the client can silently abandon the connection on the IP address family with lower precedence. 4. Discovery of TURN server Methods of TURN server discovery, including using anycast, are described in [RFC8155]. If a host with multiple interfaces discovers a TURN server in each interface, the mechanism described in [RFC7982] can be used by the TURN client to influence the TURN server selection. The syntax of the "turn" and "turns" URIs are defined in Section 3.1 of [RFC7065]. DTLS as a transport protocol for TURN is defined in [RFC7350]. 4.1. TURN URI Scheme Semantics The "turn" and "turns" URI schemes are used to designate a TURN server (also known as a relay) on Internet hosts accessible using the TURN protocol. The TURN protocol supports sending messages over UDP, TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the "turn" scheme MUST be used otherwise. The required part of the "turn" URI denotes the TURN server host. The part, if Reddy, et al. Expires January 28, 2020 [Page 22] Internet-Draft TURN July 2019 present, denotes the port on which the TURN server is awaiting connection requests. If it is absent, the default port is 3478 for both UDP and TCP. The default port for TURN over TLS and TURN over DTLS is 5349. 5. General Behavior This section contains general TURN processing rules that apply to all TURN messages. TURN is an extension to STUN. All TURN messages, with the exception of the ChannelData message, are STUN-formatted messages. All the base processing rules described in [I-D.ietf-tram-stunbis] apply to STUN-formatted messages. This means that all the message-forming and message-processing descriptions in this document are implicitly prefixed with the rules of [I-D.ietf-tram-stunbis]. [I-D.ietf-tram-stunbis] specifies an authentication mechanism called the long-term credential mechanism. TURN servers and clients MUST implement this mechanism, and the authentication options are discussed in Section 7.2. Note that the long-term credential mechanism applies only to requests and cannot be used to authenticate indications; thus, indications in TURN are never authenticated. If the server requires requests to be authenticated, then the server's administrator MUST choose a realm value that will uniquely identify the username and password combination that the client must use, even if the client uses multiple servers under different administrations. The server's administrator MAY choose to allocate a unique username to each client, or MAY choose to allocate the same username to more than one client (for example, to all clients from the same department or company). For each Allocate request, the server SHOULD generate a new random nonce when the allocation is first attempted following the randomness recommendations in [RFC4086] and SHOULD expire the nonce at least once every hour during the lifetime of the allocation. The server uses the mechanism described in section 9.2 of [I-D.ietf-tram-stunbis] to indicate that it supports [I-D.ietf-tram-stunbis]. All requests after the initial Allocate must use the same username as that used to create the allocation, to prevent attackers from hijacking the client's allocation. Specifically, if the server requires the use of the long-term credential mechanism, and if a non- Allocate request passes authentication under this mechanism, and if the 5-tuple identifies an existing allocation, but the request does not use the same username as used to create the allocation, then the request MUST be rejected with a 441 (Wrong Credentials) error. Reddy, et al. Expires January 28, 2020 [Page 23] Internet-Draft TURN July 2019 When a TURN message arrives at the server from the client, the server uses the 5-tuple in the message to identify the associated allocation. For all TURN messages (including ChannelData) EXCEPT an Allocate request, if the 5-tuple does not identify an existing allocation, then the message MUST either be rejected with a 437 Allocation Mismatch error (if it is a request) or silently ignored (if it is an indication or a ChannelData message). A client receiving a 437 error response to a request other than Allocate MUST assume the allocation no longer exists. [I-D.ietf-tram-stunbis] defines a number of attributes, including the SOFTWARE and FINGERPRINT attributes. The client SHOULD include the SOFTWARE attribute in all Allocate and Refresh requests and MAY include it in any other requests or indications. The server SHOULD include the SOFTWARE attribute in all Allocate and Refresh responses (either success or failure) and MAY include it in other responses or indications. The client and the server MAY include the FINGERPRINT attribute in any STUN-formatted messages defined in this document. TURN does not use the backwards-compatibility mechanism described in [I-D.ietf-tram-stunbis]. TURN, as defined in this specification, supports both IPv4 and IPv6. IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6- to-IPv4 relaying. When only a single address type is desired, the REQUESTED-ADDRESS-FAMILY attribute is used 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). If both IPv4 and IPv6 are desired, the single ADDITIONAL-ADDRESS-FAMILY attribute indicates a request to the server to allocate one IPv4 and one IPv6 relay address in a single Allocate request. This saves local ports on the client and reduces the number of messages sent between the client and the TURN server. By default, TURN runs on the same ports as STUN: 3478 for TURN over UDP and TCP, and 5349 for TURN over (D)TLS. However, TURN has its own set of Service Record (SRV) names: "turn" for UDP and TCP, and "turns" for (D)TLS. Either the DNS resolution procedures or the ALTERNATE-SERVER procedures, both described in Section 7, can be used to run TURN on a different port. To ensure interoperability, a TURN server MUST support the use of UDP transport between the client and the server, and SHOULD support the use of TCP, TLS-over-TCP and DTLS-over-UDP transports. When UDP or DTLS-over-UDP transport is used between the client and the server, the client will retransmit a request if it does not receive a response within a certain timeout period. Because of this, Reddy, et al. Expires January 28, 2020 [Page 24] Internet-Draft TURN July 2019 the server may receive two (or more) requests with the same 5-tuple and same transaction id. STUN requires that the server recognize this case and treat the request as idempotent (see [I-D.ietf-tram-stunbis]). Some implementations may choose to meet this requirement by remembering all received requests and the corresponding responses for 40 seconds (Section 6.3.1 in [I-D.ietf-tram-stunbis]). Other implementations may choose to reprocess the request and arrange that such reprocessing returns essentially the same response. To aid implementors who choose the latter approach (the so-called "stateless stack approach"), this specification includes some implementation notes on how this might be done. Implementations are free to choose either approach or choose some other approach that gives the same results. To mitigate either intentional or unintentional denial-of-service attacks against the server by clients with valid usernames and passwords, it is RECOMMENDED that the server impose limits on both the number of allocations active at one time for a given username and on the amount of bandwidth those allocations can use. The server should reject new allocations that would exceed the limit on the allowed number of allocations active at one time with a 486 (Allocation Quota Exceeded) (see Section 7.2), and since UDP does not include a congestion control mechanism, it should discard application data traffic that exceeds the bandwidth quota. 6. Allocations All TURN operations revolve around allocations, and all TURN messages are associated with either a single or dual allocation. An allocation conceptually consists of the following state data: o the relayed transport address or addresses; o the 5-tuple: (client's IP address, client's port, server IP address, server port, transport protocol); o the authentication information; o the time-to-expiry for each relayed transport address; o a list of permissions for each relayed transport address; o a list of channel to peer bindings for each relayed transport address. The relayed transport address is the transport address allocated by the server for communicating with peers, while the 5-tuple describes the communication path between the client and the server. On the Reddy, et al. Expires January 28, 2020 [Page 25] Internet-Draft TURN July 2019 client, the 5-tuple uses the client's host transport address; on the server, the 5-tuple uses the client's server-reflexive transport address. The relayed transport address MUST be unique across all allocations so it can be used to uniquely identify the allocation, and an allocation in this context can be either a single or dual allocation. The authentication information (e.g., username, password, realm, and nonce) is used to both verify subsequent requests and to compute the message integrity of responses. The username, realm, and nonce values are initially those used in the authenticated Allocate request that creates the allocation, though the server can change the nonce value during the lifetime of the allocation using a 438 (Stale Nonce) reply. For security reasons, the server MUST NOT store the password explicitly and MUST store the key value, which is a cryptographic hash over the username, realm, and password (see Section 16.1.3 in [I-D.ietf-tram-stunbis]). Note that if the response contains a PASSWORD-ALGORITHMS attribute and this attribute contains both MD5 and SHA-256 algorithms, and the client also supports both the algorithms, the request MUST contain a PASSWORD-ALGORITHM attribute with the SHA-256 algorithm. The time-to-expiry is the time in seconds left until the allocation expires. Each Allocate or Refresh transaction sets this timer, which then ticks down towards 0. By default, each Allocate or Refresh transaction resets this timer to the default lifetime value of 600 seconds (10 minutes), but the client can request a different value in the Allocate and Refresh request. Allocations can only be refreshed using the Refresh request; sending data to a peer does not refresh an allocation. When an allocation expires, the state data associated with the allocation can be freed. The list of permissions is described in Section 9 and the list of channels is described in Section 12. 7. Creating an Allocation An allocation on the server is created using an Allocate transaction. 7.1. Sending an Allocate Request The client forms an Allocate request as follows. The client first picks a host transport address. It is RECOMMENDED that the client picks a currently unused transport address, typically by allowing the underlying OS to pick a currently unused port. Reddy, et al. Expires January 28, 2020 [Page 26] Internet-Draft TURN July 2019 The client then picks a transport protocol that the client supports to use between the client and the server based on the transport protocols supported by the server. Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that the client pick UDP unless it has a reason to use a different transport. One reason to pick a different transport would be that the client believes, either through configuration or discovery or by experiment, that it is unable to contact any TURN server using UDP. See Section 3.1 for more discussion. The client also picks a server transport address, which SHOULD be done as follows. The client uses one or more procedures described in [RFC8155] to discover a TURN server and uses the TURN server resolution mechanism defined in [RFC5928] and [RFC7350] to get a list of server transport addresses that can be tried to create a TURN allocation. The client MUST include a REQUESTED-TRANSPORT attribute in the request. This attribute specifies the transport protocol between the server and the peers (note that this is NOT the transport protocol that appears in the 5-tuple). In this specification, the REQUESTED- TRANSPORT type is always UDP. This attribute is included to allow future extensions to specify other protocols. If the client wishes to obtain a relayed transport address of a specific address type then it includes a REQUESTED-ADDRESS-FAMILY attribute in the request. This attribute indicates the specific address type the client wishes the TURN server to allocate. Clients MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in an Allocate request. Clients MUST NOT include a REQUESTED-ADDRESS- FAMILY attribute in an Allocate request that contains a RESERVATION- TOKEN attribute, for the reason that the server uses the previously reserved transport address corresponding to the included token and the client cannot obtain a relayed transport address of a specific address type. If the client wishes to obtain one IPv6 and one IPv4 relayed transport address then it includes an ADDITIONAL-ADDRESS-FAMILY attribute in the request. This attribute specifies that the server must allocate both address types. The attribute value in the ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- ADDRESS-FAMILY attributes in the same request. Clients MUST NOT include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request that contains a RESERVATION-TOKEN attribute. Clients MUST NOT include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request that contains an EVEN-PORT attribute with the R bit set to 1. The reason behind the restriction is if EVEN-PORT with R bit set to 1 is Reddy, et al. Expires January 28, 2020 [Page 27] Internet-Draft TURN July 2019 allowed with the ADDITIONAL-ADDRESS-FAMILY attribute, two tokens will have to be returned in success response and requires changes to the way RESERVATION-TOKEN is handled. If the client wishes the server to initialize the time-to-expiry field of the allocation to some value other than the default lifetime, then it MAY include a LIFETIME attribute specifying its desired value. This is just a hint, and the server may elect to use a different value. Note that the server will ignore requests to initialize the field to less than the default value. If the client wishes to later use the DONT-FRAGMENT attribute in one or more Send indications on this allocation, then the client SHOULD include the DONT-FRAGMENT attribute in the Allocate request. This allows the client to test whether this attribute is supported by the server. If the client requires the port number of the relayed transport address be even, the client includes the EVEN-PORT attribute. If this attribute is not included, then the port can be even or odd. By setting the R bit in the EVEN-PORT attribute to 1, the client can request that the server reserve the next highest port number (on the same IP address) for a subsequent allocation. If the R bit is 0, no such request is made. The client MAY also include a RESERVATION-TOKEN attribute in the request to ask the server to use a previously reserved port for the allocation. If the RESERVATION-TOKEN attribute is included, then the client MUST omit the EVEN-PORT attribute. Once constructed, the client sends the Allocate request on the 5-tuple. 7.2. Receiving an Allocate Request When the server receives an Allocate request, it performs the following checks: 1. The TURN server provided by the local or access network MAY allow unauthenticated request in order to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long term credentials for STUN authentication. Making STUN authentication optional and its security implications are discussed in [RFC8155]. Otherwise, the server MUST require that the request be authenticated. If the request is authenticated, the authentication MUST be done either using the long-term credential mechanism of [I-D.ietf-tram-stunbis] or the STUN Extension for Third-Party Reddy, et al. Expires January 28, 2020 [Page 28] Internet-Draft TURN July 2019 Authorization [RFC7635] unless the client and server agree to use another mechanism through some procedure outside the scope of this document. 2. The server checks if the 5-tuple is currently in use by an existing allocation. If yes, the server rejects the request with a 437 (Allocation Mismatch) error. 3. The server checks if the request contains a REQUESTED-TRANSPORT attribute. If the REQUESTED-TRANSPORT attribute is not included or is malformed, the server rejects the request with a 400 (Bad Request) error. Otherwise, if the attribute is included but specifies a protocol that is not supported by the server, the server rejects the request with a 442 (Unsupported Transport Protocol) error. 4. The request may contain a DONT-FRAGMENT attribute. If it does, but the server does not support sending UDP datagrams with the DF bit set to 1 (see Section 14 and Section 15), then the server treats the DONT-FRAGMENT attribute in the Allocate request as an unknown comprehension-required attribute. 5. The server checks if the request contains a RESERVATION-TOKEN attribute. If yes, and the request also contains an EVEN-PORT or REQUESTED-ADDRESS-FAMILY or ADDITIONAL-ADDRESS-FAMILY attribute, the server rejects the request with a 400 (Bad Request) error. Otherwise, it checks to see if the token is valid (i.e., the token is in range and has not expired and the corresponding relayed transport address is still available). If the token is not valid for some reason, the server rejects the request with a 508 (Insufficient Capacity) error. 6. The server checks if the request contains both REQUESTED- ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes. If yes, then the server rejects the request with a 400 (Bad Request) error. 7. If the server does not support the address family requested by the client in REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address family is disabled by local policy, it MUST generate an Allocate error response, and it MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code. If the REQUESTED-ADDRESS-FAMILY attribute is absent and the server does not support IPv4 address family, the server MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code. If the REQUESTED- ADDRESS-FAMILY attribute is absent and the server supports IPv4 Reddy, et al. Expires January 28, 2020 [Page 29] Internet-Draft TURN July 2019 address family, the server MUST allocate an IPv4 relayed transport address for the TURN client. 8. The server checks if the request contains an EVEN-PORT attribute with the R bit set to 1. If yes, and the request also contains an ADDITIONAL-ADDRESS-FAMILY attribute, the server rejects the request with a 400 (Bad Request) error. Otherwise, the server checks if it can satisfy the request (i.e., can allocate a relayed transport address as described below). If the server cannot satisfy the request, then the server rejects the request with a 508 (Insufficient Capacity) error. 9. The server checks if the request contains an ADDITIONAL-ADDRESS- FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4 address family), then the server rejects the request with a 400 (Bad Request) error. Otherwise, the server checks if it can allocate relayed transport addresses of both address types. If the server cannot satisfy the request, then the server rejects the request with a 508 (Insufficient Capacity) error. If the server can partially meet the request, i.e. if it can only allocate one relayed transport address of a specific address type, then it includes ADDRESS-ERROR-CODE attribute in the success response to inform the client the reason for partial failure of the request. The error code value signaled in the ADDRESS-ERROR-CODE attribute could be 440 (Address Family not Supported) or 508 (Insufficient Capacity). If the server can fully meet the request, then the server allocates one IPv4 and one IPv6 relay address, and returns an Allocate success response containing the relayed transport addresses assigned to the dual allocation in two XOR-RELAYED-ADDRESS attributes. 10. At any point, the server MAY choose to reject the request with a 486 (Allocation Quota Reached) error if it feels the client is trying to exceed some locally defined allocation quota. The server is free to define this allocation quota any way it wishes, but SHOULD define it based on the username used to authenticate the request, and not on the client's transport address. 11. Also at any point, the server MAY choose to reject the request with a 300 (Try Alternate) error if it wishes to redirect the client to a different server. The use of this error code and attribute follow the specification in [I-D.ietf-tram-stunbis]. If all the checks pass, the server creates the allocation. The 5-tuple is set to the 5-tuple from the Allocate request, while the list of permissions and the list of channels are initially empty. Reddy, et al. Expires January 28, 2020 [Page 30] Internet-Draft TURN July 2019 The server chooses a relayed transport address for the allocation as follows: o If the request contains a RESERVATION-TOKEN attribute, the server uses the previously reserved transport address corresponding to the included token (if it is still available). Note that the reservation is a server-wide reservation and is not specific to a particular allocation, since the Allocate request containing the RESERVATION-TOKEN uses a different 5-tuple than the Allocate request that made the reservation. The 5-tuple for the Allocate request containing the RESERVATION-TOKEN attribute can be any allowed 5-tuple; it can use a different client IP address and port, a different transport protocol, and even different server IP address and port (provided, of course, that the server IP address and port are ones on which the server is listening for TURN requests). o If the request contains an EVEN-PORT attribute with the R bit set to 0, then the server allocates a relayed transport address with an even port number. o If the request contains an EVEN-PORT attribute with the R bit set to 1, then the server looks for a pair of port numbers N and N+1 on the same IP address, where N is even. Port N is used in the current allocation, while the relayed transport address with port N+1 is assigned a token and reserved for a future allocation. The server MUST hold this reservation for at least 30 seconds, and MAY choose to hold longer (e.g., until the allocation with port N expires). The server then includes the token in a RESERVATION- TOKEN attribute in the success response. o Otherwise, the server allocates any available relayed transport address. In all cases, the server SHOULD only allocate ports from the range 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), unless the TURN server application knows, through some means not specified here, that other applications running on the same host as the TURN server application will not be impacted by allocating ports outside this range. This condition can often be satisfied by running the TURN server application on a dedicated machine and/or by arranging that any other applications on the machine allocate ports before the TURN server application starts. In any case, the TURN server SHOULD NOT allocate ports in the range 0 - 1023 (the Well- Known Port range) to discourage clients from using TURN to run standard services. Reddy, et al. Expires January 28, 2020 [Page 31] Internet-Draft TURN July 2019 NOTE: The use of randomized port assignments to avoid certain types of attacks is described in [RFC6056]. It is RECOMMENDED that a TURN server implement a randomized port assignment algorithm from [RFC6056]. This is especially applicable to servers that choose to pre-allocate a number of ports from the underlying OS and then later assign them to allocations; for example, a server may choose this technique to implement the EVEN- PORT attribute. The server determines the initial value of the time-to-expiry field as follows. If the request contains a LIFETIME attribute, then the server computes the minimum of the client's proposed lifetime and the server's maximum allowed lifetime. If this computed value is greater than the default lifetime, then the server uses the computed lifetime as the initial value of the time-to-expiry field. Otherwise, the server uses the default lifetime. It is RECOMMENDED that the server use a maximum allowed lifetime value of no more than 3600 seconds (1 hour). Servers that implement allocation quotas or charge users for allocations in some way may wish to use a smaller maximum allowed lifetime (perhaps as small as the default lifetime) to more quickly remove orphaned allocations (that is, allocations where the corresponding client has crashed or terminated or the client connection has been lost for some reason). Also, note that the time- to-expiry is recomputed with each successful Refresh request, and thus the value computed here applies only until the first refresh. Once the allocation is created, the server replies with a success response. The success response contains: o An XOR-RELAYED-ADDRESS attribute containing the relayed transport address or two XOR-RELAYED-ADDRESS attributes containing the relayed transport addresses. o A LIFETIME attribute containing the current value of the time-to- expiry timer. o A RESERVATION-TOKEN attribute (if a second relayed transport address was reserved). o An XOR-MAPPED-ADDRESS attribute containing the client's IP address and port (from the 5-tuple). NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response as a convenience to the client. TURN itself does not make use of this value, but clients running ICE can often need this value and can thus avoid having to do an extra Binding transaction with some STUN server to learn it. Reddy, et al. Expires January 28, 2020 [Page 32] Internet-Draft TURN July 2019 The response (either success or error) is sent back to the client on the 5-tuple. NOTE: When the Allocate request is sent over UDP, [I-D.ietf-tram-stunbis] requires that the server handle the possible retransmissions of the request so that retransmissions do not cause multiple allocations to be created. Implementations may achieve this using the so-called "stateless stack approach" as follows. To detect retransmissions when the original request was successful in creating an allocation, the server can store the transaction id that created the request with the allocation data and compare it with incoming Allocate requests on the same 5-tuple. Once such a request is detected, the server can stop parsing the request and immediately generate a success response. When building this response, the value of the LIFETIME attribute can be taken from the time-to-expiry field in the allocate state data, even though this value may differ slightly from the LIFETIME value originally returned. In addition, the server may need to store an indication of any reservation token returned in the original response, so that this may be returned in any retransmitted responses. For the case where the original request was unsuccessful in creating an allocation, the server may choose to do nothing special. Note, however, that there is a rare case where the server rejects the original request but accepts the retransmitted request (because conditions have changed in the brief intervening time period). If the client receives the first failure response, it will ignore the second (success) response and believe that an allocation was not created. An allocation created in this matter will eventually timeout, since the client will not refresh it. Furthermore, if the client later retries with the same 5-tuple but different transaction id, it will receive a 437 (Allocation Mismatch), which will cause it to retry with a different 5-tuple. The server may use a smaller maximum lifetime value to minimize the lifetime of allocations "orphaned" in this manner. 7.3. Receiving an Allocate Success Response If the client receives an Allocate success response, then it MUST check that the mapped address and the relayed transport address or addresses are part of an address family or families that the client understands and is prepared to handle. If these addresses are not part of an address family or families which the client is prepared to handle, then the client MUST delete the allocation (Section 8) and MUST NOT attempt to create another allocation on that server until it believes the mismatch has been fixed. Reddy, et al. Expires January 28, 2020 [Page 33] Internet-Draft TURN July 2019 Otherwise, the client creates its own copy of the allocation data structure to track what is happening on the server. In particular, the client needs to remember the actual lifetime received back from the server, rather than the value sent to the server in the request. The client must also remember the 5-tuple used for the request and the username and password it used to authenticate the request to ensure that it reuses them for subsequent messages. The client also needs to track the channels and permissions it establishes on the server. If the client receives an Allocate success response but with ADDRESS- ERROR-CODE attribute in the response and the error code value signaled in the ADDRESS-ERROR-CODE attribute is 440 (Address Family not Supported), the client MUST NOT retry its request for the rejected address type. If the client receives an ADDRESS-ERROR-CODE attribute in the response and the error code value signaled in the ADDRESS-ERROR-CODE attribute is 508 (Insufficient Capacity), the client SHOULD wait at least 1 minute before trying to request any more allocations on this server for the rejected address type. The client will probably wish to send the relayed transport address to peers (using some method not specified here) so the peers can communicate with it. The client may also wish to use the server- reflexive address it receives in the XOR-MAPPED-ADDRESS attribute in its ICE processing. 7.4. Receiving an Allocate Error Response If the client receives an Allocate error response, then the processing depends on the actual error code returned: o (Request timed out): There is either a problem with the server, or a problem reaching the server with the chosen transport. The client considers the current transaction as having failed but MAY choose to retry the Allocate request using a different transport (e.g., TCP instead of UDP). o 300 (Try Alternate): The server would like the client to use the server specified in the ALTERNATE-SERVER attribute instead. The client considers the current transaction as having failed, but SHOULD try the Allocate request with the alternate server before trying any other servers (e.g., other servers discovered using the DNS resolution procedures). When trying the Allocate request with the alternate server, the client follows the ALTERNATE-SERVER procedures specified in [I-D.ietf-tram-stunbis]. o 400 (Bad Request): The server believes the client's request is malformed for some reason. The client considers the current Reddy, et al. Expires January 28, 2020 [Page 34] Internet-Draft TURN July 2019 transaction as having failed. The client MAY notify the user or operator and SHOULD NOT retry the request with this server until it believes the problem has been fixed. o 401 (Unauthorized): If the client has followed the procedures of the long-term credential mechanism and still gets this error, then the server is not accepting the client's credentials. In this case, the client considers the current transaction as having failed and SHOULD notify the user or operator. The client SHOULD NOT send any further requests to this server until it believes the problem has been fixed. o 403 (Forbidden): The request is valid, but the server is refusing to perform it, likely due to administrative restrictions. The client considers the current transaction as having failed. The client MAY notify the user or operator and SHOULD NOT retry the same request with this server until it believes the problem has been fixed. o 420 (Unknown Attribute): If the client included a DONT-FRAGMENT attribute in the request and the server rejected the request with a 420 error code and listed the DONT-FRAGMENT attribute in the UNKNOWN-ATTRIBUTES attribute in the error response, then the client now knows that the server does not support the DONT- FRAGMENT attribute. The client considers the current transaction as having failed but MAY choose to retry the Allocate request without the DONT-FRAGMENT attribute. o 437 (Allocation Mismatch): This indicates that the client has picked a 5-tuple that the server sees as already in use. One way this could happen is if an intervening NAT assigned a mapped transport address that was used by another client that recently crashed. The client considers the current transaction as having failed. The client SHOULD pick another client transport address and retry the Allocate request (using a different transaction id). The client SHOULD try three different client transport addresses before giving up on this server. Once the client gives up on the server, it SHOULD NOT try to create another allocation on the server for 2 minutes. o 438 (Stale Nonce): See the procedures for the long-term credential mechanism [I-D.ietf-tram-stunbis]. o 440 (Address Family not Supported): The server does not support the address family requested by the client. If the client receives an Allocate error response with the 440 (Unsupported Address Family) error code, the client MUST NOT retry the request. Reddy, et al. Expires January 28, 2020 [Page 35] Internet-Draft TURN July 2019 o 441 (Wrong Credentials): The client should not receive this error in response to a Allocate request. The client MAY notify the user or operator and SHOULD NOT retry the same request with this server until it believes the problem has been fixed. o 442 (Unsupported Transport Address): The client should not receive this error in response to a request for a UDP allocation. The client MAY notify the user or operator and SHOULD NOT reattempt the request with this server until it believes the problem has been fixed. o 486 (Allocation Quota Reached): The server is currently unable to create any more allocations with this username. The client considers the current transaction as having failed. The client SHOULD wait at least 1 minute before trying to create any more allocations on the server. o 508 (Insufficient Capacity): The server has no more relayed transport addresses available, or has none with the requested properties, or the one that was reserved is no longer available. The client considers the current operation as having failed. If the client is using either the EVEN-PORT or the RESERVATION-TOKEN attribute, then the client MAY choose to remove or modify this attribute and try again immediately. Otherwise, the client SHOULD wait at least 1 minute before trying to create any more allocations on this server. Note that the error code values 486 and 508 indicate to a eavesdropper that several other users are using the server at this time, similar to that of the HTTP error response code 503, but does not reveal any information about the users using the TURN server. An unknown error response MUST be handled as described in [I-D.ietf-tram-stunbis]. 8. Refreshing an Allocation A Refresh transaction can be used to either (a) refresh an existing allocation and update its time-to-expiry or (b) delete an existing allocation. If a client wishes to continue using an allocation, then the client MUST refresh it before it expires. It is suggested that the client refresh the allocation roughly 1 minute before it expires. If a client no longer wishes to use an allocation, then it SHOULD explicitly delete the allocation. A client MAY refresh an allocation at any time for other reasons. Reddy, et al. Expires January 28, 2020 [Page 36] Internet-Draft TURN July 2019 8.1. Sending a Refresh Request If the client wishes to immediately delete an existing allocation, it includes a LIFETIME attribute with a value of 0. All other forms of the request refresh the allocation. When refreshing a dual allocation, the client includes REQUESTED- ADDRESS-FAMILY attribute indicating the address family type that should be refreshed. If no REQUESTED-ADDRESS-FAMILY is included then the request should be treated as applying to all current allocations. The client MUST only include a family type it previously allocated and has not yet deleted. This process can also be used to delete an allocation of a specific address type, by setting the lifetime of that refresh request to 0. Deleting a single allocation destroys any permissions or channels associated with that particular allocation; it MUST NOT affect any permissions or channels associated with allocations for the other address family. The Refresh transaction updates the time-to-expiry timer of an allocation. If the client wishes the server to set the time-to- expiry timer to something other than the default lifetime, it includes a LIFETIME attribute with the requested value. The server then computes a new time-to-expiry value in the same way as it does for an Allocate transaction, with the exception that a requested lifetime of 0 causes the server to immediately delete the allocation. 8.2. Receiving a Refresh Request When the server receives a Refresh request, it processes the request as per Section 5 plus the specific rules mentioned here. If the server receives a Refresh Request with a REQUESTED-ADDRESS- FAMILY attribute and the attribute value does not match the address family of the allocation, the server MUST reply with a 443 (Peer Address Family Mismatch) Refresh error response. The server computes a value called the "desired lifetime" as follows: if the request contains a LIFETIME attribute and the attribute value is 0, then the "desired lifetime" is 0. Otherwise, if the request contains a LIFETIME attribute, then the server computes the minimum of the client's requested lifetime and the server's maximum allowed lifetime. If this computed value is greater than the default lifetime, then the "desired lifetime" is the computed value. Otherwise, the "desired lifetime" is the default lifetime. Subsequent processing depends on the "desired lifetime" value: Reddy, et al. Expires January 28, 2020 [Page 37] Internet-Draft TURN July 2019 o If the "desired lifetime" is 0, then the request succeeds and the allocation is deleted. o If the "desired lifetime" is non-zero, then the request succeeds and the allocation's time-to-expiry is set to the "desired lifetime". If the request succeeds, then the server sends a success response containing: o A LIFETIME attribute containing the current value of the time-to- expiry timer. NOTE: A server need not do anything special to implement idempotency of Refresh requests over UDP using the "stateless stack approach". Retransmitted Refresh requests with a non-zero "desired lifetime" will simply refresh the allocation. A retransmitted Refresh request with a zero "desired lifetime" will cause a 437 (Allocation Mismatch) response if the allocation has already been deleted, but the client will treat this as equivalent to a success response (see below). 8.3. Receiving a Refresh Response If the client receives a success response to its Refresh request with a non-zero lifetime, it updates its copy of the allocation data structure with the time-to-expiry value contained in the response. If the client receives a 437 (Allocation Mismatch) error response to its request to refresh the allocation, it should consider the allocation no longer exists. If the client receives a 438 (Stale Nonce) error to its request to refresh the allocation, it should reattempt the request with the new nonce value. If the client receives a 437 (Allocation Mismatch) error response to a request to delete the allocation, then the allocation no longer exists and it should consider its request as having effectively succeeded. 9. Permissions For each allocation, the server keeps a list of zero or more permissions. Each permission consists of an IP address and an associated time-to-expiry. While a permission exists, all peers using the IP address in the permission are allowed to send data to the client. The time-to-expiry is the number of seconds until the permission expires. Within the context of an allocation, a permission is uniquely identified by its associated IP address. Reddy, et al. Expires January 28, 2020 [Page 38] Internet-Draft TURN July 2019 By sending either CreatePermission requests or ChannelBind requests, the client can cause the server to install or refresh a permission for a given IP address. This causes one of two things to happen: o If no permission for that IP address exists, then a permission is created with the given IP address and a time-to-expiry equal to Permission Lifetime. o If a permission for that IP address already exists, then the time- to-expiry for that permission is reset to Permission Lifetime. The Permission Lifetime MUST be 300 seconds (= 5 minutes). Each permission's time-to-expiry decreases down once per second until it reaches 0; at which point, the permission expires and is deleted. CreatePermission and ChannelBind requests may be freely intermixed on a permission. A given permission may be initially installed and/or refreshed with a CreatePermission request, and then later refreshed with a ChannelBind request, or vice versa. When a UDP datagram arrives at the relayed transport address for the allocation, the server extracts the source IP address from the IP header. The server then compares this address with the IP address associated with each permission in the list of permissions for the allocation. Note that only addresses are compared and port numbers are not considered. If no match is found, relaying is not permitted, and the server silently discards the UDP datagram. If an exact match is found, the permission check is considered to have succeeded and the server continues to process the UDP datagram as specified elsewhere (Section 11.3). The permissions for one allocation are totally unrelated to the permissions for a different allocation. If an allocation expires, all its permissions expire with it. NOTE: Though TURN permissions expire after 5 minutes, many NATs deployed at the time of publication expire their UDP bindings considerably faster. Thus, an application using TURN will probably wish to send some sort of keep-alive traffic at a much faster rate. Applications using ICE should follow the keep-alive guidelines of ICE [RFC8445], and applications not using ICE are advised to do something similar. Reddy, et al. Expires January 28, 2020 [Page 39] Internet-Draft TURN July 2019 10. CreatePermission TURN supports two ways for the client to install or refresh permissions on the server. This section describes one way: the CreatePermission request. A CreatePermission request may be used in conjunction with either the Send mechanism in Section 11 or the Channel mechanism in Section 12. 10.1. Forming a CreatePermission Request The client who wishes to install or refresh one or more permissions can send a CreatePermission request to the server. When forming a CreatePermission request, the client MUST include at least one XOR-PEER-ADDRESS attribute, and MAY include more than one such attribute. The IP address portion of each XOR-PEER-ADDRESS attribute contains the IP address for which a permission should be installed or refreshed. The port portion of each XOR-PEER-ADDRESS attribute will be ignored and can be any arbitrary value. The various XOR-PEER-ADDRESS attributes MAY appear in any order. The client MUST only include XOR-PEER-ADDRESS attributes with addresses of the same address family as that of the relayed transport address for the allocation. For dual allocations obtained using the ADDITIONAL-ADDRESS-FAMILY attribute, the client MAY include XOR-PEER- ADDRESS attributes with addresses of IPv4 and IPv6 address families. 10.2. Receiving a CreatePermission Request When the server receives the CreatePermission request, it processes as per Section 5 plus the specific rules mentioned here. The message is checked for validity. The CreatePermission request MUST contain at least one XOR-PEER-ADDRESS attribute and MAY contain multiple such attributes. If no such attribute exists, or if any of these attributes are invalid, then a 400 (Bad Request) error is returned. If the request is valid, but the server is unable to satisfy the request due to some capacity limit or similar, then a 508 (Insufficient Capacity) error is returned. If an XOR-PEER-ADDRESS attribute contains an address of an address family that is not the same as that of a relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code. The server MAY impose restrictions on the IP address allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error. Reddy, et al. Expires January 28, 2020 [Page 40] Internet-Draft TURN July 2019 If the message is valid and the server is capable of carrying out the request, then the server installs or refreshes a permission for the IP address contained in each XOR-PEER-ADDRESS attribute as described in Section 9. The port portion of each attribute is ignored and may be any arbitrary value. The server then responds with a CreatePermission success response. There are no mandatory attributes in the success response. NOTE: A server need not do anything special to implement idempotency of CreatePermission requests over UDP using the "stateless stack approach". Retransmitted CreatePermission requests will simply refresh the permissions. 10.3. Receiving a CreatePermission Response If the client receives a valid CreatePermission success response, then the client updates its data structures to indicate that the permissions have been installed or refreshed. 11. Send and Data Methods TURN supports two mechanisms for sending and receiving data from peers. This section describes the use of the Send and Data mechanisms, while Section 12 describes the use of the Channel mechanism. 11.1. Forming a Send Indication The client can use a Send indication to pass data to the server for relaying to a peer. A client may use a Send indication even if a channel is bound to that peer. However, the client MUST ensure that there is a permission installed for the IP address of the peer to which the Send indication is being sent; this prevents a third party from using a TURN server to send data to arbitrary destinations. When forming a Send indication, the client MUST include an XOR-PEER- ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS attribute contains the transport address of the peer to which the data is to be sent, and the DATA attribute contains the actual application data to be sent to the peer. The client MAY include a DONT-FRAGMENT attribute in the Send indication if it wishes the server to set the DF bit on the UDP datagram sent to the peer. Reddy, et al. Expires January 28, 2020 [Page 41] Internet-Draft TURN July 2019 11.2. Receiving a Send Indication When the server receives a Send indication, it processes as per Section 5 plus the specific rules mentioned here. The message is first checked for validity. The Send indication MUST contain both an XOR-PEER-ADDRESS attribute and a DATA attribute. If one of these attributes is missing or invalid, then the message is discarded. Note that the DATA attribute is allowed to contain zero bytes of data. The Send indication may also contain the DONT-FRAGMENT attribute. If the server is unable to set the DF bit on outgoing UDP datagrams when this attribute is present, then the server acts as if the DONT- FRAGMENT attribute is an unknown comprehension-required attribute (and thus the Send indication is discarded). The server also checks that there is a permission installed for the IP address contained in the XOR-PEER-ADDRESS attribute. If no such permission exists, the message is discarded. Note that a Send indication never causes the server to refresh the permission. The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server silently discards the Send indication. If everything is OK, then the server forms a UDP datagram as follows: o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the Send indication arrived; o the destination transport address is taken from the XOR-PEER- ADDRESS attribute; o the data following the UDP header is the contents of the value field of the DATA attribute. The handling of the DONT-FRAGMENT attribute (if present), is described in Section 14 and Section 15. The resulting UDP datagram is then sent to the peer. 11.3. Receiving a UDP Datagram When the server receives a UDP datagram at a currently allocated relayed transport address, the server looks up the allocation associated with the relayed transport address. The server then Reddy, et al. Expires January 28, 2020 [Page 42] Internet-Draft TURN July 2019 checks to see whether the set of permissions for the allocation allow the relaying of the UDP datagram as described in Section 9. If relaying is permitted, then the server checks if there is a channel bound to the peer that sent the UDP datagram (see Section 12). If a channel is bound, then processing proceeds as described in Section 12.7. If relaying is permitted but no channel is bound to the peer, then the server forms and sends a Data indication. The Data indication MUST contain both an XOR-PEER-ADDRESS and a DATA attribute. The DATA attribute is set to the value of the 'data octets' field from the datagram, and the XOR-PEER-ADDRESS attribute is set to the source transport address of the received UDP datagram. The Data indication is then sent on the 5-tuple associated with the allocation. 11.4. Receiving a Data Indication When the client receives a Data indication, it checks that the Data indication contains an XOR-PEER-ADDRESS attribute, and discards the indication if it does not. The client SHOULD also check that the XOR-PEER-ADDRESS attribute value contains an IP address with which the client believes there is an active permission, and discard the Data indication otherwise. NOTE: The latter check protects the client against an attacker who somehow manages to trick the server into installing permissions not desired by the client. If the XOR-PEER-ADDRESS is present and valid, the client checks that the Data indication contains either a DATA attribute or an ICMP attribute and discards the indication if it does not. Note that a DATA attribute is allowed to contain zero bytes of data. Processing of Data indications with an ICMP attribute is described in Section 11.6. If the Data indication passes the above checks, the client delivers the data octets inside the DATA attribute to the application, along with an indication that they were received from the peer whose transport address is given by the XOR-PEER-ADDRESS attribute. 11.5. Receiving an ICMP Packet When the server receives an ICMP packet, the server verifies that the type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the IP packet in the ICMP packet payload contains a UDP header. If either of these conditions fail, then the ICMP packet is silently dropped. Reddy, et al. Expires January 28, 2020 [Page 43] Internet-Draft TURN July 2019 If a UDP header is present, the server extracts the source and destination IP address and UDP port information. The server looks up the allocation whose relayed transport address corresponds to the encapsulated packet's source IP address and UDP port. If no such allocation exists, the packet is silently dropped. The server then checks to see whether the set of permissions for the allocation allows the relaying of the ICMP packet. For ICMP packets, the source IP address MUST NOT be checked against the permissions list as it would be for UDP packets. Instead, the server extracts the destination IP address from the encapsulated IP header. The server then compares this address with the IP address associated with each permission in the list of permissions for the allocation. If no match is found, relaying is not permitted, and the server silently discards the ICMP packet. Note that only addresses are compared and port numbers are not considered. If relaying is permitted then the server forms and sends a Data indication. The Data indication MUST contain both an XOR-PEER- ADDRESS and an ICMP attribute. The ICMP attribute is set to the value of the type and code fields from the ICMP packet. The IP address portion of XOR-PEER-ADDRESS attribute is set to the destination IP address in the encapsulated IP header. At the time of writing of this specification, Socket APIs on some operating systems do not deliver the destination port in the encapsulated UDP header to applications without superuser privileges. If destination port in the encapsulated UDP header is available to the server then the port portion of XOR-PEER-ADDRESS attribute is set to the destination port otherwise the port portion is set to 0. The Data indication is then sent on the 5-tuple associated with the allocation. Implementation Note: New ICMP types or codes can be defined in future specifications. If the server receives an ICMP error packet, and the new type or code field can help the client to make use of the ICMP error notification and generate feedback to the application layer, the server sends the Data indication with an ICMP attribute conveying the new ICMP type or code. 11.6. Receiving a Data Indication with an ICMP attribute When the client receives a Data indication with an ICMP attribute, it checks that the Data indication contains an XOR-PEER-ADDRESS attribute, and discards the indication if it does not. The client SHOULD also check that the XOR-PEER-ADDRESS attribute value contains an IP address with an active permission, and discard the Data indication otherwise. Reddy, et al. Expires January 28, 2020 [Page 44] Internet-Draft TURN July 2019 If the Data indication passes the above checks, the client signals the application of the error condition, along with an indication that it was received from the peer whose transport address is given by the XOR-PEER-ADDRESS attribute. The application can make sense of the meaning of the type and code values in the ICMP attribute by using the family field in the XOR-PEER-ADDRESS attribute. 12. Channels Channels provide a way for the client and server to send application data using ChannelData messages, which have less overhead than Send and Data indications. The ChannelData message (see Section 12.4) starts with a two-byte field that carries the channel number. The values of this field are allocated as follows: 0x0000 through 0x3FFF: These values can never be used for channel numbers. 0x4000 through 0x4FFF: These values are the allowed channel numbers (4096 possible values). 0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision avoidance, see [RFC7983]. Note that the channel number range is not backwards compatible with [RFC5766], which could prevent an RFC5766-compliant client from establishing channel bindings with a TURN server that complies with this specification. . According to [RFC7983], ChannelData messages can be distinguished from other multiplexed protocols by examining the first byte of the message: Reddy, et al. Expires January 28, 2020 [Page 45] Internet-Draft TURN July 2019 +------------+------------------------------+ | [0..3] | STUN | | | | +-------------------------------------------+ | [16..19] | ZRTP | | | | +-------------------------------------------+ | [20..63] | DTLS | | | | +-------------------------------------------+ | [64..79] | TURN Channel | | | | +-------------------------------------------+ | [128..191] | RTP/RTCP | | | | +-------------------------------------------+ | Others | Reserved, MUST be dropped | | | and an alert MAY be logged | +-------------------------------------------+ Figure 5 Reserved values may be used in the future by other protocols. When the client uses channel binding, it MUST comply with the demultiplexing scheme discussed above. Channel bindings are always initiated by the client. The client can bind a channel to a peer at any time during the lifetime of the allocation. The client may bind a channel to a peer before exchanging data with it, or after exchanging data with it (using Send and Data indications) for some time, or may choose never to bind a channel to it. The client can also bind channels to some peers while not binding channels to other peers. Channel bindings are specific to an allocation, so that the use of a channel number or peer transport address in a channel binding in one allocation has no impact on their use in a different allocation. If an allocation expires, all its channel bindings expire with it. A channel binding consists of: o a channel number; o a transport address (of the peer); and o A time-to-expiry timer. Reddy, et al. Expires January 28, 2020 [Page 46] Internet-Draft TURN July 2019 Within the context of an allocation, a channel binding is uniquely identified either by the channel number or by the peer's transport address. Thus, the same channel cannot be bound to two different transport addresses, nor can the same transport address be bound to two different channels. A channel binding lasts for 10 minutes unless refreshed. Refreshing the binding (by the server receiving a ChannelBind request rebinding the channel to the same peer) resets the time-to-expiry timer back to 10 minutes. When the channel binding expires, the channel becomes unbound. Once unbound, the channel number can be bound to a different transport address, and the transport address can be bound to a different channel number. To prevent race conditions, the client MUST wait 5 minutes after the channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number. When binding a channel to a peer, the client SHOULD be prepared to receive ChannelData messages on the channel from the server as soon as it has sent the ChannelBind request. Over UDP, it is possible for the client to receive ChannelData messages from the server before it receives a ChannelBind success response. In the other direction, the client MAY elect to send ChannelData messages before receiving the ChannelBind success response. Doing so, however, runs the risk of having the ChannelData messages dropped by the server if the ChannelBind request does not succeed for some reason (e.g., packet lost if the request is sent over UDP, or the server being unable to fulfill the request). A client that wishes to be safe should either queue the data or use Send indications until the channel binding is confirmed. 12.1. Sending a ChannelBind Request A channel binding is created or refreshed using a ChannelBind transaction. A ChannelBind transaction also creates or refreshes a permission towards the peer (see Section 9). To initiate the ChannelBind transaction, the client forms a ChannelBind request. The channel to be bound is specified in a CHANNEL-NUMBER attribute, and the peer's transport address is specified in an XOR-PEER-ADDRESS attribute. Section 12.2 describes the restrictions on these attributes. The client MUST only include an XOR-PEER-ADDRESS attribute with an address of the same address family as that of a relayed transport address for the allocation. Reddy, et al. Expires January 28, 2020 [Page 47] Internet-Draft TURN July 2019 Rebinding a channel to the same transport address that it is already bound to provides a way to refresh a channel binding and the corresponding permission without sending data to the peer. Note however, that permissions need to be refreshed more frequently than channels. 12.2. Receiving a ChannelBind Request When the server receives a ChannelBind request, it processes as per Section 5 plus the specific rules mentioned here. The server checks the following: o The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS attribute; o The channel number is in the range 0x4000 through 0x4FFF (inclusive); o The channel number is not currently bound to a different transport address (same transport address is OK); o The transport address is not currently bound to a different channel number. If any of these tests fail, the server replies with a 400 (Bad Request) error. If the XOR-PEER-ADDRESS attribute contains an address of an address family that is not the same as that of a relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code. The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error. If the request is valid, but the server is unable to fulfill the request due to some capacity limit or similar, the server replies with a 508 (Insufficient Capacity) error. Otherwise, the server replies with a ChannelBind success response. There are no required attributes in a successful ChannelBind response. If the server can satisfy the request, then the server creates or refreshes the channel binding using the channel number in the CHANNEL-NUMBER attribute and the transport address in the XOR-PEER- ADDRESS attribute. The server also installs or refreshes a Reddy, et al. Expires January 28, 2020 [Page 48] Internet-Draft TURN July 2019 permission for the IP address in the XOR-PEER-ADDRESS attribute as described in Section 9. NOTE: A server need not do anything special to implement idempotency of ChannelBind requests over UDP using the "stateless stack approach". Retransmitted ChannelBind requests will simply refresh the channel binding and the corresponding permission. Furthermore, the client must wait 5 minutes before binding a previously bound channel number or peer address to a different channel, eliminating the possibility that the transaction would initially fail but succeed on a retransmission. 12.3. Receiving a ChannelBind Response When the client receives a ChannelBind success response, it updates its data structures to record that the channel binding is now active. It also updates its data structures to record that the corresponding permission has been installed or refreshed. If the client receives a ChannelBind failure response that indicates that the channel information is out-of-sync between the client and the server (e.g., an unexpected 400 "Bad Request" response), then it is RECOMMENDED that the client immediately delete the allocation and start afresh with a new allocation. 12.4. The ChannelData Message The ChannelData message is used to carry application data between the client and the server. It 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Application Data / / / | | | +-------------------------------+ | | +-------------------------------+ The Channel Number field specifies the number of the channel on which the data is traveling, and thus the address of the peer that is sending or is to receive the data. Reddy, et al. Expires January 28, 2020 [Page 49] Internet-Draft TURN July 2019 The Length field specifies the length in bytes of the application data field (i.e., it does not include the size of the ChannelData header). Note that 0 is a valid length. The Application Data field carries the data the client is trying to send to the peer, or that the peer is sending to the client. 12.5. Sending a ChannelData Message Once a client has bound a channel to a peer, then when the client has data to send to that peer it may use either a ChannelData message or a Send indication; that is, the client is not obligated to use the channel when it exists and may freely intermix the two message types when sending data to the peer. The server, on the other hand, MUST use the ChannelData message if a channel has been bound to the peer. The server uses a Data indication to signal the XOR-PEER-ADDRESS and ICMP attributes to the client even if a channel has been bound to the peer. The fields of the ChannelData message are filled in as described in Section 12.4. Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages. The padding is not reflected in the length field of the ChannelData message, so the actual size of a ChannelData message (including padding) is (4 + Length) rounded up to the nearest multiple of 4 (See section 14 in [I-D.ietf-tram-stunbis]). Over UDP, the padding is not required but MAY be included. The ChannelData message is then sent on the 5-tuple associated with the allocation. 12.6. Receiving a ChannelData Message The receiver of the ChannelData message uses the first byte to distinguish it from other multiplexed protocols, as described in Figure 5. If the message uses a value in the reserved range (0x5000 through 0xFFFF), then the message is silently discarded. If the ChannelData message is received in a UDP datagram, and if the UDP datagram is too short to contain the claimed length of the ChannelData message (i.e., the UDP header length field value is less than the ChannelData header length field value + 4 + 8), then the message is silently discarded. Reddy, et al. Expires January 28, 2020 [Page 50] Internet-Draft TURN July 2019 If the ChannelData message is received over TCP or over TLS-over-TCP, then the actual length of the ChannelData message is as described in Section 12.5. If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded. On the client, it is RECOMMENDED that the client discard the ChannelData message if the client believes there is no active permission towards the peer. On the server, the receipt of a ChannelData message MUST NOT refresh either the channel binding or the permission towards the peer. On the server, if no errors are detected, the server relays the application data to the peer by forming a UDP datagram as follows: o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the ChannelData message arrived; o the destination transport address is the transport address to which the channel is bound; o the data following the UDP header is the contents of the data field of the ChannelData message. The resulting UDP datagram is then sent to the peer. Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent (Section 4.1 in [RFC6263]). 12.7. Relaying Data from the Peer When the server receives a UDP datagram on the relayed transport address associated with an allocation, the server processes it as described in Section 11.3. If that section indicates that a ChannelData message should be sent (because there is a channel bound to the peer that sent to the UDP datagram), then the server forms and sends a ChannelData message as described in Section 12.5. When the server receives an ICMP packet, the server processes it as described in Section 11.5. 13. Packet Translations This section addresses IPv4-to-IPv6, IPv6-to-IPv4, and IPv6-to-IPv6 translations. Requirements for translation of the IP addresses and Reddy, et al. Expires January 28, 2020 [Page 51] Internet-Draft TURN July 2019 port numbers of the packets are described above. The following sections specify how to translate other header fields. As discussed in Section 3.6, translations in TURN are designed so that a TURN server can be implemented as an application that runs in user space under commonly available operating systems and that does not require special privileges. The translations specified in the following sections follow this principle. The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred behavior, but if that is not possible for a particular field, the server MUST implement the alternate behavior and MUST NOT do anything else for the reasons detailed in [RFC7915]. The TURN server solely relies on the DF bit in the IPv4 header and Fragmentation header in IPv6 header to handle fragmentation using the approach described in [RFC7915] and does not rely on the DONT-FRAGMENT attribute, ignoring the DONT-FRAGMENT is only applicable for UDP-to-UDP relay, and not for TCP-to-UDP relay. 13.1. IPv4-to-IPv6 Translations Time to Live (TTL) field Preferred Behavior: As specified in Section 4 of [RFC7915]. Alternate Behavior: Set the outgoing value to the default for outgoing packets. Traffic Class Preferred behavior: As specified in Section 4 of [RFC7915]. Alternate behavior: The TURN server sets the Traffic Class to the default value for outgoing packets. Flow Label Preferred behavior: The TURN server can use the 5-tuple of relayed transport address, peer transport address and UDP protocol number to identify each flow, and to generate and set the flow label value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the TURN server is incapable of generating the flow label value from the IPv6 packet's 5-tuple, it sets the Flow label to 0. Alternate behavior: The alternate behavior is the same as the preferred behavior for a TURN server that does not support flow labels. Reddy, et al. Expires January 28, 2020 [Page 52] Internet-Draft TURN July 2019 Hop Limit Preferred behavior: As specified in Section 4 of [RFC7915]. Alternate behavior: The TURN server sets the Hop Limit to the default value for outgoing packets. Fragmentation Preferred behavior: As specified in Section 4 of [RFC7915]. Alternate behavior: The TURN server assembles incoming fragments. The TURN server follows its default behavior to send outgoing packets. For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server. Extension Headers Preferred behavior: The outgoing packet uses the system defaults for IPv6 extension headers, with the exception of the Fragmentation header as described above. Alternate behavior: Same as preferred. 13.2. IPv6-to-IPv6 Translations Flow Label The TURN server should consider that it is handling two different IPv6 flows. Therefore, the Flow label [RFC6437] SHOULD NOT be copied as part of the translation. Preferred behavior: The TURN server can use the 5-tuple of relayed transport address, peer transport address and UDP protocol number to identify each flow, and to generate and set the flow label value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the TURN server is incapable of generating the flow label value from the IPv6 packet's 5-tuple, it sets the Flow label to 0. Alternate behavior: The alternate behavior is the same as the preferred behavior for a TURN server that does not support flow labels. Hop Limit Reddy, et al. Expires January 28, 2020 [Page 53] Internet-Draft TURN July 2019 Preferred behavior: The TURN server acts as a regular router with respect to decrementing the Hop Limit and generating an ICMPv6 error if it reaches zero. Alternate behavior: The TURN server sets the Hop Limit to the default value for outgoing packets. Fragmentation Preferred behavior: If the incoming packet did not include a Fragment header and the outgoing packet size does not exceed the outgoing link's MTU, the TURN server sends the outgoing packet without a Fragment header. If the incoming packet did not include a Fragment header and the outgoing packet size exceeds the outgoing link's MTU, the TURN server drops the outgoing packet and send an ICMP message of type 2 code 0 ("Packet too big") to the sender of the incoming packet. If the ICMPv6 packet ("Packet too big") is being sent to the peer, the TURN server SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication. If the incoming packet included a Fragment header and the outgoing packet size (with a Fragment header included) does not exceed the outgoing link's MTU, the TURN server sends the outgoing packet with a Fragment header. The TURN server sets the fields of the Fragment header as appropriate for a packet originating from the server. If the incoming packet included a Fragment header and the outgoing packet size exceeds the outgoing link's MTU, the TURN server MUST fragment the outgoing packet into fragments of no more than 1280 bytes. The TURN server sets the fields of the Fragment header as appropriate for a packet originating from the server. Alternate behavior: The TURN server assembles incoming fragments. The TURN server follows its default behavior to send outgoing packets. For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server. Extension Headers Preferred behavior: The outgoing packet uses the system defaults for IPv6 extension headers, with the exception of the Fragmentation header as described above. Reddy, et al. Expires January 28, 2020 [Page 54] Internet-Draft TURN July 2019 Alternate behavior: Same as preferred. 13.3. IPv6-to-IPv4 Translations Type of Service and Precedence Preferred behavior: As specified in Section 5 of [RFC7915]. Alternate behavior: The TURN server sets the Type of Service and Precedence to the default value for outgoing packets. Time to Live Preferred behavior: As specified in Section 5 of [RFC7915]. Alternate behavior: The TURN server sets the Time to Live to the default value for outgoing packets. Fragmentation Preferred behavior: As specified in Section 5 of [RFC7915]. Additionally, when the outgoing packet's size exceeds the outgoing link's MTU, the TURN server needs to generate an ICMP error (ICMPv6 Packet Too Big) reporting the MTU size. If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is being sent to the peer, the TURN server SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication. Alternate behavior: The TURN server assembles incoming fragments. The TURN server follows its default behavior to send outgoing packets. For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server. 14. UDP-to-UDP relay This section describes how the server sets various fields in the IP header for UDP-to-UDP relay from the client to the peer or vice versa. The descriptions in this section apply: (a) when the server sends a UDP datagram to the peer, or (b) when the server sends a Data indication or ChannelData message to the client over UDP transport. The descriptions in this section do not apply to TURN messages sent over TCP or TLS transport from the server to the client. The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred Reddy, et al. Expires January 28, 2020 [Page 55] Internet-Draft TURN July 2019 behavior, but if that is not possible for a particular field, then it SHOULD implement the alternative behavior. Differentiated Services Code Point (DSCP) field [RFC2474] Preferred Behavior: Set the outgoing value to the incoming value, unless the server includes a differentiated services classifier and marker [RFC2474]. Alternate Behavior: Set the outgoing value to a fixed value, which by default is Best Effort unless configured otherwise. In both cases, if the server is immediately adjacent to a differentiated services classifier and marker, then DSCP MAY be set to any arbitrary value in the direction towards the classifier. Explicit Congestion Notification (ECN) field [RFC3168] Preferred Behavior: Set the outgoing value to the incoming value. The server may perform Active Queue Management, in which case it SHOULD behave as a ECN aware router [RFC3168] and can mark traffic with Congestion Experienced (CE) instead of dropping the packet. The use of ECT(1) is subject to experimental usage [RFC8311]. Alternate Behavior: Set the outgoing value to Not-ECT (=0b00). IPv4 Fragmentation fields (applicable only for IPv4-to-IPv4 relay) Preferred Behavior: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the outgoing UDP packet to not fragment. In all other cases when sending an outgoing packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), copy the DF bit from the DF bit of the incoming packet that contained the application data. Set the other fragmentation fields (Identification, More Fragments, Fragment Offset) as appropriate for a packet originating from the server. Alternate Behavior: As described in the Preferred Behavior, except always assume the incoming DF bit is 0. Reddy, et al. Expires January 28, 2020 [Page 56] Internet-Draft TURN July 2019 In both the Preferred and Alternate Behaviors, the resulting packet may be too large for the outgoing link. If this is the case, then the normal fragmentation rules apply [RFC1122]. IPv4 Options Preferred Behavior: The outgoing packet uses the system defaults for IPv4 options. Alternate Behavior: Same as preferred. 15. TCP-to-UDP relay This section describes how the server sets various fields in the IP header for TCP-to-UDP relay from the client to the peer. The descriptions in this section apply when the server sends a UDP datagram to the peer. Note that the server does not perform per- packet translation for TCP-to-UDP relaying. Multipath TCP [I-D.ietf-mptcp-rfc6824bis] is not supported by this version of TURN because TCP multi-path is not used by either SIP or WebRTC protocols [RFC7478] for media and non-media data. TCP connection between the TURN client and server can use TCP-AO [RFC5925] but UDP does not provide a similar type of authentication though it might be added in the future [I-D.ietf-tsvwg-udp-options]. Even if both TCP-AO and UDP authentication would be used between TURN client and server, it would not change the end-to-end security properties of the application payload being relayed. Therefore applications using TURN will need to secure their application data end-to-end appropriately, e.g., SRTP for RTP applications. Note that TCP-AO option obsoletes TCP MD5 option. Unlike UDP, TCP without the TCP Fast Open extension [RFC7413] does not support 0-RTT session resumption. The TCP user timeout [RFC5482] equivalent for application data relayed by the TURN is the use of RTP control protocol (RTCP). As a reminder, RTCP is a fundamental and integral part of RTP. The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred behavior, but if that is not possible for a particular field, then it SHOULD implement the alternative behavior. For the UDP datagram sent to the peer based on Send Indication or ChannelData message arriving at the TURN server over a TCP Transport, the server sets various fields in the IP header as follows: Reddy, et al. Expires January 28, 2020 [Page 57] Internet-Draft TURN July 2019 Differentiated Services Code Point (DSCP) field [RFC2474] Preferred Behavior: The TCP connection can only use a single DSCP code point so inter flow differentiation is not possible, see Section 5.1 of [RFC7657]. The server sets the outgoing value to the DSCP code point used by the TCP connection, unless the server includes a differentiated services classifier and marker [RFC2474]. Alternate Behavior: Set the outgoing value to a fixed value, which by default is Best Effort unless configured otherwise. In both cases, if the server is immediately adjacent to a differentiated services classifier and marker, then DSCP MAY be set to any arbitrary value in the direction towards the classifier. Explicit Congestion Notification (ECN) field [RFC3168] Preferred Behavior: No mechanism is defined to indicate what ECN value should be used for the outgoing UDP datagrams of an allocation, therefore set the outgoing value to Not-ECT (=0b00). Alternate Behavior: Same as preferred. IPv4 Fragmentation fields (applicable only for IPv4-to-IPv4 relay) Preferred Behavior: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the outgoing UDP packet to not fragment. In all other cases when sending an outgoing UDP packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), set the DF bit in the outgoing IP header to 0. Alternate Behavior: Same as preferred. IPv6 Fragmentation fields Preferred Behavior: If the TCP traffic arrives over IPv6, the server relies on the presence of DONT-FRAGMENT attribute in the send indication to set the outgoing UDP packet to not fragment. Alternate Behavior: Same as preferred. Reddy, et al. Expires January 28, 2020 [Page 58] Internet-Draft TURN July 2019 IPv4 Options Preferred Behavior: The outgoing packet uses the system defaults for IPv4 options. Alternate Behavior: Same as preferred. 16. UDP-to-TCP relay This section describes how the server sets various fields in the IP header for UDP-to-TCP relay from the peer to the client. The descriptions in this section apply when the server sends a Data indication or ChannelData message to the client over TCP or TLS transport. Note that the server does not perform per-packet translation for UDP-to-TCP relaying. The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred behavior, but if that is not possible for a particular field, then it SHOULD implement the alternative behavior. The TURN server sets IP header fields in the TCP packets on a per- connection basis for the TCP connection as follows: Differentiated Services Code Point (DSCP) field [RFC2474] Preferred Behavior: Ignore the incoming DSCP value. When TCP is used between the client and the server, a single DSCP should be used for all traffic on that TCP connection. Note, TURN/ICE occurs before application data is exchanged. Alternate Behavior: Same as preferred. Explicit Congestion Notification (ECN) field [RFC3168] Preferred Behavior: Ignore, ECN signals are dropped in the TURN server for the incoming UDP datagrams from the peer. Alternate Behavior: Same as preferred. Fragmentation Preferred Behavior: Any fragmented packets are reassembled in the server and then forwarded to the client over the TCP connection. ICMP messages resulting from the UDP datagrams sent to the peer are processed by the server as described in Section 11.5 and Reddy, et al. Expires January 28, 2020 [Page 59] Internet-Draft TURN July 2019 forwarded to the client using TURN's mechanism for relevant ICMP types and codes. Alternate Behavior: Same as preferred. Extension Headers Preferred behavior: The outgoing packet uses the system defaults for IPv6 extension headers. Alternate behavior: Same as preferred. IPv4 Options Preferred Behavior: The outgoing packet uses the system defaults for IPv4 options. Alternate Behavior: Same as preferred. 17. STUN Methods This section lists the codepoints for the STUN methods defined in this specification. See elsewhere in this document for the semantics of these methods. 0x003 : Allocate (only request/response semantics defined) 0x004 : Refresh (only request/response semantics defined) 0x006 : Send (only indication semantics defined) 0x007 : Data (only indication semantics defined) 0x008 : CreatePermission (only request/response semantics defined 0x009 : ChannelBind (only request/response semantics defined) 18. STUN Attributes Reddy, et al. Expires January 28, 2020 [Page 60] Internet-Draft TURN July 2019 This STUN extension defines the following attributes: 0x000C: CHANNEL-NUMBER 0x000D: LIFETIME 0x0010: Reserved (was BANDWIDTH) 0x0012: XOR-PEER-ADDRESS 0x0013: DATA 0x0016: XOR-RELAYED-ADDRESS 0x0017: REQUESTED-ADDRESS-FAMILY 0x0018: EVEN-PORT 0x0019: REQUESTED-TRANSPORT 0x001A: DONT-FRAGMENT 0x0021: Reserved (was TIMER-VAL) 0x0022: RESERVATION-TOKEN TBD-CA: ADDITIONAL-ADDRESS-FAMILY TBD-CA: ADDRESS-ERROR-CODE TBD-CA: ICMP Some of these attributes have lengths that are not multiples of 4. By the rules of STUN, any attribute whose length is not a multiple of 4 bytes MUST be immediately followed by 1 to 3 padding bytes to ensure the next attribute (if any) would start on a 4-byte boundary (see [I-D.ietf-tram-stunbis]). 18.1. CHANNEL-NUMBER The CHANNEL-NUMBER attribute contains the number of the channel. The value portion of this attribute is 4 bytes long and consists of a 16-bit unsigned integer, followed by a two-octet RFFU (Reserved For Future Use) field, which MUST be set to 0 on transmission and MUST be ignored on reception. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Number | RFFU = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18.2. LIFETIME The LIFETIME attribute represents the duration for which the server will maintain an allocation in the absence of a refresh. The TURN client can include the LIFETIME attribute with the desired lifetime in Allocate and Refresh requests. The value portion of this attribute is 4-bytes long and consists of a 32-bit unsigned integral value representing the number of seconds remaining until expiration. Reddy, et al. Expires January 28, 2020 [Page 61] Internet-Draft TURN July 2019 18.3. XOR-PEER-ADDRESS The XOR-PEER-ADDRESS specifies the address and port of the peer as seen from the TURN server. (For example, the peer's server-reflexive transport address if the peer is behind a NAT.) It is encoded in the same way as XOR-MAPPED-ADDRESS [I-D.ietf-tram-stunbis]. 18.4. DATA The DATA attribute is present in all Send indications. If the ICMP attribute is not present in a Data indication, it contains a DATA attribute. The value portion of this attribute is variable length and consists of the application data (that is, the data that would immediately follow the UDP header if the data was been sent directly between the client and the peer). The application data is equivalent to the "UDP user data" and does not include the "surplus area" defined in Section 4 of [I-D.ietf-tsvwg-udp-options]. If the length of this attribute is not a multiple of 4, then padding must be added after this attribute. 18.5. XOR-RELAYED-ADDRESS The XOR-RELAYED-ADDRESS is present in Allocate responses. It specifies the address and port that the server allocated to the client. It is encoded in the same way as XOR-MAPPED-ADDRESS [I-D.ietf-tram-stunbis]. 18.6. REQUESTED-ADDRESS-FAMILY This attribute is used in Allocate and Refresh requests to specify the address type requested by the client. The value of this attribute is 4 bytes with 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Family | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Family: there are two values defined for this field and specified in [I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses. Reserved: at this point, the 24 bits in the Reserved field MUST be set to zero by the client and MUST be ignored by the server. Reddy, et al. Expires January 28, 2020 [Page 62] Internet-Draft TURN July 2019 18.7. EVEN-PORT This attribute allows the client to request that the port in the relayed transport address be even, and (optionally) that the server reserve the next-higher port number. The value portion of this attribute is 1 byte long. Its format is: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R| RFFU | +-+-+-+-+-+-+-+-+ The value contains a single 1-bit flag: R: If 1, the server is requested to reserve the next-higher port number (on the same IP address) for a subsequent allocation. If 0, no such reservation is requested. RFFU: Reserved For Future Use. The RFFU field must be set to zero on transmission and ignored on reception. Since the length of this attribute is not a multiple of 4, padding must immediately follow this attribute. 18.8. REQUESTED-TRANSPORT This attribute is used by the client to request a specific transport protocol for the allocated transport address. The value of this attribute is 4 bytes with 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | RFFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol field specifies the desired protocol. The codepoints used in this field are taken from those allowed in the Protocol field in the IPv4 header and the NextHeader field in the IPv6 header [Protocol-Numbers]. This specification only allows the use of codepoint 17 (User Datagram Protocol). The RFFU field MUST be set to zero on transmission and MUST be ignored on reception. It is reserved for future uses. Reddy, et al. Expires January 28, 2020 [Page 63] Internet-Draft TURN July 2019 18.9. DONT-FRAGMENT This attribute is used by the client to request that the server set the DF (Don't Fragment) bit in the IP header when relaying the application data onward to the peer, and for determining the server capability in Allocate requests. This attribute has no value part and thus the attribute length field is 0. 18.10. RESERVATION-TOKEN The RESERVATION-TOKEN attribute contains a token that uniquely identifies a relayed transport address being held in reserve by the server. The server includes this attribute in a success response to tell the client about the token, and the client includes this attribute in a subsequent Allocate request to request the server use that relayed transport address for the allocation. The attribute value is 8 bytes and contains the token value. 18.11. ADDITIONAL-ADDRESS-FAMILY This attribute is used by clients to request the allocation of a IPv4 and IPv6 address type from a server. It is encoded in the same way as REQUESTED-ADDRESS-FAMILY Section 18.6. The ADDITIONAL-ADDRESS- FAMILY attribute MAY be present in Allocate request. The attribute value of 0x02 (IPv6 address) is the only valid value in Allocate request. 18.12. ADDRESS-ERROR-CODE This attribute is used by servers to signal the reason for not allocating the requested address family. The value portion of this attribute is variable length with 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Family | Reserved |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Family: there are two values defined for this field and specified in [I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses. Reddy, et al. Expires January 28, 2020 [Page 64] Internet-Draft TURN July 2019 Reserved: at this point, the 13 bits in the Reserved field MUST be set to zero by the server and MUST be ignored by the client. Class: The Class represents the hundreds digit of the error code and is defined in section 14.8 of [I-D.ietf-tram-stunbis]. Number: this 8-bit field contains the reason server cannot allocate one of the requested address types. The error code values could be either 440 (unsupported address family) or 508 (insufficient capacity). The number representation is defined in section 14.8 of [I-D.ietf-tram-stunbis]. Reason Phrase: The recommended reason phrases for error codes 440 and 508 are explained in Section 19. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 509 bytes when encoding them or 763 bytes when decoding them). 18.13. ICMP This attribute is used by servers to signal the reason an UDP packet was dropped. The following is the format of the ICMP attribute. 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 | ICMP Type | ICMP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field MUST be set to 0 when sent, and MUST be ignored when received. ICMP Type: The field contains the value in the ICMP type. Its interpretation depends whether the ICMP was received over IPv4 or IPv6. ICMP Code: The field contains the value in the ICMP code. Its interpretation depends whether the ICMP was received over IPv4 or IPv6. Error Data: This field size is 4 bytes long. If the ICMPv6 type is 2 (Packet Too Big Message) or ICMPv4 type is 3 ( Destination Unreachable) and Code is 4 (fragmentation needed and DF set), the Error Data field will be set to the Maximum Transmission Unit of the next-hop link (Section 3.2 of [RFC4443]) and Section 4 of Reddy, et al. Expires January 28, 2020 [Page 65] Internet-Draft TURN July 2019 [RFC1191]). For other ICMPv6 types and ICMPv4 types and codes, Error Data field MUST be set to zero. 19. STUN Error Response Codes This document defines the following error response codes: 403 (Forbidden): The request was valid but cannot be performed due to administrative or similar restrictions. 437 (Allocation Mismatch): A request was received by the server that requires an allocation to be in place, but no allocation exists, or a request was received that requires no allocation, but an allocation exists. 440 (Address Family not Supported): The server does not support the address family requested by the client. 441 (Wrong Credentials): The credentials in the (non-Allocate) request do not match those used to create the allocation. 442 (Unsupported Transport Protocol): The Allocate request asked the server to use a transport protocol between the server and the peer that the server does not support. NOTE: This does NOT refer to the transport protocol used in the 5-tuple. 443 (Peer Address Family Mismatch). A peer address is part of a different address family than that of the relayed transport address of the allocation. 486 (Allocation Quota Reached): No more allocations using this username can be created at the present time. 508 (Insufficient Capacity): The server is unable to carry out the request due to some capacity limit being reached. In an Allocate response, this could be due to the server having no more relayed transport addresses available at that time, having none with the requested properties, or the one that corresponds to the specified reservation token is not available. 20. Detailed Example This section gives an example of the use of TURN, showing in detail the contents of the messages exchanged. The example uses the network diagram shown in the Overview (Figure 1). For each message, the attributes included in the message and their values are shown. For convenience, values are shown in a human- Reddy, et al. Expires January 28, 2020 [Page 66] Internet-Draft TURN July 2019 readable format rather than showing the actual octets; for example, "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED- ADDRESS attribute is included with an address of 192.0.2.15 and a port of 9000, here the address and port are shown before the xor-ing is done. For attributes with string-like values (e.g., SOFTWARE="Example client, version 1.03" and NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda"), the value of the attribute is shown in quotes for readability, but these quotes do not appear in the actual value. Reddy, et al. Expires January 28, 2020 [Page 67] Internet-Draft TURN July 2019 TURN TURN Peer Peer client server A B | | | | |--- Allocate request -------------->| | | | Transaction-Id=0xA56250D3F17ABE679422DE85 | | | SOFTWARE="Example client, version 1.03" | | | LIFETIME=3600 (1 hour) | | | | REQUESTED-TRANSPORT=17 (UDP) | | | | DONT-FRAGMENT | | | | | | | |<-- Allocate error response --------| | | | Transaction-Id=0xA56250D3F17ABE679422DE85 | | | SOFTWARE="Example server, version 1.17" | | | ERROR-CODE=401 (Unauthorized) | | | | REALM="example.com" | | | | NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | | | | |--- Allocate request -------------->| | | | Transaction-Id=0xC271E932AD7446A32C234492 | | | SOFTWARE="Example client 1.03" | | | | LIFETIME=3600 (1 hour) | | | | REQUESTED-TRANSPORT=17 (UDP) | | | | DONT-FRAGMENT | | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHM=SHA256 | | | | MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY-SHA256=... | | | | | | | |<-- Allocate success response ------| | | | Transaction-Id=0xC271E932AD7446A32C234492 | | | SOFTWARE="Example server, version 1.17" | | | LIFETIME=1200 (20 minutes) | | | | XOR-RELAYED-ADDRESS=192.0.2.15:50000 | | | XOR-MAPPED-ADDRESS=192.0.2.1:7000 | | | MESSAGE-INTEGRITY-SHA256=... | | | The client begins by selecting a host transport address to use for the TURN session; in this example, the client has selected 198.51.100.2:49721 as shown in Figure 1. The client then sends an Allocate request to the server at the server transport address. The client randomly selects a 96-bit transaction id of 0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in the transaction id field in the fixed header. The client includes a SOFTWARE attribute that gives information about the client's Reddy, et al. Expires January 28, 2020 [Page 68] Internet-Draft TURN July 2019 software; here the value is "Example client, version 1.03" to indicate that this is version 1.03 of something called the Example client. The client includes the LIFETIME attribute because it wishes the allocation to have a longer lifetime than the default of 10 minutes; the value of this attribute is 3600 seconds, which corresponds to 1 hour. The client must always include a REQUESTED- TRANSPORT attribute in an Allocate request and the only value allowed by this specification is 17, which indicates UDP transport between the server and the peers. The client also includes the DONT-FRAGMENT attribute because it wishes to use the DONT-FRAGMENT attribute later in Send indications; this attribute consists of only an attribute header, there is no value part. We assume the client has not recently interacted with the server, thus the client does not include USERNAME, USERHASH, REALM, NONCE, PASSWORD-ALGORITHMS, PASSWORD- ALGORITHM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. Finally, note that the order of attributes in a message is arbitrary (except for the MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256 and FINGERPRINT attributes) and the client could have used a different order. Servers require any request to be authenticated. Thus, when the server receives the initial Allocate request, it rejects the request because the request does not contain the authentication attributes. Following the procedures of the long-term credential mechanism of STUN [I-D.ietf-tram-stunbis], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. The NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1. The server includes a PASSWORD-ALGORITHMS attribute that specifies the list of algorithms that the server can use to derive the long-term password. If the server sets the STUN Security Feature "Username anonymity" bit to 1 then the client uses the USERHASH attribute instead of the USERNAME attribute in the Allocate request to anonymise the username. The server also includes a SOFTWARE attribute that gives information about the server's software. The client, upon receipt of the 401 error, re-attempts the Allocate request, this time including the authentication attributes. The client selects a new transaction id, and then populates the new Allocate request with the same attributes as before. The client includes a USERNAME attribute and uses the realm value received from the server to help it determine which value to use; here the client is configured to use the username "George" for the realm "example.com". The client includes the PASSWORD-ALGORITHM attribute indicating the algorithm that the server must use to derive the long- term password. The client also includes the REALM, PASSWORD- Reddy, et al. Expires January 28, 2020 [Page 69] Internet-Draft TURN July 2019 ALGORITHMS and NONCE attributes, which are just copied from the 401 error response. Finally, the client includes MESSAGE-INTEGRITY- SHA256 attribute as the last attributes in the message, whose value is Hashed Message Authentication Code - Secure Hash Algorithm 2 (HMAC-SHA2) hash over the contents of the message (shown as just "..." above); this HMAC-SHA2 computation includes a password value. Thus, an attacker cannot compute the message integrity value without somehow knowing the secret password. The server, upon receipt of the authenticated Allocate request, checks that everything is OK, then creates an allocation. The server replies with an Allocate success response. The server includes a LIFETIME attribute giving the lifetime of the allocation; here, the server has reduced the client's requested 1-hour lifetime to just 20 minutes, because this particular server doesn't allow lifetimes longer than 20 minutes. The server includes an XOR-RELAYED-ADDRESS attribute whose value is the relayed transport address of the allocation. The server includes an XOR-MAPPED-ADDRESS attribute whose value is the server-reflexive address of the client; this value is not used otherwise in TURN but is returned as a convenience to the client. The server includes a MESSAGE-INTEGRITY-SHA256 attribute to authenticate the response and to ensure its integrity; note that the response does not contain the USERNAME, REALM, and NONCE attributes. The server also includes a SOFTWARE attribute. TURN TURN Peer Peer client server A B |--- CreatePermission request ------>| | | | Transaction-Id=0xE5913A8F460956CA277D3319 | | | XOR-PEER-ADDRESS=192.0.2.150:0 | | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHM=SHA256 | | | | MESSAGE-INTEGRITY-SHA256=... | | | | | | | |<-- CreatePermission success resp.--| | | | Transaction-Id=0xE5913A8F460956CA277D3319 | | | MESSAGE-INTEGRITY-SHA256=... | | | The client then creates a permission towards Peer A in preparation for sending it some application data. This is done through a CreatePermission request. The XOR-PEER-ADDRESS attribute contains the IP address for which a permission is established (the IP address of peer A); note that the port number in the attribute is ignored when used in a CreatePermission request, and here it has been set to 0; also, note how the client uses Peer A's server-reflexive IP Reddy, et al. Expires January 28, 2020 [Page 70] Internet-Draft TURN July 2019 address and not its (private) host address. The client uses the same username, realm, and nonce values as in the previous request on the allocation. Though it is allowed to do so, the client has chosen not to include a SOFTWARE attribute in this request. The server receives the CreatePermission request, creates the corresponding permission, and then replies with a CreatePermission success response. Like the client, the server chooses not to include the SOFTWARE attribute in its reply. Again, note how success responses contains a MESSAGE-INTEGRITY-SHA256 attribute (assuming the server uses the long-term credential mechanism), but no USERNAME, REALM, and NONCE attributes. TURN TURN Peer Peer client server A B |--- Send indication --------------->| | | | Transaction-Id=0x1278E9ACA2711637EF7D3328 | | | XOR-PEER-ADDRESS=192.0.2.150:32102 | | | DONT-FRAGMENT | | | | DATA=... | | | | |-- UDP dgm ->| | | | data=... | | | | | | | |<- UDP dgm --| | | | data=... | | |<-- Data indication ----------------| | | | Transaction-Id=0x8231AE8F9242DA9FF287FEFF | | | XOR-PEER-ADDRESS=192.0.2.150:32102 | | | DATA=... | | | The client now sends application data to Peer A using a Send indication. Peer A's server-reflexive transport address is specified in the XOR-PEER-ADDRESS attribute, and the application data (shown here as just "...") is specified in the DATA attribute. The client is doing a form of path MTU discovery at the application layer and thus specifies (by including the DONT-FRAGMENT attribute) that the server should set the DF bit in the UDP datagram to send to the peer. Indications cannot be authenticated using the long-term credential mechanism of STUN, so no MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- SHA256 attribute is included in the message. An application wishing to ensure that its data is not altered or forged must integrity- protect its data at the application level. Upon receipt of the Send indication, the server extracts the application data and sends it in a UDP datagram to Peer A, with the relayed transport address as the source transport address of the datagram, and with the DF bit set as requested. Note that, had the client not previously established a permission for Peer A's server- Reddy, et al. Expires January 28, 2020 [Page 71] Internet-Draft TURN July 2019 reflexive IP address, then the server would have silently discarded the Send indication instead. Peer A then replies with its own UDP datagram containing application data. The datagram is sent to the relayed transport address on the server. When this arrives, the server creates a Data indication containing the source of the UDP datagram in the XOR-PEER-ADDRESS attribute, and the data from the UDP datagram in the DATA attribute. The resulting Data indication is then sent to the client. TURN TURN Peer Peer client server A B |--- ChannelBind request ----------->| | | | Transaction-Id=0x6490D3BC175AFF3D84513212 | | | CHANNEL-NUMBER=0x4000 | | | | XOR-PEER-ADDRESS=192.0.2.210:49191 | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHM=SHA256 | | | | MESSAGE-INTEGRITY-SHA256=... | | | | | | | |<-- ChannelBind success response ---| | | | Transaction-Id=0x6490D3BC175AFF3D84513212 | | | MESSAGE-INTEGRITY-SHA256=... | | | The client now binds a channel to Peer B, specifying a free channel number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's transport address in the XOR-PEER-ADDRESS attribute. As before, the client re-uses the username, realm, and nonce from its last request in the message. Upon receipt of the request, the server binds the channel number to the peer, installs a permission for Peer B's IP address, and then replies with ChannelBind success response. TURN TURN Peer Peer client server A B |--- ChannelData ------------------->| | | | Channel-number=0x4000 |--- UDP datagram --------->| | Data=... | Data=... | | | | | | |<-- UDP datagram ----------| | | Data=... | | |<-- ChannelData --------------------| | | | Channel-number=0x4000 | | | | Data=... | | | Reddy, et al. Expires January 28, 2020 [Page 72] Internet-Draft TURN July 2019 The client now sends a ChannelData message to the server with data destined for Peer B. The ChannelData message is not a STUN message, and thus has no transaction id. Instead, it has only three fields: a channel number, data, and data length; here the channel number field is 0x4000 (the channel the client just bound to Peer B). When the server receives the ChannelData message, it checks that the channel is currently bound (which it is) and then sends the data onward to Peer B in a UDP datagram, using the relayed transport address as the source transport address and 192.0.2.210:49191 (the value of the XOR- PEER-ADDRESS attribute in the ChannelBind request) as the destination transport address. Later, Peer B sends a UDP datagram back to the relayed transport address. This causes the server to send a ChannelData message to the client containing the data from the UDP datagram. The server knows to which client to send the ChannelData message because of the relayed transport address at which the UDP datagram arrived, and knows to use channel 0x4000 because this is the channel bound to 192.0.2.210:49191. Note that if there had not been any channel number bound to that address, the server would have used a Data indication instead. TURN TURN Peer Peer client server A B |--- ChannelBind request ----------->| | | | Transaction-Id=0xE5913A8F46091637EF7D3328 | | | CHANNEL-NUMBER=0x4000 | | | | XOR-PEER-ADDRESS=192.0.2.210:49191 | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHM=SHA256 | | | | MESSAGE-INTEGRITY-SHA256=... | | | | | | | |<-- ChannelBind success response ---| | | | Transaction-Id=0xE5913A8F46091637EF7D3328 | | | MESSAGE-INTEGRITY-SHA256=... | | | The channel binding lasts for 10 minutes unless refreshed. The TURN client refreshes the binding by sending ChannelBind request rebinding the channel to the same peer (Peer B's IP address). The server processes the ChannelBind request, rebinds the channel to the same peer and resets the time-to-expiry timer back to 10 minutes. Reddy, et al. Expires January 28, 2020 [Page 73] Internet-Draft TURN July 2019 TURN TURN Peer Peer client server A B |--- Refresh request --------------->| | | | Transaction-Id=0x0864B3C27ADE9354B4312414 | | | SOFTWARE="Example client 1.03" | | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="oobMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHM=SHA256 | | | | MESSAGE-INTEGRITY-SHA256=... | | | | | | | |<-- Refresh error response ---------| | | | Transaction-Id=0x0864B3C27ADE9354B4312414 | | | SOFTWARE="Example server, version 1.17" | | | ERROR-CODE=438 (Stale Nonce) | | | | REALM="example.com" | | | | NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | | | | |--- Refresh request --------------->| | | | Transaction-Id=0x427BD3E625A85FC731DC4191 | | | SOFTWARE="Example client 1.03" | | | | USERNAME="George" | | | | REALM="example.com" | | | | NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHM=SHA256 | | | | MESSAGE-INTEGRITY-SHA256=... | | | | | | | |<-- Refresh success response -------| | | | Transaction-Id=0x427BD3E625A85FC731DC4191 | | | SOFTWARE="Example server, version 1.17" | | | LIFETIME=600 (10 minutes) | | | Sometime before the 20 minute lifetime is up, the client refreshes the allocation. This is done using a Refresh request. As before, the client includes the latest username, realm, and nonce values in the request. The client also includes the SOFTWARE attribute, following the recommended practice of always including this attribute in Allocate and Refresh messages. When the server receives the Refresh request, it notices that the nonce value has expired, and so replies with 438 (Stale Nonce) error given a new nonce value. The client then reattempts the request, this time with the new nonce value. This second attempt is accepted, and the server replies with a success response. Note that the client did not include a LIFETIME attribute in the request, so the server refreshes the allocation for Reddy, et al. Expires January 28, 2020 [Page 74] Internet-Draft TURN July 2019 the default lifetime of 10 minutes (as can be seen by the LIFETIME attribute in the success response). 21. Security Considerations This section considers attacks that are possible in a TURN deployment, and discusses how they are mitigated by mechanisms in the protocol or recommended practices in the implementation. Most of the attacks on TURN are mitigated by the server requiring requests be authenticated. Thus, this specification requires the use of authentication. The mandatory-to-implement mechanism is the long- term credential mechanism of STUN. Other authentication mechanisms of equal or stronger security properties may be used. However, it is important to ensure that they can be invoked in an inter-operable way. 21.1. Outsider Attacks Outsider attacks are ones where the attacker has no credentials in the system, and is attempting to disrupt the service seen by the client or the server. 21.1.1. Obtaining Unauthorized Allocations An attacker might wish to obtain allocations on a TURN server for any number of nefarious purposes. A TURN server provides a mechanism for sending and receiving packets while cloaking the actual IP address of the client. This makes TURN servers an attractive target for attackers who wish to use it to mask their true identity. An attacker might also wish to simply utilize the services of a TURN server without paying for them. Since TURN services require resources from the provider, it is anticipated that their usage will come with a cost. These attacks are prevented using the long-term credential mechanism, which allows the TURN server to determine the identity of the requestor and whether the requestor is allowed to obtain the allocation. 21.1.2. Offline Dictionary Attacks The long-term credential mechanism used by TURN is subject to offline dictionary attacks. An attacker that is capable of eavesdropping on a message exchange between a client and server can determine the password by trying a number of candidate passwords and seeing if one of them is correct. This attack works when the passwords are low Reddy, et al. Expires January 28, 2020 [Page 75] Internet-Draft TURN July 2019 entropy, such as a word from the dictionary. This attack can be mitigated by using strong passwords with large entropy. In situations where even stronger mitigation is required, (D)TLS transport between the client and the server can be used. 21.1.3. Faked Refreshes and Permissions An attacker might wish to attack an active allocation by sending it a Refresh request with an immediate expiration, in order to delete it and disrupt service to the client. This is prevented by authentication of refreshes. Similarly, an attacker wishing to send CreatePermission requests to create permissions to undesirable destinations is prevented from doing so through authentication. The motivations for such an attack are described in Section 21.2. 21.1.4. Fake Data An attacker might wish to send data to the client or the peer, as if they came from the peer or client, respectively. To do that, the attacker can send the client a faked Data Indication or ChannelData message, or send the TURN server a faked Send Indication or ChannelData message. Since indications and ChannelData messages are not authenticated, this attack is not prevented by TURN. However, this attack is generally present in IP-based communications and is not substantially worsened by TURN. Consider a normal, non-TURN IP session between hosts A and B. An attacker can send packets to B as if they came from A by sending packets towards B with a spoofed IP address of A. This attack requires the attacker to know the IP addresses of A and B. With TURN, an attacker wishing to send packets towards a client using a Data indication needs to know its IP address (and port), the IP address and port of the TURN server, and the IP address and port of the peer (for inclusion in the XOR-PEER-ADDRESS attribute). To send a fake ChannelData message to a client, an attacker needs to know the IP address and port of the client, the IP address and port of the TURN server, and the channel number. This particular combination is mildly more guessable than in the non-TURN case. These attacks are more properly mitigated by application-layer authentication techniques. In the case of real-time traffic, usage of SRTP [RFC3711] prevents these attacks. In some situations, the TURN server may be situated in the network such that it is able to send to hosts to which the client cannot directly send. This can happen, for example, if the server is located behind a firewall that allows packets from outside the firewall to be delivered to the server, but not to other hosts behind Reddy, et al. Expires January 28, 2020 [Page 76] Internet-Draft TURN July 2019 the firewall. In these situations, an attacker could send the server a Send indication with an XOR-PEER-ADDRESS attribute containing the transport address of one of the other hosts behind the firewall. If the server was to allow relaying of traffic to arbitrary peers, then this would provide a way for the attacker to attack arbitrary hosts behind the firewall. To mitigate this attack, TURN requires that the client establish a permission to a host before sending it data. Thus, an attacker can only attack hosts with which the client is already communicating, unless the attacker is able to create authenticated requests. Furthermore, the server administrator may configure the server to restrict the range of IP addresses and ports to which it will relay data. To provide even greater security, the server administrator can require that the client use (D)TLS for all communication between the client and the server. 21.1.5. Impersonating a Server When a client learns a relayed address from a TURN server, it uses that relayed address in application protocols to receive traffic. Therefore, an attacker wishing to intercept or redirect that traffic might try to impersonate a TURN server and provide the client with a faked relayed address. This attack is prevented through the long-term credential mechanism, which provides message integrity for responses in addition to verifying that they came from the server. Furthermore, an attacker cannot replay old server responses as the transaction id in the STUN header prevents this. Replay attacks are further thwarted through frequent changes to the nonce value. 21.1.6. Eavesdropping Traffic If the TURN client and server use the STUN Extension for Third-Party Authorization [RFC7635] (for example it is used in WebRTC), the username does not reveal the real user's identity, the USERNAME attribute carries an ephemeral and unique key identifier. If the TURN client and server use the STUN long-term credential mechanism and the username reveals the real user's identity, the client MUST either use the USERHASH attribute instead of the USERNAME attribute to anonynmize the username or use (D)TLS transport between the client and the server. If the TURN client and server use the STUN long-term credential mechanism and realm information is privacy sensitive, TURN can be run over (D)TLS. As a reminder, STUN Extension for Third-Party Authorization does not use realm. Reddy, et al. Expires January 28, 2020 [Page 77] Internet-Draft TURN July 2019 The SOFTWARE attribute can reveal the specific software version of the TURN client and server to eavesdropper and it might possibly allow attacks against vulnerable software that is known to contain security vulnerabilities. If the software version is known to contain security vulnerabilities, TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text. If zero-day vulnerabilities are detected in the software version, the endpoint policy can be modified to mandate the use of (D)TLS until the patch is in place to fix the flaw. TURN concerns itself primarily with authentication and message integrity. Confidentiality is only a secondary concern, as TURN control messages do not include information that is particularly sensitive, with the exception of USERNAME, REALM and SOFTWARE. The primary protocol content of the messages is the IP address of the peer. If it is important to prevent an eavesdropper on a TURN connection from learning this, TURN can be run over (D)TLS. Confidentiality for the application data relayed by TURN is best provided by the application protocol itself, since running TURN over (D)TLS does not protect application data between the server and the peer. If confidentiality of application data is important, then the application should encrypt or otherwise protect its data. For example, for real-time media, confidentiality can be provided by using SRTP. 21.1.7. TURN Loop Attack An attacker might attempt to cause data packets to loop indefinitely between two TURN servers. The attack goes as follows. First, the attacker sends an Allocate request to server A, using the source address of server B. Server A will send its response to server B, and for the attack to succeed, the attacker must have the ability to either view or guess the contents of this response, so that the attacker can learn the allocated relayed transport address. The attacker then sends an Allocate request to server B, using the source address of server A. Again, the attacker must be able to view or guess the contents of the response, so it can send learn the allocated relayed transport address. Using the same spoofed source address technique, the attacker then binds a channel number on server A to the relayed transport address on server B, and similarly binds the same channel number on server B to the relayed transport address on server A. Finally, the attacker sends a ChannelData message to server A. The result is a data packet that loops from the relayed transport address on server A to the relayed transport address on server B, Reddy, et al. Expires January 28, 2020 [Page 78] Internet-Draft TURN July 2019 then from server B's transport address to server A's transport address, and then around the loop again. This attack is mitigated as follows. By requiring all requests to be authenticated and/or by randomizing the port number allocated for the relayed transport address, the server forces the attacker to either intercept or view responses sent to a third party (in this case, the other server) so that the attacker can authenticate the requests and learn the relayed transport address. Without one of these two measures, an attacker can guess the contents of the responses without needing to see them, which makes the attack much easier to perform. Furthermore, by requiring authenticated requests, the server forces the attacker to have credentials acceptable to the server, which turns this from an outsider attack into an insider attack and allows the attack to be traced back to the client initiating it. The attack can be further mitigated by imposing a per-username limit on the bandwidth used to relay data by allocations owned by that username, to limit the impact of this attack on other allocations. More mitigation can be achieved by decrementing the TTL when relaying data packets (if the underlying OS allows this). 21.2. Firewall Considerations A key security consideration of TURN is that TURN should not weaken the protections afforded by firewalls deployed between a client and a TURN server. It is anticipated that TURN servers will often be present on the public Internet, and clients may often be inside enterprise networks with corporate firewalls. If TURN servers provide a 'backdoor' for reaching into the enterprise, TURN will be blocked by these firewalls. TURN servers therefore emulate the behavior of NAT devices that implement address-dependent filtering [RFC4787], a property common in many firewalls as well. When a NAT or firewall implements this behavior, packets from an outside IP address are only allowed to be sent to an internal IP address and port if the internal IP address and port had recently sent a packet to that outside IP address. TURN servers introduce the concept of permissions, which provide exactly this same behavior on the TURN server. An attacker cannot send a packet to a TURN server and expect it to be relayed towards the client, unless the client has tried to contact the attacker first. It is important to note that some firewalls have policies that are even more restrictive than address-dependent filtering. Firewalls can also be configured with address- and port-dependent filtering, or can be configured to disallow inbound traffic entirely. In these cases, if a client is allowed to connect the TURN server, Reddy, et al. Expires January 28, 2020 [Page 79] Internet-Draft TURN July 2019 communications to the client will be less restrictive than what the firewall would normally allow. 21.2.1. Faked Permissions In firewalls and NAT devices, permissions are granted implicitly through the traversal of a packet from the inside of the network towards the outside peer. Thus, a permission cannot, by definition, be created by any entity except one inside the firewall or NAT. With TURN, this restriction no longer holds. Since the TURN server sits outside the firewall, at attacker outside the firewall can now send a message to the TURN server and try to create a permission for itself. This attack is prevented because all messages that create permissions (i.e., ChannelBind and CreatePermission) are authenticated. 21.2.2. Blacklisted IP Addresses Many firewalls can be configured with blacklists that prevent a client behind the firewall from sending packets to, or receiving packets from, ranges of blacklisted IP addresses. This is accomplished by inspecting the source and destination addresses of packets entering and exiting the firewall, respectively. This feature is also present in TURN, since TURN servers are allowed to arbitrarily restrict the range of addresses of peers that they will relay to. 21.2.3. Running Servers on Well-Known Ports A malicious client behind a firewall might try to connect to a TURN server and obtain an allocation which it then uses to run a server. For example, a client might try to run a DNS server or FTP server. This is not possible in TURN. A TURN server will never accept traffic from a peer for which the client has not installed a permission. Thus, peers cannot just connect to the allocated port in order to obtain the service. 21.3. Insider Attacks In insider attacks, a client has legitimate credentials but defies the trust relationship that goes with those credentials. These attacks cannot be prevented by cryptographic means but need to be considered in the design of the protocol. Reddy, et al. Expires January 28, 2020 [Page 80] Internet-Draft TURN July 2019 21.3.1. DoS against TURN Server A client wishing to disrupt service to other clients might obtain an allocation and then flood it with traffic, in an attempt to swamp the server and prevent it from servicing other legitimate clients. This is mitigated by the recommendation that the server limit the amount of bandwidth it will relay for a given username. This won't prevent a client from sending a large amount of traffic, but it allows the server to immediately discard traffic in excess. Since each allocation uses a port number on the IP address of the TURN server, the number of allocations on a server is finite. An attacker might attempt to consume all of them by requesting a large number of allocations. This is prevented by the recommendation that the server impose a limit of the number of allocations active at a time for a given username. 21.3.2. Anonymous Relaying of Malicious Traffic TURN servers provide a degree of anonymization. A client can send data to peers without revealing its own IP address. TURN servers may therefore become attractive vehicles for attackers to launch attacks against targets without fear of detection. Indeed, it is possible for a client to chain together multiple TURN servers, such that any number of relays can be used before a target receives a packet. Administrators who are worried about this attack can maintain logs that capture the actual source IP and port of the client, and perhaps even every permission that client installs. This will allow for forensic tracing to determine the original source, should it be discovered that an attack is being relayed through a TURN server. 21.3.3. Manipulating Other Allocations An attacker might attempt to disrupt service to other users of the TURN server by sending Refresh requests or CreatePermission requests that (through source address spoofing) appear to be coming from another user of the TURN server. TURN prevents this by requiring that the credentials used in CreatePermission, Refresh, and ChannelBind messages match those used to create the initial allocation. Thus, the fake requests from the attacker will be rejected. 21.4. Tunnel Amplification Attack An attacker might attempt to cause data packets to loop numerous times between a TURN server and a tunnel between IPv4 and IPv6. The attack goes as follows. Reddy, et al. Expires January 28, 2020 [Page 81] Internet-Draft TURN July 2019 Suppose an attacker knows that a tunnel endpoint will forward encapsulated packets from a given IPv6 address (this doesn't necessarily need to be the tunnel endpoint's address). Suppose he then spoofs two packets from this address: 1. An Allocate request asking for a v4 address, and 2. A ChannelBind request establishing a channel to the IPv4 address of the tunnel endpoint Then he has set up an amplification attack: o The TURN server will re-encapsulate IPv6 UDP data in v4 and send it to the tunnel endpoint o The tunnel endpoint will de-encapsulate packets from the v4 interface and send them to v6 So if the attacker sends a packet of the following form... IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 UDP: TURN: IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 UDP: TURN: IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 UDP: TURN: ... Then the TURN server and the tunnel endpoint will send it back and forth until the last TURN header is consumed, at which point the TURN server will send an empty packet, which the tunnel endpoint will drop. The amplification potential here is limited by the MTU, so it's not huge: IPv6+UDP+TURN takes 334 bytes, so a four-to-one amplification out of a 1500-byte packet is possible. But the attacker could still increase traffic volume by sending multiple packets or by establishing multiple channels spoofed from different addresses behind the same tunnel endpoint. The attack is mitigated as follows. It is RECOMMENDED that TURN servers not accept allocation or channel binding requests from addresses known to be tunneled, and that they not forward data to such addresses. In particular, a TURN server MUST NOT accept Teredo or 6to4 addresses in these requests. Reddy, et al. Expires January 28, 2020 [Page 82] Internet-Draft TURN July 2019 21.5. Other Considerations Any relay addresses learned through an Allocate request will not operate properly with IPsec Authentication Header (AH) [RFC4302] in transport or tunnel mode. However, tunnel-mode IPsec Encapsulating Security Payload (ESP) [RFC4303] should still operate. 22. IANA Considerations [Paragraphs in braces should be removed by the RFC Editor upon publication] The codepoints for the STUN methods defined in this specification are listed in Section 17. [IANA is requested to update the reference from [RFC5766] to RFC-to-be for the STUN methods listed in Section 17.] The codepoints for the STUN attributes defined in this specification are listed in Section 18. [IANA is requested to update the reference from [RFC5766] to RFC-to-be for the STUN attributes CHANNEL-NUMBER, LIFETIME, Reserved (was BANDWIDTH), XOR-PEER-ADDRESS, DATA, XOR- RELAYED-ADDRESS, REQUESTED-ADDRESS-FAMILY, EVEN-PORT, REQUESTED- TRANSPORT, DONT-FRAGMENT, Reserved (was TIMER-VAL) and RESERVATION- TOKEN listed in Section 18.] [The ADDITIONAL-ADDRESS-FAMILY, ADDRESS-ERROR-CODE and ICMP attributes requires that IANA allocate a value in the "STUN attributes Registry" from the comprehension-optional range (0x8000-0xFFFF), to be replaced for TBD-CA throughout this document] The codepoints for the STUN error codes defined in this specification are listed in Section 19. [IANA is requested to update the reference from [RFC5766] and [RFC6156] to RFC-to-be for the STUN error codes listed in Section 19.] IANA has allocated the SRV service name of "turn" for TURN over UDP or TCP, and the service name of "turns" for TURN over (D)TLS. IANA has created a registry for TURN channel numbers, initially populated as follows: o 0x0000 through 0x3FFF: Reserved and not available for use, since they conflict with the STUN header. o 0x4000 through 0x4FFF: A TURN implementation is free to use channel numbers in this range. o 0x5000 through 0xFFFF: Unassigned. Reddy, et al. Expires January 28, 2020 [Page 83] Internet-Draft TURN July 2019 Any change to this registry must be made through an IETF Standards Action. 23. IAB Considerations The IAB has studied the problem of "Unilateral Self Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol-reflection mechanism [RFC3424]. The TURN extension is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. These considerations and the responses for TURN are documented in this section. Consideration 1: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short-term fix should not be generalized to solve other problems. Such generalizations lead to the prolonged dependence on and usage of the supposed short-term fix -- meaning that it is no longer accurate to call it "short-term". Response: TURN is a protocol for communication between a relay (= TURN server) and its client. The protocol allows a client that is behind a NAT to obtain and use a public IP address on the relay. As a convenience to the client, TURN also allows the client to determine its server-reflexive transport address. Consideration 2: Description of an exit strategy/transition plan. The better short-term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed. Response: TURN will no longer be needed once there are no longer any NATs. Unfortunately, as of the date of publication of this document, it no longer seems very likely that NATs will go away any time soon. However, the need for TURN will also decrease as the number of NATs with the mapping property of Endpoint-Independent Mapping [RFC4787] increases. Consideration 3: Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition. Response: TURN is "brittle" in that it requires the NAT bindings between the client and the server to be maintained unchanged for the lifetime of the allocation. This is typically done using keep- Reddy, et al. Expires January 28, 2020 [Page 84] Internet-Draft TURN July 2019 alives. If this is not done, then the client will lose its allocation and can no longer exchange data with its peers. Consideration 4: Identify requirements for longer-term, sound technical solutions; contribute to the process of finding the right longer-term solution. Response: The need for TURN will be reduced once NATs implement the recommendations for NAT UDP behavior documented in [RFC4787]. Applications are also strongly urged to use ICE [RFC8445] to communicate with peers; though ICE uses TURN, it does so only as a last resort, and uses it in a controlled manner. Consideration 5: Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports. Response: Some NATs deployed today exhibit a mapping behavior other than Endpoint-Independent mapping. These NATs are difficult to work with, as they make it difficult or impossible for protocols like ICE to use server-reflexive transport addresses on those NATs. A client behind such a NAT is often forced to use a relay protocol like TURN because "UDP hole punching" techniques [RFC5128] do not work. 24. Changes since RFC 5766 This section lists the major changes in the TURN protocol from the original [RFC5766] specification. o IPv6 support. o REQUESTED-ADDRESS-FAMILY attribute. o Description of the tunnel amplification attack. o DTLS support. o Add support for receiving ICMP packets. o Updates PMTUD. o Discovery of TURN server. o TURN URI Scheme Semantics. o Happy Eyeballs for TURN. o Align with the changes in STUNbis. Reddy, et al. Expires January 28, 2020 [Page 85] Internet-Draft TURN July 2019 25. Updates to RFC 6156 This section lists the major updates to [RFC6156] in this specification. o ADDITIONAL-ADDRESS-FAMILY, AND ADDRESS-ERR-CODE attributes. o 440 (Address Family not Supported) and 443 (Peer Address Family Mismatch) responses. o More details on packet translation. o TCP-to-UDP and UDP-to-TCP relaying. 26. Acknowledgements Most of the text in this note comes from the original TURN specification, [RFC5766]. The authors would like to thank Rohan Mahy co-author of original TURN specification and everyone who had contributed to that document. The authors would also like to acknowledge that this document inherits material from [RFC6156]. Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang and Simon Perreault for their help on the ADDITIONAL-ADDRESS-FAMILY mechanism. Authors would like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox, Brandon Williams, Karl Stahl, Noriyuki Torii, Nils Ohlmeier, Dan Wing, Vijay Gurbani, Joseph Touch, Justin Uberti, Christopher Wood, Roman Danyliw, Eric Vyncke, Adam Roach, Suresh Krishnan, Mirja Kuehlewind, Benjamin Kaduk and Oleg Moskalenko for comments and review. The authors would like to thank Marc for his contributions to the text. Special thanks to Magnus Westerlund for the detailed AD review. 27. References 27.1. Normative References [I-D.ietf-tram-stunbis] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21 (work in progress), March 2019. [Protocol-Numbers] "IANA Protocol Numbers Registry", 2005, . Reddy, et al. Expires January 28, 2020 [Page 86] Internet-Draft TURN July 2019 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. Jones, "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065, November 2013, . Reddy, et al. Expires January 28, 2020 [Page 87] Internet-Draft TURN July 2019 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 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, . [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, . [RFC7982] Martinsen, P., Reddy, T., Wing, D., and V. Singh, "Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)", RFC 7982, DOI 10.17487/RFC7982, September 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 27.2. Informative References Reddy, et al. Expires January 28, 2020 [Page 88] Internet-Draft TURN July 2019 [Frag-Harmful] Kent, C. and J. Mogul, ""Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524", August 1987, . [I-D.ietf-intarea-frag-fragile] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", draft- ietf-intarea-frag-fragile-15 (work in progress), July 2019. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-36 (work in progress), June 2019. [I-D.ietf-mptcp-rfc6824bis] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work in progress), June 2019. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-12 (work in progress), July 2019. [I-D.ietf-tram-stun-pmtud] Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", draft- ietf-tram-stun-pmtud-10 (work in progress), September 2018. [I-D.ietf-tsvwg-udp-options] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- udp-options-07 (work in progress), March 2019. [Port-Numbers] "IANA Port Numbers Registry", 2005, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . Reddy, et al. Expires January 28, 2020 [Page 89] Internet-Draft TURN July 2019 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [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, . [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, . [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, . [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 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, . [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, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 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, . Reddy, et al. Expires January 28, 2020 [Page 90] Internet-Draft TURN July 2019 [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, . [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, . [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, . [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, DOI 10.17487/RFC5766, April 2010, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, DOI 10.17487/RFC5928, August 2010, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, DOI 10.17487/RFC6062, November 2010, . [RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, DOI 10.17487/RFC6156, April 2011, . Reddy, et al. Expires January 28, 2020 [Page 91] Internet-Draft TURN July 2019 [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, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, . [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays around NAT (TURN) Server Auto Discovery", RFC 8155, DOI 10.17487/RFC8155, April 2017, . [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . Reddy, et al. Expires January 28, 2020 [Page 92] Internet-Draft TURN July 2019 Authors' Addresses Tirumaleswar Reddy (editor) McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: kondtir@gmail.com Alan Johnston (editor) Villanova University Villanova, PA USA Email: alan.b.johnston@gmail.com Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario Canada Email: philip_matthews@magma.ca Jonathan Rosenberg jdrosen.net Edison, NJ USA Email: jdrosen@jdrosen.net URI: http://www.jdrosen.net Reddy, et al. Expires January 28, 2020 [Page 93] ./draft-ietf-trill-ecn-support-07.txt0000644000764400076440000010204213244635507016772 0ustar iustyiusty TRILL Working Group Donald Eastlake INTERNET-DRAFT Huawei Intended status: Proposed Standard Bob Briscoe CableLabs Expires: August 24, 2018 February 25, 2018 TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support Abstract Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document extends ECN to TRILL (TRansparent Interconnection of Lots of Links) switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179). Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list . 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. D. Eastlake & B. Briscoe [Page 1] INTERNET-DRAFT TRILL ECN Support Table of Contents 1. Introduction............................................3 1.1 Conventions used in this document......................4 2. The ECN Specific Extended Header Flags..................6 3. ECN Support.............................................7 3.1 Ingress ECN Support....................................7 3.2 Transit ECN Support....................................7 3.3 Egress ECN Support.....................................8 3.3.1 Non-ECN Egress RBridges..............................8 3.3.2 ECN Egress RBridges..................................8 4. TRILL Support for ECN Variants.........................11 4.1 Pre-Congestion Notification (PCN).....................11 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......12 5. IANA Considerations....................................13 6. Security Considerations................................14 7. Acknowledgements.......................................14 Normative References......................................15 Informative References....................................16 Appendix A. TRILL Transit RBridge Behavior to Support L4S.17 Authors' Addresses........................................19 D. Eastlake & B. Briscoe [Page 2] INTERNET-DRAFT TRILL ECN Support 1. Introduction Explicit congestion notification (ECN [RFC3168] [RFC8311]) allows a forwarding element (such as a router) to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. The forwarding element can explicitly mark a proportion of packets in an ECN field instead of dropping the packet. For example, a two-bit field is available for ECN marking in IP headers. ............................. . . +---------+ . +------+ | Ingress | . |Source| +->| RBridge | . +----------+ +---+--+ | | RB1 | . |Forwarding| | | +------+--+ +----------+ . | Element | v | . | | Transit | . | Y | +-------+--+ . +---->| RBridges | . +--------+-+ |Forwarding| . | RBn | . ^ | | Element | . +-------+--+ +---------+ | v | X | . | | Egress | | +-----------+ +----------+ . +---->| RBridge +-+ |Destination| . | RB9 | +-----------+ . TRILL +---------+ . campus . ............................. Figure 1. Example Path Forwarding Nodes In [RFC3168], it was recognized that tunnels and lower layer protocols would need to support ECN, and ECN markings would need to be propagated, as headers were encapsulated and decapsulated. [ECNencapGuide] gives guidelines on the addition of ECN to protocols like TRILL (TRansparent Interconnection of Lots of Links) that often encapsulate IP packets, including propagation of ECN from and to IP. In the figure above, assuming IP traffic, RB1 is an encapsulator and RB9 a decapsulator. Traffic from Source to RB1 might or might not get marked as having experienced congestion in forwarding elements, such as X, before being encapsulated at ingress RB1. Any such ECN marking is encapsulated with a TRILL Header [RFC6325]. This document specifies how ECN marking in traffic at the ingress is copied into the TRILL Extension Header Flags Word and requires such copying for IP traffic. It also enables congestion marking by a congested RBridge such as RBn or RB1 above in the TRILL Header Extension Flags Word [RFC7179]. D. Eastlake & B. Briscoe [Page 3] INTERNET-DRAFT TRILL ECN Support At RB9, the TRILL egress, it specifies how any ECN markings in the TRILL Header Flags Word and in the encapsulated traffic are combined so that subsequent forwarding elements, such as Y and the Destination, can see if congestion was experienced at any previous point in the path from Source. A large part of the guidelines for adding ECN to lower layer protocols [ECNencapGuide] concerns safe propagation of congestion notifications in scenarios where some of the nodes do not support or understand ECN. Such ECN ignorance is not a major problem with RBridges using this specification because the method specified assures that, if an egress RBridge is ECN ignorant (so it cannot further propagate ECN) and congestion has been encountered, the egress RBridge will at least drop the packet and this drop will itself indicate congestion to end stations. 1.1 Conventions used in this document The terminology and acronyms defined in [RFC6325] are used herein with the same meaning. In this documents, "IP" refers to both IPv4 and IPv6. 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] [RFC8174] when, and only when, they appear in all capitals, as shown here. Acronyms: AQM - Active Queue Management CCE - Critical Congestion Experienced CE - Congestion Experienced CItE - Critical Ingress-to-Egress ECN - Explicit Congestion Notification ECT - ECN Capable Transport L4S - Low Latency, Low Loss, Scalable throughput NCHbH - Non-Critical Hop-by-Hop NCCE - Non-Critical Congestion Experienced D. Eastlake & B. Briscoe [Page 4] INTERNET-DRAFT TRILL ECN Support Not-ECT - Not ECN-Capable Transport PCN - Pre-Congestion Notification D. Eastlake & B. Briscoe [Page 5] INTERNET-DRAFT TRILL ECN Support 2. The ECN Specific Extended Header Flags The extension header fields for explicit congestion notification (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit Critical Congestion Experienced (CCE) field in the 32-bit TRILL Header Extension Flags Word [RFC7780]. These fields are shown in Figure 2 as "ECN" and "CCE". The TRILL-ECN field consists of bits 12 and 13, which are in the range reserved for non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 26, which is in the range reserved for Critical Ingress-to-Egress (CItE) bits. The CRItE bit is the critical Ingress-to-Egress summary bit and will be one if and only if any of the bits in the CItE range (21-26) are one or there is a critical feature invoked in some further extension of the TRILL Header after the Extension Flags Word. The other bits and fields shown in Figure 2 are not relevant to ECN. See [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these other bits and 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | |.....|.........|...........|.....|.......|...........|.........| |C|C|C| |C|N| | | | | | | | | |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | |H|I|R| |C|C| | | Hop | | |C|Clr| | |b|t|s| |A|A| | | Cnt | | |E| | | |H|E|v| |F|F| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The TRILL-ECN and CCE TRILL Header Extension Flags Word Fields Table 1 shows the meaning of the codepoints in the TRILL-ECN field. The first three have the same meaning as the corresponding ECN field codepoints in the IP header as defined in [RFC3168]. However, codepoint 0b11 is called Non-Critical Congestion Experienced (NCCE) to distinguish it from Congestion Experienced in IP. Binary Name Meaning ------ ------- ----------------------------------- 00 Not-ECT Not ECN-Capable Transport 01 ECT(1) ECN-Capable Transport (1) 10 ECT(0) ECN-Capable Transport (0) 11 NCCE Non-Critical Congestion Experienced Table 1. TRILL-ECN Field Codepoints D. Eastlake & B. Briscoe [Page 6] INTERNET-DRAFT TRILL ECN Support 3. ECN Support This section specifies interworking between TRILL and the original standardized form of ECN in IP [RFC3168]. The subsections below describe the required behavior to support ECN at TRILL ingress, transit, and egress. The ingress behavior occurs as a native frame is encapsulated with a TRILL Header to produce a TRILL Data packet. The transit behavior occurs in all RBridges where TRILL Data packets are queued, usually at the output port. The egress behavior occurs where a TRILL Data packet is decapsulated and output as a native frame through an RBridge port. An RBridge that supports ECN MUST behave as described in the relevant subsections below, which correspond to the recommended provisions in Section 3 and Sections 5.1-5.4 of [ECNencapGuide]. Nonetheless, the scheme is designed to safely propagate some form of congestion notification even if some RBridges in the path followed by a TRILL Data packet support ECN and others do not. 3.1 Ingress ECN Support The behavior at an ingress RBridge is as follows: o When encapsulating an IP frame, the ingress RBridge MUST: + set the F flag in the main TRILL header [RFC7780]; + create a Flags Word as part of the TRILL Header; + copy the two ECN bits from the IP header into the TRILL-ECN field (Flags Word bits 12 and 13) + ensure the CCE flag is set to zero (Flags Word bit 26). o When encapsulating a frame for a non-IP protocol, where that protocol has a means of indicating ECN that is understood by the ingress RBridge, it MUST follow the guidelines in Section 5.3 of [ECNencapGuide] to add a Flags Word to the TRILL Header. For a non-IP protocol with a similar ECN field to IP, this would be achieved by copying into the TRILL-ECN field from the encapsulated native frame. 3.2 Transit ECN Support The transit behavior, shown below, is required at all RBridges where TRILL Data packets are queued, usually at the output port. o An RBridge that supports ECN MUST implement some form of active D. Eastlake & B. Briscoe [Page 7] INTERNET-DRAFT TRILL ECN Support queue management (AQM) according to the guidelines of [RFC7567]. The RBridge detects congestion either by monitoring its own queue depth or by participating in a link-specific protocol. o If the TRILL Header Flags Word is present, whenever the AQM algorithm decides to indicate congestion on a TRILL Data packet it MUST set the CCE flag (Flags Word bit 26). o If the TRILL header Flags Word is not present, to indicate congestion the RBridge will either drop the packet or it MAY do all of the following instead: + set the F flag in the main TRILL header; + add a Flags Word to the TRILL Header; + set the TRILL-ECN field to Not-ECT (00); + and set the CCE flag and the Ingress-to-Egress critical summary bit (CRIbE). Note that a transit RBridge that supports ECN does not refer to the TRILL-ECN field before signaling CCE in a packet. It signals CCE irrespective of whether the packet indicates that the transport is ECN-capable. The egress/decapsulation behavior (described next) ensures that a CCE indication is converted to a drop if the transport is not ECN-capable. 3.3 Egress ECN Support 3.3.1 Non-ECN Egress RBridges If the egress RBridge does not support ECN, that RBridge will ignore bits 12 and 13 of any Flags Word that is present, because it does not contain any special ECN logic. Nonetheless, if a transit RBridge has set the CCE flag, the egress will drop the packet. This is because drop is the default behavior for an RBridge decapsulating a Critical Ingress-to-Egress flag when it has no specific logic to understand it. Drop is the intended behavior for such a packet, as required by Section 5.4 of [ECNencapGuide]. 3.3.2 ECN Egress RBridges If an RBridge supports ECN, for the two cases of an IP and a non-IP inner packet, the egress behavior is as follows: Decapsulating an inner IP packet: The RBridge sets the ECN field D. Eastlake & B. Briscoe [Page 8] INTERNET-DRAFT TRILL ECN Support of the outgoing native IP packet using Table 3. It MUST set the ECN field of the outgoing IP packet to the codepoint at the intersection of the row for the arriving encapsulated IP packet and the column for 3-bit ECN codepoint in the arriving outer TRILL Data packet TRILL Header. If no TRILL Header Extension Flags Word is present, the 3-bit ECN codepoint is assumed to be all zero bits. The name of the TRILL 3-bit ECN codepoint is defined using the combination of the TRILL-ECN and CCE fields in Table 2. Specifically, the TRILL 3-bit ECN codepoint is called CE if either NCCE or CCE is set in the TRILL Header Extension Flags Word. Otherwise it has the same name as the 2-bit TRILL-ECN codepoint. In the case where the TRILL 3-bit ECN codepoint indicates congestion experienced (CE) but the encapsulated native IP frame indicates a not ECN-capable transport (Not-ECT), it can be seen that the RBridge MUST drop the packet. Such packet dropping is necessary because a transport above the IP layer that is not ECN-capable will have no ECN logic, so it will only understand dropped packets as an indication of congestion. Decapsulating a non-IP protocol frame: If the frame has a means of indicating ECN that is understood by the RBridge, it MUST follow the guidelines in Section 5.4 of [ECNencapGuide] when setting the ECN information in the decapsulated native frame. For a non-IP protocol with a similar ECN field to IP, this would be achieved by combining the information in the TRILL Header Flags Word with the encapsulated non-IP native frame, as specified in Table 3. +------------+-----+---------------------+ | TRILL-ECN | CCE | Arriving TRILL 3-bit| | | | ECN codepoint name | +------------+-----+---------------------+ | Not-ECT 00 | 0 | Not-ECT | | ECT(1) 01 | 0 | ECT(1) | | ECT(0) 10 | 0 | ECT(0) | | NCCE 11 | 0 | CE | | Not-ECT 00 | 1 | CE | | ECT(1) 01 | 1 | CE | | ECT(0) 10 | 1 | CE | | NCCE 11 | 1 | CE | +------------+-----+---------------------+ Table 2. Mapping of TRILL-ECN and CCE Fields to the TRILL 3-bit ECN Codepoint Name D. Eastlake & B. Briscoe [Page 9] INTERNET-DRAFT TRILL ECN Support +---------+----------------------------------------------+ | Inner | Arriving TRILL 3-bit ECN Codepoint Name | | Native +---------+------------+------------+----------+ | Header | Not-ECT | ECT(0) | ECT(1) | CE | +---------+---------+------------+------------+----------+ | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | | CE | CE | CE | CE(*) | CE | +---------+---------+------------+------------+----------+ Table 3. Egress ECN Behavior An asterisk in the above table indicates a combination that is currently unused in all variants of ECN marking (see Section 4) and therefore SHOULD be logged. With one exception, the mappings in Table 3 are consistent with those for IP-in-IP tunnels [RFC6040], which ensures backward compatibility with all current and past variants of ECN marking (see Section 4). It also ensures forward compatibility with any future form of ECN marking that complies with the guidelines in [ECNencapGuide], including cases where ECT(1) represents a second level of marking severity below CE. The one exception is that the drop condition in Table 3 need not be logged because, with TRILL, it is the result of a valid combination of events. D. Eastlake & B. Briscoe [Page 10] INTERNET-DRAFT TRILL ECN Support 4. TRILL Support for ECN Variants This section is informative, not normative; it discusses interworking between TRILL and variants of the standardized form of ECN in IP [RFC3168]. See also [RFC8311]. The ECN wire protocol for TRILL (Section 2) and the ingress (Section 3.1) and egress (Section 3.3) ECN behaviors have been designed to support the other known variants of ECN, as detailed below. New variants of ECN will have to comply with the guidelines for defining alternative ECN semantics [RFC4774]. It is expected that the TRILL ECN wire protocol is generic enough to support such potential future variants. 4.1 Pre-Congestion Notification (PCN) The PCN wire protocol [RFC6660] is recognized by the use of a PCN- compatible Diffserv codepoint in the IP header and a non-zero IP-ECN field. For TRILL or any lower layer protocol, equivalent traffic classification codepoints would have to be defined, but that is outside the scope of the current document. The PCN wire protocol is similar to ECN, except it indicates congestion with two levels of severity. It uses: o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) codepoint o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked (ThM) codepoint. (This difference between ECT(1) and ECT(0) only applies to PCN, not to the classic ECN support specified for TRILL in this document before Section 4.) To implement PCN on a transit RBridge would require a detailed specification. But in brief: o the TRILL Critical Congestion Experienced (CCE) flag would be used for the Excess-Traffic-Marked (ETM) codepoint; o ECT(1) in the TRILL-ECN field would be used for the Threshold- Marked codepoint. Then the ingress and egress behaviors defined in Section 3 would not need to be altered to ensure support for PCN as well as ECN. D. Eastlake & B. Briscoe [Page 11] INTERNET-DRAFT TRILL ECN Support 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) L4S is currently on the IETF's experimental track. An outline of how a transit TRILL RBridge would support L4S [ECNL4S] is given in Appendix A. D. Eastlake & B. Briscoe [Page 12] INTERNET-DRAFT TRILL ECN Support 5. IANA Considerations IANA is requested to update the TRILL Extended Header Flags registry by replacing the lines for bits 9-13 and for bits 21-26 with the following: Bits Purpose Reference ----- ------- --------- 9-11 available non-critical hop-by-hop flags 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 21-25 available critical ingress-to-egress flags 26 Critical Congestion Experienced (CCE) [this doc] D. Eastlake & B. Briscoe [Page 13] INTERNET-DRAFT TRILL ECN Support 6. Security Considerations TRILL support of ECN is a straightforward combination of previously specified ECN and TRILL with no significant new security considerations. For ECN tunneling security considerations, see [RFC6040]. For general TRILL protocol security considerations, see [RFC6325]. 7. Acknowledgements The helpful comments of Loa Andersson and Adam Roach are hereby acknowledged. This document was prepared with basic NROFF. All macros used were defined in the source file. D. Eastlake & B. Briscoe [Page 14] INTERNET-DRAFT TRILL ECN Support 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, . [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, . [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, . [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, . [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, . [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, . [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, . [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, work in progress. D. Eastlake & B. Briscoe [Page 15] INTERNET-DRAFT TRILL ECN Support Informative References [ECNL4S] - K. De Schepper, B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queueing Delay", draft-ietf-tsvwg-ecn-l4s-id, work in progress. [IANAthFlags] - IANA TRILL Extended Header word flags: http://www.iana.org/assignments/trill-parameters/trill- parameters.xhtml#extended-header-flags [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, . D. Eastlake & B. Briscoe [Page 16] INTERNET-DRAFT TRILL ECN Support Appendix A. TRILL Transit RBridge Behavior to Support L4S The specification of the Low Latency, Low Loss, Scalable throughput (L4S) wire protocol for IP is given in [ECNL4S]. L4S is one example of the ways TRILL ECN handling may evolve [RFC8311]. It is similar to the original ECN wire protocol for IP [RFC3168], except: o An AQM that supports L4S classifies packets with ECT(1) or CE in the IP header into an L4S queue and a "Classic" queue otherwise. o The meaning of CE markings applied by an L4S queue is not the same as the meaning of a drop by a "Classic" queue (contrary to the original requirement for ECN [RFC3168]). Instead, the likelihood that the Classic queue drops packets is defined as the square of the likelihood that the L4S queue marks packets (e.g., when there is a drop probability of 0.0009 (0.09%) the L4S marking probability will be 0.03 (3%)). This seems to present a problem for the way that a transit TRILL RBridge defers the choice between marking and dropping to the egress. Nonetheless, the following pseudocode outlines how a transit TRILL RBridge can implement L4S marking in such a way that the egress behavior already described in Section 3.3 for Classic ECN [RFC3168] will produce the desired outcome. /* p is an internal variable calculated by any L4S AQM * dependent on the delay being experienced in the Classic queue. * bit13 is the least significant bit of the TRILL-ECN field */ % On TRILL transit if (bit13 == 0 ) { % Classic Queue if (p > max(random(), random()) ) mark(CCE) % likelihood: p^2 } else { % L4S Queue if (p > random() ) { if (p > random() ) mark(CCE) % likelihood: p^2 else mark(NCCE) % likelihood: p - p^2 } } With the above transit behavior, an egress that supports ECN (Section 3.3) will drop packets or propagate their ECN markings depending on whether the arriving inner header is from a non-ECN-capable or ECN- capable transport. D. Eastlake & B. Briscoe [Page 17] INTERNET-DRAFT TRILL ECN Support Even if an egress has no L4S-specific logic of its own, it will drop packets with the square of the probability that an egress would if it did support ECN, for the following reasons: o Egress with ECN support: + L4S: propagates both the Critical and Non-Critical CE marks (CCE & NCCE) as a CE mark. Likelihood: p^2 + p - p^2 = p + Classic: Propagates CCE marks as CE or drop, depending on inner. Likelihood: p^2 o Egress without ECN support: + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. Likelihood: p^2 + Classic: drops CCE marks. Likelihood: p^2 D. Eastlake & B. Briscoe [Page 18] INTERNET-DRAFT TRILL ECN Support Authors' Addresses Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Tel: +1-508-333-2270 Email: d3e3e3@gmail.com Bob Briscoe CableLabs UK Email: ietf@bobbriscoe.net URI: http://bobbriscoe.net/ D. Eastlake & B. Briscoe [Page 19] INTERNET-DRAFT TRILL ECN Support Copyright and IPR Provisions Copyright (c) 2018 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. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake & B. Briscoe [Page 20] ./draft-ietf-tsvwg-fecframe-ext-08.txt0000644000764400076440000013135013416072764017113 0ustar iustyiusty TSVWG V. Roca Internet-Draft INRIA Updates: 6363 (if approved) A. Begen Intended status: Standards Track Networked Media Expires: July 15, 2019 January 11, 2019 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes draft-ietf-tsvwg-fecframe-ext-08 Abstract RFC 6363 describes a framework for using Forward Error Correction (FEC) codes 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. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC Codes based on a sliding encoding window, in addition to Block FEC Codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency. 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 https://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 15, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Roca & Begen Expires July 15, 2019 [Page 1] Internet-Draft FEC Framework Extension January 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Definitions and Abbreviations . . . . . . . . . . . . . . . . 4 3. Summary of Architecture Overview . . . . . . . . . . . . . . 7 4. Procedural Overview . . . . . . . . . . . . . . . . . . . . . 10 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Sender Operation with Sliding Window FEC Codes . . . . . 10 4.3. Receiver Operation with Sliding Window FEC Codes . . . . 13 5. Protocol Specification . . . . . . . . . . . . . . . . . . . 15 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. FEC Framework Configuration Information . . . . . . . . . 16 5.3. FEC Scheme Requirements . . . . . . . . . . . . . . . . . 16 6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Transport Protocols . . . . . . . . . . . . . . . . . . . . . 17 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Operations and Management Considerations . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. About Sliding Encoding Window Management (informational) . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Many applications need to transport a continuous stream of packetized data from a source (sender) to one or more destinations (receivers) over networks that do not provide guaranteed packet delivery. In particular packets may be lost, which is strictly the focus of this document: we assume that transmitted packets are either lost (e.g., because of a congested router, of a poor signal-to-noise ratio in a wireless network, or because the number of bit errors exceeds the correction capabilities of the physical-layer error correcting code) Roca & Begen Expires July 15, 2019 [Page 2] Internet-Draft FEC Framework Extension January 2019 or received by the transport protocol without any corruption (i.e., the bit-errors, if any, have been fixed by the physical-layer error correcting code and therefore are hidden to the upper layers). For these use-cases, Forward Error Correction (FEC) applied within the transport or application layer is an efficient technique to improve packet transmission robustness in presence of packet losses (or "erasures"), without going through packet retransmissions that create a delay often incompatible with real-time constraints. The FEC Building Block defined in [RFC5052] provides a framework for the definition of Content Delivery Protocols (CDPs) that make use of separately-defined FEC schemes. Any CDP defined according to the requirements of the FEC Building Block can then easily be used with any FEC Scheme that is also defined according to the requirements of the FEC Building Block. Then FECFRAME [RFC6363] provides a framework to define Content Delivery Protocols (CDPs) that provide FEC protection for arbitrary packet flows over an unreliable datagram service transport such as UDP. It is primarily intended for real-time or streaming media applications, using broadcast, multicast, or on-demand delivery. However, [RFC6363] only considers block FEC schemes defined in accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681], [RFC6816] or [RFC6865]). These codes require the input flow(s) to be segmented into a sequence of blocks. Then FEC encoding (at a sender or an encoding middlebox) and decoding (at a receiver or a decoding middlebox) are both performed on a per-block basis. For instance, if the current block encompasses the 100's to 119's source symbols (i.e., a block of size 20 symbols) of an input flow, encoding (and decoding) will be performed on this block independently of other blocks. This approach has major impacts on FEC encoding and decoding delays. The data packets of continuous media flow(s) may be passed to the transport layer immediately, without delay. But the block creation time, that depends on the number of source symbols in this block, impacts both the FEC encoding delay (since encoding requires that all source symbols be known), and mechanically the packet loss recovery delay at a receiver (since no repair symbol for the current block can be generated and therefore received before that time). Therefore a good value for the block size is necessarily a balance between the maximum FEC decoding latency at the receivers (which must be in line with the most stringent real-time requirement of the protected flow(s), hence an incentive to reduce the block size), and the desired robustness against long loss bursts (which increases with the block size, hence an incentive to increase this size). This document updates [RFC6363] in order to also support FEC codes based on a sliding encoding window (A.K.A. convolutional codes) Roca & Begen Expires July 15, 2019 [Page 3] Internet-Draft FEC Framework Extension January 2019 [RFC8406]. This encoding window, either of fixed or variable size, slides over the set of source symbols. FEC encoding is launched whenever needed, from the set of source symbols present in the sliding encoding window at that time. This approach significantly reduces FEC-related latency, since repair symbols can be generated and passed to the transport layer on-the-fly, at any time, and can be regularly received by receivers to quickly recover packet losses. Using sliding window FEC codes is therefore highly beneficial to real-time flows, one of the primary targets of FECFRAME. [RLC-ID] provides an example of such FEC Scheme for FECFRAME, built upon the simple sliding window Random Linear Codes (RLC). This document is fully backward compatible with [RFC6363]. Indeed: o this FECFRAME update does not prevent nor compromise in any way the support of block FEC codes. Both types of codes can nicely co-exist, just like different block FEC schemes can co-exist; o each sliding window FEC Scheme is associated to a specific FEC Encoding ID subject to IANA registration, just like block FEC Schemes; o any receiver, for instance a legacy receiver that only supports block FEC schemes, can easily identify the FEC Scheme used in a FECFRAME session. Indeed, the FEC Encoding ID that identifies the FEC Scheme is carried in the FEC Framework Configuration Information (see section 5.5 of [RFC6363]). For instance, when the Session Description Protocol (SDP) is used to carry the FEC Framework Configuration Information, the FEC Encoding ID can be communicated in the "encoding-id=" parameter of a "fec-repair- flow" attribute [RFC6364]. This mechanism is the basic approach for a FECFRAME receiver to determine whether or not it supports the FEC Scheme used in a given FECFRAME session; This document leverages on [RFC6363] and re-uses its structure. It proposes new sections specific to sliding window FEC codes whenever required. The only exception is Section 3 that provides a quick summary of FECFRAME in order to facilitate the understanding of this document to readers not familiar with the concepts and terminology. 2. Definitions and Abbreviations The following list of definitions and abbreviations is copied from [RFC6363], adding only the Block/sliding window FEC Code and Encoding/Decoding Window definitions (tagged with "ADDED"): Application Data Unit (ADU): The unit of source data provided as payload to the transport layer. For instance, it can be a Roca & Begen Expires July 15, 2019 [Page 4] Internet-Draft FEC Framework Extension January 2019 payload containing the result of the RTP packetization of a compressed video frame. ADU Flow: A sequence of ADUs associated with a transport-layer flow identifier (such as the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}). AL-FEC: Application-layer Forward Error Correction. Application Protocol: Control protocol used to establish and control the source flow being protected, e.g., the Real-Time Streaming Protocol (RTSP). Content Delivery Protocol (CDP): A complete application protocol specification that, through the use of the framework defined in this document, is able to make use of FEC schemes to provide FEC capabilities. FEC Code: An algorithm for encoding data such that the encoded data flow is resilient to data loss. Note that, in general, FEC codes may also be used to make a data flow resilient to corruption, but that is not considered in this document. Block FEC Code: (ADDED) An FEC Code that operates on blocks, i.e., for which the input flow MUST be segmented into a sequence of blocks, FEC encoding and decoding being performed independently on a per-block basis. Sliding Window FEC Code: (ADDED) An FEC Code that can generate repair symbols on-the-fly, at any time, from the set of source symbols present in the sliding encoding window at that time. These codes are also known as convolutional codes. FEC Framework: A protocol framework for the definition of Content Delivery Protocols using FEC, such as the framework defined in this document. FEC Framework Configuration Information: Information that controls the operation of the FEC Framework. FEC Payload ID: Information that identifies the contents and provides positional information of a packet with respect to the FEC Scheme. FEC Repair Packet: At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport Roca & Begen Expires July 15, 2019 [Page 5] Internet-Draft FEC Framework Extension January 2019 protocol containing one or more repair symbols along with a Repair FEC Payload ID and possibly an RTP header. FEC Scheme: A specification that defines the additional protocol aspects required to use a particular FEC code with the FEC Framework. FEC Source Packet: At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an optional Explicit Source FEC Payload ID. Repair Flow: The packet flow carrying FEC data. Repair FEC Payload ID: A FEC Payload ID specifically for use with repair packets. Source Flow: The packet flow to which FEC protection is to be applied. A source flow consists of ADUs. Source FEC Payload ID: A FEC Payload ID specifically for use with source packets. Source Protocol: A protocol used for the source flow being protected, e.g., RTP. Transport Protocol: The protocol used for the transport of the source and repair flows, using an unreliable datagram service such as UDP. Encoding Window: (ADDED) Set of Source Symbols available at the sender/coding node that are used to generate a repair symbol, with a Sliding Window FEC Code. Decoding Window: (ADDED) Set of received or decoded source and repair symbols available at a receiver that are used to decode erased source symbols, with a Sliding Window FEC Code. Code Rate: The ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that 0 < code rate <= 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process. Encoding Symbol: Unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols. Roca & Begen Expires July 15, 2019 [Page 6] Internet-Draft FEC Framework Extension January 2019 Packet Erasure Channel: A communication path where packets are either lost (e.g., in our case, by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical-layer code) or received. When a packet is received, it is assumed that this packet is not corrupted (i.e., in our case, the bit-errors, if any, are fixed by the physical-layer code and therefore hidden to the upper layers). Repair Symbol: Encoding symbol that is not a source symbol. Source Block: Group of ADUs that are to be FEC protected as a single block. This notion is restricted to Block FEC Codes. Source Symbol: Unit of data used during the encoding process. Systematic Code: FEC code in which the source symbols are part of the encoding symbols. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Summary of Architecture Overview The architecture of [RFC6363], Section 3, equally applies to this FECFRAME extension and is not repeated here. However, we provide hereafter a quick summary to facilitate the understanding of this document to readers not familiar with the concepts and terminology. Roca & Begen Expires July 15, 2019 [Page 7] Internet-Draft FEC Framework Extension January 2019 +----------------------+ | Application | +----------------------+ | | (1) Application Data Units (ADUs) | v +----------------------+ +----------------+ | FEC Framework | | | | |-------------------------->| FEC Scheme | |(2) Construct source |(3) Source Block | | | blocks | |(4) FEC Encoding| |(6) Construct FEC |<--------------------------| | | Source and Repair | | | | Packets |(5) Explicit Source FEC | | +----------------------+ Payload IDs +----------------+ | Repair FEC Payload IDs | Repair symbols | |(7) FEC Source and Repair Packets v +----------------------+ | Transport Protocol | +----------------------+ Figure 1: FECFRAME architecture at a sender. The FECFRAME architecture is illustrated in Figure 1 from the sender's point of view, in case of a block FEC Scheme. It shows an application generating an ADU flow (other flows, from other applications, may co-exist). These ADUs, of variable size, must be somehow mapped to source symbols of fixed size (this fixed size is a requirement of all FEC Schemes that comes from the way mathematical operations are applied to symbols content). This is the goal of an ADU-to-symbols mapping process that is FEC-Scheme specific (see below). Once the source block is built, taking into account both the FEC Scheme constraints (e.g., in terms of maximum source block size) and the application's flow constraints (e.g., in terms of real-time constraints), the associated source symbols are handed to the FEC Scheme in order to produce an appropriate number of repair symbols. FEC Source Packets (containing ADUs) and FEC Repair Packets (containing one or more repair symbols each) are then generated and sent using an appropriate transport protocol (more precisely [RFC6363], Section 7, requires a transport protocol providing an unreliable datagram service, such as UDP). In practice FEC Source Packets may be passed to the transport layer as soon as available, without having to wait for FEC encoding to take place. In that case Roca & Begen Expires July 15, 2019 [Page 8] Internet-Draft FEC Framework Extension January 2019 a copy of the associated source symbols needs to be kept within FECFRAME for future FEC encoding purposes. At a receiver (not shown), FECFRAME processing operates in a similar way, taking as input the incoming FEC Source and Repair Packets received. In case of FEC Source Packet losses, the FEC decoding of the associated block may recover all (in case of successful decoding) or a subset potentially empty (otherwise) of the missing source symbols. After source-symbol-to-ADU mapping, when lost ADUs are recovered, they are then assigned to their respective flow (see below). ADUs are returned to the application(s), either in their initial transmission order (in that case ADUs received after an erased one will be delayed until FEC decoding has taken place) or not (in that case each ADU is returned as soon as it is received or recovered), depending on the application requirements. FECFRAME features two subtle mechanisms: o ADUs-to-source-symbols mapping: in order to manage variable size ADUs, FECFRAME and FEC Schemes can use small, fixed size symbols and create a mapping between ADUs and symbols. To each ADU this mechanism prepends a length field (plus a flow identifier, see below) and pads the result to a multiple of the symbol size. A small ADU may be mapped to a single source symbol while a large one may be mapped to multiple symbols. The mapping details are FEC-Scheme-dependent and must be defined in the associated document; o Assignment of decoded ADUs to flows in multi-flow configurations: when multiple flows are multiplexed over the same FECFRAME instance, a problem is to assign a decoded ADU to the right flow (UDP port numbers and IP addresses traditionally used to map incoming ADUs to flows are not recovered during FEC decoding). To make it possible, at the FECFRAME sending instance, each ADU is prepended with a flow identifier (1 byte) during the ADU-to- source-symbols mapping (see above). The flow identifiers are also shared between all FECFRAME instances as part of the FEC Framework Configuration Information. This (flow identifier + length + application payload + padding), called ADUI, is then FEC protected. Therefore a decoded ADUI contains enough information to assign the ADU to the right flow. A few aspects are not covered by FECFRAME, namely: o [RFC6363] section 8 does not detail any congestion control mechanism, but only provides high level normative requirements; Roca & Begen Expires July 15, 2019 [Page 9] Internet-Draft FEC Framework Extension January 2019 o the possibility of having feedbacks from receiver(s) is considered out of scope, although such a mechanism may exist within the application (e.g., through RTCP control messages); o flow adaptation at a FECFRAME sender (e.g., how to set the FEC code rate based on transmission conditions) is not detailed, but it needs to comply with the congestion control normative requirements (see above). 4. Procedural Overview 4.1. General The general considerations of [RFC6363], Section 4.1, that are specific to block FEC codes are not repeated here. With a Sliding Window FEC Code, the FEC Source Packet MUST contain information to identify the position occupied by the ADU within the source flow, in terms specific to the FEC Scheme. This information is known as the Source FEC Payload ID, and the FEC Scheme is responsible for defining and interpreting it. With a Sliding Window FEC Code, the FEC Repair Packets MUST contain information that identifies the relationship between the contained repair payloads and the original source symbols used during encoding. This information is known as the Repair FEC Payload ID, and the FEC Scheme is responsible for defining and interpreting it. The Sender Operation ([RFC6363], Section 4.2.) and Receiver Operation ([RFC6363], Section 4.3) are both specific to block FEC codes and therefore omitted below. The following two sections detail similar operations for Sliding Window FEC codes. 4.2. Sender Operation with Sliding Window FEC Codes With a Sliding Window FEC Scheme, the following operations, illustrated in Figure 2 for the generic case (non-RTP repair flows), and in Figure 3 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows: 1. A new ADU is provided by the application. 2. The FEC Framework communicates this ADU to the FEC Scheme. 3. The sliding encoding window is updated by the FEC Scheme. The ADU-to-source-symbols mapping as well as the encoding window management details are both the responsibility of the FEC Scheme Roca & Begen Expires July 15, 2019 [Page 10] Internet-Draft FEC Framework Extension January 2019 and MUST be detailed there. Appendix A provides non-normative hints about what FEC Scheme designers need to consider; 4. The Source FEC Payload ID information of the source packet is determined by the FEC Scheme. If required by the FEC Scheme, the Source FEC Payload ID is encoded into the Explicit Source FEC Payload ID field and returned to the FEC Framework. 5. The FEC Framework constructs the FEC Source Packet according to [RFC6363] Figure 6, using the Explicit Source FEC Payload ID provided by the FEC Scheme if applicable. 6. The FEC Source Packet is sent using normal transport-layer procedures. This packet is sent using the same ADU flow identification information as would have been used for the original source packet if the FEC Framework were not present (e.g., the source and destination addresses and UDP port numbers on the IP datagram carrying the source packet will be the same whether or not the FEC Framework is applied). 7. When the FEC Framework needs to send one or several FEC Repair Packets (e.g., according to the target Code Rate), it asks the FEC Scheme to create one or several repair packet payloads from the current sliding encoding window along with their Repair FEC Payload ID. 8. The Repair FEC Payload IDs and repair packet payloads are provided back by the FEC Scheme to the FEC Framework. 9. The FEC Framework constructs FEC Repair Packets according to [RFC6363] Figure 7, using the FEC Payload IDs and repair packet payloads provided by the FEC Scheme. 10. The FEC Repair Packets are sent using normal transport-layer procedures. The port(s) and multicast group(s) to be used for FEC Repair Packets are defined in the FEC Framework Configuration Information. Roca & Begen Expires July 15, 2019 [Page 11] Internet-Draft FEC Framework Extension January 2019 +----------------------+ | Application | +----------------------+ | | (1) New Application Data Unit (ADU) v +---------------------+ +----------------+ | FEC Framework | | FEC Scheme | | |-------------------------->| | | | (2) New ADU |(3) Update of | | | | encoding | | |<--------------------------| window | |(5) Construct FEC | (4) Explicit Source | | | Source Packet | FEC Payload ID(s) |(7) FEC | | |<--------------------------| encoding | |(9) Construct FEC | (8) Repair FEC Payload ID | | | Repair Packet(s) | + Repair symbol(s) +----------------+ +---------------------+ | | (6) FEC Source Packet | (10) FEC Repair Packets v +----------------------+ | Transport Protocol | +----------------------+ Figure 2: Sender Operation with Sliding Window FEC Codes Roca & Begen Expires July 15, 2019 [Page 12] Internet-Draft FEC Framework Extension January 2019 +----------------------+ | Application | +----------------------+ | | (1) New Application Data Unit (ADU) v +---------------------+ +----------------+ | FEC Framework | | FEC Scheme | | |-------------------------->| | | | (2) New ADU |(3) Update of | | | | encoding | | |<--------------------------| window | |(5) Construct FEC | (4) Explicit Source | | | Source Packet | FEC Payload ID(s) |(7) FEC | | |<--------------------------| encoding | |(9) Construct FEC | (8) Repair FEC Payload ID | | | Repair Packet(s) | + Repair symbol(s) +----------------+ +---------------------+ | | |(6) Source |(10) Repair payloads | packets | | + -- -- -- -- -+ | | RTP | | +-- -- -- -- --+ v v +----------------------+ | Transport Protocol | +----------------------+ Figure 3: Sender Operation with Sliding Window FEC Codes and RTP Repair Flows 4.3. Receiver Operation with Sliding Window FEC Codes With a Sliding Window FEC Scheme, the following operations, illustrated in Figure 4 for the generic case (non-RTP repair flows), and in Figure 5 for the case of RTP repair flows. The only differences with respect to block FEC codes lie in steps (4) and (5). Therefore this section does not repeat the other steps of [RFC6363], Section 4.3, "Receiver Operation". The new steps (4) and (5) are: 4. The FEC Scheme uses the received FEC Payload IDs (and derived FEC Source Payload IDs when the Explicit Source FEC Payload ID field is not used) to insert source and repair packets into the decoding window in the right way. If at least one source packet is missing and at least one repair packet has been received, then FEC decoding is attempted to recover missing source payloads. The FEC Scheme determines whether source packets have been lost Roca & Begen Expires July 15, 2019 [Page 13] Internet-Draft FEC Framework Extension January 2019 and whether enough repair packets have been received to decode any or all of the missing source payloads. 5. The FEC Scheme returns the received and decoded ADUs to the FEC Framework, along with indications of any ADUs that were missing and could not be decoded. +----------------------+ | Application | +----------------------+ ^ |(6) ADUs | +----------------------+ +----------------+ | FEC Framework | | FEC Scheme | | |<--------------------------| | |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding | IDs and pass IDs & |-------------------------->| | | payloads to FEC |(3) Explicit Source FEC +----------------+ | scheme | Payload IDs +----------------------+ Repair FEC Payload IDs ^ Source payloads | Repair payloads |(1) FEC Source | and Repair Packets +----------------------+ | Transport Protocol | +----------------------+ Figure 4: Receiver Operation with Sliding Window FEC Codes Roca & Begen Expires July 15, 2019 [Page 14] Internet-Draft FEC Framework Extension January 2019 +----------------------+ | Application | +----------------------+ ^ |(6) ADUs | +----------------------+ +----------------+ | FEC Framework | | FEC Scheme | | |<--------------------------| | |(2)Extract FEC Payload|(5) ADUs |(4) FEC Decoding| | IDs and pass IDs & |-------------------------->| | | payloads to FEC |(3) Explicit Source FEC +----------------+ | scheme | Payload IDs +----------------------+ Repair FEC Payload IDs ^ ^ Source payloads | | Repair payloads |Source pkts |Repair payloads | | +-- |- -- -- -- -- -- -+ |RTP| | RTP Processing | | | +-- -- -- --|-- -+ | +-- -- -- -- -- |--+ | | | RTP Demux | | +-- -- -- -- -- -- -- -+ ^ |(1) FEC Source and Repair Packets | +----------------------+ | Transport Protocol | +----------------------+ Figure 5: Receiver Operation with Sliding Window FEC Codes and RTP Repair Flows 5. Protocol Specification 5.1. General This section discusses the protocol elements for the FEC Framework specific to Sliding Window FEC schemes. The global formats of source data packets (i.e., [RFC6363], Figure 6) and repair data packets (i.e., [RFC6363], Figures 7 and 8) remain the same with Sliding Window FEC codes. They are not repeated here. Roca & Begen Expires July 15, 2019 [Page 15] Internet-Draft FEC Framework Extension January 2019 5.2. FEC Framework Configuration Information The FEC Framework Configuration Information considerations of [RFC6363], Section 5.5, equally applies to this FECFRAME extension and is not repeated here. 5.3. FEC Scheme Requirements The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply to this FECFRAME extension and are not repeated here. An exception though is the "full specification of the FEC code", item (4), that is specific to block FEC codes. The following item (4-bis) applies in case of Sliding Window FEC schemes: 4-bis. A full specification of the Sliding Window FEC code This specification MUST precisely define the valid FEC-Scheme- Specific Information values, the valid FEC Payload ID values, and the valid packet payload sizes (where packet payload refers to the space within a packet dedicated to carrying encoding symbols). Furthermore, given valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, a valid packet payload size, and a valid encoding window (i.e., a set of source symbols), the specification MUST uniquely define the values of the encoding symbol (or symbols) to be included in the repair packet payload with the given Repair FEC Payload ID value. Additionally, the FEC Scheme associated to a Sliding Window FEC Code: o MUST define the relationships between ADUs and the associated source symbols (mapping); o MUST define the management of the encoding window that slides over the set of ADUs. Appendix A provides non normative hints about what FEC Scheme designers need to consider; o MUST define the management of the decoding window. This usually consists in managing a system of linear equations (in case of a linear FEC code); 6. Feedback The discussion of [RFC6363], Section 6, equally applies to this FECFRAME extension and is not repeated here. Roca & Begen Expires July 15, 2019 [Page 16] Internet-Draft FEC Framework Extension January 2019 7. Transport Protocols The discussion of [RFC6363], Section 7, equally applies to this FECFRAME extension and is not repeated here. 8. Congestion Control The discussion of [RFC6363], Section 8, equally applies to this FECFRAME extension and is not repeated here. 9. Implementation Status Editor's notes: RFC Editor, please remove this section motivated by RFC 7942 before publishing the RFC. Thanks! An implementation of FECFRAME extended to Sliding Window codes exists: o Organisation: Inria o Description: This is an implementation of FECFRAME extended to Sliding Window codes and supporting the RLC FEC Scheme [RLC-ID]. It is based on: (1) a proprietary implementation of FECFRAME, made by Inria and Expway for which interoperability tests have been conducted; and (2) a proprietary implementation of RLC Sliding Window FEC Codes. o Maturity: the basic FECFRAME maturity is "production", the FECFRAME extension maturity is "under progress". o Coverage: the software implements a subset of [RFC6363], as specialized by the 3GPP eMBMS standard [MBMSTS]. This software also covers the additional features of FECFRAME extended to Sliding Window codes, in particular the RLC FEC Scheme. o Licensing: proprietary. o Implementation experience: maximum. o Information update date: March 2018. o Contact: vincent.roca@inria.fr 10. Security Considerations This FECFRAME extension does not add any new security consideration. All the considerations of [RFC6363], Section 9, apply to this document as well. However, for the sake of completeness, the Roca & Begen Expires July 15, 2019 [Page 17] Internet-Draft FEC Framework Extension January 2019 following goal can be added to the list provided in Section 9.1 "Problem Statement" of [RFC6363]: o Attacks can try to corrupt source flows in order to modify the receiver application's behavior (as opposed to just denying service). 11. Operations and Management Considerations This FECFRAME extension does not add any new Operations and Management Consideration. All the considerations of [RFC6363], Section 10, apply to this document as well. 12. IANA Considerations No IANA actions are required for this document. A FEC Scheme for use with this FEC Framework is identified via its FEC Encoding ID. It is subject to IANA registration in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of [RFC6363], Section 11, apply and are not repeated here. 13. Acknowledgments The authors would like to thank Christer Holmberg, David Black, Gorry Fairhurst, and Emmanuel Lochin, Spencer Dawkins, Ben Campbell, Benjamin Kaduk, Eric Rescorla, Adam Roach, and Greg Skinner for their valuable feedback on this document. This document being an extension to [RFC6363], the authors would also like to thank Mark Watson as the main author of that RFC. 14. References 14.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, . [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Roca & Begen Expires July 15, 2019 [Page 18] Internet-Draft FEC Framework Extension January 2019 14.2. Informative References [MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346, March 2009, . [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007, . [RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, DOI 10.17487/RFC6364, October 2011, . [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward Error Correction (FEC) Schemes for FECFRAME", RFC 6681, DOI 10.17487/RFC6681, August 2012, . [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6816, DOI 10.17487/RFC6816, December 2012, . [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. Matsuzono, "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", RFC 6865, DOI 10.17487/RFC6865, February 2013, . [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, . [RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME", Work in Progress, Transport Area Working Group (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in Progress), September 2018, . Roca & Begen Expires July 15, 2019 [Page 19] Internet-Draft FEC Framework Extension January 2019 Appendix A. About Sliding Encoding Window Management (informational) The FEC Framework does not specify the management of the sliding encoding window which is the responsibility of the FEC Scheme. This annex only provides a few informational hints. Source symbols are added to the sliding encoding window each time a new ADU is available at the sender, after the ADU-to-source-symbol mapping specific to the FEC Scheme. Source symbols are removed from the sliding encoding window, for instance: o after a certain delay, when an "old" ADU of a real-time flow times out. The source symbol retention delay in the sliding encoding window should therefore be initialized according to the real-time features of incoming flow(s) when applicable; o once the sliding encoding window has reached its maximum size (there is usually an upper limit to the sliding encoding window size). In that case the oldest symbol is removed each time a new source symbol is added. Several considerations can impact the management of this sliding encoding window: o at the source flows level: real-time constraints can limit the total time source symbols can remain in the encoding window; o at the FEC code level: theoretical or practical limitations (e.g., because of computational complexity) can limit the number of source symbols in the encoding window; o at the FEC Scheme level: signaling and window management are intrinsically related. For instance, an encoding window composed of a non-sequential set of source symbols requires an appropriate signaling to inform a receiver of the composition of the encoding window, and the associated transmission overhead can limit the maximum encoding window size. On the opposite, an encoding window always composed of a sequential set of source symbols simplifies signaling: providing the identity of the first source symbol plus their number is sufficient, which creates a fixed and relatively small transmission overhead. Roca & Begen Expires July 15, 2019 [Page 20] Internet-Draft FEC Framework Extension January 2019 Authors' Addresses Vincent Roca INRIA Univ. Grenoble Alpes France EMail: vincent.roca@inria.fr Ali Begen Networked Media Konya Turkey EMail: ali.begen@networked.media Roca & Begen Expires July 15, 2019 [Page 21] ./draft-ietf-tsvwg-rtcweb-qos-18.txt0000644000764400076440000006310112755720053016626 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-tinymt32-06.txt0000644000764400076440000006047513501766477016253 0ustar iustyiusty TSVWG M. Saito Internet-Draft M. Matsumoto Intended status: Standards Track Hiroshima University Expires: December 19, 2019 V. Roca (Ed.) E. Baccelli INRIA June 17, 2019 TinyMT32 Pseudo Random Number Generator (PRNG) draft-ietf-tsvwg-tinymt32-06 Abstract This document describes the TinyMT32 Pseudo Random Number Generator (PRNG) that produces 32-bit pseudo-random unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping a reasonably good randomness that represents a sigificant improvement compared to the Park-Miller Linear Congruential PRNG. However, neither the TinyMT nor MT PRNG are meant to be used for cryptographic 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 https://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 19, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Saito, et al. Expires December 19, 2019 [Page 1] Internet-Draft TinyMT32 PRNG June 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. TinyMT32 PRNG Specification . . . . . . . . . . . . . . . . . 3 3.1. TinyMT32 Source Code . . . . . . . . . . . . . . . . . . 3 3.2. TinyMT32 Usage . . . . . . . . . . . . . . . . . . . . . 7 3.3. Specific Implementation Validation and Deterministic Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document specifies the TinyMT32 PRNG, as a specialization of the reference implementation version 1.1 (2015/04/24) by Mutsuo Saito and Makoto Matsumoto, from Hiroshima University, that can be found at [TinyMT-web] (TinyMT web site) and [TinyMT-dev] (Github site). This specialisation aims at having a simple-to-use and deterministic PRNG, as explained below. However, the TinyMT32 PRNG is not meant to be used for cryptographic applications. TinyMT is a new small-sized variant introduced in 2011 of the Mersenne Twister (MT) PRNG [MT98]. This document focusses on the TinyMT32 variant (rather than TinyMT64) of the TinyMT PRNG, which outputs 32-bit unsigned integers. The purpose of TinyMT is not to replace Mersenne Twister: TinyMT has a far shorter period (2^^127 - 1) than MT. The merit of TinyMT is in the small size of the internal state of 127 bits, far smaller than the 19937 bits of MT. The outputs of TinyMT satisfy several statistical tests for non-cryptographic randomness, including BigCrush in TestU01 [TestU01] and AdaptiveCrush [AdaptiveCrush], Saito, et al. Expires December 19, 2019 [Page 2] Internet-Draft TinyMT32 PRNG June 2019 leaving it well-placed for non-cryptographic usage, especially given the small size of its internal state (see [TinyMT-web]). From this point of view, TinyMT32 represents a major improvement with respect to the Park-Miller Linear Congruential PRNG (e.g., as specified in [RFC5170]) that suffers several known limitations (see for instance [PTVF92], section 7.1, p. 279, and [RLC-ID], Appendix B). The TinyMT32 PRNG initialization depends, among other things, on a parameter set, namely (mat1, mat2, tmat). In order to facilitate the use of this PRNG and make the sequence of pseudo-random numbers depend only on the seed value, this specification requires the use of a specific parameter set (see Section 3.1). This is a major difference with respect to the implementation version 1.1 (2015/04/24) that leaves this parameter set unspecified. Finally, the determinism of this PRNG, for a given seed, has been carefully checked (see Section 3.3). It means that the same sequence of pseudo-random numbers should be generated, no matter the target execution platform and compiler, for a given initial seed value. This determinism can be a key requirement as it the case with [RLC-ID] that normatively depends on this specification. 2. Definitions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. TinyMT32 PRNG Specification 3.1. TinyMT32 Source Code The TinyMT32 PRNG requires to be initialized with a parameter set that needs to be well chosen. In this specification, for the sake of simplicity, the following parameter set MUST be used: o mat1 = 0x8f7011ee = 2406486510 o mat2 = 0xfc78ff1f = 4235788063 o tmat = 0x3793fdff = 932445695 This parameter set is the first entry of the precalculated parameter sets in file tinymt32dc/tinymt32dc.0.1048576.txt, by Kenji Rikitake, and available at [TinyMT-params]. This is also the parameter set used in [KR12]. Saito, et al. Expires December 19, 2019 [Page 3] Internet-Draft TinyMT32 PRNG June 2019 The TinyMT32 PRNG reference implementation is reproduced in Figure 1. This is a C language implementation, written for C99 [C99]. This reference implementation differs from the original source code as follows: o the original copyright and license have been removed by the original authors who are now authors of this document, in accordance with BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info); o the source code initially spread over the tinymt32.h and tinymt32.c files has been merged; o the unused parts of the original source code have been removed. This is the case of the tinymt32_init_by_array() alternative initialisation function. This is also the case of the period_certification() function after having checked it is not required with the chosen parameter set; o the unused constants TINYMT32_MEXP and TINYMT32_MUL have been removed; o the appropriate parameter set has been added to the initialization function; o the function order has been changed; o certain internal variables have been renamed for compactness purposes; o the const qualifier has been added to the constant definitions; o the code that was dependant on the representation of negative integers by 2's complements has been replaced by a more portable version; /** * Tiny Mersenne Twister only 127 bit internal state. * Derived from the reference implementation version 1.1 (2015/04/24) * by Mutsuo Saito (Hiroshima University) and Makoto Matsumoto * (Hiroshima University). */ #include /** * tinymt32 internal state vector and parameters */ typedef struct { uint32_t status[4]; uint32_t mat1; uint32_t mat2; uint32_t tmat; } tinymt32_t; static void tinymt32_next_state (tinymt32_t* s); Saito, et al. Expires December 19, 2019 [Page 4] Internet-Draft TinyMT32 PRNG June 2019 static uint32_t tinymt32_temper (tinymt32_t* s); /** * Parameter set to use for this IETF specification. Don't change. * This parameter set is the first entry of the precalculated * parameter sets in file tinymt32dc/tinymt32dc.0.1048576.txt, by * Kenji Rikitake, available at: * https://github.com/jj1bdx/tinymtdc-longbatch/ * It is also the parameter set used: * Rikitake, K., "TinyMT Pseudo Random Number Generator for * Erlang", ACM 11th SIGPLAN Erlang Workshop (Erlang'12), * September, 2012. */ const uint32_t TINYMT32_MAT1_PARAM = UINT32_C(0x8f7011ee); const uint32_t TINYMT32_MAT2_PARAM = UINT32_C(0xfc78ff1f); const uint32_t TINYMT32_TMAT_PARAM = UINT32_C(0x3793fdff); /** * This function initializes the internal state array with a * 32-bit unsigned integer seed. * @param s pointer to tinymt internal state. * @param seed a 32-bit unsigned integer used as a seed. */ void tinymt32_init (tinymt32_t* s, uint32_t seed) { const uint32_t MIN_LOOP = 8; const uint32_t PRE_LOOP = 8; s->status[0] = seed; s->status[1] = s->mat1 = TINYMT32_MAT1_PARAM; s->status[2] = s->mat2 = TINYMT32_MAT2_PARAM; s->status[3] = s->tmat = TINYMT32_TMAT_PARAM; for (int i = 1; i < MIN_LOOP; i++) { s->status[i & 3] ^= i + UINT32_C(1812433253) * (s->status[(i - 1) & 3] ^ (s->status[(i - 1) & 3] >> 30)); } /* * NB: the parameter set of this specification warrants * that none of the possible 2^^32 seeds leads to an * all-zero 127-bit internal state. Therefore, the * period_certification() function of the original * TinyMT32 source code has been safely removed. If * another parameter set is used, this function will * have to be re-introduced here. */ for (int i = 0; i < PRE_LOOP; i++) { tinymt32_next_state(s); } Saito, et al. Expires December 19, 2019 [Page 5] Internet-Draft TinyMT32 PRNG June 2019 } /** * This function outputs a 32-bit unsigned integer from * the internal state. * @param s pointer to tinymt internal state. * @return 32-bit unsigned integer r (0 <= r < 2^32). */ uint32_t tinymt32_generate_uint32 (tinymt32_t* s) { tinymt32_next_state(s); return tinymt32_temper(s); } /** * Internal tinymt32 constants and functions. * Users should not call these functions directly. */ const uint32_t TINYMT32_SH0 = 1; const uint32_t TINYMT32_SH1 = 10; const uint32_t TINYMT32_SH8 = 8; const uint32_t TINYMT32_MASK = UINT32_C(0x7fffffff); /** * This function changes the internal state of tinymt32. * @param s pointer to tinymt internal state. */ static void tinymt32_next_state (tinymt32_t* s) { uint32_t x; uint32_t y; y = s->status[3]; x = (s->status[0] & TINYMT32_MASK) ^ s->status[1] ^ s->status[2]; x ^= (x << TINYMT32_SH0); y ^= (y >> TINYMT32_SH0) ^ x; s->status[0] = s->status[1]; s->status[1] = s->status[2]; s->status[2] = x ^ (y << TINYMT32_SH1); s->status[3] = y; /* * The if (y & 1) {...} block below replaces: * s->status[1] ^= -((int32_t)(y & 1)) & s->mat1; * s->status[2] ^= -((int32_t)(y & 1)) & s->mat2; * The adopted code is equivalent to the original code * but does not depend on the representation of negative Saito, et al. Expires December 19, 2019 [Page 6] Internet-Draft TinyMT32 PRNG June 2019 * integers by 2's complements. It is therefore more * portable, but includes an if-branch which may slow * down the generation speed. */ if (y & 1) { s->status[1] ^= s->mat1; s->status[2] ^= s->mat2; } } /** * This function outputs a 32-bit unsigned integer from * the internal state. * @param s pointer to tinymt internal state. * @return 32-bit unsigned pseudo-random number. */ static uint32_t tinymt32_temper (tinymt32_t* s) { uint32_t t0, t1; t0 = s->status[3]; t1 = s->status[0] + (s->status[2] >> TINYMT32_SH8); t0 ^= t1; /* * The if (t1 & 1) {...} block below replaces: * t0 ^= -((int32_t)(t1 & 1)) & s->tmat; * The adopted code is equivalent to the original code * but does not depend on the representation of negative * integers by 2's complements. It is therefore more * portable, but includes an if-branch which may slow * down the generation speed. */ if (t1 & 1) { t0 ^= s->tmat; } return t0; } Figure 1: TinyMT32 Reference Implementation 3.2. TinyMT32 Usage This PRNG MUST first be initialized with the following function: void tinymt32_init (tinymt32_t* s, uint32_t seed); It takes as input a 32-bit unsigned integer used as a seed (note that value 0 is permitted by TinyMT32). This function also takes as input Saito, et al. Expires December 19, 2019 [Page 7] Internet-Draft TinyMT32 PRNG June 2019 a pointer to an instance of a tinymt32_t structure that needs to be allocated by the caller but left uninitialized. This structure will then be updated by the various TinyMT32 functions in order to keep the internal state of the PRNG. The use of this structure admits several instances of this PRNG to be used in parallel, each of them having its own instance of the structure. Then, each time a new 32-bit pseudo-random unsigned integer between 0 and 2^32 - 1 inclusive is needed, the following function is used: uint32_t tinymt32_generate_uint32 (tinymt32_t * s); Of course, the tinymt32_t structure must be left unchanged by the caller between successive calls to this function. 3.3. Specific Implementation Validation and Deterministic Behavior PRNG determinism, for a given seed, can be a requirement (e.g., with [RLC-ID]). Consequently, any implementation of the TinyMT32 PRNG in line with this specification MUST have the same output as that provided by the reference implementation of Figure 1. In order to increase the compliancy confidence, this document proposes the following criteria. Using a seed value of 1, the first 50 values returned by tinymt32_generate_uint32(s) as 32-bit unsigned integers are equal to values provided in Figure 2, to be read line by line. Note that these values come from the tinymt/check32.out.txt file provided by the PRNG authors to validate implementations of TinyMT32, as part of the MersenneTwister-Lab/TinyMT Github repository. 2545341989 981918433 3715302833 2387538352 3591001365 3820442102 2114400566 2196103051 2783359912 764534509 643179475 1822416315 881558334 4207026366 3690273640 3240535687 2921447122 3984931427 4092394160 44209675 2188315343 2908663843 1834519336 3774670961 3019990707 4065554902 1239765502 4035716197 3412127188 552822483 161364450 353727785 140085994 149132008 2547770827 4064042525 4078297538 2057335507 622384752 2041665899 2193913817 1080849512 33160901 662956935 642999063 3384709977 1723175122 3866752252 521822317 2292524454 Figure 2: First 50 decimal values (to be read per line) returned by tinymt32_generate_uint32(s) as 32-bit unsigned integers, with a seed value of 1. In particular, the deterministic behavior of the Figure 1 source code has been checked across several platforms: high-end laptops running 64-bits Mac OSX and Linux/Ubuntu; a board featuring a 32-bits ARM Cortex-A15 and running 32-bit Linux/Ubuntu; several embedded cards Saito, et al. Expires December 19, 2019 [Page 8] Internet-Draft TinyMT32 PRNG June 2019 featuring either an ARM Cortex-M0+, a Cortex-M3 or a Cortex-M4 32-bit microcontroller, all of them running RIOT [Baccelli18]; two low-end embedded cards featuring either a 16-bit microcontroller (TI MSP430) or a 8-bit microcontroller (Arduino ATMEGA2560), both of them running RIOT. This specification only outputs 32-bit unsigned pseudo-random numbers and does not try to map this output to a smaller integer range (e.g., between 10 and 49 inclusive). If a specific use-case needs such a mapping, it will have to provide its own function. In that case, if PRNG determinism is also required, the use of floating point (single or double precision) to perform this mapping should probably be avoided, these calculations leading potentially to different rounding errors across different target platforms. Great care should also be put on not introducing biases in the randomness of the mapped output (it may be the case with some mapping algorithms) incompatible with the use-case requirements. The details of how to perform such a mapping are out-of-scope of this document. 4. Security Considerations The authors do not believe the present specification generates specific security risks per se. However, neither the TinyMT nor MT PRNG are meant to be used for cryptographic applications. 5. IANA Considerations This document does not require any IANA action. 6. Acknowledgments The authors would like to thank Belkacem Teibi with whom we explored TinyMT32 specificities when looking to an alternative to the Park- Miller Linear Congruential PRNG. The authors would like to thank Carl Wallace, Stewart Bryant, Greg Skinner, Mike Heard, the three TSVWG chairs, Wesley Eddy, our shepherd, David Black and Gorry Fairhurst, as well as Spencer Dawkins and Mirja Kuhlewind. Last but not least, the authors are really grateful to the IESG members, in particular Benjamin Kaduk, Eric Rescorla, Adam Roach, Roman Danyliw, Barry Leiba, Martin Vigoureux, Eric Vyncke for their highly valuable feedbacks that greatly contributed to improve this specification. 7. References Saito, et al. Expires December 19, 2019 [Page 9] Internet-Draft TinyMT32 PRNG June 2019 7.1. Normative References [C99] "Programming languages - C: C99, correction 3:2007", International Organization for Standardization, ISO/IEC 9899:1999/Cor 3:2007, November 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [AdaptiveCrush] Haramoto, H., "Automation of statistical tests on randomness to obtain clearer conclusion", Monte Carlo and Quasi-Monte Carlo Methods 2008, DOI:10.1007/978-3-642-04107-5_26, November 2009, . [Baccelli18] Baccelli, E., Gundogan, C., Hahm, O., Kietzmann, P., Lenders, M., Petersen, H., Schleiser, K., Schmidt, T., and M. Wahlisch, "RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT", IEEE Internet of Things Journal (Volume 5, Issue 6), DOI: 10.1109/JIOT.2018.2815038, December 2018. [KR12] Rikitake, K., "TinyMT Pseudo Random Number Generator for Erlang", ACM 11th SIGPLAN Erlang Workshop (Erlang'12), September 14, 2012, Copenhagen, Denmark, DOI: http://dx.doi.org/10.1145/2364489.2364504, September 2012. [MT98] Matsumoto, M. and T. Nishimura, "Mersenne Twister: A 623-dimensionally equidistributed uniform pseudorandom number generator", ACM Transactions on Modeling and Computer Simulation (TOMACS), Volume 8 Issue 1, Jan. 1998, pp.3-30, January 1998, DOI:10.1145/272991.272995, January 1998. [PTVF92] Press, W., Teukolsky, S., Vetterling, W., and B. Flannery, "Numerical Recipies in C; Second Edition", Cambridge University Press, ISBN: 0-521-43108-5, 1992. Saito, et al. Expires December 19, 2019 [Page 10] Internet-Draft TinyMT32 PRNG June 2019 [RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes", RFC 5170, DOI 10.17487/RFC5170, June 2008, . [RLC-ID] Roca, V. and B. Teibi, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME", Work in Progress, Transport Area Working Group (TSVWG) draft-ietf-tsvwg-rlc-fec-scheme (Work in Progress), February 2019, . [TestU01] L'Ecuyer, P. and R. Simard, "TestU01: A C Library for Empirical Testing of Random Number Generators", ACM Transactions on Mathematical Software, Vol. 33, article 22, 2007, 2007, . [TinyMT-dev] Saito, M. and M. Matsumoto, "Tiny Mersenne Twister (TinyMT) github site", . [TinyMT-params] Rikitake, K., "TinyMT pre-calculated parameter list github site", . [TinyMT-web] Saito, M. and M. Matsumoto, "Tiny Mersenne Twister (TinyMT) web site", . Authors' Addresses Mutsuo Saito Hiroshima University Japan EMail: saito@math.sci.hiroshima-u.ac.jp Makoto Matsumoto Hiroshima University Japan EMail: m-mat@math.sci.hiroshima-u.ac.jp Saito, et al. Expires December 19, 2019 [Page 11] Internet-Draft TinyMT32 PRNG June 2019 Vincent Roca INRIA Univ. Grenoble Alpes France EMail: vincent.roca@inria.fr Emmanuel Baccelli INRIA France EMail: emmanuel.baccelli@inria.fr Saito, et al. Expires December 19, 2019 [Page 12] ./draft-ietf-uta-smtp-require-tls-09.txt0000644000764400076440000012552213521130661017412 0ustar iustyiusty Internet Engineering Task Force J. Fenton Internet-Draft Altmode Networks Intended status: Standards Track August 2, 2019 Expires: February 3, 2020 SMTP Require TLS Option draft-ietf-uta-smtp-require-tls-09 Abstract The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed, or by requesting that recipient-side policy mechanisms such as MTA-STS and DANE be ignored when relaying a message for which security is unimportant. 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 https://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 3, 2020. Copyright Notice Copyright (c) 2019 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 Fenton Expires February 3, 2020 [Page 1] Internet-Draft SMTP Require TLS Option August 2019 (https://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. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 4 3. The TLS-Required Header Field . . . . . . . . . . . . . . . . 5 4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 6 4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 6 4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 6 4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 6 4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 7 4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 8 4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 6. Reorigination considerations . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 11 8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 11 8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 12 8.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Changes since -08 Draft . . . . . . . . . . . . . . . . 13 10.2. Changes since -07 Draft . . . . . . . . . . . . . . . . 13 10.3. Changes since -06 Draft . . . . . . . . . . . . . . . . 13 10.4. Changes since -05 Draft . . . . . . . . . . . . . . . . 14 10.5. Changes since -04 Draft . . . . . . . . . . . . . . . . 14 10.6. Changes since -03 Draft . . . . . . . . . . . . . . . . 14 10.7. Changes since -02 Draft . . . . . . . . . . . . . . . . 14 10.8. Changes since -01 Draft . . . . . . . . . . . . . . . . 14 10.9. Changes since -00 Draft . . . . . . . . . . . . . . . . 15 10.10. Changes since fenton-03 Draft . . . . . . . . . . . . . 15 10.11. Changes Since -02 Draft . . . . . . . . . . . . . . . . 15 10.12. Changes Since -01 Draft . . . . . . . . . . . . . . . . 15 10.13. Changes Since -00 Draft . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 Fenton Expires February 3, 2020 [Page 2] Internet-Draft SMTP Require TLS Option August 2019 A.1. REQUIRETLS SMTP Option . . . . . . . . . . . . . . . . . 19 A.2. TLS-Required Header Field . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a means by which an SMTP server and client can establish a Transport Layer Security (TLS) protected session for the transmission of email messages. By default, TLS is used only upon mutual agreement (successful negotiation) of STARTTLS between the client and server; if this is not possible, the message is sent without transport encryption. Furthermore, it is common practice for the client to negotiate TLS even if the SMTP server's certificate is invalid. Policy mechanisms such as DANE [RFC7672] and MTA-STS [RFC8461] may impose requirements for the use of TLS for email destined for some domains. However, such policies do not allow the sender to specify which messages are more sensitive and require transport-level encryption, and which ones are less sensitive and ought to be relayed even if TLS cannot be negotiated successfully. The default opportunistic nature of SMTP TLS enables several "on the wire" attacks on SMTP security between MTAs. These include passive eavesdropping on connections for which TLS is not used, interference in the SMTP protocol to prevent TLS from being negotiated (presumably accompanied by eavesdropping), and insertion of a man-in-the-middle attacker exploiting the lack of server authentication by the client. Attacks are described in more detail in the Security Considerations section of this document. REQUIRETLS consists of two mechanisms: an SMTP service extension and a message header field. The service extension is used to specify that a given message sent during a particular session MUST be sent over a TLS-protected session with specified security characteristics. It also requires that the SMTP server advertise that it supports REQUIRETLS, in effect promising that it will honor the requirement to enforce TLS transmission and REQUIRETLS support for onward transmission of those messages. The TLS-Required message header field is used to convey a request to ignore recipient-side policy mechanisms such as MTA-STS and DANE, thereby prioritizing delivery over ability to negotiate TLS. Unlike the service extension, the TLS-Required header field allows the message to transit through one or more MTAs that do not support REQUIRETLS. Fenton Expires February 3, 2020 [Page 3] Internet-Draft SMTP Require TLS Option August 2019 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] including the core rules defined in Appendix B of that document. 2. The REQUIRETLS Service Extension 1. The textual name of the extension is "Require TLS". 2. The EHLO keyword value associated with this extension is "REQUIRETLS". 3. No additional SMTP verbs are defined by this extension. 4. One optional parameter ("REQUIRETLS") is added to the MAIL FROM command by this extension. No value is associated with this parameter. 5. The maximum length of a MAIL FROM command line is increased by 11 octets by the possible addition of a space and the REQUIRETLS keyword. 6. One new SMTP status code is defined by this extension to convey an error condition resulting from failure of the client to send to a server not also supporting the REQUIRETLS extension. 7. The REQUIRETLS extension is valid for message relay [RFC5321], submission [RFC6409], and the Local Mail Transfer Protocol (LMTP) [RFC2033] 8. The ABNF syntax for the MAIL FROM parameter is as follows: requiretls-param = "REQUIRETLS" ; where requiretls-param is an instance of an ; esmtp-param used in Mail-parameters in ; RFC 5321 Section 4.1.2. There is no esmtp-value ; associated with requiretls-param. In order to specify REQUIRETLS treatment for a given message, the REQUIRETLS option is specified on the MAIL FROM command when that message is transmitted. This option MUST only be specified in the Fenton Expires February 3, 2020 [Page 4] Internet-Draft SMTP Require TLS Option August 2019 context of an SMTP session meeting the security requirements of REQUIRETLS: o The session itself MUST employ TLS transmission. o If the SMTP server to which the message is being transmitted is identified through an MX record lookup, its name MUST be validated via a DNSSEC signature on the recipient domain's MX record, or the MX hostname MUST be validated by an MTA-STS policy as described in Section 4.1 of RFC 8461 [RFC8461]. DNSSEC is defined in RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]. o The certificate presented by the SMTP server MUST either verify successfully in a trust chain leading to a certificate trusted by the SMTP client or it MUST verify successfully using DANE as specified in RFC 7672 [RFC7672]. For trust chains, the choice of trusted (root) certificates is at the discretion of the SMTP client. o Following the negotiation of STARTTLS, the SMTP server MUST advertise in the subsequent EHLO response that it supports REQUIRETLS. 3. The TLS-Required Header Field One new message header field [RFC5322], TLS-Required, is defined by this specification. It is used for messages for which the originator requests that recipient TLS policy (including MTA-STS [RFC8461] and DANE [RFC7672]) be ignored. This might be done, for example, to report a misconfigured mail server, such as an expired TLS certificate. The TLS-Required header field has a single REQUIRED parameter: o No - The SMTP client SHOULD attempt to send the message regardless of its ability to negotiate STARTTLS with the SMTP server, ignoring policy-based mechanisms (including MTA-STS and DANE), if any, asserted by the recipient domain. Nevertheless, the client SHOULD negotiate STARTTLS with the server if available. More than one instance of the TLS-Required header field MUST NOT appear in a given message. The ABNF syntax for the TLS-Required header field is as follows: Fenton Expires February 3, 2020 [Page 5] Internet-Draft SMTP Require TLS Option August 2019 requiretls-field = "TLS-Required:" [FWS] "No" CRLF ; where requiretls-field in an instance of an ; optional-field defined in RFC 5322 Section ; 3.6.8. FWS = CRLF = 4. REQUIRETLS Semantics 4.1. REQUIRETLS Receipt Requirements Upon receipt of the REQUIRETLS option on a MAIL FROM command during the receipt of a message, an SMTP server MUST tag that message as needing REQUIRETLS handling. Upon receipt of a message not specifying the REQUIRETLS option on its MAIL FROM command but containing the TLS-Required header field in its message header, an SMTP server implementing this specification MUST tag that message with the option specified in the TLS-Required header field. If the REQUIRETLS MAIL FROM parameter is specified, the TLS- Required header field MUST be ignored but MAY be included in onward relay of the message. The manner in which the above tagging takes place is implementation- dependent. If the message is being locally aliased and redistributed to multiple addresses, all instances of the message MUST be tagged in the same manner. 4.2. REQUIRETLS Sender Requirements 4.2.1. Sending with TLS Required When sending a message tagged as requiring TLS for which the MAIL FROM return-path is not empty (an empty MAIL FROM return-path indicating a bounce message), the sending (client) MTA MUST: 1. Look up the SMTP server to which the message is to be sent as described in [RFC5321] Section 5.1. 2. If the server lookup is accomplished via the recipient domain's MX record (the usual case) and is not accompanied by a valid DNSSEC signature, the client MUST also validate the SMTP server name using MTA-STS as described in RFC 8461 [RFC8461] Section 4.1. 3. Open an SMTP session with the peer SMTP server using the EHLO verb. Fenton Expires February 3, 2020 [Page 6] Internet-Draft SMTP Require TLS Option August 2019 4. Establish a TLS-protected SMTP session with its peer SMTP server and authenticate the server's certificate as specified in [RFC6125] or [RFC7672] as applicable. The hostname from the MX record lookup (or the domain name in the absence of an MX record where an A record is used directly) MUST match the DNS-ID or CN- ID of the certificate presented by the server. 5. Ensure that the response to the subsequent EHLO following establishment of the TLS protection advertises the REQUIRETLS capability. The SMTP client SHOULD follow the recommendations in [RFC7525] or its successor with respect to negotiation of the TLS session. If any of the above steps fail, the client MUST issue a QUIT to the server and repeat steps 2-5 with each host on the recipient domain's list of MX hosts in an attempt to find a mail path that meets the sender's requirements. The client MAY send other, unprotected, messages to that server if it has any prior to issuing the QUIT. If there are no more MX hosts, the client MUST NOT transmit the message to the domain. Following such a failure, the SMTP client MUST send a non-delivery notification to the reverse-path of the failed message as described in section 3.6 of [RFC5321]. The following status codes [RFC5248] SHOULD be used: o REQUIRETLS not supported by server: 5.7.YYY REQUIRETLS needed o Unable to establish TLS-protected SMTP session: 5.7.10 Encryption needed Refer to Section 5 for further requirements regarding non-delivery messages. If all REQUIRETLS requirements have been met, transmit the message, issuing the REQUIRETLS option on the MAIL FROM command with the required option(s), if any. 4.2.2. Sending with TLS Optional Messages tagged TLS-Required: No are handled as follows. When sending such a message, the sending (client) MTA MUST: o Look up the SMTP server to which the message is to be sent as described in [RFC5321] Section 5.1. Fenton Expires February 3, 2020 [Page 7] Internet-Draft SMTP Require TLS Option August 2019 o Open an SMTP session with the peer SMTP server using the EHLO verb. Attempt to negotiate STARTTLS if possible, and follow any policy published by the recipient domain, but do not fail if this is unsuccessful. Some SMTP servers may be configured to require STARTTLS connections as a matter of policy and not accept messages in the absence of STARTTLS. A non-delivery notification MUST be returned to the sender if message relay fails due to an inability to negotiate STARTTLS when required by the server. Since messages tagged with TLS-Required: No will sometimes be sent to SMTP servers not supporting REQUIRETLS, that option will not be uniformly observed by all SMTP relay hops. 4.3. REQUIRETLS Submission An MUA or other agent making the initial introduction of a message has the option to decide whether to require TLS. If TLS is to be required, it MUST do so by negotiating STARTTLS and REQUIRETLS and include the REQUIRETLS option on the MAIL FROM command, as is done for message relay. When TLS is not to be required, the sender MUST include the TLS- Required header field in the message. SMTP servers implementing this specification MUST interpret this header field as described in Section 4.1. In either case, the decision whether to specify REQUIRETLS MAY be done based on a user interface selection or based on a ruleset or other policy. The manner in which the decision to require TLS is made is implementation-dependent and is beyond the scope of this specification. 4.4. Delivery of REQUIRETLS messages Messages are usually retrieved by end users using protocols other than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems. Mail delivery agents supporting the REQUIRETLS SMTP option SHOULD observe the guidelines in [RFC8314]. 5. Non-delivery message handling Non-delivery ("bounce") messages usually contain important metadata about the message to which they refer, including the original message header. They therefore MUST be protected in the same manner as the original message. All non-delivery messages resulting from messages with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS Fenton Expires February 3, 2020 [Page 8] Internet-Draft SMTP Require TLS Option August 2019 error or some other, MUST also specify the REQUIRETLS SMTP option unless redacted as described below. The path from the origination of an error bounce message back to the MAIL FROM address may not share the same REQUIRETLS support as the forward path. Therefore, users requiring TLS are advised to make sure that they are capable of receiving mail using REQUIRETLS as well. Otherwise, such non-delivery messages will be lost. If a REQUIRETLS message is bounced, the server MUST behave as if RET=HDRS was present as described in [RFC3461]. If both RET=FULL and REQUIRETLS are present, the RET=FULL MUST be disregarded. The SMTP client for a REQUIRETLS bounce message uses an empty MAIL FROM return-path as required by [RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce message to be discarded even if the next-hop relay does not advertise REQUIRETLS. Senders of messages requiring TLS are advised to consider the possibility that bounce messages will be lost as a result of REQUIRETLS return path failure, and that some information could be leaked if a bounce message is not able to be transmitted with REQUIRETLS. 6. Reorigination considerations In a number of situations, a mediator [RFC5598] originates a new message as a result of an incoming message. These situations include, but are not limited to, mailing lists (including administrative traffic such as message approval requests), Sieve [RFC5228], "vacation" responders, and other filters to which incoming messages may be piped. These newly originated messages may essentially be copies of the incoming message, such as with a forwarding service or a mailing list expander. In other cases, such as with a vacation message or a delivery notification, they will be different but might contain parts of the original message or other information for which the original message sender wants to influence the requirement to use TLS transmission. Mediators that reoriginate messages should apply REQUIRETLS requirements in incoming messages (both requiring TLS transmission and requesting that TLS not be required) to the reoriginated messages to the extent feasible. A limitation to this might be that for a message requiring TLS, redistribution to multiple addresses while retaining the TLS requirement could result in the message not being delivered to some of the intended recipients. Fenton Expires February 3, 2020 [Page 9] Internet-Draft SMTP Require TLS Option August 2019 User-side mediators (such as use of Sieve rules on a user agent) typically do not have access to the SMTP details, and therefore may not be aware of the REQUIRETLS requirement on a delivered message. Recipients that expect sensitive traffic should avoid the use of user-side mediators. Alternatively, if operationally feasible (such as when forwarding to a specific, known address), they should apply REQUIRETLS to all reoriginated messages that do not contain the "TLS- Required: No" header field. 7. IANA Considerations If published as an RFC, this draft requests the addition of the following keyword to the SMTP Service Extensions Registry [MailParams]: Textual name: Require TLS EHLO keyword value: REQUIRETLS Syntax and parameters: (no parameters) Additional SMTP verbs: none MAIL and RCPT parameters: REQUIRETLS parameter on MAIL Behavior: Use of the REQUIRETLS parameter on the MAIL verb causes that message to require the use of TLS and tagging with REQUIRETLS for all onward relay. Command length increment: 11 characters If published as an RFC, this draft requests the addition of an entry to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry [SMTPStatusCodes]: Code: 5.7.YYY Sample Text: REQUIRETLS support required Associated basic status code: 550 Description: This indicates that the message was not able to be forwarded because it was received with a REQUIRETLS requirement and none of the SMTP servers to which the message should be forwarded provide this support. Reference: (this document) Submitter: J. Fenton Change controller: IESG If published as an RFC, this draft requests the addition of an entry to the Permanent Message Header Field Names Registry [PermMessageHeaderFields]: Fenton Expires February 3, 2020 [Page 10] Internet-Draft SMTP Require TLS Option August 2019 Header field name: TLS-Required Applicable protocol: mail Status: standard Author/change controller: IETF Specification document: (this document) This section is to be updated for publication by the RFC Editor. 8. Security Considerations The purpose of REQUIRETLS is to give the originator of a message control over the security of email they send, either by conveying an expectation that it will be transmitted in an encrypted form "over the wire" or explicitly that transport encryption is not required if it cannot be successfully negotiated. The following considerations apply to the REQUIRETLS service extension but not the TLS-Required header field, since messages specifying the header field are less concerned with transport security. 8.1. Passive attacks REQUIRETLS is generally effective against passive attackers who are merely trying to eavesdrop on an SMTP exchange between an SMTP client and server. This assumes, of course, the cryptographic integrity of the TLS connection being used. 8.2. Active attacks Active attacks against TLS encrypted SMTP connections can take many forms. One such attack is to interfere in the negotiation by changing the STARTTLS command to something illegal such as XXXXXXXX. This causes TLS negotiation to fail and messages to be sent in the clear, where they can be intercepted. REQUIRETLS detects the failure of STARTTLS and declines to send the message rather than send it insecurely. A second form of attack is a man-in-the-middle attack where the attacker terminates the TLS connection rather than the intended SMTP server. This is possible when, as is commonly the case, the SMTP client either does not verify the server's certificate or establishes the connection even when the verification fails. REQUIRETLS requires successful certificate validation before sending the message. Another active attack involves the spoofing of DNS MX records of the recipient domain. An attacker having this capability could potentially cause the message to be redirected to a mail server under Fenton Expires February 3, 2020 [Page 11] Internet-Draft SMTP Require TLS Option August 2019 the attacker's own control, which would presumably have a valid certificate. REQUIRETLS requires that the recipient domain's MX record lookup be validated either using DNSSEC or via a published MTA-STS policy that specifies the acceptable SMTP server hostname(s) for the recipient domain. 8.3. Bad Actor MTAs A bad-actor MTA along the message transmission path could misrepresent its support of REQUIRETLS and/or actively strip REQUIRETLS tags from messages it handles. However, since intermediate MTAs are already trusted with the cleartext of messages they handle, and are not part of the threat model for transport-layer security, they are also not part of the threat model for REQUIRETLS. It should be reemphasized that since SMTP TLS is a transport-layer security protocol, messages sent using REQUIRETLS are not encrypted end-to-end and are visible to MTAs that are part of the message delivery path. Messages containing sensitive information that MTAs should not have access to MUST be sent using end-to-end content encryption such as OpenPGP [RFC4880] or S/MIME [RFC8551]. 8.4. Policy Conflicts In some cases, the use of the TLS-Required header field may conflict with a recipient domain policy expressed through the DANE [RFC7672] or MTA-STS [RFC8461] protocols. Although these protocols encourage the use of TLS transport by advertising availability of TLS, the use of "TLS-Required: No" header field represents an explicit decision on the part of the sender not to require the use of TLS, such as to overcome a configuration error. The recipient domain has the ultimate ability to require TLS by not accepting messages when STARTTLS has not been negotiated; otherwise, "TLS-Required: No" is effectively directing the client MTA to behave as if it does not support DANE nor MTA-STS. 9. Acknowledgements The author would like to acknowledge many helpful suggestions on the ietf-smtp and uta mailing lists, in particular those of Viktor Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, Barry Leiba, John Levine, Rolf Sonneveld, and Per Thorsheim. Fenton Expires February 3, 2020 [Page 12] Internet-Draft SMTP Require TLS Option August 2019 10. Revision History To be removed by RFC Editor upon publication as an RFC. 10.1. Changes since -08 Draft Additional changes in response to IESG review: o Unify wording describing TLS-Required in Appendix A.2. o Add specifics on verification of mail server hostnames with certificates. o Wording tweak in 4.3 to emphasize optional nature of REQUIRETLS. o Update S/MIME reference from RFC 5751 to 8551 10.2. Changes since -07 Draft Changes in response to IESG review and IETF Last Call comments: o Change associated status code for 5.7.YYY from 530 to 550. o Correct textual name of extension in IANA Considerations for consistency with the rest of the document. o Remove special handling of bounce messages in Section 4.1. o Change name of header field from RequireTLS to TLS-Required and make capitalization of parameter consistent. o Remove mention of transforming RET=FULL to RET=HDRS on relay in Section 5. o Replace Section 6 dealing with mailing lists with a more general section on reorigination by mediators. o Add security considerations section on policy conflicts. 10.3. Changes since -06 Draft Various changes in response to AD review: o Reference RFC 7525 for TLS negotiation recommendations. o Make reference to requested 5.7.YYY error code consistent. o Clarify applicability to LMTP and submission. Fenton Expires February 3, 2020 [Page 13] Internet-Draft SMTP Require TLS Option August 2019 o Provide ABNF for syntax of SMTP option and header field and examples in Appendix A. o Correct use of normative language in Section 5. o Clarify case where REQUIRETLS option is used on bounce messages. o Improve Security Requirements wording to be inclusive of both SMTP option and header field. 10.4. Changes since -05 Draft Corrected IANA Permanent Message Header Fields Registry request. 10.5. Changes since -04 Draft Require validation of SMTP server hostname via DNSSEC or MTA-STS policy when TLS is required. 10.6. Changes since -03 Draft Working Group Last Call changes, including: o Correct reference for SMTP DANE o Clarify that RequireTLS: NO applies to both MTA-STS and DANE policies o Correct newly-defined status codes o Update MTA-STS references to RFC 10.7. Changes since -02 Draft o More complete documentation for IANA registration requests. o Changed bounce handling to use RET parameters of [RFC3461], along with slightly more liberal transmission of bounces even if REQUIRETLS can't be negotiated. 10.8. Changes since -01 Draft o Converted DEEP references to RFC 8314. o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. o Editorial corrections, notably making the header field name consistent (RequireTLS rather than Require-TLS). Fenton Expires February 3, 2020 [Page 14] Internet-Draft SMTP Require TLS Option August 2019 10.9. Changes since -00 Draft o Created new header field, Require-TLS, for use by "NO" option. o Removed "NO" option from SMTP service extension. o Recommend DEEP requirements for delivery of messages requiring TLS. o Assorted copy edits 10.10. Changes since fenton-03 Draft o Wording improvements from Rolf Sonneveld review 22 July 2017 o A few copy edits o Conversion from individual to UTA WG draft 10.11. Changes Since -02 Draft o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per suggestion on UTA WG mailing list. o Additional guidance on bounce messages 10.12. Changes Since -01 Draft o Specified retries when multiple MX hosts exist for a given domain. o Clarified generation of non-delivery messages o Specified requirements for application of REQUIRETLS to mail forwarders and mailing lists. o Clarified DNSSEC requirements to include MX lookup only. o Corrected terminology regarding message retrieval vs. delivery. o Changed category to standards track. 10.13. Changes Since -00 Draft o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM parameter to better associate REQUIRETLS requirements with transmission of individual messages. Fenton Expires February 3, 2020 [Page 15] Internet-Draft SMTP Require TLS Option August 2019 o Addition of an option to require DNSSEC lookup of the remote mail server, since this affects the common name of the certificate that is presented. o Clarified the wording to more clearly state that TLS sessions must be established and not simply that STARTTLS is negotiated. o Introduced need for minimum encryption standards (key lengths and algorithms) o Substantially rewritten Security Considerations section 11. References 11.1. Normative References [MailParams] Internet Assigned Numbers Authority (IANA), "IANA Mail Parameters", 2007, . [PermMessageHeaderFields] Internet Assigned Numbers Authority (IANA), "Permanent Message Header Field Names Registry", 2004, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . [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, . Fenton Expires February 3, 2020 [Page 16] Internet-Draft SMTP Require TLS Option August 2019 [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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, DOI 10.17487/RFC5248, June 2008, . [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, . [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, . [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, . [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, . Fenton Expires February 3, 2020 [Page 17] Internet-Draft SMTP Require TLS Option August 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, . [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA- STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, . [SMTPStatusCodes] Internet Assigned Numbers Authority (IANA), "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry", 2008, . 11.2. Informative References [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, . [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, DOI 10.17487/RFC2033, October 1996, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . Fenton Expires February 3, 2020 [Page 18] Internet-Draft SMTP Require TLS Option August 2019 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . Appendix A. Examples This section is informative. A.1. REQUIRETLS SMTP Option The TLS-Required SMTP option is used to express the intent of the sender that the associated message be relayed using TLS. In the following example, lines beginning with C: are transmitted from the SMTP client to the server, and lines beginning with S: are transmitted in the opposite direction. Fenton Expires February 3, 2020 [Page 19] Internet-Draft SMTP Require TLS Option August 2019 S: 220 mail.example.net ESMTP C: EHLO mail.example.org S: 250-mail.example.net Hello example.org [192.0.2.1] S: 250-SIZE 52428800 S: 250-8BITMIME S: 250-PIPELINING S: 250-STARTTLS S: 250 HELP C: STARTTLS S: TLS go ahead (at this point TLS negotiation takes place. The remainder of this session occurs within TLS.) S: 220 mail.example.net ESMTP C: EHLO mail.example.org S: 250-mail.example.net Hello example.org [192.0.2.1] S: 250-SIZE 52428800 S: 250-8BITMIME S: 250-PIPELINING S: 250-REQUIRETLS S: 250 HELP C: MAIL FROM: REQUIRETLS S: 250 OK C: RCPT TO: S: 250 Accepted C: DATA S: 354 Enter message, ending with "." on a line by itself (message follows) C: . S: 250 OK C: QUIT A.2. TLS-Required Header Field The TLS-Required header field is used when the sender requests that the mail system not heed a default policy of the recipient domain requiring TLS. It might be used, for example, to allow problems with the recipient domain's TLS certificate to be reported: Fenton Expires February 3, 2020 [Page 20] Internet-Draft SMTP Require TLS Option August 2019 From: Roger Reporter To: Andy Admin Subject: Certificate problem? TLS-Required: No Date: Fri, 18 Jan 2019 10:26:55 -0800 Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> Andy, there seems to be a problem with the TLS certificate on your mail server. Are you aware of this? Roger Author's Address Jim Fenton Altmode Networks Los Altos, California 94024 USA Email: fenton@bluepopcorn.net Fenton Expires February 3, 2020 [Page 21] ./draft-ietf-v6ops-nat64-deployment-08.txt0000644000764400076440000032252013512112276017551 0ustar iustyiusty v6ops J. Palet Martinez Internet-Draft The IPv6 Company Intended status: Informational July 11, 2019 Expires: January 12, 2020 Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks draft-ietf-v6ops-nat64-deployment-08 Abstract This document describes how NAT64 (including 464XLAT) can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise, and possible optimizations. The document also discusses issues to be considered when having IPv6-only connectivity, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or 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 https://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 12, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Palet Martinez Expires January 12, 2020 [Page 1] Internet-Draft NAT64/464XLAT Deployment July 2019 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. NAT64 Deployment Scenarios . . . . . . . . . . . . . . . . . 5 3.1. Known to Work . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Service Provider NAT64 with DNS64 . . . . . . . . . . 6 3.1.2. Service Provider Offering 464XLAT, with DNS64 . . . . 8 3.1.3. Service Provider Offering 464XLAT, without DNS64 . . 12 3.2. Known to Work Under Special Conditions . . . . . . . . . 14 3.2.1. Service Provider NAT64 without DNS64 . . . . . . . . 14 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts . . . 16 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network . . . . . . . . . . . . . . . . . . . 16 3.3. Comparing the Scenarios . . . . . . . . . . . . . . . . . 17 4. Issues to be Considered . . . . . . . . . . . . . . . . . . . 19 4.1. DNSSEC Considerations and Possible Approaches . . . . . . 19 4.1.1. Not using DNS64 . . . . . . . . . . . . . . . . . . . 20 4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21 4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22 4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22 4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22 4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24 4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25 4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25 4.4.3. Split DNS and VPNs . . . . . . . . . . . . . . . . . 26 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26 4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27 4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28 4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28 6. Deployment of 464XLAT/NAT64 in Enterprise Networks . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38 Palet Martinez Expires January 12, 2020 [Page 2] Internet-Draft NAT64/464XLAT Deployment July 2019 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39 17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 39 18. ANNEX H: Changes from -06 to -07 . . . . . . . . . . . . . . 39 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 19.1. Normative References . . . . . . . . . . . . . . . . . . 39 19.2. Informative References . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation mechanism, which allows IPv6-only hosts to communicate with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of IPv4 public addresses sharing, among multiple IPv6-only hosts. Unless otherwise stated, references in the rest of this document to NAT64 (function) should be interpreted as to Stateful NAT64. The translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915] and algorithmically translating the IPv4 addresses to IPv6 addresses and vice versa, following [RFC6052]. DNS64 ([RFC6147]) is in charge of the synthesis of AAAA records from the A records, so only works for applications making use of DNS. It was designed to avoid changes in both, the IPv6-only hosts and the IPv4-only server, so they can use a NAT64 function. As discussed in Section 5.5 of [RFC6147], a security-aware and validating host has to perform the DNS64 function locally. However, the use of NAT64 and/or DNS64 present three drawbacks: a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is designed to detect such modifications, DNS64 ([RFC6147]) may potentially break DNSSEC, depending on a number of factors, such as the location of the DNS64 function (at a DNS server or validator, at the end host, ...), how it has been configured, if the end-hosts is validating, etc. b. Because the need of using DNS64 ([RFC6147]) or an alternative "host/application built-in" mechanism for address synthesis, there may be an issue for NAT64 ([RFC6146]), as it doesn't work when IPv4 literal addresses or non-IPv6 compliant APIs are being used. c. NAT64 alone, was not designed to provide a solution for IPv4-only hosts or applications located within a network which are Palet Martinez Expires January 12, 2020 [Page 3] Internet-Draft NAT64/464XLAT Deployment July 2019 connected to a service provider IPv6-only access, as it was designed for a very specific scenario ([RFC6144], Section 2.1). Above drawbacks may be true if part of, an enterprise network, is connected to other parts of the same network or third-party networks by means of IPv6-only connectivity. This is just an example which may apply to many other similar cases. All them are deployment specific. According to that, across this document, the use of "operator", "operator network", "service provider", and similar ones, are interchangeable with equivalent cases of enterprise networks (and similar ones). This may be also the case for "managed end-user networks". Note that if all the hosts in a network were performing the address synthesis, as described in Section 7.2 of [RFC6147], some of the drawbacks may vanish. However, it is unrealistic today to expect that, considering the high number of devices and applications that aren't yet IPv6-enabled. So, in this document, this will be considered only for specific scenarios that can guarantee it. An analysis of stateful IPv4/IPv6 mechanisms is provided in [RFC6889]. This document looks into different possible NAT64 ([RFC6146]) deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and similar ones, which were not documented in [RFC6144], such as 464XLAT ([RFC6877]), in operator (broadband and cellular) and enterprise networks, and provides guidelines to avoid operational issues. Towards that, this document first looks into the possible NAT64 deployment scenarios (split in "known to work" and "known to work under special conditions"), providing a quick and generic comparison table among them. Then the document describes the issues that an operator need to understand on different matters that will allow to define what is the best approach/scenario for each specific network case. A summary provides some recommendations and decision points. A section with clarifications on the usage of this document for enterprise networks, is also provided. Finally, an annex provides an example of a broadband deployment using 464XLAT and another annex provides hints for a CLAT implementation. [RFC7269] already provides information about NAT64 deployment options and experiences. Both, this document and [RFC7269] are complementary; they are looking into different deployment considerations and furthermore, this document is considering the updated deployment experience and newer standards. Palet Martinez Expires January 12, 2020 [Page 4] Internet-Draft NAT64/464XLAT Deployment July 2019 The target deployment scenarios in this document may be covered as well by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. Note that this is true only for the case of broadband networks, as in the case of cellular networks the only supported solution is the use of NAT64/464XLAT. So, it is out of scope of this document to provide a comparison among the different IPv4aaS transition mechanisms, which is being analyzed already in [I-D.lmhp-v6ops-transition-comparison]. Consequently, this document should not be understood as a guide for an operator or enterprise to decide which IPv4aaS is the best one for its own network. Instead it should be used as a tool for understanding all the implications, including relevant documents (or even specific parts of them), for the deployment of NAT64/464XLAT and facilitate the decision process regarding specific deployment details. 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. NAT64 Deployment Scenarios Section 7 of DNS64 ([RFC6147]), provides three scenarios, depending on the location of the DNS64 function. However, since the publication of that document, other deployment scenarios and NAT64 use cases need to be considered in actual networks, despite some of them were specifically ruled out by the original NAT64/DNS64 work. Consequently, the perspective in this document is to broaden those scenarios, including a few new ones. However, in order to be able to reduce the number of possible cases, we work under the assumption that typically, the service provider wants to make sure that all the customers have a service without failures. This means considering the following assumptions for the worst possible case: a. There are hosts that will be validating DNSSEC. b. IPv4 literal addresses and non-IPv6 compliant APIs are being used. c. There are IPv4-only hosts or applications beyond the IPv6-only link (e.g., tethering in cellular networks). The document uses a common set of possible "participant entities": Palet Martinez Expires January 12, 2020 [Page 5] Internet-Draft NAT64/464XLAT Deployment July 2019 1. An IPv6-only access network (IPv6). 2. An IPv4-only remote network/server/service (IPv4). 3. A NAT64 function (NAT64) in the service provider. 4. A DNS64 function (DNS64) in the service provider. 5. An external service provider offering the NAT64 function and/or the DNS64 function (extNAT64/extDNS64). 6. 464XLAT customer side translator (CLAT). Note that the nomenclature used in parenthesis is the one that, for short, will be used in the figures. Note also that for simplicity, the boxes in the figures don't mean they are actually a single device; they just represent one or more functions as located in that part of the network (i.e. a single box with NAT64 and DNS64 functions can actually be several devices, not just one). The possible scenarios are split in two general categories: 1. Known to work. 2. Known to work under special conditions. 3.1. Known to Work The scenarios in this category are known to work, as there are well- known existing deployments from different operators using them. Each one may have different pros and cons, and in some cases the trade- offs, maybe acceptable for some operators. 3.1.1. Service Provider NAT64 with DNS64 In this scenario (Figure 1), the service provider offers both, the NAT64 and the DNS64 functions. This is the most common scenario as originally considered by the designers of NAT64 ([RFC6146]) and DNS64 ([RFC6147]), however also may have the implications related the DNSSEC. This scenario also may fail to solve the issue of IPv4 literal addresses or non-IPv6 compliant APIs, as well as the issue of IPv4-only hosts or applications behind the IPv6-only access network. Palet Martinez Expires January 12, 2020 [Page 6] Internet-Draft NAT64/464XLAT Deployment July 2019 +----------+ +----------+ +----------+ | | | NAT64 | | | | IPv6 +--------+ + +--------+ IPv4 | | | | DNS64 | | | +----------+ +----------+ +----------+ Figure 1: NAT64 with DNS64 A similar scenario (Figure 2) will be if the service provider offers only the DNS64 function, and the NAT64 function is provided by an outsourcing agreement with an external provider. All the considerations in the previous paragraphs of this section, are the same for this sub-case. +----------+ +----------+ | | | | | extNAT64 +--------+ IPv4 | | | | | +----+-----+ +----------+ | | +----------+ +----+-----+ | | | | | IPv6 +--------+ DNS64 + | | | | +----------+ +----------+ Figure 2: NAT64 in external service provider This is equivalent to the scenario (Figure 3) where the outsourcing agreement with the external provider is to provide both the NAT64 and DNS64 functions. Once more, all the considerations in the previous paragraphs of this section are the same for this sub-case. +----------+ +----------+ | extNAT64 | | | | + +-------+ IPv4 | | extDNS64 | | | +----+-----+ +----------+ | +----------+ | | | | | IPv6 +-------------+ | | +----------+ Figure 3: NAT64 and DNS64 in external provider Palet Martinez Expires January 12, 2020 [Page 7] Internet-Draft NAT64/464XLAT Deployment July 2019 One additional equivalent scenario (Figure 4) will be if the service provider offers the NAT64 function only, and the DNS64 function is from an external provider with or without a specific agreement among them. This is a scenario already common today, as several "global" service providers provide free DNS/DNS64 services and users often configure manually their DNS. This will only work if both the NAT64 and the DNS64 functions are using the WKP (Well-Known Prefix) or the same NSP (Network-Specific Prefix). All the considerations in the previous paragraphs of this section, are the same for this sub-case. Of course, if the external DNS64 function is agreed with the service provider, then we are in the same case as in the previous ones already depicted in this scenario. +----------+ | | | extDNS64 | | | +----+-----+ | | +----------+ +----+-----+ +----------+ | | | | | | | IPv6 +--------+ NAT64 +--------+ IPv4 | | | | | | | +----------+ +----------+ +----------+ Figure 4: NAT64; DNS64 by external provider 3.1.2. Service Provider Offering 464XLAT, with DNS64 464XLAT ([RFC6877]) describes an architecture that provides IPv4 connectivity across a network, or part of it, when it is only natively transporting IPv6. [RFC7849] already suggest the need to support the CLAT function in order to ensure the IPv4 service continuity in IPv6-only cellular deployments. In order to do that, 464XLAT ([RFC6877]) relies on the combination of existing protocols: 1. The customer-side translator (CLAT) is a stateless IPv4 to IPv6 translator (NAT46) ([RFC7915]) implemented in the end-user device or CE (Customer Edge Router), located at the "customer edge" of the network. 2. The provider-side translator (PLAT) is a stateful NAT64 ([RFC6146]), implemented typically at in the operator network. Palet Martinez Expires January 12, 2020 [Page 8] Internet-Draft NAT64/464XLAT Deployment July 2019 3. Optionally, DNS64 ([RFC6147]), may allow an optimization: a single translation at the NAT64, instead of two translations (NAT46+NAT64), when the application at the end-user device supports IPv6 DNS (uses AAAA Resource Records). Note that even if in the 464XLAT ([RFC6877]) terminology, the provider-side translator is referred as PLAT, for simplicity and uniformity, across this document is always referred as NAT64 (function). In this scenario (Figure 5) the service provider deploys 464XLAT with a DNS64 function. As a consequence, the DNSSEC issues remain, unless the host is doing the address synthesis. 464XLAT ([RFC6877]) is a very simple approach to cope with the major NAT64+DNS64 drawback: Not working with applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs. 464XLAT ([RFC6877]) has been used initially mainly in IPv6-only cellular networks. By supporting a CLAT function, the end-user device applications can access IPv4-only end-networks/applications, despite those applications or devices use literal IPv4 addresses or non-IPv6 compliant APIs. In addition to that, in the same example of the cellular network above, if the User Equipment (UE) provides tethering, other devices behind it will be presented with a traditional NAT44, in addition to the native IPv6 support, so clearly it allows IPv4-only hosts behind the IPv6-only access network. Furthermore, as discussed in [RFC6877], 464XLAT can be used in broadband IPv6 network architectures, by implementing the CLAT function at the CE. The support of this scenario in a network, offers two additional advantages: o DNS load optimization: A CLAT should implement a DNS proxy (as per [RFC5625]), so that only IPv6 native queries and only for AAAA records are sent to the DNS64 server. Otherwise doubling the number of queries may impact the DNS infrastructure. o Connection establishment delay optimization: If the UE/CE implementation is detecting the presence of a DNS64 function, it may issue only the AAAA query, instead of both the AAAA and A queries. Palet Martinez Expires January 12, 2020 [Page 9] Internet-Draft NAT64/464XLAT Deployment July 2019 In order to understand all the communication possibilities, let's assume the following representation of two dual-stack peers: +-------+ .-----. .-----. | | / \ / \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ / Local \ | SOHO +--( only )---( NAT64 )---( only ) / \ | | \ flow /\ `-----' \ flow / ( Dual- )--+ IPv6 | \ / \ / \ / \ Stack / | CE | `--+--' \ .-----. / `--+--' \ Peer / | with | | \ / Remote\/ | `-----' | CLAT | +---+----+ / \ +---+----+ | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| +-------+ | with | \ Stack / +--------+ | DNS64 | \ Peer / +--------+ `-----' Figure A: Representation of 464XLAT among two peers with DNS64 The possible communication paths, among the IPv4/IPv6 stacks of both peers, in this case, are: a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers. b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements EAM (Explicit Address Mappings) as indicated by Section 4.9. In principle, it is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations. e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT implements EAM as indicated by Section 4.9, instead of using the path d. above, NAT64 translation is avoided and the flow will use IPv6 from the CLAT to the destination. The rest of the figures in this section show different choices for placing the different elements. Palet Martinez Expires January 12, 2020 [Page 10] Internet-Draft NAT64/464XLAT Deployment July 2019 +----------+ +----------+ +----------+ | IPv6 | | NAT64 | | | | + +--------+ + +--------+ IPv4 | | CLAT | | DNS64 | | | +----------+ +----------+ +----------+ Figure 5: 464XLAT with DNS64 A similar scenario (Figure 6) will be if the service provider offers only the DNS64 function, and the NAT64 function is provided by an outsourcing agreement with an external provider. All the considerations in the previous paragraphs of this section are the same for this sub-case. +----------+ +----------+ | | | | | extNAT64 +--------+ IPv4 | | | | | +----+-----+ +----------+ | | +----------+ +----+-----+ | IPv6 | | | | + +--------+ DNS64 + | CLAT | | | +----------+ +----------+ Figure 6: 464XLAT with DNS64; NAT64 in external provider As well, is equivalent to the scenario (Figure 7) where the outsourcing agreement with the external provider is to provide both the NAT64 and DNS64 functions. Once more, all the considerations in the previous paragraphs of this section are the same for this sub- case. +----------+ +----------+ | extNAT64 | | | | + +--------+ IPv4 | | extDNS64 | | | +----+-----+ +----------+ | +----------+ | | IPv6 | | | + +-------------+ | CLAT | +----------+ Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider Palet Martinez Expires January 12, 2020 [Page 11] Internet-Draft NAT64/464XLAT Deployment July 2019 3.1.3. Service Provider Offering 464XLAT, without DNS64 The major advantage of this scenario (Figure 8), using 464XLAT without DNS64, is that the service provider ensures that DNSSEC is never broken, even in case the user modifies the DNS configuration. Nevertheless, some CLAT implementations or applications may impose an extra delay, which is induced by the dual A/AAAA queries (and wait for both responses), unless Happy Eyeballs v2 ([RFC8305]) is also present. A possible variation of this scenario is the case when DNS64 is used only for the discovery of the NAT64 prefix. The rest of the document is not considering it as a different scenario, because once the prefix has been discovered, the DNS64 function is not used, so it behaves as if the DNS64 synthesis function is not present. In this scenario, as in the previous one, there are no issues related to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only access network, neither related to the usage of IPv4 literals or non- IPv6 compliant APIs. The support of this scenario in a network, offers one advantage: o DNS load optimization: A CLAT should implement a DNS proxy (as per [RFC5625]), so that only IPv6 native queries are sent to the DNS64 server. Otherwise doubling the number of queries may impact the DNS infrastructure. As indicated earlier, the connection establishment delay optimization is achieved only in the case of devices, Operating Systems, or applications that use Happy Eyeballs v2 ([RFC8305]), which is very common. Let's assume the representation of two dual-stack peers as in the previous case: Palet Martinez Expires January 12, 2020 [Page 12] Internet-Draft NAT64/464XLAT Deployment July 2019 +-------+ .-----. .-----. | | / \ / \ .-----. | Res./ | / IPv6- \ .-----. / IPv4- \ / Local \ | SOHO +--( only )---( NAT64 )---( only ) / \ | | \ flow /\ `-----' \ flow / ( Dual- )--+ IPv6 | \ / \ / \ / \ Stack / | CE | `--+--' \ .-----. / `--+--' \ Peer / | with | | \ / Remote\/ | `-----' | CLAT | +---+----+ / \ +---+----+ | | |DNS/IPv6| ( Dual- ) |DNS/IPv4| +-------+ +--------+ \ Stack / +--------+ \ Peer / `-----' Figure B: Representation of 464XLAT among two peers without DNS64 The possible communication paths, among the IPv4/IPv6 stacks of both peers, in this case, are: a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers. b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations. c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements EAM as indicated by Section 4.9. In principle, it is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations. e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT implements EAM as indicated by Section 4.9, instead of using the path d. above, NAT64 translation is avoided and the flow will use IPv6 from the CLAT to the destination. It needs to be noticed that this scenario works while the local hosts/applications are dual-stack (which is the current situation), because the connectivity from a local-IPv6 to a remote-IPv4 is not possible without an AAAA synthesis. This aspect is important only when in the LANs behind the CLAT there are IPv6-only hosts and they need to communicate with remote IPv4-only hosts. However, it doesn't look a sensible approach from an Operating System or application vendor perspective, to provide IPv6-only support unless, similarly to case c above, there is certainty of peers supporting IPv6 as well. A Palet Martinez Expires January 12, 2020 [Page 13] Internet-Draft NAT64/464XLAT Deployment July 2019 solution approach to this is also presented in [I-D.palet-v6ops-464xlat-opt-cdn-caches]. The following figures show different choices for placing the different elements. +----------+ +----------+ +----------+ | IPv6 | | | | | | + +--------+ NAT64 +--------+ IPv4 | | CLAT | | | | | +----------+ +----------+ +----------+ Figure 8: 464XLAT without DNS64 This is equivalent to the scenario (Figure 9) where there is an outsourcing agreement with an external provider for the NAT64 function. All the considerations in the previous paragraphs of this section are the same for this sub-case. +----------+ +----------+ | | | | | extNAT64 +--------+ IPv4 | | | | | +----+-----+ +----------+ | +----------+ | | IPv6 | | | + +-------------+ | CLAT | +----------+ Figure 9: 464XLAT without DNS64; NAT64 in external provider 3.2. Known to Work Under Special Conditions The scenarios in this category are known to not work unless significant effort is devoted to solve the issues, or are intended to solve problems across "closed" networks, instead of as a general Internet access usage. In addition to the different pros, cons and trade-offs, which may be acceptable for some operators, they have implementation difficulties, as they are beyond the original expectations of the NAT64/DNS64 original intent. 3.2.1. Service Provider NAT64 without DNS64 In this scenario (Figure 10), the service provider offers a NAT64 function, however there is no DNS64 function support at all. Palet Martinez Expires January 12, 2020 [Page 14] Internet-Draft NAT64/464XLAT Deployment July 2019 As a consequence, an IPv6 host in the IPv6-only access network, will not be able to detect the presence of DNS64 by means of [RFC7050], neither to learn the IPv6 prefix to be used for the NAT64 function. This can be sorted out as indicated in Section 4.1.1. However, despite that, because the lack of the DNS64 function, the IPv6 host will not be able to obtain AAAA synthesized records, so the NAT64 function becomes useless. An exception to this "useless" scenario will be manually configure mappings between the A records of each of the IPv4-only remote hosts and the corresponding AAAA records, with the WKP (Well-Known Prefix) or NSP (Network-Specific Prefix) used by the service provider NAT64 function, as if they were synthesized by a DNS64 function. This mapping could be done by several means, typically at the authoritative DNS server, or at the service provider resolvers by means of DNS RPZ (Response Policy Zones, [I-D.vixie-dns-rpz]) or equivalent functionality. DNS RPZ, may have implications in DNSSEC, if the zone is signed. Also, if the service provider is using an NSP, having the mapping at the authoritative server, may create troubles to other parties trying to use different NSP or the WKP, unless multiple DNS "views" (split-DNS) is also being used at the authoritative servers. Generally, the mappings alternative, will only make sense if a few set of IPv4-only remote hosts need to be accessed by a single network (or a small number of them), which support IPv6-only in the access. This will require some kind of mutual agreement for using this procedure, so it doesn't care if they become a trouble for other parties across Internet ("closed services"). In any case, this scenario doesn't solve the issue of IPv4 literal addresses or non-IPv6 compliant APIs, neither it solves the problem of IPv4-only hosts within that IPv6-only access network. +----------+ +----------+ +----------+ | | | | | | | IPv6 +--------+ NAT64 +--------+ IPv4 | | | | | | | +----------+ +----------+ +----------+ Figure 10: NAT64 without DNS64 Palet Martinez Expires January 12, 2020 [Page 15] Internet-Draft NAT64/464XLAT Deployment July 2019 3.2.2. Service Provider NAT64; DNS64 in the IPv6 hosts In this scenario (Figure 11), the service provider offers the NAT64 function, but not the DNS64 function. However, the IPv6 hosts have a built-in DNS64 function. This may become common if the DNS64 function is implemented in all the IPv6 hosts/stacks. However, commonly this is not the actual situation, even if it may happen in the medium-term. At this way, the DNSSEC validation is performed on the A record, and then the host can use the DNS64 function so to be able to use the NAT64 function, without any DNSSEC issues. This scenario fails to solve the issue of IPv4 literal addresses or non-IPv6 compliant APIs, unless the IPv6 hosts also supports Happy Eyeballs v2 ([RFC8305], Section 7.1), which may solve that issue. However, this scenario still fails to solve the problem of IPv4-only hosts or applications behind the IPv6-only access network. +----------+ +----------+ +----------+ | IPv6 | | | | | | + +--------+ NAT64 +--------+ IPv4 | | DNS64 | | | | | +----------+ +----------+ +----------+ Figure 11: NAT64; DNS64 in IPv6 hosts 3.2.3. Service Provider NAT64; DNS64 in the IPv4-only remote network In this scenario (Figure 12), the service provider offers the NAT64 function only. The remote IPv4-only network offers the DNS64 function. This is not common, and looks like doesn't make too much sense that a remote network, not deploying IPv6, is providing a DNS64 function. As in the case of the scenario depicted in Section 3.2.1, it will only work if both sides are using the WKP or the same NSP, so the same considerations apply. It can be also tuned to behave as in Section 3.1.1 This scenario still fails to solve the issue of IPv4 literal addresses or non-IPv6 compliant APIs. This scenario also fails to solve the problem of IPv4-only hosts or applications behind the IPv6-only access network. Palet Martinez Expires January 12, 2020 [Page 16] Internet-Draft NAT64/464XLAT Deployment July 2019 +----------+ +----------+ +----------+ | | | | | IPv4 | | IPv6 +--------+ NAT64 +--------+ + | | | | | | DNS64 | +----------+ +----------+ +----------+ Figure 12: NAT64; DNS64 in the IPv4-only 3.3. Comparing the Scenarios This section compares the different scenarios, including the possible variations (each one represented in the precedent sections by a different figure), looking at the following criteria: a. DNSSEC: Are there hosts validating DNSSEC? b. Literal/APIs: Are there applications using IPv4 literals or non- IPv6 compliant APIs? c. IPv4-only: Are there hosts or applications using IPv4-only? d. Foreign DNS: Is the scenario surviving if the user, Operating System, applications or devices change the DNS? e. DNS load opt. (DNS load optimization): Are there extra queries that may impact DNS infrastructure? f. Connect. opt. (Connection establishment delay optimization): Is the UE/CE issuing only the AAAA query or also an A query and waiting for both responses? In the next table, the columns represent each of the scenarios from the previous sections, by the figure number. The possible values are: o "-" Scenario "bad" for that criteria. o "+" Scenario "good" for that criteria. o "*" Scenario "bad" for that criteria, however it is typically resolved, with the support of Happy Eyeballs v2 ([RFC8305]). In some cases, "countermeasures", alternative or special configurations, may be available for the criteria designated as "bad". So, this comparison is considering a generic case, as a quick comparison guide. In some cases, a "bad" criterion is not necessarily a negative aspect, all it depends on the specific needs/ characteristics of the network where the deployment will take place. Palet Martinez Expires January 12, 2020 [Page 17] Internet-Draft NAT64/464XLAT Deployment July 2019 For instance, in a network which has only IPv6-only hosts and apps using only DNS and IPv6-compliant APIs, there is no impact using only NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is still relevant. +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ Figure 13: Scenario Comparison As a general conclusion, we should note that, if the network must support applications using any of the following: o IPv4 literals o non-IPv6-compliant APIs o IPv4-only hosts or applications Then, only the scenarios with 464XLAT, a CLAT function, or equivalent built-in local address synthesis features, will provide a valid solution. Further to that, those scenarios will also keep working if the DNS configuration is modified. Clearly also, depending on if DNS64 is used or not, DNSSEC may be broken for those hosts doing DNSSEC validation. All the scenarios are good in terms of DNS load optimization, and in the case of 464XLAT it may provide an extra degree of optimization. Finally, all them are also good in terms of connection establishment delay optimization. However, in the case of 464XLAT without DNS64, it requires the usage of Happy Eyeballs v2. This is not an issue, as commonly it is available in actual Operating Systems. Palet Martinez Expires January 12, 2020 [Page 18] Internet-Draft NAT64/464XLAT Deployment July 2019 4. Issues to be Considered This section reviews the different issues that an operator needs to consider towards a NAT64/464XLAT deployment, as they may bring to specific decision points about how to approach that deployment. 4.1. DNSSEC Considerations and Possible Approaches As indicated in Section 8 of [RFC6147] (DNS64, Security Considerations), because DNS64 modifies DNS answers and DNSSEC is designed to detect such modifications, DNS64 may break DNSSEC. If a device connected to an IPv6-only access network, queries for a domain name in a signed zone, by means of a recursive name server that supports DNS64, and the result is a synthesized AAAA record, and the recursive name server is configured to perform DNSSEC validation and has a valid chain of trust to the zone in question, it will cryptographically validate the negative response from the authoritative name server. This is the expected DNS64 behavior: The recursive name server actually "lies" to the client device. However, in most of the cases, the client will not notice it, because generally, they don't perform validation themselves and instead, rely on the recursive name servers. A validating DNS64 resolver in fact, increase the confidence on the synthetic AAAA, as it has validated that a non-synthetic AAAA for sure, doesn't exists. However, if the client device is NAT64-oblivious (most common case) and performs DNSSEC validation on the AAAA record, it will fail as it is a synthesized record. The best possible scenario from DNSSEC point of view, is when the client requests the DNS64 server to perform the DNSSEC validation (by setting the DO bit to 1 and the CD bit to 0). In this case, the DNS64 server validates the data, thus tampering may only happen inside the DNS64 server (which is considered as a trusted part, thus its likelihood is low) or between the DNS64 server and the client. All other parts of the system (including transmission and caching) are protected by DNSSEC ([Threat-DNS64]). Similarly, if the client querying the recursive name server is another name server configured to use it as a forwarder, and is performing DNSSEC validation, it will also fail on any synthesized AAAA record. All those considerations are extensively covered in Sections 3, 5.5 and 6.2 of [RFC6147]. A solution to avoid DNSSEC issues, will be that all the signed zones Palet Martinez Expires January 12, 2020 [Page 19] Internet-Draft NAT64/464XLAT Deployment July 2019 also provide IPv6 connectivity, together with the corresponding AAAA records. However, this is out of the control of the operator needing to deploy a NAT64 function. This has been proposed already in [I-D.bp-v6ops-ipv6-ready-dns-dnssec]. An alternative solution, which was the one considered while developing [RFC6147], is that validators will be DNS64-aware, so could perform the necessary discovery and do their own synthesis. That was done under the expectation that it was sufficiently early in the validator-deployment curve that it would be ok to break certain DNSSEC assumptions for networks who were really stuck in a NAT64/ DNS64-needing world. As already indicated, the scenarios in the previous section, are in fact somehow simplified, looking at the worst possible case. Saying it in a different way: "trying to look for the most perfect approach". DNSSEC breach will not happen if the end-host is not doing validation. Existing previous studies seems to indicate that the figures of DNSSEC actually broken by using DNS64 will be around 1.7% ([About-DNS64]) of the cases. However, we can't negate that this may increase, as DNSSEC deployment grows. Consequently, a decision point for the operator must depend on "do I really care for that percentage of cases and the impact in my helpdesk or can I provide alternative solutions for them?". Some possible solutions may be taken, as depicted in the next sections. 4.1.1. Not using DNS64 A solution will be to avoid using DNS64, but as already indicated this is not possible in all the scenarios. The use of DNS64 is a key component for some networks, in order to comply with traffic performance metrics, monitored by some governmental bodies and other institutions ([FCC], [ARCEP]). One drawback of not having a DNS64 at the network side, is that is not possible to heuristically discover the NAT64 ([RFC7050]). Consequently, an IPv6 host behind the IPv6-only access network, will not be able to detect the presence of the NAT64 function, neither to learn the IPv6 prefix to be used for it, unless it is configured by alternative means. The discovery of the IPv6 prefix could be solved, as described in [RFC7050], by means of adding the relevant AAAA records to the ipv4only.arpa. zone, of the service provider recursive servers, i.e., if using the WKP (64:ff9b::/96): Palet Martinez Expires January 12, 2020 [Page 20] Internet-Draft NAT64/464XLAT Deployment July 2019 ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. NS . ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.171 An alternative option to the above, is the use of DNS RPZ ([I-D.vixie-dns-rpz]) or equivalent functionalities. Note that this may impact DNSSEC if the zone is signed. One more alternative, only valid in environments with PCP support (for both the hosts or CEs and for the service provider network), is to follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP). Other alternatives may be available in the future. All them are extensively discussed in [RFC7051], however the deployment evolution has evolved many considerations from that document. New options are being documented, such using Router Advertising ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]). It may be convenient the simultaneous support of several of the possible approaches, in order to ensure that clients with different ways to configure the NAT64 prefix, successfully obtain it. This is also convenient even if DNS64 is being used. Of special relevance to this section is also [I-D.cheshire-sudn-ipv4only-dot-arpa]. 4.1.2. DNSSEC validator aware of DNS64 In general, by default, DNS servers with DNS64 function will not synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the query. In this case, as only an A record is available, if a CLAT function is present, it means that the CLAT will take the responsibility, as in the case of literal IPv4 addresses, to keep that traffic flow end-to- end as IPv4, so DNSSEC is not broken. However, this will not work if a CLAT function is not present as the hosts will not be able to use IPv4 (which is the case for all the scenarios without 464XLAT). Palet Martinez Expires January 12, 2020 [Page 21] Internet-Draft NAT64/464XLAT Deployment July 2019 4.1.3. Stub validator If the DO flag is set and the client device performs DNSSEC validation, and the Checking Disabled (CD) flag is set for a query, the DNS64 recursive server will not synthesize AAAA responses. In this case, the client could perform the DNSSEC validation with the A record and then synthesize the AAAA ([RFC6052]). For that to be possible, the client must have learned beforehand the NAT64 prefix using any of the available methods ([RFC7050], [RFC7225], [I-D.ietf-6man-ra-pref64], [I-D.li-intarea-nat64-prefix-dhcp-option]). This allows the client device to avoid using the DNS64 function and still use NAT64 even with DNSSEC. If the end-host is IPv4-only, this will not work if a CLAT function is not present (scenarios without 464XLAT). Some devices or Operating Systems may implement, instead of a CLAT, an equivalent function by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the considerations in the above paragraphs are also applicable. 4.1.4. CLAT with DNS proxy and validator If a CE includes CLAT support and also a DNS proxy, as indicated in Section 6.4 of [RFC6877], the CE could behave as a stub validator on behalf of the client devices. Then, following the same approach described in the Section 4.1.3, the DNS proxy actually will "lie" to the client devices, which in most of the cases will not notice it, unless they perform validation by themselves. Again, this allow the client devices to avoid using the DNS64 function and still use NAT64 with DNSSEC. Once more, this will not work without a CLAT function (scenarios without 464XLAT). 4.1.5. ACL of clients In cases of dual-stack clients, the AAAA queries typically take preference over A queries. If DNS64 is enabled for those clients, will never get A records, even for IPv4-only servers. As a consequence, in cases where there are IPv4-only servers, and those are located in the path before the NAT64 function, the clients will not be able to reach them. If DNSSEC is being used for all those flows, specific addresses or prefixes can be left-out of the DNS64 synthesis by means of ACLs. Palet Martinez Expires January 12, 2020 [Page 22] Internet-Draft NAT64/464XLAT Deployment July 2019 Once more, this will not work without a CLAT function (scenarios without 464XLAT). 4.1.6. Mapping-out IPv4 addresses If there are well-known specific IPv4 addresses or prefixes using DNSSEC, they can be mapped-out of the DNS64 synthesis. Even if this is not related to DNSSEC, this "mapping-out" feature is actually, quite commonly used to ensure that [RFC1918] addresses (for example used by LAN servers) are not synthesized to AAAA. Once more, this will not work without a CLAT function (scenarios without 464XLAT). 4.2. DNS64 and Reverse Mapping When a client device, using DNS64 tries to reverse-map a synthesized IPv6 address, the name server responds with a CNAME record pointing the domain name used to reverse-map the synthesized IPv6 address (the one under ip6.arpa), to the domain name corresponding to the embedded IPv4 address (under in-addr.arpa). This is the expected behavior, so no issues need to be considered regarding DNS reverse mapping. 4.3. Using 464XLAT with/without DNS64 In the case the client device is IPv6-only (either because the stack or application is IPv6-only, or because it is connected via an IPv6-only LAN) and the remote server is IPv4-only (either because the stack is IPv4-only, or because it is connected via an IPv4-only LAN), only NAT64 combined with DNS64 will be able to provide access among both. Because DNS64 is then required, DNSSEC validation will be only possible if the recursive name server is validating the negative response from the authoritative name server and the client is not performing validation. Note that is not expected at this stage of the transition, that applications, devices or Operating Systems are IPv6-only. It will not be a sensible decision for a developer to work on that direction, unless it is clear that the deployment scenario fully supports it. On the other hand, an end-user or enterprise network may decide to run IPv6-only in the LANs. In case there is any chance for applications to be IPv6-only, the Operating System may be responsible either for doing a local address synthesis, or alternatively, setting up some kind of on-demand VPN (IPv4-in-IPv6), which need to be Palet Martinez Expires January 12, 2020 [Page 23] Internet-Draft NAT64/464XLAT Deployment July 2019 supported by that network. This may become very common in enterprise networks, where "Unique IPv6 Prefix per Host" [RFC8273] is supported. However, when the client device is dual-stack and/or connected in a dual-stack LAN by means of a CLAT function (or has a built-in CLAT function), DNS64 is an option. 1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if using literal IPv4 addresses or non-IPv6 compliant APIs) will not use the CLAT, so will use the IPv6 path and only one translation will be done at the NAT64. This may break DNSSEC, unless measures as described in the precedent sections are taken. 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will make use of the CLAT, so two translations are required (NAT46 at the CLAT and NAT64 at the PLAT), which adds some overhead in terms of the extra NAT46 translation. However, this avoids the AAAA synthesis and consequently will never break DNSSEC. Note that the extra translation, when DNS64 is not used, takes place at the CLAT, which means no extra overhead for the operator. It however adds potential extra delays to establish the connections, and no perceptible impact for a CE in a broadband network, while it may have some impact in a battery powered device. This cost for a battery powered device, is possibly comparable to the cost when the device is doing a local address synthesis (see Section 7.1 of [RFC8305]). 4.4. Foreign DNS Clients, devices or applications in a service provider network, may use DNS servers from other networks. This may be the case either if individual applications use their own DNS server, the Operating System itself or even the CE, or combinations of the above. Those "foreign" DNS servers may not support DNS64, which as a consequence, will mean that those scenarios that require a DNS64 may not work. However, if a CLAT function is available, the considerations in Section 4.3 will apply. In the case that the foreign DNS supports the DNS64 function, we may be in the situation of providing incorrect configurations parameters, for example, un-matching WKP or NSP, or a case such the one described in Section 3.2.3. Having a CLAT function, even if using foreign DNS without a DNS64 function, ensures that everything will work, so the CLAT must be considered as an advantage even against user configuration errors. Palet Martinez Expires January 12, 2020 [Page 24] Internet-Draft NAT64/464XLAT Deployment July 2019 The cost of this, is that all the traffic will use a double translation (NAT46 at the CLAT and NAT64 at the operator network), unless there is support for EAM (Section 4.9). An exception to that is the case when there is a CLAT function at the CE, which is not able to obtain the correct configuration parameters (again, un-matching WKP or NSP). However, it needs to be emphasized, that if there is not a CLAT function (scenarios without 464XLAT), an external DNS without DNS64 support, will disallow any access to IPv4-only destination networks, and will not guarantee the correct DNSSEC validation, so will behave as in the Section 3.2.1. In summary, it can be said, that the consequences of the use of foreign DNS depend very much in each specific case. However, in general, if a CLAT function is present, most of the time, there will not be any. In the other cases, generally, the access to IPv6-enabled services is still guaranteed for IPv6-enabled hosts, but not for IPv4-only hosts, neither the access to IPv4-only services for any hosts in the network. The causes of "foreign DNS" could be classified in three main categories, as depicted in the following sub-sections. 4.4.1. Manual Configuration of DNS It is becoming increasingly common that end-users or even devices or applications configure alternative DNS in their Operating Systems, and sometimes in CEs. 4.4.2. DNS Privacy/Encryption Mechanisms Clients or applications may use mechanisms for DNS privacy/ encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH and DoQ. Those DNS privacy/encryption options, currently are typically provided by the applications, not the Operating System vendors. At the time of writing this document, at least DoT and DoH standards have declared DNS64 (and consequently NAT64) out of their scope, so an application using them may break NAT64, unless a correctly configured CLAT function is used. Palet Martinez Expires January 12, 2020 [Page 25] Internet-Draft NAT64/464XLAT Deployment July 2019 4.4.3. Split DNS and VPNs When networks or hosts use "split-DNS" (also called Split Horizon, DNS views or private DNS), the successful use of the DNS64 is not guaranteed. Section 4 of [RFC6950], analyses this case. A similar situation may happen in case of VPNs that force all the DNS queries through the VPN, ignoring the operator DNS64 function. 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) Section 3 of [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), discusses some considerations which are useful to decide if an operator should use the WKP or an NSP. Taking in consideration that discussion and other issues, we can summarize the possible decision points as: a. The WKP MUST NOT be used to represent non-global IPv4 addresses. If this is required because the network to be translated use non- global addresses, then an NSP is required. b. The WKP MAY appear in inter-domain routing tables, if the operator provides a NAT64 function to peers. However, in this case, special considerations related to BGP filtering are required and IPv4-embedded IPv6 prefixes longer than the WKP MUST NOT be advertised (or accepted) in BGP. An NSP may be a more appropriate option in those cases. c. If several NAT64 use the same prefix, packets from the same flow may be routed to different NAT64 in case of routing changes. This can be avoided either by using different prefixes for each NAT64 function, or by ensuring that all the NAT64 coordinate their state. Using an NSP could simplify that. d. If DNS64 is required and users, devices, Operating Systems or applications may change their DNS configuration, and deliberately choose an alternative DNS64 function, most probably alternative DNS64 will use by default the WKP. In that case, if an NSP is used by the NAT64 function, clients will not be able to use the operator NAT64 function, which will break connectivity to IPv4-only destinations. 4.6. IPv4 literals and non-IPv6 Compliant APIs A host or application using literal IPv4 addresses or older APIs, which aren't IPv6 compliant, behind a network with IPv6-only access, will not work unless any of the following alternatives is provided: Palet Martinez Expires January 12, 2020 [Page 26] Internet-Draft NAT64/464XLAT Deployment July 2019 o CLAT (or equivalent function). o Happy Eyeballs v2 (Section 7.1, [RFC8305]). o Bump-in-the-Host ([RFC6535]) with a DNS64 function. Those alternatives will solve the problem for an end-host. However, if that end-hosts is providing "tethering" or an equivalent service to other hosts, that needs to be considered as well. In other words, in a case of a cellular network, it resolves the issue for the UE itself, but may be not the case for hosts behind it. Otherwise, the support of 464XLAT is the only valid and complete approach to resolve this issue. 4.7. IPv4-only Hosts or Applications An IPv4-only hosts or application behind a network with IPv6-only access, will not work unless a CLAT function is present. 464XLAT is the only valid approach to resolve this issue. 4.8. CLAT Translation Considerations As described in Section 6.3 of [RFC6877] (IPv6 Prefix Handling), if the CLAT function can be configured with a dedicated /64 prefix for the NAT46 translation, then it will be possible to do a more efficient stateless translation. Otherwise, if this dedicated prefix is not available, the CLAT function will need to do a stateful translation, for example performing stateful NAT44 for all the IPv4 LAN packets, so they appear as coming from a single IPv4 address, and then in turn, stateless translated to a single IPv6 address. A possible setup, in order to maximize the CLAT performance, is to configure the dedicated translation prefix. This can be easily achieved automatically, if the broadband CE or end-user device is able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or other alternatives. The CE can then use a specific /64 for the translation. This is also possible when broadband is provided by a cellular access. The above recommendation is often not possible for cellular networks, when connecting smartphones (as UEs), as generally they don't use DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each PDP context and prefix sharing ([RFC6877]) is used. So, in this case, the UEs typically have a build-in CLAT function which is Palet Martinez Expires January 12, 2020 [Page 27] Internet-Draft NAT64/464XLAT Deployment July 2019 performing a stateful NAT44 translation before the stateless NAT46. 4.9. EAM Considerations Explicit Address Mappings for Stateless IP/ICMP Translation ([RFC7757]) provide a way to configure explicit mappings between IPv4 and IPv6 prefixes of any length. When this is used, for example in a CLAT function, it may provide a simple mechanism in order to avoid traffic flows between IPv4-only nodes or applications and dual-stack destinations to be translated twice (NAT46 and NAT64), by creating mapping entries with the GUA of the IPv6-reachable destination. This optimization of the NAT64 usage is very useful in many scenarios, including CDNs and caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches]. In addition to that, it may provide as well a way for IPv4-only nodes or applications to communicate with IPv6-only destinations. 4.10. Incoming Connections The use of NAT64, in principle, disallows IPv4 incoming connections, which may be still needed for IPv4-only peer-to-peer applications. However, there are several alternatives that resolve this issue: a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are commonly used by peer-to-peer applications in order to allow incoming connections with IPv4 NAT. In the case of NAT64, they work as well. RFC editor note: If in time, replace STUN and TURN with [I-D.ietf-tram-stunbis] / [I-D.ietf-tram-turnbis]. b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and IPv6 packets are translated and forwarded. A NAT64 may implement PCP to allow this service. c. EAM ([RFC7757]) may also be used in order to configure explicit mappings for customers that require them. This is used for example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]). 5. Summary of Deployment Recommendations for NAT64/464XLAT NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predominant mechanism in the majority of the cellular networks, which account for hundreds of millions of users ([ISOC]). NAT64/464XLAT offer different choices of deployment, depending on each network case, needs and requirements. Despite that, this document is not an explicit recommendation for using this choice versus other IPv4aaS transition mechanisms. Instead, this document is a guide that Palet Martinez Expires January 12, 2020 [Page 28] Internet-Draft NAT64/464XLAT Deployment July 2019 facilitates evaluating a possible implementation of NAT64/464XLAT and key decision points about specific design considerations for its deployment. Depending on the specific requirements of each deployment case, DNS64 may be a required function, while in other cases the adverse effects may be counterproductive. Similarly, in some cases a NAT64 function, together with a DNS64 function, may be a valid solution, when there is a certainty that IPv4-only hosts or applications do not need to be supported (Section 4.6 and Section 4.7). However, in other cases (i.e. IPv4-only devices or applications need to be supported), the limitations of NAT64/DNS64, may suggest the operator to look into 464XLAT as a more complete solution. In the case of broadband managed networks (where the CE is provided or suggested/supported by the operator), in order to fully support the actual user needs (IPv4-only devices and applications, usage of IPv4 literals and non-IPv6 compliant APIs), the 464XLAT scenario should be considered. In that case, it must support a CLAT function. If the operator provides DNS services, in order to increase performance by reducing the double translation for all the IPv4 traffic, they may support a DNS64 function and avoid, as much as possible, breaking DNSSEC. In this case, if the DNS service is offering DNSSEC validation, then it must be in such way that it is aware of the DNS64. This is considered the simpler and safer approach, and may be combined as well with other recommendations described in this document: o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2). o Devices running CLAT SHOULD follow the indications in Section 4.1.3 (Stub Validator). However, this may be out of the control of the operator. o CEs SHOULD include a DNS proxy and validator (Section 4.1.4). o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4 addresses) MAY be considered by operators, depending on their own infrastructure. This "increased performance" approach has the disadvantage of potentially breaking DNSSEC for a small percentage of validating end- hosts versus the small impact of a double translation taking place in the CE. If CE performance is not an issue, which is the most frequent case, then a much safer approach is to not use DNS64 at all, and consequently, ensure that all the IPv4 traffic is translated at the CLAT (Section 4.3). Palet Martinez Expires January 12, 2020 [Page 29] Internet-Draft NAT64/464XLAT Deployment July 2019 If DNS64 is not used, at least one of the alternatives described in Section 4.1.1, must be followed in order to learn the NAT64 prefix. The operator needs to consider that if the DNS configuration can be modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most probably is impossible to avoid, there are chances that instead of configuring a DNS64 a foreign non-DNS64 is used. In a scenario with only a NAT64 function IPv4-only remote host will no longer be accessible. Instead, it will continue to work in the case of 464XLAT. Similar considerations need to be taken regarding the usage of a NAT64 WKP vs NSP (Section 4.5), as they must match with the configuration of the DNS64. In case of using foreign DNS, they may not match. If there is a CLAT and the configured foreign DNS is not a DNS64, the network will keep working only if other means of learning the NAT64 prefix are available. As described in Section 4.8, for broadband networks, the CEs supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or alternative means for configuring a shorter prefix. The CE SHOULD internally reserve one /64 for the stateless NAT46 translation. The operator must ensure that the customers get allocated prefixes shorter than /64 in order to support this optimization. One way or the other, this is not impacting the performance of the operator network. Operators may follow Section 7 of [RFC6877] (Deployment Considerations), for suggestions in order to take advantage of traffic engineering requirements. In the case of cellular networks, the considerations regarding DNSSEC may appear as out-of-scope, because UEs Operating Systems, commonly don't support DNSSEC. However, applications running on them may do, or it may be an Operating System "built-in" support in the future. Moreover, if those devices offer tethering, other client devices behind the UE, may be doing the validation, hence the relevance of a proper DNSSEC support by the operator network. Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" ([RFC7050]), allow a progressive IPv6 deployment, with a single APN supporting all types of PDP context (IPv4, IPv6, IPv4v6). This approach allows the network to automatically serve every possible combinations of UEs. If the operator chooses to provide validation for the DNS64 prefix discovery, it must follow the advice from Section 3.1. of [RFC7050] Palet Martinez Expires January 12, 2020 [Page 30] Internet-Draft NAT64/464XLAT Deployment July 2019 (Validation of Discovered Pref64::/n). One last consideration, is that many networks may have a mix of different complex scenarios at the same time, for example, customers requiring 464XLAT, others not requiring it, customers requiring DNS64, others not, etc. In general, the different issues and the approaches described in this document can be implemented at the same time for different customers or parts of the network. That mix of approaches don't present any problem or incompatibility, as they work well together, being just a matter of appropriate and differentiated provisioning. In fact, the NAT64/464XLAT approach facilitates an operator offering both cellular and broadband services, to have a single IPv4aaS for both networks while differentiating the deployment key decisions to optimize each case. It even makes possible using hybrid CEs that have a main broadband access link and a backup via the cellular network. In an ideal world we could safely use DNS64, if the approach proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the cases where DNSSEC may be broken. However, this will not solve the issues related to DNS Privacy and Split DNS. The only 100% safe solution, which also resolves all the issues, will be, in addition to having a CLAT function, not using a DNS64 but instead making sure that the hosts have a built-in address synthesis feature. Operators could manage to provide CEs with the CLAT function, however the built-in address synthesis feature is out of their control. If the synthesis is provided either by the Operating System (via its DNS resolver API) or by the application (via its own DNS resolver), in such way that the prefix used for the NAT64 function is reachable for the host, the problem goes away. Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9, provides a very relevant optimization, avoiding double-translations. Applications that require incoming connections, typically already provide means for that. However, PCP and EAM, as indicated in Section 4.10, are valid alternatives, even for creating explicit mappings for customers that require them. 6. Deployment of 464XLAT/NAT64 in Enterprise Networks The recommendations of this document can be used as well in enterprise networks, campus and other similar scenarios (including managed end-user networks). This include scenarios where the NAT64 function (and DNS64 function, if available) are under the control of that network (or can be Palet Martinez Expires January 12, 2020 [Page 31] Internet-Draft NAT64/464XLAT Deployment July 2019 configured manually according to that network specific requirements), and for whatever reasons, there is a need to provide "IPv6-only access" to any part of that network or it is IPv6-only connected to third party-networks. An example of that is the IETF meetings network itself, where both NAT64 and DNS64 functions are provided, presenting in this case the same issues as per Section 3.1.1. If there is a CLAT function in the IETF network, then there is no need to use DNS64 and it falls under the considerations of Section 3.1.3. Both scenarios have been tested and verified already in the IETF network itself. Next figures are only meant to represent a few of the possible scenarios, not pretending to be the only feasible ones. Figure 14 provides an example of an IPv6-only enterprise network connected with dual-stack to Internet and using local NAT64 and DNS64 functions. +----------------------------------+ | Enterprise Network | | +----------+ +----------+ | +----------+ | | IPv6 | | NAT64 | | | IPv4 | | | only +--------+ + | +-------+ + | | | LANs | | DNS64 | | | IPv6 | | +----------+ +----------+ | +----------+ +----------------------------------+ Figure 14: IPv6-only enterprise with NAT64 and DNS64 Figure 15 provides an example of a dual-stack (DS) enterprise network connected with dual-stack (DS) to Internet and using a CLAT function, without a DNS64 function. +----------------------------------+ | Enterprise Network | | +----------+ +----------+ | +----------+ | | IPv6 | | | | | IPv4 | | | + +--------+ NAT64 | +-------+ + | | | CLAT | | | | | IPv6 | | +----------+ +----------+ | +----------+ +----------------------------------+ Figure 15: DS enterprise with CLAT, DS Internet, without DNS64 Finally, Figure 16 provides an example of an IPv6-only provider with a NAT64 function, and a dual-stack (DS) enterprise network by means of their own CLAT function, without a DNS64 function. Palet Martinez Expires January 12, 2020 [Page 32] Internet-Draft NAT64/464XLAT Deployment July 2019 +----------------------------------+ | Enterprise Network | | +----------+ +----------+ | +----------+ | | IPv6 | | | | IPv6 | | | | + +--------+ CLAT | +--------+ NAT64 | | | IPv4 | | | | only | | | +----------+ +----------+ | +----------+ +----------------------------------+ Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64 7. Security Considerations This document does not have new specific security considerations beyond those already reported by each of the documents cited. For example, DNS64 ([RFC6147]) already describes the DNSSEC issues. Note that, as already described in Section 4.4, there may be undesirable interactions, specially if using VPNs or DNS privacy, which may impact in the correct performance of DNS64/NAT64. It should be remarked that the use of a DNS64 function has equivalent privacy considerations as in the case of a regular DNS, either located in the service provider or an external one. 8. IANA Considerations This document does not have any new specific IANA considerations. Note: This section is assuming that https://www.rfc- editor.org/errata/eid5152 is resolved, otherwise, this section may include the required text to resolve the issue. Alternatively, this could be fixed also by [I-D.cheshire-sudn-ipv4only-dot-arpa]. 9. Acknowledgements The author would like to acknowledge the inputs of Gabor Lencse, Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson and Eric Vyncke. Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 and DNS64, as well as several emails in mailing lists from Mark Andrews, have been very useful for this work. Christian Huitema inspired working in this document by suggesting Palet Martinez Expires January 12, 2020 [Page 33] Internet-Draft NAT64/464XLAT Deployment July 2019 that DNS64 should never be used, during a discussion regarding the deployment of CLAT in the IETF network. 10. ANNEX A: Example of Broadband Deployment with 464XLAT This section summarizes how an operator may deploy an IPv6-only network for residential/SOHO customers, supporting IPv6 inbound connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT. Note that an equivalent setup could also be provided for enterprise customers. In case they need to support IPv4 inbound connections, several mechanisms, depending on specific customer needs, allow that, for instance [RFC7757]. Conceptually, most part of the operator network could be IPv6-only (represented in the next pictures as "IPv6-only flow"), or even if this part of the network is actually dual-stack, only IPv6-access is available for some customers (i.e. residential customers). This part of the network connects the IPv6-only subscribers (by means of IPv6-only access links), to the IPv6 upstream providers, as well as to the IPv4-Internet by means of the NAT64 (PLAT in the 464XLAT terminology). The traffic flow from and back to the CE to services available in the IPv6 Internet (or even dual-stack remote services, when IPv6 is being used), is purely native IPv6 traffic, so there are no special considerations about it. Looking at the picture from the DNS perspective, there are remote networks with are IPv4-only, and typically will have only IPv4 DNS (DNS/IPv4), or at least will be seen as that from the CE perspective. At the operator side, the DNS, as seen from the CE, is only IPv6 (DNS/IPv6) and has also a DNS64 function. In the customer LANs side, there is actually one network, which of course could be split in different segments. The most common setup will be those segments being dual-stack, using global IPv6 addresses and [RFC1918] for IPv4, as usual in any regular residential/SOHO IPv4 network. In the figure, it is represented as tree segments, just to show that the three possible setups are valid (IPv6-only, IPv4-only and dual-stack). Palet Martinez Expires January 12, 2020 [Page 34] Internet-Draft NAT64/464XLAT Deployment July 2019 .-----. +-------+ .-----. .-----. / IPv6- \ | | / \ / \ ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ \ LANs / | SOHO +--( only )--( NAT64 )--( only ) `-----' | | \ flow / `-----' \ flow / .-----. | IPv6 | \ / \ / / IPv4- \ | CE | `--+--' `--+--' ( only )--+ with | | | \ LANs / | CLAT | +---+----+ +---+----+ `-----' | | |DNS/IPv6| |DNS/IPv4| .-----. +---+---+ | with | +--------+ / Dual- \ | | DNS64 | ( Stack )------| +--------+ \ LANs / `-----' Figure 17: CE setup with built-in CLAT with DNS64 In addition to the regular CE setup, which will be typically access- technology dependent, the steps for the CLAT function configuration can be summarized as: 1. Discovery of the PLAT (NAT64) prefix: It may be done using [RFC7050], or in those networks where PCP is supported, by means of [RFC7225], or other alternatives that may be available in the future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]). 2. If the CLAT function allows stateless NAT46 translation, a /64 from the pool typically provided to the CE by means of DHCPv6-PD [RFC8415], need to be set aside for that translation. Otherwise, the CLAT is forced to perform an intermediate stateful NAT44 before the a stateless NAT46, as described in Section 4.8. A more detailed configuration approach is described in [RFC8585]. The operator network needs to ensure that the correct responses are provided for the discovery of the PLAT prefix. It is highly recommended to follow [RIPE-690], in order to ensure that multiple /64s are available, including the one needed for the NAT46 stateless translation. The operator needs to understand other issues, described across this document, in order to take the relevant decisions. For example, if several NAT64 functions are needed in the context of scalability/ high-availability, an NSP should be considered (Section 4.5). More complex scenarios are possible, for example, if a network offers Palet Martinez Expires January 12, 2020 [Page 35] Internet-Draft NAT64/464XLAT Deployment July 2019 multiple NAT64 prefixes, destination-based NAT64 prefixes, etc. If the operator decides not to provide a DNS64 function, then this setup turns into the one in the following Figure. This will be also the setup that "will be seen" from the perspective of the CE, if a foreign DNS is used and consequently is not the operator-provided DNS64 function. .-----. +-------+ .-----. .-----. / IPv6- \ | | / \ / \ ( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \ \ LANs / | SOHO +--( only )--( NAT64 )--( only ) `-----' | | \ flow / `-----' \ flow / .-----. | IPv6 | \ / \ / / IPv4- \ | CE | `--+--' `--+--' ( only )--+ with | | | \ LANs / | CLAT | +---+----+ +---+----+ `-----' | | |DNS/IPv6| |DNS/IPv4| .-----. +---+---+ +--------+ +--------+ / Dual- \ | ( Stack )------| \ LANs / `-----' Figure 18: CE setup with built-in CLAT without DNS64 In this case, the discovery of the PLAT prefix needs to be arranged as indicated in Section 4.1.1. In this case, the CE doesn't have a built-in CLAT function, or the customer can choose to setup the IPv6 operator-managed CE in bridge mode (and optionally use an external router), or for example, there is an access technology that requires some kind of media converter (ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will look as in Figure 19. Obviously, there will be some intermediate configuration steps for the bridge, depending on the specific access technology/protocols, which should not modify the steps already described in the previous cases for the CLAT function configuration. Palet Martinez Expires January 12, 2020 [Page 36] Internet-Draft NAT64/464XLAT Deployment July 2019 +-------+ .-----. .-----. | | / \ / \ | Res./ | / IPv6- \ .-----. / IPv4- \ | SOHO +--( only )--( NAT64 )--( only ) | | \ flow / `-----' \ flow / | IPv6 | \ / \ / | CE | `--+--' `--+--' | Bridge| | | | | +---+----+ +---+----+ | | |DNS/IPv6| |DNS/IPv4| +---+---+ +--------+ +--------+ | .-----. +---+---+ / IPv6- \ | | ( only )--+ IPv6 | \ LANs / | Router| `-----' | | .-----. | with | / IPv4- \ | CLAT | ( only )--+ | \ LANs / | | `-----' | | .-----. +---+---+ / Dual- \ | ( Stack )------| \ LANs / `-----' Figure 19: CE setup with bridged CLAT without DNS64 It should be avoided that several routers (i.e., the operator provided CE and a downstream user provided router) enable simultaneously routing and/or CLAT, in order to avoid multiple NAT44 and NAT46 levels, as well as ensuring the correct operation of multiple IPv6 subnets. In those cases, it is suggested the use of HNCP ([RFC8375]). Note that the procedure described here for the CE setup, can be simplified if the CE follows [RFC8585]. 11. ANNEX B: CLAT Implementation In addition to the regular set of features for a CE, a CLAT CE implementation requires support of: o [RFC7915] for the NAT46 function. o [RFC7050] for the PLAT prefix discovery. Palet Martinez Expires January 12, 2020 [Page 37] Internet-Draft NAT64/464XLAT Deployment July 2019 o [RFC7225] for the PLAT prefix discovery if PCP is supported. o [I-D.ietf-6man-ra-pref64] for the PLAT prefix discovery by means of Router Advertising. o [I-D.li-intarea-nat64-prefix-dhcp-option] for the PLAT prefix discovery by means of DHCP. o If stateless NAT46 is supported, a mechanism to ensure that multiple /64 are available, such as DHCPv6-PD [RFC8415]. There are several OpenSource implementations of CLAT, such as: o Android: https://github.com/ddrown/android_external_android-clat. o Jool: https://www.jool.mx. o Linux: https://github.com/toreanderson/clatd. o OpenWRT: https://github.com/openwrt- routing/packages/blob/master/nat46/files/464xlat.sh. o VPP: https://git.fd.io/vpp/tree/src/plugins/nat. 12. ANNEX C: Benchmarking [RFC8219] has defined a benchmarking methodology for IPv6 transition technologies. NAT64 and 464XLAT are addressed among the single and double translation technologies, respectively. DNS64 is addressed in Section 9, and the methodology is more elaborated in [DNS64-BM-Meth]. Several documents provide references to benchmarking results, for example in the case of DNS64, [DNS64-Benchm]. 13. ANNEX D: Changes from -00 to -01/-02 Section to be removed after WGLC. Significant updates are: 1. Text changes across all the document. 14. ANNEX E: Changes from -02 to -03 Section to be removed after WGLC. Significant updates are: 1. Added references to new cited documents. 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only LANs w/o DNS64. Palet Martinez Expires January 12, 2020 [Page 38] Internet-Draft NAT64/464XLAT Deployment July 2019 3. Overall review and editorial changes. 15. ANNEX F: Changes from -03 to -04 Section to be removed after WGLC. Significant updates are: 1. Added text related to EAM considerations. 16. ANNEX G: Changes from -04 to -05 Section to be removed after WGLC. Significant updates are: 1. Added cross references to EAM section. 2. Reworded "foreing DNS section". 3. Overall editorial review of text, pictures and nits correction. 17. ANNEX H: Changes from -05 to -06 Section to be removed after WGLC. Significant updates are: 1. Corrected EAMT to EAM. 2. Typos and nits. 3. New considerations regarding incoming connections. 18. ANNEX H: Changes from -06 to -07 Section to be removed after WGLC. Significant updates are: 1. Inputs/clarifications from IESG review. 19. References 19.1. Normative References [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, . Palet Martinez Expires January 12, 2020 [Page 39] Internet-Draft NAT64/464XLAT Deployment July 2019 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, . [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, DOI 10.17487/RFC5766, April 2010, . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, . [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, . [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, . [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . Palet Martinez Expires January 12, 2020 [Page 40] Internet-Draft NAT64/464XLAT Deployment July 2019 [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, . [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, . [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014, . [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, . [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . Palet Martinez Expires January 12, 2020 [Page 41] Internet-Draft NAT64/464XLAT Deployment July 2019 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . 19.2. Informative References [About-DNS64] Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016, . [ARCEP] ARCEP, "Service client des operateurs : les mesures de qualite de service", 2018, . [DNS64-Benchm] Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications , vol. 127, no. 1, pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September 2018. [DNS64-BM-Meth] Lencse, G., Georgescu, M., and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", Computer Communications , vol. 109, no. 1, pp. 162-175, DOI 10.1016/j.comcom.2017.06.004, September 2017. [FCC] FCC, "Measuring Broadband America Mobile 2013-2018 Coarsened Data", 2018, . [I-D.bp-v6ops-ipv6-ready-dns-dnssec] Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00 (work in progress), October 2018. Palet Martinez Expires January 12, 2020 [Page 42] Internet-Draft NAT64/464XLAT Deployment July 2019 [I-D.cheshire-sudn-ipv4only-dot-arpa] Cheshire, S. and D. Schinazi, "Special Use Domain Name 'ipv4only.arpa'", draft-cheshire-sudn-ipv4only-dot-arpa-14 (work in progress), November 2018. [I-D.huitema-quic-dnsoquic] Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Iyengar, "Specification of DNS over Dedicated QUIC Connections", draft-huitema-quic-dnsoquic-06 (work in progress), March 2019. [I-D.ietf-6man-ra-pref64] Colitti, L. and J. Linkova, "Discovering PREF64 in Router Advertisements", draft-ietf-6man-ra-pref64-01 (work in progress), June 2019. [I-D.ietf-tram-stunbis] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21 (work in progress), March 2019. [I-D.ietf-tram-turnbis] K, R., Johnston, A., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-tram-turnbis-27 (work in progress), June 2019. [I-D.li-intarea-nat64-prefix-dhcp-option] Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, "DHCPv6 Options for Discovery NAT64 Prefixes", draft-li- intarea-nat64-prefix-dhcp-option-02 (work in progress), April 2019. [I-D.lmhp-v6ops-transition-comparison] Lencse, G., Palet, J., Howard, L., Patterson, R., and I. Farrer, "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", draft-lmhp-v6ops-transition-comparison-03 (work in progress), July 2019. [I-D.palet-v6ops-464xlat-opt-cdn-caches] Palet, J. and A. D'Egidio, "464XLAT Optimization", draft- palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress), June 2019. Palet Martinez Expires January 12, 2020 [Page 43] Internet-Draft NAT64/464XLAT Deployment July 2019 [I-D.vixie-dns-rpz] Vixie, P. and V. Schryver, "DNS Response Policy Zones (RPZ)", draft-vixie-dns-rpz-04 (work in progress), December 2016. [ISOC] ISOC, "State of IPv6 Deployment 2018", 2018, . [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, "Analysis of Stateful 64 Translation", RFC 6889, DOI 10.17487/RFC6889, April 2013, . [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, . [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, DOI 10.17487/RFC7051, November 2013, . [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Deployment Options and Experience", RFC 7269, DOI 10.17487/RFC7269, June 2014, . [RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments", RFC 7755, DOI 10.17487/RFC7755, February 2016, . [RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode", RFC 7756, DOI 10.17487/RFC7756, February 2016, . [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, DOI 10.17487/RFC7849, May 2016, . Palet Martinez Expires January 12, 2020 [Page 44] Internet-Draft NAT64/464XLAT Deployment July 2019 [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, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, . [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking Methodology for IPv6 Transition Technologies", RFC 8219, DOI 10.17487/RFC8219, August 2017, . [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, "Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 2019, . [RIPE-690] RIPE, "Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non- persistent, and what size to choose", October 2017, . [Threat-DNS64] Lencse, G. and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security , vol. 77, no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018. Author's Address Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid 28420 Spain Email: jordi.palet@theipv6company.com URI: http://www.theipv6company.com/ Palet Martinez Expires January 12, 2020 [Page 45] ./draft-ise-iana-policy-03.txt0000644000764400076440000002603713542131023015413 0ustar iustyiusty Network Working Group A. Farrel Internet-Draft Independent Submissions Editor Intended status: Informational September 23, 2019 Expires: March 26, 2020 How Requests for IANA Action Will be Handled on the Independent Stream draft-ise-iana-policy-03 Abstract The Internet Assigned Numbers Authority (IANA) maintains registries to track codepoints used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. The Independent Submissions Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE). This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submissions Stream that request actions from the IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. 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 https://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, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Farrel Expires March 26, 2020 [Page 1] Internet-Draft IANA and the Independent Stream September 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Allocations from Existing Registries . . . . . . . . . . . . 3 3. Changing Policies of Existing Registries . . . . . . . . . . 3 4. Creating New IANA Registries . . . . . . . . . . . . . . . . 3 5. Assigning Designated Experts . . . . . . . . . . . . . . . . 4 6. Transfer of Control . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Internet Assigned Numbers Authority (IANA) maintains registries to track codepoints used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. A full list of registries and code points can be found at . Requests may be made to IANA for actions to create registries or to allocate code points from existing registries. Procedures for these operations are described in [RFC8126]. Many requests for IANA action are included in documents that are progressed for publication as RFCs. RFCs may be sourced from within the IETF (on the IETF Stream), but may also be sourced from other streams including the Independent Submissions Stream (the Independent Stream) as described in [RFC4846]. The Independent Stream is under the care of the Independent Submissions Editor (ISE). This document complements [RFC4846] by providing a description of how the ISE currently handles documents in the Independent Stream that request actions from the IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. Farrel Expires March 26, 2020 [Page 2] Internet-Draft IANA and the Independent Stream September 2019 In the event that a case arises that is not precisely covered by this document, the ISE may discuss a solution with the interested parties, including IANA, the IESG, the stream managers for other streams, and the authors of an Independent Submission that requests IANA action. 2. Allocations from Existing Registries Each IANA registry is governed by an allocation policy: the rules that IANA applies to determine which code points can be allocated and under what circumstances. These policies are described in [RFC8126]. Documents proceeding from the Independent Stream will always follow the assignment policies defined for the registries from which they request allocations. Similarly, all code point assignments are subject to the oversight of any Designated Expert (DE) appointed for the registry. It should be noted that documents on the Independent Stream can never result in Standards Track RFCs and Independent Stream documents are never subject to IETF review. Thus a registry whose policy is "IETF Review" or "Standards Action" [RFC8126] is not available to Independent Stream documents. 3. Changing Policies of Existing Registries From time to time a decision is made to change the allocation policy for a registry. Such changes are normally only made using allocation policy of the registry itself, and usually require documentation from the same stream as created the registry. Independent Stream RFCs will not seek to change the allocation policies of any registries except those created by documents from the Independent Stream. The list of such registries is, itself, very limited (see Section 4). 4. Creating New IANA Registries Sometimes new registries are needed to track a new set of codepoints for a new protocol or an extension to an existing protocol. In general, documents on the Independent Stream cannot request the creation of a new registry. The only exception to this rule is the creation of a sub-registry that is specifically tied to a code point allocated for the same document from an existing registry where the allocation policy for that document is Specification Required, Expert Review, RFC Required, or First Come First Served. Furthermore, where there is an appointed DE for the parent registry, that DE must approve the creation of the Farrel Expires March 26, 2020 [Page 3] Internet-Draft IANA and the Independent Stream September 2019 sub-registry. Additionally, the allocation policy for the new sub- registry may only be First Come First Served, RFC Required, Experimental, or Private Use. In particular, no sub-registry may be created that would require IETF action to achieve a future codepoint allocation. See Section 5 for an explanation of why the application of Specification Required and Expert Review are not acceptable policies for any sub-registry created from a document in the Independent Stream. 5. Assigning Designated Experts Some IANA allocation policies (specifically, Specification Required and Expert Review) utilize the review of a DE. The procedures applicable to the appointment and actions of a DE are described in section 5 of [RFC8126]. When a DE is appointed, the position must be maintained and supported by whoever designated the DE in the first place. That is, someone must appoint replacement DEs if necessary, and someone must provide a backstop in case the appointed DEs are unresponsive. The ISE will not appoint a DE. That means that no sub-registry created for Independent Stream documents will require the review of a DE. That means that no new sub-registry can be created that uses the Specification Required or Expert Review policies. 6. Transfer of Control Very rarely, it may be desirable to transfer "ownership" of an IANA registry from the Independent Stream to the IETF Stream. This might happen, for example, if a protocol was originally documented in the Independent Stream, but has been adopted for work and standardization in the IETF. Such a transfer may require an IETF Stream RFC to act as the base reference for the registry, and will require discussion and agreement with the ISE. Ownership of a registry will not be transferred from the IETF Stream to the Independent Stream. 7. IANA Considerations This document is all about IANA actions, but makes no request for IANA action. Farrel Expires March 26, 2020 [Page 4] Internet-Draft IANA and the Independent Stream September 2019 8. Security Considerations There are no direct security considerations arising from this document. It may be noted that some IANA registries relate to security protocols, and the stability and proper management of those registries contributes to the stability of the protocols themselves. That is a benefit for the security of the Internet and the users of the Internet. 9. Acknowledgements Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz, Michael Richardson, Colin Perkins, Brian Carpenter, Stephen Farrell, Barry Leiba, and Benjamin Kaduk for suggestions and advice. 10. Normative References [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Author's Address Adrian Farrel Independent Submissions Editor Email: rfc-ise@rfc-editor.org Farrel Expires March 26, 2020 [Page 5] ./draft-jenkins-cnsa-cmc-profile-05.txt0000644000764400076440000013041413473567671017237 0ustar iustyiusty Network Working Group M. Jenkins Internet-Draft L. Zieglar Intended status: Informational NSA Expires: November 30, 2019 May 29, 2019 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS draft-jenkins-cnsa-cmc-profile-05 Abstract This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available here for use by developers and operators of these and any other system deployments. 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 https://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 30, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Jenkins & Zieglar Expires November 30, 2019 [Page 1] Internet-Draft CNSA Suite CMC Profile May 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. The Commercial National Security Algorithm Suite . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements and Assumptions . . . . . . . . . . . . . . . . 4 5. Client Requirements: Generating PKI Requests . . . . . . . . 5 5.1. Tagged Certification Request . . . . . . . . . . . . . . 7 5.2. Certificate Request Message . . . . . . . . . . . . . . . 8 6. RA Requirements . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. RA Processing of Requests . . . . . . . . . . . . . . . . 9 6.2. RA-Generated PKI Requests . . . . . . . . . . . . . . . . 9 6.3. RA-Generated PKI Responses . . . . . . . . . . . . . . . 10 7. CA Requirements . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. CA Processing of PKI Requests . . . . . . . . . . . . . . 11 7.2. CA-Generated PKI Responses . . . . . . . . . . . . . . . 11 8. Client Requirements: Processing PKI Responses . . . . . . . . 13 9. Shared-Secrets . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Scenarios . . . . . . . . . . . . . . . . . . . . . 17 A.1. Initial Enrollment . . . . . . . . . . . . . . . . . . . 17 A.2. Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction This document specifies a profile of the Certificate Management over CMS (CMC) protocol to comply with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite [CNSA]. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems [SP80059]. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. Jenkins & Zieglar Expires November 30, 2019 [Page 2] Internet-Draft CNSA Suite CMC Profile May 2019 This document does not define any new cryptographic algorithm suite; instead, it defines a CNSA compliant profile of CMC. CMC is defined in [RFC5272], [RFC5273], and [RFC5274], and is updated by [RFC6402]. This document profiles CMC to manage X.509 public key certificates in compliance with the CNSA Suite Certificate and Certificate Revocation List (CRL) Profile [ID.cnsa-cert-profile]. This document specifically focuses on defining CMC interactions for both initial enrollment and rekey of CNSA Suite public key certificates between a client and a Certification Authority (CA). One or more Registration Authorities (RAs) may act as intermediaries between the client and the CA. This profile may be further tailored by specific communities to meet their needs. Specific communities will also define Certificate Policies that implementations need to comply with. 2. The Commercial National Security Algorithm Suite The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems. To this end, it publishes guidance both to assist with the US Government transition to new algorithms, and to provide vendors - and the Internet community in general - with information concerning their proper use and configuration within the scope of US Government National Security Systems. Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant quantum computer. NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near- term flexibility in meeting their cybersecurity interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum- resistant cryptography in the near future. NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data- at-rest for US Government National Security Systems. 3. 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 Jenkins & Zieglar Expires November 30, 2019 [Page 3] Internet-Draft CNSA Suite CMC Profile May 2019 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terminology in [RFC5272] Section 2.1 applies to this profile. The term "Certificate Request" is used to refer to a single PKCS #10 or CRMF structure. All PKI Requests are Full PKI Requests, and all PKI Responses are Full PKI Responses; the respective set of terms should be interpreted synonymously in this document. 4. Requirements and Assumptions Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) key pairs are on the curve P-384. FIPS 186-4 [FIPS186], Appendix B.4, provides useful guidance for elliptic curve key pair generation that SHOULD be followed by systems that conform to this document. RSA key pairs (public, private) are identified by the modulus size expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 bits, respectively. RSA signature key pairs used in CNSA Suite compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 2^16. [FIPS186] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standard 186-4, July 2013, . [ID.cnsa-cert-profile] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", January 2018, . Work in progress. [ID.cnsa-smime-profile] Jenkins, M., "Using CNSA Suite Algorithms in Secure/ Multipurpose Internet Mail Extensions(S/MIME)", February 2018, . Work in progress. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, . Jenkins & Zieglar Expires November 30, 2019 [Page 15] Internet-Draft CNSA Suite CMC Profile May 2019 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, DOI 10.17487/RFC4056, June 2005, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [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, . [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, . [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008, . [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, DOI 10.17487/RFC5274, June 2008, . [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, . [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints Extension", RFC 6010, DOI 10.17487/RFC6010, September 2010, . [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, . Jenkins & Zieglar Expires November 30, 2019 [Page 16] Internet-Draft CNSA Suite CMC Profile May 2019 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [SP80057] National Institute of Standards and Technology, "Recommendation for Key Management, Part 1: General", Special Publication 800-57 , January 2016, . [SP80059] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", Special Publication 800 59, August 2003, . [SP80090A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", Special Publication 800-90A Revision 1, June 2015, . Appendix A. Scenarios This section illustrates several potential certificate enrollment and rekey scenarios supported by this profile. This section does not intend to place any limits or restrictions on the use of CMC. A.1. Initial Enrollment This section describes three scenarios for authenticating initial enrollment requests: 1. Previously certified signature key-pair (e.g., Manufacturer Installed Certificate); 2. Shared-secret distributed securely out-of-band; 3. RA authentication. Jenkins & Zieglar Expires November 30, 2019 [Page 17] Internet-Draft CNSA Suite CMC Profile May 2019 A.1.1. Previously Certified Signature Key-pair In this scenario, the end-entity has a private signing key, and a corresponding public key certificate obtained from a cryptographic module manufacturer recognized by the CA. The end-entity signs a Full PKI Request with the private key that corresponds to the subject public key of the previously installed signature certificate. The CA will verify the authorization of the previously installed certificate and issue an appropriate new certificate to the end-entity. A.1.2. Shared-Secret Distributed Securely Out-of-Band In this scenario, the CA distributes a shared-secret out-of-band to the end-entity that the end-entity uses to authenticate its certification request. The end-entity signs the Full PKI Request with the private key for which the certification is being requested. The end-entity includes the Identity Proof Version 2 control to authenticate the request using the shared-secret. The CA uses either the Identification control or the Subject in the end-entity's enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request message to identify the request. The end-entity performs either the POP Link Witness Version 2 mechanism as described in [RFC5272], Section 6.3.1.1, or the Shared-Subject/Subject Distinguished Name (DN) linking mechanism as described in [RFC5272], Section 6.3.2. The Subject in the enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request does not necessarily match the issued certificate, as it may be used just to help identify the request (and corresponding shared-secret) to the CA. A.1.3. RA Authentication In this scenario, the end-entity does not automatically authenticate its enrollment request to the CA, either because the end-entity has nothing to authenticate the request with or because organizational policy requires an RA's involvement. The end-entity creates a Full PKI Request and sends it to an RA. The RA verifies the authenticity of the request, then, if approved, encapsulates and signs the request as described in Section 5.2, forwarding the new request on to the CA. The Subject in the PKCS #10 [RFC2986] or CRMF [RFC4211] certification request is not required to match the issued certificate, it may be used just to help identify the request to the RA and/or CA. A.2. Rekey There are two scenarios to support the rekey of certificates that are already enrolled. One addresses the rekey of signature certificates and the other addresses the rekey of key establishment certificates. Typically, organizational policy will require certificates to be Jenkins & Zieglar Expires November 30, 2019 [Page 18] Internet-Draft CNSA Suite CMC Profile May 2019 currently valid to be rekeyed, and it may require initial enrollment to be repeated when rekey is not possible. However, some organizational policies might allow a grace period during which an expired certificate could be used to rekey. A.2.1. Rekey of Signature Certificates When a signature certificate is rekeyed, the PKCS #10 [RFC2986] or CRMF [RFC4211] certification request message enclosed in the Full PKI Request will include the same Subject as the current signature certificate. The Full PKI Request will be signed by the current private key corresponding to the current signature certificate. A.2.2. Rekey of Key Establishment Certificates When a key establishment certificate is rekeyed, the Full PKI Request will generally be signed by the current private key corresponding to the current signature certificate. If there is no current signature certificate, one of the initial enrollment options in Appendix A.1 may be used. Authors' Addresses Michael Jenkins National Security Agency Email: mjjenki@nsa.gov Lydia Zieglar National Security Agency Email: llziegl@tycho.ncsc.mil Jenkins & Zieglar Expires November 30, 2019 [Page 19] ./draft-kanugovi-intarea-mams-framework-04.txt0000644000764400076440000102255713474271247020650 0ustar iustyiusty INTAREA S. Kanugovi Internet-Draft Nokia Intended status: Informational F. Baboescu Expires: December 2, 2019 Broadcom J. Zhu Intel J. Mueller AT&T S. Seo Korea Telecom May 31, 2019 Multiple Access Management Services draft-kanugovi-intarea-mams-framework-04 Abstract In multiconnectivity scenarios, the end-user devices can simultaneously connect to multiple networks based on different access technologies and network architectures like WiFi, LTE, DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions. This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP, but is not an Internet Standard and does not represent the consensus opinion of the IETF. This document describes the requirements, solution principles, and an architectural framework that aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol multi-access management to: 1) flexibly select the best combination of access and core network paths for uplink and downlink; as well as 2) determine the user plane treatment and traffic distribution over the selected links ensuring network efficiency and application performance. 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 https://datatracker.ietf.org/drafts/current/. Kanugovi, et al. Expires December 2, 2019 [Page 1] Internet-Draft MAMS May 2019 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, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Access Technology Agnostic Interworking . . . . . . . . . 9 4.2. Support Common Transport Deployments . . . . . . . . . . 9 4.3. Independent Access Path Selection for Uplink and Downlink 9 4.4. Core Selection Independent of Uplink and Downlink Access 9 4.5. Adaptive Access Network Path Selection . . . . . . . . . 9 4.6. Multipath Support and Aggregation of Access Link Capacities . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Scalable Mechanism based on User Plane Interworking . . . 10 4.8. Separate Control and Data Plane functions . . . . . . . . 10 4.9. Lossless Path (Connection) Switching . . . . . . . . . . 10 4.10. Concatenation and Fragmentation for adaptation to MTU Differences . . . . . . . . . . . . . . . . . . . . . . . 11 4.11. Configuring Network Middleboxes based on Negotiated Protocols . . . . . . . . . . . . . . . . . . . . . . . . 11 4.12. Policy based Optimal Path Selection . . . . . . . . . . . 11 4.13. Access Technology Agnostic Control Signaling . . . . . . 11 4.14. Service Discovery and Reachability . . . . . . . . . . . 11 5. Solution Principles . . . . . . . . . . . . . . . . . . . . . 12 6. MAMS Reference Architecture . . . . . . . . . . . . . . . . . 12 7. MAMS Protocol Architecture . . . . . . . . . . . . . . . . . 15 Kanugovi, et al. Expires December 2, 2019 [Page 2] Internet-Draft MAMS May 2019 7.1. MAMS Control-Plane Protocol . . . . . . . . . . . . . . . 15 7.2. MAMS User Plane Protocol . . . . . . . . . . . . . . . . 16 8. MAMS Control Plane Procedures . . . . . . . . . . . . . . . . 18 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Common fields in MAMS Control Messages . . . . . . . . . 20 8.3. Common Procedures for MAMS Control Messages . . . . . . . 20 8.3.1. Message Timeout . . . . . . . . . . . . . . . . . . . 20 8.3.2. Keep Alive Procedure . . . . . . . . . . . . . . . . 20 8.4. Discovery & Capability Exchange . . . . . . . . . . . . . 21 8.5. User Plane Configuration . . . . . . . . . . . . . . . . 25 8.6. MAMS Path Quality Estimation . . . . . . . . . . . . . . 29 8.6.1. MX Control PDU definition . . . . . . . . . . . . . . 31 8.6.2. Keep-Alive Message . . . . . . . . . . . . . . . . . 32 8.6.3. Probe REQ/ACK Message . . . . . . . . . . . . . . . . 32 8.7. MAMS Traffic Steering . . . . . . . . . . . . . . . . . . 33 8.8. MAMS Application MADP Association . . . . . . . . . . . . 34 8.9. MAMS Network ID Indication . . . . . . . . . . . . . . . 35 8.10. MAMS Client Measurement Configuration and Reporting . . . 36 8.11. MAMS Session Termination Procedure . . . . . . . . . . . 38 8.12. MAMS Network Analytics Request Procedure . . . . . . . . 39 9. Generic MAMS Signaling Flow . . . . . . . . . . . . . . . . . 41 10. Relation to IETF Technologies . . . . . . . . . . . . . . . . 43 11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Applying MAMS Control Procedures for Network Assisted Traffic Steering when there is No Convergence Layer . . . . . . . . . 49 13. Co-existence of MX Adaptation and MX Convergence Layers . . . 51 14. Security Considerations . . . . . . . . . . . . . . . . . . . 51 14.1. MAMS Control Plane Security . . . . . . . . . . . . . . 51 14.2. MAMS User Plane Security . . . . . . . . . . . . . . . . 52 15. Implementation Considerations . . . . . . . . . . . . . . . . 52 16. Applicability to Multi Access Edge Computing . . . . . . . . 52 17. Related work in other Industry and Standards Forums . . . . . 53 18. Contributing Authors . . . . . . . . . . . . . . . . . . . . 53 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 21.1. Normative References . . . . . . . . . . . . . . . . . . 54 21.2. Informative References . . . . . . . . . . . . . . . . . 54 Appendix A. MAMS Control Plane Optimization over Secure Connections . . . . . . . . . . . . . . . . . . . . 56 Appendix B. MAMS Application Interface . . . . . . . . . . . . . 57 B.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 57 B.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 57 B.3. Error Indication . . . . . . . . . . . . . . . . . . . . 57 B.4. CCM APIs . . . . . . . . . . . . . . . . . . . . . . . . 57 B.4.1. Get Capabilities . . . . . . . . . . . . . . . . . . 57 B.4.2. Post App Requirements . . . . . . . . . . . . . . . . 58 Kanugovi, et al. Expires December 2, 2019 [Page 3] Internet-Draft MAMS May 2019 B.4.3. Get Predictive Link Parameters . . . . . . . . . . . 59 Appendix C. JSON Specification for MAMS Control Plane . . . . . 60 C.1. Protocol Specification: General Processing . . . . . . . 60 C.1.1. Notation . . . . . . . . . . . . . . . . . . . . . . 60 C.1.2. Discovery Procedure . . . . . . . . . . . . . . . . . 61 C.1.3. System Information Procedure . . . . . . . . . . . . 61 C.1.4. Capability Exchange Procedure . . . . . . . . . . . . 62 C.1.5. User Plane Configuration Procedure . . . . . . . . . 63 C.1.6. Reconfiguration Procedure . . . . . . . . . . . . . . 65 C.1.7. Path Estimation Procedure . . . . . . . . . . . . . . 66 C.1.8. Traffic Steering Procedure . . . . . . . . . . . . . 67 C.1.9. MAMS Application MADP Association . . . . . . . . . . 68 C.1.10. SSID Indication . . . . . . . . . . . . . . . . . . . 69 C.1.11. Measurements . . . . . . . . . . . . . . . . . . . . 70 C.1.12. Keep Alive . . . . . . . . . . . . . . . . . . . . . 71 C.1.13. Session Termination Procedure . . . . . . . . . . . . 72 C.1.14. Network Analytics . . . . . . . . . . . . . . . . . . 73 C.2. Protocol Specification: Data Types . . . . . . . . . . . 74 C.2.1. MXBase . . . . . . . . . . . . . . . . . . . . . . . 74 C.2.2. Unique Session Id . . . . . . . . . . . . . . . . . . 75 C.2.3. NCM Connections . . . . . . . . . . . . . . . . . . . 76 C.2.4. Connection Information . . . . . . . . . . . . . . . 76 C.2.5. Features Activation Status . . . . . . . . . . . . . 77 C.2.6. Anchor Connections . . . . . . . . . . . . . . . . . 77 C.2.7. Delivery Connections . . . . . . . . . . . . . . . . 78 C.2.8. Method Support . . . . . . . . . . . . . . . . . . . 78 C.2.9. Convergence Methods . . . . . . . . . . . . . . . . . 78 C.2.10. Adaptation Methods . . . . . . . . . . . . . . . . . 79 C.2.11. Setup of Anchor Connections . . . . . . . . . . . . . 79 C.2.12. Init Probe Results . . . . . . . . . . . . . . . . . 81 C.2.13. Active Probe Results . . . . . . . . . . . . . . . . 82 C.2.14. Downlink Delivery . . . . . . . . . . . . . . . . . . 82 C.2.15. Uplink Delivery . . . . . . . . . . . . . . . . . . . 82 C.2.16. Traffic Flow Template . . . . . . . . . . . . . . . . 83 C.2.17. Measurement Report Configuration . . . . . . . . . . 83 C.2.18. Measurement Report . . . . . . . . . . . . . . . . . 84 C.3. Schemas in JSON . . . . . . . . . . . . . . . . . . . . . 85 C.3.1. MX Base Schema . . . . . . . . . . . . . . . . . . . 85 C.3.2. MX Definitions . . . . . . . . . . . . . . . . . . . 86 C.3.3. MX Discover . . . . . . . . . . . . . . . . . . . . . 93 C.3.4. MX System Update . . . . . . . . . . . . . . . . . . 93 C.3.5. MX Capability Request . . . . . . . . . . . . . . . . 94 C.3.6. MX Capability Response . . . . . . . . . . . . . . . 95 C.3.7. MX Capability Ack . . . . . . . . . . . . . . . . . . 96 C.3.8. MX Reconfiguration Request . . . . . . . . . . . . . 97 C.3.9. MX Reconfiguration Response . . . . . . . . . . . . . 98 C.3.10. MX UP Setup Configuration . . . . . . . . . . . . . . 99 C.3.11. MX UP Setup Confirmation . . . . . . . . . . . . . . 100 Kanugovi, et al. Expires December 2, 2019 [Page 4] Internet-Draft MAMS May 2019 C.3.12. MX Traffic Steering Request . . . . . . . . . . . . . 101 C.3.13. MX Traffic Steering Response . . . . . . . . . . . . 101 C.3.14. MX Application MADP Association Request . . . . . . . 102 C.3.15. MX Application MADP Association Response . . . . . . 103 C.3.16. MX Path Estimation Request . . . . . . . . . . . . . 103 C.3.17. MX Path Estimation Report . . . . . . . . . . . . . . 104 C.3.18. MX SSID Indication . . . . . . . . . . . . . . . . . 105 C.3.19. MX Measurements Configuration . . . . . . . . . . . . 106 C.3.20. MX Measurements Report . . . . . . . . . . . . . . . 107 C.3.21. MX Keep Alive Request . . . . . . . . . . . . . . . . 109 C.3.22. MX Keep Alive Response . . . . . . . . . . . . . . . 109 C.3.23. MX Session Termination Request . . . . . . . . . . . 109 C.3.24. MX Session Termination Response . . . . . . . . . . . 110 C.3.25. MX Network Analytics Request . . . . . . . . . . . . 110 C.3.26. MX Network Analytics Response . . . . . . . . . . . . 111 C.4. Examples in JSON . . . . . . . . . . . . . . . . . . . . 112 C.4.1. MX Discover . . . . . . . . . . . . . . . . . . . . . 112 C.4.2. MX System Update . . . . . . . . . . . . . . . . . . 112 C.4.3. MX Capability Request . . . . . . . . . . . . . . . . 113 C.4.4. MX Capability Response . . . . . . . . . . . . . . . 115 C.4.5. MX Capability Ack . . . . . . . . . . . . . . . . . . 116 C.4.6. MX Reconfiguration Request . . . . . . . . . . . . . 116 C.4.7. MX Reconfiguration Response . . . . . . . . . . . . . 117 C.4.8. MX UP Setup Configuration Request . . . . . . . . . . 117 C.4.9. MX UP Setup Confirmation . . . . . . . . . . . . . . 119 C.4.10. MX Traffic Steering Request . . . . . . . . . . . . . 119 C.4.11. MX Traffic Steering Response . . . . . . . . . . . . 121 C.4.12. MX Application MADP Association Request . . . . . . . 121 C.4.13. MX Application MADP Association Response . . . . . . 122 C.4.14. MX Path Estimation Request . . . . . . . . . . . . . 122 C.4.15. MX Path Estimation Results . . . . . . . . . . . . . 123 C.4.16. MX SSID Indication . . . . . . . . . . . . . . . . . 123 C.4.17. MX Measurements Configuration . . . . . . . . . . . . 124 C.4.18. MX Measurements Report . . . . . . . . . . . . . . . 125 C.4.19. MX Keep Alive Request . . . . . . . . . . . . . . . . 127 C.4.20. MX Keep Alive Response . . . . . . . . . . . . . . . 127 C.4.21. MX Session Termination Request . . . . . . . . . . . 127 C.4.22. MX Session Termination Response . . . . . . . . . . . 127 C.4.23. MX Network Analytics Request . . . . . . . . . . . . 128 C.4.24. MX Network Analytics Response . . . . . . . . . . . . 128 Appendix D. Definition of APIs provided by CCM to the Applications at the Client . . . . . . . . . . . . . 129 Appendix E. Implementation Example using Python for MAMS Client and Server . . . . . . . . . . . . . . . . . . . . . 137 E.1. Client Side Implementation . . . . . . . . . . . . . . . 137 E.2. Server Side Implementation . . . . . . . . . . . . . . . 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 Kanugovi, et al. Expires December 2, 2019 [Page 5] Internet-Draft MAMS May 2019 1. Introduction Multi Access Management Services (MAMS) is a programmable framework that provides mechanisms for flexible selection of network paths in a multi-access communication environment, based on application needs. It leverages network intelligence and policies to dynamically adapt traffic distribution across selected paths and user plane treatment to changing network/link conditions. The network path selection and configuration messages are carried as user plane data between the functional elements in the network and the end-user device, and thus without any impact to the control plane signaling schemes of the underlying access network(s). For example, in a multi-access network with LTE and WiFi technologies, existing LTE and existing WiFi signaling procedures will be used to setup the LTE and WiFi connections, respectively, and MAMS specific control plane messages are carried as LTE or WiFi user plane data. The MAMS framework defined in this document provides the capabilities of smart selection and flexible combination of access paths and core network paths, as well as the user plane treatment when the traffic is distributed across the selected paths. Thus, it is a broad programmable framework providing functions beyond simple sharing of network policies such as provided by Access Network Discovery and Selection Function (ANDSF) [ANDSF] that offers policies and rules for assisting 3GPP devices to discover and select available access networks. Further, it allows the choice and configuration of user plane treatment for the traffic over the multiple paths, depending on the needs of the application. MAMS mechanisms are not dependent on any specific access network type or user plane protocols like TCP, UDP, GRE, MPTCP etc. It co-exists and complements the existing protocols by providing a way to negotiate and configure these protocols based on client and network capabilities per access basis to match their use for a given multi- access scenario. Further, it allows load balancing of the traffic flows across the selected multiple accesses and exchange of network state information to be used for network intelligence to optimize the performance of such protocols. The document presents the requirements, solution principles, functional architecture, and protocols for realizing the MAMS framework. An important goal for MAMS is to ensure that it either requires minimum dependency or (better) no dependency on the actual access technologies of the participating links, beyond the fact that MAMS functional elements form an IP-overlay across the multiple paths. This allows the scheme to be future proof by allowing independent technology evolution of the existing access and core networks as well as, seamless integration of new access technologies. Kanugovi, et al. Expires December 2, 2019 [Page 6] Internet-Draft MAMS May 2019 The solution described in this document has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP, but is not an Internet Standard and does not represent the consensus opinion of the IETF. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. "Client": The end-user device supporting connections with multiple access nodes, possibly over different access technologies. "Multiconnectivity Client": A client with multiple network connections. "Access network": The segment in the network that delivers user data packets to the client via an access link like WiFi airlink, LTE airlink, or DSL. "Core": The functional element that anchors the client IP address used for communication with applications via the network. "Network Connection manager"(NCM): A functional entity in the network that handles MAMS control messages from the client and configures distribution of data packets over the multiple available access and core network paths, and user plane treatment of the traffic flows. "Client Connection Manager" (CCM): A functional entity in the client that exchanges MAMS Signaling with the Network Connection Manager and configures the multiple network paths at the client for transport of user data. "Network Multi Access Data Proxy" (N-MADP): This functional entity in the network handles the user data traffic forwarding across multiple network paths. N-MADP is responsible for MAMS related user-plane functionalities in the network. "Client Multi Access Data Proxy" (C-MADP): This functional entity in the client handles the user data traffic forwarding across multiple network paths. C-MADP is responsible for MAMS related user-plane functionalities in the client. Kanugovi, et al. Expires December 2, 2019 [Page 7] Internet-Draft MAMS May 2019 "Anchor Connection": Refers to the network path from the N-MADP to the user plane gateway (IP anchor ) that has assigned an IP address to the client. "Delivery Connection": Refers to the network path from the N-MADP to the client. 3. Problem Statement Typically, an end-user device has access to multiple communication networks based on different technologies, say LTE, WiFi, DSL, MuLTEfire, for accessing application services. Different technologies exhibit benefits and limitations in different scenarios. For example, WiFi provides high throughput for end users when under good coverage, but the throughput degrades significantly as the user moves closer to the edge of WiFi coverage (typically in the range of few tens of meters) or with large user population (due to contention based WiFi access scheme). In LTE networks, the capacity is often constrained by the limited availability of licensed spectrum. However, the quality of the service is predictable even in multi-user scenarios due to controlled scheduling and licensed spectrum usage. Additionally, the use of a particular access network path is often coupled with the use of its associated core network and the services that are offered by it. For example, in an enterprise that has deployed both WiFi and LTE networks, the enterprise services, like printers, Corporate Audio and Video conferencing, are accessible only via WiFi access connected to the enterprise hosted (WiFi) core, whereas the LTE access can be used to get operator core anchored services including access to public Internet. Thus, application performance in different scenarios becomes dependent on the choice of the access networks (e.g. WiFi, LTE, etc.) and the used network and transport protocols (e.g. VPN, MPTCP, GRE etc.). Therefore, to achieve the best possible application performance in a wide range of scenarios, a framework is needed that allows the selection and flexible combination of access and core network paths and used protocols for uplink and downlink data delivery. For example, to ensure best performance for enterprise applications at all times, in uncongested scenarios, when the user is under good WiFi coverage, it would be beneficial to use WiFi access in both uplink and downlink for connecting to enterprise applications. However, in congested scenarios or when the user is getting close to the edge of its WiFi coverage, the use of WiFi in uplink by multiple users can lead to degraded capacity and increased delays due to contention. In this case, it would be beneficial to at least use the Kanugovi, et al. Expires December 2, 2019 [Page 8] Internet-Draft MAMS May 2019 LTE access for increased uplink coverage while WiFi may still continue to be used for downlink. 4. Requirements The requirements set out in this section are for the definition of behavior of the MAMS mechanism and the related functional elements. 4.1. Access Technology Agnostic Interworking The access nodes may use different technology types like LTE, WiFi, etc. The framework, however, MUST be agnostic to the type of underlying technology used at the access network. 4.2. Support Common Transport Deployments The network path selection and user data distribution MUST work transparently across various transport deployments that include end- to-end IPsec, VPNs, and middleboxes like NATs and proxies. 4.3. Independent Access Path Selection for Uplink and Downlink A Client SHOULD be able to transmit on the uplink and, receive on the downlink, using one or more accesses. The selection of the access paths for uplink and downlink SHOULD happen independent of each other. 4.4. Core Selection Independent of Uplink and Downlink Access A client SHOULD flexibly select the Core, independent of the access paths used to reach the Core, depending on the application needs, local policies and the result of MAMS control plane negotiation. 4.5. Adaptive Access Network Path Selection The framework MUST have the ability to determine the quality of each of the network paths, e.g. access link delay and capacity. The network path quality information needs to be considered in the logic for selection of the combination of network paths to be used for transporting user data. The path selection algorithm can use network path quality information, in addition to other considerations like network policies, for optimizing network usage and enhancing QoE delivered to the user. Kanugovi, et al. Expires December 2, 2019 [Page 9] Internet-Draft MAMS May 2019 4.6. Multipath Support and Aggregation of Access Link Capacities The framework MUST support distribution and aggregation of user data across multiple network paths at the IP layer. The client SHOULD be able to leverage the combined capacity of the multiple network connections by enabling simultaneous transport of user data over multiple network paths. If required, packet re-ordering needs to be done at the receiver. The framework MUST allow flexibility to choose the flow steering and aggregation protocols based on capabilities supported by the client and the network data plane entities. The multi-connection aggregation solution MUST support existing transport and network layer protocols like TCP, UDP, GRE. The framework MUST allow use and configuration of existing aggregation protocols such as Multi-Path TCP(MPTCP) and SCTP. 4.7. Scalable Mechanism based on User Plane Interworking The framework MUST leverage commonly available transport, routing and tunneling capabilities to provide user plane interworking functionality. The addition of functional elements in the user plane path between the client and the network MUST not impact the access technology specific procedures. This makes solution easy to deploy and scale when different networks are added and removed. 4.8. Separate Control and Data Plane functions The client MUST use the control plane protocol to negotiate with the network, the choice of access and core network paths for both uplink and downlink, as well as the user plane protocol treatment. The control plane MUST configure the actual user plane data distribution function per this negotiation. A common control protocol SHOULD allow creation of multiple user plane function instance with potentially different user plane (e.g. tunneling) protocol types. This enables maintaining a clear separation between the control and data plane functions, allowing the framework to be scalable and extensible, e.g. using SDN based architecture and implementations. 4.9. Lossless Path (Connection) Switching When switching data traffic from one path (connection) to another, packets may be lost or delivered out-of-order, which will have negative impacts on the performance of higher layer protocols, e.g. TCP. The framework SHOULD provide necessary mechanisms to ensure in- order delivery at the receiver, e.g. during path switching. The framework MUST not cause any packet loss beyond that of access network mobility functions may cause. Kanugovi, et al. Expires December 2, 2019 [Page 10] Internet-Draft MAMS May 2019 4.10. Concatenation and Fragmentation for adaptation to MTU Differences Different network paths may have different security and middlebox (e.g NAT) configurations, which will lead to use of different tunneling protocols for transport of data between the network user plane function and the client. As a result, different effective payload sizes (e.g. due to variable encapsulation header overheads) per network path are possible. Hence, MAMS framework SHOULD support fragmentation of a single IP packet payload across MTU sized IP packets to avoid IP fragmentation when aggregating packets from different paths. Further, concatenation of multiple IP packets into a single IP packet to improve efficiency in packing the MTU size should also be supported. 4.11. Configuring Network Middleboxes based on Negotiated Protocols The framework SHOULD enable identification of the optimal parameters that may be used for configuring the middle-boxes, like radio link dormancy timers, binding expiry times and supported MTUs, for efficient operation of the user plane protocols, based on parameters negotiated between the client and the network, e.g. Configuring longer binding expiry time in NATs when UDP transport is used in contrast to the scenario where TCP is configured at the transport layer. 4.12. Policy based Optimal Path Selection The framework MUST support consideration of policies at the client, in addition to guidance from the network, for network path selection addressing different application requirements. 4.13. Access Technology Agnostic Control Signaling The control plane signaling MUST NOT be dependent on the underlying access technology procedures, e.g. be carried transparently as user plane. It should support delivery of control plane signaling over the existing Internet protocols, e.g. TCP or UDP. 4.14. Service Discovery and Reachability There can be multiple instances of the control and user plane functional elements of the framework, either collocated or hosted on separate network elements, and reachable via any of the available user plane paths. The client MUST have flexibility to choose the appropriate control plane instance in the network and use the control plane signaling to choose the desired user plane functional element instances. The choice can be based on considerations like, but not Kanugovi, et al. Expires December 2, 2019 [Page 11] Internet-Draft MAMS May 2019 limited to, quality of link through which the network function is reachable, client preferences, pre-configuration etc. 5. Solution Principles This document proposes the Multiple Access Management Services(MAMS) framework for dynamic selection and flexible combination of access and core network paths independently for the uplink and downlink, as well as the user plane treatment for the traffic spread across the selected links. MAMS framework consists of clearly separated control and user plane functions in the network and the client. The control plane protocol allows configuration of the user plane protocols and desired network paths for transport of application traffic. The control plane messages are carried as user plane data over any of the available network paths between the peer control plane functional elements in the client and the network . Multiple user plane paths are dynamically distributed across multiple access networks and aggregated in side the common core network. The access network diversity is not exposed to the application servers but kept within the scope of the elements defined in this framework. This offloads the application servers from reacting to access link changes caused to mobility events or changing of link characteristics. The selection of paths and user plane treatment of the traffic, is based on negotiation of capabilities (of device and network) and probing of network link quality between the user plane functional elements at the end-user device/client and the network. The framework enables leveraging network intelligence to setup and dynamically configure the best access network path combination based on device and network capabilities, application needs and knowledge of the network state. 6. MAMS Reference Architecture Kanugovi, et al. Expires December 2, 2019 [Page 12] Internet-Draft MAMS May 2019 +--------------------------------------------------------+ | +---------------+ +---------------+ | | ! ! ! ! | | !Core(IP anchor)! +---+ !Core(IP anchor)! | | !network 1 ! !(network 'n' ! | | ! ! ! ! | | +---------------+ +---------------+ | | \ / | | Anchor \ +---+ Anchor | | Connection 1 Connection 'n' | | \ / | | +---------------+\+---+/+------+ | | | |-----+ +----------+ | | | +----|NCM ! | N-MADP | | | | | | |-----+ +----------+ | | | | +------------------------------+ | | | / \ | | Control Plane Delivery +----+Delivery | | Path (over any Connection 1 Connection 'n' | | access user plane) / \ | | | / \ | | +------------------+ +---------------+ | | | | Access | +---+ | Access | | | | | n/w 1 | | n/w 'n' | | | +------------------+ +---------/-----+ | +-----------------------------\----------------/---------+ | \ / | +---- -\------------/-+ | | +---+ \ |------+ / | +------------+CCM | \|C-MADP|/ | | +---+ +------+ | | Client | +---------------------+ Figure 1: MAMS Reference Architecture Figure 1 illustrates MAMS architecture for the scenario of a client served by multiple (n) networks. It introduces the following functional elements, o Network Connection Manager (NCM) and Client Connection Manager (CCM) in the control plane, and o Network Multi Access Data Proxy (N-MADP) and Client Multi Access Data Proxy (C-MADP) handling the user plane. NCM: It is the functional element in the network that handles the MAMS control plane procedures. It configures the network (N-MADP) Kanugovi, et al. Expires December 2, 2019 [Page 13] Internet-Draft MAMS May 2019 and client (C-MADP) user plane functions like negotiating the client on the use of available access network paths, protocols and rules for processing the user plane traffic, as well as link monitoring procedures. The control plane messages between the NCM and CCM are transported as an overlay, without any impact to the underlying access networks. CCM: It is the peer functional element in the client for handling MAMS control plane procedures. It manages multiple network connections at the client. It is responsible for exchange of MAMS signaling messages with the NCM for supporting functions like UL and DL user network path configuration for transporting user data packets, link probing and reporting to support adaptive network path selection by NCM. In the downlink, for the user data received by the client, it configures C-MADP such that application data packet received over any of the accesses to reach the appropriate application on the client. In the uplink, for the data transmitted by the client, it configures the C-MADP to determine the best access links to be used for uplink data based on a combination of local policy and network policy delivered by the NCM. N-MADP: It is the functional element in the network that handles the user data traffic forwarding across multiple network paths, as well as other user-plane functionalities like encapsulation, fragmentation, concatenation, reordering, retransmission, etc. It is the distribution node that routes the uplink user plane traffic to the appropriate anchor connection towards the core network, and the downlink user traffic to the client over the appropriate delivery connection(s). In the downlink, the NCM configures the use of delivery connections, and user plane protocols at the N-MADP for transporting user data traffic. The N-MADP should implement ECMP support for the down link traffic. Or alternatively, it may be connected to a router with ECMP functionality. The load balancing algorithm at the N-MADP is configured by the NCM, based on static and/or dynamic network policies like assigning access and core paths for specific user data traffic type, data volume based percentage distribution, and link availability and feedback information from exchange of MAMS signaling with the CCM at the Client.. N-MADP can be configured with appropriate user plane protocols to support both per- flow and per-packet traffic distribution across the delivery connections. In the uplink, N-MADP selects the appropriate anchor connection over which to forward the user data traffic, received from the client (via the delivery connections). The forwarding rules in the uplink at the N-MADP are configured by the NCM based on application requirements, e.g. Enterprise hosted Application flows via Wi-Fi Anchor, Mobile Operator hosted applications via the Cellular Core. Kanugovi, et al. Expires December 2, 2019 [Page 14] Internet-Draft MAMS May 2019 C-MADP: It is the functional element in the client that handles the MAMS user plane data procedures. C-MADP is configured by CCM based on signaling exchange with NCM and local policies at the client. The CCM configures the selection of delivery connections and the user plane protocols to be used for uplink user data traffic based on the signaling exchanged with NCM. The C-MADP entity handles user plane data forwarding across multiple delivery connections and associated user-plane functions like encapsulation, fragmentation, concatenation, reordering, retransmissions, etc. The NCM and N-MADP can be either collocated or instantiated on different network nodes. NCM can setup multiple N-MADP instances in the network. NCM controls the selection of N-MADP instance by the client and the rules for distribution of user traffic across the N-MADP instances., This is beneficial in multple deployment scenarios, like the following examples. o Different N-MADP instances to handle different sets of clients for load balancing across clients o Address deployment topologies e.g. N-MADP hosted at the user plane node at the access edge or in the core network, while the NCM hosted at the access edge node) o Address access network technology architecture. For exanple, N-MADP instance at core network node to manage traffic distribution across LTE and DSL networks, and N-MADP instance at access network node to manage traffic distribution across LTE and Wi-Fi traffic. o A single client can be configured to use multiple N-MADP instances. This is beneficial in addressing different application requirements. For example, separate N-MADP instances to handle TCP and UDP transport based traffic. Thus, MAMS architecture flexibly addresses multiple network deployments. 7. MAMS Protocol Architecture This section describes the protocol structure for the MAMS User and Control plane functional elements. 7.1. MAMS Control-Plane Protocol Figure 2 shows the default MAMS control plane protocol stack. WebSocket is used for transporting management and control messages between NCM and CCM. Kanugovi, et al. Expires December 2, 2019 [Page 15] Internet-Draft MAMS May 2019 +------------------------------------------+ | Multi Access (MX) Control Message | | | +------------------------------------------+ | WebSocket | | | +------------------------------------------+ | TCP/TLS | | | +------------------------------------------+ Figure 2: TCP-based MAMS Control Plane Protocol Stack 7.2. MAMS User Plane Protocol Figure 3 shows the MAMS user plane protocol stack. Kanugovi, et al. Expires December 2, 2019 [Page 16] Internet-Draft MAMS May 2019 +-----------------------------------------------------+ | User Payload (e.g. IP PDU) | +-----------------------------------------------------+ +-----------------------------------------------------------+ | +-----------------------------------------------------+ | | | Multi Access (MX) Convergence Sublayer | | | +-----------------------------------------------------+ | | +-----------------------------------------------------+ | | | MX Adaptation | MX Adaptation | MX Adaptation | | | | Sublayer | Sublayer | Sublayer | | | | (optional) | (optional) | (optional) | | | +----------------++--------------+-+------------------+ | | | Access #1 IP | Access #2 IP | Access #3 IP | | | +-----------------------------------------------------+ | | MAMS User Plane Protocol Stack| +-----------------------------------------------------------+ Figure 3: MAMS User Plane Protocol Stack It consists of the following two Sublayers: o Multi-Access (MX) Convergence Sublayer: The MAMS framework configures the Convergence sublayer to perform multi-access specific tasks in the user plane. This layer performs functions Kanugovi, et al. Expires December 2, 2019 [Page 17] Internet-Draft MAMS May 2019 like access (path) selection, multi-link (path) aggregation, splitting/reordering, lossless switching, fragmentation, concatenation, etc. MX Convergence layer can be implemented using existing user plane protocols like Multipath TCP (MPTCP [RFC 6824]), Multi Path QUIC (MPQUIC [I-D.deconinck-multipath-quic]) or by adapting encapsulating header/trailer schemes like Generic Routing and Encapsulation (GRE [RFC 2784], [RFC 2890]), Generic Multi Access(GMA [I-D.zhu-intarea-gma]). o Multi-Access (MX) Adaptation Sublayer: The MAMS framework configures the Adaptation Sublayer to address transport network related aspects like reachability and security in the user plane. This layer performs functions to handle tunnelling, network layer security, and NAT. MX Adaptation can be implemented using IPsec, DTLS or Client NAT (Source NAT at Client with inverse mapping at N-MADP [I-D.zhu-intarea-mams-user-protocol]). The MX Adaptation Layer is optional and can be independently configured for each of the Access Links. E.g. In a deployment with LTE (assumed secure) and Wi-Fi (assumed not secure), the MX Adaptation Sublayer can be omitted for the LTE link but MX Adaptation Sublayer is configured as IPsec for securing the Wi-Fi link. Further details on the MAMS user plane are described in [I-D.zhu-intarea-mams-user-protocol]. 8. MAMS Control Plane Procedures 8.1. Overview CCM and NCM exchange signaling messages to configure the user plane functions, C-MADP and N-MADP, at the client and network respectively. The means for CCM to obtain the NCM credentials (FQDN or IP Address) for sending the initial discovery messages are out of the scope of MAMS document. As an example, the client can obtain the NCM credentials using methods like provisioning, DNS query. Once the discovery process is successful, the (initial) NCM can update and assign additional NCM addresses, e.g. based on MCC/MNC tuple information received in the MX Discovery Message, for sending subsequent control plane messages. CCM discovers and exchanges capabilities with the NCM. NCM provides the credentials of the N-MADP end-point and negotiates the parameters for user plane with the CCM. CCM configures C-MADP to setup the user plane path (e.g. MPTCP/UDP Proxy Connection) with the N-MADP based on the credentials (e.g. (MPTCP/UDP) Proxy IP address and port, Associated Core Network Path), and the parameters exchanged with the NCM. Further, NCM and CCM exchange link status information to adapt traffic steering and user plane treatment with dynamic network conditions. The key procedures are described in details in the following sub-sections. Kanugovi, et al. Expires December 2, 2019 [Page 18] Internet-Draft MAMS May 2019 +-----+ +-----+ | CCM | | NCM | +--+--+ +--+--+ | Discovery and | | Capability | | Exchange | <----------------------> | | | User Plane | | Protocols | | Setup | <----------------------> | Path Quality | | Estimation | <----------------------> | Network capabilities | | e.g. RNIS[ETSIRNIS] | <----------------------+ | | | Network policies | <----------------------+ + + Kanugovi, et al. Expires December 2, 2019 [Page 19] Internet-Draft MAMS May 2019 Figure 4: MAMS Control Plane Procedures 8.2. Common fields in MAMS Control Messages Each MAMS control message consists of the following common fields: o Version: indicates the version of MAMS control protocol. o Message Type: indicates the type of the message, e.g. MX Discovery, MX Capability REQ/RSP etc. o Sequence Number: auto-incremented integer to uniquely identify a transaction of message exchange, e.g. MX Capability REQ/RSP. 8.3. Common Procedures for MAMS Control Messages This section describes the common procedures for MAMS Control Messages. 8.3.1. Message Timeout MAMS Control plane peer (NCM or CCM) waits for a duration of MAMS_TIMEOUT ms, after sending a MAMS control message, before timing out when expecting a response. The sender of the message will retransmit the message for MAMS_RETRY times before declaring failure. A failure implies that the MAMS peer is dead, and the sender reverts back to native non-multi access/single path mode. CCM may initiate the MAMS discovery procedure for re-establishment of the MAMS session. 8.3.2. Keep Alive Procedure MAMS Control plane peers execute the keep alive procedures to ensure that peers are reachable and to recover from dead-peer scenarios. Each MAMS control plane end-point maintains a MAMS_KEEP_ALIVE timer that is set for duration MAMS_KEEP_ALIVE_TIMEOUT. MAMS_KEEP_ALIVE timer is reset whenever the peer receives a MAMS Control message. When MAMS_KEEP_ALIVE timer expires, MAMS KEEP ALIVE REQ message is sent. On reception of a MAMS KEEP ALIVE REQ message, the receiver responds with a MAMS KEEP ALIVE RSP message. If the sender does not receive a MAMS Control message in response to MAMS_RETRY number of retries of MAMS KEEP ALIVE REQ message, the MAMS peer declares that the peer is dead. CCM may initiate MAMS Discovery procedure for re- establishment of the MAMS session. CCM shall additionally send MX KEEP ALIVE REQ message immediately to NCM whenever it detects a handover from one base station/access point to another. During this time the user equipment shall stop using MAMS user plane functionality in uplink direction till it receives a MX KEEP ALIVE RSP from NCM. Kanugovi, et al. Expires December 2, 2019 [Page 20] Internet-Draft MAMS May 2019 MX KEEP ALIVE REQ includes following information: o Reason: Can be 'Timeout' or 'Handover'. Reason 'Handover' shall be used by CCM only on detection of handover. o Unique Session Identifier: As defined in Section 8.4. o Connection Id: This field shall be mandatorily be included if the reason is 'Handover'. o Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi). This field shall be mandatorily be included if the reason is 'Handover'. 8.4. Discovery & Capability Exchange Figure 5 shows the MAMS discovery and capability exchange procedure consisting of the following key steps: Kanugovi, et al. Expires December 2, 2019 [Page 21] Internet-Draft MAMS May 2019 CCM NCM | | +------- MX Discovery Message ---------------------->| | +-----------------+ | |Learn CCM | | | IP address | | |& port | | +-----------------+ | | |<--------------------------------MX System INFO-----| | | |---------------------------------MX Capability REQ->| |<----- MX Capability RSP----------------------------| |---------------------------------MX Capability ACK->| | | + + Figure 5: MAMS Control Procedure for Discovery & Capability Exchange Step 1 (Discovery): CCM periodically sends out the MX Discovery Message to a pre-defined (NCM) IP Address/port until MX System INFO message is received in acknowledgement. MX Discovery Message includes the following information: o MAMS Version o MCC/MNC Tuple: Optional Parameter to Identify the Operator Network to which the client is susbcribed, in conformance with format specified in [E212] MX System INFO includes the following information: Kanugovi, et al. Expires December 2, 2019 [Page 22] Internet-Draft MAMS May 2019 o Number of Anchor Connections For each Anchor Connection, it includes the following parameters: * Connection ID: Unique identifier for the Anchor Connection * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) * NCM Endpoint Address (For Control Plane Messages over this connection) + IP Address or FQDN (Fully Qualified Domain Name) + Port Number Step 2 (Capability Exchange): On receiving MX System Info message CCM learns the IP Address and port to start the step 2 of the control plane connection, and sends out the MX Capability REQ message, including the following Parameters: o MX Feature Activation List: Indicates if the corresponding feature is supported or not, e.g. lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, Measurement, probing, etc. o Number of Anchor Connections (Core Networks) For each Anchor Connection, it includes the following parameters: * Connection ID * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) o Number of Delivery Connections (Access Links) For each Delivery Connection, it includes the following parameters: * Connection ID * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) o MX Convergence Method Support List * GMA * MPTCP Proxy * GRE Aggregation Proxy * MPQUIC o MX Adaptation Method Support List * UDP Tunnel without DTLS * UDP Tunnel with DTLS * IPsec Tunnel [RFC3948] Kanugovi, et al. Expires December 2, 2019 [Page 23] Internet-Draft MAMS May 2019 * Client NAT In response, NCM creates a unique identity for the CCM session, and sends out the MX Capability RSP message, including the following information: o MX Feature Activation List: Indicates if the corresponding feature is enabled or not, e.g. lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, Measurement, probing, etc. o Number of Anchor Connections (Core Networks) For each Anchor Connection, it includes the following parameters: * Connection ID * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) o Number of Delivery Connections (Access Links) For each Delivery Connection, it includes the following parameters: * Connection ID * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: Multi-Fire; 3: LTE) o MX Convergence Method Support List * GMA * MPTCP Proxy * GRE Aggregation Proxy * MPQUIC o MX Adaptation Method Support List * UDP Tunnel without DTLS * UDP Tunnel with DTLS * IPsec Tunnel [RFC3948] * Client NAT Unique Session Identifier: Unique session identifier for the CCM which has setup the connection. In case the session for the UE already exists then the existing unique session identifier is sent back. o NCM Id: Unique Identity of the NCM in the operator network. o Session Id: Unique identity assigned to the CCM instance by this NCM instance. Kanugovi, et al. Expires December 2, 2019 [Page 24] Internet-Draft MAMS May 2019 In response to MX Capability RSP message, the CCM sends confirmation (or reject) in the MX Capability ACK message. MX Capability ACK includes the following parameters o Unique Session Identifier: Same identifier as provided in MX Capability RSP. o Acknowledgement: An indication if the client has accepted or rejected the capability phase. * MX ACCEPT: CCM Accepts the Capability set proposed by the NCM. * MX REJECT: CCM Rejects the Capability set proposed by the NCM. If MX_REJECT is received by the NCM, the current MAMS session will be terminated. If CCM can no longer continue with the current capabilities, it should send an MX SESSION TERMINATE message to terminate the MAMS session. In response, the NCM should send a MX SESSION TERMINATE ACK to confirm the termination. 8.5. User Plane Configuration Figure 6 shows the user plane configuration procedure consisting of the following key steps: Kanugovi, et al. Expires December 2, 2019 [Page 25] Internet-Draft MAMS May 2019 CCM NCM | | |------MX Reconfiguration REQ (setup)--------------->| |<------------------------+MX Reconfiguration RSP+---| | +-----------+----------------+ | | NCM prepares N+MADP for | | | User Plane|Setup | | +----------------------------+ |<----------------------------- MX UP Setup Config---| |-----| MX UP Setup CNF+---------------------------->| +-------------------+ | |Link "X" is up/down| | +-------------------+ | |-----MX Reconfiguration REQ (update/release)------->| |<------------------------+MX Reconfiguration RSP+---| Figure 6: MAMS Control Procedure for User Plane Configuration Reconfiguration: when the client detects that the link is up/down or the IP address changes (e.g. via APIs provided by the client OS), CCM sends out a MX Reconfiguration REQ Message to setup / release / update the connection, and the message SHOULD include the following information o Unique Session Identifier: Identity of the CCM identity at NCM, created by NCM during the capability exchange phase. Kanugovi, et al. Expires December 2, 2019 [Page 26] Internet-Draft MAMS May 2019 o Reconfiguration Action: indicate the reconfiguration action (0:release; 1: setup; 2: update). o Connection ID: identify the connection for reconfiguration If (Reconfiguration Action is setup or update), then include the following parameters o IP address of the connection o SSID (if Connection Type = WiFi) o MTU of the connection: MTU of the delivery path that is calculated at the UE for use by NCM to configure fragmentation and concatenation procedures[I-D.zhu-intarea-mams-user-protocol] at N-MADP. o Delivery Node Identity: Identity of the node to which the client is attached. ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi. At the beginning of a connection setup, CCM informs the NCM of the connection status using the MX Reconfiguration REQ message with Reconfiguration Action type set to "setup". NCM acknowledges the connection setup status and exchanges parameters with the CCM for user plane setup, described as follows. User Plane Protocols Setup: Based on the negotiated capabilities, NCM sets up the user plane (Adaptation Layer and Convergence Layer) protocols at the N-MADP, and informs the CCM of the user plane protocols to setup at the client (C-MADP) and the parameters for C-MADP to connect to N-MADP. The MX UP Setup Config is used to create (multiple) MADP instances with each Anchor Connection having one or more Configurations, namely MX Configurations. It consists of the following parameters: o Number of Anchor Connections (Core Networks) For Each Anchor Connection, it includes the following parameters * Anchor Connection ID * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) * Number of Active MX Configurations (Included only if more than one MX configurations are active for the anchor connection) For each active MX configuration, it includes the following parameters + MX Configuration ID (included if more than one MX Configuration is present Kanugovi, et al. Expires December 2, 2019 [Page 27] Internet-Draft MAMS May 2019 + MX Convergence Method, one of the following - GMA - MPTCP Proxy - GRE Aggregation Proxy - MPQUIC + MX Convergence Method Parameters - Convergence Proxy IP Address - Convergence Proxy Port - Client Key + MX Convergence Control Parameters (included if any MX Control PDU, e.g. Probe-REQ/ACK, is supported): - UDP Port Number for sending and receiving MX Control PDUs, e.g. Probe-REQ/ACK, Keep-Alive, etc.) - Convergence Proxy Port + Number of Delivery Connections For each Delivery Connection, include the following: - Delivery Connection ID - Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) - MX Adaptation Method, one of the following o UDP Tunnel without DTLS o UDP Tunnel with DTLS o IPSec Tunnel o Client NAT - MX Adaptation Method Parameters o Tunnel Endpoint IP Address o Tunnel Endpoint Port o Shared Secret o Header Optimization (included only if MX Convergence Method is GMA) e.g. When LTE and Wi-Fi are the two user plane accesses, NCM conveys to CCM that IPsec needs to be setup as the MX Adaptation Layer over the Wi-Fi Access, using the following parameters - IPsec end-point IP address, Pre-Shared Key. No Adaptation Layer is needed or Client NAT may be used over the LTE Access as it is considered secure with no NAT. Similarly, as an example of the MX Convergence Method configuration is to indicate the convergence protocol as MPTCP Proxy along with Kanugovi, et al. Expires December 2, 2019 [Page 28] Internet-Draft MAMS May 2019 parameters for connection to the MPTCP Proxy, namely IP Address and Port of the MPTCP Proxy for TCP Applications. Once the user plane protocols are configured, CCM informs the NCM of the status via the MX UP Setup CNF message. The MX UP Setup CNF consists of the following parameters: o Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. o MX Convergence Control Parameters (included if any MX Control PDU, e.g. Probe-REQ/ACK, Keep-alive, is supported): * UDP Port Number for sending and receiving MX Control PDUs, e.g. Probe-REQ/ACK, Keep-Alive, etc.) * MX Configuration ID (if MX Configuration ID is specified in MX UP Setup Config, indicate the MX Configuration that will be used for Probing) o Client Adaptation Layer Parameters: * Number of Delivery Connections * For each Delivery Connection, include the following: + Delivery Connection ID + UDP port number: If UDP based adaptation is in use, the UDP port at C-MADP side 8.6. MAMS Path Quality Estimation Path quality estimations can be done either passively or actively. Traffic measurements in the network could be performed passively by comparing the real-time data throughput of the device with the capacity available in the network. In special deployments where the NCM has interfaces with access nodes, direct interfaces can be used to gather path quality information. For example, the utilization of a cell/eNB attached to a device could be used as an indicator for path quality estimations without creating an extra traffic overhead. Active measurements by the device are an alternative for estimating path quality. Kanugovi, et al. Expires December 2, 2019 [Page 29] Internet-Draft MAMS May 2019 CCM NCM | | |<--------------+ MX Path Estimation Configuration+--| |-----+ MX Path Estimation Results+----------------->| | | Figure 7: MAMS Control Plane Procedure for Path Quality Estimation NCM sends following the configuration parameters in the MX Path Estimation Configuration message to the CCM o Connection ID (of Delivery Connection whose path quality needs to be estimated) o Init Probe Test Duration (ms) o Init Probe Test Rate (Mbps) o Init Probe Size (Bytes) o Init Probe Ack Required (0 -> No/1 -> Yes) o Active Probe Frequency (ms) o Active Probe Size (Bytes) o Active Probe Test Duration (ms) o Active Probe Ack Required (0 -> No/1 -> Yes) CCM configures the C-MADP for probe reception based on these parameters and for collection of the statistics according to the following configuration. o Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. o Init Probe Results Configuration * Lost Probes (%) * Probe Receiving Rate (packets per second) o Active Probe Results Configuration * Average Throughput in the last Probe Duration The user plane probing is divided into two phases - Initialization phase and Active phase. o Initialization phase: A network path that is not included by N-MADP for transmission of user data is deemed to be in the Initialization phase. The user data may be transmitted over other available network paths. Kanugovi, et al. Expires December 2, 2019 [Page 30] Internet-Draft MAMS May 2019 o Active phase: A network path that is included by N-MADP for transmission of user data is deemed to be in Active phase. In Initialization phase, NCM configures N-MADP to send an MX Idle Probe REQ message. CCM collects the Idle probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Initialization Probe Results configuration. In Active phase, NCM configures N-MADP to send an MX Active Probe REQ message.. C-MADP calculates the metrics as specified by the Active Probe Results Configuration. CCM collects the Active probe statistics from C-MADP and sends the MX Path Estimation Results Message to NCM per the Active Probe Results configuration. The following sub-sections define the control PDU encoding for Probe and Keep Alive messages to support path quality estimation. 8.6.1. MX Control PDU definition Control PDUs are sent as UDP Messages between C-MADP and N-MADP to exchange control messages for keep-alive or path quality estimation. MX Probe Parameters are negotiated during the User Plane Setup phase (MX UP SETUP CFG and MX UP SETUP CNF). Figure 7 shows the MX control PDU format with the following fields: o Type (1 Byte): the type of the MX control message * 0: Keep-Alive * 1: Probe REQ/ACK * Others: Reserved o CID (1 Byte): the connection ID of the delivery connection for sending out the MX control message o MX Control Message (variable): the payload of the MX control message o Figure 8 shows the MX Control PDU format. MX Control PDU is sent as a normal user plane packet over the desired delivery connection whose quality and reachability needs to be determined. Kanugovi, et al. Expires December 2, 2019 [Page 31] Internet-Draft MAMS May 2019 | | | <-----+MX Control PDU Payload +--------> | | | +-----------+------------------+-----+-----------------------------+ | IP header | UDP Header| Type | CID | MX Control Message | +-----------+------------------+-----+-----------------------------+ Figure 8: MX Control PDU Format 8.6.2. Keep-Alive Message The "Type" field is set to "0" for Keep-Alive messages. C-MADP may send out Keep-Alive message periodically over one or multiple delivery connections, especially if UDP tunneling is used as the adaptation method for the delivery connection with a NAT function on the path. A Keep-Alive message is 2 Bytes long, and consists of the following fields: o Keep-Alive Sequence Number (2 Bytes): the sequence number of the keep-alive message. 8.6.3. Probe REQ/ACK Message The "Type" field is set to "1" for Probe REQ/ACK messages. N-MADP may send out the Probe REQ message for path quality estimation. In response, C-MADP may send back the Probe ACK message. A Probe REQ message consists of the following fields: o Probing Sequence Number (2 Bytes): the sequence number of the Probe REQ message o Probing Flag (1 Byte): * Bit #0: a Probe ACK flag to indicate if the Probe ACK message is expected (1) or not (0); * Bit #1: a Probe Type flag to indicate if the Probe REQ/ACK message is sent during the initialization phase (0) when the network path is not included for transmission of user data or the active phase (1) when the network path is included for transmission of user data; * Bit #2: a bit flag to indicate the presence of the Reverse Connection ID (R-CID) field. * Bit #3~7: reserved Kanugovi, et al. Expires December 2, 2019 [Page 32] Internet-Draft MAMS May 2019 o Reverse Connection ID (1 Byte): the connection ID of the delivery connection for sending out the Probe ACK message on the reverse path o Padding (variable) The "R-CID" field is only present if both Bit #0 and Bit #2 of the "Probing Flag" field are set to "1". Moreover, Bit #2 of the "Probing Flag" field SHOULD be set to "0" if the Bit #0 is "0", indicating the Probe ACK message is not expected. If the "R-CID" field is not present but the Bit #0 of the "Probing Flag" field is set to "1", the Probe ACK message SHOULD be sent over the same delivery connection as the Probe REQ message. The "Padding" field is used to control the length of Probe REQ message. C-MADP SHOULD send out the Probe ACK message in response to a Probe REQ message with the Probe ACK flag set to "1". A Probe ACK message is 3 Bytes long, and consists of the following fields: o Probing Acknowledgement Number (2 Bytes): the sequence number of the corresponding Probe REQ message 8.7. MAMS Traffic Steering CCM NCM | | | +------------------------------+ | |Steer user traffic to Path "X"| | +------------------------------+ |<------------------MX Traffic Steering (TS) REQ--| |----- MX Traffic Steering (TS) RSP ------------->| Figure 9: MAMS Traffic Steering Procedure NCM sends out a MX Traffic Steering (TS) REQ message to steer data traffic. It is also possible to send data traffic over multiple connections simultaneously, i.e. aggregation. The message includes the following information: o Connection ID of the Anchor Connection o MX Configuration ID (if MX Configuration ID is specified in MX UP Setup Config) Kanugovi, et al. Expires December 2, 2019 [Page 33] Internet-Draft MAMS May 2019 o Connection ID List of Delivery Connections for DL traffic o Connection ID of Default UL Delivery Connection o For the number of Specific UL traffic Templates, include the following * Traffic Template for identifying the UL traffic * Connection ID List of Delivery connections for UL traffic identified by the traffic template o MX Feature Activation List: each parameter indicates if the corresponding feature is enabled or not: lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, Measurement, probing In response, CCM sends out a MX Traffic Steering (TS) RSP message, including the following information: o Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. o MX Feature Activation List: each parameter indicates if the corresponding feature is enabled or not: lossless switching, fragmentation, concatenation, Uplink aggregation, Downlink aggregation, probing 8.8. MAMS Application MADP Association CCM NCM | | | +-------------------------+ | | Associate MADP instance | | | with application flow | | +-------------------------+ |-------------------MX App MADP ----------->| | Association(AMA) REQ | | | |-------------------MX App MADP ----------->| | Association(AMA) RSP | Figure 10: MAMS Application MADP Association Procedure CCM sends out a MX App MADP Association(AMA) REQ message to request association of a specific Application flow with a specific MADP instance ID for the anchor connection with multiple active MX configurations. MADP Instance ID is a tuple (Anchor Connection ID, MX Configuration ID). This provides the capability for the client to indicate the user plane processing that needs to be associated with different application flows depending on their needs. The Kanugovi, et al. Expires December 2, 2019 [Page 34] Internet-Draft MAMS May 2019 application flow is identified by its associated traffic flow template. The message includes the following information: o Number of Application Flows For Each Application Flow, identified by the Traffic Flow Template(s), * Anchor Connection ID * MX Configuration ID (if more than one MX Configurations are associated with an Anchor Connection) * Traffic Template for identifying the UL traffic * Traffic Template for identifying the DL traffic In response, NCM sends out a MX App MADP Association (AMA) RSP message, including the following information: o Number of Application Flows For Each Application Flow, identified by the Traffic Flow Template(s), * Status (Success or Failure) 8.9. MAMS Network ID Indication CCM NCM | | | +---------------------------------+ | |NCM determines preferred Networks| | +---------------------------------+ |<------------------MX SSID Indication------------| Figure 11: MAMS Network ID Indication Procedure NCM indicates the preferred network list to the CCM to guide client on networks that it should connect to. To indicate preferred Wi-Fi Networks, the NCM sends the list of WLAN networks, represented by SSID/BSSID/HESSID, available in the MX SSID Indication. Kanugovi, et al. Expires December 2, 2019 [Page 35] Internet-Draft MAMS May 2019 8.10. MAMS Client Measurement Configuration and Reporting CCM NCM | | |<------------------MX MEAS CONFIG----------------| | | +---------------------------------+ | |Client Ready to send measurements| | +---------------------------------+ | | | |----- MX MEAS REPORT---------------------------->| Figure 12: MAMS Client Measurement Configuration and Reporting Procedure NCM configures the CCM with the different parameters (e.g. radio link information), with the associated thresholds to be reported by the client. The MX MEAS CONFIG message contains the following parameters. For each Delivery Connection, include the following: o Delivery Connection ID o Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) o If Connection Type is Wi-Fi * WLAN_RSSI_THRESH: High and Low Thresholds for sending Average RSSI of the Wi-Fi Link. * WLAN_RSSI_PERIOD: Periodicity in ms for sending Average RSSI of the Wi-Fi Link. * WLAN_LOAD_THRESH: High and Low Thresholds for sending Loading of the WLAN system. * WLAN_LOAD_PERIOD: Periodicity in ms for sending Loading of the WLAN system. * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse Link Throughput on the Wi-Fi link. * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link Throughput on the Wi-Fi link. * DL_TPUT_THRESH: High and Low Thresholds for sending Forward Link Throughput on the Wi-Fi link. * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link Throughput on the Wi-Fi link. * EST_UL_TPUT_THRESH: High and Low Thresholds for sending Reverse Link Throughput (EstimatedThroughputOutbound as defined in [IEEE]) on the Wi-Fi link. Kanugovi, et al. Expires December 2, 2019 [Page 36] Internet-Draft MAMS May 2019 * EST_UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link Throughput (EstimatedThroughputOutbound as defined in [IEEE]) on the Wi-Fi link. * EST_DL_TPUT_THRESH: High and Low Thresholds for sending Forward Link Throughput (EstimatedThroughputInbound as defined in [IEEE]) on the Wi-Fi link. * EST_DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link Throughput (EstimatedThroughputInbound as defined in [IEEE]) on the Wi-Fi link. o If Connection Type is LTE * LTE_RSRP_THRESH: High and Low Thresholds for sending RSRP of Serving LTE link. * LTE_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving LTE link. * LTE_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of the serving LTE link. * LTE_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving LTE link. * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse Link Throughput on the serving LTE link. * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link Throughput on the serving LTE link. * DL_TPUT_THRESH: High and Low Thresholds for sending Forward Link Throughput on the serving LTE link. * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link Throughput on the serving LTE link. o If Connection Type is 5G NR * NR_RSRP_THRESH: High and Low Thresholds for sending RSRP of Serving NR link. * NR_RSRP_PERIOD: Periodicity in ms for sending RSRP of Serving NR link. * NR_RSRQ_THRESH: High and Low Thresholds for sending RSRQ of the serving NR link. * NR_RSRQ_PERIOD: Periodicity in ms for sending RSRP of Serving NR link. * UL_TPUT_THRESH: High and Low Thresholds for sending Reverse Link Throughput on the serving NR link. * UL_TPUT_PERIOD: Periodicity in ms for sending Reverse Link Throughput on the serving NR link. * DL_TPUT_THRESH: High and Low Thresholds for sending Forward Link Throughput on the serving NR link. * DL_TPUT_PERIOD: Periodicity in ms for sending Forward Link Throughput on the serving NR link. The MX MEAS REPORT message contains the following parameters Kanugovi, et al. Expires December 2, 2019 [Page 37] Internet-Draft MAMS May 2019 o Unique Session Identifier: Session identifier provided to the client in MX Capability RSP. o For each Delivery Connection, include the following: * Delivery Connection ID * Connection Type (e.g., 0: Wi-Fi; 1: 5G NR; 2: MulteFire; 3: LTE) * Delivery Node Identity (ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi) * If Connection Type is Wi-Fi + WLAN_RSSI: Average RSSI of the Wi-Fi Link. + WLAN_LOAD: Loading of the WLAN system. + UL_TPUT: Reverse Link Throughput on the Wi-Fi link. + DL_TPUT: Forward Link Throughput on the Wi-Fi link. + EST_UL_TPUT: Estimated Reverse Link Throughput on the Wi-Fi link (EstimatedThroughputOutbound as defined in [IEEE]). + EST_DL_TPUT: Estimated Forward Link Throughput on the Wi-Fi link (EstimatedThroughputInbound as defined in [IEEE]). * If Connection Type is LTE + LTE_RSRP: RSRP of Serving LTE link. + LTE_RSRQ: RSRQ of the serving LTE link. + UL_TPUT: Reverse Link Throughput on the serving LTE link. + DL_TPUT: Forward Link Throughput on the serving LTE link. * If Connection Type is 5G NR + NR_RSRP: RSRP of Serving NR link. + NR_RSRQ: RSRQ of the serving NR link. + UL_TPUT: Reverse Link Throughput on the serving NR link. + DL_TPUT: Forward Link Throughput on the serving NR link. 8.11. MAMS Session Termination Procedure CCM NCM | | |+----MX Session Terminate--------->| | | | | |<---MX Session Terminate Ack-------| | +---------------+ | Remove Resources | +---------------+ | | Figure 13: MAMS Session Termination Procedure - Client Initiated Kanugovi, et al. Expires December 2, 2019 [Page 38] Internet-Draft MAMS May 2019 CCM NCM | | |<----------MX Session Terminate--------| | | | | | | +--------MX Session Terminate Ack-------> | | | | +-----------+-----------+ | | Remove Resources | | +-----------+-----------+ | | | Figure 14: MAMS Session Termination Procedure - Network Initiated At any point in MAMS functioning if CCM or NCM is unable to support the MAMS functions anymore, then either of them can initiate a termination procedure by sending MX Session Terminate to the peer, the peer shall acknowledge the termination by sending MX Session Terminate ACK message. After the session is disconnected the CCM shall start a new procedure with MX Discover Message. MX Session Terminate message shall contain Unique Session Identifier and reason for termination in Request. Possible reasons for termination can be: o Normal Release o No Response from Peer o Internal Error 8.12. MAMS Network Analytics Request Procedure CCM NCM | | |+----MX Network Analytics Request----------->| | | | | |<---MX Network Analytics Info----------------| | | Figure 15: MAMS Network Analytics Request Procedure CCM sends the MX Network Analytics Request informs the NCM to send information related to network parameters like bandwidth, latency, jitter, signal quality based on application of analytics at the Kanugovi, et al. Expires December 2, 2019 [Page 39] Internet-Draft MAMS May 2019 network utilizing the received path measurements and client measurement reporting. The MX Network Analytics Request message consists of the following parameters. o Link Quality Indicators, one or more of the following: * Bandwidth * Jitter * Latency * Signal Quality NCM sends the MX Network Analytics Info to convey the analytics info, predictive parameters with likelihoods, for the different parameters of interest for the CCM. The MX Network Analytics Info messages consists of the following parameters. o Number of Delivery Connections For Each Delivery Connection, * Access Link Identifier + Connection Type + Connection ID * Link Quality Indicator + Bandwidth - Predicted Value (in Mbps) - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) + Jitter - Predicted Value (in s) - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) + Latency - Predicted Value (in s) - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) + Signal Quality - if Delivery Connection Type is LTE, LTE_RSRP Predicted Value (in dBm) Kanugovi, et al. Expires December 2, 2019 [Page 40] Internet-Draft MAMS May 2019 - if Delivery Connection Type is LTE, LTE_RSRQ Predicted Value (in dBm) - if Delivery Connection Type is NR, NR_RSRP Predicted Value (in dBm) - if Delivery Connection Type is NR, NR_RSRQ Predicted Value (in dBm) - if Delivery Connection Type is WiFi, WLAN_RSSI Predicted Value (in dBm) - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) 9. Generic MAMS Signaling Flow +----------------------------------------+ | MAMS enabled Network of Networks | | +-----+ +-----+ +-----+ +------+ +-----------------+ | | | | | | | | || | Client | | |Netwo| |Netwo| | | | || | +-----+ +-----+ | | |rk 1 | |rk 2 + |NCM | N-MADP|| | C-MADP |CCM | | | |(LTE)| |(WiFi) | | | || | +-----+ +-----+ | | +-----+ +-----+ +-----+ +------| -+----------------+ +----------------------------------------+| | | | | | | | | | | | | | | | 1.SETUP CONNECTION| | | | |<-----------+------------>| | | | | | | + + | | | | | 2. MAMS Capabilities Exchange | | | | |<-------------+----------+-------->| | | | | | | | | | | + | | | | | | 3. SETUP CONNECTION | | | |<--+-------------------------------->| | | | 4c. Config| 4a. NEGOTIATE NETWORK PATHS, FLOW |4b. Config| | C-MADP | PROTOCOL AND PARAMETERS | |N-MADP | | |<----->|<-------------+----------+-------->|<-------->| | | | + + | | | | |5. ESTABLISH USER PLANE PATH ACCORDING TO | | | | SELECTED FLOW PROTOCOL | | | | |<---------------------+----------+------------------->| | | | | | | | + + + + + + + Figure 16: MAMS call flow Kanugovi, et al. Expires December 2, 2019 [Page 41] Internet-Draft MAMS May 2019 Figure 16 illustrates the MAMS signaling mechanism for negotiation of network paths and flow protocols between the client and the network. In this example scenario, the client is connected to two networks (say LTE and WiFi). 1. UE connects to network 1 and gets an IP address assigned by network 1. 2. CCM communicates with NCM functional element via the network 1 connection and exchanges capabilities and parameters for MAMS operation. Note: The NCM credentials (e.g. NCM IP Address) can be made known to the UE by pre-provisioning. 3. Client sets up connection with network 2 and gets an IP address assigned by network 2. 4. CCM and NCM negotiate capabilities and parameters for establishment of network paths, which are then used to configure user plane functions N-MADP at the network and C-MADP at the client. 4a. CCM and NCM negotiate network paths, flow routing and aggregation protocols, and related parameters. 4b. NCM communicates with the N-MADP to exchange and configure flow aggregation protocols, policies and parameters in alignment with those negotiated with the CCM. 4c. CCM communicates with the C-MADP to exchange and configure flow aggregation protocols, policies and parameters in alignment with those negotiated with the NCM. 5. C-MADP and N-MADP establish the user plane paths, e.g. using IKE [RFC7296] signaling, based on the negotiated flow aggregation protocols and parameters specified by NCM. CCM and NCM can further exchange messages containing access link measurements for link maintenance by the NCM. NCM evaluates the link conditions in the UL and DL across LTE and WiFi, based on link measurements reported by CCM and/or link probing techniques and determines the UL and DL user data distribution policy. NCM and CCM also negotiate application level policies for categorizing applications, e.g. based on DSCP, Destination IP address, and determining which of the available network paths, needs to be used for transporting data of that category of applications. NCM configures N-MADP, and CCM configures C-MADP, based on the negotiated application policies. CCM may apply local application policies, in addition to the application policy conveyed by the NCM. Kanugovi, et al. Expires December 2, 2019 [Page 42] Internet-Draft MAMS May 2019 10. Relation to IETF Technologies MAMS leverages technologies developed in IETF like MPTCP, GRE and enables a control plane framework to negotiate the use of these protocols between the client and the network. It also addresses the limitations in the scope of other multihoming protocols. E.g. MOBIKE RFC 4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE)) scope indicates that it is limited to multihoming between IPsec clients(tunnel mode IPsec SAs) ONLY and does NOT support load balancing. MAMS addresses this limitation in handling multihoming scenario by supporting load balancing with simultaneous use of multiple access paths by negotiating use of protocols like MPTCP. Unlike MOBIKE, which only applies to end points connected with IPsec tunnel mode SA, MAMS allows flexibility to use a wide range of tunneling protocols to be used in the Adaptation layer. 11. Applying MAMS Control Procedures with MPTCP Proxy as User Plane If NCM determines that N-MADP is to be instantiated with MPTCP as the MX Convergence Protocol, it exchanges the MPTCP capability support in discovery and capability exchange procedures. NCM then exchanges the credentials of the N-MADP instance, setup as MPTCP Proxy, along with related parameters to the CCM. CCM configures C-MADP with these parameters to connect with the N-MADP, MPTCP proxy (e.g. [I-D.ietf-tcpm-converters]) instance, on the available network path (Access). Figure 17 illustrates the user plane protocol layering when MPTCP is configured to be the "MX Convergence Sublayer" protocol. MPTCP manages traffic distribution and aggregation over multiple delivery connections. +-----------------------------------------------------+ | MPTCP | +----------------+---------------+--------------------+ | TCP | TCP | TCP | +-----------------------------------------------------+ | MX Adaptation | MX Adaptation | MX Adaptation | | Sublayer | Sublayer | Sublayer | | (optional) | (optional) | (optional) | +-----------------------------------------------------+ | Access #1 IP | Access #2 IP | Access #3 IP | +----------------+---------------+--------------------+ Figure 17: MAMS U-plane Protocol Stack with MPTCP as MX Convergence Layer Kanugovi, et al. Expires December 2, 2019 [Page 43] Internet-Draft MAMS May 2019 The Client (C-MADP) sets up an MPTCP connection with the N-MADP to begin with. MAMS control procedures are then applied to, o Connect to the appropriate MPTCP network endpoint, e.g. MPTCP Proxy (illustrated in Figure 18) o Control addition of second TCP subflow after WiFi connection is established and is deemed good, (illustrated in illustrated in Figure 19), o Control the MPTCP scheduler behavior like use of only LTE Subflow in UL and both LTE and WiFi subflows in DL (illustrated in illustrated in Figure 20), o Faster response to WiFi link degradation by proactive deletion of TCP subflow over WiFi when poor link conditions are reported, to maintain performance (illustrated in illustrated in Figure 21) Figure 18 shows the call flow describing MAMS control procedures applied to configure user plane and dynamic optimal path selection in a scenario with MPTCP Proxy as the convergence protocol in the user plane. Kanugovi, et al. Expires December 2, 2019 [Page 44] Internet-Draft MAMS May 2019 +------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | 1. LTE Session Setup and IP Add. Allocation | -------------------------------------------+-------------+-------------+-+ |2. MAMS Discovery Message (MAMS Version, MCC/MNC) | | | +-----------------------------------------+-------------> | | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | <-------------+-------------+-------------+-------------+ | | | | | | | |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | +-----------------------------------------------------+-> | |5. MX CAPABILITY RSP(Convergence/Adaptation Parameters)| | <-----------------------------------------+-------------+ | | 6. MX CAPABILITY ACK(ACCEPT) | | | +-------------+-------------+---------------------------> | | | | | | | |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | <-------------------------------------------------------+ | |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | +-----------------------------------------+-------------> | |9. MAMS SSID IND(List of SSIDs) | | | <-------------+-------------+---------------------------+ | | | | | | | |10. MX RECONFIGURATION REQ (LTE IP) | | | +-------------------------------------------------------> | |11. MX RECONFONFIGURATION RSP | | | <-----------------------------------------+-------------+ | |12. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | <---------------------------+-------------+-------------+ | |13. MX UP SETUP RSP | | | | +-------------+-------------+-------------+-------------> + | | 14. MPTCP Connection with designated MPTCP Proxy over LTE | +-------------+-------------+-------------+-------------> | | | | | | + + + + + + Figure 18: MAMS-assisted MPTCP Proxy as User Plane - Initial Setup with LTE leg Following are the salient steps described in the call flow. The client connects to the LTE network and obtains an IP address (assume LTE is the first connection), and initiates the NCM discovery procedures and exchange capabilities, including the support for MPTCP as the convergence protocol at both the network and the client. Kanugovi, et al. Expires December 2, 2019 [Page 45] Internet-Draft MAMS May 2019 The CCM informs the LTE connection parameters to the NCM. NCM provides the parameters like MPTCP Proxy IP address/Port, MPTCP Client Key for configuring the convergence layer. This is useful if N-MADP is reachable via different IP address or/and port, from different access networks. The current MPTCP signaling can't identify or differentiate the MPTCP proxy IP address and port among multiple access networks. The client uses the MPTCP Client Key during the subflow creation, and this enables the N-MADP to uniquely identify the client, even if NAT is present. The N-MADP then can inform the NCM of the subflow creation and pararmeters related to creating additional subflows. Since LTE is the only connection, the user plane traffic, flows over the single TCP subflow over the LTE connection. Optionally, NCM provides assistance information to the device on the neighboring/preferred Wi-Fi networks that it can associate with. Kanugovi, et al. Expires December 2, 2019 [Page 46] Internet-Draft MAMS May 2019 +------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C-MADP | |Wi-Fi N/W| | LTE N/W | | NCM | |N-MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | Traffic over LTE in UL and DL over MPTCP Connection | +------------------------------------------------------------------------+ +------------------------------------------------------------------------+ | Wi-Fi Connection Establishment and IP Address Allocation | +---------------------------------------------------------------------+--+ |15. MX RECONFIGURATION REQ (Wi-Fi IP) | | | +-------------------------------------------------------> | |16. MX RECONFONFIGURATION RSP | | | <-----------------------------------------+-------------+ | |17. MX UP SETUP REQ (MPTCP Proxy IP/Port, Aggregation) | | <---------------------------+-------------+-------------+ | |18. MX UP SETUP RSP | | | | +-------------+-------------+-------------+-------------> | | | 19. IPsec Tunnel Establishment over WLAN path | | <-----------------------------------------|-------------> | 20. MX MEAS REPORT (WLAN RSSI, LTE RSRP. UL/DL TPUT) |+-------------+ +-------------+-------------+-------------+------------->+Wait for | | | | | |+good reports | | | | | |+-------------+ | 21. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +------------+ <-----------------------------------------+-------------+ |Allow Use of| | 22. MX TRAFFIC STEERING RSP (...) | | |Wi-Fi link | +-------------+-------------+---------------------------> +-----------++ | | | | | | | 23. Add TCP subflow to the MPTCP connection over WiFi link (IPsec Tunnel) | |<----------------------------------------------------->| +-----------------------------------------------------------------------+ || Aggregated Wi-Fi and LTE capacity for UL and DL || +-----------------------------------------------------------------------+ | | | | Figure 19: MAMS-assisted MPTCP Proxy as User Plane - Add Wi-Fi leg Figure 19 describes the steps, when the client establishes a Wi-Fi connection. CCM informs the NCM of the Wi-Fi connection along with parameters like the Wi-Fi IP address, SSID. NCM determines that the Wi-Fi connection needs to be secured and configures the Adaptation Layer to be IPsec and provides the required parameters to the CCM. In addition, NCM provides the information to configure the convergence layer, (e.g. MPTCP Proxy IP Address), and provides the Traffic Steering Request to indicate that client should use only the Kanugovi, et al. Expires December 2, 2019 [Page 47] Internet-Draft MAMS May 2019 LTE access. NCM may do this, for example, on determination from the measurements that the Wi-Fi link is not consistently good enough. As the Wi-Fi link conditions improve, NCM sends a Traffic Steering Request to use Wi-Fi access as well. This triggers the client to establish the TCP subflow over the Wi-Fi link with the MPTCP proxy +------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | Traffic over LTE and Wi Fi in UL And DL over MPTCP | +-------------+-------------+-------------+-------------+------------+---+ | | | | | | | 24. MX MEAS REPORT (WLAN RSSI, LTE RSRP ,UL/DL TPUT) |+-----------+---+ +-------------+-------------+-------------+------------>|| Reports of bad| | | | | |+ Wi-Fi UL tput| | + + + ++---------------+ | 25. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ |<-----------------------------------------+------------+ |Disallow use| | 26. MX TRAFFIC STEERING RSP (...) | | |of Wi-Fi UL | |-------------+-------------+-------------------------->| +----------+--+ | | | | | | ++-------------+-------------+-------------+-------------+------------+-+ | UL data to use TCP subflow over LTE link only, | | Aggregated Wi-Fi+LTE capacity for DL | ++-------------+-------------+-------------+-------------+-------------++ | | | | | | + + + + + + Figure 20: MAMS-assisted MPTCP Proxy as User Plane - Wi-Fi UL degrades Figure 20 describes the steps, when the client reports that Wi-Fi link conditions degrade in UL. MAMS control plane is used to continuously monitor the access link conditions on Wi-Fi and LTE connections. The NCM may at some point determine increase in UL traffic on Wi-Fi, and trigger the client to only LTE in the UL via Traffic Steering Request to improve UL performance. Kanugovi, et al. Expires December 2, 2019 [Page 48] Internet-Draft MAMS May 2019 +------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +-----------------------------------------------------------------------+ | UL data to use TCP subflow over LTE link only, | | Aggregated Wi+Fi+LTE capacity for DL | ++-------------+-------------+-------------+-------------+------------+-+ | | | | | | | + + + | | | 27. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) +------------+---+ +-------------+-------------+-------------+------------>|| Reports of bad+ | | | | || Wi+Fi UL/DL tput | + + + +----------------+ | 28. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) | +-------------+ +<----------------------------------------+-------------+ |Disallow use| | 29. MX TRAFFIC STEERING RSP (...) | | |of Wi+Fi | +-----------------------------------------+------------>+ +-------------+ | |30. Delete TCP subflow from MPTCP conn. over Wi-Fi link | | +<---------------------------------------------------->| +-----------------------------------------------------------------------+ || Traffic over LTE link only for DL and UL | | | || (until Client reports better Wi-Fi link conditions) | | | +-----------------------------------------------------------------------+ | | | | | | + + + + + + Figure 21: MAMS-assisted MPTCP Proxy as User Plane - Part 4 Figure 21 describes the steps, when the client reports that Wi-Fi link conditions degrade in both UL and DL. As the Wi-Fi link conditions deteriorate further, the NCM may determine to send Traffic Steering Request guiding the client to stop using Wi-Fi, and to use only LTE access in both UL and DL. This condition may be maintained until NCM determines, based on reported measurements that Wi-Fi link has become usable. 12. Applying MAMS Control Procedures for Network Assisted Traffic Steering when there is No Convergence Layer Figure 22 shows the call flow describing MAMS control procedures applied for dynamic optimal path selection in a scenario convergence and Adaptation layer protocols are not omitted. This scenario indicates the applicability of a MAMS Control Plane only solution. In the capability exchange messages, NCM and CCM negotiate that Convergence and Adaptation layer protocols are not needed (or Kanugovi, et al. Expires December 2, 2019 [Page 49] Internet-Draft MAMS May 2019 supported). CCM informs the NCM of the availability of the LTE and Wi-Fi links. NCM determines the access links, Wi-Fi or LTE to be used dynamically based on the reported link quality measurements. +------+ +---------+ +---------+ +---------+ +---------+ +------+ | | | | | | | | | | | | |CCM | | C+MADP | |Wi+Fi N/W| | LTE N/W | | NCM | |N+MADP| +------+ +---------+ +---------+ +---------+ +---------+ +------+ +------------------------------------------------------------------------+ | 1. LTE Session Setup and IP Add. Allocation | +------------------------------------------+-------------+-------------+-+ |2. MAMS Discovery Message (MAMS Version, MCC/MNC Tuple) | | | +-----------------------------------------+------------>| | | 3. MX SYSTEM INFO (Serving NCM IP/Port Address) | | <-------------+-------------+-------------+-------------+ | | + + + + | |4. MX CAPABILITY REQ(Supported Anchor/Delivery Links ( Wi-Fi, LTE ) | +------------------------------------------------------>| | |5. MX CAPABILITY RSP(No Convergence/Adpatation parameters) | |<-----------------------------------------+------------+ | | 6. MX CAPABILITY ACK(ACCEPT) | | | +-------------+-------------+-------------------------->| | | + + + + | |7. MX MEAS CONFIG (WLAN/LTE Measurement Thresholds/Period) | |<------------------------------------------------------| | |8. MX MEAS REPORT ( LTE RSRP, UL/DL TPUT ) | | |-----------------------------------------+------------>| | |9. MAMS SSID IND(List of SSIDs) | | | |<------------------------------------------------------| | +-----------------------------------------------------------------------++ | 10. Wi|Fi connection setup and IP Address allocation | +-+-------------+-------------+-------------+-------------+-------------++ | + + | | | |10. MX RECONFIGURATION REQ (LTE IP, Wi-Fi IP) | | +-----------------------------------------+------------>| | |11. MX RECONFONFIGURATION RSP | | | <------------------------------------------------------+| | +-----------------------------------------------------------------------++ | Initial Condition, Data over LTE link only, WLAN link is poor | +---------------------------------------------------------+-------------++ |12. MX MEAS REPORT (WLAN RSSI, LTE RSRP, UL/DL TPUT) |+-------------+ |------------------------------------------------------>||Wi-Fi Link | | | | | ||conditions | | | | | ||reported good| | | | | |+-------------+ | | | | | | |13. MX TRAFFIC STEERING REQ (UL/DL Access, TFTs) |+--------------+ Kanugovi, et al. Expires December 2, 2019 [Page 50] Internet-Draft MAMS May 2019 |<-------------+-------------+-------------+------------||Steer traffic | |14. MX TRAFFIC STEERING RSP (...) | ||to use Wi-Fi | |<-------------+-------------+-------------+------------||link | | | | | |+--------------+ +-----------------------------------------------------------------------++ | Use Wi-Fi link for Data | +---------------------------------------------------------+-------------++ | | | | | | + + + + + + Figure 22: MAMS With No Convergence Layer 13. Co-existence of MX Adaptation and MX Convergence Layers MAMS user plane supports multiple instances and combinations of protocols to be used at the MX Adaptation and the Convergence layer. For example, one instance of the MX Convergence Layer can be MPTCP Proxy and another instance can be GMA. The MX Adaptation for each can be either UDP tunnel or IPsec. IPSec may be set up when network path needs to be secured, e.g. to protect the TCP subflow traversing the network path between the client and MPTCP proxy. Each of the instances of MAMS user plane, i.e. combination of MX Convergence and MX Adaptation layer protocols, can coexist simultaneously and independently handle different traffic types. 14. Security Considerations 14.1. MAMS Control Plane Security The NCM functional element is hosted on a network node which is assumed to be within a secure network, e.g. within the operator's network, and is assumed to be protected against hijack attacks. For deployment scenarios, where the client is configured (e.g. by the network operator) to use a specific network path for exchanging control plane messages and if the network path is assumed to be secure, MAMS control messages will rely on security provided by the underlying network. For deployment scenarios where the security of the network path cannot be assumed, NCM and CCM implementations MUST support the "wss" URI scheme [RFC6455] and Transport Layer Security (TLS) [RFC5246] to secure control plane message exchange between the NCM and CCM. Kanugovi, et al. Expires December 2, 2019 [Page 51] Internet-Draft MAMS May 2019 For deployment scenarios where client authentication is desired, the WebSocket server can use any client authentication mechanisms available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication. 14.2. MAMS User Plane Security User data in MAMS framework relies on the security of the underlying network transport paths. When this cannot be assumed, NCM configures use of protocols, like IPsec [RFC4301] [RFC3948] in the MX Adaptation Layer, for security. 15. Implementation Considerations MAMS builds on commonly available functions available on terminal devices that can be delivered as a software update over the popular end-user device operating systems, enabling rapid deployment and addressing the large deployed device base. 16. Applicability to Multi Access Edge Computing Multi-access Edge Computing (MEC), previously known as Mobile Edge Computing, is an access-edge cloud platform being considered at ETSI [ETSIMEC] , whose initial focus was to improve quality of experience by leveraging intelligence at the cellular (e.g., 3GPP technologies like LTE) access edge, and the scope is now being extended to support access technologies beyond 3GPP. The applicability of the framework described in this document to the MEC platform has been evaluated and tested in different network configurations by the authors. The NCM can be hosted on a MEC cloud server that is located in the user plane path at the edge of the multi-technology access network. The NCM and CCM can negotiate the network path combinations based on application needs and the necessary user plane protocols to be used across the multiple paths. The network conditions reported by the CCM to the NCM can be complemented by a Radio Analytics application [ETSIRNIS] residing at the MEC to configure the uplink and downlink access paths according to changing radio and congestion conditions. The user plane functional element, N-MADP, can either be collocated with the NCM at the MEC cloud server (e.g., MEC hosted applications), or placed at a separate network element like a common user plane gateway across the multiple networks. Also, even in scenarios where N-MADP is not deployed, the NCM can be used to augment the traffic steering decisions at the device. Kanugovi, et al. Expires December 2, 2019 [Page 52] Internet-Draft MAMS May 2019 The aim of these enhancements is to improve the end-user's quality of experience by leveraging the best network path based on application needs and network conditions, and building on the advantages of significantly reduced latency and the dynamic and real-time exposure of radio network information available at the MEC. 17. Related work in other Industry and Standards Forums The MAMS framework described in this document has been incorporated as a solution to address multi access integration in multiple industry forums and standards. This section describes the related work in other industry forums and the standards organizations. Wireless Broadband Alliance Industry partners have published a whitepaper that describes applicability of different technologies for multi access integration to different deployments as part of their project named, Unlicensed Integration with 5G Networks [WBAUnl5G]. The whitepaper includes MAMS framework described in this document as a technology for integrating Unlicensed (WiFi) networks with 5G networks above the 5G core network. 3GPP is developing a technical report as part of its work item Study on Access Traffic Steering, Switching and Splitting (ATSSS). That report, TR23.793 [GPPATSSS], contains a number of potential solutions and Solution 1 utilizes a separate control plane for flexible negotiation of user plane protocols and path measurements in a way that is similar the MAMS architecture described in this document. The Small Cell Forum (SCF) [SCFTECH5G] plans to develop a while paper as part of its work item on LTE/5G and WiFi. There is a proposal to include MAMS in this whitepaper. The ETSI Multi-access Edge Computing Phase 2 technical work is examining many aspects of this work including use cases for optimizing Quality of Experience (QoE) and resource utilization. The MAMS architecture and procedures outlined in this document is included in the use cases and requirements document[ETSIMAMS]. 18. Contributing Authors The editors gratefully acknowledge the following additional contributors in alphabetical order: A Krishna Pramod/Nokia, Hannu Flinck/Nokia, Hema Pentakota/Nokia, Nurit Sprecher/Nokia, Salil Agarwal/Nokia; Shuping Peng/Huawei, Vasudevan Subramanian/Nokia. Vasudevan Subramanian has been instrumental in conceptualization and development of solution principles for the MAMS framework. Shuping Peng has been a key contributor in refining the framework and control plane protocol aspects. Kanugovi, et al. Expires December 2, 2019 [Page 53] Internet-Draft MAMS May 2019 19. Acknowledgments This protocol is the outcome of work by many engineers, not just the authors of this document. In alphabetical order, the contributors to the project are: Barbara Orlandi, Bongho Kim,David Lopez-Perez, Doru Calin, Jonathan Ling, Lohith Nayak, Michael Scharf. 20. IANA Considerations This draft makes no requests of IANA 21. References 21.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, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 21.2. Informative References [ANDSF] "TS 24.312 version 15.0, 21 June 2018: 3GPP Specification on Access Network Discovery and Selection Function (ANDSF) Management Object (MO)", http://www.3gpp.org/ftp//Specs/ archive/24_series/24.312/24312-f00.zip", . [E212] "ITU-T E.212: The international identification plan for public networks and subscriptions, https://www.itu.int/rec/T-REC-E.212-201609-I/en", . [ETSIMAMS] "Multi-access Edge Computing (MEC); Phase 2: Use Cases and Requirements, https://www.etsi.org/deliver/etsi_gs/ MEC/001_099/002/02.01.01_60/gs_MEC002v020101p.pdf", . Kanugovi, et al. Expires December 2, 2019 [Page 54] Internet-Draft MAMS May 2019 [ETSIMEC] "Multi-access Edge Computing (MEC), ETSI", . [ETSIRNIS] "Mobile Edge Computing (MEC) Radio Network Information API", . [GPPATSSS] "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture (Release 16), https://www.3gpp.org, work in progress", . [I-D.deconinck-multipath-quic] Coninck, Q. and O. Bonaventure, "Multipath Extension for QUIC", draft-deconinck-multipath-quic-00 (work in progress), October 2017. [I-D.ietf-tcpm-converters] Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- tcpm-converters-06 (work in progress), March 2019. [I-D.zhu-intarea-gma] Zhu, J. and S. Kanugovi, "Generic Multi-Access (GMA) Convergence Encapsulation Protocols", draft-zhu-intarea- gma-02 (work in progress), March 2019. [I-D.zhu-intarea-mams-user-protocol] Zhu, J., Seo, S., Kanugovi, S., and S. Peng, "User-Plane Protocols for Multiple Access Management Service", draft- zhu-intarea-mams-user-protocol-07 (work in progress), April 2019. [IEEE] "IEEE Standard for Information technology: Telecommunications and information exchange between systems Local and metropolitan area networks:Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.", . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . Kanugovi, et al. Expires December 2, 2019 [Page 55] Internet-Draft MAMS May 2019 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, . [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 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, . [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, . [SCFTECH5G] "Small Cell Forum, https://scf.io/", . [WBAUnl5G] "Wireless Broadband Alliance Project - Unlicensed Integration with 5G Networks, https://www.wballiance.com/resource/ unlicensed-integration-with-5g-networks/.", . Appendix A. MAMS Control Plane Optimization over Secure Connections If the connection between CCM and NCM over which the MAMS control plane messages are transported is assumed to be secure, UDP is used as the transport for management & control messages between NCM and UCM (see Figure 23). Kanugovi, et al. Expires December 2, 2019 [Page 56] Internet-Draft MAMS May 2019 +-----------------------------------------------------+ | Multi-Access (MX) Control Message | |-----------------------------------------------------| | UDP | |-----------------------------------------------------| Figure 23: UDP-based MAMS Control plane Protocol Stack Appendix B. MAMS Application Interface B.1. Overall Design CCM hosts an HTTPS server for applications to communicate and request services. It is assumed in this draft that all CCM and the communicating Application instances are hosted in a single administrative domain from security point of view. The content of messages is defined in "Java Script Object Notation" (JSON) format. They offer RESTful APIs for communication. The exact mechanism regarding how Application knows about the end point of CCM is not covered as part of this document. It may be provided as part of the Application Settings. B.2. Notation The documentation of APIs are provided in OpenAPI format using swagger v2.0 (TBD - Add section in appendix) B.3. Error Indication For every API, there could be an error response in case the objective of API could not be met as defined in [RFC2616]. B.4. CCM APIs The following sections describe the APIs exposed by CCM to the applications B.4.1. Get Capabilities The CCM provides a HTTPS GET interface as "/ccm/v1.0/capabilities" for the Application to query about the capabilities supported by the CCM instance. Kanugovi, et al. Expires December 2, 2019 [Page 57] Internet-Draft MAMS May 2019 +-----------+ +-------------+ | | | | | App +----------+HTTPS GET /capabilities+-------->| CCM | | | | | +-----------+ +-------------+ Figure 24: CCM API - GET Procedures The CCM shall provide information of its capabilities as follows: o Supported Features: One of more of as defined in MX Feature Activation List parameter of MX Capability REQ. o Supported Connections: Supported connection types and connection IDs o Supported MX Adaptation Sublayers: List of MX adaptation sublayer protocols supported by the N-MADP instance alongwith the connection type where these are supported and their respective parameters. o Supported MX Convergence Sublayers: List of supported MX Convergence Sublayer protocols alongwith the parameters associated with respective convergence technique. B.4.2. Post App Requirements The CCM provides a HTTPS POST interface as "/ccm/v1.0/ app_requirements" for the Application to post the needs of the application data streams to the CCM instance. +-----------+ +-------------+ | | | | | App +----------+HTTPS POST /App Requirements+--->| CCM | | | | | +-----------+ +-------------+ Figure 25: CCM API - POST Procedures The CCM shall provide for the application to post the following requirements of its different data streams: o Number of data stream types For each data stream type, the following link feature preferences, o Protocol Type: Transport layer protocol associated with the application data stream packets. o Port Range: Supported connection types and connection IDs. Kanugovi, et al. Expires December 2, 2019 [Page 58] Internet-Draft MAMS May 2019 o Traffic QoS: Quality of service parameters as follows * Bandwidth * Latency * Jitter B.4.3. Get Predictive Link Parameters The CCM provides a HTTPS GET interface as "/ccm/v1.0/ predictive_link_params" for the Application to get the predicted link parameters from the CCM instance. +-----------+ +-------------+ | | | | | App +-------+HTTPS GET /Predictive Link Params--->| CCM | | | | | +-----------+ +-------------+ Figure 26: CCM API - GET Predictive Link Parameters Procedures CCM requests the NCM for link parameters via the MAMS Network Analytics Request Procedure (Section 8.12) and includes the information in response to the API invocation. o Number of Delivery Connections For Each Delivery Connection, * Access Link Identifier + Connection Type + Connection ID * Link Quality Indicator + Bandwidth - Predicted Value (in Mbps) - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) + Jitter - Predicted Value (in s) - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) + Latency - Predicted Value (in s) Kanugovi, et al. Expires December 2, 2019 [Page 59] Internet-Draft MAMS May 2019 - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) + Signal Quality - if Delivery Connection Type is LTE, LTE_RSRP Predicted Value (in dBm) - if Delivery Connection Type is LTE, LTE_RSRQ Predicted Value (in dBm) - if Delivery Connection Type is NR, NR_RSRP Predicted Value (in dBm) - if Delivery Connection Type is NR, NR_RSRQ Predicted Value (in dBm) - if Delivery Connection Type is WiFi, WLAN_RSSI Predicted Value (in dBm) - - Likelihoood (in Percentage) - Prediction Validity (Validity Time in s) Appendix C. JSON Specification for MAMS Control Plane MAMS Control plane messages are exchanged between the CCM and the NCM. This section, specifies the format and content of messages in "Java Script Object Notation" (JSON) format. C.1. Protocol Specification: General Processing C.1.1. Notation This document uses JSONString, JSONNumber, and JSONBool to indicate the JSON string, number, and boolean types, respectively. The type JSONValue indicates a JSON value, as specified in Section 3 of [RFC7159]. This document uses an adaptation of the C-style struct notation to define JSON objects. A JSON object consists of name/value pairs. This document refers to each pair as a field. In some context, this document also refers to a field as an attribute. The name of a field/attribute may be referred to as the key. An optional field is enclosed by [ ]. In the definitions, the JSON names of the fields are case sensitive. An array is indicated by two numbers in angle brackets, , where m indicates the minimal number of values and n is the maximum. When this document uses * for n, it means no upper bound. For example, the definition below defines a new type Type4, with three fields named "name1", "name2", and "name3", respectively. The field named "name3" is optional, and the field named "name2" is an array of at least one value. Kanugovi, et al. Expires December 2, 2019 [Page 60] Internet-Draft MAMS May 2019 object { Type1 name1; Type2 name2<1..*>; [Type3 name3;] } Type4; This document uses subtyping to denote that one type is derived from another type. The example below denotes that TypeDerived is derived from TypeBase. TypeDerived includes all fields defined in TypeBase. If TypeBase does not have a field named "name1", TypeDerived will have a new field named "name1". If TypeBase already has a field named "name1" but with a different type, TypeDerived will have a field named "name1" with the type defined in TypeDerived (i.e., Type1 in the example). object { Type1 name1; } TypeDerived : TypeBase; Note that, despite the notation, no standard, machine-readable interface definition or schema is provided in this document. Extension documents may describe these as necessary. C.1.2. Discovery Procedure C.1.2.1. MX Discovery Message This message is the first message sent by CCM to discover the presence of NCM in the network. It contains only the base information as described in Appendix C.2.1 with message_type set as mx_discover. Following is the representation of the message: object { [JSONString MCC_MNC_Tuple;] } MXDiscover : MXBase; C.1.3. System Information Procedure C.1.3.1. MX System Information Message This message is sent by NCM to CCM to inform the endpoints that NCM supports for MAMS functionality. In addition to base information (Appendix C.2.1) it contains following information: a) NCM Connections (described in Appendix C.2.3) Following is the representation of the message: object { Kanugovi, et al. Expires December 2, 2019 [Page 61] Internet-Draft MAMS May 2019 NCMConnections ncm_connections; } MXSystemInfo : MXBase; C.1.4. Capability Exchange Procedure C.1.4.1. MX Capability Request This message is sent by CCM to NCM to indicate the capabilities of the CCM instance available to the NCM indicated in System Info message earlier. In addition to base information (Appendix C.2.1) it contains following information: (a) Features Activation Status: Described in Appendix C.2.5 (b) Number of anchor connections: Number of anchor connection (towards core) supported by the NCM. (c) Anchor Connections: Described in sec Appendix C.2.6 (d) Number of Delivery connections: Number of delivery connection (towards access) supported by the NCM. (e) Delivery Connections: Described in Appendix C.2.7 (f) Convergence Methods: Described in Appendix C.2.9 (g) Adaptation Methods: Described in Appendix C.2.10 Following is the representation of the message: object { FeaturesActive feature_active; JSONNumber num_anchor_connections; AnchorConnections anchor_connections; JSONNumber num_delivery_connections; DeliveryConnections delivery_connections; ConvergenceMethods convergence_methods; AdaptationMethods adaptation_methods } MXCapabilityReq : MXBase; C.1.4.2. MX Capability Response This message is sent by NCM to CCM to indicate the capabilities of the NCM instance and unique session identifier for CCM. In addition to base information (Appendix C.2.1) it contains following information: (a) Features Activation Status: Described in Appendix C.2.5 (b) Number of anchor connections: Number of anchor connection (towards core) supported by the NCM. (c) Anchor Connections: Described in Appendix C.2.6 (d) Number of Delivery connections: Number of delivery connection (towards access) supported by the NCM. Kanugovi, et al. Expires December 2, 2019 [Page 62] Internet-Draft MAMS May 2019 (e) Delivery Connections: Described in Appendix C.2.7 (f) Convergence Methods: Described in Appendix C.2.9 (g) Adaptation Methods: Described in Appendix C.2.10 (h) Unique Session Id: This uniquely identifies the session between CCM and NCM in a network. Described in Appendix C.2.2 Following is the representation of the message: object { FeaturesActive feature_active; JSONNumber num_anchor_connections; AnchorConnections anchor_connections; JSONNumber num_delivery_connections; DeliveryConnections delivery_connections; ConvergenceMethods convergence_methods; AdaptationMethods adaptation_methods UniqueSessionId unique_session_id; } MXCapabilityRsq : MXBase; C.1.4.3. MX Capability Acknowledge This message is sent by CCM to NCM to indicate acceptance of capabilities advertised by NCM in earlier MX Capability Response message. In addition to base information (Appendix C.2.1) it contains following information: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Appendix C.2.2. (b) Capability Acknowledgement: Either Accept or Reject of the capabilities sent by CCM. Can take either "MX_ACCEPT" or "MX_REJECT" as acceptable values. Following is the representation of the message: object { UniqueSessionId unique_session_id; JSONString capability_ack; } MXCapabilityAck : MXBase; C.1.5. User Plane Configuration Procedure C.1.5.1. MX User Plane Configuration Request This message is sent by NCM to CCM to configure the user plane for MAMS. In addition to base information (Appendix C.2.1) it contains following information: Kanugovi, et al. Expires December 2, 2019 [Page 63] Internet-Draft MAMS May 2019 (a) Number of Anchor Connection: Number of anchor connections supported by NCM. (b) Setup of Anchor Connections: Described in Appendix C.2.11. Following is the representation of the message: object { JSONNumber num_anchor_connections; SetupAnchorConns anchor_connections; } MXUPSetupConfigReq : MXBase; C.1.5.2. MX User Plane Configuration Confirmation This message is the confirmation of user plane setup message sent from CCM after successfully configuring the user plane at user equipment. This message contains following information: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Appendix C.2.2. (b) MX Probe Parameters (included if probing is supported) (1) Probe Port: UDP port for accepting probe message. (2) Anchor connection Id: Identifier of the anchor connection to be used for probe function, provided in user plane setup request. (3) MX Configuration Id: For the given anchor connection, which configuration id is to be used for probe, this is present only if provided in the user plane setup request. (c) For each delivery connection following is required: (1) Connection ID: Delivery connection id supported by UE. (2) Client Adaptation Layer Parameters: If UDP adaptation layer is in use then the UDP port to be used at C-MADP side. Following is the representation of the message: object { UniqueSessionId unique_session_id; [ProbeParam probe_param;] JSONNumber num_delivery_conn; ClientParam client_params <1...*>; } MXUPSetupConfigCnf : MXBase; Where ProbeParam is defined as following: object { JSONNumber probe_port; JSONNumber anchor_conn_id; Kanugovi, et al. Expires December 2, 2019 [Page 64] Internet-Draft MAMS May 2019 [JSONNumber mx_configuration_id;] } ProbeParam; Where ClientParam is defined as following: object { JSONNumber connection_id; [AdaptationParam adapt_param;] } ClientParam; Where AdaptationParam is defined as following: object { JSONNumber udp_adapt_port; } AdaptationParam; C.1.6. Reconfiguration Procedure C.1.6.1. Reconfiguration Request This message is sent by CCM to NCM in case of reconfiguration of any the connections from user equipment's side. In addition to base information (Appendix C.2.1) it contains following information: (a) Unique Session Id: Identifier for CCM-NCM association Appendix C.2.2. (b) Reconfiguration Action: Type of reconfiguration action can be one of "setup", "release" or "modify". (c) Connection Id: Connection Id for which the reconfiguration is taking place. (d) IP address: IP address in case of setup and modify type of reconfiguration. (e) SSID: If the connection type is WiFi, in that case the SSID the UE has attached to is contained in this parameter. (f) MTU of connection: MTU of the delivery path that is calculated at the UE for use by NCM to configure fragmentation and concatenation procedures at N-MADP. (g) Connection Status: This parameter informs if the connection is currently "disabled", "enabled" or "connected". Default: "connected". (h) Delivery Node Id: Identity of the node to which the client is attached. ECGI in case of LTE and WiFi AP Id or MAC address in case of WiFi. Following is the representation of the message: object { UniqueSessionId unique_session_id; Kanugovi, et al. Expires December 2, 2019 [Page 65] Internet-Draft MAMS May 2019 JSONString reconf_action; JSONNumber connection_id; JSONString ip_address; JSONString ssid; JSONNumber mtu_size; JSONString connection_status; [JSONSring delivery_node_id;] } MXReconfReq : MXBase; C.1.6.2. Reconfiguration Response This message is sent by NCM to CCM as a confirmation towards reconfiguration requirement after taking the reconfiguration into use and contains only the base information (as defined in Appendix C.2.1). Following is the representation of the message:] object { } MXReconfRsp : MXBase; C.1.7. Path Estimation Procedure C.1.7.1. Path Estimation Request This message is sent by NCM towards CCM to configure the CCM to send path estimation reports. In addition to base information (Appendix C.2.1) it contains following information: (a) Connection Id: Id of the connection for which the path estimation report is required. (b) Init Probe Test Duration: Duration of initial probe test in milliseconds. [TBD: Range of values] (c) Init Probe Test Rate: Initial testing rate in Mega Bits per Second. [TBD: Range of values] (d) Init Probe Size: Size of each packet for initial probe in Bytes. [TBD: Range of values] (e) Init Probe Ack: If an acknowledgement for probe is required. [Possible values: "yes", "no"] (f) Active Probe Frequency: Frequency in milliseconds at which the active probes shall be sent. [TBD: Range of values] (g) Active Probe Size: Size of the active probe in Bytes. [TBD: Range of values] (h) Active Probe Duration: Duration in seconds for which the active probe shall be performed. [TBD. Range of values] (i) Active Probe Ack. If an acknowledgement for probe is required. [Possible values: "yes", "no"] Kanugovi, et al. Expires December 2, 2019 [Page 66] Internet-Draft MAMS May 2019 Following is the representation of the message: object { JSONNumber connection_id; JSONNumber init_probe_test_duration_ms; JSONNumber init_probe_test_rate_Mbps; JSONNumber init_probe_size_bytes; JSONString init_probe_ack_req; JSONNumber active_probe_freq_ms; JSONNumber active_probe_size_bytes; JSONNumber active_probe_duration_sec; JSONString active_probe_ack_req; } MXPathEstReq : MXBase; C.1.7.2. Path Estimation Report This message is sent by CCM to NCM as report to the probe estimation configured by NCM. In addition to base information (Appendix C.2.1) it contains following information: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Appendix C.2.2. (b) Connection Id: Id of the connection for which the path estimation report is required. (c) Init Probe Results: Defined in section Appendix C.2.12. (d) Active Probe Results: Defined in section Appendix C.2.13. Following is the representation of the message: object { JSONNumber connection_id; UniqueSessionId unique_session_id; [InitProbeResults init_probe_results;] [ActiveProbeResults active_probe_results;] } MXPathEstResults : MXBase; C.1.8. Traffic Steering Procedure C.1.8.1. Traffic Steering Request This message is sent by NCM to CCM for enabling traffic steering at delivery side in uplink and downlink configuration. In addition to base information (Appendix C.2.1) it contains following information: (a) Connection id: Anchor connection number for which the traffic steering is getting defined. (b) MX Configuration Id: MX configuration for which the traffic steering is getting defined. Kanugovi, et al. Expires December 2, 2019 [Page 67] Internet-Draft MAMS May 2019 (c) Downlink Delivery: Defined in Appendix C.2.14. (d) Default UL Delivery: The default delivery connection for uplink. All traffic should be delivered on this connection in uplink direction and the TFT filter should be applied only for the traffic mentioned in Uplink Delivery. (e) Uplink Delivery: Defined in Appendix C.2.15. (f) Features Activated: Defined in Appendix C.2.5. Following is the representation of the message: object { JSONNumber connection_id; [JSONNumber mx_configuration_id;] DLDelivery downlink_delivery; JSONNumber default_uplink_delivery; ULDelivery uplink_delivery; FeaturesActive feature_activation; } MXTraffiSteeringReq : MXBase; C.1.8.2. Traffic Steering Response This message is response to Traffic Steering request from CCM to NCM. In addition to base information (Appendix C.2.1) it contains following information: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Appendix C.2.2. (b) Features Activated: Defined in Appendix C.2.5. Following is the representation of the message: object { UniqueSessionId unique_session_id; FeaturesActive feature_activation; } MXTraffiSteeringResp : MXBase; C.1.9. MAMS Application MADP Association C.1.9.1. MAMS Application MADP Association Request This message is sent by CCM to NCM to select MADP instances provided earlier in User Plane Setup Request based on requirement of the applications. In addition to the base information (Appendix C.2.1) it contains following: Kanugovi, et al. Expires December 2, 2019 [Page 68] Internet-Draft MAMS May 2019 (a) Unique Session Id: This uniquely identifies the session between CCM and NCM in a network. Described in Appendix C.2.2, and a list of following MX Application MADP Associations (a) Connection id: Defines the anchor connection number of the MADP instance (b) MX Configuration Id: identify the MX configuration of the MADP instance (c) Traffic Template Uplink: Traffic template as defined in 5.16 to be used in uplink direction. (d) Traffic Template Downlink: Traffic template as defined in 5.16 to be used in downlink direction. Following is the representation of the message: object { UniqueSessionId unique_session_id; MXAppMADPAssoc app_madp_assoc_list <1..*>; } MXAppMADPAssocReq : MXBase; Where each measurement MXAppMADPAssoc is represented by following: object { JSONNumber connection_id; JSONNumber mx_configuration_id TrafficFlowTemplate tft_ul_list <1..*>; TrafficFlowTemplate tft_dl_list <1..*>; } MXAppMADPAssoc; C.1.9.2. MAMS Application MADP Association Response This message is sent by NCM to CCM to confirm the selected MADP instances provided in request message by CCM. In addition to the base information (Appendix C.2.1), it contains information if the request has been successful. Following is the representation of the message: object { JSONBool is_success; } MXAppMADPAssocResp : MXBase; C.1.10. SSID Indication This message is sent by NCM to CCM to indicate the list of allowed SSID which are supported by MAMS entity at the network side. It contains the list of SSIDs. Kanugovi, et al. Expires December 2, 2019 [Page 69] Internet-Draft MAMS May 2019 Each SSID consists of the type of SSID (which can be one of the "SSID", "BSSID" or "HESSID" and the SSID itself. Following is the representation of the message: object { SSID ssid_list<1..*>; } MXSSIDIndication : MXBase; Where each SSID is defined as following: object { JSONString ssid_type; JSONString ssid; } SSID; C.1.11. Measurements C.1.11.1. Measurement Configuration This message is sent from NCM to CCM to configure the period measurement reporting at CCM. The message contains a list of measurement configuration with each element containing following information: (a) Connection Id: Connection id of the delivery connection for which the reporting is being configured. (b) Connection Type: Connection Type for which the reporting is being configured, can be "lte", "wifi", "5g-nr" etc. (c) Measurement Report Configuration: Actual report configuration based on the connection type, as defined in Appendix C.2.17 Following is the representation of the message: object { MeasReportConf measurement_configuration <1..*>; } MXMeasReportConf : MXBase; Where each measurement MeasReportConf is represented by following: object { JSONNumber connection_id; JSONString connection_type; MeasReportConfs meas_rep_conf <1..*>; } MeasReportConf; Kanugovi, et al. Expires December 2, 2019 [Page 70] Internet-Draft MAMS May 2019 C.1.11.2. Measurement Report This message is periodically sent by CCM to NCM after measurement configuration. In addition to the base information it contains following information: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Appendix C.2.2. (b) Measurement report for each delivery connection is measured by the client device as defined in Appendix C.2.18. Following is the representation of the message: object { UniqueSessionId unique_session_id; MXMeasRep measurment_reports <1..*>; } MXMeasurementReport : MXBase; C.1.12. Keep Alive C.1.12.1. Keep Alive Request A Keep Alive Request message can be sent from either NCM or CCM on expiry of MAMS_KEEP_ALIVE timer or a handover event. This request shall be responded by the peer with Keep Alive Response. In case of no response from peer the MAMS connection shall be assumed to be broken and new connection shall be established again by CCM by sending MX Discover messages. In addition to the base information it cantains following information: (a) Keep Alive Reason: Reason for sending this message, can be "Timeout" or "Handover". (b) Unique Session Id: Identifier for CCM-NCM association Appendix C.2.2. (c) Connection Id: Connection id for which handover is detected, in case the reason is "Handover". (d) Delivery Node Id: The target delivery node id (ECGI or WiFi Access Point Id/MAC) to which the handover is executed. Following is the representation of the message: object { JSONString keep_alive_reason; UniqueSessionId unique_session_id; JSONNumber connection_id; JSONString delivery_node_id; Kanugovi, et al. Expires December 2, 2019 [Page 71] Internet-Draft MAMS May 2019 } MXKeepAliveReq : MXBase; C.1.12.2. Keep Alive Response On receiving Keep Alive Request from peer, NCM/CCM shall immediately respond with a Keep Alive Response message on the same delivery path from where the request arrived. In addition to base information it contains the unique session identifier for the CCM-NCM association (defined in Appendix C.2.2) Following is the representation of the message: object { UniqueSessionId unique_session_id; } MXKeepAliveResp : MXBase; C.1.13. Session Termination Procedure C.1.13.1. Session Terminate Request In the event where NCM or CCM can no longer handle MAMS for any reason then it can send MX session termination request to the peer. In addition to base information it contains Unique Session Id and reason for termination, this can be "MX_NORMAL_RELEASE", "MX_NO_RESPONSE" or "INTERNAL_ERROR". Following is the representation of the message: object { UniqueSessionId unique_session_id; JSONString reason; } MXSessionTerminationReq : MXBase; C.1.13.2. Session Terminate Response On reception of MX session termination request from peer, NCM/CCM shall respond with MX Session Termination Response on the same delivery path where the request arrived and clean the MAMS related resources and settings. CCM shall re-initiate a new session with MX Discover messages again. Following is the representation of the message: object { UniqueSessionId unique_session_id; } MXSessionTerminationResp : MXBase; Kanugovi, et al. Expires December 2, 2019 [Page 72] Internet-Draft MAMS May 2019 C.1.14. Network Analytics C.1.14.1. MX Network Analytics Request This message is sent by CCM to NCM to request for parameters like bandwidth, jitter, latency and signal quality predicted by network analytics function. In addition to the base information it contains following parameter: (a) Unique Session Id: Same identifier as provided in MX Capability RSP. Described in Appendix C.2.2. (b) Parameter List: List of parameters which the CCM is interested in namely one or more of, "bandwidth", "jitter", "latency" and "signal_quality". Following is the representation of the message: object { UniqueSessionId unique_session_id; JSONString params<1..*>; } MXNetAnalyticsReq : MXBase; Where the params object can take one or more of the following values: "bandwidth" "jitter" "latency" "signal_quality" C.1.14.2. MX Network Analytics Response This message is sent by NCM to CCM in response to the analytics request. For each delivery connection that the client has NCM reports the requested parameter predictions and their respective likelihood (between 1-100). In addition to the base information it contains following parameters: (a) Number of delivery connections: The number of delivery connections configured for the client currently. (b) For each delivery connection following is provided: (a) Connection Id: Connection ID of the delivery connection for which the parameters are being predicted. (b) Connection Type: Type of connection, can be "Wi-Fi, "5G NR", "Multi-Fire" and "LTE". (c) List of Parameters for which Prediction is requested, where each of the predicted parameters consists of following: Kanugovi, et al. Expires December 2, 2019 [Page 73] Internet-Draft MAMS May 2019 (a) Parameter name: Name of the parameter being predicted. Can be one of "bandwidth", "jitter", "latency", "signal_quality". (b) Additional Parameter: If Parameter name is "signal_quality", then this qualifies the quality parameter like "lte_rsrp", "lte_rsrq", "nr_rsrp", "nr_rsrq", or "wifi_rssi". (c) Predicted value: Provides the predicted value of the parameter and, if applicable, the additional parameter. (d) Likelihood: Provides a stochastic likelihood of about the predicted value. (e) Validity Time: the time horizon until which the predictions are valid. Following is the representation of the message: object { MXAnalyticsList param_list<1..*>>; } MXNetAnalyticsResp : MXBase; Where MXAnalyticsList is defined as following:: object{ JSONNumber connection_id; JSONString connection_type; ParamPredictions predictions <1..*>; } MXAnalyticsList; Where each ParamPredictions is defined as: object{ JSONString param_name; [JSONString additional_param;] JSONNumber prediction; JSONNumber likelihood; JSONNumber validity_time; } ParamPredictions; C.2. Protocol Specification: Data Types C.2.1. MXBase This is the base information that every message between CCM and NCM exchanges shall have as mandatory information. It contains following information: (a) Version: Version of MAMS in used Kanugovi, et al. Expires December 2, 2019 [Page 74] Internet-Draft MAMS May 2019 (b) Message Type: Message type being sent with following as valid values: (a) "mx_discover" (b) "mx_system_info" (c) "mx_capability_req" (d) "mx_capability_resp" (e) mx_capability_ack" (f) "mx_up_setup_conf_req" (g) "mx_up_setup_cnf" (h) "mx_reconf_req" (i) "mx_reconf_rsp" (j) "mx_path_est_req" (k) "mx_path_est_results" (l) "mx_traffic_steering_req" (m) "mx_traffic_steering_rsp" (n) "mx_ssid_indication" (o) "mx_keep_alive_req" (p) "mx_keep_alive_rsp" (q) "mx_measurement_conf" (r) "mx_measurement_report" (s) "mx_session_termination_req" (t) "mx_session_termination_resp" (u) "mx_app_madp_assoc_req" (v) "mx_app_madp_assoc_resp" (w) "mx_network_analytics_req" (x) "mx_network_analytics_resp" (c) Sequence Number: Sequence number to uniquely identify a transaction of message exchange, e.g. MX Capability REQ/RSP/ ACK. Following is the representation of this data type: object { JSONString version; JSONString message_type; JSONNumber sequence_num; } MXBase; C.2.2. Unique Session Id This data type defines the unique session id between a CCM and NCM entity, it contains a NCM id which is unique in the network and a session id allocated by NCM for that session. On reception, of discovery message if the session is existing then the old session id is returned in System Info message otherwise NCM allocates a new session id to the CCM and sends in response with System Info message. Kanugovi, et al. Expires December 2, 2019 [Page 75] Internet-Draft MAMS May 2019 Following is the representation of this data type: object { JSONNumber ncm_id; JSONNumber session_id; } UniqueSessionId; C.2.3. NCM Connections This data type defines the connection available at NCM for MAMS connectivity towards the User Equipment. It contains a list of NCM connections available where each connection has following information: (a) Connection Information: As defined in Appendix C.2.4 (b) NCM End Point information: This contains IP Address and Port exposed by NCM end point for CCM. Following is the representation of this data type: object { NCMConnection items<1..*>; } NCMConnections; where NCMConnection is defined as: object { NCMEndPoint ncm_end_point; } NCMConnection : ConnectionInfo; where NCMEndPoint is defined as: object { JSONString ip_address; JSONNumber port; } NCMEndPoint; C.2.4. Connection Information This data type provides the mapping of connection Id and connection type. It contains following information: (a) Connection Id: Number indicating the connection can be 0,1,2 and 3. (b) Connection type: Type of connect can be "Wi-Fi, "5G NR", "Multi- Fire" and "LTE". Kanugovi, et al. Expires December 2, 2019 [Page 76] Internet-Draft MAMS May 2019 The two are considered a mapping like 0-"Wi-Fi", 1-"5G NR", 2-"Multi- Fire" and 3-"LTE". Following is the representation of this data type: object { JSONNumber connection_id; JSONString connection_type; } ConnectionInfo; C.2.5. Features Activation Status This data type provides the list of all features with their activation status. Each feature status contains following: (a) Feature Name: Name of the feature can be one of the following: (a) "lossless_switching" (b) "fragmentation" (c) "concatenation" (d) "uplink_aggregation" (e) "downlink_aggregation" (f) "measurement" (b) Active status: Activation status of the feature, "true" means feature is active, "false" means feature is inactive. Following is the representation of this data type: object { FeatureInfo items<1..*>; } FeaturesActive; where FeatureInfo is defined as: object { JSONString feature_name; JSONBool active; } FeatureInfo; C.2.6. Anchor Connections This data type contains the list of Connection Information (Appendix C.2.4) that are supported at anchor (core) side. Following is the representation of this data type: object { ConnectionInfo items<1..*>; Kanugovi, et al. Expires December 2, 2019 [Page 77] Internet-Draft MAMS May 2019 } AnchorConnections; C.2.7. Delivery Connections This data type contains the list of Connection Information (Appendix C.2.4) that are supported at delivery (access) side. Following is the representation of this data type: object { ConnectionInfo items<1..*>; } DeliveryConnections; C.2.8. Method Support This data type provides the support for a particular convergence or adaptation method. It consists of following: (a) Method: Name of the method. (b) Supported: Whether the method named above is supported or not. Possible values are "true" and "false". Following is the representation of this data type: object { JSONString method; JSONBool supported; } MethodSupport; C.2.9. Convergence Methods This data type contains the list of all convergence methods and their support status. Convergence Methods possible are: "GMA" "MPTCP_Proxy" "GRE_Aggregation_Proxy" "MPQUIC" Following is the representation of this data type: object { MethodSupport items<1..*>; } ConvergenceMethods; Kanugovi, et al. Expires December 2, 2019 [Page 78] Internet-Draft MAMS May 2019 C.2.10. Adaptation Methods This data type contains the list of all convergence methods and their support status. Converge Methods possible are: "UDP_without_DTLS" "UDP_with_DTLS" "IPSec" "Client_NAT" Following is the representation of this data type: object { MethodSupport items<1..*>; } AdaptationMethods; C.2.11. Setup of Anchor Connections This data type defines the setup configuration for each of the anchor connection that is required at the user equipment side. It contains following information in addition to the connection id and type of the anchor connection: (a) Number of Active MX configurations: If more than one active configurations are present for this anchor then this identifies the number of such connections (b) For each active configuration following convergence parameters are provided: (a) MX Configuration Identifier: This identifier is present in case there are multiple active configuration and identifies the configuration for this MADP instance id. (b) Convergence Method: Converge method selected, has to be one of the supported convergence method as listed in section Appendix C.2.9. (c) Convergence Method Parameters: Described in section Appendix C.2.11.1 (d) Number of Delivery Connections: Number of delivery connections (access side) that are supported for this anchor connection. (e) Setup Delivery Connections: Described in section Appendix C.2.11.2. Following is the representation of this data type: object { SetupAnchorConn items<1..*>; } SetupAnchorConns; Kanugovi, et al. Expires December 2, 2019 [Page 79] Internet-Draft MAMS May 2019 Where each Anchor connection configuration is defined as following: object { [JSONNumber num_active_mx_conf;] ConvergenceConfig convergence_config } SetupAnchorConn : ConnectionInfo; where each Convergence configuration is defined as following: object { [JSONNumber mx_configuration_id;] JSONString convergence_method; ConvergenceMethodParam convergence_method_params; JSONNumber num_delivery_connections; SetupDeliveryConns delivery_connections; } ConvergenceConfig; C.2.11.1. Convergence Method Parameters This data type defines the parameters used for convergence method and contains following: (a) Proxy IP: IP Address of proxy that is provided by Convergence Method selected. (b) Proxy Port: Port of the proxy that is provided by Convergence Method selected. Following in the representation of this data type: object { JSONString proxy_ip; JSONString proxy_port; JSONString client_key; } ConvergenceMethodParam; C.2.11.2. Setup Delivery Connections This is the list of delivery connections and their parameters to be configured at the user equipment. Each delivery connection defined by its connection information (Appendix C.2.4) contains optionally following: (a) Adaptation Method: Selected adaptation method name, this shall be one of the names as listed in Appendix C.2.10. (b) Adaptation Method Parameters: Depending on the adaptation method one or more of the following parameters shall be provided. (a) Tunnel IP address Kanugovi, et al. Expires December 2, 2019 [Page 80] Internet-Draft MAMS May 2019 (b) Tunnel Port number (c) Shared Secret (d) MX header optimization: If the adaptation method is UDP_and convergence is GMA then this flag represents if the checksum field and the length field in the IP header of a MX PDU should be recalculated or not by the MX convergence sublayer. The possible values are "true" and "false". If it is "true", both fields remain unchanged; otherwise, both fields should be recalculated. If this field is not present then the default of "false" should be considered. Following in the representation of this data type: object { SetupDeliveryConn items<1..*>; } SetupDeliveryConns; where each Setup Delivery Connection consists of following: object { [JSONSting adaptation_method;] [AdaptationMethodParam adaptation_method_param;] } SetupDeliveryConn : ConnectionInfo; where Adaptation Method Param is defined as: object { JSONString tunnel_ip_addr; JSONString tunnel_end_port; JSONString shared_secret; [JSONBool mx_header_optimization;] } AdaptationMethodParam; C.2.12. Init Probe Results This data type defines the results of init probe request made by NCM. It consists of following information: (a) Lost Probes: Percentage or probes lost. (b) Prode Delay: Average delay of probe message in microseconds. (c) Probe Rate: Probe rate achieved in Mega Bits per second. Following in the representation of this data type: object { JSONNumber lost_probes_percentage; JSONNumber probe_rate_Mbps; } InitProbeResults; Kanugovi, et al. Expires December 2, 2019 [Page 81] Internet-Draft MAMS May 2019 C.2.13. Active Probe Results This data type defines the results of init probe request made by NCM. It consists of following information: (a) Average Probe Throughput: Average active probe throughput achieved in Mega Bits per second. Following in the representation of this data type: object { JSONNumber avg_tput_last_probe_duration_Mbps; } ActiveProbeResults; C.2.14. Downlink Delivery This data type defines the list of connections which are enabled in delivery side to be used in downlink direction. Following in the representation of this data type: object { JSONNumber connection_id <1..*>; } DLDelivery; C.2.15. Uplink Delivery This data type defines the list of connections and parameters enabled for deliver side to be used in uplink direction. The uplink delivery consists of multiple uplink delivery entities, where each entity consists of a traffic flow template (TFT) Appendix C.2.16 and list of connection ids in uplink where traffic qualifying for such traffic flow template can be redirected. Following in the representation of this data type: object { ULDeliveryEntity ul_del <1..*>; } ULDelivery; Where each uplink delivery entity consists of following data type: object { TrafficFlowTemplate ul_tft <1..*>; JSONNumber connection_id <1..*>; } ULDeliveryEntity; Kanugovi, et al. Expires December 2, 2019 [Page 82] Internet-Draft MAMS May 2019 C.2.16. Traffic Flow Template Traffic flow template follows in general guidelines specified in 3GPP TS 23.060. Traffic flow template in MAMS consists of one or more of following: (a) Remote Address and Mask: IP address and subnet for remote addresses represented in CIDR notation. Default: "0.0.0.0/0". (b) Local Address and Mask: IP address and subnet for local addresses represented in CIDR notation. Default: "0.0.0.0/0" (c) Protocol Type: IP protocol number of the payload being carried by IP packet. e.g. UDP, TCP etc. Default: 255. (d) Local Port Range: Range of ports for local ports for which the flow template is applicable. Default: Start=0, End=65535. (e) Remote Port Range: Range of ports for remote ports for which the flow template is applicable. Default: Start=0, End=65535. (f) Traffic Class: Represented by Type of Service in IPv4 and Traffic Class in IPv6. Default: 255 (g) Flow Label: Flow label for IPv6, applicable only for IPv6 protocol type. Default: 0. Following in the representation of this data type: object { JSONString remote_addr_mask; JSONString local_addr_mask; JSONNumber protocol_type; PortRange local_port_range; PortRange remote_port_range; JSONNumber traffic_class; JSONNumber flow_label; } TrafficFlowTemplate; Where the port range is defined as following: object { JSONNumber start; JSONNumber end; } PortRange; C.2.17. Measurement Report Configuration This data type defines the configuration done by NCM towards CCM for reporting measurement events. (a) Measurement Report Parameter: Parameter which shall be measured and reported. This is dependent on the connection type: Kanugovi, et al. Expires December 2, 2019 [Page 83] Internet-Draft MAMS May 2019 (a) For connection type "wifi" allowed measurement parameters are "WLAN_RSSI", "WLAN_LOAD", "UL_TPUT", "DL_TPUT", "EST_UL_TPUT" and "EST_DL_TPUT". (b) For connection type "lte" allowed measurement parameters are "LTE_RSRP", "LTE_RSRQ", "UL_TPUT" and "DL_TPUT". (c) For connection type "5g-nr" allowed measurement parameters are "NR_RSRP", "NR_RSRQ", "UL_TPUT" and "DL_TPUT". (b) Threshold: High and Low threshold for reporting. (c) Period: Period for reporting in milliseconds. Following is the representation of this data type: object { JSONString meas_rep_param; Threshold meas_threshold; JSONNumber meas_period; } MeasReportConfs; Where Threshold is defined as following: object { JSONNumber high; JSONNumber low; } Threshold; C.2.18. Measurement Report This data type defines the measurements reported by CCM for each access network measured. This type contains the connection information, delivery node id which identifies the cell (ECGI) or the WiFI Access Point Id or MAC address (or equivalent identifier in other technologies) and the actual measurement performed by CCM in the last measurement period. Following is the representation of this data type: object { JSONNumber connection_id; JSONString connection_type; JSONString delivery_node_id; Measurement measurements <1..*>; }MXMeasRep; Where Measurement is defined as the key value pair of measurement type and value. The exact type and value are defined on a per delivery type and defined in Appendix C.2.17. object{ Kanugovi, et al. Expires December 2, 2019 [Page 84] Internet-Draft MAMS May 2019 JSONString measurement_type; JSONNumber measurement_value; } Measurement; C.3. Schemas in JSON C.3.1. MX Base Schema Kanugovi, et al. Expires December 2, 2019 [Page 85] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": { "message_type_def": { "enum": [ "mx_discover", "mx_system_info", "mx_capability_req", "mx_capability_resp", "mx_capability_ack", "mx_up_setup_conf_req", "mx_up_setup_cnf", "mx_reconf_req", "mx_reconf_rsp", "mx_path_est_req", "mx_path_est_results", "mx_traffic_steering_req", "mx_traffic_steering_rsp", "mx_ssid_indication", "mx_keep_alive_req", "mx_keep_alive_rsp", "mx_measurement_conf", "mx_measurement_report", "mx_session_termination_req", "mx_session_termination_resp", "mx_app_madp_assoc_req", "mx_app_madp_assoc_resp", "mx_network_analytics_req", "mx_network_analytics_resp" ], "type": "string" }, "sequence_num_def": { "minimum": 1, "type": "integer" }, "version_def": { "type": "string" } }, "id": "http://www.ietf.org/mams/mx_base_def.json" } C.3.2. MX Definitions { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": { Kanugovi, et al. Expires December 2, 2019 [Page 86] Internet-Draft MAMS May 2019 "adapt_method": { "enum": [ "UDP_without_DTLS", "UDP_with_DTLS", "IPSec", "Client_NAT" ], "type": "string" }, "conv_method": { "enum": [ "GMA", "MPTCP_Proxy", "GRE_Aggregation_Proxy", "MPQUIC" ], "type": "string" }, "supported": { "type": "boolean" }, "active": { "type": "boolean" }, "connection_id": { "type": "integer" }, "feature_name": { "enum": [ "lossless_switching", "fragmentation", "concatenation", "uplink_aggregation", "downlink_aggregation", "measurement" ], "type": "string" }, "connection_type": { "enum": [ "wi-fi", "5g-nr", "multi-fire", "lte" ], "type": "string" }, "ip_address": { Kanugovi, et al. Expires December 2, 2019 [Page 87] Internet-Draft MAMS May 2019 "type": "string" }, "port": { "maximum": 65535, "minimum": 1, "type": "integer" }, "adaptation_method": { "allOf" : [ { "$ref": "#/definitions/adapt_method" }, { "$ref": "#/definitions/supported" } ] }, "connection": { "allOf" : [ { "$ref": "#/definitions/connection_id" }, { "$ref": "#/definitions/connection_type" } ] }, "convergence_method": { "allOf": [ { "$ref": "#/definitions/conv_method" }, { "$ref": "#/definitions/supported" } ] }, "feature_status": { "allOf": [ { "$ref": "#/definitions/feature_name" }, { "$ref": "#/definitions/active" } ] }, "ncm_end_point": { "allOf" : [ { "$ref" : "#/definitions/ip_address" }, { "$ref" : "#/definitions/port" } ] }, "capability_acknowledgement" : { "enum" : [ "MX_ACCEPT", "MX_REJECT" ], "type" : "string" }, "threshold" : { "high" : { "type" : "integer" }, Kanugovi, et al. Expires December 2, 2019 [Page 88] Internet-Draft MAMS May 2019 "low" : { "type" : "integer" }, "type" : "object" }, "meas_report_param" : { "enum" : [ "WLAN_RSSI", "WLAN_LOAD", "LTE_RSRP", "LTE_RSRQ", "UL_TPUT", "DL_TPUT", "EST_UL_TPUT", "EST_DL_TPUT", "NR_RSRP", "NR_RSRQ", ], "type" : "string" }, "meas_report_conf" : { "meas_rep_param" : { "$ref" : "#definitions/meas_report_param" }, "meas_threshold" : { "$ref" : "#definitions/threshold" }, "meas_period_ms" : { "type" : "integer" }, "type" : "object" }, "ssid_types" : { "enum" : [ "ssid", "bssid", "hessid" ], "type" : "string" }, "ip_addr_mask" : { "type" : "string", "default" : "0.0.0.0/0" }, "port_range" : { "start" : { "type" : "integer", "default" : 0 Kanugovi, et al. Expires December 2, 2019 [Page 89] Internet-Draft MAMS May 2019 }, "end" : { "type" : "integer", "default" : 65535 } }, "traffic_flow_template" : { "remote_addr_mask" : { "$ref" : "#definitions/ip_addr_mask" }, "local_addr_mask" : { "$ref" : "#definitions/ip_addr_mask" }, "protocol_type" : { "type" : "integer", "minimum" : 0, "maximum" : 255 }, "local_port_range" : { "$ref" : "#definitions/port_range" }, "remote_port_range" : { "$ref" : "#definitions/port_range" }, "traffic_class" : { "type" : "integer", "default" : 255 }, "flow_label" : { "type" : "integer", "default" : 0 } }, "delivery_node_id" : { "type" : "string" }, "unique_session_id" : { "type" : "object", "ncm_id" : { "type" : "integer" }, "session_id" : { "type" : "integer" } }, "keep_alive_reason" : { "enum" : [ "Timeout", "Handover" ], "type" : "string" }, "connection_status" : { "enum" : [ "disabled", "enabled", Kanugovi, et al. Expires December 2, 2019 [Page 90] Internet-Draft MAMS May 2019 "connected" ], "type" : "string", "default" : "connected" }, "adaptation_param" : { "udp_adapt_port" : { "type" : "integer" } }, "probe_param" : { "probe_port" : { "type" : "integer" }, "anchor_conn_id" : { "type" : "integer" }, "mx_configuration_id" : { "type" : "integer" }, }, "client_param" : { "connection_id" : { "type" : "integer" }, "adapt_param" : { "type" : {"$ref" : "#definitions/adaptation_param" } } } }, "adapt_param": { "tunnel_ip_addr": { "type": "string" }, "tunnel_end_port": { "type": "integer" }, "shared_secret": { "type": "string" }, "mx_header_optimization": { "type": "boolean", "default": false } }, "delivery_connection": { "connection_id": { "$ref": "#definitions/connection_id" Kanugovi, et al. Expires December 2, 2019 [Page 91] Internet-Draft MAMS May 2019 }, "connection_type": { "$ref": "#definitions/connection_type" }, "adaptation_method": { "$ref": "#definitions/adapt_method" }, "adaptation_method_param": { "$ref": "#definitions/adapt_param" } }, "app_madp_assoc": { "anchor_conn_id" : { "type" : "integer" }, "mx_configuration_id" : { "type" : "integer" } "ul_tft_list": { "items": { "$ref": "#definitions/traffic_flow_template" }, "type": "array" }, "dl_tft_list": { "items": { "$ref": "#definitions/traffic_flow_template" }, "type": "array" } } "predict_param_name": { "enum": [ "validity time", "bandwidth", "jitter", "latency", "signal_quality" ], "type": "string" }, "predict_add_param_name": { "enum": [ "WLAN_RSSI", "WLAN_LOAD", "LTE_RSRP", "LTE_RSRQ", Kanugovi, et al. Expires December 2, 2019 [Page 92] Internet-Draft MAMS May 2019 "NR_RSRP", "NR_RSRQ" ], "type": "string" } }, "id": "http://www.ietf.org/mams/definitions.json" } C.3.3. MX Discover { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_discover.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"} }, "type": "object" } C.3.4. MX System Update Kanugovi, et al. Expires December 2, 2019 [Page 93] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_system_info.json", "properties": { "message_type": { "$ref": "mx_base_def.json#/message_type_def" }, "sequence_num": { "$ref": "mx_base_def.json#/sequence_num_def" }, "version": { "$ref": "mx_base_def.json#/version_def" }, "ncm_connections": { "type": "array", "items": [ { "$ref": "definitions.json#/connection" }, { "$ref": "definitions.json#/ncm_end_point" } ] } }, "type": "object" } C.3.5. MX Capability Request Kanugovi, et al. Expires December 2, 2019 [Page 94] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_capability_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "adaptation_methods": { "items": { "$ref" : "definitions.json#/adaptation_method"}, "type": "array" }, "anchor_connections": { "items": { "$ref" : "definitions.json#/connection"}, "type": "array" }, "convergence_methods": { "items": { "$ref" : "definitions.json#/convergence_method"}, "type": "array" }, "delivery_connections": { "items": { "$ref" : "definitions.json#/connection"}, "type": "array" }, "feature_active": { "items": { "$ref" : "definitions.json#/feature_status"}, "type": "array" }, "num_anchor_connections": { "type": "integer" }, "num_delivery_connections": { "type": "integer" } }, "type": "object" } C.3.6. MX Capability Response Kanugovi, et al. Expires December 2, 2019 [Page 95] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_capability_resp.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "adaptation_methods": { "items": { "$ref" : "definitions.json#/adaptation_method" }, "type": "array" }, "anchor_connections": { "items": { "$ref" : "definitions.json#/connection"}, "type": "array" }, "convergence_methods": { "items": { "$ref" : "definitions.json#/convergence_method" }, "type": "array" }, "delivery_connections": { "items": { "$ref" : "definitions.json#/connection"}, "type": "array" }, "feature_active": { "items": { "$ref" : "definitions.json#/feature_status"}, "type": "array" }, "num_anchor_connections": { "type": "integer" }, "num_delivery_connections": { "type": "integer" }, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" } }, "type": "object" } C.3.7. MX Capability Ack Kanugovi, et al. Expires December 2, 2019 [Page 96] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_capability_ack.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "capability_ack": {"$ref" : "definitions.json#/capability_acknowledgement"} }, "type": "object" } C.3.8. MX Reconfiguration Request Kanugovi, et al. Expires December 2, 2019 [Page 97] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_reconf_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "connection_id" : {"$ref" : "definitions.json#/connection_id" }, "ip_address": {"$ref" : "definitions.json#/ip_address" }, "mtu_size": { "maximum" : 65535, "minimum": 1, "type": "integer" }, "ssid" : { "type" : "string" }, "reconf_action": { "enum": [ "release", "setup", "update" ], "id": "/properties/reconf_action", "type": "string" }, "connection_status" : {"$ref" : "definitions.json#/connection_status"}, "delivery_node_id" : {"$ref": "definitions.json#/delivery_node_id"} }, "type": "object" } C.3.9. MX Reconfiguration Response Kanugovi, et al. Expires December 2, 2019 [Page 98] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_reconf_rsp.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"} }, "type": "object" } C.3.10. MX UP Setup Configuration { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "definitions": { "convergence_configuration" : { "mx_configuration_id": { "type" : "integer"}, "convergence_method": { "$ref" : "definitions.json#/conv_method" }, "convergence_method_params": { "properties": { "proxy_ip": { "$ref" : "definitions.json#/ip_address" }, "proxy_port": {"$ref" : "definitions.json#/port" }, "client_key": {"$ref" : "definitions.json#/client_key" } }, "type": "object" }, "num_delivery_connections": { "type": "integer" }, "delivery_connections": { "items":{ "$ref" : "definitions.json#/delivery_connection" }, "type": "array" } } }, "id": "http://www.ietf.org/mams/mx_up_setup_conf_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "num_anchor_connections": { "type": "integer" }, "anchor_connections": { Kanugovi, et al. Expires December 2, 2019 [Page 99] Internet-Draft MAMS May 2019 "items": { "properties": { "connection_id": { "$ref" : "definitions.json#/connection_id" }, "connection_type": { "$ref" : "definitions.json#/connection_type" }, "num_active_mx_conf" : { "type" : "integer" }, "convergence_config" : { "items":{ "$ref" : "definitions/convergence_configuration" }, "type" : "array" } }, "type": "object" }, "type": "array" } }, "type": "object" } C.3.11. MX UP Setup Confirmation { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_up_setup_cnf.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "probe_param" : { "$ref": "definitions.json#/probe_param" }, "num_delivery_conn" : { "type" : "integer" }, "client_params" : { "type" : "array", "items" : [ {"$ref": "definitions.json#/client_param"} ] } }, "type": "object" } Kanugovi, et al. Expires December 2, 2019 [Page 100] Internet-Draft MAMS May 2019 C.3.12. MX Traffic Steering Request { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": { "conn_list" : { "items" : { "$ref" : "definitions.json#/connection_id" }, "type": "array" }, "ul_delivery" : { "ul_tft" : { "$ref" : "definitions.json#/traffic_flow_template"}, "connection_list" : { "$ref" : "#definitions/conn_list" } } }, "id": "http://www.ietf.org/mams/mx_traffic_steering_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "connection_id": {"$ref" : "definitions.json#/connection_id" }, "mx_configuration_id": { "type" : "integer"}, "downlink_delivery": { "items": { "$ref" : "definitions.json#/connection_id" }, "type": "array" }, "feature_activation": { "items": {"$ref" : "definitions.json#/feature_status" }, "type": "array" }, "default_uplink_delivery": { "type": "integer" }, "uplink_delivery": { "items": { "$ref" : "#definitions/ul_delivery" }, "type": "array" } }, "type": "object" } C.3.13. MX Traffic Steering Response Kanugovi, et al. Expires December 2, 2019 [Page 101] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://example.com/example.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "feature_activation": { "items": {"$ref" : "definitions.json#/feature_status" }, "type": "array" } }, "type": "object" } C.3.14. MX Application MADP Association Request { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://example.com/example.json", "properties": { "message_type": { "$ref": "mx_base_def.json#/message_type_def" }, "sequence_num": { "$ref": "mx_base_def.json#/sequence_num_def" }, "version": { "$ref": "mx_base_def.json#/version_def" }, "unique_session_id": { "$ref": "definitions.json#/unique_session_id" }, "app_madp_assoc_list": { "items": { "$ref": "definitions.json#/app_madp_assoc" }, "type": "array" } }, "type": "object" } Kanugovi, et al. Expires December 2, 2019 [Page 102] Internet-Draft MAMS May 2019 C.3.15. MX Application MADP Association Response { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://example.com/example.json", "properties": { "message_type": { "$ref": "mx_base_def.json#/message_type_def" }, "sequence_num": { "$ref": "mx_base_def.json#/sequence_num_def" }, "version": { "$ref": "mx_base_def.json#/version_def" }, "unique_session_id": { "$ref": "definitions.json#/unique_session_id" }, "is_success": { "type": "boolean" } }, "type": "object" } C.3.16. MX Path Estimation Request { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_path_est_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "active_probe_ack_req": { "enum": [ "no", "yes" ], "type": "string" }, "active_probe_freq_ms": { "maximum" : 10000, "minimum": 100, "type": "integer" Kanugovi, et al. Expires December 2, 2019 [Page 103] Internet-Draft MAMS May 2019 }, "active_probe_size_bytes": { "maximum": 1500, "minimum": 100, "type": "integer" }, "active_probe_duration_sec" : { "maximum" : 100, "minimum" : 10, "type" : "integer" }, "connection_id": { "$ref" : "definitions#/connection_id" }, "init_probe_ack_req": { "enum": [ "no", "yes" ], "type": "string" }, "init_probe_size_bytes": { "maximum": 1500, "minimum": 100, "type": "integer" }, "init_probe_test_duration_ms": { "maximum": 10000, "minimum": 100, "type": "integer" }, "init_probe_test_rate_Mbps": { "maximum": 100, "minimum": 1, "type": "integer" } }, "type": "object" } C.3.17. MX Path Estimation Report Kanugovi, et al. Expires December 2, 2019 [Page 104] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_path_est_results.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "active_probe_results": { "properties": { "avg_tput_last_probe_duration_Mbps": { "maximum":100, "minimum": 1, "type": "number" } }, "type": "object" }, "connection_id": { "$ref" : "definitions.json#/connection_id" }, "init_probe_results": { "properties": { "lost_probes_percentage": { "maximum": 100, "minimum": 1, "type": "integer" }, "probe_rate_Mbps": { "maximum": 100, "minimum": 1, "type": "number" } }, "type": "object" } }, "type": "object" } C.3.18. MX SSID Indication Kanugovi, et al. Expires December 2, 2019 [Page 105] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_ssid_indication.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "ssid_list": { "items": { "properties" : { "ssid_type": { "$ref" : "definitions.json#/ssid_types" }, "ssid_id" : { "type" : "integer" } } }, "type": "array" } }, "type": "object" } C.3.19. MX Measurements Configuration Kanugovi, et al. Expires December 2, 2019 [Page 106] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "definitions" : { "meas_conf" : { "connection_id" : { "$ref" : "definitions.json#/connection_id" }, "connection_type" : { "$ref" : "definitions.json#/connection_type" }, "meas_rep_conf" : { "items" : { "$ref" : "definitions.json#/meas_report_conf" }, "type" : "array" } } }, "id": "http://www.ietf.org/mams/mx_measurement_conf.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "measurement_configuration" : { "items" : {"$ref" : "#definitions/meas_conf" }, "type" : "array" } }, "type": "object" } C.3.20. MX Measurements Report Kanugovi, et al. Expires December 2, 2019 [Page 107] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "definitions": {}, "id": "http://www.ietf.org/mams/mx_measurement_report.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "measurment_reports": { "items": { "properties": { "connection_id": { "$ref" : "definitions.json#/connection_id" }, "connection_type" : { "$ref" : "definitions.json#/connection_type" }, "delivery_node_id" : { "$ref" : "definitions.json#/delivery_node_id" }, "measurements": { "items": { "properties": { "measurement_type": { "$ref" : "definitions.json#/meas_report_param" }, "measurement_value": { "type": "integer" } }, "type": "object" }, "type": "array" } }, "type": "object" }, "type": "array" } }, "type": "object" } Kanugovi, et al. Expires December 2, 2019 [Page 108] Internet-Draft MAMS May 2019 C.3.21. MX Keep Alive Request { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_keep_alive_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "keep_alive_reason" : {"$ref": "definitions.json#/keep_alive_reason"}, "unique_session_id" : {"$ref": "definitions.json#/unique_session_id"}, "connection_id" : {"$ref": "definitions.json#/connection_id"}, "delivery_node_id" : {"$ref": "definitions.json#/connection_id"} }, "type": "object" } C.3.22. MX Keep Alive Response { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_keep_alive_rsp.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : {"$ref": "definitions.json#/unique_session_id"} }, "type": "object" } C.3.23. MX Session Termination Request Kanugovi, et al. Expires December 2, 2019 [Page 109] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_keep_alive_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "reason" : { "enum" : [ "MX_NORMAL_RELEASE", "MX_NO_RESPONSE", "INTERNAL_ERROR" ], "type" : "string" } }, "type": "object" } C.3.24. MX Session Termination Response { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_session_termination_resp.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" } }, "type": "object" } C.3.25. MX Network Analytics Request Kanugovi, et al. Expires December 2, 2019 [Page 110] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "id": "http://www.ietf.org/mams/mx_network_analytics_req.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "unique_session_id" : { "$ref": "definitions.json#/unique_session_id" }, "params" : { "items" : {"$ref": "definitions.json#/predict_param_name"}, "type" : "array" } }, "type": "object" } C.3.26. MX Network Analytics Response Kanugovi, et al. Expires December 2, 2019 [Page 111] Internet-Draft MAMS May 2019 { "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "definitions" : { "ParamPredictions" : { "param_name" : {"$ref" : "definitions.json#/predict_param_name"}, "additional_param" : {"$ref" : "definitions.json#/predict_add_param_name"}, "prediction" : { "type" : "integer" }, "likelihood" : { "type" : "integer" }, "validity_time" : { "type" : "integer" } }, "MXAnalyticsList" : { "connection_id" : { "$ref" : "definitions.json#/connection_id" }, "connection_type" : { "$ref" : "definitions.json#/connection_type" }, "predictions " : { "items" : { "$ref" : "#definitions/ParamPredictions" }, "type" : "array" } } }, "id": "http://www.ietf.org/mams/mx_network_analytics_resp.json", "properties": { "message_type" : {"$ref": "mx_base_def.json#/message_type_def"}, "sequence_num" : {"$ref": "mx_base_def.json#/sequence_num_def"}, "version" : {"$ref": "mx_base_def.json#/version_def"}, "param_list" : { "items" : {"$ref": "#definitions/MXAnalyticsList"}, "type" : "array"} }, "type": "object" } C.4. Examples in JSON C.4.1. MX Discover { "version" : "1.0", "message_type" : "mx_discover", "sequence_num" : 1 } C.4.2. MX System Update Kanugovi, et al. Expires December 2, 2019 [Page 112] Internet-Draft MAMS May 2019 { "version" : "1.0", "message_type" : "mx_system_info", "sequence_num" : 2, "ncm_connections" : [ { "connection_id" : 0, "connection_type" : "lte", "ncm_end_point" : { "ip_address" : "192.168.1.10", "port" : 1234 } }, { "connection_id" : 1, "connection_type" : "wifi", "ncm_end_point" : { "ip_address" : "192.168.1.10", "port" : 1234 } } ] } C.4.3. MX Capability Request { "version" : "1.0", "message_type" : "mx_capability_req", "sequence_num" : 3, "feature_active" : [ { "feature_name" : "lossless_switching", "active" : true }, { "feature_name" : "fragmentation", "active" : false } ], "num_anchor_connections" : 2, "anchor_connections" : [ { "connection_id" : 0, "connection_type" : "lte" }, { "connection_id" : 1, Kanugovi, et al. Expires December 2, 2019 [Page 113] Internet-Draft MAMS May 2019 "connection_type" : "wifi" } ], "num_delivery_connections" : 2, "delivery_connections" : [ { "connection_id" : 0, "connection_type" : "lte" }, { "connection_id" : 1, "connection_type" : "wifi" } ], "convergence_methods" : [ { "method" : "GMA", "supported" : true }, { "method" : "MPTCP_Proxy", "supported" : false } ], "adaptation_methods" : [ { "method" : "UDP_without_DTLS", "supported" : false }, { "method" : "UDP_with_TLS", "supported" : false }, { "method" : "IPSec", "supported" : true }, { "method" : "Client_NAT", "supported" : false } ] } Kanugovi, et al. Expires December 2, 2019 [Page 114] Internet-Draft MAMS May 2019 C.4.4. MX Capability Response { "version" : "1.0", "message_type" : "mx_capability_resp", "sequence_num" : 3, "feature_active" : [ { "feature_name" : "lossless_switching", "active" : true }, { "feature_name" : "fragmentation", "active" : false } ], "num_anchor_connections" : 2, "anchor_connections" : [ { "connection_id" : 0, "connection_type" : "lte" }, { "connection_id" : 1, "connection_type" : "wifi" } ], "num_delivery_connections" : 2, "delivery_connections" : [ { "connection_id" : 0, "connection_type" : "lte" }, { "connection_id" : 1, "connection_type" : "wifi" } ], "convergence_methods" : [ { "method" : "GMA", "supported" : true }, { "method" : "MPTCP_Proxy", "supported" : false } ], Kanugovi, et al. Expires December 2, 2019 [Page 115] Internet-Draft MAMS May 2019 "adaptation_methods" : [ { "method" : "UDP_without_DTLS", "supported" : false }, { "method" : "UDP_with_TLS", "supported" : false }, { "method" : "IPSec", "supported" : true }, { "method" : "Client_NAT", "supported" : false } ], "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 } } C.4.5. MX Capability Ack { "version" : "1.0", "message_type" : "mx_capability_ack", "sequence_num" : 3, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "capability_ack" : "MX ACCEPT" } C.4.6. MX Reconfiguration Request Kanugovi, et al. Expires December 2, 2019 [Page 116] Internet-Draft MAMS May 2019 { "version" : "1.0", "message_type" : "mx_reconf_req", "sequence_num" : 4, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "reconf_action" : "setup", "connection_id" : 0, "ip_address" : "192.168.110.1", "ssid" : "SSID_1", "mtu_size" : 1300, "connection_status" : "connected", "delivery_node_id" : "2A12C" } C.4.7. MX Reconfiguration Response { "version" : "1.0", "message_type" : "mx_reconf_rsp", "sequence_num" : 4 } C.4.8. MX UP Setup Configuration Request { "version": "1.0", "message_type": "mx_up_setup_conf_req", "sequence_num": 5, "num_anchor_connections": 2, "anchor_connections": [{ "connection_id": 1, "connection_type": "wifi", "num_active_mx_conf" : 2, "convergence_config" : [ { "mx_configuration_id" : 1, "convergence_method": "GMA", "convergence_method_params": {}, "num_delivery_connections": 2, "delivery_connections": [{ "connection_id": 0, "connection_type": "lte", "adaptation_method": "UDP_without_DTLS", "adaptation_method_param": { "tunnel_ip_addr": "6.6.6.6", "tunnel_end_port": 9999, Kanugovi, et al. Expires December 2, 2019 [Page 117] Internet-Draft MAMS May 2019 "mx_header_optimization": true } }, { "connection_id": 1, "connection_type": "wifi" } ] }, { "mx_configuration_id" : 2, "convergence_method": "GMA", "convergence_method_params": {}, "num_delivery_connections": 1, "delivery_connections": [{ "connection_id": 0, "connection_type": "lte", "adaptation_method": "UDP_without_DTLS", "adaptation_method_param": { "tunnel_ip_addr": "6.6.6.6", "tunnel_end_port": 8877 } } ] } ] }, { "connection_id": 0, "connection_type": "lte", "udp_port": 8888, "num_delivery_connections": 2, "delivery_connections": [{ "connection_id": 0, "connection_type": "lte" }, { "connection_id": 1, "connection_type": "wifi", "adaptation_method": "UDP_without_DTLS", "adaptation_method_param": { "tunnel_ip_addr": "192.168.3.3", "tunnel_end_port": "6000" } } ] } ] Kanugovi, et al. Expires December 2, 2019 [Page 118] Internet-Draft MAMS May 2019 } C.4.9. MX UP Setup Confirmation { "version" : "1.0", "message_type" : "mx_up_setup_cnf", "sequence_num" : 5, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "probe_param" : { "probe_port" : 48700, "anchor_conn_id" : 0, "mx_configuration_id" : 1 }, "num_delivery_conn" : 2, "client_params" : [ { "connection_id" : 0, "adapt_param" : { "udp_adapt_port" : 51000 } }, { "connection_id" : 1, "adapt_param" : { "udp_adapt_port" : 52000 } } ] } C.4.10. MX Traffic Steering Request { "version" : "1.0", "message_type" : "mx_traffic_steering_req", "sequence_num" : 6, "connection_id" : 0, "mx_configuration_id" : 1, "downlink_delivery" : [ { "connection_id" : 0 }, { "connection_id" : 1 Kanugovi, et al. Expires December 2, 2019 [Page 119] Internet-Draft MAMS May 2019 } ], "default_uplink_delivery" : 0, "uplink_delivery" : [ { "ul_tft" : { "remote_addr_mask" : "10.10.0.0/24", "local_addr_mask" : "192.168.0.0/24", "protocol_type" : 6, "loca_port_range" : { "start" : 100, "end" : 1000 }, "remote_port_range" : { "start" : 100, "end" : 1000 }, "traffic_class" : 20, "flow_label" : 100 }, "conn_list" : [ { "connection_id" : 1 } ] }, { "ul_tft" : { "remote_addr_mask" : "10.10.0.0/24", "local_addr_mask" : "192.168.0.0/24", "protocol_type" : 6, "local_port_range" : { "start" : 2000, "end" : 2000 }, "remote_port_range" : { "start" : 100, "end" : 1000 }, "traffic_class" : 20, "flow_label" : 50 }, "conn_list" : [ { "connection_id" : 1 } ] } Kanugovi, et al. Expires December 2, 2019 [Page 120] Internet-Draft MAMS May 2019 ], "feature_activation" : [ { "feature_name" : "dl_aggregation", "active" : true }, { "feature_name" : "ul_aggregation", "active" : false } ] } C.4.11. MX Traffic Steering Response { "version": "1.0", "message_type": "mx_traffic_steering_rsp", "sequence_num": 6, "unique_session_id": { "ncm_id": 110, "session_id": 1111 }, "feature_activation": [{ "feature_name": "lossless_switching", "active": true }, { "feature_name": "fragmentation", "active": false } ] } C.4.12. MX Application MADP Association Request Kanugovi, et al. Expires December 2, 2019 [Page 121] Internet-Draft MAMS May 2019 { "version": "1.0", "message_type": "mx_app_madp_assoc_req", "sequence_num": 6, "unique_session_id": { "ncm_id": 110, "session_id": 1111 }, "app_madp_assoc_list": [{ "connection_id" : 0, "mx_configuration_id" : 1, "ul_tft_list": [{ "protocol_type": 17, "local_port_range": { "start": 8888, "end": 8888 } }], "dl_tft_list": [{ "protocol_type": 17, "remote_port_range": { "start": 8888, "end": 8888 } }] } ] } C.4.13. MX Application MADP Association Response { "version": "1.0", "message_type": "mx_app_madp_assoc_resp", "sequence_num": 6, "is_success": true } C.4.14. MX Path Estimation Request Kanugovi, et al. Expires December 2, 2019 [Page 122] Internet-Draft MAMS May 2019 { "version" : "1.0", "message_type" : "mx_path_est_req", "sequence_num" : 7, "connection_id" : 0, "init_probe_test_duration_ms" : 100, "init_probe_test_rate_Mbps" : 10, "init_probe_size_bytes" : 1000, "init_probe_ack_req" : "yes", "active_probe_freq_ms" : 10000, "active_probe_size_bytes" : 1000, "active_probe_duration_sec" : 10, "active_probe_ack_req" : "no" } C.4.15. MX Path Estimation Results { "version" : "1.0", "message_type" : "mx_path_est_results", "sequence_num" : 8, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "connection_id" : 0, "init_probe_results" : { "lost_probes_percentage" : 1, "probe_rate_Mbps" : 9.9 }, "active_probe_results" : { "avg_tput_last_probe_duration_Mbps" : 9.8 } } C.4.16. MX SSID Indication Kanugovi, et al. Expires December 2, 2019 [Page 123] Internet-Draft MAMS May 2019 { "version" : "1.0", "message_type" : "mx_ssid_indication", "sequence_num" : 9, "ssid_list" : [ { "ssid_type" : "ssid", "ssid_id" : "SSID_1" }, { "ssid_type" : "bssid", "ssid_id" : "xxx-yyy" } ] } C.4.17. MX Measurements Configuration { "version" : "1.0", "message_type" : "mx_measurement_conf", "sequence_num" : 10, "measurement_configuration" : [ { "connection_id" : 0, "connection_type" : "wi-fi", "meas_rep_conf" : [ { "meas_rep_param" : "WLAN_RSSI", "meas_threshold" : { "high" : -10, "low" : -15 }, "meas_period_ms" : 500 }, { "meas_rep_param" : "WLAN_LOAD", "meas_threshold" : { "high" : -10, "low" : -15 }, "meas_period_ms" : 500 }, { "meas_rep_param" : "EST_UL_TPUT", "meas_threshold" : { "high" : 100, "low" : 30 Kanugovi, et al. Expires December 2, 2019 [Page 124] Internet-Draft MAMS May 2019 }, "meas_period_ms" : 500 } ] }, { "connection_id" : 1, "connection_type" : "lte", "meas_rep_conf" : [ { "meas_rep_param" : "LTE_RSRP", "meas_threshold" : { "high" : -10, "low" : -15 }, "meas_period_ms" : 500 }, { "meas_rep_param" : "LTE_RSRQ", "meas_threshold" : { "high" : -10, "low" : -15 }, "meas_period_ms" : 500 } ] } ] } C.4.18. MX Measurements Report Kanugovi, et al. Expires December 2, 2019 [Page 125] Internet-Draft MAMS May 2019 { "version" : "1.0", "message_type" : "mx_measurement_report", "sequence_num" : 11, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "measurment_reports" : [ { "connection_id" : 0, "connection_type" : "wi-fi", "delivery_node_id" : "2021A", "measurements" : [ { "measurement_type" : "WLAN_RSSI", "measurement_value" : -12 }, { "measurement_type" : "UL_TPUT", "measurement_value" : 10 }, { "measurement_type" : "EST_UL_TPUT", "measurement_value" : 20 } ] }, { "connection_id" : 1, "connection_type" : "lte", "delivery_node_id" : "12323", "measurements" : [ { "measurement_type" : "LTE_RSRP", "measurement_value" : -12 }, { "measurement_type" : "LTE_RSRQ", "measurement_value" : -12 } ] } ] } Kanugovi, et al. Expires December 2, 2019 [Page 126] Internet-Draft MAMS May 2019 C.4.19. MX Keep Alive Request { "version" : "1.0", "message_type" : "mx_keep_alive_req", "sequence_num" : 12, "keep_alive_reason" : "Handover", "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "connection_id" : 0, "delivery_node_id" : "2021A" } C.4.20. MX Keep Alive Response { "version" : "1.0", "message_type" : "mx_keep_alive_rsp", "sequence_num" : 12, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 } } C.4.21. MX Session Termination Request { "version" : "1.0", "message_type" : "mx_session_termination_req", "sequence_num" : 13, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "reason" : "MX_NORMAL_RELEASE" } C.4.22. MX Session Termination Response Kanugovi, et al. Expires December 2, 2019 [Page 127] Internet-Draft MAMS May 2019 { "version" : "1.0", "message_type" : "mx_session_termination_resp", "sequence_num" : 13, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 } } C.4.23. MX Network Analytics Request { "version" : "1.0", "message_type" : "mx_network_analytics_req", "sequence_num" : 20, "unique_session_id" : { "ncm_id" : 110, "session_id" : 1111 }, "parmas" : [ "jitter", "latency" ] } C.4.24. MX Network Analytics Response Kanugovi, et al. Expires December 2, 2019 [Page 128] Internet-Draft MAMS May 2019 { "version": "1.0", "message_type": "mx_network_analytics_resp", "sequence_num": 20, "param_list": [{ "connection_id": 1, "connection_type": "wifi", "predictions": [{ "param_name": "jitter", "prediction": 100, "likelihood": 50, "validity_time": 10 }, { "param_name": "latency", "prediction": 19, "likelihood": 40, "validity_time": 10 } ] }, { "connection_id": 2, "connection_type": "lte", "predictions": [{ "param_name": "jitter", "prediction": 10, "likelihood": 80, "validity_time": 10 }, { "param_name": "latency", "prediction": 4, "likelihood": 60, "validity_time": 10 } ] } ] } Appendix D. Definition of APIs provided by CCM to the Applications at the Client This section provides an example implementation of the APIs exposed by the CCM to the Applications on the client, documented with OpenAPI using Swagger 2.0. Kanugovi, et al. Expires December 2, 2019 [Page 129] Internet-Draft MAMS May 2019 { "swagger": "2.0", "info": { "version": "1.0.0", "title": "Client Connection Manager (CCM)", "description": "API provided by CCM towards Application on a MAMS client." }, "host": "MAMS.ietf.org", "basePath": "/ccm/v1.0", "schemes": [ "https" ], "consumes": [ "application/json" ], "produces": [ "application/json" ], "paths": { "/capabilities": { "get": { "description": "This API can be used by application to request for capabilities of the CCM.", "produces": [ "application/json", "text/html" ], "responses": { "200": { "description": "OK", "schema": { "$ref": "#/definitions/capability" } }, "default": { "description": "unexpected error", "schema": { "$ref": "#/definitions/errorModel" } } } } }, "/app_requirements": { "post": { "description": "This API is used by N-MADP to report any kind of MAMS user specific errors to NCM.", "produces": [ "application/json", "text/html" Kanugovi, et al. Expires December 2, 2019 [Page 130] Internet-Draft MAMS May 2019 ], "parameters": [ { "name": "app-requirements", "in": "body", "required": true, "schema": { "$ref": "#/definitions/app-requirements" } } ], "responses": { "200": { "description": "OK" }, "default": { "description": "unexpected error", "schema": { "$ref": "#/definitions/errorModel" } } } } }, "/predictive_link_params": { "get": { "description": "This API is used by applications to get the information about predicted parameters for each delivery connection.", "produces": [ "application/json", "text/html" ], "responses": { "200": { "description": "OK", "schema": { "$ref": "#/definitions/link-params" } }, "default": { "description": "unexpected error", "schema": { "$ref": "#/definitions/errorModel" } } } } } }, Kanugovi, et al. Expires December 2, 2019 [Page 131] Internet-Draft MAMS May 2019 "definitions": { "connection-id": { "type": "integer", "format": "uint8" }, "connection-type": { "enum": [ "wi-fi", "5g-nr", "multi-fire", "lte" ], "type": "string" }, "features": { "enum": [ "lossless_switching", "fragmentation", "concatenation", "uplink_aggregation", "downlink_aggregation", "measurement" ], "type": "string" }, "adaptation-methods": { "enum": [ "UDP_without_DTLS", "UDP_with_DTLS", "IPSec", "Client_NAT" ], "type": "string" }, "convergence-methods": { "enum": [ "GMA", "MPTCP_Proxy", "GRE_Aggregation_Proxy", "MPQUIC" ], "type": "string" }, "connection": { "type": "object", "properties": { "conn-id": { "$ref": "#/definitions/connection-id" Kanugovi, et al. Expires December 2, 2019 [Page 132] Internet-Draft MAMS May 2019 }, "conn-type": { "$ref": "#/definitions/connection-type" } } }, "convergence-parameters": { "type": "object", "properties": { "conv-param-name": { "type": "string" }, "conv-param-value": { "type": "string" } } }, "convergence-details": { "type": "object", "properties": { "conv-method": { "$ref": "#/definitions/convergence-methods" }, "conv-params": { "type": "array", "items": { "$ref": "#/definitions/convergence-parameters" } } } }, "capability": { "type": "object", "properties": { "connections": { "type": "array", "items": { "$ref": "#/definitions/connection" } }, "features": { "type": "array", "items": { "$ref": "#/definitions/features" } }, "adapt-methods": { "type": "array", Kanugovi, et al. Expires December 2, 2019 [Page 133] Internet-Draft MAMS May 2019 "items": { "$ref": "#/definitions/adaptation-methods" } }, "conv-methods": { "type": "array", "items": { "$ref": "#/definitions/convergence-details" } } } }, "qos-param-name": { "enum": [ "jitter", "latency", "bandwidth" ], "type": "string" }, "qos-param": { "type": "object", "properties": { "qos-param-name": { "$ref": "#/definitions/qos-param-name" }, "qos-param-value": { "type": "integer" } } }, "port-range": { "type": "object", "properties": { "start": { "type": "integer" }, "end": { "type": "integer" } } }, "protocol-type": { "type": "integer" }, "stream-features": { "type": "object", "properties": { Kanugovi, et al. Expires December 2, 2019 [Page 134] Internet-Draft MAMS May 2019 "proto": { "$ref": "#/definitions/protocol-type" }, "port-range": { "$ref": "#/definitions/port-range" }, "traffic-qos": { "$ref": "#/definitions/qos-param" } } }, "app-requirements": { "type": "object", "properties": { "num-streams": { "type": "integer" }, "stream-feature": { "type": "array", "items": { "$ref": "#/definitions/stream-features" } } } }, "param-name": { "enum": [ "bandwidth", "jitter", "latency", "signal_quality" ], "type": "string" }, "additional-param-name": { "enum": [ "lte-rsrp", "lte-rspq", "nr-rsrp", "nr-rsrq", "wifi-rssi" ], "type": "string" }, "link-parameter": { "type": "object", "properties": { "connection": { Kanugovi, et al. Expires December 2, 2019 [Page 135] Internet-Draft MAMS May 2019 "$ref": "#/definitions/connection" }, "param": { "$ref": "#/definitions/param-name" }, "additional-param": { "$ref": "#/definitions/additional-param-name" }, "prediction": { "type": "integer" }, "likelihood": { "type": "integer" }, "validity_time": { "type": "integer" } } }, "link-params": { "type": "array", "items": { "$ref": "#/definitions/link-parameter" } }, "errorModel": { "type": "object", "description": "Error indication containing the error code and message.", "required": [ "code", "message" ], "properties": { "code": { "type": "integer", "format": "int32" }, "message": { "type": "string" } } } } } Kanugovi, et al. Expires December 2, 2019 [Page 136] Internet-Draft MAMS May 2019 Appendix E. Implementation Example using Python for MAMS Client and Server E.1. Client Side Implementation A simple client side implementation using python can be as following: Kanugovi, et al. Expires December 2, 2019 [Page 137] Internet-Draft MAMS May 2019 #!/usr/bin/env python import asyncio import websockets import json import ssl import time import sys context = ssl.SSLContext(ssl.PROTOCOL_TLS) context.verify_mode = ssl.CERT_REQUIRED context.set_ciphers("RSA") context.check_hostname = False context.load_verify_locations("/home/mecadmin/certs/rootca.pem") discoverMsg = {'version':'1.0', 'message_type':'mx_discover'} MXCapabilityRes = { 'version':'1.0', 'message_type':'mx_capability_res', 'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'}, {'feature_name':'lossless_switching', 'active':'yes'}], 'num_anchor_connections':1, 'anchor_connections':[{'connection_id':0, 'connection_type':'lte'}], 'num_delivery_connections':1, 'delivery_connections':[{'connection_id':1, 'connection_type':"wifi"}], 'convergence_methods':[{'method':'GMA', 'supported':'true'}], 'adaptation_methods':[{'method':'client_nat', 'supported':'false'}] } async def hello(): async with websockets.connect('wss://localhost:8765', ssl=context) as websocket: try: loopFlag=False while True: await websocket.send(json.dumps(discoverMsg)) json_message = await websocket.recv() message = json.loads(json_message) if "message_type" in message.keys(): print("Recieved message:{}".format(message["message_type"]),"version:{}".format(message["version"])) if message["message_type"] == "mx_capability_req" : await websocket.send(json.dumps(MXCapabilityRes)) loopFlag=True while(loopFlag==True): pass except: print("Client stopped") asyncio.get_event_loop().run_until_complete(hello()) Kanugovi, et al. Expires December 2, 2019 [Page 138] Internet-Draft MAMS May 2019 E.2. Server Side Implementation A server client side implementation using python can be as following: Kanugovi, et al. Expires December 2, 2019 [Page 139] Internet-Draft MAMS May 2019 #!/usr/bin/env python import asyncio import websockets import json import ssl ctx = ssl.SSLContext(ssl.PROTOCOL_TLS) #ctx.set_ciphers("RSA-AES256-SHA") ctx.load_verify_locations("/home/mecadmin/certs/rootca.pem") certfile = "/home/mecadmin/certs/server.pem" keyfile = "/home/mecadmin/certs/serverkey.pem" ctx.load_cert_chain(certfile, keyfile, password=None) MXCapabilityReq = { 'version':'1.0', 'message_type':'mx_capability_req', 'FeatureActive':[{'feature_name':'fragmentation', 'active':'yes'}, {'feature_name':'lossless_switching', 'active':'yes'}], 'num_anchor_connections':1, 'anchor_connections':[{'connection_id':0, 'connection_type':'lte'}], 'num_delivery_connections':1, 'delivery_connections':[{'connection_id':1, 'connection_type':"wifi"}], 'convergence_methods':[{'method':'GMA', 'supported':'true'}], 'adaptation_methods':[{'method':'client_nat', 'supported':'false'}] } async def hello(websocket, path): try: while True: name = await websocket.recv() msg = json.loads(name) if "message_type" in msg.keys(): print("Recieved message:{}".format(msg["message_type"]),"version:{}".format(msg["version"])) if msg['message_type'] == 'mx_discover': await websocket.send(json.dumps(MXCapabilityReq)) except: print("client disconnected") try: start_server = websockets.serve(hello, 'localhost', 8765,ssl=ctx) asyncio.get_event_loop().run_until_complete(start_server) asyncio.get_event_loop().run_forever() except: print("server stopped") Kanugovi, et al. Expires December 2, 2019 [Page 140] Internet-Draft MAMS May 2019 Authors' Addresses Satish Kanugovi Nokia Email: satish.k@nokia.com Florin Baboescu Broadcom Email: florin.baboescu@broadcom.com Jing Zhu Intel Email: jing.z.zhu@intel.com Julius Mueller AT&T Email: jm169k@att.com SungHoon Seo Korea Telecom Email: sh.seo@kt.com Kanugovi, et al. Expires December 2, 2019 [Page 141]./draft-nottingham-safe-hint-11.txt0000644000764400076440000004326213521072467016467 0ustar iustyiusty Network Working Group M. Nottingham Internet-Draft August 2, 2019 Intended status: Informational Expires: February 3, 2020 The "safe" HTTP Preference draft-nottingham-safe-hint-11 Abstract This specification defines a "safe" preference for HTTP requests that expresses a desire to avoid objectionable content, according to the definition of that term by the origin server. This specification does not define a precise semantic for "safe". Rather, the term is interpreted by the server and within the scope of each Web site that chooses to act upon this information. Support for this preference by clients and servers is optional. 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 https://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 3, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Nottingham Expires February 3, 2020 [Page 1] Internet-Draft Preference for Safe Browsing August 2019 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. The "safe" Preference . . . . . . . . . . . . . . . . . . . . 4 3. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Appendix B. Sending "safe" from Web Browsers . . . . . . . . . . 8 Appendix C. Supporting "safe" on Web Sites . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Many Web sites have a "safe" mode, to assist those who don't want to be exposed (or have their children exposed) to content to which they might object. However, that goal is often difficult to achieve, because of the need to go to every Web site that might be used, navigate to the appropriate page (possibly creating an account along the way) to get a cookie [RFC6265] set in the browser, for each browser on every device used. A more manageable approach is for the browser to proactively indicate a preference for safe content. A user agent that supports doing so (whether it be an individual browser, or through an Operating System HTTP library) need only be configured once to assure that the preference is advertised to a set of sites, or even all sites. This specification defines how to declare this desire in requests as a HTTP Preference [RFC7240]. Note that this specification does not define what content might be considered objectionable, and so the concept of "safe" is also not precisely defined. Rather, the term is interpreted by the server and within the scope of each Web site that chooses to act upon this information. That said, the intent of "safe" is to allow end users (or those acting on their behalf) to express a desire to avoid content that is considered objectionable within the cultural context of that site; Nottingham Expires February 3, 2020 [Page 2] Internet-Draft Preference for Safe Browsing August 2019 usually (but not always) content that is unsuitable for minors. The "safe" preference is not intended to be used for other purposes. Furthermore, sending "safe" does not guarantee that the Web site will use it, nor that it will apply a concept of "objectionable" that is consistent with the requester's views. As such, its effect can be described as "best effort," and not to be relied upon. In other words, sending the preference is no more reliable than going to each Web site and manually selecting a "safe" mode, but it is considerably easier. It is also important to note that the "safe" preference is not a reliable indicator that the end user is a child; other users might have a desire for unobjectionable content, and some children might browse without the preference being set. Note also that the cultural context applies to the hosting location of a site, the content provider, and the source of the content. It cannot be guaranteed that a user-agent and origin server will have the same view of the concept of what is objectionable. Simply put, it is a statement by (or on behalf of) the end user to the effect "If your site has a 'safe' setting, this user is hereby opting into that, according to your definition of the term." The mechanism described in this document does not have IETF consensus and is not a standard. It is a widely deployed approach that has turned out to be useful, and is presented here so that server and browser implementations can have a common understanding of how it operates. This mechanism was presented for publication as an IETF Proposed Standard, but was not approved for publication by the IESG because of concerns that included the vagueness of the meaning of "safe", the ability of a proxy to insert the hint outside of a user's control, the fact that there was no way to know whether the hint was or was not applied to the response returned by the server, and how the use of this preference may incentivize increased censorship and/or targeting of minors. The specification has been updated to address those concerns, but the IESG has not approved progressing this document as an IETF Proposed Standard. As a result, it is published in the Independent Stream. Nottingham Expires February 3, 2020 [Page 3] Internet-Draft Preference for Safe Browsing August 2019 1.1. Notational Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. The "safe" Preference When present in a request, the "safe" preference indicates that the user prefers that the origin server to not respond with content which is designated as objectionable, according to the origin server's definition of the concept. For example, a request that includes the "safe" preference: GET /foo.html HTTP/1.1 Host: www.example.org User-Agent: ExampleBrowser/1.0 Prefer: safe Typically, user agents that emit the "safe" preference will include it in all requests with the "https" URI scheme, although some might expose finer-grained controls over when it is sent; this ensures that the preference is available to the applicable resources. User agents MUST NOT emit the "safe" preference on requests with the "http" URI scheme (see Section 4). See Appendix B for more information about configuring the set of resources "safe" is sent to. Safe MAY be implemented in common HTTP libraries (e.g., an operating system might choose to insert the preference in requests based upon system-wide configuration). Origin servers that utilize the "safe" preference ought to document that they do so, along with the criteria that they use to denote objectionable content. If a server has more fine-grained degrees of "safety", it SHOULD select a reasonable default to use, and document that; it MAY use additional mechanisms (e.g., cookies [RFC6265]) to fine-tune. A response corresponding to the request above might have headers that look like this: Nottingham Expires February 3, 2020 [Page 4] Internet-Draft Preference for Safe Browsing August 2019 HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: text/html Preference-Applied: safe Server: ExampleServer/2.0 Vary: Prefer Here, the Preference-Applied response header ([RFC7240]) indicates that the site has applied the preference. Servers are not required to send Preference-Applied (even when they have applied the preference), but are encouraged to where possible. Note that the Vary response header needs to be sent if the response is cacheable and might change depending on the value of the "Prefer" header. This is not only true for those responses that are "safe", but also the default "unsafe" response. See [RFC7234] Section 4.1 for more information the interaction between Vary and Web caching. See Appendix C for additional advice specific to Web servers wishing to use "safe". 3. Implementation Status _Note to RFC Editor: Please remove this section 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. 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. o Microsoft Internet Explorer - see https://support.microsoft.com/ en-hk/help/2980016/ o Microsoft Bing - see https://developer.microsoft.com/en-us/ microsoft-edge/testdrive/demos/familysearch/ o Mozilla Firefox - see https://support.mozilla.org/en-US/kb/block- and-unblock-websites-parental-controls-firef o Cisco - see http://blogs.cisco.com/security/filtering-explicit- content Nottingham Expires February 3, 2020 [Page 5] Internet-Draft Preference for Safe Browsing August 2019 4. Security Considerations The "safe" preference is not a secure mechanism; it can be inserted or removed by intermediaries with access to the request stream (e.g. for "http" URLs). Therefore, it is prohibited from being included in requests with the "http" scheme. Its presence reveals information about the user, which may be of assistance in "fingerprinting" the user by sites and other entities in the network. This information which provides insight into the preferences of the user, might be used to make assumptions about the user and so could be used to target categories of user for purposes such as targeting (including advertising and identification of minors). Therefore, user agents SHOULD NOT include it in requests when the user has expressed a desire to avoid such attacks (e.g., some forms of "private mode" browsing). By its nature, including "safe" in requests does not assure that all content will actually be safe; it is only when servers elect to honor it that content might be "safe". Even then, a malicious server might adapt content so that it is even less "safe" (by some definition of the word). As such, this mechanism on its own is not enough to assure that only "safe" content is seen; those who wish to ensure that will need to combine its use with other techniques (e.g., content filtering). Furthermore, the server and user may have differing ideas regarding the semantics of "safe." As such, the "safety" of the user's experience when browsing from site to site as well as over time might (and probably will) change. 5. IANA Considerations This specification registers the following entry in the "HTTP Preferences" registry [RFC7240]: o Preference: safe o Value: (no value) o Description: Indicates that "safe" / "unobjectionable" content is preferred. o Reference: (this document) o Notes: Nottingham Expires February 3, 2020 [Page 6] Internet-Draft Preference for Safe Browsing August 2019 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, . [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, . [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . Nottingham Expires February 3, 2020 [Page 7] Internet-Draft Preference for Safe Browsing August 2019 Appendix A. Acknowledgements Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, Lorrie Cranor, Doug Turner and Dave Crocker for their comments. Appendix B. Sending "safe" from Web Browsers As discussed in Section 2, there are many possible ways for the "safe" preference to be generated. One possibility is for a Web browser to allow its users to configure the preference to be sent. When doing so, it is important not to misrepresent the preference as binding to Web sites. For example, an appropriate setting might be a checkbox with wording such as: [] Request "safe" content from Web sites ... along with further information available upon request. Browsers might also allow the "safe" preference to be "locked" - that is, prevent modification without administrative access, or a passcode. Note that this specification does not require browsers to send "safe" on all requests, although that is one possible implementation; e.g., alternate implementation strategies include blacklists and whitelists. Appendix C. Supporting "safe" on Web Sites Web sites that allow configuration of a "safe" mode (for example, using a cookie) can add support for the "safe" preference incrementally; since the preference will not be supported by all clients immediately, it is necessary to have another way to configure it. When honoring the safe preference, it is important that it not be possible to disable it through the Web site's interface, since "safe" may be configured and locked down by the browser or computer's administrator (e.g., a parent). If the site has such a means of configuration (e.g., stored user preferences) and the safe preference is received in a request, the "safer" interpretation ought to be used. The appropriate level of "safety" is a site-specific decision. When selecting it, sites ought to bear in mind that disabling the preference might be considerably more onerous than through other Nottingham Expires February 3, 2020 [Page 8] Internet-Draft Preference for Safe Browsing August 2019 means, especially if the preference is generated based upon Operating System configuration. Sites might offer different levels of "safeness" through Web configuration, they will need to either inform their users of what level the "safe" hint corresponds to, or provide them with some means of adjusting it. If the user expresses a wish to disable "safe" mode, the site can remind them that the safe preference is being sent, and ask them to consult their administrator (since "safe" might be set by a locked- down Operating System configuration). As explained in Section 2, responses that change based upon the presence of the "safe" preference need to either carry the "Vary: Prefer" response header field, or be uncacheable by shared caches (e.g., with a "Cache-Control: private" response header field). This is to avoid an unsafe cached response being served to a client that prefers safe content (or vice versa). Author's Address Mark Nottingham EMail: mnot@mnot.net URI: https://www.mnot.net/ Nottingham Expires February 3, 2020 [Page 9] ./draft-ribose-asciirfc-08.txt0000644000764400076440000106050113265536533015515 0ustar iustyiusty Network Working Group R. Tse Internet-Draft N. Nicholas Intended status: Informational J. Lau Expires: October 20, 2018 P. Brasolin Ribose April 18, 2018 AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc draft-ribose-asciirfc-08 Abstract This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator. 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 https://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 20, 2018. Tse, et al. Expires October 20, 2018 [Page 1] Internet-Draft AsciiRFC Specifications April 2018 Copyright Notice Copyright (c) 2018 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Designed for authoring RFCs and Internet-Drafts . . . . . 3 1.2. Relationship between AsciiRFC, AsciiDoc and Asciidoctor . 4 1.3. Comparison with RFC XML tools based on Markdown variants 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 2.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 6 2.2. Wrapping Lines in Documentation Examples . . . . . . . . 6 3. Document Structure and Syntax . . . . . . . . . . . . . . . . 7 3.1. Unsupported features compared with Asciidoctor syntax . . 8 3.2. Mapping To RFC XML syntax . . . . . . . . . . . . . . . . 8 3.3. Example Illustrations . . . . . . . . . . . . . . . . . . 9 3.4. Simple Illustration . . . . . . . . . . . . . . . . . . . 10 4. Header And Document Attributes . . . . . . . . . . . . . . . 28 4.1. Title And Basic Attributes . . . . . . . . . . . . . . . 28 4.2. Detailed Author Information . . . . . . . . . . . . . . . 30 4.3. XML Processing Information . . . . . . . . . . . . . . . 34 4.4. AsciiRFC-specific Document Attributes . . . . . . . . . . 35 5. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6. Sections and Paragraphs . . . . . . . . . . . . . . . . . . . 39 7. Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.1. Basic Lists . . . . . . . . . . . . . . . . . . . . . . . 47 8.2. List Continuation . . . . . . . . . . . . . . . . . . . . 52 9. Blockquotes . . . . . . . . . . . . . . . . . . . . . . . . . 55 10. Notes And Asides . . . . . . . . . . . . . . . . . . . . . . 56 11. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 12. Inline Formatting . . . . . . . . . . . . . . . . . . . . . . 62 12.1. Italics, Boldface, Monospace, Subscripts, Superscripts . 62 12.2. Formatting BCP 14 Keywords . . . . . . . . . . . . . . . 63 12.3. Escaping AsciiRFC Syntax . . . . . . . . . . . . . . . . 64 13. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 14. Cross-References . . . . . . . . . . . . . . . . . . . . . . 66 14.1. Basic Referencing . . . . . . . . . . . . . . . . . . . 66 14.2. Referencing With Attributes . . . . . . . . . . . . . . 67 Tse, et al. Expires October 20, 2018 [Page 2] Internet-Draft AsciiRFC Specifications April 2018 14.3. Indexing . . . . . . . . . . . . . . . . . . . . . . . . 68 15. Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . 69 16. Encoding and Entities . . . . . . . . . . . . . . . . . . . . 70 17. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 72 17.1. Using Raw RFC XML . . . . . . . . . . . . . . . . . . . 72 17.2. Preprocessing Using "asciidoctor-bibliography" . . . . . 77 18. RFC XML features not supported in Asciidoctor . . . . . . . . 79 19. Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . 79 19.1. Using the "rfc-asciirfc-minimal" template . . . . . . . 80 19.2. Installing AsciiRFC Backend Processors . . . . . . . . . 80 19.3. Iterating AsciiRFC Content . . . . . . . . . . . . . . . 80 20. Security Considerations . . . . . . . . . . . . . . . . . . . 81 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 22.1. Normative References . . . . . . . . . . . . . . . . . . 81 22.2. Informative References . . . . . . . . . . . . . . . . . 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 85 A.1. Example 1: "A Minimal Internet-Draft In AsciiRFC" . . . . 85 A.1.1. In AsciiRFC . . . . . . . . . . . . . . . . . . . . . 85 A.1.2. Rendered as RFC XML v3 . . . . . . . . . . . . . . . 93 A.2. Example 2: "The Holy Hand Grenade of Antioch" . . . . . . 98 A.2.1. In AsciiRFC . . . . . . . . . . . . . . . . . . . . . 98 A.2.2. Rendered as RFC XML v3 . . . . . . . . . . . . . . . 115 A.3. Example 3: "An API For Calendar-Based Fortune Heuristics Services" in AsciiRFC . . . . . . . . . . . . . . . . . . 133 A.3.1. In AsciiRFC . . . . . . . . . . . . . . . . . . . . . 134 A.4. Rendered as RFC XML v3 . . . . . . . . . . . . . . . . . 153 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 170 1. Introduction This document describes a markup language called "AsciiRFC", developed specifically for the purpose of generating RFC XML document, based on Asciidoctor syntax. AsciiRFC can be used to generate compliant RFC XML v2 and v3 documents through the usage of an open source, MIT-licensed Ruby gem called "asciidoctor-rfc" written by the authors [asciidoctor-rfc]. 1.1. Designed for authoring RFCs and Internet-Drafts Internet-Drafts and RFCs intended for publication submission to the IETF can be written in a multitude of formats today, including: o XML: RFC XML v2 [RFC7749] and v3 [RFC7991] o nroff: through [NroffEdit] Tse, et al. Expires October 20, 2018 [Page 3] Internet-Draft AsciiRFC Specifications April 2018 o Microsoft Word: through usage of [RFC5385] o Lyx: through [lyx2rfc] o Pandoc: [RFC7328], through [pandoc2rfc] or [draftr] o Kramdown: through [kramdown-rfc2629] o mmark: through [mmark] Interestingly, the last three are Markdown [RFC7763] variants. As specified in [RFC7990], the IETF intends for the canonical format of RFCs to transition from plain-text ASCII to RFC XML v3 [RFC7991]. While plain-text will continue to be accepted from authors by the IETF, at least in the short- to medium-term, XML will be preferred for submission, and any plain-text submissions will need to be converted to RFC XML v3. While this need is already met for RFC XML v2 [RFC7749] by the tools specified above, the transition to RFC XML v3 [RFC7991] places added onus on authors to generate compliant XML. 1.2. Relationship between AsciiRFC, AsciiDoc and Asciidoctor [AsciiDoc] is a lightweight markup language and an alternative to Markdown, with features that make it attractive as a markup language for RFC with XML output. [Asciidoctor] is an open source, MIT-licensed Ruby implementation of [AsciiDoc] that provides an enhancement of the original AsciiDoc markup language. The variant of AsciiDoc syntax accepted by [Asciidoctor] is hereafter called "Asciidoctor syntax". AsciiRFC, as described in this document, is an AsciiDoc variant developed on Asciidoctor syntax, created for the purpose of generating RFC XML documents. 1.3. Comparison with RFC XML tools based on Markdown variants Section 1.2 of [RFC7764] famously states that "there is no such thing as 'invalid' Markdown, there is no standard demanding adherence to the Markdown syntax, and there is no governing body that guides or impedes its development." While there are contexts where that flexibility is useful, the authoring of RFCs does have a standard and a governing body, and there is such a thing as invalid RFC XML. A Tse, et al. Expires October 20, 2018 [Page 4] Internet-Draft AsciiRFC Specifications April 2018 more rigorous and extensible counterpart to Markdown, which still preserves its basic approach to formatting, can generate RFC XML that encompasses a fuller subset of the specification, and preempts malformed RFC XML output. The proposed markup language and associated Ruby gem has several advantages that we believe make it worth considering as an approach to generating RFC XML. o AsciiDoc was designed from the beginning as a publishing language: it was initially intended as a plain-text alternative to the DocBook XML schema. For that reason, Asciidoctor natively supports the full range of formatting required by RFC XML (including notes, tables, bibliographies, source-code blocks, and definition lists), without resorting to embedded HTML or Markdown "flavours". o AsciiRFC covers the full range of elements in RFC XML v2 and RFC XML v3. o AsciiDoc in its Ruby-based Asciidoctor implementation is extensible, with a well-defined API. (Extensions have been harnessed to deal with bibliographic preprocessing for AsciiRFC.) o AsciiRFC allows granular control of rendering, including user- specified attributes of text blocks. o The Asciidoctor implementation allows document inclusion, for managing large-scale documentation projects. o AsciiRFC allows granular control of permutations of block nesting, such as source code within lists or definition lists within unordered lists. o As a more formal counterpart to Markdown, AsciiDoc is well-suited to generating XML that needs to conform to a specified schema. The asciidoctor-rfc Ruby gem developed around AsciiDoc validates its RFC XML output against the RelaxNG schema defined for RFC XML, and reports any issues to the end user. o The asciidoctor-rfc Ruby gem incorporates validation not only of the XML structure of the standard, but also of the IETF workgroups it mentions against the latest listing online, and the bibliographic entries for RFC and other standards registered on . The gem also dynamically fetches bibliographic entries from the xml2rfc site, and uses them to populate the RFC XML document. As with Markdown, there is a wide range of tools that can render AsciiDoc; so AsciiRFC drafts of RFC documents can be previewed and Tse, et al. Expires October 20, 2018 [Page 5] Internet-Draft AsciiRFC Specifications April 2018 accessed without depending on the RFC tools ecosystem. Our realisation of RFC XML in AsciiRFC has aimed to ensure that, as much as possible, the markup language can be can be processed by generic Asciidoctor tools. The only exception to this as an add-on is the optional bibliography module, which allows bibliographies to be assembled on the fly based on citations in a document: see Section 17.2. 2. Conventions Used in This Document 2.1. Terms and Definitions The following terms and definitions apply to this document: AsciiDoc The AsciiDoc markup language generically, as described in [AsciiDoc]. Asciidoctor syntax The enhanced AsciiDoc syntax implemented by the [Asciidoctor] Ruby gem. AsciiRFC The AsciiDoc syntax developed for the purpose of generating RFC XML document based on Asciidoctor syntax, as described in this document. 2.2. Wrapping Lines in Documentation Examples This document contains a number of examples as fragments of XML. In some cases, the examples contain URLs that are over 72 characters long and so need to be wrapped for presentation in this document even though they would not need to be wrapped in the actual source XML. This document adopts a policy similar to that described in [I-D.wu-netmod-yang-xml-doc-conventions] to denote line wraps. When an XML example contains a URL, that URL is always included in double- quotes. If the URL would extend beyond 72 characters, the line is wrapped and the wrap is indicated with a backslash ("\"). The backslash appears without any additional space before the backslash and with no further characters after the backslash. For example, the following XML... Tse, et al. Expires October 20, 2018 [Page 6] Internet-Draft AsciiRFC Specifications April 2018 ...may be presented as 3. Document Structure and Syntax AsciiRFC consists of a subset of Asciidoctor syntax with the addition of bibliographic macros (Section 17.2). Asciidoctor syntax is presented in the Asciidoctor user manual [Asciidoctor-Manual]. AsciiRFC syntax consists of: o A document header, containing a title, a list of authors, and document attributes in lines prefixed with ":". o An optional document preamble, separated from the document header by a blank line, and not containing any section titles. o A number of sections, set off by a section title (a line prefixed with two or more "=".) A section may contain: o Other sections, whose level of nesting is indicated by the number of "=" in their header. o Blocks of text. Blocks can have metadata (including a title, an anchor for cross-references, and attributes.) Blocks can be: o Paragraphs, which are terminated by blank lines. o Lists. List items are by default paragraphs, but can span over multiple paragraphs. o Delimited blocks (with a line delimiter on either side of them); these include tables, notes, sidebars, source code, block quotes, examples, and unprocessed content (e.g. raw XML). Delimited blocks contain by default one or more paragraphs. o List items can contain other blocks, including both nested lists and delimited blocks. Tse, et al. Expires October 20, 2018 [Page 7] Internet-Draft AsciiRFC Specifications April 2018 o Some delimited blocks can contain other delimited blocks; for example, examples can contain source code as well as discussion in paragraphs. o Blocks of text consist of inline text, which itself can contain markup. Inline markup includes: o Text formatting: Bold, italic, superscript, subscript, monospace. o Markup macros: the "bcp14" and "comment" macros. (Asciidoctor syntax supports custom markup macros.) o URLs, including display text to render. o Inline anchors. o Cross-references to anchors (IDs of blocks or spans of text), including display text to render. o Images: SVG only, as specified in [RFC7996]. o Index terms. 3.1. Unsupported features compared with Asciidoctor syntax Several features from Asciidoctor are not supported within AsciiRFC due to the lack of support within RFC XML, including: o Audio and video files are not supported in AsciiRFC as today's RFC XML structure does not support audio or video. o Equations are not supported as there is no current RFC XML equivalent. Asciidoctor provides native support for [AsciiMathML] and [TeX-LaTeX], via the [MathJax] tool. o Footnotes are not supported in AsciiRFC as there is no equivalent semantic representation in RFC XML. These carved out features can be easily supported by AsciiRFC once RFC XML allows these elements. 3.2. Mapping To RFC XML syntax The Asciidoctor syntax document structure aligns with both the RFC XML v2 and the RFC XML v3 structure. In the following, RFC XML v3 equivalences are given to the basic Asciidoctor structure. Tse, et al. Expires October 20, 2018 [Page 8] Internet-Draft AsciiRFC Specifications April 2018 Header "" attributes, most "front" elements. Preamble "front/abstract" and "front/note". Sections "middle/section" elements. Sections with bibliography style attribute "back/references" elements. Sections with appendix style attribute "back/section" elements. Paragraphs "t" elements. Lists "ul", "ol", "dl" elements. Delimited blocks "artwork", "aside", "blockquote", "figure", "note", "sourcecode", "table". Inline markup "bcp14", "br", "cref", "em", "eref", "iref", "relref", "strong", "sub", "sup", "tt", "xref". Full details of the mapping of AsciiRFC elements to RFC XML v2 and v3 elements, and of how to convert AsciiRFC documents to RFC XML, are given in the documentation of [asciidoctor-rfc]. 3.3. Example Illustrations This document utilizes example documents provided in Appendix A for demonstration of AsciiRFC syntax and usage. The source files and published versions (at the IETF Datatracker) of these example documents are available in Appendix A. o "A Minimal Internet-Draft In AsciiRFC" Appendix A.1.1 o "The Holy Hand Grenade of Antioch" Appendix A.2.1 o "An API For Calendar-Based Fortune Heuristics Services" Appendix A.3.1 Tse, et al. Expires October 20, 2018 [Page 9] Internet-Draft AsciiRFC Specifications April 2018 3.4. Simple Illustration This section gives an overview of how to create an RFC XML document in AsciiRFC, with some pitfalls to be aware of. Illustrations are in RFC XML v3 and RFC XML v2. A sample AsciiRFC document is provided in Figure 1, together with its corresponding rendering in: o RFC XML v3 (Figure 2) o RFC XML v2 (Figure 3) = A Minimal Internet-Draft In AsciiRFC :doctype: internet-draft :name: draft-asciirfc-minimal-02 :abbrev: AsciiRFC Example :status: informational :ipr: trust200902 :submissionType: individual :area: Internet :intended-series: full-standard :revdate: 2018-04-12T00:00:00Z :fullname: Josiah Stinkney Carberry :lastname: Carberry :forename_initials: J. S. :organization: Brown University :phone: +1 401 863 1000 :street: Box K, 69 Brown Street :city: Providence :code: 02912 :country: United States of America :uri: https://www.brown.edu :email: josiah.carberry@ribose.com :fullname_2: Truman Grayson :lastname_2: Grayson :forename_initials_2: T. :organization_2: Brown University :phone_2: +1 401 863 1000 :street_2: Box G, 69 Brown Street :city_2: Providence :code_2: 02912 :country_2: United States of America :uri_2: https://www.brown.edu :email_2: truman.grayson@ribose.com Tse, et al. Expires October 20, 2018 [Page 10] Internet-Draft AsciiRFC Specifications April 2018 [abstract] This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the `asciidoctor-rfc` Ruby gem. [#introduction] == Introduction AsciiRFC <> is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to <>. This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to <> and submittable to the IETF datatracker. [#conventions] == Terms and Definitions 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 <> <> when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions: AsciiRFC:: an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in <>. [#symbols] == Symbols And Abbreviations ADRFC:: abbreviated form of AsciiRFC [#security] == Security Considerations Any security considerations should be placed here. As described in <
> (here's how you refer a local anchor), Tse, et al. Expires October 20, 2018 [Page 11] Internet-Draft AsciiRFC Specifications April 2018 local tools have to be installed before the document template can be built. Running of these local tools *MAY* produce unintended side effects that impact security. [#iana] == IANA Considerations This document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here. [bibliography] == Normative References //bibliography::norm[] ++++ Key words for use in RFCs to Indicate Requirement Levels 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. Tse, et al. Expires October 20, 2018 [Page 12] Internet-Draft AsciiRFC Specifications April 2018 The "xml2rfc" Version 3 Vocabulary 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ++++ [bibliography] == Informative References //bibliography::info[] ++++ IETF Trust Legal Provisions (TLP) IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc Tse, et al. Expires October 20, 2018 [Page 14] Internet-Draft AsciiRFC Specifications April 2018 This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator. Rights Contributors Provide to the IETF Trust 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. Tse, et al. Expires October 20, 2018 [Page 15] Internet-Draft AsciiRFC Specifications April 2018 The OCB Authenticated-Encryption Algorithm 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). ++++ [appendix] [#appendix-a] == Examples === Example 1 Here's an example of a properly wrapped code snippet in accordance with rules specified in <>. [source,json] ---- { "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ---- Tse, et al. Expires October 20, 2018 [Page 16] Internet-Draft AsciiRFC Specifications April 2018 [#acknowledgements] == Acknowledgements The authors would like to thank their families. Figure 1: Sample Internet-Draft in AsciiRFC The first block of text, from "= Template For Writing An Internet- Draft In AsciiRFC" through to ":email_2: thomas.kandell@brown.edu", is the document header. It contains a title in the first line, an author attribution ("Josiah Carberry; Thomas Kandell"), and then a set of document attributes, conveying information about the document as well as information about its authors. This information ends up in RFC XML either as attributes of the root "rfc" tag, elements of the "front" tag, or processing instructions. The following blocks of text, up until the first section header ("== Introduction"), are the document preamble. They are treated by the document converter as containing the document abstract ("abstract"), followed by any notes if present. Section headers delimit the sections of the main body of the document, starting with "== Introduction". The document converter treats the first section of the document as the start of the "middle" section in RFC XML. The first section header is followed by a paragraph, and other sections and paragraphs. The number of "=" signs can be one higher than that of the preceding section header, which indicates that they are subsections of that section; so "=== Operators" is a subsection of the preceding "== Symbols And Abbreviations". The paragraphs contain some inline formatting (e.g. boldface: "*MUST*", monospace: "`type`"), and sections can also contain blocks other than normal paragraphs; the section "== Operators", for example, contains a definition list (whose terms are delimited by "::"), and the subsection "=== Example 1" contains a code snippet (delimited by "----", and tagged with the style attribute "[source,json]", indicating that this is a JSON sourcecode listing). The document can also include comments ("//" for inline, "////" for blocks), which are not rendered when the document is processed. The introductory section in this example contains a citation of a reference, which in this version of AsciiRFC is treated identically to a cross-reference ("<>") -- the crossreference being to the references section of the document. Sections and blocks of texts within the document can also be the target of crossreferences; for example, the section header "=== Operators" is preceded by the anchor Tse, et al. Expires October 20, 2018 [Page 17] Internet-Draft AsciiRFC Specifications April 2018 "[#operators]", and that anchor is already referenced in the section "== Security Considerations". The third last and second last section are tagged with the style attribute "[bibliography]", which identifies them as references containers; the document converter accordingly inserts them into the "back" element under RFC XML. The contents of the references sections are in this instance raw XML, delimited as a passthrough block (with "++++"), which the converter does not alter. The final section is tagged with the style attribute "[appendix]", and is treated as such. The RFC XML v3 document generated from this AsciiRFC document is: A Minimal Internet-Draft In AsciiRFC Brown University
Box K, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 josiah.carberry@ribose.com https://www.brown.edu Tse, et al. Expires October 20, 2018 [Page 18] Internet-Draft AsciiRFC Specifications April 2018
Brown University
Box G, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 truman.grayson@ribose.com https://www.brown.edu
Internet This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the asciidoctor-rfc Ruby gem.
IntroductionAsciiRFC is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to . This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to and submittable to the IETF datatracker.
Terms and DefinitionsThe 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 when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions:
Tse, et al. Expires October 20, 2018 [Page 19] Internet-Draft AsciiRFC Specifications April 2018
AsciiRFC
an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in .
Symbols And Abbreviations
ADRFC
abbreviated form of AsciiRFC
Main contentThis is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes.
Getting startedThe AsciiRFC and RFC toolchains MUST be available locally to build this document template.
AsciiRFC toolchainYou will need to have:
  • Ruby: for running the AsciiRFC toolchain
  • asciidoctor-rfc gem: for converting AsciiRFC into XML RFC (v2 or v3)
XML RFC toolchainYou will need to have:
  • Python: for running xml2rfc
  • xml2rfc: for converting RFC XML (v2 or v3) into TXT
  • idnits: for submission preflight
Referencing external content
  • This is a published RFC
  • This is an Internet-Draft
  • This is an external reference
Code snippets Code snippets should be wrapped with <CODE BEGINS> and Tse, et al. Expires October 20, 2018 [Page 20] Internet-Draft AsciiRFC Specifications April 2018 <CODE ENDS> blocks, as required by the IETF Trust Legal Provisions (TLP) specified in .
Security ConsiderationsAny security considerations should be placed here. As described in (here’s how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools MAY produce unintended side effects that impact security.
IANA ConsiderationsThis document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here.
 Normative References Informative References IETF Trust Legal Provisions (TLP) IETF Tse, et al. Expires October 20, 2018 [Page 21] Internet-Draft AsciiRFC Specifications April 2018 RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
Examples
Example 1Here’s an example of a properly wrapped code snippet in accordance with rules specified in .
{ "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ]]> Tse, et al. Expires October 20, 2018 [Page 22] Internet-Draft AsciiRFC Specifications April 2018
Acknowledgements The authors would like to thank their families.
Figure 2: Sample Internet-Draft In AsciiRFC, Output In RFC XML v3 Format Some default processing instructions have already been prefixed to the XML. Our AsciiRFC converter can also generate RFC XML v2 from the same source AsciiRFC, as shown in Figure 3. Output in RFC XML v2 is not extensively described in this document. ]> Tse, et al. Expires October 20, 2018 [Page 23] Internet-Draft AsciiRFC Specifications April 2018 A Minimal Internet-Draft In AsciiRFC Brown University
Box K, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 josiah.carberry@ribose.com https://www.brown.edu
Brown University
Box G, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 truman.grayson@ribose.com https://www.brown.edu
Internet This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the asciidoctor-rfc Ruby gem.
AsciiRFC is an extremely simple way to author Internet-Drafts and RFCs without needing to manually Tse, et al. Expires October 20, 2018 [Page 24] Internet-Draft AsciiRFC Specifications April 2018 craft RFC XML conforming to . This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to and submittable to the IETF datatracker.
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 when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions: an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in .
abbreviated form of AsciiRFC
This is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes.
The AsciiRFC and RFC toolchains MUST be available locally to build this document template.
You will need to have: Tse, et al. Expires October 20, 2018 [Page 25] Internet-Draft AsciiRFC Specifications April 2018 Ruby: for running the AsciiRFC toolchain asciidoctor-rfc gem: for converting AsciiRFC into XML RFC (v2 or v3)
You will need to have: Python: for running xml2rfc xml2rfc: for converting RFC XML (v2 or v3) into TXT idnits: for submission preflight
This is a published RFC This is an Internet-Draft This is an external reference
Code snippets should be wrapped with <CODE BEGINS> and <CODE ENDS> blocks, as required by the IETF Trust Legal Provisions (TLP) specified in .
Any security considerations should be placed here. As described in (here’s how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools MAY produce unintended side effects that impact security.
This document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, Tse, et al. Expires October 20, 2018 [Page 26] Internet-Draft AsciiRFC Specifications April 2018 please include them here.
 &RFC2119; &RFC7991; &RFC8174; IETF Trust Legal Provisions (TLP) IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
&I-D.ribose-asciirfc; &RFC5378; &RFC7253;
Here’s an example of a properly wrapped code snippet in accordance with rules specified in .
Tse, et al. Expires October 20, 2018 [Page 27] Internet-Draft AsciiRFC Specifications April 2018 { "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ]]>
The authors would like to thank their families.
Figure 3: Sample Internet-Draft In AsciiRFC, Output In RFC XML v2 Format 4. Header And Document Attributes The header gives the document title, followed by an optional author attribution, and a series of document attributes, with no empty lines. 4.1. Title And Basic Attributes Document attributes are used to populate attributes of the root "rfc" element, "front" elements, and document-level processing instructions. o ":doctype:" determines whether the document will be considered "rfc" or "internet-draft", and interprets other attributes accordingly. o Certain attributes ("workgroup", "area", "keyword") are comma delimited, and result in repeated RFC XML elements. Figure 4 demonstrates how to set the document header in AsciiRFC, with its rendering in RFC XML v3 shown in Figure 5. Tse, et al. Expires October 20, 2018 [Page 28] Internet-Draft AsciiRFC Specifications April 2018 = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :area: General, Operations and Management :keyword: rabbits, grenades, antioch, camelot :ipr: trust200902 :toc-include: true :sort-refs: true :revdate: 2018-04-15T00:00:00Z Figure 4: AsciiRFC Document Header The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot grenades camelot Figure 5: AsciiRFC Document Header Rendered As RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 29] Internet-Draft AsciiRFC Specifications April 2018 4.2. Detailed Author Information The document header can spell out further information about authors, including contact details. The AsciiRFC header is shown in Figure 6 with its rendering in RFC XML v3 shown in Figure 7. = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :area: General, Operations and Management :keyword: rabbits, grenades, antioch, camelot :ipr: trust200902 :toc-include: true :sort-refs: true :revdate: 2018-04-15T00:00:00Z :fullname: Arthur son of Uther Pendragon :forename_initials: A. :lastname: Pendragon :email: arthur.pendragon@ribose.com :organization: Camelot :uri: http://camelot.gov.example :street: Palace\ Camel Lot 1 :city: Camelot :region: England :country: United Kingdom Figure 6: AsciiRFC Document Header With One Author Tse, et al. Expires October 20, 2018 [Page 30] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot England United Kingdom arthur.pendragon@ribose.com http://camelot.gov.example
General Operations and Management rabbits grenades antioch camelot Figure 7: AsciiRFC Document Header With One Author (RFC XML v3) Details of a second, third etc. author, including their organization and contact details, are provided by suffixing the relevant author attributes with "_2", "_3" etc., as shown in Figure 8 and its RFC XML v3 rendering Figure 9. Tse, et al. Expires October 20, 2018 [Page 31] Internet-Draft AsciiRFC Specifications April 2018 = An API For Calendar-Based Fortune Heuristics Services Gabriel Destiny; Charise Luck :doctype: internet-draft :abbrev: Calendar Fortune Heuristics API :name: draft-divination-cfapi-00 :status: informational :ipr: trust200902 :area: Internet :submission-type: independent :intended-series: informational :revdate: 2018-03-23T00:00:00Z :lastname: Destiny :fullname: Gabriel Destiny :forename_initials: G. :organization: Divination Inc. :email: gabriel.destiny@ribose.com :street: 9288 N Divine Street :city: Dunn :code: 28334 :region: NC :country: United States of America :lastname_2: Luck :fullname_2: Charise Luck :forename_initials_2: C. :organization_2: Divination Inc. :email_2: charise.luck@ribose.com :street_2: 9288 N Divine Street :city_2: Dunn :code_2: 28334 :region_2: NC :country_2: United States of America Figure 8 Tse, et al. Expires October 20, 2018 [Page 32] Internet-Draft AsciiRFC Specifications April 2018 An API For Calendar-Based Fortune Heuristics Services Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America gabriel.destiny@ribose.com
Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America charise.luck@ribose.com
Internet Figure 9: AsciiRFC Document Header With Multiple Authors (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 33] Internet-Draft AsciiRFC Specifications April 2018 The initial author attribution in AsciiRFC, e.g. "Gabriel Destiny; Charlise Luck" in the example above, expects a strict format of First Name, zero or more Middle Names, Last name, and cannot process honorifics like "Dr." or suffixes like "Jr.". Name attributes with any degree of complexity should be overriden by using the ":fullname:" and ":lastname:" attributes. The AsciiRFC ":forename_initials:" attribute replaces the built-in Asciidoctor syntax ":initials:" attribute (which includes the surname initial), and is not automatically populated from the name attribution. 4.3. XML Processing Information A document header may also contain attribute headers which are treated as XML processing instructions. An AsciiRFC example is shown in Figure 10 with its rendering in Figure 11. (Note that several processing instructions are included by default in the output of the AsciiRFC processor.) = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :ipr: trust200902 :comments: yes :notedraftinprogress: yes Figure 10: AsciiRFC Document Header With XML Processing Information Tse, et al. Expires October 20, 2018 [Page 34] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot grenades Figure 11: AsciiRFC Document Header With XML Processing Information (RFC XML v3) In the foregoing, values for the processing instructions "strict", "compact", "toc" etc are included by default; but "comments" and "notedraftinprogress" are included as specified in the AsciiRFC document header. The default values provided for processing instructions can in fact be overriden through the AsciiRFC document header. 4.4. AsciiRFC-specific Document Attributes A few document attributes are specific to the operation of the RFC XML document converter: Tse, et al. Expires October 20, 2018 [Page 35] Internet-Draft AsciiRFC Specifications April 2018 :no-rfc-bold-bcp14: false overrides the wrapping by default of boldface uppercase BCP14 [RFC2119] words (e.g. "*MUST NOT*") with the "bcp14" element. :smart-quotes: false overrides Asciidoctor's conversion of straight quotes and apostrophes to smart quotes and apostrophes. :inline-definition-lists: true overrides the RFC XML v2 "idnits" requirement that a blank line be inserted between a definition list term and its definition. = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :status: informational :name: draft-camelot-holy-grenade-00 == Section 1 The specification *MUST NOT* use the word _doesn't_. Figure 12: AsciiRFC Document Header Without RFC-specific Attributes Tse, et al. Expires October 20, 2018 [Page 36] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch
Section 1 The specification MUST NOT use the word doesn’t.
Figure 13: AsciiRFC Document Header Without RFC-specific Attributes (RFC XML v3) = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :status: informational :name: draft-camelot-holy-grenade-00 :no-rfc-bold-bcp14: false :smart-quotes: false == Section 1 The specification *MUST NOT* use the word _doesn't_. Figure 14: AsciiRFC Document Header With Overridden RFC-specific Attributes Tse, et al. Expires October 20, 2018 [Page 37] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch
Section 1 The specification MUST NOT use the word doesn't.
Figure 15: AsciiRFC Document Header With Overridden RFC-specific Attributes (RFC XML v3) 5. Preamble The preamble in AsciiRFC is the text between the end of the document header (which terminates with a blank line) and the first section of text. Any paragraphs of text in the preamble are treated as an abstract, and may optionally be tagged with the "abstract" style attribute. Any notes in the preamble are treated as a "note" element. An example of setting the preamble is given in Figure 16 with its rendering in Figure 17. Tse, et al. Expires October 20, 2018 [Page 38] Internet-Draft AsciiRFC Specifications April 2018 [abstract] The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. [NOTE,remove-in-rfc=false] .Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635. Figure 16: AsciiRFC With Preamble The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635. Figure 17: AsciiRFC With Preamble (RFC XML v3) 6. Sections and Paragraphs Section headers are given with a sequence of "=", where the number of instances of "=" gives the header level. The document itself opens Tse, et al. Expires October 20, 2018 [Page 39] Internet-Draft AsciiRFC Specifications April 2018 with a single "=", and sections within it must be started with a minimum of "==". Section numbering is toggled with the in-document attribute ":sectnums:" (on), ":sectnums!:" (off). The boolean "toc" attribute can also be set on sections, indicating whether the section can be included in the document's table of contents. Figure 18 shows how sections and paragraphs are used in AsciiRFC, and its rendered form is shown in Figure 19. [toc=exclude] :sectnums!: == 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 <> <> when, and only when, they appear in all capitals, as shown here. :sectnums: == Introduction <> refers to the intended move of RFC formatting to XML2RFC v3 <>, in the following terms: Figure 18: AsciiRFC With Sections Tse, et al. Expires October 20, 2018 [Page 40] Internet-Draft AsciiRFC Specifications April 2018
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 when, and only when, they appear in all capitals, as shown here.
Introduction refers to the intended move of RFC formatting to XML2RFC v3 , in the following terms: Figure 19: AsciiRFC With Sections (RFC XML v3) Note that skipped sections, such as defining a section using "====" within a section defined using "==", is not allowed in AsciiRFC syntax. Doing so will trigger an error with the following message: asciidoctor: WARNING: _filename_: line _X_: section title out of sequence: expected level 2, got level 3 7. Figures AsciiRFC examples (corresponding to RFC XML Figures), source code Listings, and Literals (preformatted text) are all delimited blocks. Listings and Literals can occur nested within Examples. An AsciiRFC example with a figure is given in Figure 20, and its rendering in Figure 21. [[killer-bunny]] .A Photo Of The Killer Rabbit of Caerbannog Taken In Secret ==== [alt=The Killer Bunny, in ASCII] .... \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Tse, et al. Expires October 20, 2018 [Page 41] Internet-Draft AsciiRFC Specifications April 2018 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\^^^^^^^^^^^^^^^^^^^^^^\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\<<#MWSHARPMWMWMWTEETHWMWWM>>>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ .... ==== [[killer-source]] .C Code To Lure Killer Rabbit Back To Cave ==== [source,c] ---- /* Locate the Killer Rabbit */ int type; unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); return LOST_CREATURE; } Tse, et al. Expires October 20, 2018 [Page 42] Internet-Draft AsciiRFC Specifications April 2018 /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ---- ==== Figure 20: AsciiRFC With A Figure
A Photo Of The Killer Rabbit of Caerbannog Taken In Secret >>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM Tse, et al. Expires October 20, 2018 [Page 43] Internet-Draft AsciiRFC Specifications April 2018 MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ ]]>
C Code To Lure Killer Rabbit Back To Cave /* Locate the Killer Rabbit */ int type; unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); return LOST_CREATURE; } /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } Tse, et al. Expires October 20, 2018 [Page 44] Internet-Draft AsciiRFC Specifications April 2018 /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ]]>
Figure 21: AsciiRFC With A Figure (RFC XML v3) If an AsciiRFC Listing or Literal occurs outside of an Example (Figure 22), the RFC XML converter will supply the surrounding Figure element (Figure 23). [[hand-grenade-figure]] .The Holy Hand Grenade of Antioch (don't pull the pin) Figure 22: AsciiRFC With ASCII Art Without Figure Wrapping ______ \\/ \/ __\\ /__ || //\ | ||__\\/ __| || | ,---, || |====`\ | || | '---' ,--'*`--, _||#|***|#| _,/.-'#|* *|#`-._ ,,-'#####| |#####`-. ,,'########| |########`, //##########| o |##########\ ||###########| |###########| ||############| o |############| ||------------' '------------| ||o o o o o o o o o o| |-----------------------------| ||###########################| \\#########################/ `..#####################,' ``..###############_,' ``--.._____..--' `''-----''` Tse, et al. Expires October 20, 2018 [Page 45] Internet-Draft AsciiRFC Specifications April 2018
The Holy Hand Grenade of Antioch (don't pull the pin)
Figure 23: AsciiRFC With ASCII Art Without Figure Wrapping (RFC XML v3) 8. Lists Tse, et al. Expires October 20, 2018 [Page 46] Internet-Draft AsciiRFC Specifications April 2018 8.1. Basic Lists AsciiRFC supports ordered, unordered, and definition lists. Indentation of ordered and unordered lists is indicated by repeating the list item prefix ("*" and "." respectively); for definition lists, it is indicated by incrementing the number of definition term delimiters ("::"). List attributes can be used to specify the type of symbol used for ordered lists. An example of an unordered list is shown in Figure 24 (with its rendered version in Figure 25). An example of an ordered list with ordered and unordered sublists is shown in Figure 26 (with its rendered version in Figure 27). An example of a definition list is shown in Figure 28 (with its rendered version in Figure 29). * Killed ** Sir Bors ** Sir Gawain ** Sir Ector * Soiled Himself ** Sir Robin * Panicked ** King Arthur * Employed Ordnance ** The Lector ** Brother Maynard * Scoffed ** Tim the Enchanter Figure 24: AsciiRFC With Unordered lists Tse, et al. Expires October 20, 2018 [Page 47] Internet-Draft AsciiRFC Specifications April 2018
  • Killed
    • Sir Bors
    • Sir Gawain
    • Sir Ector
  • Soiled Himself
    • Sir Robin
  • Panicked
    • King Arthur
  • Employed Ordnance
    • The Lector
    • Brother Maynard
  • Scoffed
    • Tim the Enchanter
Figure 25: AsciiRFC With Unordered Lists (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 48] Internet-Draft AsciiRFC Specifications April 2018 . Preamble: St Attila Benediction . Feast of the People on Sundry Foods ** Lambs ** Sloths ** Carp ** Anchovies ** Orangutangs ** Breakfast Cereals ** Fruit Bats ** _et hoc genus omne_ . Take out the Holy Pin . The Count [upperalpha] .. Count is to Three: no more, no less .. Not Four .. Nor Two, except if the count then proceeds to Three .. Five is Right Out . Lob the Holy Hand Grenade of Antioch towards the Foe . The Foe, being naughty in the *LORD's* sight, [bcp14]#shall# snuff it Figure 26: AsciiRFC With Ordered lists Tse, et al. Expires October 20, 2018 [Page 49] Internet-Draft AsciiRFC Specifications April 2018
  1. Preamble: St Attila Benediction
  2. Feast of the People on Sundry Foods
    • Lambs
    • Sloths
    • Carp
    • Anchovies
    • Orangutangs
    • Breakfast Cereals
    • Fruit Bats
    • et hoc genus omne
  3. Take out the Holy Pin
  4. The Count
    1. Count is to Three: no more, no less
    2. Not Four
    3. Nor Two, except if the count then proceeds to Three
    4. Five is Right Out
  5. Lob the Holy Hand Grenade of Antioch towards the Foe
  6. The Foe, being naughty in the LORD's sight, SHALL snuff it
Figure 27: AsciiRFC With Ordered Lists (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 50] Internet-Draft AsciiRFC Specifications April 2018 Holy Hand Grenade of Antioch:: Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See <>. Holy Spear of Antioch:: A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098. Sovereign's Orb of the United Kingdom:: Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See <>. Figure 28: AsciiRFC With Definition lists
Holy Hand Grenade of Antioch
Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See .
Holy Spear of Antioch
A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098.
Sovereign's Orb of the United Kingdom
Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See .
Figure 29: AsciiRFC With Definition Lists (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 51] Internet-Draft AsciiRFC Specifications April 2018 8.2. List Continuation A list item by default spans a single paragraph. A following paragraph or other block element can be appended to the current list item by prefixing it with "+" in a separate line. See the "List Continuation" section in [Asciidoctor-Manual] for more information. An example of list continuation with text is shown in Figure 30 with its rendered version in Figure 31. Trojan Rabbit:: In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." + The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the French soldiers took the Trojan Rabbit inside the castle. Killer Rabbit of Caerbannog:: Guarding the entrance to the Cave of Caerbannog; see <>. Figure 30: AsciiRFC List With Text Continuation Tse, et al. Expires October 20, 2018 [Page 52] Internet-Draft AsciiRFC Specifications April 2018
Trojan Rabbit
In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the French soldiers took the Trojan Rabbit inside the castle.
Killer Rabbit of Caerbannog
Guarding the entrance to the Cave of Caerbannog; see .
Figure 31: AsciiRFC List With Text Continuation (RFC XML v3) (Multiple paragraphs are not permitted within a list item in RFC XML v2. The RFC XML converter deals with this by converting paragraph breaks into line breaks within a list item.) List continuations can also be embedded to populate a list item with a sequence of blocks as a unit (in an Asciidoctor syntax open block). An example of list continuation with a delimited block is shown in Figure 32 with its rendered version in Figure 33. Tse, et al. Expires October 20, 2018 [Page 53] Internet-Draft AsciiRFC Specifications April 2018 . Take out the Holy Pin . The Count + ---- integer count; for count := 1 step 1 until 3 do say(count) comment Five is Right Out ---- . Lob the Holy Hand Grenade of Antioch towards the Foe . Foe snuffs it Figure 32: AsciiRFC List With Block Continuation
  1. Take out the Holy Pin
  2. The Count
  3. Lob the Holy Hand Grenade of Antioch towards the Foe
  4. Foe snuffs it
Figure 33: AsciiRFC List With Block Continuation (RFC XML v3) AsciiDoc, and thus AsciiRFC, considers paragraphs to be the basic level of blocks, and does not permit lists to be nested within them: any text after a list is considered to be a new paragraph. Therefore, markup as shown in Figure 34 cannot be generated via AsciiRFC. Tse, et al. Expires October 20, 2018 [Page 54] Internet-Draft AsciiRFC Specifications April 2018 This is the start of a paragraph.
  • List Entry 1
  • List Entry 2 Note 2.
And this is the continuation of the paragraph. Figure 34: This RFC XML v3 Output Cannot Be Generated Using AsciiRFC 9. Blockquotes Asciidoctor syntax supports blockquotes and quotations of verse; its block quotations permit arbitrary levels of quote nesting. RFC XML v3, and thus AsciiRFC, only supports one level of blockquotes. Unlike RFC XML v2, RFC XML v3 does not support line breaks outside of tables, so verse quotations are converted to prose in the v3 converter. An example of using AsciiRFC Blockquotes is given in Figure 35 with its rendered version in Figure 36. [quote,attribution="A. Farrel"] ____ Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence. ____ Figure 35: AsciiRFC Blockquote Usage Tse, et al. Expires October 20, 2018 [Page 55] Internet-Draft AsciiRFC Specifications April 2018
Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence.
Figure 36: AsciiRFC Blockquote Usage (RFC XML v3) 10. Notes And Asides Asciidoctor syntax supports a range of "admonitions", including notes, warnings, and tips. They are indicated by a paragraph prefix (e.g. "WARNING:"), or as a block with an admonition style attribute. All admonitions are conflated in AsciiRFC, being converted to "note" elements in the document preamble, and "cref" elements in the main document. This means that no admonitions will therefore appear in the textual output, unless forced to through the "comments" processing instruction. A sample admonition is shown in Figure 37, with its rendered output in Figure 38. [NOTE,display=true,source=Author] ==== Image courtesy of https://camelot.gov.example/creatures-in-ascii/ ==== Figure 37: An AsciiRFC Adminition Block Tse, et al. Expires October 20, 2018 [Page 56] Internet-Draft AsciiRFC Specifications April 2018 Image courtesy of Figure 38: An AsciiRFC Adminition Block (RFC XML v3) With RFC XML v2, note that no inline formatting is permitted for "cref" elements, and any such formatting is therefore stripped for v2 by the converter. Because paragraphs in AsciiRFC cannot contain any other blocks, a comment at the end of a paragraph is treated as a new block. In the document converter, any such comments are moved inside the preceding RFC XML paragraph; if the comment is at the start of a section, as in the example above, it is wrapped inside a paragraph. The RFC XML v3 converter also supports "asides" (Asciidoctor syntax Sidebars). A sample is shown in Figure 39, with its rendered output in Figure 40. **** While the exchange at the French-occupied castle is one of the more memorable scenes of _Monty Python and the Holy Grail_, the Trojan Rabbit has not reached the same level of cultural resonance as its more murderous counterpart. Reasons for this may include: * Less overall screen-time dedicated to the Trojan Rabbit. * The Trojan Rabbit as projectile has already been anticipated by the Cow as projectile. **** Figure 39: An AsciiRFC Sidebar Block Tse, et al. Expires October 20, 2018 [Page 57] Internet-Draft AsciiRFC Specifications April 2018 Figure 40: An AsciiRFC Sidebar Block Rendered As An Aside (RFC XML v3) Comments given in AsciiDoc syntax (notated with initial "//") are not intended to be shown in the rendered output, and will not appear in the output as XML comments. XML comments can be generated by using the "[comment]#...#" inline formatting macro, or the "[.comment]" role attribute on blocks. A sample is shown in Figure 39 with its rendered output in Figure 40. The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, [comment]#TODO: Will need to verify that claim.# which arguably predates the traditional English enmity with the French. [comment]#Strictly speaking, the Knights are Welsh.# [.comment] -- This document, as it turns out, has a profusion of XML comments. As expected, they are ignored in any rendering of the document. -- Figure 41: AsciiRFC delimited text intended as an XML Comment Tse, et al. Expires October 20, 2018 [Page 58] Internet-Draft AsciiRFC Specifications April 2018 The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, which arguably predates the traditional English enmity with the French. Figure 42: AsciiRFC delimited text Rendered As An XML Comment (RFC XML v3) 11. Tables AsciiRFC tables, like RFC XML v3, support distinct table heads, bodies and feet; cells spanning multiple rows and columns; and horizontal alignment. The larger range of table formatting options available in RFC XML v2 is also supported. A sample of an AsciiRFC table is shown in Figure 43, with its rendered output in Figure 44. Neither version of RFC XML is as expressive in its table structure as Asciidoctor syntax. RFC XML, for example, does not permit blocks within table cells. Tse, et al. Expires October 20, 2018 [Page 59] Internet-Draft AsciiRFC Specifications April 2018 [grid=all,options="footer"] |=== |French Castle | Cave of Caerbannog 2+|King Arthur 2+|Patsy 2+|Sir Bedevere the Wise 2+|Sir Galahad the Pure 2+|Sir Lancelot the Brave 2+|Sir Robin the Not-quite-so-brave-as-Sir-Lancelot |French Guard with Outrageous Accent| Tim the Enchanter |Other French Guards | Brother Maynard | | The Lector .3+^|not yet recruited >|Sir Bors >|Sir Gawain >|Sir Ector |Retinue of sundry knights |Retinue of sundry more knights than at the French Castle |=== Figure 43: An AsciiRFC Table Tse, et al. Expires October 20, 2018 [Page 60] Internet-Draft AsciiRFC Specifications April 2018
French Castle Cave of Caerbannog
King Arthur
Patsy
Sir Bedevere the Wise
Sir Galahad the Pure
Sir Lancelot the Brave
Sir Robin the Not-quite-so-brave-as-Sir-Lancelot
French Guard with Outrageous Accent Tim the Enchanter
Other French Guards Brother Maynard
The Lector
not yet recruited Sir Bors
Sir Gawain
Sir Ector
Retinue of sundry knights Retinue of sundry more knights than at the French Castle
Figure 44: An AsciiRFC Table (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 61] Internet-Draft AsciiRFC Specifications April 2018 12. Inline Formatting 12.1. Italics, Boldface, Monospace, Subscripts, Superscripts AsciiRFC supports italics, boldface, monospace, subscripts and superscripts, just like RFC XML v3. The inline formatting syntax given in Figure 45 produces the RFC XML v3 output given in Figure 46. The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the _Knights of the Round Table_ and the taunting French soldiers serving under *Guy de Lombard* are, properly speaking, outside the scope of this `menagerie`, being more or less human. Notwithstanding, several^ish^ beasts both animate~d~ and wooden played a significant part in this encounter; most notably: * The Projectile Cow, see <> * The Trojan Rabbit, see <> Figure 45: Inline Formatting In AsciiRFC Tse, et al. Expires October 20, 2018 [Page 62] Internet-Draft AsciiRFC Specifications April 2018 The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the Knights of the Round Table and the taunting French soldiers serving under Guy de Lombard are, properly speaking, outside the scope of this menagerie, being more or less human. Notwithstanding, severalish beasts both animated and wooden played a significant part in this encounter; most notably:
  • The Projectile Cow, see
  • The Trojan Rabbit, see
Figure 46: Inline Formatting In AsciiRFC (RFC XML v3) 12.2. Formatting BCP 14 Keywords RFC XML v3 also supports tagging of BCP14 keywords [RFC2119] [RFC8174]; this is done in AsciiRFC either by tagging them with a custom formatting span (e.g. "MUST NOT"), or by converting any boldface all-caps words recognised as BCP14 words (unless the ":no- rfc-bold-bcp14: false" document attribute is set). Any spans of BCP14 text delimited by inline formatting delimiters need to be contained within a single line of text; in Asciidoctor syntax, formatting spans are broken up across line breaks. This usage is demonstrated in Figure 47 with the rendered output in Figure 48. The instructions in the _Book of Armaments_ on the proper deployment of the Holy Hand Grenade of Antioch [bcp14]#may# be summarized as follows, although this summary *SHALL NOT* be used as a substitute for a reading from the Book of Armaments: Figure 47: BCP14 Keywords In AsciiRFC Tse, et al. Expires October 20, 2018 [Page 63] Internet-Draft AsciiRFC Specifications April 2018 The instructions in the Book of Armaments on the proper deployment of the Holy Hand Grenade of Antioch MAY be summarized as follows, although this summary SHALL NOT be used as a substitute for a reading from the Book of Armaments: Figure 48: BCP14 Keywords In AsciiRFC (RFC XML v3) 12.3. Escaping AsciiRFC Syntax Formatting delimiters like "*" can be escaped with backslash ("\*"); double formatting delimiters, like "**" and "__", need to be escaped with double backslash ("\\**"). Escaping delimiters is not always reliable, and for double delimiters it is preferable to use HTML entities ("**"), or attribute references (references to the value of attributes set in the document header) as shown in Figure 49. :dblast: ** `{dblast}` Figure 49: Escaping AsciiRFC Syntax Using Attributes In extreme circumstances (such as quoting AsciiDoc syntax), you may need to resort to altering the substitutions behaviour within a given block of of AsciiDoc; see the "Applying Substitutions" section of [Asciidoctor-Manual]. 13. Links Common URL formats are recognised automatically as hyperlinks in AsciiRFC, which inherits this excellent feature from AsciiDoc, and are rendered as such. Any hyperlinked text is appended after the hyperlink in square brackets. An example is given in Figure 50 with its rendered version in Figure 51. Tse, et al. Expires October 20, 2018 [Page 64] Internet-Draft AsciiRFC Specifications April 2018 <> of the fearsome beast has been sourced from http://camelot.gov.example/avatars/rabbit[Rabbit-SCII], <> by C code that was used in this accurate depiction of the Killer Rabbit: Figure 50: An AsciiRFC Link The following depiction of the fearsome beast has been sourced from Rabbit-SCII, accompanied by C code that was used in this accurate depiction of the Killer Rabbit: Figure 51: An AsciiRFC Link (RFC XML v3) To prevent hyperlinking of a URL, prefix it with a backslash, as shown in Figure 52 with its rendered version in Figure 53. The screaming move into the twenty-*first* century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like \ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) Figure 52: A Literal AsciiRFC Link Tse, et al. Expires October 20, 2018 [Page 65] Internet-Draft AsciiRFC Specifications April 2018 The screaming move into the twenty-first century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) Figure 53: A Literal AsciiRFC Link (RFC XML v3) 14. Cross-References 14.1. Basic Referencing Anchors for cross-references are notated as "[[...]]" or "[#...]", and can be inserted on their own line in front of most blocks. Asciidoctor syntax supports anchors in a much wider range of contexts than is supported than RFC XML v3 (let alone v2); anchors that are not supported for that version of RFC XML are simply ignored by the converter. Note that anchors in RFC XML are constrained to the format "[A-Za- z_:][[A-Za-z0-9_:.-]*" (i.e. "xsd:ID"). Cross-references to anchors are notated as "<<...>>"; cross- references with custom text as "<>". An example of using cross-references in AsciiRFC is given in Figure 54 with its rendered output in Figure 55. Tse, et al. Expires October 20, 2018 [Page 66] Internet-Draft AsciiRFC Specifications April 2018 The _Cave of Caerbannog_ has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the *Killer Rabbit of Caerbannog* <>. It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the <>), that we recount here through monospace font and multiple spaces. [[killer_rabbit_caerbannog]] === The Killer Rabbit of Caerbannog Figure 54: Setting And Referring To Cross-References In AsciiRFC The Cave of Caerbannog has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the Killer Rabbit of Caerbannog . It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the following section), that we recount here through monospace font and multiple spaces.
The Killer Rabbit of Caerbannog Figure 55: Setting And Referring To Cross-References In AsciiRFC (RFC XML v3) 14.2. Referencing With Attributes While Asciidoctor syntax natively does not support attributes on cross-references, AsciiRFC works around that by embedding formatting information as templated text within cross-references: o "format= x: text" populates the "xref@format" attribute Tse, et al. Expires October 20, 2018 [Page 67] Internet-Draft AsciiRFC Specifications April 2018 o a section number followed by one of the words "of", "parens", "bare", "text" is treated as a "relref" reference to an external document. An example of referencing with attributes is given in Figure 56 with its output in Figure 57. The *Killer Rabbit of Caerbannog*, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, _contra_ the claim made in <>, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as <>, there are few remedies known against its awful lapine powers. Figure 56: Cross-References With Attributes In AsciiRFC The Killer Rabbit of Caerbannog, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, contra the claim made in Ze Vompyre, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as , there are few remedies known against its awful lapine powers. Figure 57: Cross-References With Attributes In AsciiRFC (RFC XML v3) 14.3. Indexing Inline index entries are notated as "((...))". Index entries which do not appear in the text are notated as "(((...)))"; such entries may include a separate sub-entry, separated from the main entry by comma. Tse, et al. Expires October 20, 2018 [Page 68] Internet-Draft AsciiRFC Specifications April 2018 The solution to the impasse at the ((Cave of Caerbannog)) was provided by the successful deployment of the *Holy Hand Grenade of Antioch* (see <>) (((Holy Hand Grenade of Antioch))). Any similarity between the Holy Hand Grenade of Antioch and the mythical _Holy Spear of Antioch_ is purely intentional; (((relics, Christian))) any similarity between the Holy Hand Grenade of Antioch and the _Sovereign's Orb of the United Kingdom_ (see <>) is putatively fortuitous. (((relics, monarchic))) Figure 58: AsciiRFC Index Entries The solution to the impasse at the Cave of Caerbannog was provided by the successful deployment of the Holy Hand Grenade of Antioch (see ) . Any similarity between the Holy Hand Grenade of Antioch and the mythical Holy Spear of Antioch is purely intentional; any similarity between the Holy Hand Grenade of Antioch and the Sovereign's Orb of the United Kingdom (see ) is putatively fortuitous. Figure 59: AsciiRFC Index Entries (RFC XML v3) 15. Inclusions AsciiRFC inherits the Asciidoctor syntax "include" directive [Asciidoctor-Manual] to include external files in a master AsciiRFC document. This directive is capable of sophisticated document merging, including adjusting the heading levels of the included text, selecting text within specified tags or line numbers to be included, and adjusting the indentation of code snippets in merged text. Tse, et al. Expires October 20, 2018 [Page 69] Internet-Draft AsciiRFC Specifications April 2018 Its basic syntax is given in Figure 60. include::path[ leveloffset=_offset_, lines=_ranges_, tag(s)=_name(s)_, indent=_depth_ ] Figure 60: Inclusions In AsciiRFC If a file is included in an AsciiRFC document, ensure it ends with a blank line. An inclusion that results in its final block not being delimited with a blank line from what follows can lead to unpredictable results. 16. Encoding and Entities XML accepts the full range of characters in the world's languages through UTF-8 character encoding, and one of the motivations for the move by the IETF from plain text to RFC XML has been to allow non- ASCII characters to be included in RFCs. However, current RFC XML v2 tools still do not support UTF-8, and alternative tooling support for UTF-8 also remains patchy. Out of an abundance of caution, the RFC XML converter uses US-ASCII for its character encoding, and renders any non-ASCII characters as HTML entities. AsciiRFC accepts HTML entities as input, even though they are not part of the W3C XML specification. HTML entities such as " " feature in examples of RFC XML provided by the IETF. In order to prevent dependence of the XML output from extraneous entity definitions, any such entities are rendered in the XML as decimal character entities. An example of how AsciiRFC renders non-ASCII UTF-8 characters are given in Figure 61 with the output in Figure 62. Tse, et al. Expires October 20, 2018 [Page 70] Internet-Draft AsciiRFC Specifications April 2018 ____ .כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה .מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh." ____ Figure 61: UTF-8 Characters In AsciiRFC
כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh."
Figure 62: UTF-8 Characters In AsciiRFC Rendered As RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 71] Internet-Draft AsciiRFC Specifications April 2018 Note that because initial period is a formatting character in Asciidoctor, we have had to use "." to escape the period at the end of Hebrew sentences (which appears at the start of the line, Hebrew being written Right-to-Left). Asciidoctor is not natively equipped to deal with Right-to-Left languages in its formatting parsing. 17. Bibliography The simple encoding of bibliography syntax provided by AsciiDoc (and Asciidoctor syntax) is inadequate for the complexity of bibliographic markup required by RFC XML. RFC documents overwhelmingly cite other RFC documents, and canonical RFC XML bibliographic entries are available at [IETF-BibXML]; so it would be inefficient to encode those entries natively in AsciiRFC, only to have them converted back to RFC XML. The converter provides two means of incorporating bibliographies into RFC documents authored in AsciiRFC: o using raw RFC XML; and o assembling bibliographies in preprocessing. In either case, the RFC XML needs to be well-formed; missing closing tags can lead to erratic behaviour in the converter. 17.1. Using Raw RFC XML In the first method, bibliographic citations are handled like all other AsciiRFC cross-references. The bibliographic entries for normative and informative references are given in the AsciiRFC as passthrough blocks, which contain the raw RFC XML for all references; document conversion leaves the raw RFC XML in place. This approach requires authors to maintain the normative and informative bibliographies within the document, to update them as citations are added and removed, and to sort them manually. However, if the citation is stored on the IETF's RFC XML citation libraries (see ), AsciiRFC will automatically replace it with an external reference to that citation. So the body of the citation XML can be left out. For example, the AsciiRFC in Figure 63 will generate the corresponding RFC XML v3 output in Figure 64. Tse, et al. Expires October 20, 2018 [Page 72] Internet-Draft AsciiRFC Specifications April 2018 [bibliography] == Normative References ++++ Key words for use in RFCs to Indicate Requirement Levels ++++ [bibliography] == Informative References ++++ Monty Python and the Holy Grail DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) Tse, et al. Expires October 20, 2018 [Page 73] Internet-Draft AsciiRFC Specifications April 2018 RFC Format Framework The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce Tse, et al. Expires October 20, 2018 [Page 74] Internet-Draft AsciiRFC Specifications April 2018 the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ++++ Figure 63: AsciiRFC Inline Bibliography Tse, et al. Expires October 20, 2018 [Page 75] Internet-Draft AsciiRFC Specifications April 2018
Normative References Informative References Monty Python and the Holy Grail Figure 64: AsciiRFC Inline Bibliography Rendered As RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 76] Internet-Draft AsciiRFC Specifications April 2018 17.2. Preprocessing Using "asciidoctor-bibliography" The alternative method is to use a preprocessing tool, [asciidoctor-bibliography], to import citations into the AsciiRFC document from an external file of references. The references file consists of RFC XML reference entries, and still needs to be managed manually; however the bibliographies are assembled from that file, sorted, and inserted into the normative and informative references in preprocessing. Citations in the document itself are given as macros to be interpreted by the preprocessor; this allows them to be split into normative and informative references. (The MMark tool likewise splits reference citations into normative and informative.) Integration with the "asciidoc-bibliography" gem proceeds as follows: 1. Create an RFC XML references file, consisting of a "" element with individual "" elements inserted, as would be done for the informative and normative references normally. The references file will contain all possible references to be used in the file; the bibliography gem will select which references have actually been cited in the document. A. Rather than hand crafting RFC XML references for RFC documents, you should download them from an authoritative source; e.g., "http://xml.resource.org/public/rfc/bibxml/\ reference.RFC.2119.xml". Note that RFC XML references from this link contains the XML document declaration, which needs to be removed before being used in the XML bibliography. B. Unlike the case for RFC XML documents created manually, the references file does not recognise XML entities and will not attempt to download them during processing. Any references to "http://xml.resource.org/public/rfc/bibxml/\ " will need to be downloaded and inserted into the references file. C. The RFC XML in the references file will need to be appropriate to the version of RFC XML used in the main document, as usual. Note that RFC XML v2 references are forward compatible with v3; v3 contains a couple of additional elements. 2. Add to the main document header attributes referencing the references file (":bibliography-database:"), and the bibliography style (":bibliography-style: rfc-v3"). Tse, et al. Expires October 20, 2018 [Page 77] Internet-Draft AsciiRFC Specifications April 2018 3. References to a normative reference are inserted with the macro "cite:norm[id]" instead of "<>", where "id" is the anchor of the reference. 4. References to an informative reference are inserted with the macro "cite:info[id]" instead of "<>", where "id" is the anchor of the reference. 5. Formatted crossreferences and "relref" crossreferences are entered by inserting the expected raw XML in the "text" attribute. Do not use the "{cite}" interpolation of the citation. For example: * "<>" = "cite:norm[id, text="words"]" * "<>" (processed as a formatted cross-reference) = "cite:norm[id, text="words"]" * "<>" (processed as relref) = "cite:norm[id, text=""]" * "<>" (processed as relref with a cross-document internal reference) = "cite:norm[id, text=""]" 6. Normative and Informative References are inserted in the document through a macro, which occurs where the RFC XML references would be inserted, as shown in Figure 65. Tse, et al. Expires October 20, 2018 [Page 78] Internet-Draft AsciiRFC Specifications April 2018 [bibliography] == Normative References ++++ bibliography::norm[] ++++ [bibliography] == Informative References ++++ bibliography::info[] ++++ Figure 65: Using asciidoctor-bibliography For Bibliography Preprocessing 18. RFC XML features not supported in Asciidoctor The following features of RFC XML v3 [RFC7991] and v2 [RFC7749] are not supported by the AsciiRFC converter, and would need to be adjusted manually after RFC XML is generated: +------------------------+--------------------+---------------------+ | RFC XML element | RFC XML v3 | RFC XML v2 | +------------------------+--------------------+---------------------+ | "front/boilerplate" | Not added by the | Not added by the | | | converter | converter | | "iref@primary" | N | N | | "reference" (and all | As Raw XML | As Raw XML | | children) | | | | "table/preamble" | Deprecated | N | | "table/postamble" | Deprecated | N | | "artwork@width" | Only on images | Only on images | | "artwork@height" | Only on images | Only on images | +------------------------+--------------------+---------------------+ 19. Authoring To author an AsciiRFC document, you should first familiarise yourself with the [Asciidoctor-Manual]. The [asciidoctor-rfc] Ruby gem source code distribution also has samples of individual RFC XML features in v2 and v3, and examples of self-standing AsciiRFC documents, along with their RFC XML renderings. (This includes round-tripped RFC XML documents.) Tse, et al. Expires October 20, 2018 [Page 79] Internet-Draft AsciiRFC Specifications April 2018 19.1. Using the "rfc-asciirfc-minimal" template In addition, you can clone the sample "rfc-asciirfc-minimal" repository as a template, and populate it for your AsciiRFC document using the steps shown in Figure 66. $ git clone https://github.com/riboseinc/rfc-asciirfc-minimal Figure 66: Cloning The AsciiRFC Document Template 19.2. Installing AsciiRFC Backend Processors Converting your AsciiRFC to RFC XML is a simple as installing the Asciidoctor Ruby gem "asciidoctor" (see "Installation" at [Asciidoctor]) and the "asciidoctor-rfc" gem in Ruby (through RubyGems), then running the "asciidoctor" executable on the document, specifying the "asciidoctor-rfc" gem as a library. The necessary steps are shown in Figure 67. $ gem install asciidoctor-rfc $ asciidoctor -b rfc3 -r 'asciidoctor-rfc' foo.adoc # RFC XML v3 output $ asciidoctor -b rfc2 -r 'asciidoctor-rfc' foo.adoc # RFC XML v2 output Figure 67: Installing The AsciiRFC Backend Processors 19.3. Iterating AsciiRFC Content As you author AsciiRFC content, you should iterate by running the AsciiRFC conversion frequently, to ensure that you are still generating valid XML through your markup. The converter makes an effort to ensure that its XML output is valid, and it issues warnings about likely issues; it also validates its own XML output against the RFC XML schema (of the corresponding version), and reports errors in the XML output in the format shown in Figure 68. V3 RELAXNG Validation: 12:0: ERROR: Invalid attribute sortRefs for element rfc Figure 68: Sample Validation Error Message From AsciiRFC Note that validation against the Relax NG RFC XML schema includes confirming the referential integrity of all cross-references in the document. It may be necessary to intervene in the XML output generated by the converter, either because the block model of AsciiRFC does not conform with the intended RFC XML (e.g. lists embedded in Tse, et al. Expires October 20, 2018 [Page 80] Internet-Draft AsciiRFC Specifications April 2018 paragraphs), or because RFC XML features are required that are not supported within AsciiRFC. 20. Security Considerations o Ensure your AsciiRFC generator comes from a geniune and trustworthy source. This protects your own machine and also prevents injection of malicious content in your resulting document. o An AsciiRFC generator may cause errors in textual rendering or link generation that may lead to security issues. o Creating cross-references (and also bibliographic references) to external documents may pose risks since the specified external location may become controlled by a malicious party. o URIs that start with the "http:" or "https:" prefix are automatically converted into links in AsciiRFC except when escaped with a backslash before the prefix. A URI that is intended to be text but unintentionally rendered as a link may cause users to visit a malicious website with security consequences. o AsciiRFC contains syntax that can directly incorporate remote URI content, such as "include::" which allows remotely-located AsciiRFC content files. If a remote URI contains malicious content, this content will be included in the resulting AsciiRFC document compiled as RFC XML. Remotely-linked URIs should always be checked for malicious content prior to compiling AsciiRFC into RFC XML. 21. IANA Considerations This document does not require any action by IANA. 22. References 22.1. Normative References [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, . 22.2. Informative References [AsciiDoc] Rackham, S., "AsciiDoc: Text based document generation", November 2013, . Tse, et al. Expires October 20, 2018 [Page 81] Internet-Draft AsciiRFC Specifications April 2018 [Asciidoctor] Allen, D., Waldron, R., and S. White, "Asciidoctor: A fast text processor & publishing toolchain for converting AsciiDoc to HTML5, DocBook & more.", November 2017, . [asciidoctor-bibliography] Ribose Inc., "Citations and Bibliography the 'asciidoctor- way'", November 2017, . [Asciidoctor-Manual] Allen, D., Waldron, R., and S. White, "Asciidoctor: A fast text processor & publishing toolchain for converting AsciiDoc to HTML5, DocBook & more.", November 2017, . [asciidoctor-rfc] Ribose Inc., "asciidoctor-rfc lets you write Internet- Drafts and RFCs in AsciiDoc, the "asciidoctor-way".", November 2017, . [AsciiMathML] "AsciiMath is an easy-to-write markup language for mathematics.", November 2017, . [datatracker-asciirfc-minimal] Carberry, J. and T. Grayson, "IETF Datatracker: A Minimal Internet-Draft In AsciiRFC", April 2018, . [datatracker-camelot-holy-grenade] Pendragon, A., "IETF Datatracker: The Holy Hand Grenade of Antioch", Aprilt 2018, . [datatracker-divination-cfapi] Destiny, G. and C. Luck, "IETF Datatracker: An API For Calendar-Based Fortune Heuristics Services", March 2018, . [draftr] Barnes, R., "draftr: an HTML front-end to pandoc2rfc", Nov 2017, . Tse, et al. Expires October 20, 2018 [Page 82] Internet-Draft AsciiRFC Specifications April 2018 [git-asciirfc-minimal] Carberry, J. and T. Grayson, "Git repository: A Minimal Internet-Draft In AsciiRFC", March 2018, . [git-camelot-holy-grenade] Pendragon, A., "Git repository: The Holy Hand Grenade of Antioch", March 2018, . [git-divination-cfapi] Destiny, G. and C. Luck, "Git repository: An API For Calendar-Based Fortune Heuristics Services", March 2018, . [I-D.asciirfc-minimal] Carberry, J. and T. Grayson, "A Minimal Internet-Draft In AsciiRFC", draft-asciirfc-minimal-02 (work in progress), April 2018. [I-D.camelot-holy-grenade] Pendragon, A., "The Holy Hand Grenade of Antioch", draft- camelot-holy-grenade-01 (work in progress), April 2018. [I-D.divination-cfapi] Destiny, G. and C. Luck, "An API For Calendar-Based Fortune Heuristics Services", draft-divination-cfapi-00 (work in progress), March 2018. [I-D.wu-netmod-yang-xml-doc-conventions] Wu, Q., Farrel, A., and B. Claise, "Documentation Conventions for Expressing YANG in XML", draft-wu-netmod- yang-xml-doc-conventions-00 (work in progress), January 2018. [IETF-BibXML] "IETF BibXML Library", November 2017, . [kramdown-rfc2629] Bormann, C., "kramdown-rfc2629: An RFC2629 (XML2RFC) backend for Thomas Leitner's kramdown markdown parser", Nov 2017, . [lyx2rfc] Williams, N., "LyX to I-D/RFC export by way of Lyx export to XHTML and XSLT conversion to xml2rfc schema", 2014, . Tse, et al. Expires October 20, 2018 [Page 83] Internet-Draft AsciiRFC Specifications April 2018 [MathJax] "MathJax: A JavaScript display engine for mathematics that works in all browsers.", November 2017, . [mmark] Gieben, R., "Using mmark to create I-Ds and RFCs", June 2015, . [NroffEdit] Santesson, S., "WYSIWYG Internet-Draft Nroff Editor", May 2011, . [pandoc2rfc] Gieben, R., "pandoc2rfc: Use pandoc to create XML suitable for xml2rfc", 2012, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", RFC 5385, DOI 10.17487/RFC5385, February 2010, . [RFC7328] Gieben, R., "Writing I-Ds and RFCs Using Pandoc and a Bit of XML", RFC 7328, DOI 10.17487/RFC7328, August 2014, . [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016, . [RFC7763] Leonard, S., "The text/markdown Media Type", RFC 7763, DOI 10.17487/RFC7763, March 2016, . [RFC7764] Leonard, S., "Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations", RFC 7764, DOI 10.17487/RFC7764, March 2016, . [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, December 2016, . Tse, et al. Expires October 20, 2018 [Page 84] Internet-Draft AsciiRFC Specifications April 2018 [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", RFC 7996, DOI 10.17487/RFC7996, December 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TeX-LaTeX] "LaTeX is document preparation software that runs on top of Donald E. Knuth's TeX typesetting system.", November 2017, . Appendix A. Examples A.1. Example 1: "A Minimal Internet-Draft In AsciiRFC" This example is available in the following formats: o AsciiRFC [git-asciirfc-minimal] o Internet-Draft [I-D.asciirfc-minimal] o Text, RFC XML, PDF and HTML on the IETF Datatracker [datatracker-asciirfc-minimal] A.1.1. In AsciiRFC = A Minimal Internet-Draft In AsciiRFC :doctype: internet-draft :name: draft-asciirfc-minimal-02 :abbrev: AsciiRFC Example :status: informational :ipr: trust200902 :submissionType: individual :area: Internet :intended-series: full-standard :revdate: 2018-04-12T00:00:00Z :fullname: Josiah Stinkney Carberry :lastname: Carberry :forename_initials: J. S. :organization: Brown University :phone: +1 401 863 1000 :street: Box K, 69 Brown Street :city: Providence :code: 02912 :country: United States of America Tse, et al. Expires October 20, 2018 [Page 85] Internet-Draft AsciiRFC Specifications April 2018 :uri: https://www.brown.edu :email: josiah.carberry@ribose.com :fullname_2: Truman Grayson :lastname_2: Grayson :forename_initials_2: T. :organization_2: Brown University :phone_2: +1 401 863 1000 :street_2: Box G, 69 Brown Street :city_2: Providence :code_2: 02912 :country_2: United States of America :uri_2: https://www.brown.edu :email_2: truman.grayson@ribose.com [abstract] This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the `asciidoctor-rfc` Ruby gem. [#introduction] == Introduction AsciiRFC <> is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to <>. This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to <> and submittable to the IETF datatracker. [#conventions] == Terms and Definitions 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 <> <> when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions: AsciiRFC:: an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in <>. Tse, et al. Expires October 20, 2018 [Page 86] Internet-Draft AsciiRFC Specifications April 2018 [#symbols] == Symbols And Abbreviations ADRFC:: abbreviated form of AsciiRFC [#main] == Main content This is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes. === Getting started The AsciiRFC and RFC toolchains *MUST* be available locally to build this document template. ==== AsciiRFC toolchain You will need to have: * Ruby: for running the AsciiRFC toolchain * `asciidoctor-rfc` gem: for converting AsciiRFC into XML RFC (v2 or v3) ==== XML RFC toolchain You will need to have: * Python: for running `xml2rfc` * `xml2rfc`: for converting RFC XML (v2 or v3) into TXT * `idnits`: for submission preflight === Referencing external content * This is a published RFC <> * This is an Internet-Draft <> * This is an external reference <> [#code-snippets] === Code snippets Tse, et al. Expires October 20, 2018 [Page 87] Internet-Draft AsciiRFC Specifications April 2018 Code snippets should be wrapped with `` and `` blocks, as required by the IETF Trust Legal Provisions (TLP) <> specified in <>. [#security] == Security Considerations Any security considerations should be placed here. As described in <
> (here's how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools *MAY* produce unintended side effects that impact security. [#iana] == IANA Considerations This document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here. // References must be given before appendixes [bibliography] == Normative References //bibliography::norm[] ++++ Key words for use in RFCs to Indicate Requirement Levels 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 Tse, et al. Expires October 20, 2018 [Page 88] Internet-Draft AsciiRFC Specifications April 2018 requests discussion and suggestions for improvements. The "xml2rfc" Version 3 Vocabulary 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Tse, et al. Expires October 20, 2018 [Page 89] Internet-Draft AsciiRFC Specifications April 2018 ++++ [bibliography] == Informative References //bibliography::info[] ++++ IETF Trust Legal Provisions (TLP) IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc Tse, et al. Expires October 20, 2018 [Page 90] Internet-Draft AsciiRFC Specifications April 2018 This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator. Rights Contributors Provide to the IETF Trust 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 Tse, et al. Expires October 20, 2018 [Page 91] Internet-Draft AsciiRFC Specifications April 2018 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. The OCB Authenticated-Encryption Algorithm 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). ++++ [appendix] [#appendix-a] == Examples === Example 1 Here's an example of a properly wrapped code snippet in accordance with rules specified in <>. [source,json] Tse, et al. Expires October 20, 2018 [Page 92] Internet-Draft AsciiRFC Specifications April 2018 ---- { "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ---- [#acknowledgements] == Acknowledgements The authors would like to thank their families. A.1.2. Rendered as RFC XML v3 A Minimal Internet-Draft In AsciiRFC Brown University
Box K, 69 Brown Street Providence Tse, et al. Expires October 20, 2018 [Page 93] Internet-Draft AsciiRFC Specifications April 2018 02912 United States of America +1 401 863 1000 josiah.carberry@ribose.com https://www.brown.edu
Brown University
Box G, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 truman.grayson@ribose.com https://www.brown.edu
Internet This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the asciidoctor-rfc Ruby gem.
IntroductionAsciiRFC is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to . This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to and submittable to the IETF datatracker.
Terms and DefinitionsThe 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 Tse, et al. Expires October 20, 2018 [Page 94] Internet-Draft AsciiRFC Specifications April 2018 when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions:
AsciiRFC
an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in .
Symbols And Abbreviations
ADRFC
abbreviated form of AsciiRFC
Main contentThis is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes.
Getting startedThe AsciiRFC and RFC toolchains MUST be available locally to build this document template.
AsciiRFC toolchainYou will need to have:
  • Ruby: for running the AsciiRFC toolchain
  • asciidoctor-rfc gem: for converting AsciiRFC into XML RFC (v2 or v3)
XML RFC toolchainYou will need to have:
  • Python: for running xml2rfc
  • xml2rfc: for converting RFC XML (v2 or v3) into TXT
  • idnits: for submission preflight
Referencing external content
  • This is a published RFC
  • This is an Internet-Draft
  • This is an external reference
    • Tse, et al. Expires October 20, 2018 [Page 95] Internet-Draft AsciiRFC Specifications April 2018
Code snippets Code snippets should be wrapped with <CODE BEGINS> and <CODE ENDS> blocks, as required by the IETF Trust Legal Provisions (TLP) specified in .
Security ConsiderationsAny security considerations should be placed here. As described in (here’s how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools MAY produce unintended side effects that impact security.
IANA ConsiderationsThis document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here.
 Normative References Informative References IETF Trust Legal Provisions (TLP) Tse, et al. Expires October 20, 2018 [Page 96] Internet-Draft AsciiRFC Specifications April 2018 IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
Examples
Example 1Here’s an example of a properly wrapped code snippet in accordance with rules specified in .
{ "code": { "encoding": "ascii", Tse, et al. Expires October 20, 2018 [Page 97] Internet-Draft AsciiRFC Specifications April 2018 "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ]]>
Acknowledgements The authors would like to thank their families.
A.2. Example 2: "The Holy Hand Grenade of Antioch" This example is available in the following formats: o AsciiRFC [git-camelot-holy-grenade] o Internet-Draft [I-D.camelot-holy-grenade] o Text, RFC XML, PDF and HTML on the IETF Datatracker [datatracker-camelot-holy-grenade] A.2.1. In AsciiRFC = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :area: General, Operations and Management :keyword: rabbits, grenades, antioch, camelot :ipr: trust200902 :toc-include: true :sort-refs: true :revdate: 2018-04-15T00:00:00Z :fullname: Arthur son of Uther Pendragon :forename_initials: A. :lastname: Pendragon Tse, et al. Expires October 20, 2018 [Page 98] Internet-Draft AsciiRFC Specifications April 2018 :email: arthur.pendragon@ribose.com :organization: Camelot :uri: http://camelot.gov.example :street: Palace\ Camel Lot 1 :city: Camelot :region: England :country: United Kingdom :comments: yes :notedraftinprogress: yes :smart-quotes: false [.comment] tag::preamble1[] // tag::preamble[] [abstract] The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. [NOTE,remove-in-rfc=false] .Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635. // end::preamble[] [.comment] end::preamble1[] [.comment] tag::sectnums1[] // tag::sectnums[] [toc=exclude] :sectnums!: == 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 <> <> when, and only when, they appear in all capitals, as shown here. Tse, et al. Expires October 20, 2018 [Page 99] Internet-Draft AsciiRFC Specifications April 2018 :sectnums: == Introduction <> refers to the intended move of RFC formatting to XML2RFC v3 <>, in the following terms: // end::sectnums[] [.comment] end::sectnums1[] [.comment] tag::quote1[] // tag::quote[] [quote,attribution="A. Farrel"] ____ Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence. ____ // end::quote[] [.comment] end::quote1[] While no pigs, flying or otherwise, are involved in the transition to RFC XML v3, it is opportune to enhance the <> legendarium in the service of RFC XML v3, by illustrating its functionality through references to the mythology of Camelot, and particularly the incidents at the Cave of Caerbannog. [.comment] tag::escaped_hyperlink1[] // tag::escaped_hyperlink[] The screaming move into the twenty-*first* century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like \ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) // end::escaped_hyperlink[] [.comment] end::escaped_hyperlink1[] There are two references to rabbits in _Monty Python and the Holy Grail_ which are expounded on herewith: Tse, et al. Expires October 20, 2018 [Page 100] Internet-Draft AsciiRFC Specifications April 2018 [.comment] tag::listcontinuation1[] // tag::listcontinuation[] Trojan Rabbit:: In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." + The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the French soldiers took the Trojan Rabbit inside the castle. Killer Rabbit of Caerbannog:: Guarding the entrance to the Cave of Caerbannog; see <>. // end::listcontinuation[] [.comment] end::listcontinuation1[] == The French-occupied castle [.comment] tag::inline_formatting1[] // tag::inline_formatting[] The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the _Knights of the Round Table_ and the taunting French soldiers serving under *Guy de Lombard* are, properly speaking, outside the scope of this `menagerie`, being more or less human. Notwithstanding, several^ish^ beasts both animate~d~ and wooden played a significant part in this encounter; most notably: * The Projectile Cow, see <> * The Trojan Rabbit, see <> // end::inline_formatting[] [.comment] end::inline_formatting1[] [[projectile-cow]] .The Projectile Cow with an accompanying cannon ==== [alt=The Projectile Cow with an accompanying cannon in ASCII] Tse, et al. Expires October 20, 2018 [Page 101] Internet-Draft AsciiRFC Specifications April 2018 .... .-.-.-.-.-.-.-.-.-.-.-.--.-.-.-.-.-.-.--.-.-.-.-.-.-.-.--.-. _-_---__--__--___-___-__-____---___-________---____-____-__- ._.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--..-.-.-.-.-.-..--.- ,..,.,.,.,.,..,.,,..,.,.,.,.,.,, ^^ .,,.,., ^^ .,.,.,.= _>-.-.-.-._>_>_>_.-.-.-.-.-.-.-. \\\ .,.,. /// .-.-.-.-. .,.,.,.,..,.,..,.,.,..,.,.,,..,., \ \_______/ / .,.,.,., .,.,.,.,..,.,.,.,..,,..,,.,.,.,.,. <[ {o} . ]> # .,.,.,. .-.-.--.-.-.-.-.-.--.-.-.-.--.-.-. [ ______] .-.-.-. .-.--.-.-.-.--.-.-.-.--.-.-.,.,., / [ ! ` `] .,.,..,.,.- .,.,.,.-.-,l,-,l.-,.,.,.,-.,*. / {_!MOO!_} . ., . . , .-.-.-.-.-.-.-.-.-.-.-.-.-.- /M / -.-<>.,.,..-.-, .-.-.--.-.-.-.-.-.-.-.-.--.. /MI LK\____ .-.-.-.-.-. .-.-.-.--.-.-.-.-.-.-.-.-.- /MILK mil_____k ,.,.,..-,- .-,-.-,-.,-.-,-.`-.-/-.. // -` // .-.p . .-.-. .-.--.-.-.-.-.-.-.-. // ., // .-.-.-.-.-.-.-.- .-.-.--.-.-.-.-.-.-. %____============ .-.-.--.-.-.-.-.- -.-.-.-.--.-.-.-.-.-. ! ! .,-.-.-,-,--,-.-,- ,--.-.-,--.--.-.,--, \ \ .-,-,--.-,--,-.---,-.-, ,-.-.-,-,-.-,-,-.--, + > .-,--,-.--,-,-.-.-,--,- ,--.-,--,-,--.---,- .-,-,--.--,--,-.---,-,-.-. .,.,.,.,..,.,.,.{A\ .,.,.,.,..,.,.,.,.,.,..,.,.,.,..,., .,.,.,.,.,.,.{GLASS\ .,..,.,.,.,.,..,.,.,.,.,.,.,..,.,.,., ,..,.,,.,,.,{OF|MILK\..,.,.,.,.,..,.,.,.,.,.,..,.,.,.,.,.,., ,.,..,.,,.,{ISWORTH},.,.,..,.,.,.,.,..,..,.,.,..,.,.,.,.,.,. .,.,.,.,.{EVERYTNG}.-.-.--..-.-.-.-.--..--.-.-.-.-.--.-.-.-. -.-.-.-{FORINFANTS}___--___-_-__-___--*(0~`~.,.,.,.,><><.><> _-__-_{BUTBETTER}-.-,-,-,-,-,-,-,-,.-^^^^.-.-.-.-.^^^7>>>,.. .._...{WITH_HONEY}-.-.-.-.-.-.-.-.-.-.RANDOM(BUSH)SHRUBS>_.. GRASS_GRASS_GRASS_GRASS_GRASS_SOMEROCKS>GRASS>GRASSPC SOIL_ROOTS_SOIL_SOIL_ROCKS_SOIL_GRASS_GRASS_GRASS_ROCKS_SOIL CLAY_ROCKS_PEBBLES_CLAY_CLAY_CLAY_CLAY_GOLD_CLAY_CLAY><_WORM ROOTS_CLAY_SKELETON_MORESOIL_CLAY_CLAY_CLAY_CLAY_ .... ==== [[trojan-rabbit]] .The Trojan Rabbit with an automatic sliding door ==== [alt=The Trojan Rabbit with an automatic sliding door, in ASCII] .... ___ ____ //_ \//\__\ || || | -__||_||__| // \--_ // ____ --___ // // \ \-_ Tse, et al. Expires October 20, 2018 [Page 102] Internet-Draft AsciiRFC Specifications April 2018 // \\ @/ o || // ---- _____|| // // //\_//__ // //-- --- \____ // // --- \______ // // , . ----- \_//_ // ,. --- \____ // .,v --- \___ // __ -- \_ || , _______________ //|| |-_ || | |''''''''''| // || | | || ' | | | || | | || | | | || | | || " | | 0 | ___||___ | | || | | | -------- | | ||___ | | | ______ | |- // \ | | | // \| _| \ // \ ____|---|__________|______// \/ | || X | / || X | / \\ /\\____/ \\ /___/ \\_____/ ----- \\_____/--- ----- ----- .... ==== [.comment] tag::aside1[] // tag::aside[] **** While the exchange at the French-occupied castle is one of the more memorable scenes of _Monty Python and the Holy Grail_, the Trojan Rabbit has not reached the same level of cultural resonance as its more murderous counterpart. Reasons for this may include: * Less overall screen-time dedicated to the Trojan Rabbit. * The Trojan Rabbit as projectile has already been anticipated by the Cow as projectile. **** // end::aside[] [.comment] end::aside1[] Tse, et al. Expires October 20, 2018 [Page 103] Internet-Draft AsciiRFC Specifications April 2018 [.comment] tag::note1[] // tag::note[] [NOTE,display=true,source=Author] ==== Image courtesy of https://camelot.gov.example/creatures-in-ascii/ ==== // end::note[] [.comment] end::note1[] [.comment] tag::comment1[] // tag::comment[] The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, [comment]#TODO: Will need to verify that claim.# which arguably predates the traditional English enmity with the French. [comment]#Strictly speaking, the Knights are Welsh.# [.comment] -- This document, as it turns out, has a profusion of XML comments. As expected, they are ignored in any rendering of the document. -- // end::comment[] [.comment] end::comment1[] [[caerbannog]] == The Mythos of Caerbannog [.comment] tag::xref1[] // tag::xref[] The _Cave of Caerbannog_ has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the Tse, et al. Expires October 20, 2018 [Page 104] Internet-Draft AsciiRFC Specifications April 2018 *Killer Rabbit of Caerbannog* <>. It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the <>), that we recount here through monospace font and multiple spaces. [[killer_rabbit_caerbannog]] === The Killer Rabbit of Caerbannog // end::xref[] [.comment] end::xref1[] [.comment] tag::relref1[] // tag::relref[] The *Killer Rabbit of Caerbannog*, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, _contra_ the claim made in <>, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as <>, there are few remedies known against its awful lapine powers. // end::relref[] [.comment] end::relref1[] [.comment] tag::hyperlink1[] // tag::hyperlink[] <> of the fearsome beast has been sourced from http://camelot.gov.example/avatars/rabbit[Rabbit-SCII], <> by C code that was used in this accurate depiction of the Killer Rabbit: // end::hyperlink[] [.comment] end::hyperlink1[] [.comment] tag::figure1[] // tag::figure1a[] Tse, et al. Expires October 20, 2018 [Page 105] Internet-Draft AsciiRFC Specifications April 2018 [[killer-bunny]] .A Photo Of The Killer Rabbit of Caerbannog Taken In Secret ==== [alt=The Killer Bunny, in ASCII] .... \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\^^^^^^^^^^^^^^^^^^^^^^\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\<<#MWSHARPMWMWMWTEETHWMWWM>>>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ .... ==== [[killer-source]] .C Code To Lure Killer Rabbit Back To Cave ==== [source,c] ---- /* Locate the Killer Rabbit */ int type; Tse, et al. Expires October 20, 2018 [Page 106] Internet-Draft AsciiRFC Specifications April 2018 unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); return LOST_CREATURE; } /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ---- ==== // end::figure1a[] [.comment] end::figure1[] On the beast's encounter with the Knights of the Round Table, the following personnel engaged with it in combat: [.comment] tag::ul1[] // tag::ul[] * Killed ** Sir Bors ** Sir Gawain ** Sir Ector * Soiled Himself ** Sir Robin * Panicked Tse, et al. Expires October 20, 2018 [Page 107] Internet-Draft AsciiRFC Specifications April 2018 ** King Arthur * Employed Ordnance ** The Lector ** Brother Maynard * Scoffed ** Tim the Enchanter // end::ul[] [.comment] end::ul1[] [[holy_hand_grenade]] === Holy Hand Grenade of Antioch [.comment] tag::figure2[] // tag::figure2a[] [[hand-grenade-figure]] .The Holy Hand Grenade of Antioch (don't pull the pin) ==== [alt=Holy Hand Grenade of Antioch, in ASCII] .... ______ \\/ \/ __\\ /__ || //\ | ||__\\/ __| || | ,---, || |====`\ | || | '---' ,--'*`--, _||#|***|#| _,/.-'#|* *|#`-._ ,,-'#####| |#####`-. ,,'########| |########`, //##########| o |##########\ ||###########| |###########| ||############| o |############| ||------------' '------------| ||o o o o o o o o o o| |-----------------------------| ||###########################| \\#########################/ Tse, et al. Expires October 20, 2018 [Page 108] Internet-Draft AsciiRFC Specifications April 2018 `..#####################,' ``..###############_,' ``--.._____..--' `''-----''` .... ==== // end::figure2a[] [.comment] end::figure2[] [[sovereign-orb]] .The Sovereign's Orb made invisible ==== .Outlines of the Sovereign's Orb [link=https://camelot.gov.example/sovereigns_orb.jpg,align=right] image::https://camelot.gov.example/sovereigns_orb.jpg[Orb,124,135] ==== [.comment] tag::index1[] // tag::index[] The solution to the impasse at the ((Cave of Caerbannog)) was provided by the successful deployment of the *Holy Hand Grenade of Antioch* (see <>) (((Holy Hand Grenade of Antioch))). Any similarity between the Holy Hand Grenade of Antioch and the mythical _Holy Spear of Antioch_ is purely intentional; (((relics, Christian))) any similarity between the Holy Hand Grenade of Antioch and the _Sovereign's Orb of the United Kingdom_ (see <>) is putatively fortuitous. (((relics, monarchic))) // end::index[] [.comment] end::index1[] [.comment] tag::dl1[] // tag::dl[] Holy Hand Grenade of Antioch:: Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See <>. Tse, et al. Expires October 20, 2018 [Page 109] Internet-Draft AsciiRFC Specifications April 2018 Holy Spear of Antioch:: A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098. Sovereign's Orb of the United Kingdom:: Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See <>. // end::dl[] [.comment] end::dl1[] [.comment] tag::bcp14_1[] // tag::bcp14[] The instructions in the _Book of Armaments_ on the proper deployment of the Holy Hand Grenade of Antioch [bcp14]#may# be summarized as follows, although this summary *SHALL NOT* be used as a substitute for a reading from the Book of Armaments: // end::bcp14[] [.comment] end::bcp14_1[] [.comment] tag::ol1[] // tag::ol[] . Preamble: St Attila Benediction . Feast of the People on Sundry Foods ** Lambs ** Sloths ** Carp ** Anchovies ** Orangutangs ** Breakfast Cereals ** Fruit Bats ** _et hoc genus omne_ . Take out the Holy Pin . The Count [upperalpha] .. Count is to Three: no more, no less .. Not Four Tse, et al. Expires October 20, 2018 [Page 110] Internet-Draft AsciiRFC Specifications April 2018 .. Nor Two, except if the count then proceeds to Three .. Five is Right Out . Lob the Holy Hand Grenade of Antioch towards the Foe . The Foe, being naughty in the *LORD's* sight, [bcp14]#shall# snuff it // end::ol[] [.comment] end::ol1[] This could also be represented in pseudocode as follows: [.comment] tag::listcontinuationblock1[] // tag::listcontinuationblock[] . Take out the Holy Pin . The Count + ---- integer count; for count := 1 step 1 until 3 do say(count) comment Five is Right Out ---- . Lob the Holy Hand Grenade of Antioch towards the Foe . Foe snuffs it // end::listcontinuationblock[] [.comment] end::listcontinuationblock1[] == Dramatis Personae The following human (more-or-less) protagonists were involved in the two incidents recounted as lore of the Knights of the Round Table: [.comment] tag::table1[] // tag::table[] [grid=all,options="footer"] |=== |French Castle | Cave of Caerbannog 2+|King Arthur 2+|Patsy 2+|Sir Bedevere the Wise Tse, et al. Expires October 20, 2018 [Page 111] Internet-Draft AsciiRFC Specifications April 2018 2+|Sir Galahad the Pure 2+|Sir Lancelot the Brave 2+|Sir Robin the Not-quite-so-brave-as-Sir-Lancelot |French Guard with Outrageous Accent| Tim the Enchanter |Other French Guards | Brother Maynard | | The Lector .3+^|not yet recruited >|Sir Bors >|Sir Gawain >|Sir Ector |Retinue of sundry knights |Retinue of sundry more knights than at the French Castle |=== // end::table[] [.comment] end::table1[] === Past the Killer Rabbit Once the Killer Rabbit of Caerbannog (<>) had been dispatched, the Knights of the Round Table uncovered the last words of Joseph of Arimathea, inscribed on the Cave of Caerbannog in Aramaic. While the precise Aramaic wording has not survived, we trust the following Hebrew subtitles will serve as an acceptable substitute: [.comment] tag::hebrew1[] // tag::hebrew[] ____ .כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה .מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. Tse, et al. Expires October 20, 2018 [Page 112] Internet-Draft AsciiRFC Specifications April 2018 He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh." ____ // end::hebrew[] [.comment] end::hebrew1[] == IANA Considerations IANA might consider a registry to track the mythical, especially ravaging beasts, such as the Killer Rabbit, who haunt the Internet. == Security Considerations Do not let the Killer Rabbit out under any circumstance. I repeat. Do not let the Killer Rabbit (<>) out. [.comment] tag::bibliography1[] // tag::bibliography[] [bibliography] == Normative References ++++ Key words for use in RFCs to Indicate Requirement Levels ++++ [bibliography] == Informative References Tse, et al. Expires October 20, 2018 [Page 113] Internet-Draft AsciiRFC Specifications April 2018 ++++ Monty Python and the Holy Grail DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) RFC Format Framework Tse, et al. Expires October 20, 2018 [Page 114] Internet-Draft AsciiRFC Specifications April 2018 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ++++ // end::bibliography[] [.comment] end::bibliography1[] A.2.2. Rendered as RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 115] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot England United Kingdom arthur.pendragon@ribose.com http://camelot.gov.example
General Operations and Management rabbits grenades antioch camelot The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the Tse, et al. Expires October 20, 2018 [Page 116] Internet-Draft AsciiRFC Specifications April 2018 menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635.
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 when, and only when, they appear in all capitals, as shown here.
Introduction refers to the intended move of RFC formatting to XML2RFC v3 , in the following terms:
Tse, et al. Expires October 20, 2018 [Page 117] Internet-Draft AsciiRFC Specifications April 2018 Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence.
While no pigs, flying or otherwise, are involved in the transition to RFC XML v3, it is opportune to enhance the legendarium in the service of RFC XML v3, by illustrating its functionality through references to the mythology of Camelot, and particularly the incidents at the Cave of Caerbannog. The screaming move into the twenty-first century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) There are two references to rabbits in Monty Python and the Holy Grail which are expounded on herewith:
Trojan Rabbit
In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the Tse, et al. Expires October 20, 2018 [Page 118] Internet-Draft AsciiRFC Specifications April 2018 French soldiers took the Trojan Rabbit inside the castle.
Killer Rabbit of Caerbannog
Guarding the entrance to the Cave of Caerbannog; see .
The French-occupied castle The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the Knights of the Round Table and the taunting French soldiers serving under Guy de Lombard are, properly speaking, outside the scope of this menagerie, being more or less human. Notwithstanding, severalish beasts both animated and wooden played a significant part in this encounter; most notably:
  • The Projectile Cow, see
  • The Trojan Rabbit, see
The Projectile Cow with an accompanying cannon -.-.-.-._>_>_>_.-.-.-.-.-.-.-. \\\ .,.,. /// .-.-.-.-. .,.,.,.,..,.,..,.,.,..,.,.,,..,., \ \_______/ / .,.,.,., .,.,.,.,..,.,.,.,..,,..,,.,.,.,.,. <[ {o} . ]> # .,.,.,. Tse, et al. Expires October 20, 2018 [Page 119] Internet-Draft AsciiRFC Specifications April 2018 .-.-.--.-.-.-.-.-.--.-.-.-.--.-.-. [ ______] .-.-.-. .-.--.-.-.-.--.-.-.-.--.-.-.,.,., / [ ! ` `] .,.,..,.,.- .,.,.,.-.-,l,-,l.-,.,.,.,-.,*. / {_!MOO!_} . ., . . , .-.-.-.-.-.-.-.-.-.-.-.-.-.- /M / -.-<>.,.,..-.-, .-.-.--.-.-.-.-.-.-.-.-.--.. /MI LK\____ .-.-.-.-.-. .-.-.-.--.-.-.-.-.-.-.-.-.- /MILK mil_____k ,.,.,..-,- .-,-.-,-.,-.-,-.`-.-/-.. // -` // .-.p . .-.-. .-.--.-.-.-.-.-.-.-. // ., // .-.-.-.-.-.-.-.- .-.-.--.-.-.-.-.-.-. %____============ .-.-.--.-.-.-.-.- -.-.-.-.--.-.-.-.-.-. ! ! .,-.-.-,-,--,-.-,- ,--.-.-,--.--.-.,--, \ \ .-,-,--.-,--,-.---,-.-, ,-.-.-,-,-.-,-,-.--, + > .-,--,-.--,-,-.-.-,--,- ,--.-,--,-,--.---,- .-,-,--.--,--,-.---,-,-.-. .,.,.,.,..,.,.,.{A\ .,.,.,.,..,.,.,.,.,.,..,.,.,.,..,., .,.,.,.,.,.,.{GLASS\ .,..,.,.,.,.,..,.,.,.,.,.,.,..,.,.,., ,..,.,,.,,.,{OF|MILK\..,.,.,.,.,..,.,.,.,.,.,..,.,.,.,.,.,., ,.,..,.,,.,{ISWORTH},.,.,..,.,.,.,.,..,..,.,.,..,.,.,.,.,.,. .,.,.,.,.{EVERYTNG}.-.-.--..-.-.-.-.--..--.-.-.-.-.--.-.-.-. -.-.-.-{FORINFANTS}___--___-_-__-___--*(0~`~.,.,.,.,><><.><> _-__-_{BUTBETTER}-.-,-,-,-,-,-,-,-,.-^^^^.-.-.-.-.^^^7>>>,.. .._...{WITH_HONEY}-.-.-.-.-.-.-.-.-.-.RANDOM(BUSH)SHRUBS>_.. GRASS_GRASS_GRASS_GRASS_GRASS_SOMEROCKS>GRASS>GRASSPC SOIL_ROOTS_SOIL_SOIL_ROCKS_SOIL_GRASS_GRASS_GRASS_ROCKS_SOIL CLAY_ROCKS_PEBBLES_CLAY_CLAY_CLAY_CLAY_GOLD_CLAY_CLAY><_WORM ROOTS_CLAY_SKELETON_MORESOIL_CLAY_CLAY_CLAY_CLAY_ ]]>
The Trojan Rabbit with an automatic sliding door
Image courtesy of Tse, et al. Expires October 20, 2018 [Page 121] Internet-Draft AsciiRFC Specifications April 2018 The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, which arguably predates the traditional English enmity with the French.
The Mythos of Caerbannog The Cave of Caerbannog has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the Killer Rabbit of Caerbannog . It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the following section), that we recount here through monospace font and multiple spaces.
The Tse, et al. Expires October 20, 2018 [Page 122] Internet-Draft AsciiRFC Specifications April 2018 Killer Rabbit of Caerbannog The Killer Rabbit of Caerbannog, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, contra the claim made in Ze Vompyre, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as , there are few remedies known against its awful lapine powers. The following depiction of the fearsome beast has been sourced from Rabbit-SCII, accompanied by C code that was used in this accurate depiction of the Killer Rabbit: Tse, et al. Expires October 20, 2018 [Page 123] Internet-Draft AsciiRFC Specifications April 2018
A Photo Of The Killer Rabbit of Caerbannog Taken In Secret >>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ ]]>
C Code To Lure Killer Rabbit Back To Cave /* Locate the Killer Rabbit */ int type; unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); Tse, et al. Expires October 20, 2018 [Page 124] Internet-Draft AsciiRFC Specifications April 2018 return LOST_CREATURE; } /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ]]>
On the beast's encounter with the Knights of the Round Table, the following personnel engaged with it in combat:
  • Killed
    • Sir Bors
    • Sir Gawain
    • Sir Ector
  • Soiled Himself
      Tse, et al. Expires October 20, 2018 [Page 125] Internet-Draft AsciiRFC Specifications April 2018
    • Sir Robin
  • Panicked
    • King Arthur
  • Employed Ordnance
    • The Lector
    • Brother Maynard
  • Scoffed
    • Tim the Enchanter
Holy Hand Grenade of Antioch
The Holy Hand Grenade of Antioch (don't pull the pin)
The Sovereign's Orb made invisible
The solution to the impasse at the Cave of Caerbannog was provided by the successful deployment of the Holy Hand Grenade of Antioch (see ) . Any similarity between the Holy Hand Grenade of Antioch and the mythical Holy Spear of Antioch is purely intentional; any similarity between the Holy Hand Grenade of Antioch and the Sovereign's Orb of the United Kingdom (see ) is putatively fortuitous. Tse, et al. Expires October 20, 2018 [Page 127] Internet-Draft AsciiRFC Specifications April 2018
Holy Hand Grenade of Antioch
Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See .
Holy Spear of Antioch
A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098.
Sovereign's Orb of the United Kingdom
Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See .
The instructions in the Book of Armaments on the proper deployment of the Holy Hand Grenade of Antioch MAY be summarized as follows, although this summary SHALL NOT be used as a substitute for a reading from the Book of Armaments: Tse, et al. Expires October 20, 2018 [Page 128] Internet-Draft AsciiRFC Specifications April 2018
  1. Preamble: St Attila Benediction
  2. Feast of the People on Sundry Foods
    • Lambs
    • Sloths
    • Carp
    • Anchovies
    • Orangutangs
    • Breakfast Cereals
    • Fruit Bats
    • et hoc genus omne
  3. Take out the Holy Pin
  4. The Count
    1. Count is to Three: no more, no less
    2. Not Four
    3. Nor Two, except if the count then proceeds to Three
    4. Five is Right Out
  5. Lob the Holy Hand Grenade of Antioch towards the Foe
  6. The Foe, being naughty in the LORD's sight, SHALL snuff it
This could also be represented in pseudocode as follows:
  1. Take out the Holy Pin
  2. The Count
  3. Lob the Holy Hand Grenade of Antioch towards the Foe
  4. Foe snuffs it
Dramatis PersonaeThe following human (more-or-less) protagonists were involved in the two incidents recounted as lore of the Knights of the Round Table: Tse, et al. Expires October 20, 2018 [Page 130] Internet-Draft AsciiRFC Specifications April 2018
French Castle Cave of Caerbannog
King Arthur
Patsy
Sir Bedevere the Wise
Sir Galahad the Pure
Sir Lancelot the Brave
Sir Robin the Not-quite-so-brave-as-Sir-Lancelot
French Guard with Outrageous Accent Tim the Enchanter
Other French Guards Brother Maynard
The Lector
not yet recruited Sir Bors
Sir Gawain
Sir Ector
Retinue of sundry knights Retinue of sundry more knights than at the French Castle
Past the Killer RabbitOnce the Killer Rabbit of Caerbannog () had been dispatched, the Knights of the Round Table uncovered the last words of Joseph of Arimathea, inscribed on the Cave of Caerbannog in Aramaic. While the precise Aramaic wording has not survived, we trust the following Hebrew subtitles will serve as an acceptable substitute: Tse, et al. Expires October 20, 2018 [Page 131] Internet-Draft AsciiRFC Specifications April 2018
כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh."
IANA Considerations IANA might consider a registry to track the mythical, especially ravaging beasts, such as the Killer Rabbit, who haunt the Internet.
Security ConsiderationsDo not let the Killer Rabbit out under any circumstance. I repeat. Do not let the Killer Rabbit () out.
Normative References Tse, et al. Expires October 20, 2018 [Page 132] Internet-Draft AsciiRFC Specifications April 2018 Informative References Monty Python and the Holy Grail A.3. Example 3: "An API For Calendar-Based Fortune Heuristics Services" in AsciiRFC This example is available in the following formats: o AsciiRFC [git-divination-cfapi] o Internet-Draft [I-D.divination-cfapi] o Text, RFC XML, PDF and HTML on the IETF Datatracker [datatracker-divination-cfapi] Tse, et al. Expires October 20, 2018 [Page 133] Internet-Draft AsciiRFC Specifications April 2018 A.3.1. In AsciiRFC = An API For Calendar-Based Fortune Heuristics Services Gabriel Destiny; Charise Luck :doctype: internet-draft :abbrev: Calendar Fortune Heuristics API :name: draft-divination-cfapi-00 :status: informational :ipr: trust200902 :area: Internet :submission-type: independent :intended-series: informational :revdate: 2018-03-23T00:00:00Z :lastname: Destiny :fullname: Gabriel Destiny :forename_initials: G. :organization: Divination Inc. :email: gabriel.destiny@ribose.com :street: 9288 N Divine Street :city: Dunn :code: 28334 :region: NC :country: United States of America :lastname_2: Luck :fullname_2: Charise Luck :forename_initials_2: C. :organization_2: Divination Inc. :email_2: charise.luck@ribose.com :street_2: 9288 N Divine Street :city_2: Dunn :code_2: 28334 :region_2: NC :country_2: United States of America [.comment] tag::sample[] // tag::sample[] [abstract] This document describes a JSON HTTP API for online services that provide calendar-based fortune heuristics. == Introduction Fortune-telling, the practice of predicting information about a person's life, is an activity practiced throughout history. Tse, et al. Expires October 20, 2018 [Page 134] Internet-Draft AsciiRFC Specifications April 2018 While there are myriad forms of fortune telling methodologies, this document applies to a particular form of service that provides fortune heuristics, commonly known as "luck", for a particular subject based on a calendar-based input. Since HTTP <> status codes are insufficient to convey information about fortune heuristics, this specification defines a simple JSON <> document format for this purpose. The response can be used by HTTP APIs to deliver results to non-human clients or to an end-user. == Conventions Used in This Document 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 <> <> when, and only when, they appear in all capitals, as shown here. The following definitions apply in this document: Well-known URI:: This specification makes use of the "well-known URI" feature of HTTP servers <> to provide a bootstrapping URI for the client usage of fortune heuristics services. Root of Fortune:: The service discovery endpoint that provides a URI list of available fortune heuristic endpoints available, in accordance with <>. == Fortune Heuristics Service Well-Known URI A well-known URI called "fortune" is registered by this specification for fortune heuristics services (see <>). Services complying with this document *SHOULD* have its well-known URI pointing (directly or through redirection) to the Root of Fortune. The Root of Fortune can be used by the client for service discovery, namely, the available calendar-based fortune heuristics services available on the server, as specified in <>. === Well-Known URI Redirection Servers *MUST* redirect HTTP requests for that resource to the actual "context path" using one of the available mechanisms provided by HTTP <> (e.g., using a 301, 303, or 307 response). Tse, et al. Expires October 20, 2018 [Page 135] Internet-Draft AsciiRFC Specifications April 2018 Clients *MUST* handle HTTP redirects on the well-known URI. === Well-Known URI Cache Behavior Servers *SHOULD* set an appropriate Cache-Control header value (as according to <>) in the redirect response to set caching behavior as required by the type of response generated. == New HTTP Methods: SEEK and DIVINE This specification defines two new HTTP methods: "SEEK" and "DIVINE" methods for HTTP <>. While HTTP GET requests are treated equivalently as the "SEEK" and "DIVINE" requests, its usage is discouraged and therefore *SHOULD NOT* be used. Usage of these methods are defined in the sections below. == Defined Data Types: Date-Time Formats This specification defines a number of date-time formats as according to the conventions of <> for the unambiguous communication between client and server. The types defined are as follows. `DATETIME`:: As described in <>, with the addition that reduced accuracy representations described in <> are supported. Reduced accuracy date and times are accepted where a date or time component (2-digits long) is replaced by "--". + For example, the date time "2018-04---T01:02:00Z" represents the UTC time of 1:02am, on an unknown day within April of the year 2018. `DATE`:: As described in "DATETIME", but the "time" component will not be taken into account in the algorithm. [#service-discovery] == Fortune Heuristics Service Discovery [#root-of-fortune] Tse, et al. Expires October 20, 2018 [Page 136] Internet-Draft AsciiRFC Specifications April 2018 === Root of Fortune Path URI ("/") The Root of Fortune URI, defined as "/" in this document, is used for service discovery on types of calendar-based fortune heuristics available. An empty SEEK request with the "application/json" request type *MUST* be sent to this endpoint to retrieve the available endpoints. All other HTTP methods *MUST NOT* be supported at this URI. An example of such a response is as follows: [source,json] ---- HTTP/1.1 200 Success Content-Type: application/json Content-Language: en { "diviners" : [ "/astrology", "/bazi", ] } ---- A service discovery object *MUST* have the following members: `diviners`:: (JSON array) An array that contains endpoints that conform to this specification. All endpoints listed here are relative to the Root of Fortune path. For example, the path "/astrology" listed in the example has an endpoint path of "[root-of-fortune]/astrology", where "[root-of-fortune]" indicates the real path of the Root of Fortune. // end::sample[] [.comment] end::sample[] [#service-endpoint] == Fortune Heuristics Service Endpoint An endpoint offering fortune heuristics services *MUST* adhere to specifications in this section. Tse, et al. Expires October 20, 2018 [Page 137] Internet-Draft AsciiRFC Specifications April 2018 A service *MAY* implement multiple divination services based on different divination methods, such as the digital oracle shown in <>. [[digital-oracle]] .Dimensional Eye, a digital oracle that communicates through one button ==== [alt=An incarnation of the Dimensional Eye, in ASCII] .... __ __===^-\ __=== -\ __===- -\ __===- -\ ___===- -\ ===- ---__ -\ \\\ |||^^\ \__ -\ \\\ ||| \__ -\ \\\ ||| ______\_ -\ \\\ ||| _/-******\\__ -\ \\\ || /-****_****-\ \_ -\ \\\ || |-***/ \***-\ \_ -\ \\\ || |-***\___/***-| \ -\ \\\ || \-*********-/ __--/ -\ \\\ || \-******/__-- -\ \\\ || __-- -\ \\\ || __-- -\ \\\ ||__-- -\ \\\ -\ \\\ -\ \\\ -\ \\\ -\ \\\ __ -\ \\\ //##\\ -\ \\\ \\##// -\ \\\ ^^ __--==^ \\\ __--=== \\\ __--=== \\\ __--=== \\\ __--== \\= .... ==== [#endpoint-specification-request] === Service Specification Request Tse, et al. Expires October 20, 2018 [Page 138] Internet-Draft AsciiRFC Specifications April 2018 To retrieve capabilities and parameters of an endpoint complying with this specification, a service specification JSON object is returned. An empty SEEK request with the "application/json" request type *MUST* be sent to this endpoint to retrieve the service specification that describes parameters accepted by this endpoint. Two examples of such a response are given below. [source,json] ---- HTTP/1.1 200 Success Content-Type: application/json Content-Language: en { "description": "Gaze into your upcoming luck!", "details": "https://divine.example.com/manual/astrology-api", "parameters": { "birthday": { "type": "DATE", "description": "Your birth date in UTC" }, "targetDateBegin": { "type": "DATE", "description": "Start of the target date range to report on" }, "targetDateEnd": { "type": "DATE", "description": "End of the target date range to report on" }, "interval": { "values": { "D": "Daily", "M": "Monthly", "Y": "Yearly" }, "description": "Available intervals to report on." } } } ---- [source,json] ---- HTTP/1.1 200 Success Content-Type: application/json Content-Language: en Tse, et al. Expires October 20, 2018 [Page 139] Internet-Draft AsciiRFC Specifications April 2018 { "description": "Matches and mis-matches according to the " "Yin Yang and Five Elements techniques", "details": "https://divine.example.com/manual/bazi-api", "parameters": { "birthday": { "type": "DATETIME", "description": "Your birth date and time in UTC" }, "targetDateBegin": { "type": "DATETIME", "description": "Start of the target date/time range to report on" }, "targetDateEnd": { "type": "DATETIME", "description": "End of the target date/time range to report on" }, "interval": { "values": { "H": "Hourly", "D": "Daily", "M": "Monthly", "Y": "Yearly" }, "description": "Available intervals to report on." } } } ---- [#service-endpoint-specification] === Service Specification Object A service specification object *MUST* contain the following members. `description`:: (string) A short, human-readable summary of the fortune heuristic service at this endpoint. This *SHOULD* be a stable reference. `details`:: (URI, optional) A URI reference that provides further details for human consumption, such as API documentation that includes details of parameters accepted or response states. `parameters`:: (object, mandatory) An object that specifies what parameters are accepted by this endpoint. Each parameter key within this object specifies an accepted parameter name, and its value is a parameter Tse, et al. Expires October 20, 2018 [Page 140] Internet-Draft AsciiRFC Specifications April 2018 specification object, which is described below. A parameter specification object *SHOULD* contain the following members: `type`:: (string, optional) The value type accepted by this parameter. Value types are described in this document. This member is mutually exclusive with `values`. `description`:: (string, mandatory) The purpose of this parameter. `values`:: (object, optional) The accepted values of this parameter, unlisted values *SHOULD* not be accepted by the parameter. Each key within this object specifies an accepted value, and its value provides a description of the purpose of the value. [#endpoint-report] == Fortune Heuristics Report Request and Response [#endpoint-report-request] === Fortune Heuristics Report Request A request using the HTTP "DIVINE" method and the "application/json" type *MUST* be sent to the fortune heuristic endpoint to retrieve results for a fortune heuristic query. The request made *MUST* conform to the specifications of the endpoint, as retrieved via the "SEEK" method described in <>. An example of a request is provided below. [source] ---- URI: /divination/astrology Method: DIVINE Content-Type: application/json Content-Language: en { "birthday": "1976-02-11T00:00:00Z", "targetDateBegin": "2018-01-01T00:00:00Z", "targetDateEnd": "2019-01-01T00:00:00Z", "interval": "M" Tse, et al. Expires October 20, 2018 [Page 141] Internet-Draft AsciiRFC Specifications April 2018 } ---- [#endpoint-report-response] === Fortune Heuristics Report Response A fortune heuristic query using the "DIVINE" method triggers a response that contains a fortune heuristics report. A successful response returns a JSON object that *MUST* conform to the object structure described in this section. A report object *SHOULD* contain the following members: `type`:: (URI, mandatory) A URI that defines the type of the report located at the `report` key of this object. `report`:: (object, mandatory) An object that contains two keys, `intervals` and `events`. The `intervals` object contains an array of interval objects that matches the demanded intervals in the request within the target date range. The `events` object contains an array of significant event objects within the target date range. An example of a response is provided below. [source] ---- URI: /divination/astrology Method: DIVINE HTTP/1.1 200 Success Content-Type: application/json Content-Language: en { "type": "https://association-of.astrology/reports/monthly", "report": { "intervals": [ { "dateStart": "2018-01-01T00:00:00Z", "dateEnd": "2018-02-01T00:00:00Z", "categories": [ { "category": "https://divine.example.com/astrology/categories/health" Tse, et al. Expires October 20, 2018 [Page 142] Internet-Draft AsciiRFC Specifications April 2018 "value": 80, "description": "Charge ahead with excellent health." }, { "category": "https://divine.example.com/astrology/categories/love" "value": 70, "description": "Give a certain person or situation another try!" }, { "category": "https://divine.example.com/astrology/categories/finance" "value": 5, "description": "You've just realized that you don't have any cash on hand." } ] }, { "dateStart": "2018-02-01T00:00:00Z", "dateEnd": "2018-03-01T00:00:00Z", "..." }, "..." ], "events": [ { "dateStart": "2018-01-15T03:20:00", "dateEnd": "2018-01-16T20:22:15", "description": "The planet of growth and good luck, Jupiter will make a harmonious connection with power planet Pluto, helping you connect with influential people", "recommendation": "Engage in networking during this time." }, { "dateStart": "2018-03-22T00:12:40", "dateEnd": "2018-03-28T02:45:03", "description": "Communication planet Mercury enters your sign, which will find you in a busier and chattier mood.", "recommendation": "Take charge of work with your newfound energy." } "..." ] } } ---- Tse, et al. Expires October 20, 2018 [Page 143] Internet-Draft AsciiRFC Specifications April 2018 Fortune heuristic reports are created by a divination output that *MAY* requires quantitative interpretation. A sample representation of interpreting a graphical divination output is provided in <>. [[divination-message]] .Forty-nine yarrow sticks reveals a mystical message on fortune ==== [alt=A mystical pattern in ASCII] .... 0000000000000000000000000 0000000000000000000000001 G 1000000000000000000000000 0000000000000000000000011 R 1100000000000000000000000 0000000000000000000000111 A 1110000000000000000000000 0000000000000000000001111 C 1111000000000000000000000 0000000000000000000011111 E 1111100000000000000000000 0000000000000000000111111 , 1111110000000000000000000 0000000000000000001111111 1111111000000000000000000 0000000011111111111111111 M 1111111111111111100000000 0000000111111111111111111 E 1111111111111111110000000 0000001111111111111111111 R 1111111111111111111000000 0000011111111111111111111 C 1111111111111111111100000 0000111111111111111111111 Y 1111111111111111111110000 0001111111111111111111111 , 1111111111111111111111000 0011111111111111111111111 1111111111111111111111100 0111111111111111111111111 A 1111111111111111111111110 0000000000000000011111111 N 1111111100000000000000000 0000000000000000111111111 D 1111111110000000000000000 0000000000000001111111111 1111111111000000000000000 0000000000000011111111111 P 1111111111100000000000000 0000000000000111111111111 E 1111111111110000000000000 0000000000001111111111111 A 1111111111111000000000000 0000000000011111111111111 C 1111111111111100000000000 0000000000111111111111111 E 1111111111111110000000000 0000000001111111111111111 . 1111111111111111000000000 .... ==== [#endpoint-report-interval-obj] === Report Interval Object The `intervals` value of a report object contains a number of report intervals -- each representing a non-overlapping period of the selected interval length. When all of these intervals are put together, the combined period *MUST* fully cover the requested report target period. Tse, et al. Expires October 20, 2018 [Page 144] Internet-Draft AsciiRFC Specifications April 2018 An example interval object is shown below. [source,json] ---- { "dateStart": "2018-01-01T00:00:00Z", "dateEnd": "2018-02-01T00:00:00Z", "categories": [ { "category": "https://divine.example.com/astrology/categories/health" "value": 80, "description": "Charge ahead with your excellent health." }, { "category": "https://divine.example.com/astrology/categories/love" "value": 70, "description": "Give a certain person or situation another try!" }, { "category": "https://divine.example.com/astrology/categories/finance" "value": 5, "description": "You've just realized that you don't have any cash on hand." } ] } ---- An interval object *MUST* contain the following members: `dateStart`:: (datetime, mandatory) This value specifies the start of the period which this interval object applies to. `dateEnd`:: (datetime, mandatory) This value specifies the end of the period which this interval object applies to. In the given example, the `categories` key is an implementation specific object that details heuristic results returned by the selected algorithm. This *MAY* differ in different algorithms. [#endpoint-report-event-obj] === Report Events Object Tse, et al. Expires October 20, 2018 [Page 145] Internet-Draft AsciiRFC Specifications April 2018 The `events` value of a report object contains a number of event objects. Each event object represents an event relevant to the calculation of fortune heuristics during a target report period. These events *MAY* be of variable time lengths, and *MAY* be overlapping amongst each other. The following example demonstrates two event objects the service determines relevant to a user's query. [source,json] ---- { "dateStart": "2018-01-15T03:20:00", "dateEnd": "2018-01-16T20:22:15", "description": "The planet of growth and good luck, Jupiter will make a harmonious connection with power planet Pluto, helping you connect with influential people", "recommendation": "Engage in networking during this time." }, { "dateStart": "2018-03-22T00:12:40", "dateEnd": "2018-03-28T02:45:03", "description": "Communication planet Mercury enters your sign, which will find you in a busier and chattier mood.", "recommendation": "Take charge of work with your newfound energy." } ---- Similar to an interval object, an event object *MUST* contain the following members: `dateStart`:: (datetime, mandatory) This value specifies the start of the period described by the event. `dateEnd`:: (datetime, mandatory) This value specifies the end of the period described by the event. In the given example, the keys `description` and `recommendation` are implementation-specific details. This *MAY* differ in different algorithms. [#endpoint-report-errors] === Report Generation Errors This specification makes use of normal HTTP error codes with the Tse, et al. Expires October 20, 2018 [Page 146] Internet-Draft AsciiRFC Specifications April 2018 following extensions. Errors *MUST* be returned using the Problem JSON Structure as accordance with <>. 422 Unprocessable Entity:: For example, a malformed date-time parameter, or an illogical input, such as when the subject's birthday occurs after the report target date period. 473 Beyond Existing Capability:: The service determines that the outcome is too difficult to predict. For example, in the case where the calculation is too complex to complete in a certain time period. The service *SHOULD* issue this response code to indicate that the client should not try the same request again. 474 Outcome Impossible:: The service determines that the outcome is impossible. For example, when the algorithm determines that the subject will have deceased before the start of the requested target period. [#security] == Security Considerations * TLS <> and authenticated HTTP requests should be used to protect the DIVINE request and responses due to the personal nature of information transmitted. * A client *SHOULD* verify the identity of the server on every request to prevent impersonation or man-in-the-middle attacks, as data transmitted to and from the server is sensitive information, and at times critical information to the user. * Synchronization of client and server time *MUST* be well-considered in the implementation of this specification. A mismatch of client and server time *MAY* lead to algorithm miscalculations that can cause mistaken choices of a user that depends on the reliability of this system. [#iana] == IANA Considerations === Well-Known URI Registrations Tse, et al. Expires October 20, 2018 [Page 147] Internet-Draft AsciiRFC Specifications April 2018 This document defines a well-known URI using the registration procedure and template from <>. ==== "fortune" Well-Known URI Registration URI suffix:: fortune Change controller:: IETF Specification document(s):: This document Related information:: N/A. [.comment] tag::sample[] // begin::sample[] [bibliography] == Normative References ++++ Key words for use in RFCs to Indicate Requirement Levels 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. Tse, et al. Expires October 20, 2018 [Page 148] Internet-Draft AsciiRFC Specifications April 2018 Defining Well-Known Uniform Resource Identifiers (URIs) This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing 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. Hypertext Transfer Protocol (HTTP/1.1): Caching 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. Problem Details for HTTP APIs This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. Tse, et al. Expires October 20, 2018 [Page 150] Internet-Draft AsciiRFC Specifications April 2018 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The JavaScript Object Notation (JSON) Data Interchange Format 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. ++++ [bibliography] == Informative References Tse, et al. Expires October 20, 2018 [Page 151] Internet-Draft AsciiRFC Specifications April 2018 ++++ ISO/DIS 8601-1:2018, Data elements and interchange formats -- Information interchange -- Representation of dates and times -- Part 1: Basic rules ISO/IEC
http://www.iso.org
Date and Time on the Internet: Timestamps The Transport Layer Security (TLS) Protocol Version 1.2 Tse, et al. Expires October 20, 2018 [Page 152] Internet-Draft AsciiRFC Specifications April 2018 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] ++++ [appendix] == Acknowledgements The authors thank the following individuals for their valuable feedback on this specification, and commend them for making fortune heuristics more accessible for the benefit of mankind. // end::sample[] [.comment] end::sample[] A.4. Rendered as RFC XML v3 An API For Calendar-Based Fortune Heuristics Services Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America gabriel.destiny@ribose.com
Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America charise.luck@ribose.com
Internet This document describes a JSON HTTP API for online services that provide calendar-based fortune heuristics.
IntroductionFortune-telling, the practice of predicting information about a person’s life, is an activity practiced throughout history. While there are myriad forms of fortune telling methodologies, this document applies to a particular form of service that provides fortune heuristics, commonly known as "luck", for a particular subject based on a calendar-based input. Since HTTP status codes are insufficient to convey Tse, et al. Expires October 20, 2018 [Page 154] Internet-Draft AsciiRFC Specifications April 2018 information about fortune heuristics, this specification defines a simple JSON document format for this purpose. The response can be used by HTTP APIs to deliver results to non-human clients or to an end-user.
Conventions Used in This DocumentThe 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 when, and only when, they appear in all capitals, as shown here. The following definitions apply in this document:
Well-known URI
This specification makes use of the "well-known URI" feature of HTTP servers to provide a bootstrapping URI for the client usage of fortune heuristics services.
Root of Fortune
The service discovery endpoint that provides a URI list of available fortune heuristic endpoints available, in accordance with .
Fortune Heuristics Service Well-Known URIA well-known URI called "fortune" is registered by this specification for fortune heuristics services (see ). Services complying with this document SHOULD have its well-known URI pointing (directly or through redirection) to the Root of Fortune. The Root of Fortune can be used by the client for service discovery, namely, the available calendar-based fortune heuristics services available on the server, as specified in .
Well-Known URI RedirectionServers MUST redirect HTTP requests for that resource to the actual "context path" using one of the available mechanisms provided by HTTP (e.g., using a 301, 303, or 307 response). Clients MUST handle HTTP redirects on the well-known URI.
Tse, et al. Expires October 20, 2018 [Page 155] Internet-Draft AsciiRFC Specifications April 2018
Well-Known URI Cache Behavior Servers SHOULD set an appropriate Cache-Control header value (as according to ) in the redirect response to set caching behavior as required by the type of response generated.
New HTTP Methods: SEEK and DIVINEThis specification defines two new HTTP methods: "SEEK" and "DIVINE" methods for HTTP . While HTTP GET requests are treated equivalently as the "SEEK" and "DIVINE" requests, its usage is discouraged and therefore SHOULD NOT be used. Usage of these methods are defined in the sections below.
Defined Data Types: Date-Time FormatsThis specification defines a number of date-time formats as according to the conventions of for the unambiguous communication between client and server. The types defined are as follows.
DATETIME
As described in , with the addition that reduced accuracy representations described in are supported. Reduced accuracy date and times are accepted where a date or time component (2-digits long) is replaced by "--". For example, the date time "2018-04---T01:02:00Z" represents the UTC time of 1:02am, on an unknown day within April of the year 2018.
DATE
As described in "DATETIME", but the "time" component will not be taken into account in the algorithm.
Fortune Heuristics Service Discovery Tse, et al. Expires October 20, 2018 [Page 156] Internet-Draft AsciiRFC Specifications April 2018
Root of Fortune Path URI ("/")The Root of Fortune URI, defined as "/" in this document, is used for service discovery on types of calendar-based fortune heuristics available. An empty SEEK request with the "application/json" request type MUST be sent to this endpoint to retrieve the available endpoints. All other HTTP methods MUST NOT be supported at this URI. An example of such a response is as follows:
A service discovery object MUST have the following members:
diviners
(JSON array) An array that contains endpoints that conform to this specification. All endpoints listed here are relative to the Root of Fortune path. For example, the path "/astrology" listed in the example has an endpoint path of "[root-of-fortune]/astrology", where "[root-of-fortune]" indicates the real path of the Root of Fortune.
Fortune Heuristics Service EndpointAn endpoint offering fortune heuristics services MUST adhere to specifications in this section. Tse, et al. Expires October 20, 2018 [Page 157] Internet-Draft AsciiRFC Specifications April 2018 A service MAY implement multiple divination services based on different divination methods, such as the digital oracle shown in .
Dimensional Eye, a digital oracle that communicates through one button
Service Specification RequestTo retrieve capabilities and parameters of an endpoint complying with this specification, a service specification JSON object is returned. Tse, et al. Expires October 20, 2018 [Page 158] Internet-Draft AsciiRFC Specifications April 2018 An empty SEEK request with the "application/json" request type MUST be sent to this endpoint to retrieve the service specification that describes parameters accepted by this endpoint. Two examples of such a response are given below.
Service Specification ObjectA service specification object MUST contain the following members.
description
(string) A short, human-readable summary of the fortune heuristic service at this endpoint. This SHOULD be a stable reference.
details
(URI, optional) A URI reference that provides further details for human consumption, such as API documentation that includes details of parameters accepted or response states.
parameters
(object, mandatory) An object that specifies what parameters are accepted by this endpoint. Each parameter key within this object Tse, et al. Expires October 20, 2018 [Page 160] Internet-Draft AsciiRFC Specifications April 2018 specifies an accepted parameter name, and its value is a parameter specification object, which is described below.
A parameter specification object SHOULD contain the following members:
type
(string, optional) The value type accepted by this parameter. Value types are described in this document. This member is mutually exclusive with values.
description
(string, mandatory) The purpose of this parameter.
values
(object, optional) The accepted values of this parameter, unlisted values SHOULD not be accepted by the parameter. Each key within this object specifies an accepted value, and its value provides a description of the purpose of the value.
Fortune Heuristics Report Request and Response
Fortune Heuristics Report RequestA request using the HTTP "DIVINE" method and the "application/json" type MUST be sent to the fortune heuristic endpoint to retrieve results for a fortune heuristic query. The request made MUST conform to the specifications of the endpoint, as retrieved via the "SEEK" method described in . An example of a request is provided below.
Fortune Heuristics Report ResponseA fortune heuristic query using the "DIVINE" method triggers a response that contains a fortune heuristics report. A successful response returns a JSON object that MUST conform to the object structure described in this section. A report object SHOULD contain the following members:
type
(URI, mandatory) A URI that defines the type of the report located at the report key of this object.
report
(object, mandatory) An object that contains two keys, intervals and events. The intervals object contains an array of interval objects that matches the demanded intervals in the request within the target date range. The events object contains an array of significant event objects within the target date range.
An example of a response is provided below.
Fortune heuristic reports are created by a divination output that MAY requires quantitative interpretation. A sample representation of interpreting a graphical divination output is provided in .
Forty-nine yarrow sticks reveals a mystical message on fortune
Report Interval ObjectThe intervals value of a report object contains a number of report Tse, et al. Expires October 20, 2018 [Page 164] Internet-Draft AsciiRFC Specifications April 2018 intervals — each representing a non-overlapping period of the selected interval length. When all of these intervals are put together, the combined period MUST fully cover the requested report target period. An example interval object is shown below.
An interval object MUST contain the following members:
dateStart
(datetime, mandatory) This value specifies the start of the period which this interval object applies to.
dateEnd
(datetime, mandatory) This value specifies the end of the period Tse, et al. Expires October 20, 2018 [Page 165] Internet-Draft AsciiRFC Specifications April 2018 which this interval object applies to.
In the given example, the categories key is an implementation specific object that details heuristic results returned by the selected algorithm. This MAY differ in different algorithms.
Report Events ObjectThe events value of a report object contains a number of event objects. Each event object represents an event relevant to the calculation of fortune heuristics during a target report period. These events MAY be of variable time lengths, and MAY be overlapping amongst each other. The following example demonstrates two event objects the service determines relevant to a user’s query.
Similar to an interval object, an event object MUST contain the following members:
dateStart
(datetime, mandatory) This value specifies the start of the period described by the event.
dateEnd
Tse, et al. Expires October 20, 2018 [Page 166] Internet-Draft AsciiRFC Specifications April 2018
(datetime, mandatory) This value specifies the end of the period described by the event.
In the given example, the keys description and recommendation are implementation-specific details. This MAY differ in different algorithms.
Report Generation ErrorsThis specification makes use of normal HTTP error codes with the following extensions. Errors MUST be returned using the Problem JSON Structure as accordance with .
422 Unprocessable Entity
For example, a malformed date-time parameter, or an illogical input, such as when the subject’s birthday occurs after the report target date period.
473 Beyond Existing Capability
The service determines that the outcome is too difficult to predict. For example, in the case where the calculation is too complex to complete in a certain time period. The service SHOULD issue this response code to indicate that the client should not try the same request again.
474 Outcome Impossible
The service determines that the outcome is impossible. For example, when the algorithm determines that the subject will have deceased before the start of the requested target period.
Security Considerations
  • TLS and authenticated HTTP requests should be used to protect the DIVINE request and responses due to the personal nature of information transmitted.
  • A client SHOULD verify the identity of the server on every request to prevent impersonation or man-in-the-middle attacks, as data transmitted to and from the server is sensitive information, and at times critical information to the user.
  • Synchronization of client and server time MUST be Tse, et al. Expires October 20, 2018 [Page 167] Internet-Draft AsciiRFC Specifications April 2018 well-considered in the implementation of this specification. A mismatch of client and server time MAY lead to algorithm miscalculations that can cause mistaken choices of a user that depends on the reliability of this system.
IANA Considerations
Well-Known URI RegistrationsThis document defines a well-known URI using the registration procedure and template from .
"fortune" Well-Known URI Registration
URI suffix
fortune
Change controller
IETF
Specification document(s)
This document
Related information
N/A.
 Normative References Informative References ISO/DIS 8601-1:2018, Data elements and interchange formats -- Information interchange -- Representation of dates and times -- Part 1: Basic rules ISO/IEC
http://www.iso.org
AcknowledgementsThe authors thank the following individuals for their valuable feedback on this specification, and commend them for making fortune heuristics more accessible for the benefit of mankind. Tse, et al. Expires October 20, 2018 [Page 169] Internet-Draft AsciiRFC Specifications April 2018
Appendix B. Acknowledgements The authors would like to thank the following persons for their valuable advice and input. o Adrian Farrel for his comprehensive review of the document and numerous beneficial suggestions. Authors' Addresses Ronald Henry Tse Ribose Suite 1111, 1 Pedder Street Central, Hong Kong Hong Kong Email: ronald.tse@ribose.com URI: https://www.ribose.com Nick Nicholas Ribose Australia Email: nick.nicholas@ribose.com URI: https://www.ribose.com Jeffrey Lau Ribose Suite 1111, 1 Pedder Street Central, Hong Kong Hong Kong Email: jeffrey.lau@ribose.com URI: https://www.ribose.com Tse, et al. Expires October 20, 2018 [Page 170] Internet-Draft AsciiRFC Specifications April 2018 Paolo Brasolin Ribose Italy Email: paolo.brasolin@ribose.com URI: https://www.ribose.com Tse, et al. Expires October 20, 2018 [Page 171] ./draft-sekar-dns-llq-06.txt0000644000764400076440000014333113527637006015124 0ustar iustyiusty Network Working Group S. Cheshire Internet-Draft M. Krochmal Intended status: Informational Apple Inc. Expires: February 23, 2020 August 22, 2019 Apple's DNS Long-Lived Queries protocol draft-sekar-dns-llq-06 Abstract Apple's DNS Long-Lived Queries protocol (LLQ) is a protocol for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2019, the LLQ protocol was superseded by the IETF Standards Track RFC xxxx [[RFC Editor note: Please replace xxxx with RFC number]] "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement. The existing LLQ protocol deployed and used from 2005 to 2019 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications. 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 https://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 23, 2020. Cheshire & Krochmal Expires February 23, 2020 [Page 1] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 Copyright Notice Copyright (c) 2019 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Transition to DNS Push Notifications . . . . . . . . . . 4 2. Conventions and Terminology Used in this Document . . . . . . 4 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Assigned Numbers . . . . . . . . . . . . . . . . . . . . 5 3.2. Opt-RR Format . . . . . . . . . . . . . . . . . . . . . . 6 4. LLQ Address and Port Identification . . . . . . . . . . . . . 7 5. LLQ Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Setup Message Retransmission . . . . . . . . . . . . . . 9 5.2. LLQ Setup Four-Way Handshake . . . . . . . . . . . . . . 9 5.2.1. Setup Request . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Setup Challenge . . . . . . . . . . . . . . . . . . . 11 5.2.3. Challenge Response . . . . . . . . . . . . . . . . . 14 5.2.4. ACK + Answers . . . . . . . . . . . . . . . . . . . . 15 5.3. Resource Record TTLs . . . . . . . . . . . . . . . . . . 16 6. Event Responses . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Add Events . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Remove Events . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Gratuitous Response Acknowledgments . . . . . . . . . . . 18 7. LLQ Lease-Life Expiration . . . . . . . . . . . . . . . . . . 19 7.1. Refresh Request . . . . . . . . . . . . . . . . . . . . . 19 7.2. LLQ Refresh Acknowledgment . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8.1. Server DOS . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Client Packet Storms . . . . . . . . . . . . . . . . . . 21 8.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Problems with the LLQ Protocol . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Cheshire & Krochmal Expires February 23, 2020 [Page 2] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 1. Introduction In dynamic environments, DNS Service Discovery [RFC6763] benefits significantly from clients being able to learn about changes to DNS information via a mechanism that is both more timely and more efficient than simple polling. Such a mechanism enables "live browses" that learn when a new instance of a service appears, or when an existing service disappears from the network, and allows clients to monitor changes to a service. Multicast DNS [RFC6762] supports this natively. When a host on the network publishes or deletes DNS records, these changes are multicast to other hosts on the network. These hosts deliver the change notifications to interested clients (applications running on the host). Hosts also send occasional queries to the network in case gratuitous announcements are not received due to packet loss, and to detect records lost due to their publishers crashing or having become disconnected from the network. This document defines an Apple extension to DNS that enables a client to issue long-lived queries that allow a DNS server to notify clients about changes to DNS data. This is a more scalable and practical solution than can be achieved by polling of the name server because a low polling rate could leave the client with stale information while a high polling rate would have an adverse impact on the network and server. The mechanism defined in this document is now being replaced by DNS Push Notifications [Push] as explained below in Section 1.1. Cheshire & Krochmal Expires February 23, 2020 [Page 3] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 1.1. Transition to DNS Push Notifications The LLQ protocol enjoyed over a decade of useful operation, enabling timely live updates for the service discovery user interface in Apple's Back to My Mac [RFC6281] service. However, some problems were discovered, as described in Appendix A. This operational experience with LLQ informed the design of its IETF Standards Track successor, DNS Push Notifications [Push]. Since no further work is being done on the LLQ protocol, this LLQ specification will not be updated to remedy these problems. All existing LLQ implementations are RECOMMENDED to migrate to using DNS Push Notifications instead. For existing LLQ servers, they are RECOMMENDED to implement and support DNS Push Notifications, so that clients can begin migrating to the newer protocol. For existing LLQ clients, they are RECOMMENDED to query for the "_dns-push-tls._tcp." SRV record first, and only if DNS Push fails, then fall back to query for "_dns-llq._udp." instead. This will cause clients to prefer the newer protocol when possible. It is RECOMMENDED that clients always attempt DNS Push Notifications first for every new request, and only if that fails, then back to using LLQ. Clients SHOULD NOT record that a given server only speaks LLQ and subsequently default to LLQ for that server, since server software gets updated, and even a server that speaks only LLQ today, may be updated to support DNS Push Notifications tomorrow. New client and server implementations are RECOMMENDED to support only DNS Push Notifications. 2. Conventions and Terminology Used in this Document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Cheshire & Krochmal Expires February 23, 2020 [Page 4] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 3. Mechanisms DNS Long-Lived Queries (DNS-LLQ) is implemented using the standard DNS message format [RFC1035] in conjunction with an EDNS(0) OPT pseudo-RR [RFC6891] with a new OPT and RDATA format specified here. Encoding the LLQ request in an OPT RR allows for implementation of LLQ with minimal modification to a name server's front-end. If a DNS query containing an LLQ option is sent to a server that does not implement LLQ, a server that complies with the EDNS(0) specification [RFC6891] will silently ignore the unrecognized option and answer the request as a normal DNS query, without establishing any long-lived state, and without returning an LLQ option in its response. If a DNS query containing an LLQ option is sent to a server that does not implement EDNS(0) at all, the server may silently ignore the EDNS(0) OPT pseudo-RR, or it may return a nonzero RCODE. However, in practice this issue is mostly theoretical, since having a zone's _dns-llq._udp. SRV record target a host that does not implement LLQ is a configuration error. Note that this protocol is designed for data set sizes of a few dozen resource records at most, and change rates no more than one every ten seconds on average. Data sets in response to queries that frequently exceed a single packet, or that experience a rapid change rate, may have undesirable performance implications. 3.1. Assigned Numbers This section describes constants uses in this document. EDNS(0) Option Code (recorded with IANA): LLQ 1 LLQ-PORT 5352 (recorded with IANA) LLQ Error Codes (specific to this LLQ EDNS(0) Option): NO-ERROR 0 SERV-FULL 1 STATIC 2 FORMAT-ERR 3 NO-SUCH-LLQ 4 BAD-VERS 5 UNKNOWN-ERR 6 LLQ Opcodes (specific to this LLQ EDNS(0) Option): LLQ-SETUP 1 LLQ-REFRESH 2 LLQ-EVENT 3 Cheshire & Krochmal Expires February 23, 2020 [Page 5] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 3.2. Opt-RR Format As required by the EDNS(0) specification [RFC6891], all OPT-RRs used in LLQs are formatted as follows: Field Name Field Type Description --------------------------------------------------------------------- NAME domain name empty (root domain) TYPE u_int16_t OPT CLASS u_int16_t 0* TTL u_int32_t 0 RDLEN u_int16_t describes RDATA RDATA octet stream (see below) * The CLASS field indicates, as per the EDNS(0) specification [RFC6891], the sender's UDP payload size. However, clients and servers need not be required to determine their reassembly buffer size, path MTU, etc. to support LLQ. Thus, the sender of an LLQ Request or Response MAY set the CLASS field to 0. The recipient MUST ignore the class field if it is set to 0. RDATA Format: Field Name Field Type Description --------------------------------------------------------------------- OPTION-CODE u_int16_t LLQ OPTION-LENGTH u_int16_t Length of following fields, as appropriate VERSION u_int16_t Version of LLQ protocol implemented LLQ-OPCODE u_int16_t Identifies LLQ operation ERROR-CODE u_int16_t Identifies LLQ errors LLQ-ID u_int64_t Identifier for an LLQ LEASE-LIFE u_int32_t Requested or granted life of LLQ, in seconds This data format, consisting of (OPTION-CODE, OPTION-LENGTH, LLQ-Metadata) tuples, may be repeated an arbitrary number of times in the RDATA section, with the RDLEN field set accordingly. The size and meaning of the OPTION-CODE and OPTION-LENGTH fields are as described in the EDNS(0) specification [RFC6891]. The remainder of the fields comprise the OPTION-DATA of the EDNS(0) option. Since for LLQ the OPTION-DATA is a fixed size, in LLQ EDNS(0) options the OPTION-LENGTH field always has the value 18. Cheshire & Krochmal Expires February 23, 2020 [Page 6] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 4. LLQ Address and Port Identification The client requires a mechanism to determine to which server it should send LLQ operations. Additionally, some firewalls block direct communication with a name server on port 53 to avoid spoof responses. However, this direct communication is necessary for LLQs. Thus, servers MAY listen for LLQs on a different port (typically 5352). Clients also therefore need a mechanism to determine to which port to send LLQ operations. The client determines the server responsible for a given LLQ much as a client determines to which server to send a dynamic update. The client begins by sending a standard DNS query for the name of the LLQ, with type SOA. The server MUST answer with that SOA record in the Answer section, if the record exists. The server SHOULD include an SOA record for that name's zone in the Authority section, if the LLQ name (type SOA) does not exist. For example, a query for "_ftp._tcp.example.com." may return an SOA record named "example.com." in the Authority section if there is no SOA record named "_ftp._tcp.example.com." If, in this case, the server does not include the SOA record in the Authority section, the client strips the leading label from the name and tries again, repeating until an answer is received. This iterative zone apex discovery algorithm is described in more detail in the DNS Push Notifications specification [Push]. Upon learning the zone (SOA), the client then constructs and sends an SRV query for the name _dns-llq._udp., e.g., _dns-llq._udp.example.com. A server implementing LLQ MUST answer with an SRV record [RFC2782] for this name. The SRV RDATA is as follows: PRIORITY typically 0 WEIGHT typically 0 PORT typically 53 or 5352 TARGET name of server providing LLQs for the requested zone The server SHOULD include its address record(s) in the Additional section of the response. If the server does not include its address record in the Additional section, the client SHOULD query explicitly for the address record with the name of the SRV target. Cheshire & Krochmal Expires February 23, 2020 [Page 7] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 The client MUST send all LLQ requests, refreshes, and acknowledgments to the name server specified in the SRV target, at the address contained in the address record for that target. Note that the queries described in this section (including those for SOA and SRV records) MAY be sent to an intermediate DNS recursive resolver -- they need not be sent directly to the name server. If, on issuing the SRV query, the client receives an NXDOMAIN response indicating that the SRV record does not exist, the client SHOULD conclude that the server does not support an LLQ in the requested zone. The client then SHOULD NOT send an LLQ request for the desired name, instead utilizing the behavior for LLQ-unaware servers described in Section 5 "LLQ Setup". Servers should send all messages to the source address and port of the LLQ setup message received from the client. Cheshire & Krochmal Expires February 23, 2020 [Page 8] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 5. LLQ Setup An LLQ is initiated by a client, and is completed via a four-way handshake. This handshake provides resilience to packet loss, demonstrates client reachability, and reduces denial of service attack opportunities (see Section 8 "Security Considerations"). 5.1. Setup Message Retransmission LLQ Setup Requests and Responses sent by the client SHOULD be retransmitted if no acknowledgments are received. The client SHOULD re-try up to two more times (for a total of 3 attempts) before considering the server down or unreachable. The client MUST wait at least 2 seconds before the first retransmission and 4 seconds between the first and second retransmissions. The client SHOULD listen for a response for at least 8 seconds after the 3rd attempt before considering the server down or unreachable. Upon determining a server to be down, a client MAY periodically attempt to re-initiate an LLQ setup, at a rate of not more than once per hour. Servers MUST NOT re-transmit acknowledgments that do not generate responses from the client. Retransmission in setup is client-driven, freeing servers from maintaining timers for incomplete LLQ setups. If servers receive duplicate messages from clients (perhaps due to the loss of the server's responses mid-flight), the server MUST re-send its reply (possibly modifying the LEASE-LIFE as described in Section 5.2.4 "ACK + Answers"). Servers MUST NOT garbage collect LLQs that fail to complete the four- way handshake until the initially granted LEASE-LIFE has elapsed. 5.2. LLQ Setup Four-Way Handshake The four phases of the handshake include: 1) Setup Request client to server, identifies LLQ(s) requested 2) Setup Challenge server to client, provides error(s) for requested LLQs, and unique identifiers for the successful requests 3) Challenge Response client to server, echoes identifier(s), demonstrating client's reachability and willingness to participate 4) ACK + Answers server to client, confirms setup and provides initial answers Cheshire & Krochmal Expires February 23, 2020 [Page 9] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 5.2.1. Setup Request A request for an LLQ is formatted like a standard DNS query, but with an OPT RR containing LLQ metadata in its Additional section. LLQ setup requests are identified by the LLQ-SETUP opcode and a zero-valued LLQ-ID. The request MAY contain multiple questions to set up multiple LLQs. A request consisting of multiple questions MUST contain multiple LLQ metadata sections, one per question, with metadata sections in the same order as the questions they correspond to (i.e., the first metadata section corresponds to the first question, the second metadata section corresponds to the second question, etc.) If requesting multiple LLQs, clients SHOULD request the same LEASE-LIFE for each LLQ. Requests over UDP MUST NOT contain multiple questions if doing so would cause the message to not fit in a single packet. A client MUST NOT request multiple identical LLQs (i.e., containing the same qname/type/class) from the same source IP address and port. This requirement is to avoid unnecessary load on servers. In the case of multiple independent client implementations that may run on the same device without knowledge of each other, it is allowable if they by chance send LLQ requests for the same qname/type/class. These independent implementations on the same client will be using different source ports. Likewise, to the server, multiple independent clients behind the same NAT gateway will appear as if they were multiple independent clients using different ports on the same host. The query MUST NOT be for record type ANY (255), class ANY (255), or class NONE (0). Setup Request OPT-RR LLQ Metadata Format: Field Name Field Type Description --------------------------------------------------------------------- OPTION-CODE u_int16_t LLQ (1) OPTION-LENGTH u_int16_t Length of following fields (18) VERSION u_int16_t Version of LLQ protocol implemented by requester (1) LLQ-OPCODE u_int16_t LLQ-SETUP (1) ERROR-CODE u_int16_t NOERROR (0) LLQ-ID u_int64_t 0 LEASE-LIFE u_int32_t Desired life of LLQ request These fields MUST be repeated once for each additional query in the Question section. Cheshire & Krochmal Expires February 23, 2020 [Page 10] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 5.2.2. Setup Challenge Upon receiving an LLQ Setup Request, a server implementing LLQs will send a Setup Challenge to the requester (client). An LLQ Setup Challenge is a DNS Response, with the DNS message ID matching that of the request, and with all questions contained in the request present in the Question section of the response. Additionally, the challenge contains a single OPT-RR with an LLQ metadata section for each LLQ request, indicating the success or failure of each request. Metadata sections MUST be in the same order as the questions they correspond to. Note that in a request containing multiple questions some LLQs may succeed, while others may fail. Setup Challenge OPT-RR RDATA Format: Field Name Field Type Description --------------------------------------------------------------------- OPTION-CODE u_int16_t LLQ (1) OPTION-LENGTH u_int16_t Length of following fields (18) VERSION u_int16_t Version of LLQ protocol implemented in server (1) LLQ-OPCODE u_int16_t LLQ-SETUP (1) ERROR-CODE u_int16_t [As Appropriate] LLQ-ID u_int64_t [As Appropriate] LEASE-LIFE u_int32_t [As Appropriate] These fields MUST be repeated once for each query in the Questions section of the Setup Request. Cheshire & Krochmal Expires February 23, 2020 [Page 11] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 LLQ Metadata field descriptions: ERROR-CODE: Possible values include: NO-ERROR: The LLQ Setup Request was successful. FORMAT-ERR: The LLQ was improperly formatted. Note that if the rest of the DNS message is properly formatted, the DNS header error code MUST NOT include a format error code, as this would cause confusion between a server that does not understand the LLQ format, and a client that sends malformed LLQs. SERV-FULL: The server cannot grant the LLQ request because it is overloaded, or the request exceeds the server's rate limit (see Section 8 "Security Considerations"). Upon returning this error, the server MUST include in the LEASE-LIFE field a time interval, in seconds, after which the client may re-try the LLQ Setup. STATIC: The data for this name and type is not expected to change frequently, and the server therefore does not support the requested LLQ. The client MUST NOT poll for this name and type, nor should it re-try the LLQ Setup, and should instead honor the normal resource record TTLs returned. BAD-VERS: The protocol version specified in the client's request is not supported by the server. UNKNOWN-ERR: The LLQ was not granted for an unknown reason Cheshire & Krochmal Expires February 23, 2020 [Page 12] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 LLQ-ID: On success, a random number generated by the server that is unique for the requested name/type/class. The LLQ-ID SHOULD be an unpredictable random number. A possible method of allocating LLQ-IDs with minimal bookkeeping would be to store the time, in seconds since the Epoch, in the high 32 bits of the field, and a cryptographically generated 32-bit random integer in the low 32 bits. On error, the LLQ-ID is set to 0. LEASE-LIFE: On success, the actual life of the LLQ, in seconds. Value may be greater than, less than, or equal to the value requested by the client, as per the server administrator's policy. The server MAY discard the LLQ after this LEASE-LIFE expires unless the LLQ has been renewed by the client (see Section 7 "LLQ Lease-Life Expiration"). The server MUST NOT generate events (see Section 6 "Event Responses") for expired LLQs. On SERV-FULL error, LEASE-LIFE MUST be set to a time interval, in seconds, after which the client may re-try the LLQ Setup. On other errors, the LEASE-LIFE MUST be set to 0. Cheshire & Krochmal Expires February 23, 2020 [Page 13] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 5.2.3. Challenge Response Upon issuing a Setup Request, a client listens for a Setup Challenge (5.2.2), re-transmitting the request as necessary (5.1). After receiving a successful Challenge, the client SHOULD send a Challenge Response to the server. This Challenge Response is a DNS request with questions from the request and challenge, and a single OPT-RR in the Additional section, with the OPT-RR RDATA identical to the OPT-RR RDATA contained in the Setup Challenge (i.e., echoing, for each set of fields, the random LLQ-ID and the granted lease life). If the challenge response contains multiple questions, the first question MUST correspond to the first OPT-RR RDATA tuple, etc. If the Setup Request fails with a STATIC error, the client MUST NOT poll the server. The client SHOULD honor the resource record TTLs contained in the response. If the Setup Request fails with a SERV-FULL error, the client MAY re-try the LLQ Setup Request (5.2.1) after the time indicated in the LEASE-LIFE field. If the Setup Request fails with an error other than STATIC or SERV-FULL, or the server is determined not to support LLQ (i.e., the client receives a DNS response with a nonzero RCODE, or a DNS response containing no LLQ option), the client MAY poll the server periodically with standard DNS queries, inferring Add and Remove events (see Section 6 "Event Responses") by comparing answers to these queries. The client SHOULD NOT poll more than once every 15 minutes for a given query. The client MUST NOT poll if it receives a STATIC error code in the acknowledgment. Cheshire & Krochmal Expires February 23, 2020 [Page 14] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 5.2.4. ACK + Answers Upon receiving a correct Challenge Response, a server MUST return an acknowledgment, completing the LLQ setup, and provide all current answers to the question(s). To acknowledge a successful Challenge Response, i.e., a Challenge Response in which the LLQ-ID and LEASE-LIFE echoed by the client match the values issued by the server, the server MUST send a DNS response containing all available answers to the question(s) contained in the original Setup Request, along with all additional resource records appropriate for those answers in the Additional section. The Additional section also contains an OPT-RR formatted as follows: Successful ACK + Answers OPT-RR RDATA Format: Field Name Field Type Description --------------------------------------------------------------------- OPTION-CODE u_int16_t LLQ OPTION-LENGTH u_int16_t Length of following fields, as appropriate VERSION u_int16_t Version of LLQ protocol implemented in server LLQ-OPCODE u_int16_t LLQ-SETUP (1) ERROR-CODE u_int16_t NO-ERROR LLQ-ID u_int64_t Originally granted ID, echoed in client's Response LEASE-LIFE u_int32_t Remaining life of LLQ, in seconds If there is a significant delay in receiving a Challenge Response, or multiple Challenge Responses are issued (possibly because they were lost en route to the client, causing the client to re-send the Challenge Response), the server MAY decrement the LEASE-LIFE by the time elapsed since the Setup Challenge was initially issued. If the setup is completed over UDP and all initially available answers to the question(s), additional records, and the OPT-RR do not fit in a single packet, some or all additional records (excluding the OPT-RR) MUST be omitted. If, after omission of all additional records, the answers still do not fit in a single message, answers MUST be removed until the message fits in a single packet. These answers not delivered in the ACK + Answers MUST be delivered without undue delay to the client via Add Events (Section 6 "Event Responses"). Cheshire & Krochmal Expires February 23, 2020 [Page 15] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 5.3. Resource Record TTLs The TTLs of resource records contained in answers to successful LLQs SHOULD be ignored by the client. The client MAY cache LLQ answers until the client receives a gratuitous announcement (see Section 6 "Event Responses") indicating that the answer to the LLQ has changed. The client SHOULD NOT cache answers after the LLQs LEASE-LIFE expires without being refreshed (see Section 7 "LLQ Lease-Life Expiration"). If an LLQ request fails, the client SHOULD NOT cache answers for a period longer than the client's polling interval. Note that resource records intended specifically to be transmitted via LLQs (e.g., DNS Service Discovery resource records) may have unusually short TTLs. This is because it is assumed that the records may change frequently, and that a client's cache coherence will be maintained via the LLQ and gratuitous responses. Short TTLs prevent stale information from residing in intermediate DNS recursive resolvers that are not LLQ-aware. TTLs of resource records included in the Additional section of an LLQ response (which do not directly answer the LLQ) SHOULD be honored by the client. Cheshire & Krochmal Expires February 23, 2020 [Page 16] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 6. Event Responses When a change ("event") occurs to a name server's zone, the server MUST check if the new or deleted resource records answer any LLQs. If so, the changes MUST be communicated to the LLQ requesters in the form of a gratuitous DNS response sent to the client, with the question(s) being answered in the Question section, and answers to these questions in the Answer section. The response also includes an OPT RR in the Additional section. This OPT RR contains, in its RDATA, an entry for each LLQ being answered in the message. Entries must include the LLQ-ID. This reduces the potential for spoof events being sent to a client. Event Response OPT-RR RDATA Format: Field Name Field Type Description --------------------------------------------------------------------- OPTION-CODE u_int16_t LLQ (1) OPTION-LENGTH u_int16_t Length of following fields (18) VERSION u_int16_t Version of LLQ protocol implemented in server (1) LLQ-OPCODE u_int16_t LLQ-EVENT (3) ERROR-CODE u_int16_t 0 LLQ-ID u_int64_t [As Appropriate] LEASE-LIFE u_int32_t 0 Gratuitous responses for a single LLQ MAY be batched, such that multiple changes are communicated in a single message. Responses MUST NOT be batched if this would cause a message that would otherwise fit in a single packet to be truncated. While responses MAY be deferred to provide opportunities for batching, responses SHOULD NOT be delayed, for purposes of batching, for more than 30 seconds, as this would cause an unacceptable latency for the client. After sending a gratuitous response, the server MUST listen for an acknowledgment from the client. If the client does not respond, the server MUST re-send the response. The server MUST re-send 2 times (for a total of 3 transmissions), after which the server MUST consider the client to be unreachable and delete its LLQ. The server MUST listen for 2 seconds before re-sending the response, 4 more seconds before re-sending again, and must wait an additional 8 seconds after the 3rd transmission before terminating the LLQ. The DNS message header of the response SHOULD include an unpredictable random number in the DNS message ID field, which is to be echoed in the client's acknowledgement. Cheshire & Krochmal Expires February 23, 2020 [Page 17] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 6.1. Add Events Add events occur when a new resource record appears, usually as the result of a dynamic update [RFC2136], that answers an LLQ. This record must be sent in the Answer section of the event to the client. Records that normally accompany this record in responses MAY be included in the Additional section, as per truncation restrictions described above. 6.2. Remove Events Remove events occur when a resource record previously sent to a client, either in an initial response, or in an Add Event, becomes invalid (normally as a result of being removed via a dynamic update). The deleted resource record is sent in the Answer section of the event to the client. The resource record TTL is set to -1, indicating that the record has been removed. 6.3. Gratuitous Response Acknowledgments Upon receiving a gratuitous response ("event"), the client MUST send an acknowledgment to the server. This acknowledgment is a DNS response echoing the OPT-RR contained in the event, with the message ID of the gratuitous response echoed in the message header. The acknowledgment MUST be sent to the source IP address and port from which the event originated. Cheshire & Krochmal Expires February 23, 2020 [Page 18] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 7. LLQ Lease-Life Expiration 7.1. Refresh Request If the client desires to maintain the LLQ beyond the duration specified in the LEASE-LIFE field of the Ack + Answers (5.2), the client MUST send a Refresh Request. A Refresh Request is identical to an LLQ Challenge Response (5.3), but with the LLQ-OPCODE set to LLQ-REFRESH. Unlike a Challenge Response, a Refresh Request returns no answers. The client SHOULD refresh an LLQ when 80% of its lease life has elapsed. As a means of reducing network traffic, when constructing refresh messages the client SHOULD include all LLQs established with a given server, even those not yet close to expiration. However, at least one LLQ MUST have elapsed at least 80% of its original LEASE-LIFE. The client MUST NOT include additional LLQs if doing so would cause the message to no longer fit in a single packet. In this case, the LLQs furthest from expiration should be omitted such that the message fits in a single packet. (These LLQs SHOULD be refreshed in a separate message when 80% of one or more of their lease lives have elapsed.) When refreshing multiple LLQs simultaneously, the message contains multiple questions, and a single OPT-RR with multiple LLQ metadata sections, one per question, with the metadata sections in the same order as the questions they correspond to. The client SHOULD specify the original lease life granted in the LLQ response as the desired LEASE-LIFE in the refresh request. If refreshing multiple LLQs simultaneously, the client SHOULD request the same lease life for all LLQs being refreshed (with the exception of termination requests, see below). To terminate an LLQ prior to its scheduled expiration (for instance, when the client terminates a DNS Service Discovery browse operation, or a client is about to go to sleep or shut down) the client specifies a lease life of 0. The client MUST listen for an acknowledgment from the server. The client MAY re-try up to two more times (for a total of 3 attempts) before considering the server down or unreachable. The client MUST NOT re-try a first time before 90% of the lease life has expired, and MUST NOT re-try again before 95% of the lease life has expired. If the server is determined to be down, the client MAY periodically attempt to re-establish the LLQ via an LLQ Setup Request message. The client MUST NOT attempt the LLQ Setup Request more than once per hour. Cheshire & Krochmal Expires February 23, 2020 [Page 19] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 7.2. LLQ Refresh Acknowledgment Upon receiving an LLQ Refresh message, a server MUST send an acknowledgment of the Refresh. This acknowledgment is formatted like the Setup ACK described in 5.2.3, but with the following variations: The LLQ-OPCODE is set to LLQ-REFRESH. NO-SUCH-LLQ MUST be returned as an error code if the client attempts to refresh an expired or non-existent LLQ (as determined by the LLQ-ID in the request). The LLQ-ID in the acknowledgment is set to the LLQ-ID in the request. Cheshire & Krochmal Expires February 23, 2020 [Page 20] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 8. Security Considerations Without care taken in the design of protocols such as this, servers may be susceptible to denial of service (DOS) attacks, and clients may be subjected to packet storms. Mechanisms have been added to the protocol to limit potential for these attacks. Note: This section contains no new protocol elements -- it serves only to explain the rationale behind protocol elements described above, as they relate to security. 8.1. Server DOS LLQs require that servers be stateful, maintaining entries for each LLQ over a potentially long period of time. If unbounded in quantity, these entries may overload the server. By returning SERV-FULL in Setup Challenges, the sever may limit the maximum number of LLQs it maintains. Additionally, the server may return SERV-FULL to limit the number of LLQs requested for a single name and type, or by a single client. This throttling may be in the form of a hard limit, or, preferably, by token-bucket rate limiting. Such rate limiting should occur rarely in normal use and is intended to prevent DOS attacks -- thus it is not built into the protocol explicitly, but is instead implemented at the discretion of an administrator via the SERV-FULL error and the LEASE-LIFE field to indicate a retry time to the client. 8.2. Client Packet Storms In addition to protecting the server from DOS attacks, the protocol limits the ability of a malicious host to cause the server to flood a client with packets. This is achieved via the four-way handshake upon setup, demonstrating reachability and willingness of the client to participate, and by requiring that gratuitous responses be ACK'd by the client. Additionally, rate-limiting by LLQ client address, as described in (8.1) serves to limit the number of packets that can be delivered to an unsuspecting client. 8.3. Spoofing A large random ID greatly reduces the risk of an off-path attacker sending spoof packets to the client (containing spoof events) or to the server (containing phony requests or refreshes). Cheshire & Krochmal Expires February 23, 2020 [Page 21] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 9. IANA Considerations The EDNS(0) OPTION CODE 1 has already been assigned for this DNS extension. IANA is requested to update the record in the DNS EDNS(0) Option Codes registry from "On-hold" to "Optional", and to set the reference to indicate the RFC number under which this document is published. TCP and UDP ports 5352 have already been assigned for LLQ. IANA is requested to add a reference to indicate the RFC number under which this document is published. No additional IANA services are required by this document. 10. Acknowledgments The concepts described in this document were originally explored, developed and implemented with help from Chris Sharp and Roger Pantos. In 2005 and 2006 Kiren Sekar made significant contributions to the first two drafts of this document, and he wrote much of the code for the implementation of LLQ that shipped in Mac OS X 10.4 Tiger in 2005. 11. References 11.1. Normative References [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications [[RFC Editor note: Please update reference "Push" to refer to assigned RFC number for that document]]", draft-ietf- dnssd-push-15 (work in progress), September 2018. [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, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . Cheshire & Krochmal Expires February 23, 2020 [Page 22] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [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, . [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, . [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, . [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, DOI 10.17487/RFC6281, June 2011, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013, . Cheshire & Krochmal Expires February 23, 2020 [Page 23] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 [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, . [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, . [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", BCP 14, RFC 8490, DOI 10.17487/RFC8490, October 2018, . [SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The Internet Protocol Journal, Cisco Systems, Volume 9, Number 4, December 2006. Cheshire & Krochmal Expires February 23, 2020 [Page 24] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 Appendix A. Problems with the LLQ Protocol In the course of using LLQ since 2005, some problems were discovered. Since no further work is being done on the LLQ protocol, this LLQ specification will not be updated to remedy these problems. LLQ's IETF Standards Track successor, DNS Push Notifications [Push], does not suffer from these problems, so all existing LLQ implementations are RECOMMENDED to migrate to using DNS Push Notifications, and all new implementations are RECOMMENDED to implement DNS Push Notifications instead of LLQ. Known problems with LLQ are documented here for the record. An LLQ "Setup Challenge" message from server to client is identical to an LLQ "ACK + Answers" message from server to client when there are no current answers for the query. If there is packet loss, retransmission, and duplication in the network, then a duplicated "Setup Challenge" message arriving late at the client would look like an "ACK + Answers" message with no answers, causing the client to clear its cache of any records matching the query. This LLQ specification states: "Servers MUST NOT garbage collect LLQs that fail to complete the four-way handshake until the initially granted LEASE-LIFE has elapsed." This is probably a mistake, since it exposes LLQ servers to an easy resource-exhaustion denial-of- service attack. DNS Push Notifications is built using DNS Stateful Operations [RFC8490], which uses TLS over TCP, and a benefit of building on TCP is that there are already established industry best practices to guard against SYN flooding and similar attacks [SYN] [RFC4953] LLQ is built using UDP, and because the UDP protocol has no standardized way of indicating the start and end of a session, firewalls and NAT gateways tend to be fairly agressive about recycling UDP mappings that they believe to be disused [RFC4787] [RFC5382] [RFC7857]. Using a high keepalive traffic rate to maintain firewall or NAT mapping state could remedy this, but would largely defeat the purpose of using LLQ in the first place, which is to provide efficient change notification without wasteful polling. Because of this, existing LLQ clients use NAT Port Mapping Protocol (NAT-PMP) [RFC6886] and/or Port Control Protocol (PCP) [RFC6887] to establish longer port mapping lifetimes. This solves the problem, but adds extra complexity, and doesn't work with firewalls and NAT gateways that don't support NAT-PMP or PCP. By using TCP instead of UDP, the DNS Push Notifications protocol benefits from better longevity of sessions through firewalls and NAT gateways that don't support NAT-PMP or PCP. Cheshire & Krochmal Expires February 23, 2020 [Page 25] Internet-Draft Apple's DNS Long-Lived Queries protocol August 2019 Authors' Addresses Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, CA 95014 United States of America Phone: +1 (408) 996-1010 Email: cheshire@apple.com Marc Krochmal Apple Inc. One Apple Park Way Cupertino, California 95014 USA Email: marc@apple.com Cheshire & Krochmal Expires February 23, 2020 [Page 26] ./draft-sheffer-tls-pinning-ticket-12.txt0000644000764400076440000020131113504707340017572 0ustar iustyiusty Network Working Group Y. Sheffer Internet-Draft Intuit Intended status: Experimental D. Migault Expires: December 28, 2019 Ericsson June 26, 2019 TLS Server Identity Pinning with Tickets draft-sheffer-tls-pinning-ticket-12 Abstract Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing. This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions 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 https://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 28, 2019. Sheffer & Migault Expires December 28, 2019 [Page 1] Internet-Draft Pinning Tickets June 2019 Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . 5 1.2. Scope of Experimentation . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Initial Connection . . . . . . . . . . . . . . . . . . . 7 2.2. Subsequent Connections . . . . . . . . . . . . . . . . . 9 2.3. Indexing the Pins . . . . . . . . . . . . . . . . . . . . 10 3. Message Definitions . . . . . . . . . . . . . . . . . . . . . 10 4. Cryptographic Operations . . . . . . . . . . . . . . . . . . 11 4.1. Pinning Secret . . . . . . . . . . . . . . . . . . . . . 11 4.2. Pinning Ticket . . . . . . . . . . . . . . . . . . . . . 11 4.3. Pinning Protection Key . . . . . . . . . . . . . . . . . 12 4.4. Pinning Proof . . . . . . . . . . . . . . . . . . . . . . 12 5. Operational Considerations . . . . . . . . . . . . . . . . . 13 5.1. Protection Key Synchronization . . . . . . . . . . . . . 13 5.2. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 14 5.3. Certificate Renewal . . . . . . . . . . . . . . . . . . . 14 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 14 5.5. Disabling Pinning . . . . . . . . . . . . . . . . . . . . 15 5.6. Server Compromise . . . . . . . . . . . . . . . . . . . . 15 5.7. Disaster Recovery . . . . . . . . . . . . . . . . . . . . 15 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 6.1. Mint Fork . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 16 6.1.2. Description . . . . . . . . . . . . . . . . . . . . . 16 6.1.3. Level of Maturity . . . . . . . . . . . . . . . . . . 17 6.1.4. Coverage . . . . . . . . . . . . . . . . . . . . . . 17 6.1.5. Version Compatibility . . . . . . . . . . . . . . . . 17 6.1.6. Licensing . . . . . . . . . . . . . . . . . . . . . . 17 6.1.7. Contact Information . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 Sheffer & Migault Expires December 28, 2019 [Page 2] Internet-Draft Pinning Tickets June 2019 7.1. Trust on First Use (TOFU) and MITM Attacks . . . . . . . 17 7.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 18 7.3. Server-Side Error Detection . . . . . . . . . . . . . . . 18 7.4. Client Policy and SSL Proxies . . . . . . . . . . . . . . 18 7.5. Client-Side Error Behavior . . . . . . . . . . . . . . . 18 7.6. Stolen and Forged Tickets . . . . . . . . . . . . . . . . 18 7.7. Client Privacy . . . . . . . . . . . . . . . . . . . . . 19 7.8. Ticket Protection Key Management . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Previous Work . . . . . . . . . . . . . . . . . . . 23 A.1. Comparison: HPKP . . . . . . . . . . . . . . . . . . . . 24 A.2. Comparison: TACK . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Document History . . . . . . . . . . . . . . . . . . 27 B.1. draft-sheffer-tls-pinning-ticket-12 . . . . . . . . . . . 27 B.2. draft-sheffer-tls-pinning-ticket-11 . . . . . . . . . . . 27 B.3. draft-sheffer-tls-pinning-ticket-10 . . . . . . . . . . . 27 B.4. draft-sheffer-tls-pinning-ticket-09 . . . . . . . . . . . 27 B.5. draft-sheffer-tls-pinning-ticket-08 . . . . . . . . . . . 27 B.6. draft-sheffer-tls-pinning-ticket-07 . . . . . . . . . . . 28 B.7. draft-sheffer-tls-pinning-ticket-06 . . . . . . . . . . . 28 B.8. draft-sheffer-tls-pinning-ticket-05 . . . . . . . . . . . 28 B.9. draft-sheffer-tls-pinning-ticket-04 . . . . . . . . . . . 28 B.10. draft-sheffer-tls-pinning-ticket-03 . . . . . . . . . . . 28 B.11. draft-sheffer-tls-pinning-ticket-02 . . . . . . . . . . . 28 B.12. draft-sheffer-tls-pinning-ticket-01 . . . . . . . . . . . 28 B.13. draft-sheffer-tls-pinning-ticket-00 . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Misissued public-key certificates can prevent TLS [RFC8446] clients from appropriately authenticating the TLS server. This is a significant risk in the context of the global public key infrastructure (PKI), and similarly for large scale deployments of certificates within enterprises. This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. The approach is intended to be easy to implement and deploy, and reuses some of the ideas behind TLS session resumption [RFC5077]. Ticket pinning is a second factor server authentication method and is not proposed as a substitute for the authentication method provided in the TLS key exchange. More specifically, the client only uses the Sheffer & Migault Expires December 28, 2019 [Page 3] Internet-Draft Pinning Tickets June 2019 pinning identity method after the TLS key exchange is successfully completed. In other words, the pinning identity method is only performed over an authenticated TLS session. Note that Ticket Pinning does not pin certificate information and therefore is truly an independent second factor authentication. Ticket pinning is a Trust On First Use (TOFU) mechanism, in that the first server authentication is only based on PKI certificate validation, but for any follow-on sessions, the client is further ensuring the server's identity based on the server's ability to decrypt the ticket, in addition to normal PKI certificate authentication. During initial TLS session establishment, the client requests a pinning ticket from the server. Upon receiving the request the server generates a pinning secret which is expected to be unpredictable for peers other than the client or the server. In our case, the pinning secret is generated from parameters exchanged during the TLS key exchange, so client and server can generate it locally and independently. The server constructs the pinning ticket with the necessary information to retrieve the pinning secret. The server then encrypts the ticket and returns the pinning ticket to the client with an associated pinning lifetime. The pinning lifetime value indicates for how long the server promises to retain the server-side ticket-encryption key, which allows it to complete the protocol exchange correctly and prove its identity. The server commitment (and ticket lifetime) is typically on the order of weeks. Once the key exchange is completed and the server is deemed authenticated, the client generates locally the pinning secret and caches the server's identifiers to index the pinning secret as well as the pinning ticket and its associated lifetime. When the client re-establishes a new TLS session with the server, it sends the pinning ticket to the server. Upon receiving it, the server returns a proof of knowledge of the pinning secret. Once the key exchange is completed and the server has been authenticated, the client checks the pinning proof returned by the server using the client's stored pinning secret. If the proof matches, the client can conclude that the server it is currently connecting to is in fact the correct server. This document only applies to TLS 1.3. We believe that the idea can also be back-fitted into earlier versions of the protocol, but this would require significant changes. One example is that TLS 1.2 [RFC5246] and earlier versions do not provide a generic facility of Sheffer & Migault Expires December 28, 2019 [Page 4] Internet-Draft Pinning Tickets June 2019 encrypted handshake extensions, such as is used here to transport the ticket. The main advantages of this protocol over earlier pinning solutions are: - The protocol is at the TLS level, and as a result is not restricted to HTTP at the application level. - The protocol is robust to server IP, Certificate Authority (CA), and public key changes. The server is characterized by the ownership of the pinning protection key, which is never provided to the client. Server configuration parameters such as the CA and the public key may change without affecting the pinning ticket protocol. - Once a single parameter is configured (the ticket's lifetime), operation is fully automated. The server administrator need not bother with the management of backup certificates or explicit pins. - For server clusters, we reuse the existing [RFC5077] infrastructure where it exists. - Pinning errors, presumably resulting from man-in-the-middle (MITM) attacks, can be detected both by the client and the server. This allows for server-side detection of MITM attacks using large-scale analytics, and with no need to rely on clients to explicitly report the error. A note on terminology: unlike other solutions in this space, we do not do "certificate pinning" (or "public key pinning"), since the protocol is oblivious to the server's certificate. We prefer the term "server identity pinning" for this new solution. In our solution, the server proves its identity by generating a proof that it can read and decrypt an encrypted ticket. As a result, the identity proof relies on proof of ownership of the pinning protection key. However, this key is never exchanged with the client or known by it, and so cannot itself be pinned. 1.1. Conventions used in this document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Sheffer & Migault Expires December 28, 2019 [Page 5] Internet-Draft Pinning Tickets June 2019 1.2. Scope of Experimentation This document describes an experimental extension to the TLS protocol. This section defines constraints on this experiment and how it can yield useful information, potentially resulting in a standard. The protocol is designed so that if the server does not support it, the client and server fall back to a normal TLS exchange, with the exception of a single PinningTicket extension being initially sent by the client. In addition, the protocol is designed to only strengthen the validation of the server's identity ("second factor"). As a result, implementation or even protocol errors should not result in weakened security compared to the normal TLS exchange. Given these two points, experimentation can be run on the open Internet between consenting client and server implementations. The goal of the experiment is to prove that: - Non-supporting clients and servers are unaffected. - Connectivity between supporting clients and servers is retained under normal circumstances, whether the client connects to the server frequently (relative to the ticket's lifetime) or very rarely. - Enterprise middleboxes do not interrupt such connectivity. - Misissued certificates and rogue TLS-aware middleboxes do result in broken connectivity, and these cases are detected on the client and/or server side. Clients and servers can be recovered even after such events and the normal connectivity restored. Following two years of successful deployment, the authors will publish a document that summarizes the experiment's findings and will resubmit the protocol for consideration as a Proposed Standard. 2. Protocol Overview The protocol consists of two phases: the first time a particular client connects to a server, and subsequent connections. This protocol supports full TLS handshakes, as well as 0-RTT handshakes. Below we present it in the context of a full handshake, but behavior in 0-RTT handshakes should be identical. The document presents some similarities with the ticket resumption mechanism described in [RFC5077]. However the scope of this document Sheffer & Migault Expires December 28, 2019 [Page 6] Internet-Draft Pinning Tickets June 2019 differs from session resumption mechanisms implemented with [RFC5077] or with other mechanisms. Specifically, the pinning ticket does not carry any state associated with a TLS session and thus cannot be used for session resumption, or to authenticate the client. Instead, the pinning ticket only contains the encrypted pinning secret. The pinning ticket is used by the server to prove its ability to decrypt it, which implies ownership of the pinning protection key. [RFC5077] has been obsoleted by [RFC8446] and ticket resumption is now defined by Sec. 2.2 of [RFC8446]. This document references [RFC5077] as an informational document since it contains a more thorough discussion of stateless ticket resumption and because ticket resumption benefits from significant operational experience with TLS 1.2 that is still widely deployed at the time of writing this document. This experience as well as deployment can easily be re- used for identity pinning. With TLS 1.3, session resumption is based on a preshared key (PSK). This is orthogonal to this protocol. With TLS 1.3, a TLS session can be established using PKI and a pinning ticket, and later resumed with PSK. However, the protocol described in this document addresses the problem of misissued certificates. Thus, it is not expected to be used outside a certificate-based TLS key exchange, such as in PSK. As a result, PSK handshakes MUST NOT include the extension defined here. 2.1. Initial Connection When a client first connects to a server, it requests a pinning ticket by sending an empty PinningTicket extension, and receives it as part of the server's first response, in the returned PinningTicket extension. Sheffer & Migault Expires December 28, 2019 [Page 7] Internet-Draft Pinning Tickets June 2019 Client Server ClientHello + key_share + signature_algorithms + PinningTicket --------> ServerHello + key_share {EncryptedExtensions + PinningTicket} {CertificateRequest*} {Certificate*} {CertificateVerify*} <-------- {Finished} {Certificate*} {CertificateVerify*} {Finished} --------> [Application Data] <-------> [Application Data] * Indicates optional or situation-dependent messages that are not always sent. {} Indicates messages protected using keys derived from the ephemeral secret. [] Indicates messages protected using keys derived from the master secret. If a client supports the PinningTicket extension and does not have any pinning ticket associated with the server, the exchange is considered as an initial connection. Other reasons the client may not have a pinning ticket include the client having flushed its pinning ticket store, or the committed lifetime of the pinning ticket having expired. Upon receipt of the PinningTicket extension, the server computes a pinning secret (Section 4.1), and sends the pinning ticket (Section 4.2) encrypted with the pinning protection key (Section 4.3). The pinning ticket is associated with a lifetime value by which the server assumes the responsibility of retaining the pinning protection key and being able to decrypt incoming pinning tickets during the period indicated by the committed lifetime. Once the pinning ticket has been generated, the server returns the pinning ticket and the committed lifetime in a PinningTicket extension embedded in the EncryptedExtensions message. We note that a PinningTicket extension MUST NOT be sent as part of a HelloRetryRequest. Sheffer & Migault Expires December 28, 2019 [Page 8] Internet-Draft Pinning Tickets June 2019 Upon receiving the pinning ticket, the client MUST NOT accept it until the key exchange is completed and the server authenticated. If the key exchange is not completed successfully, the client MUST ignore the received pinning ticket. Otherwise, the client computes the pinning secret and SHOULD cache the pinning secret and the pinning ticket for the duration indicated by the pinning ticket lifetime. The client SHOULD clean up the cached values at the end of the indicated lifetime. 2.2. Subsequent Connections When the client initiates a connection to a server it has previously seen (see Section 2.3 on identifying servers), it SHOULD send the pinning ticket for that server. The pinning ticket, pinning secret and pinning ticket lifetime computed during the establishment of the previous TLS session are designated in this document as the "original" ones, to distinguish them from a new ticket that may be generated during the current session. The server MUST extract the original pinning_secret value from the ticket and MUST respond with a PinningTicket extension, which includes: - A proof that the server can understand the ticket that was sent by the client; this proof also binds the pinning ticket to the server's (current) public key, as well as the ongoing TLS session. The proof is mandatory and MUST be included if a pinning ticket was sent by the client. - A fresh pinning ticket. The main reason for refreshing the ticket on each connection is privacy: to avoid the ticket serving as a fixed client identifier. While a fresh pinning ticket might be of zero length, it is RECOMMENDED to include a fresh ticket with a non zero length with each response. If the server cannot validate the received ticket, that might indicate an earlier MITM attack on this client. The server MUST then abort the connection with a handshake_failure alert, and SHOULD log this failure. The client MUST verify the proof, and if it fails to do so, MUST issue a handshake_failure alert and abort the connection (see also Section 7.5). It is important that the client does not attempt to "fall back" by omitting the PinningTicket extension. When the connection is successfully set up, i.e. after the Finished message is verified, the client SHOULD store the new ticket along with the corresponding pinning_secret, replacing the original ticket. Sheffer & Migault Expires December 28, 2019 [Page 9] Internet-Draft Pinning Tickets June 2019 Although this is an extension, if the client already has a ticket for a server, the client MUST interpret a missing PinningTicket extension in the server's response as an attack, because of the server's prior commitment to respect the ticket. The client MUST abort the connection in this case. See also Section 5.5 on ramping down support for this extension. 2.3. Indexing the Pins Each pin is associated with a set of identifiers which include among others host name, protocol (TLS or DTLS) and port number. In other words, the pin for port TCP/443 may be different from that for DTLS or from the pin for port TCP/8443. These identifiers are expected to be relevant to characterize the identity of the server as well as the establishing TLS session. When a host name is used, it MUST be the value sent inside the Server Name Indication (SNI) extension. This definition is similar to a Web Origin [RFC6454], but does not assume the existence of a URL. The purpose of ticket pinning is to pin the server identity. As a result, any information orthogonal to the server's identity MUST NOT be considered in indexing. More particularly, IP addresses are ephemeral and forbidden in SNI and therefore pins MUST NOT be associated with IP addresses. Similarly, CA names or public keys associated with server MUST NOT be used for indexing as they may change over time. 3. Message Definitions This section defines the format of the PinningTicket extension. We follow the message notation of [RFC8446]. opaque pinning_ticket<0..2^16-1>; opaque pinning_proof<0..2^8-1>; struct { select (Role) { case client: pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection case server: pinning_proof proof<0..2^8-1>; //no proof on 1st connection pinning_ticket ticket<0..2^16-1>; //omitted on ramp down uint32 lifetime; } } PinningTicketExtension; Sheffer & Migault Expires December 28, 2019 [Page 10] Internet-Draft Pinning Tickets June 2019 ticket a pinning ticket sent by the client or returned by the server. The ticket is opaque to the client. The extension MUST contain exactly 0 or 1 tickets. proof a demonstration by the server that it understands the received ticket and therefore that it is in possession of the secret that was used to generate it originally. The extension MUST contain exactly 0 or 1 proofs. lifetime the duration (in seconds) that the server commits to accept offered tickets in the future. 4. Cryptographic Operations This section provides details on the cryptographic operations performed by the protocol peers. 4.1. Pinning Secret The pinning secret is generated locally by the client and the server which means they must use the same inputs to generate it. This value must be generated before the ServerHello message is sent, as the server includes the corresponding pinning ticket in the same flight as the ServerHello message. In addition, the pinning secret must be unpredictable to any party other than the client and the server. The pinning secret is derived using the Derive-Secret function provided by TLS 1.3, described in Section "Key Schedule" of [RFC8446]. pinning secret = Derive-Secret(Handshake Secret, "pinning secret", ClientHello...ServerHello) 4.2. Pinning Ticket The pinning ticket contains the pinning secret. The pinning ticket is provided by the client to the server which decrypts it in order to extract the pinning secret and responds with a pinning proof. As a result, the characteristics of the pinning ticket are: - Pinning tickets MUST be encrypted and integrity-protected using strong cryptographic algorithms. - Pinning tickets MUST be protected with a long-term pinning protection key. - Pinning tickets MUST include a pinning protection key ID or serial number as to enable the pinning protection key to be refreshed. Sheffer & Migault Expires December 28, 2019 [Page 11] Internet-Draft Pinning Tickets June 2019 - The pinning ticket MAY include other information, in addition to the pinning secret. When additional information is included, a careful review needs to be performed to evaluate its impact on privacy. The pinning ticket's format is not specified by this document, but we RECOMMEND a format similar to the one proposed by [RFC5077]. 4.3. Pinning Protection Key The pinning protection key is only used by the server and so remains server implementation specific. [RFC5077] recommends the use of two keys, but when using AEAD algorithms only a single key is required. When a single server terminates TLS for multiple virtual servers using the Server Name Indication (SNI) mechanism, we strongly RECOMMEND to use a separate protection key for each one of them, in order to allow migrating virtual servers between different servers while keeping pinning active. As noted in Section 5.1, if the server is actually a cluster of machines, the protection key MUST be synchronized between all the nodes that accept TLS connections to the same server name. When [RFC5077] is deployed, an easy way to do it is to derive the protection key from the session-ticket protection key, which is already synchronized. For example: pinning_protection_key = HKDF-Expand(resumption_protection_key, "pinning protection", L) Where resumption_protection_key is the ticket protection key defined in [RFC5077]. Both resumption_protection_key and pinning_protection_key are only used by the server. The above solution attempts to minimize code changes related to management of the resumption_protection_key. The drawback is that this key would be used both to directly encrypt session tickets and to derive the pinning_protection_key, and such mixed usage of a single key is not in line with cryptographic best practices. Where possible, we RECOMMEND to have the resumption_protection_key and pinning_protection_key as two, unrelated keys that are separately shared among the relevant servers. 4.4. Pinning Proof The pinning proof is sent by the server to demonstrate that it has been able to decrypt the pinning ticket and retrieve the pinning secret. The proof must be unpredictable and must not be replayed. Sheffer & Migault Expires December 28, 2019 [Page 12] Internet-Draft Pinning Tickets June 2019 Similarly to the pinning ticket, the pinning proof is sent by the server in the ServerHello message. In addition, it must not be possible for a MITM server with a fake certificate to obtain a pinning proof from the original server. In order to address these requirements, the pinning proof is bound to the TLS session as well as the public key of the server: pinning_proof_secret=Derive-Secret(Handshake Secret, "pinning proof 1", ClientHello...ServerHello) proof = HMAC(original_pinning_secret, "pinning proof 2" + pinning_proof_secret + Hash(server_public_key)) where HMAC [RFC2104] uses the Hash algorithm that was negotiated in the handshake, and the same hash is also used over the server's public key. The original_pinning_secret value refers to the secret value extracted from the ticket sent by the client, to distinguish it from a new pinning secret value that is possibly computed in the current exchange. The server_public_key value is the DER representation of the public key, specifically the SubjectPublicKeyInfo structure as-is. 5. Operational Considerations The main motivation behind the current protocol is to enable identity pinning without the need for manual operations. Manual operations are susceptible to human error and in the case of public key pinning, can easily result in "server bricking": the server becoming inaccessible to some or all of its users. To achieve this goal operations described in identity pinning are only performed within the current TLS session, and there is no dependence on any TLS configuration parameters such as CA identity or public keys. As a result, configuration changes are unlikely to lead to desynchronized state between the client and the server. 5.1. Protection Key Synchronization The only operational requirement when deploying this protocol is that if the server is part of a cluster, protection keys (the keys used to encrypt tickets) MUST be synchronized between all cluster members. The protocol is designed so that if resumption ticket protection keys [RFC5077] are already synchronized between cluster members, nothing more needs to be done. Moreover, synchronization does not need to be instantaneous, e.g. protection keys can be distributed a few minutes or hours in advance of their rollover. In such scenarios, each cluster member MUST be Sheffer & Migault Expires December 28, 2019 [Page 13] Internet-Draft Pinning Tickets June 2019 able to accept tickets protected with a new version of the protection key, even while it is still using an old version to generate keys. This ensures that a client that receives a "new" ticket does not next hit a cluster member that still rejects this ticket. Misconfiguration can lead to the server's clock being off by a large amount of time. Consider a case where a server's clock is misconfigured, for example, to be 1 year in the future, and the system is allowed to delete expired keys automatically. The server will then delete many outstanding keys because they are now long expired and will end up rejecting valid tickets that are stored by clients. Such a scenario could make the server inaccessible to a large number of clients. The decision to delete a key should at least consider the largest value of the ticket lifetime as well as the expected time desynchronisation between the servers of the cluster and the time difference for distributing the new key among the different servers in the cluster. 5.2. Ticket Lifetime The lifetime of the ticket is a commitment by the server to retain the ticket's corresponding protection key for this duration, so that the server can prove to the client that it knows the secret embedded in the ticket. For production systems, the lifetime SHOULD be between 7 and 31 days. 5.3. Certificate Renewal The protocol ensures that the client will continue speaking to the correct server even when the server's certificate is renewed. In this sense, pinning is not associated with certificates which is the reason we designate the protocol described in this document as "server identity pinning". Note that this property is not impacted by the use of the server's public key in the pinning proof, because the scope of the public key used is only the current TLS session. 5.4. Certificate Revocation The protocol is orthogonal to certificate validation in the sense that, if the server's certificate has been revoked or is invalid for some other reason, the client MUST refuse to connect to it regardless of any ticket-related behavior. Sheffer & Migault Expires December 28, 2019 [Page 14] Internet-Draft Pinning Tickets June 2019 5.5. Disabling Pinning A server implementing this protocol MUST have a "ramp down" mode of operation where: - The server continues to accept valid pinning tickets and responds correctly with a proof. - The server does not send back a new pinning ticket. After a while no clients will hold valid tickets any more and the feature may be disabled. Note that clients that do not receive a new pinning ticket do not necessarily need to remove the original ticket. Instead, the client may keep on using the ticket until its lifetime expires. However, as detailed in section Section 7.7, re-use of a ticket by the client may result in privacy concerns as the ticket value may be used to correlate TLS sessions. Issuing a new pinning ticket with a shorter lifetime would only delay the ramp down process, as the shorter lifetime can only affect clients that actually initiated a new connection. Other clients would still see the original lifetime for their pinning tickets. 5.6. Server Compromise If a server compromise is detected, the pinning protection key MUST be rotated immediately, but the server MUST still accept valid tickets that use the old, compromised key. Clients that still hold old pinning tickets will remain vulnerable to MITM attacks, but those that connect to the correct server will immediately receive new tickets protected with the newly generated pinning protection key. The same procedure applies if the pinning protection key is compromised directly, e.g. if a backup copy is inadvertently made public. 5.7. Disaster Recovery All web servers in production need to be backed up, so that they can be recovered if a disaster (including a malicious activity) ever wipes them out. Backup often includes the certificate and its private key, which must be backed up securely. The pinning secret, including earlier versions that are still being accepted, must be backed up regularly. However since it is only used as an authentication second factor, it does not require the same level of confidentiality as the server's private key. Sheffer & Migault Expires December 28, 2019 [Page 15] Internet-Draft Pinning Tickets June 2019 Readers should note that [RFC5077] session resumption keys are more security sensitive, and should normally not be backed up but rather treated as ephemeral keys. Even when servers derive pinning secrets from resumption keys (Section 4.1), they MUST NOT back up resumption keys. 6. Implementation Status Note to RFC Editor: please remove this section before publication, including the reference to [RFC7942]. 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 RFC 7942, "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". 6.1. Mint Fork 6.1.1. Overview A fork of the Mint TLS 1.3 implementation, developed by Yaron Sheffer and available at https://github.com/yaronf/mint. 6.1.2. Description This is a fork of the TLS 1.3 implementation, and includes client and server code. In addition to the actual protocol, several utilities are provided allowing to manage pinning protection keys on the server side, and pinning tickets on the client side. Sheffer & Migault Expires December 28, 2019 [Page 16] Internet-Draft Pinning Tickets June 2019 6.1.3. Level of Maturity This is a prototype. 6.1.4. Coverage The entire protocol is implemented. 6.1.5. Version Compatibility The implementation is compatible with draft-sheffer-tls-pinning- ticket-02. 6.1.6. Licensing Mint itself and this fork are available under an MIT license. 6.1.7. Contact Information See author details below. 7. Security Considerations This section reviews several security aspects related to the proposed extension. 7.1. Trust on First Use (TOFU) and MITM Attacks This protocol is a "trust on first use" protocol. If a client initially connects to the "right" server, it will be protected against MITM attackers for the lifetime of each received ticket. If it connects regularly (depending of course on the server-selected lifetime), it will stay constantly protected against fake certificates. However if it initially connects to an attacker, subsequent connections to the "right" server will fail. Server operators might want to advise clients on how to remove corrupted pins, once such large scale attacks are detected and remediated. The protocol is designed so that it is not vulnerable to an active MITM attacker who has real-time access to the original server. The pinning proof includes a hash of the server's public key, to ensure the client that the proof was in fact generated by the server with which it is initiating the connection. Sheffer & Migault Expires December 28, 2019 [Page 17] Internet-Draft Pinning Tickets June 2019 7.2. Pervasive Monitoring Some organizations, and even some countries perform pervasive monitoring on their constituents [RFC7258]. This often takes the form of always-active SSL proxies. Because of the TOFU property, this protocol does not provide any security in such cases. Pervasive monitoring may also result in privacy concerns detailed in section Section 7.7. 7.3. Server-Side Error Detection Uniquely, this protocol allows the server to detect clients that present incorrect tickets and therefore can be assumed to be victims of a MITM attack. Server operators can use such cases as indications of ongoing attacks, similarly to fake certificate attacks that took place in a few countries in the past. 7.4. Client Policy and SSL Proxies Like it or not, some clients are normally deployed behind an SSL proxy. Similarly to [RFC7469], it is acceptable to allow pinning to be disabled for some hosts according to local policy. For example, a User Agent (UA) MAY disable pinning for hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform). Moreover, a client MAY accept an empty PinningTicket extension from such hosts as a valid response. 7.5. Client-Side Error Behavior When a client receives a malformed or empty PinningTicket extension from a pinned server, it MUST abort the handshake and MUST NOT retry with no PinningTicket in the request. Doing otherwise would expose the client to trivial fallback attacks, similar to those described in [RFC7507]. This rule can however have negative affects on clients that move from behind SSL proxies into the open Internet and vice versa, if the advice in Section 7.4 is not followed. Therefore, we RECOMMEND that browser and library vendors provide a documented way to remove stored pins. 7.6. Stolen and Forged Tickets Stealing pinning tickets even in conjunction with other pinning parameters, such as the associated pinning secret, provides no benefit to the attacker since pinning tickets are used to secure the Sheffer & Migault Expires December 28, 2019 [Page 18] Internet-Draft Pinning Tickets June 2019 client rather than the server. Similarly, it is useless to forge a ticket for a particular server. 7.7. Client Privacy This protocol is designed so that an external attacker cannot correlate between different requests of a single client, provided the client requests and receives a fresh ticket upon each connection. This may be of concern particularly during ramp-down, if the server does not provide any new ticket and the client re-uses the same ticket. To reduce or avoid such privacy concerns, it is RECOMMENDED for the server to issue a fresh ticket with a reduced life time. This would at least reduce the time period under which TLS session of the client are correlated. The server MAY also issue tickets with a zero second lifetime until it is confident all tickets are expired. On the other hand, the server to which the client is connecting can easily track the client. This may be an issue when the client expects to connect to the server (e.g., a mail server) with multiple identities. Implementations SHOULD allow the user to opt out of pinning, either in general or for particular servers. This document does not define the exact content of tickets. Including client-specific information in tickets would raise privacy concerns and is NOT RECOMMENDED. 7.8. Ticket Protection Key Management While the ticket format is not mandated by this document, we RECOMMEND using authenticated encryption to protect it. Some of the algorithms commonly used for authenticated encryption, e.g. GCM, are highly vulnerable to nonce reuse, and this problem is magnified in a cluster setting. Therefore implementations that choose AES-GCM or any AEAD equivalent MUST adopt one of these three alternatives: - Partition the nonce namespace between cluster members and use monotonic counters on each member, e.g. by setting the nonce to the concatenation of the cluster member ID and an incremental counter. - Generate random nonces but avoid the so-called birthday bound, i.e. never generate more than the maximum allowed number of encrypted tickets (2**64 for AES-128-GCM) for the same ticket pinning protection Key. - An alternative design which has been attributed to Karthik Bhargavan is as follows. Start with a 128-bit master key "K_master" and then for each encryption, generate a 256-bit random Sheffer & Migault Expires December 28, 2019 [Page 19] Internet-Draft Pinning Tickets June 2019 nonce and compute: K = HKDF(K_master, Nonce || "key"), then N = HKDF(K_master, Nonce || "nonce"). Use these values to encrypt the ticket, AES-GCM(K, N, data). This nonce should then be stored and transmitted with the ticket. 8. IANA Considerations IANA is requested to allocate a TicketPinning extension value in the TLS ExtensionType Registry. [RFC8447] defines the procedure and requirements and the necessary information for the IANA to update the "TLS ExtensionType Values" registry [TLS-EXT]. According to [RFC8447] the update of the "TLS ExtensionType Values" registry is "Specification Required" [RFC8126] which is fulfilled by the current document, when it is published as an RFC. The TicketPinning Extension is not limited to Private use and as such the TicketPinning Extension Value is expected to have its first byte in the range 0-254. The TicketPinning Extension Name is expected to be ticket_pinning. The TicketPinning Extension Recommended value should be set to "No" with the publication of the current document as "Experimental". The TicketPinning Extension TLS.13 column should be set to CH, EE to indicate that the TicketPinning Extension is present in ClientHello and EncryptedExtensions messages. 9. Acknowledgements The original idea behind this proposal was published in [Oreo] by Moti Yung, Benny Pinkas and Omer Berkman. The current protocol is but a distant relative of the original Oreo protocol, and any errors are the responsibility of the authors of this document alone. We would like to thank Adrian Farrel, Dave Garrett, Daniel Kahn Gillmor, Alexey Melnikov, Yoav Nir, Eric Rescorla, Benjamin Kaduk and Rich Salz for their comments on this document. Special thanks to Craig Francis for contributing the HPKP deployment script, and to Ralph Holz for several fruitful discussions. Sheffer & Migault Expires December 28, 2019 [Page 20] Internet-Draft Pinning Tickets June 2019 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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, . 10.2. Informative References [I-D.perrin-tls-tack] Marlinspike, M., "Trust Assertions for Certificate Keys", draft-perrin-tls-tack-02 (work in progress), January 2013. [Netcraft] Mutton, P., "HTTP Public Key Pinning: You're doing it wrong!", March 2016, . [Oreo] Berkman, O., Pinkas, B., and M. Yung, "Firm Grip Handshakes: A Tool for Bidirectional Vouching", Cryptology and Network Security, pp. 142-157 , 2012. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . Sheffer & Migault Expires December 28, 2019 [Page 21] Internet-Draft Pinning Tickets June 2019 [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, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 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, . [TLS-EXT] IANA, ., "TLS Extension Type Value", 2018, . Sheffer & Migault Expires December 28, 2019 [Page 22] Internet-Draft Pinning Tickets June 2019 Appendix A. Previous Work The global PKI system relies on the trust of a CA issuing certificates. As a result, a corrupted trusted CA may issue a certificate for any organization without the organization's approval (a misissued or "fake" certificate), and use the certificate to impersonate the organization. There are many attempts to resolve these weaknesses, including Certificate Transparency (CT) [RFC6962], HTTP Public Key Pinning (HPKP) [RFC7469], and TACK [I-D.perrin-tls-tack]. CT requires cooperation of a large portion of the hundreds of extant certificate authorities (CAs) before it can be used "for real", in enforcing mode. It is noted that the relevant industry forum (CA/ Browser Forum) is indeed pushing for such extensive adoption. However the public nature of CT often makes it inappropriate for enterprise use, because many organizations are not willing to expose their internal infrastructure publicly. TACK has some similarities to the current proposal, but work on it seems to have stalled. Appendix A.2 compares our proposal to TACK. HPKP is an IETF standard, but so far has proven hard to deploy. HPKP pins (fixes) a public key, one of the public keys listed in the certificate chain. As a result, HPKP needs to be coordinated with the certificate management process. Certificate management impacts HPKP and thus increases the probability of HPKP failures. This risk is made even higher given the fact that, even though work has been done at the ACME WG to automate certificate management, in many or even most cases, certificates are still managed manually. As a result, HPKP cannot be completely automated resulting in error-prone manual configuration. Such errors could prevent the web server from being accessed by some clients. In addition, HPKP uses a HTTP header which makes this solution HTTPS specific and not generic to TLS. On the other hand, the current document provides a solution that is independent of the server's certificate management and that can be entirely and easily automated. Appendix A.1 compares HPKP to the current document in more detail. The ticket pinning proposal augments these mechanisms with a much easier to implement and deploy solution for server identity pinning, by reusing some of the ideas behind TLS session resumption. This section compares ticket pinning to two earlier proposals, HPKP and TACK. Sheffer & Migault Expires December 28, 2019 [Page 23] Internet-Draft Pinning Tickets June 2019 A.1. Comparison: HPKP The current IETF standard for pinning the identity of web servers is the Public Key Pinning Extension for HTTP, or HPKP [RFC7469]. The main differences between HPKP and the current document are the following: - HPKP limits its scope to HTTPS, while the current document considers all application above TLS. - HPKP pins the public key of the server (or another public key along the certificate chain) and as such is highly dependent on the management of certificates. Such dependency increases the potential error surface, especially as certificate management is not yet largely automated. The current proposal, on the other hand, is independent of certificate management. - HPKP pins public keys which are public and used for the standard TLS authentication. Identity pinning relies on the ownership of the pinning key which is not disclosed to the public and not involved in the standard TLS authentication. As a result, identity pinning is a completely independent second factor authentication mechanism. - HPKP relies on a backup key to recover the misissuance of a key. We believe such backup mechanisms add excessive complexity and cost. Reliability of the current mechanism is primarily based on its being highly automated. - HPKP relies on the client to report errors to the report-uri. The current document does not need any out-of band mechanism, and the server is informed automatically. This provides an easier and more reliable health monitoring. On the other hand, HPKP shares the following aspects with identity pinning: - Both mechanisms provide hard failure. With HPKP only the client is aware of the failure, while with the current proposal both client and server are informed of the failure. This provides room for further mechanisms to automatically recover such failures. - Both mechanisms are subject to a server compromise in which users are provided with an invalid ticket (e.g. a random one) or HTTP Header, with a very long lifetime. For identity pinning, this lifetime SHOULD NOT be longer than 31 days. In both cases, clients will not be able to reconnect the server during this Sheffer & Migault Expires December 28, 2019 [Page 24] Internet-Draft Pinning Tickets June 2019 lifetime. With the current proposal, an attacker needs to compromise the TLS layer, while with HPKP, the attacker needs to compromise the HTTP server. Arguably, the TLS-level compromise is typically more difficult for the attacker. Unfortunately HPKP has not seen wide deployment yet. As of March 2016, the number of servers using HPKP was less than 3000 [Netcraft]. This may simply be due to inertia, but we believe the main reason is the interactions between HPKP and manual certificate management which is needed to implement HPKP for enterprise servers. The penalty for making mistakes (e.g. being too early or too late to deploy new pins) is having the server become unusable for some of the clients. To demonstrate this point, we present a list of the steps involved in deploying HPKP on a security-sensitive Web server. 1. Generate two public/private key-pairs on a computer that is not the Live server. The second one is the "backup1" key-pair. "openssl genrsa -out "example.com.key" 2048;" "openssl genrsa -out "example.com.backup1.key" 2048;" 2. Generate hashes for both of the public keys. These will be used in the HPKP header: "openssl rsa -in "example.com.key" -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64" "openssl rsa -in "example.com.backup1.key" -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64" 3. Generate a single CSR (Certificate Signing Request) for the first key-pair, where you include the domain name in the CN (Common Name) field: "openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Company/ CN=example.com" -key "example.com.key" -out "example.com.csr";" 4. Send this CSR to the CA (Certificate Authority), and go though the dance to prove you own the domain. The CA will give you back a single certificate that will typically expire within a year or two. 5. On the Live server, upload and setup the first key-pair (and its certificate). At this point you can add the "Public-Key-Pins" header, using the two hashes you created in step 2. Sheffer & Migault Expires December 28, 2019 [Page 25] Internet-Draft Pinning Tickets June 2019 Note that only the first key-pair has been uploaded to the server so far. 6. Store the second (backup1) key-pair somewhere safe, probably somewhere encrypted like a password manager. It won't expire, as it's just a key-pair, it just needs to be ready for when you need to get your next certificate. 7. Time passes... probably just under a year (if waiting for a certificate to expire), or maybe sooner if you find that your server has been compromised and you need to replace the key-pair and certificate. 8. Create a new CSR (Certificate Signing Request) using the "backup1" key-pair, and get a new certificate from your CA. 9. Generate a new backup key-pair (backup2), get its hash, and store it in a safe place (again, not on the Live server). 10. Replace your old certificate and old key-pair, and update the "Public-Key-Pins" header to remove the old hash, and add the new "backup2" key-pair. Note that in the above steps, both the certificate issuance as well as the storage of the backup key pair involve manual steps. Even with an automated CA that runs the ACME protocol, key backup would be a challenge to automate. A.2. Comparison: TACK Compared with HPKP, TACK [I-D.perrin-tls-tack] is a lot more similar to the current document. It can even be argued that this document is a symmetric-cryptography variant of TACK. That said, there are still a few significant differences: - Probably the most important difference is that with TACK, validation of the server certificate is no longer required, and in fact TACK specifies it as a "MAY" requirement (Sec. 5.3). With ticket pinning, certificate validation by the client remains a MUST requirement, and the ticket acts only as a second factor. If the pinning secret is compromised, the server's security is not immediately at risk. - Both TACK and the current document are mostly orthogonal to the server certificate as far as their life cycle, and so both can be deployed with no manual steps. Sheffer & Migault Expires December 28, 2019 [Page 26] Internet-Draft Pinning Tickets June 2019 - TACK uses ECDSA to sign the server's public key. This allows cooperating clients to share server assertions between themselves. This is an optional TACK feature, and one that cannot be done with pinning tickets. - TACK allows multiple servers to share its public keys. Such sharing is disallowed by the current document. - TACK does not allow the server to track a particular client, and so has better privacy properties than the current document. - TACK has an interesting way to determine the pin's lifetime, setting it to the time period since the pin was first observed, with a hard upper bound of 30 days. The current document makes the lifetime explicit, which may be more flexible to deploy. For example, Web sites which are only visited rarely by users may opt for a longer period than other sites that expect users to visit on a daily basis. Appendix B. Document History B.1. draft-sheffer-tls-pinning-ticket-12 - IETF-Conflict Review comments. - IANA: removed request for a specific extension value. B.2. draft-sheffer-tls-pinning-ticket-11 - Comments by Ben Kaduk. Specifically, changed the derivation of the pinning proof to make it more in line with the TLS 1.3 key schedule. B.3. draft-sheffer-tls-pinning-ticket-10 - ISE comments by Adrian Farrel, the ISE. B.4. draft-sheffer-tls-pinning-ticket-09 - ISE comments by Yoav Nir. B.5. draft-sheffer-tls-pinning-ticket-08 - ISE comments by Rich Salz. Sheffer & Migault Expires December 28, 2019 [Page 27] Internet-Draft Pinning Tickets June 2019 B.6. draft-sheffer-tls-pinning-ticket-07 - Refer to published RFCs. B.7. draft-sheffer-tls-pinning-ticket-06 - IANA Considerations in preparation for Experimental publication. B.8. draft-sheffer-tls-pinning-ticket-05 - Multiple comments from Eric Rescorla. B.9. draft-sheffer-tls-pinning-ticket-04 - Editorial changes. - Two-phase rotation of protection key. B.10. draft-sheffer-tls-pinning-ticket-03 - Deleted redundant length fields in the extension's formal definition. - Modified cryptographic operations to align with the current state of TLS 1.3. - Numerous textual improvements. B.11. draft-sheffer-tls-pinning-ticket-02 - Added an Implementation Status section. - Added lengths into the extension structure. - Changed the computation of the pinning proof to be more robust. - Clarified requirements on the length of the pinning_secret. - Revamped the HPKP section to be more in line with current practices, and added recent statistics on HPKP deployment. B.12. draft-sheffer-tls-pinning-ticket-01 - Corrected the notation for variable-sized vectors. - Added a section on disaster recovery and backup. - Added a section on privacy. Sheffer & Migault Expires December 28, 2019 [Page 28] Internet-Draft Pinning Tickets June 2019 - Clarified the assumptions behind the HPKP procedure in the comparison section. - Added a definition of pin indexing (origin). - Adjusted to the latest TLS 1.3 notation. B.13. draft-sheffer-tls-pinning-ticket-00 Initial version. Authors' Addresses Yaron Sheffer Intuit EMail: yaronf.ietf@gmail.com Daniel Migault Ericsson EMail: daniel.migault@ericsson.com Sheffer & Migault Expires December 28, 2019 [Page 29] ./draft-trossen-sfc-name-based-sff-07.txt0000644000764400076440000021615213472614401017457 0ustar iustyiusty Network Working Group D. Trossen Internet-Draft InterDigital Europe, Ltd Intended status: Informational D. Purkayastha Expires: November 27, 2019 A. Rahman InterDigital Communications, LLC May 26, 2019 Name-Based Service Function Forwarder (nSFF) component within SFC framework draft-trossen-sfc-name-based-sff-07 Abstract Adoption of cloud and fog technology allows operators to deploy a single "Service Function" to multiple "Execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity etc. Under the current SFC framework, steering traffic dynamically to the different execution end points require a specific 're-chaining', i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify re-chaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path from the specific execution end points. This can be done by identifying the Service Functions using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions and protocol details in SFF (Service Function Forwarder) to handle name based relationships. This document presents InterDigital's approach to name-based service function chaining. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers. 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 https://datatracker.ietf.org/drafts/current/. Trossen, et al. Expires November 27, 2019 [Page 1] Internet-Draft Name Based SFF May 2019 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 27, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. Example use case: 5G control plane services . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Relevant part of SFC architecture . . . . . . . . . . . . 6 4.2. Challenges with current framework . . . . . . . . . . . . 7 5. Name based operation in SFF . . . . . . . . . . . . . . . . . 8 5.1. General Idea . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Name-Based Service Function Path (nSFP) . . . . . . . . . 8 5.3. Name Based Network Locator Map (nNLM) . . . . . . . . . . 10 5.4. Name-based Service Function Forwarder (nSFF) . . . . . . 12 5.5. High Level Architecture . . . . . . . . . . . . . . . . . 13 5.6. Operational Steps . . . . . . . . . . . . . . . . . . . . 14 6. nSFF Forwarding Operations . . . . . . . . . . . . . . . . . 16 6.1. nSFF Protocol Layers . . . . . . . . . . . . . . . . . . 16 6.2. nSFF Operations . . . . . . . . . . . . . . . . . . . . . 18 6.2.1. Forwarding between nSFFs and nSFF-NR . . . . . . . . 18 6.2.2. SF Registration . . . . . . . . . . . . . . . . . . . 21 6.2.3. Local SF Forwarding . . . . . . . . . . . . . . . . . 22 6.2.4. Handling of HTTP responses . . . . . . . . . . . . . 23 6.2.5. Remote SF Forwarding . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 Trossen, et al. Expires November 27, 2019 [Page 2] Internet-Draft Name Based SFF May 2019 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The requirements on today's networks are very diverse, enabling multiple use cases such as IoT, Content Distribution, Gaming and Network functions such as Cloud RAN and 5G control planes based on a service-based architecture. These services are deployed, provisioned and managed using Cloud based techniques as seen in the IT world. Virtualization of compute and storage resources is at the heart of providing (often web) services to end users with the ability to quickly provisioning such virtualized service endpoints through, e.g., container based techniques. This creates a dynamicity with the capability to dynamically compose new services from available services as well as move a service instance in response to user mobility or resource availability where desirable. When moving from a pure 'distant cloud' model to one of localized micro data centers with regional, metro or even street level, often called 'edge' data centers, such virtualized service instances can be instantiated in topologically different locations with the overall 'distant' data center now being transformed into a network of distributed ones. The reaction of content providers, like Facebook, Google, NetFlix and others, are not just relying on deploying content server at the ingress of the customer network. Instead the trend is towards deploying multiple POPs within the customer network, those POPs being connected through proprietary mechanisms [Schlinker2017] to push content. The Service Function Chaining (SFC) framework [RFC7665] allows network operators as well as service providers to compose new services by chaining individual "Service Functions (SFs)". Such chains are expressed through explicit relationships of functional components (the service functions), realized through their direct Layer 2 (e.g., MAC address) or Layer 3 (e.g., IP address) relationship as defined through next hop information that is being defined by the network operator, see Section 4 for more background on SFC. In a dynamic service environment of distributed data centers as the one outlined above, with the ability to create and recreate service endpoints frequently, the SFC framework requires to reconfigure the existing chain through information based on the new relationships, causing overhead in a number of components, specifically the orchestrator that initiates the initial service function chain and any possible reconfiguration. Trossen, et al. Expires November 27, 2019 [Page 3] Internet-Draft Name Based SFF May 2019 This document describes how such changes can be handled without involving the initiation of new and reconfigured SFCs by lifting the chaining relationship from Layer 2 and 3 information to that of service function 'names', such as names for instance being expressed as URIs. In order to transparently support such named relationships, we propose to embed the necessary functionality directly into the Service Function Forwarder (SFF), as described in [RFC7665]). With that, the SFF described in this document allows for keeping an existing SFC intact, as described by its service function path (SFP), while enabling the selection of an appropriate service function endpoint(s) during the traversal of packets through the SFC. This document is an Independent Submission to the RFC Editor. It is not an output of the IETF SFC WG. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Example use case: 5G control plane services We exemplify the need for chaining service functions at the level of a service name through a use case stemming from the current 3GPP Rel 16 work on Service Based Architecture (SBA) [_3GPP_SBA], [_3GPP_SBA_ENHANCEMENT]. In this work, mobile network control planes are proposed to be realized by replacing the traditional network function interfaces with a fully service-based one. HTTP was chosen as the application layer protocol for exchanging suitable service requests [_3GPP_SBA]. With this in mind, the exchange between, say the 3GPP (Rel. 15) defined Session Management Function (SMF) and the Access and Mobility management Function (AMF) in a 5G control plane is being described as a set of web service like requests which are in turn embedded into HTTP requests. Hence, interactions in a 5G control plane can be modelled based on service function chains where the relationship is between the specific (IP-based) service function endpoints that implement the necessary service endpoints in the SMF and AMF. The service functions are exposed through URIs with work ongoing to define the used naming conventions for such URIs. This move from a network function model (in pre-Rel 15 systems of 3GPP) to a service-based model is motivated through the proliferation of data center operations for mobile network control plane services. In other words, typical IT-based methods to service provisioning, in particular that of virtualization of entire compute resources, are envisioned to being used in future operations of mobile networks. Trossen, et al. Expires November 27, 2019 [Page 4] Internet-Draft Name Based SFF May 2019 Hence, operators of such future mobile networks desire to virtualize service function endpoints and direct (control plane) traffic to the most appropriate current service instance in the most appropriate (local) data centre, such data centre envisioned as being interconnected through a software-defined wide area network (SD-WAN). 'Appropriate' here can be defined by topological or geographical proximity of the service initiator to the service function endpoint. Alternatively, network or service instance compute load can be used to direct a request to a more appropriate (in this case less loaded) instance to reduce possible latency of the overall request. Such data center centric operation is extended with the trend towards regionalization of load through a 'regional office' approach, where micro data centers provide virtualizable resources that can be used in the service execution, creating a larger degree of freedom when choosing the 'most appropriate' service endpoint for a particular incoming service request. While the move to a service-based model aligns well with the framework of SFC, choosing the most appropriate service instance at runtime requires so-called 're-chaining' of the SFC since the relationships in said SFC are defined through Layer 2 or 3 identifiers, which in turn are likely to be different if the chosen service instances reside in different parts of the network (e.g., in a regional data center). Hence, when a traffic flow is forwarded over a service chain expressed as an SFC-compliant Service Function Path (SFP), packets in the traffic flow are processed by the various service function instances, with each service function instance applying a service function prior to forwarding the packets to the next network node. It is a Service layer concept and can possibly work over any Virtual network layer and an Underlay network, possibly IP or any Layer 2 technology. At the service layer, Service Functions are identified using a path identifier and an index. Eventually this index is translated to an IP address (or MAC address) of the host where the service function is running. Because of this, any change of service function instance is likely to require a change of the path information since either IP address (in the case of changing the execution from one data centre to another) or MAC address will change due to the newly selected service function instance. Returning to our 5G Control plane example, a user's connection request to access an application server in the internet may start with signaling in the Control Plane to setup user plane bearers. The connection request may flow through service functions over a service chain in the Control plane, as deployed by network operator. Typical SFs in a 5G control plane may include "RAN termination / processing", "Slice Selection Function", "AMF" and "SMF". A Network Slice is a Trossen, et al. Expires November 27, 2019 [Page 5] Internet-Draft Name Based SFF May 2019 complete logical network including Radio Access Network (RAN) and Core Network (CN). Distinct RAN and Core Network Slices may exist. A device may access multiple Network Slices simultaneously through a single RAN. The device may provide Network Slice Selection Assistance Information (NSSAI) parameters to the network to help it select a RAN and a Core network part of a slice instance. Part of the control plane, the Common Control Network Function (CCNF), the Network Slice Selection Function (NSSF) is in charge of selecting core Network Slice instances. The Classifier, as described in SFC architecture, may reside in the user terminal or at the eNB. These service functions can be configured to be part of a Service Function Chain. We can also say that some of the configurations of the Service Function Path may change at the execution time. For example, the SMF may be relocated as user moves and a new SMF may be included in the Service Function Path based on user location. The following diagram in Figure 1 shows the example Service Function Chain described here. +------+ +---------+ +-----+ +-----+ | User | | Slice | | | | | | App |-->| Control |->| AMF |-->| SMF |--> | Fn | | Function| | | | | +------+ +---------+ +-----+ +-----+ Figure 1: Mapping SFC onto Service Function Execution Points along a Service Function Path 4. Background [RFC7665] describes an architecture for the specification, creation and ongoing maintenance of Service Function Chains (SFCs). It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. In the following, we outline the parts of this SFC architecture relevant for our proposed extension, followed by the challenges with this current framework in the light of our example use case. 4.1. Relevant part of SFC architecture SFC Architecture, as defined in [RFC7665], describes architectural components such as Service Function (SF), Classifier, and Service Function Forwarder (SFF). It describes the Service Function Path (SFP) as the logical path of an SFC. Forwarding traffic along such SFP is the responsibility of the SFF. For this, the SFFs in a Trossen, et al. Expires November 27, 2019 [Page 6] Internet-Draft Name Based SFF May 2019 network maintain the requisite SFP forwarding information. Such SFP forwarding information is associated with a service path identifier (SPI) that is used to uniquely identify an SFP. The service forwarding state is represented by the Service Index (SI) and enables an SFF to identify which SFs of a given SFP should be applied, and in what order. The SFF also has information that allows it to forward packets to the next SFF after applying local service functions. The operational steps to forward traffic are then as follows: Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. After SF processing, the traffic is returned to the SFF, and, if needed, is forwarded to another SF associated with that SFF. If there is another non-local hop (i.e., to an SF with a different SFF) in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata. 4.2. Challenges with current framework As outlined in previous section, the Service Function Path defines an ordered sequence of specific Service Functions instances being used for the interaction between initiator and service functions along the SFP. These service functions are addressed by IP (or any L2/MAC) addresses and defined as next hop information in the network locator maps of traversing SFF nodes. As outlined in our use case, however, the service provider may want to provision SFC nodes based on dynamically spun up service function instances so that these (now virtualized) service functions can be reached in the SFC domain using the SFC underlay layer. Following the original model of SFC, any change in a specific execution point for a specific Service Function along the SFP will require a change of the SFP information (since the new service function execution point likely carries different IP or L2 address information) and possibly even the Next Hop information in SFFs along the SFP. In case the availability of new service function instances is rather dynamic (e.g., through the use of container-based virtualization techniques), the current model and realization of SFC could lead to reducing the flexibility of service providers and increasing the management complexity incurred by the frequent changes of (service) forwarding information in the respective SFF nodes. This is because any change of the SFP (and possibly next hop info) will need to go through suitable management cycles. Trossen, et al. Expires November 27, 2019 [Page 7] Internet-Draft Name Based SFF May 2019 To address these challenges through a suitable solution, we identify the following requirements: o Relations between Service Execution Points MUST be abstracted so that, from an SFP point of view, the Logical Path never changes. o Deriving the Service Execution Points from the abstract SFP SHOULD be fast and incur minimum delay. o Identification of the Service Execution Points SHOULD not use a combination of Layer 2 or Layer 3 mechanisms. The next section outlines a solution to address the issue, allowing for keeping SFC information (represented in its SFP) intact while addressing the desired flexibility of the service provider. 5. Name based operation in SFF 5.1. General Idea The general idea is two-pronged. Firstly, we elevate the definition of a Service Function Path onto the level of 'name-based interactions' rather than limiting SFPs to Layer 3 or Layer 2 information only. Secondly, we extend the operations of the SFF to allow for forwarding decisions that take into account such name-based interaction while remaining backward compatible to the current SFC architecture, as defined in [RFC7665]. In the following sections, we outline these two components of our solution. If the next hop information in the Network Locator Map (NLM) is described using L2/L3 identifier, the name-based SFF (nSFF) may operate as described for [traditional] SFF, as defined in [RFC7665]. On the other hand, if the next hop information in the NLM is described as a name, then the nSFF operates as described in the following sections. In the following sections, we outline the two components of our solution. 5.2. Name-Based Service Function Path (nSFP) The existing SFC framework is defined in [RFC7665]. Section 4 outlines that the SFP information is representing path information based on Layer 2 or 3 information, i.e., MAC or IP addresses, causing the aforementioned frequent adaptations in cases of execution point changes. Instead, we introduce the notion of a "name-based service function path (nSFP)". Trossen, et al. Expires November 27, 2019 [Page 8] Internet-Draft Name Based SFF May 2019 In today's networking terms, any identifier can be treated as a name but we will illustrate the realization of a "Name based SFP" through extended SFF operations (see Section 6) based on URIs as names and HTTP as the protocol of exchanging information. Here, URIs are being used to name for a Service Function along the nSFP. It is to be noted that the Name based SFP approach is not restricted to HTTP (as the protocol) and URIs (as next hop identifier within the SFP). Other identifiers such as an IP address itself can also be used and are interpreted as a 'name' in the nSFP. IP addresses as well as fully qualified domain names forming complex URIs (uniform resource identifiers), such as www.example.com/service_name1, are all captured by the notion of 'name' in this document. Generally, nSFPs are defined as an ordered sequence of the "name" of Service Functions (SF) and a typical name-based Service Function Path may look like: 192.0.x.x -> www.example.com -> www.example2.com/ service1 -> www.example2.com/service2. Our use case in Section 3 can then be represented as an ordered named sequence. An example for a session initiation that involves an authentication procedure, this could look like 192.0.x.x -> smf.example.org/session_initiate -> amf.example.org/auth -> smf.example.org/session_complete -> 192.0.x.x. [Note that this example is only a conceptual one, since the exact nature of any future SBA-based exchange of 5G control plane functions is yet to be defined by standardization bodies such as 3GPP]. In accordance with our use case in Section 3, any of these named services can potentially be realized through more than one replicated SF instances. This leads to make dynamic decision on where to send packets along the SAME service function path information, being provided during the execution of the SFC. Through elevating the SFP onto the notion of name-based interactions, the SFP will remain the same even if those specific execution points change for a specific service interaction. The following diagram in Figure 2, describes this name-based SFP concept and the resulting mapping of those named interactions onto (possibly) replicated instances. Trossen, et al. Expires November 27, 2019 [Page 9] Internet-Draft Name Based SFF May 2019 +---------------------------------------------------------------+ |SERVICE LAYER | | 192.0.x.x --> www.example.com --> www.example2.com --> | | || || | +----------------------||--------------||-----------------------+ || || || || +----------------------||--------------||-----------------------+ | Underlay network \/ \/ | | +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ | | Compute and Compute and | | storage nodes storage nodes | +---------------------------------------------------------------+ Figure 2: Mapping SFC onto Service Function Execution Points along a Service Function Path based on Virtualized Service Function Instance 5.3. Name Based Network Locator Map (nNLM) In order to forward a packet within a name-based SFP, we need to extend the network locator map as defined in [RFC8300] with the ability to consider name relations based on URIs as well as high- level transport protocols such as HTTP for means of SFC packet forwarding. Another example for SFC packet forwarding could be that of CoAP. The extended Network Locator Map or name-based Network Locator Map (nNLM) is shown in Figure 3 as an example for www.example.com being part of the nSFP. Such extended nNLM is stored at each SFF throughout the SFC domain with suitable information populated to the nNLM during the configuration phase. Trossen, et al. Expires November 27, 2019 [Page 10] Internet-Draft Name Based SFF May 2019 +------+------+---------------------+-----------------------------+ | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| +------+------+---------------------+-----------------------------+ | 10 | 255 | 192.0.2.1 | VXLAN-gpe | | | | | | | 10 | 254 | 198.51.100.10 | GRE | | | | | | | 10 | 253 | www.example.com | HTTP | ----------------------------------------------------------------- | | | | | | 40 | 251 | 198.51.100.15 | GRE | | | | | | | 50 | 200 | 01:23:45:67:89:ab | Ethernet | | | | | | | 15 | 212 | Null (end of path) | None | +------+------+---------------------+-----------------------------+ Figure 3: Name-based Network Locator Map Alternatively, the extended network locator map may be defined with implicit name information rather than explicit URIs as in Figure 3. In the example of Figure 4 below, the next hop is represented as a generic HTTP service without a specific URI being identified in the extended network locator map. In this scenario, the SFF forwards the packet based on parsing the HTTP request in order to identify the host name or URI. It retrieves the URI and may apply policy information to determine the destination host/service. Trossen, et al. Expires November 27, 2019 [Page 11] Internet-Draft Name Based SFF May 2019 +------+------+---------------------+-----------------------------+ | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| +------+------+---------------------+-----------------------------+ | 10 | 255 | 192.0.2.1 | VXLAN-gpe | | | | | | | 10 | 254 | 198.51.100.10 | GRE | | | | | | | 10 | 253 | HTTP Service | HTTP | ----------------------------------------------------------------- | | | | | | 40 | 251 | 198.51.100.15 | GRE | | | | | | | 50 | 200 | 01:23:45:67:89:ab | Ethernet | | | | | | | 15 | 212 | Null (end of path) | None | +------+------+---------------------+-----------------------------+ Figure 4: Name-based Network Locator Map with Implicit Name information 5.4. Name-based Service Function Forwarder (nSFF) It is desirable to extend the SFF of the SFC underlay to handle nSFPs transparently and without the need to insert any service function into the nSFP. Such extended name-based SFF would then be responsible for forwarding a packet in the SFC domain as per the definition of the (extended) nSFP. In our exemplary realization for an extended SFF, the solution described in this document uses HTTP as the protocol of forwarding SFC packets to the next (name-based) hop in the nSFP. The URI in the HTTP transaction are the names in our nSFP information, which will be used for name based forwarding. Following our reasoning so far, HTTP requests (and more specifically the plain text encoded requests above) are the equivalent of Packets that enter the SFC domain. In the existing SFC framework, typically an IP payload is assumed to be a packet entering the SFC domain. This packet is forwarded to destination nodes using the L2 encapsulation. Any layer 2 network can be used as an underlay network. This notion is now extended to packets being possibly part of a entire higher layer application, such as HTTP requests. The handling of any intermediate layers such as TCP, IP is left to the realization of the (extended) SFF operations towards the next (named) hop. For this, we will first outline the general lifecycle of an SFC packet in the following subsection, followed by two examples for Trossen, et al. Expires November 27, 2019 [Page 12] Internet-Draft Name Based SFF May 2019 determining next hop information in Section 6.2.3, finalized by a layered view on the realization of the nSFF in Section 6.2.4. 5.5. High Level Architecture +----------+ | SF1 | +--------+ +------+ | instance |\ | NR | | SF2 | +----------+ \ +--------+ +------+ \ || || +------------+ \ +-------+ +---------+ +---------+ +-------+ | Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 | +------------+ +-------+ +---------+ +---------+ +-------+ || +----------+ | Boundary | | node | +----------+ Figure 5: High-level architecture The high-level architecture for name based operation shown in Figure 5 is very similar to the SFC architecture, as described in [RFC7665]. Two new functions are introduced, as shown in the above diagram, namely the name-based Service Function Forwarder (nSFF) and the Name Resolver (NR). nSFF (name-based Service Function Forwarder) is an extension of the existing SFF and is capable of processing SFC packets based on name- based network locator map (nNLM) information, determining the next SF, where the packet should be forwarded and the required transport encapsulation. Like standard SFF operation, it adds transport encapsulation to the SFC packet and forwards it. The Name Resolver is a new functional component, capable of identifying the execution end points, where a "named SF" is running, triggered by suitable resolution requests sent by the nSFF. Though this is similar to DNS function, but it is not same. It does not use DNS protocols or data records. A new procedure to determine the suitable routing/forwarding information towards the Nsff (name-based SFF) serving the next hop of the SFP (Service Function Path) is used. The details is described later. Trossen, et al. Expires November 27, 2019 [Page 13] Internet-Draft Name Based SFF May 2019 The other functional components such as Classifier, SF are same as described in SFC architecture, as defined in [RFC7665], while the Forwarders shown in the above diagram are traditional Layer 2 switches. 5.6. Operational Steps In the proposed solution, the operations are realized by the name- based SFF, called nSFF. We utilize the high-level architecture in Figure 5 to describe the traversal between two service function instances of an nSFP-based transactions in an example chain of : 192.0.x.x -> SF1 (www.example.com) -> SF2 (www.example2.com) -> SF3 -> ... Service Function 3 (SF3)is assumed to be a classical Service Function, hence existing SFC mechanisms can be used to reach it and will not be considered in this example. According to the SFC lifecycle, as defined in [RFC7665], based on our example chain above, the traffic originates from a Classifier or another SFF on the left. The traffic is processed by the incoming nSFF1 (on the left side) through the following steps. The traffic exits at nSFF2. o Step 1: At nSFF1 the following nNLM is assumed +------+------+---------------------+----------------------------+ | SPI | SI | Next Hop(s) | Transport Encapsulation(TE)| +------+------+---------------------+----------------------------+ | 10 | 255 | 192.0.2.1 | VXLAN-gpe | | | | | | | 10 | 254 | 198.51.100.10 | GRE | | | | | | | 10 | 253 | www.example.com | HTTP | | | | | | | 10 | 252 | www.example2.com | HTTP | | | | | | | 40 | 251 | 198.51.100.15 | GRE | | | | | | | 50 | 200 | 01:23:45:67:89:ab | Ethernet | | | | | | | 15 | 212 | Null (end of path) | None | +------+------+---------------------+----------------------------+ Figure 6: nNLM at nSFF1 o Step 2: nSFF1 removes the previous transport encapsulation (TE) for any traffic originating from another SFF or classifier Trossen, et al. Expires November 27, 2019 [Page 14] Internet-Draft Name Based SFF May 2019 (traffic from an SF instance does not carry any TE and is therefore directly processed at the nSFF). o Step 3: nSFF1 then processes the Network Service Header (NSH) information, as defined in [RFC8300], to identify the next SF at the nSFP level by mapping the NSH information to the appropriate entry in its nNLM (see Figure 6) based on the provided SPI/SI information in the NSH (see Section 4) in order to determine the name-based identifier of the next hop SF. With such nNLM in mind, the nSFF searches the map for SPI = 10 and SI = 253. It identifies the next hop as = www.example.com and HTTP as the protocol to be used. Given the next hop resides locally, the SFC packet is forwarded to the SF1 instance of www.example.com. Note that the next hop could also be identified from the provided HTTP request, if the next hop information was identified as a generic HTTP service, as defined in Section 5.3. o Step 4: The SF1 instance then processes the received SFC packet according to its service semantics and modifies the NSH by setting SPI = 10, SI = 252 for forwarding the packet along the SFP. It then forwards the SFC packet to its local nSFF, i.e., nSFF1. o Step 5: nSSF1 processes the NSH of the SFC packet again, now with the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It retrieves the next hop information from its nNLM in Figure 6, to be www.example2.com. Due to this SF not being locally available, the nSFF consults any locally available information regarding routing/forwarding towards a suitable nSFF that can serve this next hop. o Step 6: If such information exists, the Packet (plus the NSH information) is marked to be sent towards the nSFF serving the next hop based on such information in step 8. o Step 7: If such information does not exist, nSFF1 consults the Name Resolver (NR) to determine the suitable routing/forwarding information towards the identified nSFF serving the next hop of the SFP. For future SFC packets towards this next hop, such resolved information may be locally cached, avoiding to contact the Name Resolver for every SFC packet forwarding. The packet is now marked to be sent via the network in step 8. o Step 8: Utilizing the forwarding information determined in steps 6 or 7, nSFF1 adds the suitable transport encapsulation (TE) for the SFC packet before forwarding via the forwarders in the network towards the next nSFF22. Trossen, et al. Expires November 27, 2019 [Page 15] Internet-Draft Name Based SFF May 2019 o Step 9: When the Packet (+NSH+TE) arrives at the outgoing nSFF2, i.e., the nSFF serving the identified next hop of the SFP, removes the TE and processes the NSH to identify the next hop information. At nSFF2 the nNLM in Figure 7 is assumed. Based on this nNLM and NSH information where SPI = 10 and SI = 252, nSFF2 identifies the next SF as www.example2.com. +------+------+---------------------+-----------------------------+ | SPI | SI | Next Hop(s) | Transport Encapsulation (TE)| +------+------+---------------------+-----------------------------+ | | | | | | 10 | 252 | www.example2.com | HTTP | | | | | | | 40 | 251 | 198.51.100.15 | GRE | | | | | | | 50 | 200 | 01:23:45:67:89:ab | Ethernet | | | | | | | 15 | 212 | Null (end of path) | None | +------+------+---------------------+-----------------------------+ Figure 7: nNLM at SFF2 o Step 10: If the next hop is locally registered at the nSFF, it forwards the packet (+NSH) to the service function instance, using suitable IP/MAC methods for doing so. o Step 11: Otherwise, the outgoing nSFF adds a new TE information to the packet and forwards the packet (+NSH+TE) to the next SFF or boundary node, as shown in Figure 7. 6. nSFF Forwarding Operations This section outlines the realization of various nSFF forwarding operations in Section 5.6. Although the operations in Section 5 utilize the notion of name-based transactions in general, we exemplify the operations here in Section 5 specifically for HTTP- based transactions to ground our description into a specific protocol for such name-based transaction. We will refer to the various steps in each of the following sub-sections. 6.1. nSFF Protocol Layers Figure 8 shows the protocol layers, based on the high-level architecture in Figure 5. Trossen, et al. Expires November 27, 2019 [Page 16] Internet-Draft Name Based SFF May 2019 +-------+ +------+----+ +----+-----+ |App | | | | +--------+ | | | |HTTP | |--------> | | NR | |nSFF----->|-- |TCP |->| TCP |nSFF| +---/\---+ | | TCP | | |IP | | IP | | || | | IP | | +-------+ +------+----+ +---------+ +---------+ +----------+ | | L2 | | L2 |->|Forwarder|-->|Forwarder|-->| L2 | | +-------+ +------+----+ +---------+ +---------+ +----------+ | SF1 nSFF1 nSFF2 | +-------+ | | App |/ | | HTTP | -----------+ | TCP |\ | IP | | L2 | +-------+ SF2 Figure 8: Protocol layers The nSFF component here is shown as implementing a full incoming/ outgoing TCP/IP protocol stack towards the local service functions, while implementing the nSFF-NR and nSFF-nSFF protocols based on the descriptions in Section 6.2.3. For the exchange of HTTP-based service function transactions, the nSFF terminates incoming TCP connections from as well as outgoing TCP connections to local SFs, e.g., the TCP connection from SF1 terminates at nSFF1, and nSFF1 may store the connection information, such as socket information. It also maintains the mapping information for the HTTP request such as originating SF, destination SF and socket ID. nSFF1 may implement sending keep-alive messages over the socket to maintain the connection to SF1. Upon arrival of an HTTP request from SF1, nSFF1 extracts the HTTP Request and forwards it towards the next node, as outlined in Section 6.2. Any returning response is mapped onto the suitable open socket (for the original request) and send towards SF1. At the outgoing nSFF2, the destination SF2/Host is identified from the HTTP request message. If no TCP connection exists to the SF2, a new TCP connection is opened towards the destination SF2 and the HTTP request is sent over said TCP connection. The nSFF2 may also save the TCP connection information (such as socket information) and maintain the mapping of the socket information to the destination SF2. When an HTTP response is received from SF2 over the TCP connection, nSFF2 extracts the HTTP response, which is forwarded to Trossen, et al. Expires November 27, 2019 [Page 17] Internet-Draft Name Based SFF May 2019 the next node. nSFF2 may maintain the TCP connection through keep- alive messages. 6.2. nSFF Operations In this section, we present three key aspects of operations for the realization of the steps in Section 5.6, namely (i) the registration of local SFs (for step 3 in Section 5.6), (ii) the forwarding of SFC packets to and from local SFs (for step 3 and 4 as well as 10 in Section 5.6), (iii) the forwarding to a remote SF (for steps 5, 6 and 7 in Section 5.6) and to the NR as well as (iv) for the lookup of a suitable remote SF (for step 7 in Section 5.6). We also cover aspects of maintaining local lookup information for reducing lookup latency and others issues. 6.2.1. Forwarding between nSFFs and nSFF-NR Forwarding between the distributed nSFFs as well as between nSFF and NR is realized over the operator network via a path-based approach. A path-based approach utilizes path information provided by the source of the packet for forwarding said packet in the network. This is similar to segment routing albeit differing in the type of information provided for such source-based forwarding, as described in this section. In this approach, the forwarding information to a remote nSFF or the NR is defined as a 'path identifier' (pathID) of a defined length where said "Length" field indicates the full pathID length. The payload of the packet is defined by the various operations outlined in the following sub-sections, resulting in an overall packet being transmitted. With this, the generic forwarding format (GFF) for transport over the operator network is defined in Figure 9 with the length field defining the length of the pathID provided. +---------+-----------------+------------------------//------------+ | | | // | | Length | Path ID | Payload // | |(12 bit) | | // | +---------+-----------------+--------------------//----------------+ Figure 9: Generic Forwarding Format(GFF) o Length (12 bits): Defines the length of the pathID, i.e., up to 4096 bits Trossen, et al. Expires November 27, 2019 [Page 18] Internet-Draft Name Based SFF May 2019 o Path ID (): Variable length field, Bit field derived from IPv6 source and destination address For the pathID information, solutions such as those in [Reed2016] can be used. Here, the IPv6 source and destination addresses are used to realize a so-called path-based forwarding from the incoming to the outgoing nSFF or the NR. The forwarders in Figure 8 are realized via SDN (software-defined networking) switches, implementing an AND/CMP operation based on arbitrary wildcard matching over the IPv6 source and destination addresses, as outlined in [Reed2016]. Note that in the case of using IPv6 address information for path-based forwarding, the step of removing the transport encapsulation at the outgoing nSFF in Figure 8 is realized by utilizing the provided (existing) IP header (which was used for the purpose of the path-based forwarding in [Reed2016]) for the purpose of next hop forwarding, such as that of IP-based routing. As described in step 8 of the extended nSFF operations, this forwarding information is used as traffic encapsulation. With the forwarding information utilizing existing IPv6 information, IP headers are utilized as TE in this case. The next hop nSFF (see Figure 8) will restore the IP header of the packet with the relevant IP information used to forward the SFC packet to SF2 or it will create a suitable TE (Transport Encapsulation) information to forward the information to another nSFF or boundary node. Forwarding operations at the intermediary forwarders, i.e., SDN switches, examine the pathID information through a flow matching rule in which a specific switch-local output port is represented through the specific assigned bit position in the pathID. Upon a positive match in said rule, the packet is forwarded on said output port. Alternatively, the solution in [I-D.ietf-bier-multicast-http-response] suggests using a so-called BIER (Binary Indexed Explicit Replication) underlay. Here, the nSFF would be realized at the ingress to the BIER underlay, injecting the SFC packet (plus the NSH) header with BIER-based traffic encapsulation into the BIER underlay with each of the forwarders in Figure 8 being realized as a so-called Bit-Forwarding Router (BFR) [RFC8279]. 6.2.1.1. Transport Protocol Considerations Given that the proposed solution operates at the 'named transaction' level, particularly for HTTP transactions, forwarding between nSFFs and/or NR SHOULD be implemented via a transport protocol between nSFFs and/or NR in order to provide reliability, segmentation of large GFF packets, and flow control, with the GFF in Figure 9 being the basic forwarding format for this. Trossen, et al. Expires November 27, 2019 [Page 19] Internet-Draft Name Based SFF May 2019 Note that the nSFFs act as TCP proxies at ingress and egress, thus terminating incoming and initiating outgoing HTTP sessions to SFs. Figure 10 shows the packet format being used for the transmission of data, being adapted from the TCP header. Segmentation of large transactions into single transport protocol packets is realized through maintaining a 'Sequence number'. A 'Checksum' is calculated over a single data packet with the ones-complement TCP checksum calculation being used. The 'Window Size' field indicates the current maximum number of transport packets that are allowed in- flight by the egress nSFF. A data packet is sent without 'Data' field to indicate the end of (e.g., HTTP) transaction. Note that in order to support future named transactions based on other application protocols, such as CoAP, future versions of the transport protocol MAY introduce a 'Type' field that indicates the type of application protocol being used between SF and nSFF with 'Type' 0x01 proposed for HTTP. This is being left for future study. | 16 bit | 16 bit | +----------------------------------------------+ | Sequence number | +----------------------------------------------+ | Checksum | Window Size | +----------------------------------------------+ | ... | | Data (Optional) | +----------------------------------------------+ Figure 10: Transport protocol data packet format Given the path-based forwarding being used between nSFFs, the transport protocol between nSFFs utilizes negative acknowledgements from the egress nSFF towards the ingress nSFF. The transport protocol NACK packet carries the number of NACKs as well as the specific sequence numbers being indicated as lost in the 'NACK number' field(s), as shown in Figure 11. Trossen, et al. Expires November 27, 2019 [Page 20] Internet-Draft Name Based SFF May 2019 | 16 bit | 16 bit | +----------------------------------------------+ | Number of NACKs | + +----------------------------------------------+ | NACK number | +----------------------------------------------+ + ... NACK Number + +----------------------------------------------+ Figure 11: Transport protocol NACK packet format If the indicated number of NACKs in a received NACK packet in non- zero, the ingress nSFF will retransmit all sequence numbers signalled in the packet, while decreasing its congestion window size for future transmissions. If the indicated number of NACKs in a received NACK packet in zero, it will indicate the current congestion window as being successfully (and completely) being transmitted, increasing the congestion window size if smaller than the advertised 'Window Size' in Figure 10. The maintenance of the congestion window is subject to realization at the ingress nSFF and left for further study in nSFF realizations. 6.2.2. SF Registration As outlined in step 3 and 10 of Section 5.6, the nSFF needs to determine if the SF derived from the nNLM is locally reachable or whether the packet needs forwarding to a remote SFF. For this, a registration mechanism is provided for such local SF with the local nSFF. Two mechanisms can be used for this: 1. SF-initiated: We assume that the SF registers its FQDN to the local nSFF. As local mechanisms, we foresee that either a REST-based interface over the link-local link or configuration of the nSFF (through configuration files or management consoles) can be utilized. Such local registration event leads to the nSFF to register the given FQDN with the NR in combination with a system-unique nSFF identifier that is being used for path computation purposes in the NR. For the registration, the packet format in Figure 12 is used (inserted as the payload in the GFF of Figure 9 with the pathID towards the NR). Trossen, et al. Expires November 27, 2019 [Page 21] Internet-Draft Name Based SFF May 2019 +---------+-----------------+------------------+ | | | | | R/D | hash(FQDN) | nSFF_ID | | (1 bit) | (16 bit) | (8 bit) | +---------+-----------------+------------------+ Figure 12: Registration packet format o R/D: 1 bit length (0 for Register, 1 for De-register) o Hash(FQDN): 16 bit length for a hash over the FQDN of the SF o nSFF_ID: 8 bit for a system-unique identifier for the SFF related to the SF. We assume that the pathID towards the NR is known to the nSFF through configuration means. The NR maintains an internal table that associates the hash(FQDN), the nSFF_id information as well as the pathID information being used for communication between nSFF and NR. The nSFF locally maintains a mapping of registered FQDNs to IP addresses, for the latter using link-local private IP addresses. 2. Orchestration-based: in this mechanism, we assume that SFC to be orchestrated and the chain being provided through an orchestration template with FQDN information associated to a compute/storage resource that is being deployed by the orchestrator. We also assume knowledge at the orchestrator of the resource topology. Based on this, the orchestrator can now use the same REST-based protocol defined in option 1 to instruct the NR to register the given FQDN, as provided in the template, at the nSFF it has identified as being the locally servicing nSFF, provided as the system-unique nSFF identifier. 6.2.3. Local SF Forwarding There are two cases of local SF forwarding, namely the SF sending an SFC packet to the local nSFF (incoming requests) or the nSFF sending a packet to the SF (outgoing requests) as part of steps 3 and 10 in Section 5.6. In the following, we outline the operation for HTTP as an example named transaction. As shown in Figure 8, incoming HTTP requests from SFs are extracted by terminating the incoming TCP connection at their local nSFFs at the TCP level. The nSFF MUST maintain a mapping of open TCP sockets Trossen, et al. Expires November 27, 2019 [Page 22] Internet-Draft Name Based SFF May 2019 to HTTP requests (utilizing the URI of the request) for HTTP response association. For outgoing HTTP requests, the nSFF utilizes the maintained mapping of locally registered FQDNs to link-local IP addresses (see Section 6.2.2 option 1). Hence, upon receiving an SFC packet from a remote nSFF (in step 9 of Section 5.6), the nSFF determines the local existence of the SF through the registration mechanisms in Section 6.2.2. If said SF does exist locally, the HTTP (+NSH) packet, after stripping the TE, is sent to the local SF as step 10 in Section 5.6 via a TCP-level connection. Outgoing nSFF SHOULD keep TCP connections open to local SFs for improving SFC packet delivery in subsequent transactions. 6.2.4. Handling of HTTP responses When executing step 3 and 10 in Section 5.6, the SFC packet will be delivered to the locally registered next hop. As part of the HTTP protocol, responses to the HTTP request will need to be delivered on the return path to the originating nSFF (i.e., the previous hop). For this, the nSFF maintains a list of link-local connection information, e.g., sockets to the local SF and the pathID on which the request was received. Once receiving the response, nSFF consults the table to determine the pathID of the original request, forming a suitable GFF-based packet to be returned to the previous nSFF. When receiving the HTTP response at the previous nSFF, the nSFF consults the table of (locally) open sockets to determine the suitable local SF connection, mapping the received HTTP response URI to the stored request URI. Utilizing the found socket, the HTTP response is forwarded to the locally registered SF. 6.2.5. Remote SF Forwarding In steps 5, 6, 7, and 8 of Section 5.6, an SFC packet is forwarded to a remote nSFF based on the nNLM information for the next hop of the nSFP. Section 6.2.5.1 handles the case of suitable forwarding information to the remote nSFF not existing, therefore consulting the NR to obtain suitable information, while Section 6.2.5.2 describes the maintenance of forwarding information at the local nSFF, while Section 6.2.5.3 describes the update of stale forwarding information. Note that the forwarding described in Section 6.2.1 is used for the actual forwarding to the various nSFF components. Ultimately, Section 6.2.5.4 describes the forwarding to the remote nSFF via the forwarder network. Trossen, et al. Expires November 27, 2019 [Page 23] Internet-Draft Name Based SFF May 2019 6.2.5.1. Remote SF Discovery The nSFF communicates with the NR for two purposes, namely the registration and discovery of FQDNs. The packet format for the former was shown in Figure 10 in Section 6.2.2, while Figure 13 outlines the packet format for the discovery request. +--------------+-------------+ +--------+-----------------//--------+ | | | | | // | | hash(FQDN) | nSFF_ID | | Length | pathID // | | (16 bit) | (8 bit) | | (4 bit)| // | +--------------+-------------+ +--------+-------------//------------+ Path Request Path Response Figure 13: Discovery packet format For Path Request: o Hash(FQDN): 16 bit length for a hash over the FQDN of the SF o nSFF_ID: 8 bit for a system-unique identifier for the SFF related to the SF For Path Response: o Length (4 bits): Defines the length of the pathID o Path ID (): Variable length field, Bit field derived from IPv6 source and destination address A path to a specific FQDN is requested by sending a hash of the FQDN to the NR together with its nSFF_id, receiving as a response a pathID with a length identifier. The NR SHOULD maintain a table of discovery requests that map discovered (hash of) FQDN to the nSFF_id that requested it and the pathID that is being calculated as a result of the discovery request. The discovery request for an FQDN that has not previously been served at the nSFF (or for an FQDN whose pathID information has been flushed as a result of the update operations in Section 6.2.5.3), results in an initial latency incurred by this discovery through the NR, while any SFC packet sent over the same SFP in a subsequent transaction will utilize the nSFF local mapping table. Such initial latency can be avoided by pre-populating the FQDN-pathID mapping proactively as part of the overall orchestration procedure, e.g., alongside the distribution of the nNLM information to the nSFF. Trossen, et al. Expires November 27, 2019 [Page 24] Internet-Draft Name Based SFF May 2019 6.2.5.2. Maintaining Forwarding Information at Local nSFF Each nSFF MUST maintain an internal table that maps the (hash of the) FQDN information to a suitable pathID information. As outlined in step 7 of Section 5.6, if a suitable entry does not exist for a given FQDN, the pathID information is requested with the operations in Section 6.2.5.1 and the suitable entry is locally created upon receiving a reply with the forwarding operation being executed as described in Section 6.2.1. If such entry does exist (i.e., step 6 of Section 5.6) the pathID is locally retrieved and used for the forwarding operation in Section 6.2.1. 6.2.5.3. Updating Forwarding Information at nSFF The forwarding information maintained at each nSFF (see Section 6.2.5.2) might need to be updated for three reasons: o An existing SF is no longer reachable: In this case, the nSFF with which the SF is locally registered, de-registers the SF explicitly at the NR by sending the packet in Figure 10 with the hashed FQDN and the R/D bit set to 1 (for de-register). o Another SF instance has become reachable in the network (and therefore might provide a better alternative to the existing SF): in this case, the NR has received another packet with format defined in Figure 11 but a different nSFF_id value. o Links along paths might no longer be reachable: the NR might use suitable southbound interface to transport networks to detect link failures, which it associates to the appropriate pathID bit position. For this purpose, the packet format in Figure 14 is sent from the NR to all affected nSFFs, using the generic format in Figure 9. +---------+-----------------+--------------//----+ | | | // | | Type | #IDs | IDs // | | (1 bit) | (8 bit) | // | +---------+-----------------+----------//--------+ Figure 14: Path update format o Type: 1 bit length (0 for Nsff ID, 1 for Link ID) Trossen, et al. Expires November 27, 2019 [Page 25] Internet-Draft Name Based SFF May 2019 o #IDs: 8 bit length for number of IDs in the list o IDs: List of IDs (Nsff ID or Link ID) The pathID to the affected nSFFs is computed as the binary OR over all pathIDs to those nSFF_ids affected where the pathID information to the affected nSFF_id values is determined from the NR-local table maintained in the registration/deregistration operation of Section 6.2.2. The pathID may include the type of information being updated (e.g., node identifiers of leaf nodes or link identifiers for removed links). The node identifier itself may be a special identifier to signal "ALL NODES" as being affected. The node identifier may signal changes to the network that are substantial (e.g., parallel link failures). The node identifier may trigger (e.g., recommend) purging of the entire path table (e.g., rather than the selective removal of a few nodes only). It will include the information according to the type. The included information may also be related to the type and length information for the number of identifiers being provided. In case 1 and 2, the Type bit is set to 1 (type nSFF_id) and the affected nSFFs are determined by those nSFFs that have previously sent SF discovery requests, utilizing the optional table mapping previously registered FQDNs to nSFF_id values. If no table mapping the (hash of) FQDN to nSFF_id is maintained, the update is sent to all nSFFs. Upon receiving the path update at the affected nSFF, all appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) identifiers provided will be removed, leading to a new NR discovery request at the next remote nSFF forwarding to the appropriate FQDN. In case 3, the Type bit is set to 0 (type linkID) and the affected nSFFs are determined by those nSFFs whose discovery requests have previously resulted in pathIDs which include the affected link, utilizing the optional table mapping previously registered FQDNs to pathID values (see Section 6.2.5.1). Upon receiving the node identifier information in the path update, the affected nSFF will check its internal table that maps FQDNs to pathIDs to determine those pathIDs affected by the link problems and remove path information that includes the received node identifier(s). For this, the pathID entries of said table are checked against the linkID values provided in the ID entry of the path update through a binary AND/CMP operation to check the inclusion of the link in the pathIDs to the FQDNs. If any pathID is affected, the FQDN-pathID entry is removed, leading to a new NR discovery request at the next remote nSFF forwarding to the appropriate FQDN. Trossen, et al. Expires November 27, 2019 [Page 26] Internet-Draft Name Based SFF May 2019 6.2.5.4. Forwarding to remote nSFF Once step 5, 6, and 7 in Section 5.6 are being executed, step 8 finally sends the SFC packet to the remote nSFF, utilizing the pathID returned in the discovery request (Section 6.2.5.1) or retrieved from the local pathID mapping table. The SFC packet is placed in the payload of the generic forwarding format in Figure 9 together with the pathID and the nSFF eventually executes the forwarding operations in Section 6.2.1. 7. IANA Considerations This document requests no IANA actions. 8. Security Considerations The operations in Sections 5 and 6 describes the forwarding of SFC packets between named SFs based on URIs exchanged in HTTP messages. For security considerations, TLS is sufficient between originating node and Nsff, Nsff to Nsff, Nsff to destination. TLS handshake allows to determine the FQDN, which in turn is enough for the service routing decision. Supporting TLS also allows the possibility of HTTPS based transactions. 9. Acknowledgement The authors would like to thank Dirk von Hugo and Andrew Malis for their reviews and valuable comments. We would also like to thank Joel Halpern, the chair of the SFC WG, and Adrian Farrel for guiding us through the IETF Independent Submission Editor (ISE) path. 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, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Trossen, et al. Expires November 27, 2019 [Page 27] Internet-Draft Name Based SFF May 2019 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . 10.2. Informative References [_3GPP_SBA] 3GPP, "Technical Realization of Service Based Architecture", 3GPP TS 29.500 0.4.0, January 2018, . [_3GPP_SBA_ENHANCEMENT] 3GPP, "New SID for Enhancements to the Service-Based 5G System Architecture", 3GPP S2-182904 , February 2018, . [I-D.ietf-bier-multicast-http-response] Purkayastha, D., Rahman, A., Trossen, D., and T. Eckert, "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", draft-ietf-bier-multicast-http- response-00 (work in progress), February 2019. [Reed2016] Reed, M., Al-Naday, M., Thomas, N., Trossen, D., and S. Spirou, "Stateless multicast switching in software defined networks", ICC 2016, 2016, . [Schlinker2017] Schlinker, B., Kim, H., Cui, T., Katz-Bassett, E., Madhyastha, Harsha., Cunha, I., Quinn, J., Hassan, S., Lapukhov, P., and H. Zeng, "Engineering Egress with Edge Fabric, Steering Oceans of Content to the World", ACM SIGCOMM 2017, 2017, . Trossen, et al. Expires November 27, 2019 [Page 28] Internet-Draft Name Based SFF May 2019 Authors' Addresses Dirk Trossen InterDigital Europe, Ltd 64 Great Eastern Street, 1st Floor London EC2A 3QR United Kingdom Email: Dirk.Trossen@InterDigital.com Debashish Purkayastha InterDigital Communications, LLC 1001 E Hector St Conshohocken USA Email: Debashish.Purkayastha@InterDigital.com Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal Canada Email: Akbar.Rahman@InterDigital.com Trossen, et al. Expires November 27, 2019 [Page 29] ./rfc-index.txt0000644000764400076440000642466713555507350013030 0ustar iustyiusty ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC INDEX ------------- (CREATED ON: 10/28/2019.) 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, PS, PDF, HTML) (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 follows in parentheses. One or more of the following formats are listed: text (TXT), PostScript (PS), Portable Document Format (PDF), HTML, XML. 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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0001) 0002 Host software. B. Duvall. April 1969. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0002) 0003 Documentation conventions. S.D. Crocker. April 1969. (Format: TXT, HTML) (Obsoleted by RFC0010) (Status: UNKNOWN) (DOI: 10.17487/RFC0003) 0004 Network timetable. E.B. Shapiro. March 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0004) 0005 Decode Encode Language (DEL). J. Rulifson. June 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0005) 0006 Conversation with Bob Kahn. S.D. Crocker. April 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0006) 0007 Host-IMP interface. G. Deloche. May 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0007) 0008 ARPA Network Functional Specifications. G. Deloche. May 1969. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0008) 0009 Host Software. G. Deloche. May 1969. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0009) 0010 Documentation conventions. S.D. Crocker. July 1969. (Format: TXT, HTML) (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, PDF, HTML) (Obsoleted by RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0011) 0012 IMP-Host interface flow diagrams. M. Wingfield. August 1969. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0012) 0013 Zero Text Length EOF Message. V. Cerf. August 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0013) 0014 Not Issued. 0015 Network subsystem for time sharing hosts. C.S. Carr. September 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0015) 0016 M.I.T. S. Crocker. August 1969. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0017) 0018 IMP-IMP and HOST-HOST Control Links. V. Cerf. September 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0018) 0019 Two protocol suggestions to reduce congestion at swap bound nodes. J.E. Kreznar. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0019) 0020 ASCII format for network interchange. V.G. Cerf. October 1969. (Format: TXT, PDF, HTML) (Also STD0080) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0020) 0021 Network meeting. V.G. Cerf. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0021) 0022 Host-host control message formats. V.G. Cerf. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0022) 0023 Transmission of Multiple Control Messages. G. Gregg. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0023) 0024 Documentation Conventions. S.D. Crocker. November 1969. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0025) 0026 Not Issued. 0027 Documentation Conventions. S.D. Crocker. December 1969. (Format: TXT, HTML) (Updates RFC0010, RFC0016, RFC0024) (Updated by RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0027) 0028 Time Standards. W.K. English. January 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0028) 0029 Response to RFC 28. R.E. Kahn. January 1970. (Format: TXT, HTML) (Also RFC0028) (Status: UNKNOWN) (DOI: 10.17487/RFC0029) 0030 Documentation Conventions. S.D. Crocker. February 1970. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0031) 0032 Some Thoughts on SRI's Proposed Real Time Clock. J. Cole. February 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0032) 0033 New Host-Host Protocol. S.D. Crocker. February 1970. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0034) 0035 Network Meeting. S.D. Crocker. March 1970. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0035) 0036 Protocol Notes. S.D. Crocker. March 1970. (Format: TXT, HTML) (Updates RFC0033) (Updated by RFC0039, RFC0044) (Status: UNKNOWN) (DOI: 10.17487/RFC0036) 0037 Network Meeting Epilogue, etc. S.D. Crocker. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0037) 0038 Comments on Network Protocol from NWG/RFC #36. S.M. Wolfe. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0038) 0039 Comments on Protocol Re: NWG/RFC #36. E. Harslem, J.F. Heafner. March 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0039) 0040 More Comments on the Forthcoming Protocol. E. Harslem, J.F. Heafner. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0040) 0041 IMP-IMP Teletype Communication. J.T. Melvin. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0041) 0042 Message Data Types. E. Ancona. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0042) 0043 Proposed Meeting. A.G. Nemeth. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0043) 0044 Comments on NWG/RFC 33 and 36. A. Shoshani, R. Long, A. Landsberg. April 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0044) 0045 New Protocol is Coming. J. Postel, S.D. Crocker. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0045) 0046 ARPA Network protocol notes. E. Meyer. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0046) 0047 BBN's Comments on NWG/RFC #33. J. Postel, S. Crocker. April 1970. (Format: TXT, HTML) (Updates RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0047) 0048 Possible protocol plateau. J. Postel, S.D. Crocker. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0048) 0049 Conversations with S. Crocker (UCLA). E. Meyer. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0049) 0050 Comments on the Meyer Proposal. E. Harslen, J. Heafner. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0050) 0051 Proposal for a Network Interchange Language. M. Elie. May 1970. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0051) 0052 Updated distribution list. J. Postel, S.D. Crocker. July 1970. (Format: TXT, HTML) (Updated by RFC0069) (Status: UNKNOWN) (DOI: 10.17487/RFC0052) 0053 Official protocol mechanism. S.D. Crocker. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0053) 0054 Official Protocol Proffering. S.D. Crocker, J. Postel, J. Newkirk, M. Kraley. June 1970. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0056) 0057 Thoughts and Reflections on NWG/RFC 54. M. Kraley, J. Newkirk. June 1970. (Format: TXT, HTML) (Updates RFC0054) (Status: UNKNOWN) (DOI: 10.17487/RFC0057) 0058 Logical Message Synchronization. T.P. Skinner. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0058) 0059 Flow Control - Fixed Versus Demand Allocation. E. Meyer. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0059) 0060 A Simplified NCP Protocol. R. Kalin. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0060) 0061 Note on Interprocess Communication in a Resource Sharing Computer Network. D.C. Walden. July 1970. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0061) (Status: UNKNOWN) (DOI: 10.17487/RFC0062) 0063 Belated Network Meeting Report. V.G. Cerf. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0063) 0064 Getting rid of marking. M. Elie. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0064) 0065 Comments on Host/Host Protocol document #1. D.C. Walden. August 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0065) 0066 NIC - third level ideas and other noise. S.D. Crocker. August 1970. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0068) 0069 Distribution List Change for MIT. A.K. Bhushan. September 1970. (Format: TXT, HTML) (Updates RFC0052) (Status: UNKNOWN) (DOI: 10.17487/RFC0069) 0070 Note on Padding. S.D. Crocker. October 1970. (Format: TXT, HTML) (Updated by RFC0228) (Status: UNKNOWN) (DOI: 10.17487/RFC0070) 0071 Reallocation in Case of Input Error. T. Schipper. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0071) 0072 Proposed Moratorium on Changes to Network Protocol. R.D. Bressler. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0072) 0073 Response to NWG/RFC 67. S.D. Crocker. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0073) 0074 Specifications for Network Use of the UCSB On-Line System. J.E. White. October 1970. (Format: TXT, PDF, HTML) (Updated by RFC0217, RFC0225) (Status: UNKNOWN) (DOI: 10.17487/RFC0074) 0075 Network Meeting. S.D. Crocker. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0075) 0076 Connection by name: User oriented protocol. J. Bouknight, J. Madden, G.R. Grossman. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0076) 0077 Network meeting report. J. Postel. November 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0077) 0078 NCP Status Report: UCSB/Rand. E. Harslem, J.F. Heafner, J.E. White. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0078) 0079 Logger Protocol error. E. Meyer. November 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0079) 0080 Protocols and Data Formats. E. Harslem, J.F. Heafner. December 1970. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0081) 0082 Network Meeting Notes. E. Meyer. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0082) 0083 Language-machine for data reconfiguration. R.H. Anderson, E. Harslem, J.F. Heafner. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0083) 0084 List of NWG/RFC's 1-80. J.B. North. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0084) 0085 Network Working Group meeting. S.D. Crocker. December 1970. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0088) 0089 Some historic moments in networking. R.M. Metcalfe. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0089) 0090 CCN as a Network Service Center. R.T. Braden. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0090) 0091 Proposed User-User Protocol. G.H. Mealy. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0091) 0092 Not Issued. 0093 Initial Connection Protocol. A.M. McKenzie. January 1971. (Format: TXT, HTML) (Updates RFC0066, RFC0080) (Status: UNKNOWN) (DOI: 10.17487/RFC0093) 0094 Some thoughts on Network Graphics. E. Harslem, J.F. Heafner. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0094) 0095 Distribution of NWG/RFC's through the NIC. S. Crocker. February 1971. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0096) 0097 First Cut at a Proposed Telnet Protocol. J.T. Melvin, R.W. Watson. February 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0097) 0098 Logger Protocol Proposal. E. Meyer, T. Skinner. February 1971. (Format: TXT, HTML) (Updated by RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0098) 0099 Network Meeting. P.M. Karp. February 1971. (Format: TXT, HTML) (Updated by RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0099) 0100 Categorization and guide to NWG/RFCs. P.M. Karp. February 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0102) 0103 Implementation of Interrupt Keys. R.B. Kalin. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0103) 0104 Link 191. J.B. Postel, S.D. Crocker. February 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, PDF, HTML) (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, PDF, HTML) (Updated by RFC0135) (Status: UNKNOWN) (DOI: 10.17487/RFC0110) 0111 Pressure from the Chairman. S.D. Crocker. March 1971. (Format: TXT, HTML) (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, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0112) 0113 Network activity report: UCSB Rand. E. Harslem, J.F. Heafner, J.E. White. April 1971. (Format: TXT, HTML) (Updated by RFC0227) (Status: UNKNOWN) (DOI: 10.17487/RFC0113) 0114 File Transfer Protocol. A.K. Bhushan. April 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0115) 0116 Structure of the May NWG Meeting. S.D. Crocker. April 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0117) 0118 Recommendations for facility documentation. R.W. Watson. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0118) 0119 Network Fortran Subprograms. M. Krilanovich. April 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0119) 0120 Network PL1 subprograms. M. Krilanovich. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0120) 0121 Network on-line operators. M. Krilanovich. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0121) 0122 Network specifications for UCSB's Simple-Minded File System. J.E. White. April 1971. (Format: TXT, HTML) (Updated by RFC0217, RFC0269, RFC0399, RFC0431) (Status: UNKNOWN) (DOI: 10.17487/RFC0122) 0123 Proffered Official ICP. S.D. Crocker. April 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC0086) (Updated by RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0125) 0126 Graphics Facilities at Ames Research Center. J. McConnell. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0126) 0127 Comments on RFC 123. J. Postel. April 1971. (Format: TXT, HTML) (Obsoleted by RFC0145) (Updates RFC0123) (Updated by RFC0151) (Status: UNKNOWN) (DOI: 10.17487/RFC0127) 0128 Bytes. J. Postel. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0128) 0129 Request for comments on socket name structure. E. Harslem, J. Heafner, E. Meyer. April 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0131) 0132 Typographical Error in RFC 107. J.E. White. April 1971. (Format: TXT, HTML) (Obsoleted by RFC0154) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0132) 0133 File Transfer and Error Recovery. R.L. Sunberg. April 1971. (Format: TXT, HTML) (Updates RFC0114) (Status: UNKNOWN) (DOI: 10.17487/RFC0133) 0134 Network Graphics meeting. A. Vezza. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0134) 0135 Response to NWG/RFC 110. W. Hathaway. April 1971. (Format: TXT, HTML) (Updates RFC0110) (Status: UNKNOWN) (DOI: 10.17487/RFC0135) 0136 Host accounting and administrative procedures. R.E. Kahn. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0136) 0137 Telnet Protocol - a proposed document. T.C. O'Sullivan. April 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0138) 0139 Discussion of Telnet Protocol. T.C. O'Sullivan. May 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0142) 0143 Regarding proffered official ICP. W. Naylor, J. Wong, C. Kline, J. Postel. May 1971. (Format: TXT, HTML) (Obsoleted by RFC0165) (Updates RFC0123, RFC0145) (Status: UNKNOWN) (DOI: 10.17487/RFC0143) 0144 Data sharing on computer networks. A. Shoshani. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0144) 0145 Initial Connection Protocol Control Commands. J. Postel. May 1971. (Format: TXT, PS, PDF, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0146) 0147 Definition of a socket. J.M. Winett. May 1971. (Format: TXT, HTML) (Updates RFC0129) (Status: UNKNOWN) (DOI: 10.17487/RFC0147) 0148 Comments on RFC 123. A.K. Bhushan. May 1971. (Format: TXT, HTML) (Updates RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0148) 0149 Best Laid Plans. S.D. Crocker. May 1971. (Format: TXT, HTML) (Updates RFC0140) (Status: UNKNOWN) (DOI: 10.17487/RFC0149) 0150 Use of IPC Facilities: A Working Paper. R.B. Kalin. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0150) 0151 Comments on a proffered official ICP: RFCs 123, 127. A. Shoshani. May 1971. (Format: TXT, HTML) (Updates RFC0127) (Status: UNKNOWN) (DOI: 10.17487/RFC0151) 0152 SRI Artificial Intelligence status report. M. Wilber. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0152) 0153 SRI ARC-NIC status. J.T. Melvin, R.W. Watson. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0153) 0154 Exposition Style. S.D. Crocker. May 1971. (Format: TXT, HTML) (Obsoletes RFC0132) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0154) 0155 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0157) 0158 Telnet Protocol: A Proposed Document. T.C. O'Sullivan. May 1971. (Format: TXT, PDF, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0161) 0162 NETBUGGER3. M. Kampe. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0162) 0163 Data transfer protocols. V.G. Cerf. May 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0164) 0165 Proffered Official Initial Connection Protocol. J. Postel. May 1971. (Format: TXT, PDF, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0166) 0167 Socket conventions reconsidered. A.K. Bhushan, R.M. Metcalfe, J.M. Winett. May 1971. (Format: TXT, HTML) (Also RFC0129, RFC0147) (Status: UNKNOWN) (DOI: 10.17487/RFC0167) 0168 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT, HTML) (Obsoletes RFC0155) (Obsoleted by RFC0211) (Status: UNKNOWN) (DOI: 10.17487/RFC0168) 0169 COMPUTER NETWORKS. S.D. Crocker. May 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0169) 0170 RFC List by Number. Network Information Center. Stanford Research Institute. June 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0173) 0174 UCLA - Computer Science Graphics Overview. J. Postel, V.G. Cerf. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0174) 0175 Comments on "Socket Conventions Reconsidered". E. Harslem, J.F. Heafner. June 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0176) 0177 Device independent graphical display description. J. McConnell. June 1971. (Format: TXT, HTML) (Updates RFC0125) (Updated by RFC0181) (Status: UNKNOWN) (DOI: 10.17487/RFC0177) 0178 Network graphic attention handling. I.W. Cotton. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0178) 0179 Link Number Assignments. A.M. McKenzie. June 1971. (Format: TXT, HTML) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0179) 0180 File system questionnaire. A.M. McKenzie. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0180) 0181 Modifications to RFC 177. J. McConnell. July 1971. (Format: TXT, HTML) (Updates RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0181) 0182 Compilation of list of relevant site reports. J.B. North. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0182) 0183 EBCDIC Codes and Their Mapping to ASCII. J.M. Winett. July 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0183) 0184 Proposed graphic display modes. K.C. Kelley. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0184) 0185 NIC distribution of manuals and handbooks. J.B. North. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0185) 0186 Network graphics loader. J.C. Michener. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0186) 0187 Network/440 Protocol Concept. D.B. McKay, D.P. Karp. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0187) 0188 Data management meeting announcement. P.M. Karp, D.B. McKay. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0188) 0189 Interim NETRJS specifications. R.T. Braden. July 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0190) 0191 Graphics implementation and conceptualization at Augmentation Research Center. C.H. Irby. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0191) 0192 Some factors which a Network Graphics Protocol must consider. R.W. Watson. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0192) 0193 NETWORK CHECKOUT. E. Harslem, J.F. Heafner. July 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0194) 0195 Data computers-data descriptions and access language. G.H. Mealy. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0195) 0196 Mail Box Protocol. R.W. Watson. July 1971. (Format: TXT, HTML) (Obsoleted by RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0196) 0197 Initial Connection Protocol - Reviewed. A. Shoshani, E. Harslem. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0197) 0198 Site Certification - Lincoln Labs 360/67. J.F. Heafner. July 1971. (Format: TXT, HTML) (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, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0199) 0200 RFC list by number. J.B. North. August 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0202) 0203 Achieving reliable communication. R.B. Kalin. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0203) 0204 Sockets in use. J. Postel. August 1971. (Format: TXT, HTML) (Updated by RFC0234) (Status: UNKNOWN) (DOI: 10.17487/RFC0204) 0205 NETCRT - a character display protocol. R.T. Braden. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0205) 0206 A User TELNET Description of an Initial Implementation. J. White. August 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0206) 0207 September Network Working Group meeting. A. Vezza. August 1971. (Format: TXT, HTML) (Obsoleted by RFC0212) (Status: UNKNOWN) (DOI: 10.17487/RFC0207) 0208 Address tables. A.M. McKenzie. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0208) 0209 Host/IMP interface documentation. B. Cosell. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0209) 0210 Improvement of Flow Control. W. Conrad. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0210) 0211 ARPA Network Mailing Lists. J.B. North. August 1971. (Format: TXT, PDF, HTML) (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, HTML) (Obsoletes RFC0207) (Updated by RFC0222) (Status: UNKNOWN) (DOI: 10.17487/RFC0212) 0213 IMP System change notification. B. Cosell. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0213) 0214 Network checkpoint. E. Harslem. August 1971. (Format: TXT, HTML) (Obsoletes RFC0198) (Status: UNKNOWN) (DOI: 10.17487/RFC0214) 0215 NCP, ICP, and Telnet: The Terminal IMP implementation. A.M. McKenzie. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0215) 0216 Telnet Access to UCSB's On-Line System. J.E. White. September 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0216) 0217 Specifications changes for OLS, RJE/RJOR, and SMFS. J.E. White. September 1971. (Format: TXT, HTML) (Updates RFC0074, RFC0105, RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0217) 0218 Changing the IMP status reporting facility. B. Cosell. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0218) 0219 User's View of the Datacomputer. R. Winter. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0219) 0220 Not Issued. 0221 Mail Box Protocol: Version 2. R.W. Watson. August 1971. (Format: TXT, HTML) (Obsoletes RFC0196) (Obsoleted by RFC0278) (Status: UNKNOWN) (DOI: 10.17487/RFC0221) 0222 Subject: System programmer's workshop. R.M. Metcalfe. September 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0223) 0224 Comments on Mailbox Protocol. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0224) 0225 Rand/UCSB network graphics experiment. E. Harslem, R. Stoughton. September 1971. (Format: TXT, HTML) (Updates RFC0074) (Status: UNKNOWN) (DOI: 10.17487/RFC0225) 0226 Standardization of host mnemonics. P.M. Karp. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0247) (Status: UNKNOWN) (DOI: 10.17487/RFC0226) 0227 Data transfer rates (Rand/UCLA). J.F. Heafner, E. Harslem. September 1971. (Format: TXT, HTML) (Updates RFC0113) (Status: UNKNOWN) (DOI: 10.17487/RFC0227) 0228 Clarification. D.C. Walden. September 1971. (Format: TXT, HTML) (Updates RFC0070) (Status: UNKNOWN) (DOI: 10.17487/RFC0228) 0229 Standard host names. J. Postel. September 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0231) 0232 Postponement of network graphics meeting. A. Vezza. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0232) 0233 Standardization of host call letters. A. Bhushan, R. Metcalfe. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0233) 0234 Network Working Group meeting schedule. A. Vezza. October 1971. (Format: TXT, HTML) (Updates RFC0222, RFC0204) (Status: UNKNOWN) (DOI: 10.17487/RFC0234) 0235 Site status. E. Westheimer. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0240) (Status: UNKNOWN) (DOI: 10.17487/RFC0235) 0236 Standard host names. J. Postel. September 1971. (Format: TXT, HTML) (Obsoletes RFC0229) (Status: UNKNOWN) (DOI: 10.17487/RFC0236) 0237 NIC view of standard host names. R.W. Watson. October 1971. (Format: TXT, HTML) (Obsoleted by RFC0273) (Status: UNKNOWN) (DOI: 10.17487/RFC0237) 0238 Comments on DTP and FTP proposals. R.T. Braden. September 1971. (Format: TXT, HTML) (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, HTML) (Also RFC0226, RFC0229, RFC0236) (Status: UNKNOWN) (DOI: 10.17487/RFC0239) 0240 Site Status. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Obsoletes RFC0235) (Obsoleted by RFC0252) (Status: UNKNOWN) (DOI: 10.17487/RFC0240) 0241 Connecting computers to MLC ports. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0241) 0242 Data Descriptive Language for Shared Data. L. Haibt, A.P. Mullery. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0242) 0243 Network and data sharing bibliography. A.P. Mullery. October 1971. (Format: TXT, HTML) (Obsoleted by RFC0290) (Status: UNKNOWN) (DOI: 10.17487/RFC0243) 0244 Not Issued. 0245 Reservations for Network Group meeting. C. Falls. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0245) 0246 Network Graphics meeting. A. Vezza. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0246) 0247 Proffered set of standard host names. P.M. Karp. October 1971. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0249) 0250 Some thoughts on file transfer. H. Brodie. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0250) 0251 Weather data. D. Stern. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0251) 0252 Network host status. E. Westheimer. October 1971. (Format: TXT, HTML) (Obsoletes RFC0240) (Obsoleted by RFC0255) (Status: UNKNOWN) (DOI: 10.17487/RFC0252) 0253 Second Network Graphics meeting details. J.A. Moorer. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0253) 0254 Scenarios for using ARPANET computers. A. Bhushan. October 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0254) 0255 Status of network hosts. E. Westheimer. October 1971. (Format: TXT, HTML) (Obsoletes RFC0252) (Obsoleted by RFC0266) (Status: UNKNOWN) (DOI: 10.17487/RFC0255) 0256 IMPSYS change notification. B. Cosell. November 1971. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC0255) (Obsoleted by RFC0267) (Status: UNKNOWN) (DOI: 10.17487/RFC0266) 0267 Network Host Status. E. Westheimer. November 1971. (Format: TXT, HTML) (Obsoletes RFC0266) (Obsoleted by RFC0287) (Status: UNKNOWN) (DOI: 10.17487/RFC0267) 0268 Graphics facilities information. J. Postel. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0268) 0269 Some Experience with File Transfer. H. Brodie. December 1971. (Format: TXT, HTML) (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, PDF, HTML) (Updates NIC7959) (Status: UNKNOWN) (DOI: 10.17487/RFC0270) 0271 IMP System change notifications. B. Cosell. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0271) 0272 Not Issued. 0273 More on standard host names. R.W. Watson. October 1971. (Format: TXT, HTML) (Obsoletes RFC0237) (Status: UNKNOWN) (DOI: 10.17487/RFC0273) 0274 Establishing a local guide for network usage. E. Forman. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0274) 0275 Not Issued. 0276 NIC course. R.W. Watson. November 1971. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0278) 0279 Not Issued. 0280 A Draft of Host Names. R.W. Watson. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0280) 0281 Suggested addition to File Transfer Protocol. A.M. McKenzie. December 1971. (Format: TXT, HTML) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0281) 0282 Graphics meeting report. M.A. Padlipsky. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0282) 0283 NETRJT: Remote Job Service Protocol for TIPS. R.T. Braden. December 1971. (Format: TXT, HTML) (Updates RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0283) 0284 Not Issued. 0285 Network graphics. D. Huff. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0285) 0286 Network Library Information System. E. Forman. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0286) 0287 Status of Network Hosts. E. Westheimer. December 1971. (Format: TXT, HTML) (Obsoletes RFC0267) (Obsoleted by RFC0288) (Status: UNKNOWN) (DOI: 10.17487/RFC0287) 0288 Network host status. E. Westheimer. January 1972. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC0384) (Status: UNKNOWN) (DOI: 10.17487/RFC0289) 0290 Computer networks and data sharing: A bibliography. A.P. Mullery. January 1972. (Format: TXT, HTML) (Obsoletes RFC0243) (Status: UNKNOWN) (DOI: 10.17487/RFC0290) 0291 Data Management Meeting Announcement. D.B. McKay. January 1972. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC0493) (Status: UNKNOWN) (DOI: 10.17487/RFC0292) 0293 Network Host Status. E. Westheimer. January 1972. (Format: TXT, HTML) (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, HTML) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0294) 0295 Report of the Protocol Workshop, 12 October 1971. J. Postel. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0295) 0296 DS-1 Display System. D.E. Liddle. January 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0296) 0297 TIP Message Buffers. D.C. Walden. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0297) 0298 Network host status. E. Westheimer. February 1972. (Format: TXT, HTML) (Obsoletes RFC0293) (Obsoleted by RFC0306) (Status: UNKNOWN) (DOI: 10.17487/RFC0298) 0299 Information Management System. D. Hopkin. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0299) 0300 ARPA Network mailing lists. J.B. North. January 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0301) 0302 Exercising The ARPANET. R.F. Bryan. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0302) 0303 ARPA Network mailing lists. Network Information Center. Stanford Research Institute. March 1972. (Format: TXT, HTML) (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, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0304) 0305 Unknown Host Numbers. R. Alter. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0305) 0306 Network host status. E. Westheimer. February 1972. (Format: TXT, HTML) (Obsoletes RFC0298) (Obsoleted by RFC0315) (Status: UNKNOWN) (DOI: 10.17487/RFC0306) 0307 Using network Remote Job Entry. E. Harslem. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0307) 0308 ARPANET host availability data. M. Seriff. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0308) 0309 Data and File Transfer Workshop Announcement. A.K. Bhushan. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0309) 0310 Another Look at Data and File Transfer Protocols. A.K. Bhushan. April 1972. (Format: TXT, HTML) (Updates RFC0264, RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0310) 0311 New Console Attachments to the USCB Host. R.F. Bryan. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0311) 0312 Proposed Change in IMP-to-Host Protocol. A.M. McKenzie. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0312) 0313 Computer based instruction. T.C. O'Sullivan. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0313) 0314 Network Graphics Working Group Meeting. I.W. Cotton. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0314) 0315 Network Host Status. E. Westheimer. March 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0316) 0317 Official Host-Host Protocol Modification: Assigned Link Numbers. J. Postel. March 1972. (Format: TXT, HTML) (Obsoleted by RFC0604) (Status: UNKNOWN) (DOI: 10.17487/RFC0317) 0318 Telnet Protocols. J. Postel. April 1972. (Format: TXT, HTML) (Updates RFC0158) (Updated by RFC0435) (Also RFC0139, RFC0158) (Status: UNKNOWN) (DOI: 10.17487/RFC0318) 0319 Network Host Status. E. Westheimer. March 1972. (Format: TXT, HTML) (Obsoletes RFC0315) (Updated by RFC0326) (Status: UNKNOWN) (DOI: 10.17487/RFC0319) 0320 Workshop on Hard Copy Line Graphics. R. Reddy. March 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0320) 0321 CBI Networking Activity at MITRE. P.M. Karp. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0321) 0322 Well known socket numbers. V. Cerf, J. Postel. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0322) 0323 Formation of Network Measurement Group (NMG). V. Cerf. March 1972. (Format: TXT, HTML) (Updated by RFC0388) (Status: UNKNOWN) (DOI: 10.17487/RFC0323) 0324 RJE Protocol meeting. J. Postel. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0324) 0325 Network Remote Job Entry program - NETRJS. G. Hicks. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0325) 0326 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0327) 0328 Suggested Telnet Protocol Changes. J. Postel. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0328) 0329 ARPA Network Mailing Lists. Network Information Center. Stanford Research Institute. May 1972. (Format: TXT, HTML) (Obsoletes RFC0303) (Obsoleted by RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0329) 0330 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (Obsoletes RFC0326) (Updated by RFC0332) (Status: UNKNOWN) (DOI: 10.17487/RFC0330) 0331 IMP System Change Notification. J.M. McQuillan. April 1972. (Format: TXT, HTML) (Obsoleted by RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0331) 0332 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0333) 0334 Network Use on May 8. A.M. McKenzie. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0334) 0335 New Interface - IMP/360. R.F. Bryan. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0335) 0336 Level 0 Graphic Input Protocol. I.W. Cotton. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0336) 0337 Not Issued. 0338 EBCDIC/ASCII Mapping for Network RJE. R.T. Braden. May 1972. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0338) 0339 MLTNET: A "Multi Telnet" Subsystem for Tenex. R. Thomas. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0339) 0340 Proposed Telnet Changes. T.C. O'Sullivan. May 1972. (Format: TXT, HTML) (Also RFC0328) (Status: UNKNOWN) (DOI: 10.17487/RFC0340) 0341 Not Issued. 0342 Network Host Status. E. Westheimer. May 1972. (Format: TXT, HTML) (Obsoletes RFC0332) (Obsoleted by RFC0344) (Status: UNKNOWN) (DOI: 10.17487/RFC0342) 0343 IMP System change notification. A.M. McKenzie. May 1972. (Format: TXT, HTML) (Obsoletes RFC0331) (Obsoleted by RFC0359) (Status: UNKNOWN) (DOI: 10.17487/RFC0343) 0344 Network Host Status. E. Westheimer. May 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0345) 0346 Satellite Considerations. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0346) 0347 Echo process. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0347) 0348 Discard Process. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0348) 0349 Proposed Standard Socket Numbers. J. Postel. May 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0350) 0351 Graphics information form for the ARPANET graphics resources notebook. D. Crocker. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0351) 0352 TIP Site Information Form. D. Crocker. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0352) 0353 Network host status. E. Westheimer. June 1972. (Format: TXT, HTML) (Obsoletes RFC0344) (Obsoleted by RFC0362) (Status: UNKNOWN) (DOI: 10.17487/RFC0353) 0354 File Transfer Protocol. A.K. Bhushan. July 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0355) 0356 ARPA Network Control Center. R. Alter. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0356) 0357 Echoing strategy for satellite links. J. Davidson. June 1972. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0359) 0360 Proposed Remote Job Entry Protocol. C. Holland. June 1972. (Format: TXT, PDF, HTML) (Obsoleted by RFC0407) (Status: UNKNOWN) (DOI: 10.17487/RFC0360) 0361 Deamon Processes on Host 106. R.D. Bressler. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0361) 0362 Network Host Status. E. Westheimer. June 1972. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0364) 0365 Letter to All TIP Users. D.C. Walden. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0365) 0366 Network Host Status. E. Westheimer. July 1972. (Format: TXT, HTML) (Obsoletes RFC0362) (Obsoleted by RFC0367) (Status: UNKNOWN) (DOI: 10.17487/RFC0366) 0367 Network host status. E. Westheimer. July 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0368) 0369 Evaluation of ARPANET services January-March, 1972. J.R. Pickens. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0369) 0370 Network Host Status. E. Westheimer. July 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0371) 0372 Notes on a Conversation with Bob Kahn on the ICCC. R.W. Watson. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0372) 0373 Arbitrary Character Sets. J. McCarthy. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0373) 0374 IMP System Announcement. A.M. McKenzie. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0374) 0375 Not Issued. 0376 Network Host Status. E. Westheimer. August 1972. (Format: TXT, HTML) (Updates RFC0370) (Status: UNKNOWN) (DOI: 10.17487/RFC0376) 0377 Using TSO via ARPA Network Virtual Terminal. R.T. Braden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0377) 0378 Traffic statistics (July 1972). A.M. McKenzie. August 1972. (Format: TXT, HTML) (Obsoleted by RFC0391) (Status: UNKNOWN) (DOI: 10.17487/RFC0378) 0379 Using TSO at CCN. R. Braden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0379) 0380 Not Issued. 0381 Three aids to improved network operation. J.M. McQuillan. July 1972. (Format: TXT, HTML) (Updated by RFC0394) (Status: UNKNOWN) (DOI: 10.17487/RFC0381) 0382 Mathematical Software on the ARPA Network. L. McDaniel. August 1972. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0289) (Status: UNKNOWN) (DOI: 10.17487/RFC0384) 0385 Comments on the File Transfer Protocol. A.K. Bhushan. August 1972. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC0401) (Status: UNKNOWN) (DOI: 10.17487/RFC0387) 0388 NCP statistics. V. Cerf. August 1972. (Format: TXT, HTML) (Updates RFC0323) (Status: UNKNOWN) (DOI: 10.17487/RFC0388) 0389 UCLA Campus Computing Network Liaison Staff for ARPA Network. B. Noble. August 1972. (Format: TXT, HTML) (Obsoleted by RFC0423) (Status: UNKNOWN) (DOI: 10.17487/RFC0389) 0390 TSO Scenario. R.T. Braden. September 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0390) 0391 Traffic statistics (August 1972). A.M. McKenzie. September 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0392) 0393 Comments on Telnet Protocol Changes. J.M. Winett. October 1972. (Format: TXT, HTML) (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, HTML) (Updates RFC0381) (Status: UNKNOWN) (DOI: 10.17487/RFC0394) 0395 Switch Settings on IMPs and TIPs. J.M. McQuillan. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0395) 0396 Network Graphics Working Group Meeting - Second Iteration. S. Bunch. November 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0398) 0399 SMFS Login and Logout. M. Krilanovich. September 1972. (Format: TXT, HTML) (Obsoleted by RFC0431) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0399) 0400 Traffic Statistics (September 1972). A.M. McKenzie. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0400) 0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates. J. Hansen. October 1972. (Format: TXT, HTML) (Updates RFC0387) (Status: UNKNOWN) (DOI: 10.17487/RFC0401) 0402 ARPA Network Mailing Lists. J.B. North. October 1972. (Format: TXT, HTML) (Obsoletes RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0402) 0403 Desirability of a Network 1108 Service. G. Hicks. January 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0403) 0404 Host Address Changes Involving Rand and ISI. A.M. McKenzie. October 1972. (Format: TXT, HTML) (Updated by RFC0405) (Status: UNKNOWN) (DOI: 10.17487/RFC0404) 0405 Correction to RFC 404. A.M. McKenzie. October 1972. (Format: TXT, HTML) (Updates RFC0404) (Status: UNKNOWN) (DOI: 10.17487/RFC0405) 0406 Scheduled IMP Software Releases. J.M. McQuillan. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0406) 0407 Remote Job Entry Protocol. R.D. Bressler, R. Guida, A.M. McKenzie. October 1972. (Format: TXT, HTML) (Obsoletes RFC0360) (Status: HISTORIC) (DOI: 10.17487/RFC0407) 0408 NETBANK. A.D. Owen, J. Postel. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0408) 0409 Tenex interface to UCSB's Simple-Minded File System. J.E. White. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0409) 0410 Removal of the 30-Second Delay When Hosts Come Up. J.M. McQuillan. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0410) 0411 New MULTICS Network Software Features. M.A. Padlipsky. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0411) 0412 User FTP Documentation. G. Hicks. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0412) 0413 Traffic statistics (October 1972). A.M. McKenzie. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0413) 0414 File Transfer Protocol (FTP) status and further comments. A.K. Bhushan. December 1972. (Format: TXT, HTML) (Updates RFC0385) (Status: UNKNOWN) (DOI: 10.17487/RFC0414) 0415 Tenex bandwidth. H. Murray. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0415) 0416 ARC System Will Be Unavailable for Use During Thanksgiving Week. J.C. Norton. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0416) 0417 Link usage violation. J. Postel, C. Kline. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0417) 0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center. W. Hathaway. November 1972. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0418) 0419 To: Network liaisons and station agents. A. Vezza. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0419) 0420 CCA ICCC weather demo. H. Murray. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0420) 0421 Software Consulting Service for Network Users. A.M. McKenzie. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0421) 0422 Traffic statistics (November 1972). A.M. McKenzie. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0422) 0423 UCLA Campus Computing Network Liaison Staff for ARPANET. B. Noble. December 1972. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0425) 0426 Reconnection Protocol. R. Thomas. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0426) 0427 Not Issued. 0428 Not Issued. 0429 Character Generator Process. J. Postel. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0429) 0430 Comments on File Transfer Protocol. R.T. Braden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0430) 0431 Update on SMFS Login and Logout. M. Krilanovich. December 1972. (Format: TXT, HTML) (Obsoletes RFC0399) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0431) 0432 Network logical map. N. Neigus. December 1972. (Format: TXT, PDF, PS, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0432) 0433 Socket number list. J. Postel. December 1972. (Format: TXT, HTML) (Obsoletes RFC0349) (Obsoleted by RFC0503) (Status: UNKNOWN) (DOI: 10.17487/RFC0433) 0434 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Obsoleted by RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0434) 0435 Telnet issues. B. Cosell, D.C. Walden. January 1973. (Format: TXT, HTML) (Updates RFC0318) (Status: UNKNOWN) (DOI: 10.17487/RFC0435) 0436 Announcement of RJS at UCSB. M. Krilanovich. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0436) 0437 Data Reconfiguration Service at UCSB. E. Faeh. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0437) 0438 FTP server-server interaction. R. Thomas, R. Clements. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0438) 0439 PARRY encounters the DOCTOR. V. Cerf. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0439) 0440 Scheduled network software maintenance. D.C. Walden. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0440) 0441 Inter-Entity Communication - an experiment. R.D. Bressler, R. Thomas. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0441) 0442 Current flow-control scheme for IMPSYS. V. Cerf. January 1973. (Format: TXT, HTML) (Updated by RFC0449) (Status: UNKNOWN) (DOI: 10.17487/RFC0442) 0443 Traffic statistics (December 1972). A.M. McKenzie. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0443) 0444 Not Issued. 0445 IMP/TIP preventive maintenance schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0445) 0446 Proposal to consider a network program resource notebook. L.P. Deutsch. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0446) 0447 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Obsoletes RFC0434) (Obsoleted by RFC0476) (Status: UNKNOWN) (DOI: 10.17487/RFC0447) 0448 Print files in FTP. R.T. Braden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0448) 0449 Current flow-control scheme for IMPSYS. D.C. Walden. January 1973. (Format: TXT, HTML) (Updates RFC0442) (Status: UNKNOWN) (DOI: 10.17487/RFC0449) 0450 MULTICS sampling timeout change. M.A. Padlipsky. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0450) 0451 Tentative proposal for a Unified User Level Protocol. M.A. Padlipsky. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0451) 0452 TELNET Command at Host LL. J. Winett. February 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0452) 0453 Meeting announcement to discuss a network mail system. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0453) 0454 File Transfer Protocol - meeting announcement and a new proposed document. A.M. McKenzie. February 1973. (Format: TXT, HTML) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0454) 0455 Traffic statistics (January 1973). A.M. McKenzie. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0455) 0456 Memorandum: Date change of mail meeting. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0456) 0457 TIPUG. D.C. Walden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0457) 0458 Mail retrieval via FTP. R.D. Bressler, R. Thomas. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0458) 0459 Network questionnaires. W. Kantrowitz. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0459) 0460 NCP survey. C. Kline. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0460) 0461 Telnet Protocol meeting announcement. A.M. McKenzie. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0461) 0462 Responding to user needs. J. Iseli, D. Crocker. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0462) 0463 FTP comments and response to RFC 430. A.K. Bhushan. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0463) 0464 Resource notebook framework. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0464) 0465 Not Issued. 0466 Telnet logger/server for host LL-67. J.M. Winett. February 1973. (Format: TXT, HTML) (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, HTML) (Updated by RFC0492) (Status: UNKNOWN) (DOI: 10.17487/RFC0467) 0468 FTP data compression. R.T. Braden. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0468) 0469 Network mail meeting summary. M.D. Kudlick. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0469) 0470 Change in socket for TIP news facility. R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0470) 0471 Workshop on multi-site executive programs. R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0471) 0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925). S. Bunch. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0472) 0473 MIX and MIXAL?. D.C. Walden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0473) 0474 Announcement of NGWG meeting: Call for papers. S. Bunch. March 1973. (Format: TXT, HTML) (Updates RFC0396) (Status: UNKNOWN) (DOI: 10.17487/RFC0474) 0475 FTP and Network Mail System. A.K. Bhushan. March 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0475) 0476 IMP/TIP memory retrofit schedule (rev 2). A.M. McKenzie. March 1973. (Format: TXT, HTML) (Obsoletes RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0476) 0477 Remote Job Service at UCSB. M. Krilanovich. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0477) 0478 FTP server-server interaction - II. R.D. Bressler, R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0478) 0479 Use of FTP by the NIC Journal. J.E. White. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0479) 0480 Host-dependent FTP parameters. J.E. White. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0480) 0481 Not Issued. 0482 Traffic statistics (February 1973). A.M. McKenzie. March 1973. (Format: TXT, HTML) (Updated by RFC0497) (Status: UNKNOWN) (DOI: 10.17487/RFC0482) 0483 Cancellation of the resource notebook framework meeting. M.D. Kudlick. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0483) 0484 Not Issued. 0485 MIX and MIXAL at UCSB. J.R. Pickens. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0485) 0486 Data transfer revisited. R.D. Bressler. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0486) 0487 Free file transfer. R.D. Bressler. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0487) 0488 NLS classes at network sites. M.F. Auerbach. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0488) 0489 Comment on resynchronization of connection status proposal. J. Postel. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0489) 0490 Surrogate RJS for UCLA-CCN. J.R. Pickens. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0490) 0491 What is "Free"?. M.A. Padlipsky. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0491) 0492 Response to RFC 467. E. Meyer. April 1973. (Format: TXT, HTML) (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, PDF, HTML) (Obsoletes RFC0292) (Status: UNKNOWN) (DOI: 10.17487/RFC0493) 0494 Availability of MIX and MIXAL in the Network. D.C. Walden. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0494) 0495 Telnet Protocol specifications. A.M. McKenzie. May 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0496) 0497 Traffic Statistics (March 1973). A.M. McKenzie. April 1973. (Format: TXT, PDF, HTML) (Updates RFC0482) (Status: UNKNOWN) (DOI: 10.17487/RFC0497) 0498 On mail service to CCN. R.T. Braden. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0498) 0499 Harvard's network RJE. B.R. Reussow. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0499) 0500 Integration of data management systems on a computer network. A. Shoshani, I. Spiegler. April 1973. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0500) 0501 Un-muddling "free file transfer". K.T. Pogran. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0501) 0502 Not Issued. 0503 Socket number list. N. Neigus, J. Postel. April 1973. (Format: TXT, HTML) (Obsoletes RFC0433) (Obsoleted by RFC0739) (Status: UNKNOWN) (DOI: 10.17487/RFC0503) 0504 Distributed resources workshop announcement. R. Thomas. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0504) 0505 Two solutions to a file transfer access problem. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0505) 0506 FTP command naming problem. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0508) 0509 Traffic statistics (April 1973). A.M. McKenzie. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0509) 0510 Request for network mailbox addresses. J.E. White. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0510) 0511 Enterprise phone service to NIC from ARPANET sites. J.B. North. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0511) 0512 More on lost message detection. W. Hathaway. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0512) 0513 Comments on the new Telnet specifications. W. Hathaway. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0513) 0514 Network make-work. W. Kantrowitz. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0514) 0515 Specifications for Datalanguage, Version 0/9. R. Winter. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0515) 0516 Lost message detection. J. Postel. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0516) 0517 Not Issued. 0518 ARPANET accounts. N. Vaughan, E.J. Feinler. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0518) 0519 Resource Evaluation. J.R. Pickens. June 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0519) 0520 Memo to FTP group: Proposal for File Access Protocol. J.D. Day. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0520) 0521 Restricted use of IMP DDT. A.M. McKenzie. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0521) 0522 Traffic Statistics (May 1973). A.M. McKenzie. June 1973. (Format: TXT, PDF, HTML) (Updates RFC0509) (Status: UNKNOWN) (DOI: 10.17487/RFC0522) 0523 SURVEY is in operation again. A.K. Bhushan. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0523) 0524 Proposed Mail Protocol. J.E. White. June 1973. (Format: TXT, HTML) (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, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0525) 0526 Technical meeting: Digital image processing software systems. W.K. Pratt. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0526) 0527 ARPAWOCKY. R. Merryman. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0527) 0528 Software checksumming in the IMP and network reliability. J.M. McQuillan. June 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0529) 0530 Report on the Survey Project. A.K. Bhushan. June 1973. (Format: PDF, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0531) 0532 UCSD-CC Server-FTP facility. R.G. Merryman. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0532) 0533 Message-ID numbers. D.C. Walden. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0533) 0534 Lost message detection. D.C. Walden. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0534) 0535 Comments on File Access Protocol. R. Thomas. July 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0535) 0536 Not Issued. 0537 Announcement of NGG meeting July 16-17. S. Bunch. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0537) 0538 Traffic statistics (June 1973). A.M. McKenzie. July 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0539) 0540 Not Issued. 0541 Not Issued. 0542 File Transfer Protocol. N. Neigus. August 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0543) 0544 Locating on-line documentation at SRI-ARC. N.D. Meyer, K. Kelley. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0544) 0545 Of what quality be the UCSB resources evaluators?. J.R. Pickens. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0545) 0546 Tenex load averages for July 1973. R. Thomas. August 1973. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0546) 0547 Change to the Very Distant Host specification. D.C. Walden. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0547) 0548 Hosts using the IMP Going Down message. D.C. Walden. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0548) 0549 Minutes of Network Graphics Group meeting, 15-17 July 1973. J.C. Michener. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0549) 0550 NIC NCP experiment. L.P. Deutsch. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0550) 0551 NYU, ANL, and LBL Joining the Net. Y. Feinroth, R. Fink. August 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0551) 0552 Single access to standard protocols. A.D. Owen. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0552) 0553 Draft design for a text/graphics protocol. C.H. Irby, K. Victor. July 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0555) 0556 Traffic Statistics (July 1973). A.M. McKenzie. August 1973. (Format: TXT, PDF, HTML) (Updates RFC0538) (Status: UNKNOWN) (DOI: 10.17487/RFC0556) 0557 REVELATIONS IN NETWORK HOST MEASUREMENTS. B.D. Wessler. August 1973. (Format: TXT, PDF, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0559) 0560 Remote Controlled Transmission and Echoing Telnet option. D. Crocker, J. Postel. August 1973. (Format: TXT, PDF, HTML) (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, HTML) (Updated by RFC0680) (Status: UNKNOWN) (DOI: 10.17487/RFC0561) 0562 Modifications to the TELNET Specification. A.M. McKenzie. August 1973. (Format: TXT, PDF, HTML) (Updates RFC0495) (Status: UNKNOWN) (DOI: 10.17487/RFC0562) 0563 Comments on the RCTE Telnet option. J. Davidson. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0563) 0564 Not Issued. 0565 Storing network survey data at the datacomputer. D. Cantor. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0565) 0566 Traffic statistics (August 1973). A.M. McKenzie. September 1973. (Format: TXT, HTML) (Updated by RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0566) 0567 Cross Country Network Bandwidth. L.P. Deutsch. September 1973. (Format: TXT, HTML) (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, HTML) (Updates RFC0567) (Status: UNKNOWN) (DOI: 10.17487/RFC0568) 0569 NETED: A Common Editor for the ARPA Network. M.A. Padlipsky. October 1973. (Format: TXT, HTML) (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, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0570) 0571 TENEX FTP PROBLEM. R. Braden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0571) 0572 Not Issued. 0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS. A. Bhushan. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0573) 0574 Announcement of a Mail Facility at UCSB. M. Krilanovich. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0574) 0575 Not Issued. 0576 Proposal for modifying linking. K. Victor. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0576) 0577 Mail priority. D. Crocker. October 1973. (Format: TXT, PDF, HTML) (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, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0578) 0579 Traffic statistics (September 1973). A.M. McKenzie. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0566) (Updated by RFC0586) (Status: UNKNOWN) (DOI: 10.17487/RFC0579) 0580 Note to Protocol Designers and Implementers. J. Postel. October 1973. (Format: TXT, HTML) (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, PDF, HTML) (Updates RFC0560) (Status: UNKNOWN) (DOI: 10.17487/RFC0581) 0582 Comments on RFC 580: Machine readable protocols. R. Clements. November 1973. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0585) 0586 Traffic statistics (October 1973). A.M. McKenzie. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0586) 0587 Announcing New Telnet Options. J. Postel. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0587) 0588 London Node Is Now Up. A. Stokes. October 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0588) 0589 CCN NETRJS server messages to remote user. R.T. Braden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0589) 0590 MULTICS address change. M.A. Padlipsky. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0590) 0591 Addition to the Very Distant Host specifications. D.C. Walden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0591) 0592 Some thoughts on system design to facilitate resource sharing. R.W. Watson. November 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0592) 0593 Telnet and FTP implementation schedule change. A.M. McKenzie, J. Postel. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0593) 0594 Speedup of Host-IMP interface. J.D. Burchfiel. December 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0594) 0595 Second thoughts in defense of the Telnet Go-Ahead. W. Hathaway. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0595) 0596 Second thoughts on Telnet Go-Ahead. E.A. Taft. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0596) 0597 Host status. N. Neigus, E.J. Feinler. December 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0598) 0599 Update on NETRJS. R.T. Braden. December 1973. (Format: TXT, HTML) (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, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0600) 0601 Traffic statistics (November 1973). A.M. McKenzie. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0601) 0602 "The stockings were hung by the chimney with care". R.M. Metcalfe. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0602) 0603 Response to RFC 597: Host status. J.D. Burchfiel. December 1973. (Format: TXT, HTML) (Updates RFC0597) (Updated by RFC0613) (Status: UNKNOWN) (DOI: 10.17487/RFC0603) 0604 Assigned link numbers. J. Postel. December 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0606) 0607 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg. January 1974. (Format: TXT, HTML) (Obsoleted by RFC0624) (Updated by RFC0614) (Status: UNKNOWN) (DOI: 10.17487/RFC0607) 0608 Host names on-line. M.D. Kudlick. January 1974. (Format: TXT, HTML) (Obsoleted by RFC0810) (Status: UNKNOWN) (DOI: 10.17487/RFC0608) 0609 Statement of upcoming move of NIC/NLS service. B. Ferguson. January 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0609) 0610 Further datalanguage design concepts. R. Winter, J. Hill, W. Greiff. December 1973. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0611) 0612 Traffic statistics (December 1973). A.M. McKenzie. January 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0612) 0613 Network connectivity: A response to RFC 603. A.M. McKenzie. January 1974. (Format: TXT, HTML) (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, HTML) (Updates RFC0542, RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0614) 0615 Proposed Network Standard Data Pathname syntax. D. Crocker. March 1974. (Format: TXT, HTML) (Obsoleted by RFC0645) (Status: UNKNOWN) (DOI: 10.17487/RFC0615) 0616 LATEST NETWORK MAPS. D. Walden. February 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0616) 0617 Note on socket number assignment. E.A. Taft. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0617) 0618 Few observations on NCP statistics. E.A. Taft. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0618) 0619 Mean round-trip times in the ARPANET. W. Naylor, H. Opderbeck. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0619) 0620 Request for monitor host table updates. B. Ferguson. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0620) 0621 NIC user directories at SRI ARC. M.D. Kudlick. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0621) 0622 Scheduling IMP/TIP down time. A.M. McKenzie. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0622) 0623 Comments on on-line host name service. M. Krilanovich. February 1974. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0624) 0625 On-line hostnames service. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0626) 0627 ASCII text file of hostnames. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0628) 0629 Scenario for using the Network Journal. J.B. North. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0629) 0630 FTP error code usage for more reliable mail service. J. Sussman. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0630) 0631 International meeting on minicomputers and data communication: Call for papers. A. Danthine. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0631) 0632 Throughput degradations for single packet messages. H. Opderbeck. May 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0632) 0633 IMP/TIP preventive maintenance schedule. A.M. McKenzie. March 1974. (Format: TXT, HTML) (Obsoleted by RFC0638) (Status: UNKNOWN) (DOI: 10.17487/RFC0633) 0634 Change in network address for Haskins Lab. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0634) 0635 Assessment of ARPANET protocols. V. Cerf. April 1974. (Format: TXT, PDF, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0636) 0637 Change of network address for SU-DSL. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0637) 0638 IMP/TIP preventive maintenance schedule. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Obsoletes RFC0633) (Status: UNKNOWN) (DOI: 10.17487/RFC0638) 0639 Not Issued. 0640 Revised FTP reply codes. J. Postel. June 1974. (Format: TXT, HTML) (Updates RFC0542) (Status: UNKNOWN) (DOI: 10.17487/RFC0640) 0641 Not Issued. 0642 Ready line philosophy and implementation. J.D. Burchfiel. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0642) 0643 Network Debugging Protocol. E. Mader. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0643) 0644 On the problem of signature authentication for network mail. R. Thomas. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0644) 0645 Network Standard Data Specification syntax. D. Crocker. June 1974. (Format: TXT, PDF, HTML) (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, PDF, HTML) (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, HTML) (Obsoleted by RFC0859) (Status: UNKNOWN) (DOI: 10.17487/RFC0651) 0652 Telnet output carriage-return disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0652) 0653 Telnet output horizontal tabstops option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0653) 0654 Telnet output horizontal tab disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0654) 0655 Telnet output formfeed disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0655) 0656 Telnet output vertical tabstops option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0656) 0657 Telnet output vertical tab disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0657) 0658 Telnet output linefeed disposition. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0658) 0659 Announcing additional Telnet options. J. Postel. October 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0659) 0660 Some changes to the IMP and the IMP/Host interface. D.C. Walden. October 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0660) 0661 Protocol information. J. Postel. November 1974. (Format: TXT, PDF, HTML) (Updated by RFC0694) (Status: UNKNOWN) (DOI: 10.17487/RFC0661) 0662 Performance improvement in ARPANET file transfers from Multics. R. Kanodia. November 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0662) 0663 Lost message detection and recovery protocol. R. Kanodia. November 1974. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0666) 0667 Host Ports. S.G. Chipman. December 1974. (Format: TXT, PDF, HTML) (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, PDF, HTML) (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, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0671) 0672 Multi-site data collection facility. R. Schantz. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0672) 0673 Not Issued. 0674 Procedure call documents: Version 2. J. Postel, J.E. White. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0674) 0675 Specification of Internet Transmission Control Program. V. Cerf, Y. Dalal, C. Sunshine. December 1974. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0677) 0678 Standard file formats. J. Postel. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0678) 0679 February, 1975, survey of New-Protocol Telnet servers. D.W. Dodds. February 1975. (Format: TXT, PDF, HTML) (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, HTML) (Updates RFC0561) (Status: UNKNOWN) (DOI: 10.17487/RFC0680) 0681 Network UNIX. S. Holmgren. March 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0681) 0682 Not Issued. 0683 FTPSRV - Tenex extension for paged files. R. Clements. April 1975. (Format: TXT, HTML) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0683) 0684 Commentary on procedure calling as a network protocol. R. Schantz. April 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0684) 0685 Response time in cross network debugging. M. Beeler. April 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0685) 0686 Leaving well enough alone. B. Harvey. May 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0686) 0687 IMP/Host and Host/IMP Protocol changes. D.C. Walden. June 1975. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0688) 0689 Tenex NCP finite state machine for connections. R. Clements. May 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0689) 0690 Comments on the proposed Host/IMP Protocol changes. J. Postel. June 1975. (Format: TXT, HTML) (Updates RFC0687) (Updated by RFC0692) (Status: UNKNOWN) (DOI: 10.17487/RFC0690) 0691 One more try on the FTP. B. Harvey. June 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0691) 0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690). S.M. Wolfe. June 1975. (Format: TXT, HTML) (Updates RFC0690) (Status: UNKNOWN) (DOI: 10.17487/RFC0692) 0693 Not Issued. 0694 Protocol information. J. Postel. June 1975. (Format: TXT, PDF, HTML) (Updates RFC0661) (Status: UNKNOWN) (DOI: 10.17487/RFC0694) 0695 Official change in Host-Host Protocol. M. Krilanovich. July 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0695) 0696 Comments on the IMP/Host and Host/IMP Protocol changes. V.G. Cerf. July 1975. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0696) 0697 CWD command of FTP. J. Lieb. July 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0697) 0698 Telnet extended ASCII option. T. Mock. July 1975. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0699) 0700 Protocol experiment. E. Mader, W.W. Plummer, R.S. Tomlinson. August 1974. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0700) 0701 August, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. August 1974. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC0679) (Status: UNKNOWN) (DOI: 10.17487/RFC0703) 0704 IMP/Host and Host/IMP Protocol change. P.J. Santos. September 1975. (Format: TXT, HTML) (Obsoletes RFC0687) (Status: UNKNOWN) (DOI: 10.17487/RFC0704) 0705 Front-end Protocol B6700 version. R.F. Bryan. November 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0705) 0706 On the junk mail problem. J. Postel. November 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0706) 0707 High-level framework for network-based resource sharing. J.E. White. December 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0707) 0708 Elements of a Distributed Programming System. J.E. White. January 1976. (Format: TXT, HTML) (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, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0712) 0713 MSDTP-Message Services Data Transmission Protocol. J. Haverty. April 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0713) 0714 Host-Host Protocol for an ARPANET-Type Network. A.M. McKenzie. April 1976. (Format: TXT, PDF, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0716) 0717 Assigned Network Numbers. J. Postel. July 1976. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0717) 0718 Comments on RCTE from the Tenex Implementation Experience. J. Postel. June 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0718) 0719 Discussion on RCTE. J. Postel. July 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0719) 0720 Address Specification Syntax for Network Mail. D. Crocker. August 1976. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0721) 0722 Thoughts on Interactions in Distributed Services. J. Haverty. September 1976. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0725) 0726 Remote Controlled Transmission and Echoing Telnet option. J. Postel, D. Crocker. March 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0726) 0727 Telnet logout option. M.R. Crispin. April 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0727) 0728 Minor pitfall in the Telnet Protocol. J.D. Day. April 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0728) 0729 Telnet byte macro option. D. Crocker. May 1977. (Format: TXT, HTML) (Obsoleted by RFC0735) (Status: UNKNOWN) (DOI: 10.17487/RFC0729) 0730 Extensible field addressing. J. Postel. May 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0730) 0731 Telnet Data Entry Terminal option. J.D. Day. June 1977. (Format: TXT, HTML) (Obsoleted by RFC0732) (Status: UNKNOWN) (DOI: 10.17487/RFC0731) 0732 Telnet Data Entry Terminal option. J.D. Day. September 1977. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0724) (Obsoleted by RFC0822) (Status: UNKNOWN) (DOI: 10.17487/RFC0733) 0734 SUPDUP Protocol. M.R. Crispin. October 1977. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0734) 0735 Revised Telnet byte macro option. D. Crocker, R.H. Gumpertz. November 1977. (Format: TXT, HTML) (Obsoletes RFC0729) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0735) 0736 Telnet SUPDUP option. M.R. Crispin. October 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0736) 0737 FTP extension: XSEN. K. Harrenstien. October 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0737) 0738 Time server. K. Harrenstien. October 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0738) 0739 Assigned numbers. J. Postel. November 1977. (Format: TXT, HTML) (Obsoletes RFC0604, RFC0503) (Obsoleted by RFC0750) (Status: HISTORIC) (DOI: 10.17487/RFC0739) 0740 NETRJS Protocol. R.T. Braden. November 1977. (Format: TXT, HTML) (Obsoletes RFC0599) (Status: HISTORIC) (DOI: 10.17487/RFC0740) 0741 Specifications for the Network Voice Protocol (NVP). D. Cohen. November 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0741) 0742 NAME/FINGER Protocol. K. Harrenstien. December 1977. (Format: TXT, HTML) (Obsoleted by RFC1288, RFC1196, RFC1194) (Status: UNKNOWN) (DOI: 10.17487/RFC0742) 0743 FTP extension: XRSQ/XRCP. K. Harrenstien. December 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0743) 0744 MARS - a Message Archiving and Retrieval Service. J. Sattley. January 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0744) 0745 JANUS interface specifications. M. Beeler. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0745) 0746 SUPDUP graphics extension. R. Stallman. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0746) 0747 Recent extensions to the SUPDUP Protocol. M.R. Crispin. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0747) 0748 Telnet randomly-lose option. M.R. Crispin. 1 April 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0748) 0749 Telnet SUPDUP-Output option. B. Greenberg. September 1978. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0749) 0750 Assigned numbers. J. Postel. September 1978. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0751) 0752 Universal host table. M.R. Crispin. January 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0752) 0753 Internet Message Protocol. J. Postel. March 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0753) 0754 Out-of-net host addresses for mail. J. Postel. April 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0754) 0755 Assigned numbers. J. Postel. May 1979. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0757) 0758 Assigned numbers. J. Postel. August 1979. (Format: TXT, HTML) (Obsoletes RFC0755) (Obsoleted by RFC0762) (Status: HISTORIC) (DOI: 10.17487/RFC0758) 0759 Internet Message Protocol. J. Postel. August 1980. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0759) 0760 DoD standard Internet Protocol. J. Postel. January 1980. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC0793, RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0761) 0762 Assigned numbers. J. Postel. January 1980. (Format: TXT, HTML) (Obsoletes RFC0758) (Obsoleted by RFC0770) (Status: HISTORIC) (DOI: 10.17487/RFC0762) 0763 Role mailboxes. M.D. Abrams. May 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0763) 0764 Telnet Protocol specification. J. Postel. June 1980. (Format: TXT, HTML) (Obsoleted by RFC0854) (Status: UNKNOWN) (DOI: 10.17487/RFC0764) 0765 File Transfer Protocol specification. J. Postel. June 1980. (Format: TXT, HTML) (Obsoletes RFC0542) (Obsoleted by RFC0959) (Status: UNKNOWN) (DOI: 10.17487/RFC0765) 0766 Internet Protocol Handbook: Table of contents. J. Postel. July 1980. (Format: TXT, HTML) (Obsoleted by RFC0774) (Status: UNKNOWN) (DOI: 10.17487/RFC0766) 0767 Structured format for transmission of multi-media documents. J. Postel. August 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0767) 0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT, HTML) (Also STD0006) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0768) 0769 Rapicom 450 facsimile file format. J. Postel. September 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0769) 0770 Assigned numbers. J. Postel. September 1980. (Format: TXT, HTML) (Obsoletes RFC0762) (Obsoleted by RFC0776) (Status: HISTORIC) (DOI: 10.17487/RFC0770) 0771 Mail transition plan. V.G. Cerf, J. Postel. September 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0771) 0772 Mail Transfer Protocol. S. Sluizer, J. Postel. September 1980. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0773) 0774 Internet Protocol Handbook: Table of contents. J. Postel. October 1980. (Format: TXT, HTML) (Obsoletes RFC0766) (Status: UNKNOWN) (DOI: 10.17487/RFC0774) 0775 Directory oriented FTP commands. D. Mankins, D. Franklin, A.D. Owen. December 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0775) 0776 Assigned numbers. J. Postel. January 1981. (Format: TXT, HTML) (Obsoletes RFC0770) (Obsoleted by RFC0790) (Status: HISTORIC) (DOI: 10.17487/RFC0776) 0777 Internet Control Message Protocol. J. Postel. April 1981. (Format: TXT, HTML) (Obsoleted by RFC0792) (Updates RFC0760) (Status: UNKNOWN) (DOI: 10.17487/RFC0777) 0778 DCNET Internet Clock Service. D.L. Mills. April 1981. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0778) 0779 Telnet send-location option. E. Killian. April 1981. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0779) 0780 Mail Transfer Protocol. S. Sluizer, J. Postel. May 1981. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0781) 0782 Virtual Terminal management model. J. Nabielsky, A.P. Skelton. January 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0782) 0783 TFTP Protocol (revision 2). K.R. Sollins. June 1981. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0784) 0785 Mail Transfer Protocol: ISI TOPS20 file definitions. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0785) 0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0786) 0787 Connectionless data transmission survey/tutorial. A.L. Chapin. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0787) 0788 Simple Mail Transfer Protocol. J. Postel. November 1981. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0789) 0790 Assigned numbers. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0776) (Obsoleted by RFC0820) (Status: HISTORIC) (DOI: 10.17487/RFC0790) 0791 Internet Protocol. J. Postel. September 1981. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates IEN125) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0794) 0795 Service mappings. J. Postel. September 1981. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0795) 0796 Address mappings. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes IEN115) (Status: HISTORIC) (DOI: 10.17487/RFC0796) 0797 Format for Bitmap files. A.R. Katz. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0797) 0798 Decoding facsimile data from the Rapicom 450. A.R. Katz. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0798) 0799 Internet name domains. D.L. Mills. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0799) 0800 Request For Comments summary notes: 700-799. J. Postel, J. Vernon. November 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0800) 0801 NCP/TCP transition plan. J. Postel. November 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0801) 0802 ARPANET 1822L Host Access Protocol. A.G. Malis. November 1981. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0804) 0805 Computer mail meeting notes. J. Postel. February 1982. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC0841) (Status: UNKNOWN) (DOI: 10.17487/RFC0806) 0807 Multimedia mail meeting notes. J. Postel. February 1982. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0808) 0809 UCL facsimile system. T. Chang. February 1982. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC0953) (Status: UNKNOWN) (DOI: 10.17487/RFC0811) 0812 NICNAME/WHOIS. K. Harrenstien, V. White. March 1982. (Format: TXT, HTML) (Obsoleted by RFC0954, RFC3912) (Status: UNKNOWN) (DOI: 10.17487/RFC0812) 0813 Window and Acknowledgement Strategy in TCP. D.D. Clark. July 1982. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0813) 0814 Name, addresses, ports, and routes. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0814) 0815 IP datagram reassembly algorithms. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0815) 0816 Fault isolation and recovery. D.D. Clark. July 1982. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0816) 0817 Modularity and efficiency in protocol implementation. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0817) 0818 Remote User Telnet service. J. Postel. November 1982. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0818) 0819 The Domain Naming Convention for Internet User Applications. Z. Su, J. Postel. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0819) 0820 Assigned numbers. J. Postel. August 1982. (Format: TXT, HTML) (Obsoletes RFC0790) (Obsoleted by RFC0870) (Status: HISTORIC) (DOI: 10.17487/RFC0820) 0821 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates IEN109, IEN30) (Status: HISTORIC) (DOI: 10.17487/RFC0823) 0824 CRONUS Virtual Local Network. W.I. MacGregor, D.C. Tappan. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0824) 0825 Request for comments on Requests For Comments. J. Postel. November 1982. (Format: TXT, HTML) (Obsoleted by RFC1111, RFC1543, RFC2223) (Status: UNKNOWN) (DOI: 10.17487/RFC0825) 0826 An 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, HTML) (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, HTML) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0827) 0828 Data communications: IFIP's international "network" of experts. K. Owen. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0828) 0829 Packet satellite technology reference sources. V.G. Cerf. November 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0829) 0830 Distributed system for Internet name service. Z. Su. October 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0830) 0831 Backup access to the European side of SATNET. R.T. Braden. December 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0831) 0832 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoleted by RFC0833) (Status: UNKNOWN) (DOI: 10.17487/RFC0832) 0833 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0832) (Obsoleted by RFC0834) (Status: UNKNOWN) (DOI: 10.17487/RFC0833) 0834 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0833) (Obsoleted by RFC0835) (Status: UNKNOWN) (DOI: 10.17487/RFC0834) 0835 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0834) (Obsoleted by RFC0836) (Status: UNKNOWN) (DOI: 10.17487/RFC0835) 0836 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0835) (Obsoleted by RFC0837) (Status: UNKNOWN) (DOI: 10.17487/RFC0836) 0837 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0836) (Obsoleted by RFC0838) (Status: UNKNOWN) (DOI: 10.17487/RFC0837) 0838 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0837) (Obsoleted by RFC0839) (Status: UNKNOWN) (DOI: 10.17487/RFC0838) 0839 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0838) (Obsoleted by RFC0842) (Status: UNKNOWN) (DOI: 10.17487/RFC0839) 0840 Official protocols. J. Postel. April 1983. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0806) (Status: UNKNOWN) (DOI: 10.17487/RFC0841) 0842 Who talks TCP? - survey of 1 February 83. D. Smallberg. February 1983. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC0843) (Status: UNKNOWN) (DOI: 10.17487/RFC0844) 0845 Who talks TCP? - survey of 15 February 1983. D. Smallberg. February 1983. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC0846) (Status: UNKNOWN) (DOI: 10.17487/RFC0847) 0848 Who provides the "little" TCP services?. D. Smallberg. March 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0848) 0849 Suggestions for improved host table distribution. M.R. Crispin. May 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0849) 0850 Standard for interchange of USENET messages. M.R. Horton. June 1983. (Format: TXT, HTML) (Obsoleted by RFC1036) (Status: UNKNOWN) (DOI: 10.17487/RFC0850) 0851 ARPANET 1822L Host Access Protocol. A.G. Malis. April 1983. (Format: TXT, HTML) (Obsoletes RFC0802) (Obsoleted by RFC0878) (Status: UNKNOWN) (DOI: 10.17487/RFC0851) 0852 ARPANET short blocking feature. A.G. Malis. April 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0852) 0853 Not Issued. 0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds. May 1983. (Format: TXT, HTML) (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, HTML) (Obsoletes NIC18640) (Also STD0008) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0855) 0856 Telnet Binary Transmission. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC15389) (Also STD0027) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0856) 0857 Telnet Echo Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (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, HTML) (Obsoletes NIC15392) (Also STD0029) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0858) 0859 Telnet Status Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes RFC0651) (Also STD0030) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0859) 0860 Telnet Timing Mark Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (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, HTML) (Obsoletes NIC16239) (Also STD0032) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0861) 0862 Echo Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0020) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0862) 0863 Discard Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0021) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0863) 0864 Character Generator Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0022) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0864) 0865 Quote of the Day Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0023) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0865) 0866 Active users. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0024) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0866) 0867 Daytime Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0025) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0867) 0868 Time Protocol. J. Postel, K. Harrenstien. May 1983. (Format: TXT, HTML) (Also STD0026) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0868) 0869 Host Monitoring Protocol. R. Hinden. December 1983. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0869) 0870 Assigned numbers. J.K. Reynolds, J. Postel. October 1983. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0871) 0872 TCP-on-a-LAN. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0872) 0873 Illusion of vendor support. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0873) 0874 Critique of X.25. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0874) 0875 Gateways, architectures, and heffalumps. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0875) 0876 Survey of SMTP implementations. D. Smallberg. September 1983. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1356) (Status: UNKNOWN) (DOI: 10.17487/RFC0877) 0878 ARPANET 1822L Host Access Protocol. A.G. Malis. December 1983. (Format: TXT, HTML) (Obsoletes RFC0851) (Status: UNKNOWN) (DOI: 10.17487/RFC0878) 0879 The TCP Maximum Segment Size and Related Topics. J. Postel. November 1983. (Format: TXT, HTML) (Obsoleted by RFC7805) (Updated by RFC6691) (Status: HISTORIC) (DOI: 10.17487/RFC0879) 0880 Official protocols. J.K. Reynolds, J. Postel. October 1983. (Format: TXT, HTML) (Obsoletes RFC0840) (Obsoleted by RFC0901) (Status: HISTORIC) (DOI: 10.17487/RFC0880) 0881 Domain names plan and schedule. J. Postel. November 1983. (Format: TXT, HTML) (Updated by RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0881) 0882 Domain names: Concepts and facilities. P.V. Mockapetris. November 1983. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC0930) (Status: UNKNOWN) (DOI: 10.17487/RFC0884) 0885 Telnet end of record option. J. Postel. December 1983. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0885) 0886 Proposed standard for message header munging. M.T. Rose. December 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0886) 0887 Resource Location Protocol. M. Accetta. December 1983. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0887) 0888 "STUB" Exterior Gateway Protocol. L. Seamonson, E.C. Rosen. January 1984. (Format: TXT, HTML) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0888) 0889 Internet Delay Experiments. D.L. Mills. December 1983. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0889) 0890 Exterior Gateway Protocol implementation schedule. J. Postel. February 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0890) 0891 DCN Local-Network Protocols. D.L. Mills. December 1983. (Format: TXT, HTML) (Also STD0044) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0891) 0892 ISO Transport Protocol specification. International Organization for Standardization. December 1983. (Format: TXT, HTML) (Obsoleted by RFC0905) (Status: UNKNOWN) (DOI: 10.17487/RFC0892) 0893 Trailer encapsulations. S. Leffler, M.J. Karels. April 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0893) 0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks. C. Hornig. April 1984. (Format: TXT, HTML) (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, HTML) (Also STD0042) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0895) 0896 Congestion Control in IP/TCP Internetworks. J. Nagle. January 1984. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0896) 0897 Domain name system implementation schedule. J. Postel. February 1984. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0898) 0899 Request For Comments summary notes: 800-899. J. Postel, A. Westine. May 1984. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0899) 0900 Assigned Numbers. J.K. Reynolds, J. Postel. June 1984. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Also STD0038) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0903) 0904 Exterior Gateway Protocol formal specification. D.L. Mills. April 1984. (Format: TXT, HTML) (Updates RFC0827, RFC0888) (Status: HISTORIC) (DOI: 10.17487/RFC0904) 0905 ISO Transport Protocol specification ISO DP 8073. ISO. April 1984. (Format: TXT, HTML) (Obsoletes RFC0892) (Status: UNKNOWN) (DOI: 10.17487/RFC0905) 0906 Bootstrap loading using TFTP. R. Finlayson. June 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0906) 0907 Host Access Protocol specification. Bolt Beranek, Newman Laboratories. July 1984. (Format: TXT, HTML) (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, HTML) (Updated by RFC1151) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0908) 0909 Loader Debugger Protocol. C. Welles, W. Milliken. July 1984. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0909) 0910 Multimedia mail meeting notes. H.C. Forsdick. August 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0910) 0911 EGP Gateway under Berkeley UNIX 4.2. P. Kirton. August 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0911) 0912 Authentication service. M. St. Johns. September 1984. (Format: TXT, HTML) (Obsoleted by RFC0931) (Status: UNKNOWN) (DOI: 10.17487/RFC0912) 0913 Simple File Transfer Protocol. M. Lottor. September 1984. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0914) 0915 Network mail path service. M.A. Elvy, R. Nedved. December 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0915) 0916 Reliable Asynchronous Transfer Protocol (RATP). G.G. Finn. October 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0916) 0917 Internet subnets. J.C. Mogul. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0917) 0918 Post Office Protocol. J.K. Reynolds. October 1984. (Format: TXT, HTML) (Obsoleted by RFC0937) (Status: UNKNOWN) (DOI: 10.17487/RFC0918) 0919 Broadcasting Internet Datagrams. J.C. Mogul. October 1984. (Format: TXT, HTML) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0919) 0920 Domain requirements. J. Postel, J.K. Reynolds. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0920) 0921 Domain name system implementation schedule - revised. J. Postel. October 1984. (Format: TXT, HTML) (Updates RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0921) 0922 Broadcasting Internet datagrams in the presence of subnets. J.C. Mogul. October 1984. (Format: TXT, HTML) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0922) 0923 Assigned numbers. J.K. Reynolds, J. Postel. October 1984. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0901) (Obsoleted by RFC0944) (Status: UNKNOWN) (DOI: 10.17487/RFC0924) 0925 Multi-LAN address resolution. J. Postel. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0925) 0926 Protocol for providing the connectionless mode network services. International Organization for Standardization. December 1984. (Format: TXT, HTML) (Obsoleted by RFC0994) (Status: UNKNOWN) (DOI: 10.17487/RFC0926) 0927 TACACS user identification Telnet option. B.A. Anderson. December 1984. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0927) 0928 Introduction to proposed DoD standard H-FP. M.A. Padlipsky. December 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0928) 0929 Proposed Host-Front End Protocol. J. Lilienkamp, R. Mandell, M.A. Padlipsky. December 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0929) 0930 Telnet terminal type option. M. Solomon, E. Wimmers. January 1985. (Format: TXT, HTML) (Obsoletes RFC0884) (Obsoleted by RFC1091) (Status: UNKNOWN) (DOI: 10.17487/RFC0930) 0931 Authentication server. M. St. Johns. January 1985. (Format: TXT, HTML) (Obsoletes RFC0912) (Obsoleted by RFC1413) (Status: UNKNOWN) (DOI: 10.17487/RFC0931) 0932 Subnetwork addressing scheme. D.D. Clark. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0932) 0933 Output marking Telnet option. S. Silverman. January 1985. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0933) 0934 Proposed standard for message encapsulation. M.T. Rose, E.A. Stefferud. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0934) 0935 Reliable link layer protocols. J.G. Robinson. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0935) 0936 Another Internet subnet addressing scheme. M.J. Karels. February 1985. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0918) (Status: HISTORIC) (DOI: 10.17487/RFC0937) 0938 Internet Reliable Transaction Protocol functional and interface specification. T. Miller. February 1985. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0941) 0942 Transport protocols for Department of Defense data networks. National Research Council. February 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0942) 0943 Assigned numbers. J.K. Reynolds, J. Postel. April 1985. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0924) (Obsoleted by RFC0961) (Status: UNKNOWN) (DOI: 10.17487/RFC0944) 0945 DoD statement on the NRC report. J. Postel. May 1985. (Format: TXT, HTML) (Obsoleted by RFC1039) (Status: UNKNOWN) (DOI: 10.17487/RFC0945) 0946 Telnet terminal location number option. R. Nedved. May 1985. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0946) 0947 Multi-network broadcasting within the Internet. K. Lebowitz, D. Mankins. June 1985. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1042) (Status: UNKNOWN) (DOI: 10.17487/RFC0948) 0949 FTP unique-named store command. M.A. Padlipsky. July 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0949) 0950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. August 1985. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC0811) (Status: HISTORIC) (DOI: 10.17487/RFC0953) 0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0955) 0956 Algorithms for synchronizing network clocks. D.L. Mills. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0956) 0957 Experiments in network clock synchronization. D.L. Mills. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0957) 0958 Network Time Protocol (NTP). D.L. Mills. September 1985. (Format: TXT, HTML) (Obsoleted by RFC1059, RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC0958) 0959 File Transfer Protocol. J. Postel, J. Reynolds. October 1985. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC0944) (Obsoleted by RFC0991) (Status: UNKNOWN) (DOI: 10.17487/RFC0961) 0962 TCP-4 prime. M.A. Padlipsky. November 1985. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0964) 0965 Format for a graphical communication protocol. L. Aguilar. December 1985. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC0988) (Status: UNKNOWN) (DOI: 10.17487/RFC0966) 0967 All victims together. M.A. Padlipsky. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0967) 0968 Twas the night before start-up. V.G. Cerf. December 1985. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC0998) (Status: UNKNOWN) (DOI: 10.17487/RFC0969) 0970 On Packet Switches With Infinite Storage. J. Nagle. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0970) 0971 Survey of data representation standards. A.L. DeSchon. January 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0971) 0972 Password Generator Protocol. F.J. Wancho. January 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0972) 0973 Domain system changes and observations. P.V. Mockapetris. January 1986. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2821) (Also STD0010) (Status: HISTORIC) (DOI: 10.17487/RFC0974) 0975 Autonomous confederations. D.L. Mills. February 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0975) 0976 UUCP mail interchange format standard. M.R. Horton. February 1986. (Format: TXT, HTML) (Updated by RFC1137) (Status: UNKNOWN) (DOI: 10.17487/RFC0976) 0977 Network News Transfer Protocol. B. Kantor, P. Lapsley. February 1986. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0978) 0979 PSN End-to-End functional specification. A.G. Malis. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0979) 0980 Protocol document order information. O.J. Jacobsen, J. Postel. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0980) 0981 Experimental multiple-path routing algorithm. D.L. Mills. March 1986. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1069) (Status: UNKNOWN) (DOI: 10.17487/RFC0986) 0987 Mapping between X.400 and RFC 822. S.E. Kille. June 1986. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1040, RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC0989) 0990 Assigned numbers. J.K. Reynolds, J. Postel. November 1986. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0995) 0996 Statistics server. D.L. Mills. February 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0996) 0997 Internet numbers. J.K. Reynolds, J. Postel. March 1987. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0969) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0998) 0999 Requests For Comments summary notes: 900-999. A. Westine, J. Postel. April 1987. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Also STD0019) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1002) 1003 Issues in defining an equations representation standard. A.R. Katz. March 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1003) 1004 Distributed-protocol authentication scheme. D.L. Mills. April 1987. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1004) 1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP). A. Khanna, A.G. Malis. May 1987. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1007) 1008 Implementation guide for the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1008) 1009 Requirements for Internet gateways. R.T. Braden, J. Postel. June 1987. (Format: TXT, HTML) (Obsoletes RFC0985) (Obsoleted by RFC1812) (Status: HISTORIC) (DOI: 10.17487/RFC1009) 1010 Assigned numbers. J.K. Reynolds, J. Postel. May 1987. (Format: TXT, HTML) (Obsoletes RFC0990) (Obsoleted by RFC1060) (Status: HISTORIC) (DOI: 10.17487/RFC1010) 1011 Official Internet protocols. J.K. Reynolds, J. Postel. May 1987. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1012) 1013 X Window System Protocol, version 11: Alpha update April 1987. R.W. Scheifler. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1013) 1014 XDR: External Data Representation standard. Sun Microsystems. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1014) 1015 Implementation plan for interagency research Internet. B.M. Leiner. July 1987. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1017) 1018 Some comments on SQuID. A.M. McKenzie. August 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1018) 1019 Report of the Workshop on Environments for Computational Mathematics. D. Arnon. September 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1019) 1020 Internet numbers. S. Romano, M.K. Stahl. November 1987. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1021) 1022 High-level Entity Management Protocol (HEMP). C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1022) 1023 HEMS monitoring and control language. G. Trewitt, C. Partridge. October 1987. (Format: TXT, HTML) (Obsoleted by RFC1076) (Status: UNKNOWN) (DOI: 10.17487/RFC1023) 1024 HEMS variable definitions. C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1024) 1025 TCP and IP bake off. J. Postel. September 1987. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1029) 1030 On testing the NETBLT Protocol over divers networks. M.L. Lambert. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1030) 1031 MILNET name domain transition. W.D. Lazear. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1031) 1032 Domain administrators guide. M.K. Stahl. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1032) 1033 Domain Administrators Operations Guide. M. Lottor. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1033) 1034 Domain names - concepts and facilities. P.V. Mockapetris. November 1987. (Format: TXT, HTML) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4343, RFC4035, RFC4592, RFC5936, RFC8020, RFC8482) (Also STD0013) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1034) 1035 Domain names - implementation and specification. P.V. Mockapetris. November 1987. (Format: TXT, HTML) (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, RFC8482, RFC8490) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1037) 1038 Draft revised IP security option. M. St. Johns. January 1988. (Format: TXT, HTML) (Obsoleted by RFC1108) (Status: UNKNOWN) (DOI: 10.17487/RFC1038) 1039 DoD statement on Open Systems Interconnection protocols. D. Latham. January 1988. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0989) (Obsoleted by RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC1040) 1041 Telnet 3270 regime option. Y. Rekhter. January 1988. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1046) 1047 Duplicate messages and SMTP. C. Partridge. February 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1047) 1048 BOOTP vendor information extensions. P.A. Prindeville. February 1988. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1049) 1050 RPC: Remote Procedure Call Protocol specification. Sun Microsystems. April 1988. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1052) 1053 Telnet X.3 PAD option. S. Levy, T. Jacobson. April 1988. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1053) 1054 Host extensions for IP multicasting. S.E. Deering. May 1988. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC0993) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1056) 1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun Microsystems. June 1988. (Format: TXT, HTML) (Obsoletes RFC1050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1057) 1058 Routing Information Protocol. C.L. Hedrick. June 1988. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC0958) (Obsoleted by RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC1059) 1060 Assigned numbers. J.K. Reynolds, J. Postel. March 1990. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1191) (Status: UNKNOWN) (DOI: 10.17487/RFC1063) 1064 Interactive Mail Access Protocol: Version 2. M.R. Crispin. July 1988. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1070) 1071 Computing the Internet checksum. R.T. Braden, D.A. Borman, C. Partridge. September 1988. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1323, RFC2018, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1072) 1073 Telnet window size option. D. Waitzman. October 1988. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1073) 1074 NSFNET backbone SPF based Interior Gateway Protocol. J. Rekhter. October 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1074) 1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. November 1988. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1075) 1076 HEMS monitoring and control language. G. Trewitt, C. Partridge. November 1988. (Format: TXT, HTML) (Obsoletes RFC1023) (Status: UNKNOWN) (DOI: 10.17487/RFC1076) 1077 Critical issues in high bandwidth networking. B.M. Leiner. November 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1077) 1078 TCP port service Multiplexer (TCPMUX). M. Lottor. November 1988. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC1078) 1079 Telnet terminal speed option. C.L. Hedrick. December 1988. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1079) 1080 Telnet remote flow control option. C.L. Hedrick. November 1988. (Format: TXT, HTML) (Obsoleted by RFC1372) (Status: UNKNOWN) (DOI: 10.17487/RFC1080) 1081 Post Office Protocol: Version 3. M.T. Rose. November 1988. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1082) 1083 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. December 1988. (Format: TXT, HTML) (Obsoleted by RFC1100) (Status: HISTORIC) (DOI: 10.17487/RFC1083) 1084 BOOTP vendor information extensions. J.K. Reynolds. December 1988. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1086) 1087 Ethics and the Internet. Defense Advanced Research Projects Agency, Internet Activities Board. January 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1087) 1088 Standard for the transmission of IP datagrams over NetBIOS networks. L.J. McLaughlin. February 1989. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC4789) (Status: UNKNOWN) (DOI: 10.17487/RFC1089) 1090 SMTP on X.25. R. Ullmann. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1090) 1091 Telnet terminal-type option. J. VanBokkelen. February 1989. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1092) 1093 NSFNET routing architecture. H.W. Braun. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1093) 1094 NFS: Network File System Protocol specification. B. Nowicki. March 1989. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1189) (Status: UNKNOWN) (DOI: 10.17487/RFC1095) 1096 Telnet X display location option. G.A. Marcy. March 1989. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1096) 1097 Telnet subliminal-message option. B. Miller. 1 April 1989. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1099) 1100 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1989. (Format: TXT, HTML) (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, HTML) (Updates RFC1034, RFC1035) (Status: UNKNOWN) (DOI: 10.17487/RFC1101) 1102 Policy routing in Internet protocols. D.D. Clark. May 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1102) 1103 Proposed standard for the transmission of IP datagrams over FDDI Networks. D. Katz. June 1989. (Format: TXT, HTML) (Obsoleted by RFC1188) (Status: UNKNOWN) (DOI: 10.17487/RFC1103) 1104 Models of policy based routing. H.W. Braun. June 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1104) 1105 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1989. (Format: TXT, HTML) (Obsoleted by RFC1163) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1105) 1106 TCP big window and NAK options. R. Fox. June 1989. (Format: TXT, HTML) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1106) 1107 Plan for Internet directory services. K.R. Sollins. July 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1107) 1108 U.S. Department of Defense Security Options for the Internet Protocol. S. Kent. November 1991. (Format: TXT, HTML) (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, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1109) 1110 Problem with the TCP big window option. A.M. McKenzie. August 1989. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1423) (Status: HISTORIC) (DOI: 10.17487/RFC1115) 1116 Telnet Linemode option. D.A. Borman. August 1989. (Format: TXT, HTML) (Obsoleted by RFC1184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1116) 1117 Internet numbers. S. Romano, M.K. Stahl, M. Recker. August 1989. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1118) 1119 Network Time Protocol (version 2) specification and implementation. D.L. Mills. September 1989. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC0958, RFC1059) (Obsoleted by RFC1305) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1119) 1120 Internet Activities Board. V. Cerf. September 1989. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1121) 1122 Requirements for Internet Hosts - Communication Layers. R. Braden, Ed.. October 1989. (Format: TXT, HTML) (Updates RFC0793) (Updated by RFC1349, RFC4379, RFC5884, RFC6093, RFC6298, RFC6633, RFC6864, RFC8029) (Also STD0003) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1122) 1123 Requirements for Internet Hosts - Application and Support. R. Braden, Ed.. October 1989. (Format: TXT, HTML) (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, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1124) 1125 Policy requirements for inter Administrative Domain routing. D. Estrin. November 1989. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1125) 1126 Goals and functional requirements for inter-autonomous system routing. M. Little. October 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1126) 1127 Perspective on the Host Requirements RFCs. R.T. Braden. October 1989. (Format: TXT, HTML) (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, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1128) 1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. October 1989. (Format: TXT, PS, PDF, HTML) (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, HTML) (Obsoletes RFC1100) (Obsoleted by RFC1140) (Status: HISTORIC) (DOI: 10.17487/RFC1130) 1131 OSPF specification. J. Moy. October 1989. (Format: TXT, PS, PDF, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1171) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1134) 1135 Helminthiasis of the Internet. J.K. Reynolds. December 1989. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1136) 1137 Mapping between full RFC 822 and RFC 822 with restricted encoding. S. Kille. December 1989. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, PS, PDF, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1143) 1144 Compressing TCP/IP Headers for Low-Speed Serial Links. V. Jacobson. February 1990. (Format: TXT, PS, PDF, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1144) 1145 TCP alternate checksum options. J. Zweig, C. Partridge. February 1990. (Format: TXT, HTML) (Obsoleted by RFC1146, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1145) 1146 TCP alternate checksum options. J. Zweig, C. Partridge. March 1990. (Format: TXT, HTML) (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, PS, PDF, HTML) (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, HTML) (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. 1 April 1990. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1152) 1153 Digest message format. F.J. Wancho. April 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1153) 1154 Encoding header field for internet messages. D. Robinson, R. Ullmann. April 1990. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1158) 1159 Message Send Protocol. R. Nelson. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1312) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1159) 1160 Internet Activities Board. V. Cerf. May 1990. (Format: TXT, HTML) (Obsoletes RFC1120) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1160) 1161 SNMP over OSI. M.T. Rose. June 1990. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1238) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1162) 1163 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1990. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1165) 1166 Internet numbers. S. Kirkpatrick, M.K. Stahl, M. Recker. July 1990. (Format: TXT, HTML) (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, HTML) (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, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1168) 1169 Explaining the role of GOSIP. V.G. Cerf, K.L. Mills. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1169) 1170 Public key standards and licenses. R.B. Fougner. January 1991. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Also FYI0003) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1175) 1176 Interactive Mail Access Protocol: Version 2. M.R. Crispin. August 1990. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1206) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1177) 1178 Choosing a name for your computer. D. Libes. August 1990. (Format: TXT, HTML) (Also FYI0005) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1178) 1179 Line printer daemon protocol. L. McLaughlin. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1179) 1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. January 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1180) 1181 RIPE Terms of Reference. R. Blokzijl. September 1990. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1323) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1185) 1186 MD4 Message Digest Algorithm. R.L. Rivest. October 1990. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1187) 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks. D. Katz. October 1990. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1095) (Status: HISTORIC) (DOI: 10.17487/RFC1189) 1190 Experimental Internet Stream Protocol: Version 2 (ST-II). C. Topolcic. October 1990. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1063) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1191) 1192 Commercialization of the Internet summary report. B. Kahin. November 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1192) 1193 Client requirements for real-time communication services. D. Ferrari. November 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1193) 1194 Finger User Information Protocol. D.P. Zimmerman. November 1990. (Format: TXT, HTML) (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, PS, HTML) (Updated by RFC1349, RFC5302, RFC5304) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1195) 1196 Finger User Information Protocol. D.P. Zimmerman. December 1990. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1197) 1198 FYI on the X window system. R.W. Scheifler. January 1991. (Format: TXT, HTML) (Also FYI0006) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1198) 1199 Request for Comments Summary Notes: 1100-1199. J. Reynolds. December 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1199) 1200 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1991. (Format: TXT, HTML) (Obsoletes RFC1140) (Obsoleted by RFC1250) (Status: HISTORIC) (DOI: 10.17487/RFC1200) 1201 Transmitting IP traffic over ARCNET networks. D. Provan. February 1991. (Format: TXT, HTML) (Obsoletes RFC1051) (Also STD0046) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1201) 1202 Directory Assistance service. M.T. Rose. February 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1202) 1203 Interactive Mail Access Protocol: Version 3. J. Rice. February 1991. (Format: TXT, HTML) (Obsoletes RFC1064) (Status: HISTORIC) (DOI: 10.17487/RFC1203) 1204 Message Posting Protocol (MPP). S. Yeh, D. Lee. February 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1204) 1205 5250 Telnet interface. P. Chmielewski. February 1991. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also FYI0007) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1207) 1208 A Glossary of Networking Terms. O.J. Jacobsen, D.C. Lynch. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1208) 1209 The Transmission of IP Datagrams over the SMDS Service. D. Piscitello, J. Lawrence. March 1991. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1210) 1211 Problems with the maintenance of large mailing lists. A. Westine, J. Postel. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1211) 1212 Concise MIB definitions. M.T. Rose, K. McCloghrie. March 1991. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1214) 1215 Convention for defining traps for use with the SNMP. M.T. Rose. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1215) 1216 Gigabit network economics and paradigm shifts. P. Richard, P. Kynikos. 1 April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1216) 1217 Memo from the Consortium for Slow Commotion Research (CSCR). V.G. Cerf. 1 April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1217) 1218 Naming scheme for c=US. North American Directory Forum. April 1991. (Format: TXT, HTML) (Obsoleted by RFC1255, RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1218) 1219 On the assignment of subnet numbers. P.F. Tsuchiya. April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1219) 1220 Point-to-Point Protocol extensions for bridging. F. Baker. April 1991. (Format: TXT, HTML) (Obsoleted by RFC1638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1220) 1221 Host Access Protocol (HAP) specification: Version 2. W. Edmond. April 1991. (Format: TXT, HTML) (Updates RFC0907) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1221) 1222 Advancing the NSFNET routing architecture. H.W. Braun, Y. Rekhter. May 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1222) 1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel. J.M. Halpern. May 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1223) 1224 Techniques for managing asynchronously generated alerts. L. Steinberg. May 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1224) 1225 Post Office Protocol: Version 3. M.T. Rose. May 1991. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1226) 1227 SNMP MUX protocol and MIB. M.T. Rose. May 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1227) 1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface. G. Carpenter, B. Wijnen. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1592) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1228) 1229 Extensions to the generic-interface MIB. K. McCloghrie. May 1991. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1234) 1235 Coherent File Distribution Protocol. J. Ioannidis, G. Maguire. June 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1235) 1236 IP to X.121 address mapping for DDN. L. Morales, P. Hasse. June 1991. (Format: TXT, HTML) (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, PS, PDF, HTML) (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, HTML) (Obsoletes RFC1162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1238) 1239 Reassignment of experimental MIBs to standard MIBs. J.K. Reynolds. June 1991. (Format: TXT, HTML) (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, HTML) (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, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1241) 1242 Benchmarking Terminology for Network Interconnection Devices. S. Bradner. July 1991. (Format: TXT, HTML) (Updated by RFC6201) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1242) 1243 AppleTalk Management Information Base. S. Waldbusser. July 1991. (Format: TXT, HTML) (Obsoleted by RFC1742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1243) 1244 Site Security Handbook. J.P. Holbrook, J.K. Reynolds. July 1991. (Format: TXT, HTML) (Obsoleted by RFC2196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1244) 1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Also RFC1246, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1245) 1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Also RFC1245, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1246) 1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (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, HTML) (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, HTML) (Also RFC1202) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1249) 1250 IAB Official Protocol Standards. J. Postel. August 1991. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1251) 1252 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1254) 1255 A Naming Scheme for c=US. The North American Directory Forum. September 1991. (Format: TXT, HTML) (Obsoletes RFC1218) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1255) 1256 ICMP Router Discovery Messages. S. Deering, Ed.. September 1991. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1256) 1257 Isochronous applications do not require jitter-controlled networks. C. Partridge. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1257) 1258 BSD Rlogin. B. Kantor. September 1991. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1259) 1260 Not Issued. 1261 Transition of Nic Services. S. Williamson, L. Nobile. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1261) 1262 Guidelines for Internet Measurement Activities. V.G. Cerf. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1262) 1263 TCP Extensions Considered Harmful. S. O'Malley, L.L. Peterson. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1263) 1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria. R.M. Hinden. October 1991. (Format: TXT, HTML) (Obsoleted by RFC4794) (Status: HISTORIC) (DOI: 10.17487/RFC1264) 1265 BGP Protocol Analysis. Y. Rekhter. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1265) 1266 Experience with the BGP Protocol. Y. Rekhter. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1266) 1267 Border Gateway Protocol 3 (BGP-3). K. Lougheed, Y. Rekhter. October 1991. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC4273) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1269) 1270 SNMP Communications Services. F. Kastenholz. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1270) 1271 Remote Network Monitoring Management Information Base. S. Waldbusser. November 1991. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1273) 1274 The COSINE and Internet X.500 Schema. P. Barker, S. Kille. November 1991. (Format: TXT, HTML) (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, PS, PDF, HTML) (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, PS, HTML) (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, PS, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1277) 1278 A string encoding of Presentation Address. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1278) 1279 X.500 and Domains. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1279) 1280 IAB Official Protocol Standards. J. Postel. March 1992. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1281) 1282 BSD Rlogin. B. Kantor. December 1991. (Format: TXT, HTML) (Obsoletes RFC1258) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1282) 1283 SNMP over OSI. M. Rose. December 1991. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1284) 1285 FDDI Management Information Base. J. Case. January 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1287) 1288 The Finger User Information Protocol. D. Zimmerman. December 1991. (Format: TXT, HTML) (Obsoletes RFC1196, RFC1194, RFC0742) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1288) 1289 DECnet Phase IV MIB Extensions. J. Saperia. December 1991. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1402) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1290) 1291 Mid-Level Networks Potential Technical Services. V. Aggarwal. December 1991. (Format: TXT, PS, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1291) 1292 A Catalog of Available X.500 Implementations. R. Lang, R. Wright. January 1992. (Format: TXT, HTML) (Obsoleted by RFC1632) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1292) 1293 Inverse Address Resolution Protocol. T. Bradley, C. Brown. January 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1295) 1296 Internet Growth (1981-1991). M. Lottor. January 1992. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1297) 1298 SNMP over IPX. R. Wormley, S. Bostock. February 1992. (Format: TXT, HTML) (Obsoleted by RFC1420) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1298) 1299 Summary of 1200-1299. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1299) 1300 Remembrances of Things Past. S. Greenfield. February 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1300) 1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K. Marzullo. February 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1301) 1302 Building a Network Information Services Infrastructure. D. Sitzler, P. Smith, A. Marine. February 1992. (Format: TXT, HTML) (Also FYI0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1302) 1303 A Convention for Describing SNMP-based Agents. K. McCloghrie, M. Rose. February 1992. (Format: TXT, HTML) (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, HTML) (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, PDF, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1306) 1307 Dynamically Switched Link Control Protocol. J. Young, A. Nicholson. March 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also FYI0014) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1309) 1310 The Internet Standards Process. L. Chapin. March 1992. (Format: TXT, HTML) (Obsoleted by RFC1602) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1310) 1311 Introduction to the STD Notes. J. Postel. March 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1311) 1312 Message Send Protocol 2. R. Nelson, G. Arnold. April 1992. (Format: TXT, HTML) (Obsoletes RFC1159) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1312) 1313 Today's Programming for KRFC AM 1313 Internet Talk Radio. C. Partridge. 1 April 1992. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1314) 1315 Management Information Base for Frame Relay DTEs. C. Brown, F. Baker, C. Carvalho. April 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1318) 1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992. (Format: TXT, HTML) (Obsoleted by RFC6149) (Status: HISTORIC) (DOI: 10.17487/RFC1319) 1320 The MD4 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT, HTML) (Obsoletes RFC1186) (Obsoleted by RFC6150) (Status: HISTORIC) (DOI: 10.17487/RFC1320) 1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1322) 1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1206) (Obsoleted by RFC1594) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1325) 1326 Mutual Encapsulation Considered Dangerous. P. Tsuchiya. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1326) 1327 Mapping between X.400(1988) / ISO 10021 and RFC 822. S. Hardcastle-Kille. May 1992. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1328) 1329 Thoughts on Address Resolution for Dual MAC FDDI Networks. P. Kuehn. May 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1172) (Updated by RFC3241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1332) 1333 PPP Link Quality Monitoring. W. Simpson. May 1992. (Format: TXT, HTML) (Obsoleted by RFC1989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1333) 1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1251) (Also FYI0009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1336) 1337 TIME-WAIT Assassination Hazards in TCP. R. Braden. May 1992. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1338) 1339 Remote Mail Checking Protocol. S. Dorner, P. Resnick. June 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1339) 1340 Assigned Numbers. J. Reynolds, J. Postel. July 1992. (Format: TXT, HTML) (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, PS, PDF, HTML) (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, HTML) (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, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1343) 1344 Implications of MIME for Internet Mail Gateways. N. Borenstein. June 1992. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1344) 1345 Character Mnemonics and Character Sets. K. Simonsen. June 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1345) 1346 Resource Allocation, Control, and Accounting for the Use of Network Resources. P. Jones. June 1992. (Format: TXT, HTML) (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, PS, PDF, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1347) 1348 DNS NSAP RRs. B. Manning. July 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1351) 1352 SNMP Security Protocols. J. Galvin, K. McCloghrie, J. Davin. July 1992. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1353) 1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC0877) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1356) 1357 A Format for E-mailing Bibliographic Records. D. Cohen. July 1992. (Format: TXT, HTML) (Obsoleted by RFC1807) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1357) 1358 Charter of the Internet Architecture Board (IAB). L. Chapin. August 1992. (Format: TXT, HTML) (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, HTML) (Also FYI0016) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1359) 1360 IAB Official Protocol Standards. J. Postel. September 1992. (Format: TXT, HTML) (Obsoletes RFC1280) (Obsoleted by RFC1410) (Status: HISTORIC) (DOI: 10.17487/RFC1360) 1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1362) 1363 A Proposed Flow Specification. C. Partridge. September 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1363) 1364 BGP OSPF Interaction. K. Varadhan. September 1992. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1365) 1366 Guidelines for Management of IP Address Space. E. Gerich. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1366) 1367 Schedule for IP Address Space Management Guidelines. C. Topolcic. October 1992. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1369) 1370 Applicability Statement for OSPF. Internet Architecture Board, L. Chapin. October 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1370) 1371 Choosing a Common IGP for the IP Internet. P. Gross. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1371) 1372 Telnet Remote Flow Control Option. C. Hedrick, D. Borman. October 1992. (Format: TXT, HTML) (Obsoletes RFC1080) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1372) 1373 Portable DUAs. T. Tignor. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1373) 1374 IP and ARP on HIPPI. J. Renwick, A. Nicholson. October 1992. (Format: TXT, HTML) (Obsoleted by RFC2834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1374) 1375 Suggestion for New Classes of IP Addresses. P. Robinson. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1375) 1376 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. November 1992. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1377) 1378 The PPP AppleTalk Control Protocol (ATCP). B. Parker. November 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1378) 1379 Extending TCP for Transactions -- Concepts. R. Braden. November 1992. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1380) 1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1381) 1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop, Ed.. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1382) 1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1383) 1384 Naming Guidelines for Directory Pilots. P. Barker, S.E. Hardcastle-Kille. January 1993. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1617, RTR0011) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1384) 1385 EIP: The Extended Internet Protocol. Z. Wang. November 1992. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1385) 1386 The US Domain. A. Cooper, J. Postel. December 1992. (Format: TXT, HTML) (Obsoleted by RFC1480) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1386) 1387 RIP Version 2 Protocol Analysis. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1721) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1387) 1388 RIP Version 2 Carrying Additional Information. G. Malkin. January 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1539) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1391) 1392 Internet Users' Glossary. G. Malkin, T. LaQuey Parker. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1392) 1393 Traceroute Using an IP Option. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1393) 1394 Relationship of Telex Answerback Codes to Internet Domains. P. Robinson. January 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1394) 1395 BOOTP Vendor Information Extensions. J. Reynolds. January 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1397) 1398 Definitions of Managed Objects for the Ethernet-Like Interface Types. F. Kastenholz. January 1993. (Format: TXT, HTML) (Obsoletes RFC1284) (Obsoleted by RFC1623) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1398) 1399 Summary of 1300-1399. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1399) 1400 Transition and Modernization of the Internet Registration Service. S. Williamson. March 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1290) (Also FYI0010) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1402) 1403 BGP OSPF Interaction. K. Varadhan. January 1993. (Format: TXT, HTML) (Obsoletes RFC1364) (Status: HISTORIC) (DOI: 10.17487/RFC1403) 1404 A Model for Common Operational Statistics. B. Stockman. January 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1233) (Obsoleted by RFC2496) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1407) 1408 Telnet Environment Option. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Updated by RFC1571) (Status: HISTORIC) (DOI: 10.17487/RFC1408) 1409 Telnet Authentication Option. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1416) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1409) 1410 IAB Official Protocol Standards. J. Postel, Ed.. March 1993. (Format: TXT, HTML) (Obsoletes RFC1360) (Obsoleted by RFC1500) (Status: HISTORIC) (DOI: 10.17487/RFC1410) 1411 Telnet Authentication: Kerberos Version 4. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1411) 1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1412) 1413 Identification Protocol. M. St. Johns. February 1993. (Format: TXT, HTML) (Obsoletes RFC0931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1413) 1414 Identification MIB. M. St. Johns, M. Rose. February 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1414) 1415 FTP-FTAM Gateway Specification. J. Mindel, R. Slaski. January 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1415) 1416 Telnet Authentication Option. D. Borman, Ed.. February 1993. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1295, RFC1255, RFC1218) (Obsoleted by RFC1758) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1417) 1418 SNMP over OSI. M. Rose. March 1993. (Format: TXT, HTML) (Obsoletes RFC1161, RFC1283) (Status: HISTORIC) (DOI: 10.17487/RFC1418) 1419 SNMP over AppleTalk. G. Minshall, M. Ritter. March 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1419) 1420 SNMP over IPX. S. Bostock. March 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1428) 1429 Listserv Distribute Protocol. E. Thomas. February 1993. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1430) 1431 DUA Metrics (OSI-DS 33 (v2)). P. Barker. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1431) 1432 Recent Internet Books. J. Quarterman. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1432) 1433 Directed ARP. J. Garrett, J. Hagan, J. Wong. March 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1433) 1434 Data Link Switching: Switch-to-Switch Protocol. R. Dixon, D. Kushi. March 1993. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1795) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1434) 1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles. March 1993. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1436) 1437 The Extension of MIME Content-Types to a New Medium. N. Borenstein, M. Linimon. 1 April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1437) 1438 Internet Engineering Task Force Statements Of Boredom (SOBs). A. Lyman Chapin, C. Huitema. 1 April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1438) 1439 The Uniqueness of Unique Identifiers. C. Finseth. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1439) 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer. R. Troth. July 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1453) 1454 Comparison of Proposals for Next Version of IP. T. Dixon. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1454) 1455 Physical Link Security Type of Service. D. Eastlake 3rd. May 1993. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1456) 1457 Security Label Framework for the Internet. R. Housley. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1457) 1458 Requirements for Multicast Protocols. R. Braudes, S. Zabele. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1458) 1459 Internet Relay Chat Protocol. J. Oikarinen, D. Reed. May 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1461) 1462 FYI on "What is the Internet?". E. Krol, E. Hoffman. May 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1465) 1466 Guidelines for Management of IP Address Space. E. Gerich. May 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1468) 1469 IP Multicast over Token-Ring Local Area Networks. T. Pusateri. June 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1474) 1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1475) 1476 RAP: Internet Route Access Protocol. R. Ullmann. June 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1476) 1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1477) 1478 An Architecture for Inter-Domain Policy Routing. M. Steenstrup. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1478) 1479 Inter-Domain Policy Routing Protocol Specification: Version 1. M. Steenstrup. July 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1479) 1480 The US Domain. A. Cooper, J. Postel. June 1993. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1481) 1482 Aggregation Support in the NSFNET Policy-Based Routing Database. M. Knopper, S. Richardson. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1482) 1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5. Juha Heinanen. July 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1779, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1485) 1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1778) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1488) 1489 Registration of a Cyrillic Character Set. A. Chernov. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1489) 1490 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. Brown, A. Malis. July 1993. (Format: TXT, HTML) (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, HTML) (Also FYI0021) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1491) 1492 An Access Control Protocol, Sometimes Called TACACS. C. Finseth. July 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1496) 1497 BOOTP Vendor Information Extensions. J. Reynolds. August 1993. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1498) 1499 Summary of 1400-1499. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1499) 1500 Internet Official Protocol Standards. J. Postel. August 1993. (Format: TXT, HTML) (Obsoletes RFC1410) (Obsoleted by RFC1540) (Status: HISTORIC) (DOI: 10.17487/RFC1500) 1501 OS/2 User Group. E. Brunsen. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1501) 1502 X.400 Use of Extended Character Sets. H. Alvestrand. August 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1502) 1503 Algorithms for Automating Administration in SNMPv2 Managers. K. McCloghrie, M. Rose. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1503) 1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing. A. Oppenheimer. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1504) 1505 Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. Ullmann. August 1993. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1506) 1507 DASS - Distributed Authentication Security Service. C. Kaufman. September 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1507) 1508 Generic Security Service Application Program Interface. J. Linn. September 1993. (Format: TXT, HTML) (Obsoleted by RFC2078) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1508) 1509 Generic Security Service API : C-bindings. J. Wray. September 1993. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC4120, RFC6649) (Status: HISTORIC) (DOI: 10.17487/RFC1510) 1511 Common Authentication Technology Overview. J. Linn. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1511) 1512 FDDI Management Information Base. J. Case, A. Rijsinghani. September 1993. (Format: TXT, HTML) (Updates RFC1285) (Status: HISTORIC) (DOI: 10.17487/RFC1512) 1513 Token Ring Extensions to the Remote Network Monitoring MIB. S. Waldbusser. September 1993. (Format: TXT, HTML) (Updates RFC1271) (Status: HISTORIC) (DOI: 10.17487/RFC1513) 1514 Host Resources MIB. P. Grillo, S. Waldbusser. September 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1517) 1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, T. Li. September 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, PS, PDF, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1286) (Status: HISTORIC) (DOI: 10.17487/RFC1525) 1526 Assignment of System Identifiers for TUBA/CLNP Hosts. D. Piscitello. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1526) 1527 What Should We Plan Given the Dilemma of the Network?. G. Cook. September 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1530) 1531 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT, HTML) (Obsoleted by RFC1541) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1531) 1532 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1536) 1537 Common DNS Data File Configuration Errors. P. Beertema. October 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1391) (Obsoleted by RFC1718) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1539) 1540 Internet Official Protocol Standards. J. Postel. October 1993. (Format: TXT, HTML) (Obsoletes RFC1500) (Obsoleted by RFC1600) (Status: HISTORIC) (DOI: 10.17487/RFC1540) 1541 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1532) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1542) 1543 Instructions to RFC Authors. J. Postel. October 1993. (Format: TXT, HTML) (Obsoletes RFC1111, RFC0825) (Obsoleted by RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1543) 1544 The Content-MD5 Header Field. M. Rose. November 1993. (Format: TXT, HTML) (Obsoleted by RFC1864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1544) 1545 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. November 1993. (Format: TXT, HTML) (Obsoleted by RFC1639) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1545) 1546 Host Anycasting Service. C. Partridge, T. Mendez, W. Milliken. November 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1546) 1547 Requirements for an Internet Standard Point-to-Point Protocol. D. Perkins. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1547) 1548 The Point-to-Point Protocol (PPP). W. Simpson. December 1993. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1550) 1551 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1551) 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP). W. Simpson. December 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1552) 1553 Compressing IPX Headers Over WAN Media (CIPX). S. Mathur, M. Lewis. December 1993. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1554) 1555 Hebrew Character Encoding for Internet Messages. H. Nussbacher, Y. Bourvine. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1555) 1556 Handling of Bi-directional Texts in MIME. H. Nussbacher. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1556) 1557 Korean Character Encoding for Internet Messages. U. Choi, K. Chon, H. Park. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1557) 1558 A String Representation of LDAP Search Filters. T. Howes. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1960) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1558) 1559 DECnet Phase IV MIB Extensions. J. Saperia. December 1993. (Format: TXT, HTML) (Obsoletes RFC1289) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1559) 1560 The MultiProtocol Internet. B. Leiner, Y. Rekhter. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1560) 1561 Use of ISO CLNP in TUBA Environments. D. Piscitello. December 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1561) 1562 Naming Guidelines for the AARNet X.500 Directory Service. G. Michaelson, M. Prior. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1562) 1563 The text/enriched MIME Content-type. N. Borenstein. January 1994. (Format: TXT, PS, PDF, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1564) 1565 Network Services Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1565) 1566 Mail Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2605) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1567) 1568 Simple Network Paging Protocol - Version 1(b). A. Gwinn. January 1994. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1703) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1569) 1570 PPP LCP Extensions. W. Simpson, Ed.. January 1994. (Format: TXT, HTML) (Updates RFC1548) (Updated by RFC2484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1570) 1571 Telnet Environment Option Interoperability Issues. D. Borman. January 1994. (Format: TXT, HTML) (Updates RFC1408) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1571) 1572 Telnet Environment Option. S. Alexander, Ed.. January 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1572) 1573 Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F. Kastenholz. January 1994. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1574) 1575 An Echo Function for CLNP (ISO 8473). S. Hares, C. Wittbrodt. February 1994. (Format: TXT, HTML) (Obsoletes RFC1139) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1575) 1576 TN3270 Current Practices. J. Penner. January 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1576) 1577 Classical IP and ARP over ATM. M. Laubach. January 1994. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1941) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1578) 1579 Firewall-Friendly FTP. S. Bellovin. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1579) 1580 Guide to Network Resource Tools. EARN Staff. March 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1581) 1582 Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1582) 1583 OSPF Version 2. J. Moy. March 1994. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1247) (Obsoleted by RFC2178) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1583) 1584 Multicast Extensions to OSPF. J. Moy. March 1994. (Format: TXT, PS, PDF, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1584) 1585 MOSPF: Analysis and Experience. J. Moy. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1585) 1586 Guidelines for Running OSPF Over Frame Relay Networks. O. deSouza, M. Rodrigues. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1586) 1587 The OSPF NSSA Option. R. Coltun, V. Fuller. March 1994. (Format: TXT, HTML) (Obsoleted by RFC3101) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1587) 1588 White Pages Meeting Report. J. Postel, C. Anderson. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1588) 1589 A Kernel Model for Precision Timekeeping. D. Mills. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1589) 1590 Media Type Registration Procedure. J. Postel. March 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1228) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1592) 1593 SNA APPN Node MIB. W. McKenzie, J. Cheng. March 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1597) 1598 PPP in X.25. W. Simpson. March 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1598) 1599 Summary of 1500-1599. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1599) 1600 Internet Official Protocol Standards. J. Postel. March 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1596) (Obsoleted by RFC2954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1604) 1605 SONET to Sonnet Translation. W. Shakespeare. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1605) 1606 A Historical Perspective On The Usage Of IP Version 9. J. Onions. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1606) 1607 A VIEW FROM THE 21ST CENTURY. V. Cerf. 1 April 1994. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1608) 1609 Charting Networks in the X.500 Directory. G. Mansfield, T. Johannsen, M. Knopper. March 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1609) 1610 Internet Official Protocol Standards. J. Postel. July 1994. (Format: TXT, HTML) (Obsoletes RFC1600) (Obsoleted by RFC1720) (Status: HISTORIC) (DOI: 10.17487/RFC1610) 1611 DNS Server MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1611) 1612 DNS Resolver MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1613) 1614 Network Access to Multimedia Information. C. Adie. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1614) 1615 Migrating from X.400(84) to X.400(88). J. Houttuin, J. Craigie. May 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1384) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1617) 1618 PPP over ISDN. W. Simpson. May 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1618) 1619 PPP over SONET/SDH. W. Simpson. May 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1620) 1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1621) 1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1622) 1623 Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. May 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1625) 1626 Default IP MTU for use over ATM AAL5. R. Atkinson. May 1994. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1627) 1628 UPS Management Information Base. J. Case, Ed.. May 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1630) 1631 The IP Network Address Translator (NAT). K. Egevang, P. Francis. May 1994. (Format: TXT, HTML) (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, HTML) (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, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1633) 1634 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. May 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1636) 1637 DNS NSAP Resource Records. B. Manning, R. Colella. June 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1640) 1641 Using Unicode with MIME. D. Goldsmith, M. Davis. July 1994. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1641) 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode. D. Goldsmith, M. Davis. July 1994. (Format: TXT, PS, PDF, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC6247) (Updates RFC1379) (Status: HISTORIC) (DOI: 10.17487/RFC1644) 1645 Simple Network Paging Protocol - Version 2. A. Gwinn. July 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1646) 1647 TN3270 Enhancements. B. Kelly. July 1994. (Format: TXT, HTML) (Obsoleted by RFC2355) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1647) 1648 Postmaster Convention for X.400 Operations. A. Cargille. July 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1318) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1660) 1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1549) (Also STD0051) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1662) 1663 PPP Reliable Transmission. D. Rand. July 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1667) 1668 Unified Routing Requirements for IPng. D. Estrin, T. Li, Y. Rekhter. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1668) 1669 Market Viability as a IPng Criteria. J. Curran. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1669) 1670 Input to IPng Engineering Considerations. D. Heagerty. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1670) 1671 IPng White Paper on Transition and Other Considerations. B. Carpenter. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1671) 1672 Accounting Requirements for IPng. N. Brownlee. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1672) 1673 Electric Power Research Institute Comments on IPng. R. Skelton. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1673) 1674 A Cellular Industry View of IPng. M. Taylor. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1674) 1675 Security Concerns for IPng. S. Bellovin. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1675) 1676 INFN Requirements for an IPng. A. Ghiselli, D. Salomoni, C. Vistoli. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1676) 1677 Tactical Radio Frequency Communication Requirements for IPng. B. Adamson. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1677) 1678 IPng Requirements of Large Corporate Networks. E. Britton, J. Tavs. August 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1679) 1680 IPng Support for ATM Services. C. Brazdziunas. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1680) 1681 On Many Addresses per Host. S. Bellovin. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1681) 1682 IPng BSD Host Implementation Analysis. J. Bound. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1682) 1683 Multiprotocol Interoperability In IPng. R. Clark, M. Ammar, K. Calvert. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1683) 1684 Introduction to White Pages Services based on X.500. P. Jurg. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1684) 1685 Writing X.400 O/R Names. H. Alvestrand. August 1994. (Format: TXT, HTML) (Also RTR0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1685) 1686 IPng Requirements: A Cable Television Industry Viewpoint. M. Vecchi. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1686) 1687 A Large Corporate User's View of IPng. E. Fleischman. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1687) 1688 IPng Mobility Considerations. W. Simpson. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1688) 1689 A Status Report on Networked Information Retrieval: Tools and Groups. J. Foster, Ed.. August 1994. (Format: TXT, HTML) (Also FYI0025) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1689) 1690 Introducing the Internet Engineering and Planning Group (IEPG). G. Huston. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1690) 1691 The Document Architecture for the Cornell Digital Library. W. Turner. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1691) 1692 Transport Multiplexing Protocol (TMux). P. Cameron, D. Crocker, D. Cohen, J. Postel. August 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1692) 1693 An Extension to TCP : Partial Order Service. T. Connolly, P. Amer, P. Conrad. November 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1698) 1699 Summary of 1600-1699. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1699) 1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1569) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1703) 1704 On Internet Authentication. N. Haller, R. Atkinson. October 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1705) 1706 DNS NSAP Resource Records. B. Manning, R. Colella. October 1994. (Format: TXT, HTML) (Obsoletes RFC1637) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1706) 1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. Ullmann. October 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1707) 1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3. D. Gowin. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1708) 1709 K-12 Internetworking Guidelines. J. Gargano, D. Wasley. November 1994. (Format: TXT, PS, PDF, HTML) (Also FYI0026) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1709) 1710 Simple Internet Protocol Plus White Paper. R. Hinden. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1710) 1711 Classifications in E-mail Routing. J. Houttuin. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1711) 1712 DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. Pleitner, D. Baldoni. November 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1712) 1713 Tools for DNS debugging. A. Romao. November 1994. (Format: TXT, HTML) (Also FYI0027) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1713) 1714 Referral Whois Protocol (RWhois). S. Williamson, M. Kosters. November 1994. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC2167) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1714) 1715 The H Ratio for Address Assignment Efficiency. C. Huitema. November 1994. (Format: TXT, HTML) (Updated by RFC3194) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1715) 1716 Towards Requirements for IP Routers. P. Almquist, F. Kastenholz. November 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1539) (Obsoleted by RFC3160) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1718) 1719 A Direction for IPng. P. Gross. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1719) 1720 Internet Official Protocol Standards. J. Postel. November 1994. (Format: TXT, HTML) (Obsoletes RFC1610) (Obsoleted by RFC1780) (Status: HISTORIC) (DOI: 10.17487/RFC1720) 1721 RIP Version 2 Protocol Analysis. G. Malkin. November 1994. (Format: TXT, HTML) (Obsoletes RFC1387) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1721) 1722 RIP Version 2 Protocol Applicability Statement. G. Malkin. November 1994. (Format: TXT, HTML) (Also STD0057) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1722) 1723 RIP Version 2 - Carrying Additional Information. G. Malkin. November 1994. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1389) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1724) 1725 Post Office Protocol - Version 3. J. Myers, M. Rose. November 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1726) 1727 A Vision of an Integrated Internet Information Service. C. Weider, P. Deutsch. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1727) 1728 Resource Transponders. C. Weider. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1728) 1729 Using the Z39.50 Information Retrieval Protocol. C. Lynch. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1729) 1730 Internet Message Access Protocol - Version 4. M. Crispin. December 1994. (Format: TXT, HTML) (Obsoleted by RFC2060, RFC2061) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1730) 1731 IMAP4 Authentication Mechanisms. J. Myers. December 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1731) 1732 IMAP4 Compatibility with IMAP2 and IMAP2bis. M. Crispin. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1732) 1733 Distributed Electronic Mail Models in IMAP4. M. Crispin. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1733) 1734 POP3 AUTHentication command. J. Myers. December 1994. (Format: TXT, HTML) (Obsoleted by RFC5034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1734) 1735 NBMA Address Resolution Protocol (NARP). J. Heinanen, R. Govindan. December 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1735) 1736 Functional Recommendations for Internet Resource Locators. J. Kunze. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1736) 1737 Functional Requirements for Uniform Resource Names. K. Sollins, L. Masinter. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1737) 1738 Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McCahill. December 1994. (Format: TXT, HTML) (Obsoleted by RFC4248, RFC4266) (Updated by RFC1808, RFC2368, RFC2396, RFC3986, RFC6196, RFC6270, RFC8089) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1738) 1739 A Primer On Internet and TCP/IP Tools. G. Kessler, S. Shepard. December 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1741) 1742 AppleTalk Management Information Base II. S. Waldbusser, K. Frisa. January 1995. (Format: TXT, HTML) (Obsoletes RFC1243) (Status: HISTORIC) (DOI: 10.17487/RFC1742) 1743 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1744) 1745 BGP4/IDRP for IP---OSPF Interaction. K. Varadhan, S. Hares, Y. Rekhter. December 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1745) 1746 Ways to Define User Expectations. B. Manning, D. Perkins. December 1994. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1747) 1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT, HTML) (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, HTML) (Updates RFC1748) (Status: HISTORIC) (DOI: 10.17487/RFC1749) 1750 Randomness Recommendations for Security. D. Eastlake 3rd, S. Crocker, J. Schiller. December 1994. (Format: TXT, HTML) (Obsoleted by RFC4086) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1750) 1751 A Convention for Human-Readable 128-bit Keys. D. McDonald. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1751) 1752 The Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin. January 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1752) 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture. N. Chiappa. December 1994. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1755) 1756 Remote Write Protocol - Version 1.0. T. Rinne. January 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1756) 1757 Remote Network Monitoring Management Information Base. S. Waldbusser. February 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC3805) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1759) 1760 The S/KEY One-Time Password System. N. Haller. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1760) 1761 Snoop Version 2 Packet Capture File Format. B. Callaghan, R. Gilligan. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1761) 1762 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. March 1995. (Format: TXT, HTML) (Obsoletes RFC1376) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1762) 1763 The PPP Banyan Vines Control Protocol (BVCP). S. Senum. March 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1763) 1764 The PPP XNS IDP Control Protocol (XNSCP). S. Senum. March 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1764) 1765 OSPF Database Overflow. J. Moy. March 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1765) 1766 Tags for the Identification of Languages. H. Alvestrand. March 1995. (Format: TXT, HTML) (Obsoleted by RFC3066, RFC3282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1766) 1767 MIME Encapsulation of EDI Objects. D. Crocker. March 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1767) 1768 Host Group Extensions for CLNP Multicasting. D. Marlow. March 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1768) 1769 Simple Network Time Protocol (SNTP). D. Mills. March 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1655) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1772) 1773 Experience with the BGP-4 protocol. P. Traina. March 1995. (Format: TXT, HTML) (Obsoletes RFC1656) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1773) 1774 BGP-4 Protocol Analysis. P. Traina, Ed.. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1774) 1775 To Be "On" the Internet. D. Crocker. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1775) 1776 The Address is the Message. S. Crocker. 1 April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1776) 1777 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. Kille. March 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1485) (Obsoleted by RFC2253, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1779) 1780 Internet Official Protocol Standards. J. Postel, Ed.. March 1995. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1484) (Obsoleted by RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1781) 1782 TFTP Option Extension. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Obsoleted by RFC2347) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1782) 1783 TFTP Blocksize Option. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1786) 1787 Routing in a Multi-provider Internet. Y. Rekhter. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1787) 1788 ICMP Domain Name Messages. W. Simpson. April 1995. (Format: TXT, HTML) (Obsoleted by RFC6918) (Status: HISTORIC) (DOI: 10.17487/RFC1788) 1789 INETPhone: Telephone Services and Servers on Internet. C. Yang. April 1995. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1790) 1791 TCP And UDP Over IPX Networks With Fixed Path MTU. T. Sung. April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1791) 1792 TCP/IPX Connection Mib Specification. T. Sung. April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1792) 1793 Extending OSPF to Support Demand Circuits. J. Moy. April 1995. (Format: TXT, HTML) (Updated by RFC3883) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1793) 1794 DNS Support for Load Balancing. T. Brisco. April 1995. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1434) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1795) 1796 Not All RFCs are Standards. C. Huitema, J. Postel, S. Crocker. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1796) 1797 Class A Subnet Experiment. Internet Assigned Numbers Authority (IANA). April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1797) 1798 Connection-less Lightweight X.500 Directory Access Protocol. A. Young. June 1995. (Format: TXT, HTML) (Obsoleted by RFC3352) (Status: HISTORIC) (DOI: 10.17487/RFC1798) 1799 Request for Comments Summary RFC Numbers 1700-1799. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1799) 1800 Internet Official Protocol Standards. J. Postel, Ed.. July 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1804) 1805 Location-Independent Data/Software Integrity Protocol. A. Rubin. June 1995. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2183) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1806) 1807 A Format for Bibliographic Records. R. Lasher, D. Cohen. June 1995. (Format: TXT, HTML) (Obsoletes RFC1357) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1807) 1808 Relative Uniform Resource Locators. R. Fielding. June 1995. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1809) 1810 Report on MD5 Performance. J. Touch. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1810) 1811 U.S. Government Internet Domain Names. Federal Networking Council. June 1995. (Format: TXT, HTML) (Obsoleted by RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1811) 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT, HTML) (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, HTML) (Also RFC1094) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1813) 1814 Unique Addresses are Good. E. Gerich. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1814) 1815 Character Sets ISO-10646 and ISO-10646-J-1. M. Ohta. July 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1815) 1816 U.S. Government Internet Domain Names. Federal Networking Council. August 1995. (Format: TXT, HTML) (Obsoletes RFC1811) (Obsoleted by RFC2146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1816) 1817 CIDR and Classful Routing. Y. Rekhter. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1817) 1818 Best Current Practices. J. Postel, T. Li, Y. Rekhter. August 1995. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1190, IEN119) (Status: HISTORIC) (DOI: 10.17487/RFC1819) 1820 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1822) 1823 The LDAP Application Program Interface. T. Howes, M. Smith. August 1995. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1824) 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2401) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1825) 1826 IP Authentication Header. R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1826) 1827 IP Encapsulating Security Payload (ESP). R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1827) 1828 IP Authentication using Keyed MD5. P. Metzger, W. Simpson. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1828) 1829 The ESP DES-CBC Transform. P. Karn, P. Metzger, W. Simpson. August 1995. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC3030) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1830) 1831 RPC: Remote Procedure Call Protocol Specification Version 2. R. Srinivasan. August 1995. (Format: TXT, HTML) (Obsoleted by RFC5531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1831) 1832 XDR: External Data Representation Standard. R. Srinivasan. August 1995. (Format: TXT, HTML) (Obsoleted by RFC4506) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1832) 1833 Binding Protocols for ONC RPC Version 2. R. Srinivasan. August 1995. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1834) 1835 Architecture of the WHOIS++ service. P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider. August 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1843) 1844 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1845) 1846 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1847) 1848 MIME Object Security Services. S. Crocker, N. Freed, J. Galvin, S. Murphy. October 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1848) 1849 "Son of 1036": News Article Format and Transmission. H. Spencer. March 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1851) 1852 IP Authentication using Keyed SHA. P. Metzger, W. Simpson. September 1995. (Format: TXT, HTML) (Obsoleted by RFC2841) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1852) 1853 IP in IP Tunneling. W. Simpson. October 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1853) 1854 SMTP Service Extension for Command Pipelining. N. Freed. October 1995. (Format: TXT, HTML) (Obsoleted by RFC2197) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1854) 1855 Netiquette Guidelines. S. Hambridge. October 1995. (Format: TXT, HTML) (Also FYI0028) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1855) 1856 The Opstat Client-Server Model for Statistics Retrieval. H. Clark. September 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1856) 1857 A Model for Common Operational Statistics. M. Lambert. October 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1859) 1860 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. October 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1862) 1863 A BGP/IDRP Route Server alternative to a full mesh routing. D. Haskin. October 1995. (Format: TXT, HTML) (Obsoleted by RFC4223) (Status: HISTORIC) (DOI: 10.17487/RFC1863) 1864 The Content-MD5 Header Field. J. Myers, M. Rose. October 1995. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1865) 1866 Hypertext Markup Language - 2.0. T. Berners-Lee, D. Connolly. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1866) 1867 Form-based File Upload in HTML. E. Nebel, L. Masinter. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1867) 1868 ARP Extension - UNARP. G. Malkin. November 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1868) 1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. November 1995. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1653) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1870) 1871 Addendum to RFC 1602 -- Variance Procedure. J. Postel. November 1995. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2112) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1872) 1873 Message/External-Body Content-ID Access Type. E. Levinson. December 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1873) 1874 SGML Media Types. E. Levinson. December 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1874) 1875 UNINETT PCA Policy Statements. N. Berge. December 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1877) 1878 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. December 1995. (Format: TXT, HTML) (Obsoletes RFC1860) (Status: HISTORIC) (DOI: 10.17487/RFC1878) 1879 Class A Subnet Experiment Results and Recommendations. B. Manning, Ed.. January 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1879) 1880 Internet Official Protocol Standards. J. Postel, Ed.. November 1995. (Format: TXT, HTML) (Obsoletes RFC1800) (Obsoleted by RFC1920) (Status: HISTORIC) (DOI: 10.17487/RFC1880) 1881 IPv6 Address Allocation Management. IAB, IESG. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1881) 1882 The 12-Days of Technology Before Christmas. B. Hancock. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1882) 1883 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1995. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1890) 1891 SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC3462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1892) 1893 Enhanced Mail System Status Codes. G. Vaudreuil. January 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1895) 1896 The text/enriched MIME Content-type. P. Resnick, A. Walker. February 1996. (Format: TXT, PS, HTML) (Obsoletes RFC1523, RFC1563) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1896) 1897 IPv6 Testing Address Allocation. R. Hinden, J. Postel. January 1996. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1898) 1899 Request for Comments Summary RFC Numbers 1800-1899. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1899) 1900 Renumbering Needs Work. B. Carpenter, Y. Rekhter. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1900) 1901 Introduction to Community-based SNMPv2. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1909) 1910 User-based Security Model for SNMPv2. G. Waters, Ed.. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1910) 1911 Voice Profile for Internet Mail. G. Vaudreuil. February 1996. (Format: TXT, HTML) (Obsoleted by RFC2421, RFC2422, RFC2423) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1911) 1912 Common DNS Operational and Configuration Errors. D. Barr. February 1996. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1913) 1914 How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz, C. Weider. February 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1919) 1920 Internet Official Protocol Standards. J. Postel. March 1996. (Format: TXT, HTML) (Obsoletes RFC1880) (Obsoleted by RFC2000) (Status: HISTORIC) (DOI: 10.17487/RFC1920) 1921 TNVIP Protocol. J. Dujonc. March 1996. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1922) 1923 RIPv1 Applicability Statement for Historic Status. J. Halpern, S. Bradner. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1923) 1924 A Compact Representation of IPv6 Addresses. R. Elz. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1924) 1925 The Twelve Networking Truths. R. Callon. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1925) 1926 An Experimental Encapsulation of IP Datagrams on Top of ATM. J. Eriksson. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1926) 1927 Suggested Additional MIME Types for Associating Documents. C. Rogers. 1 April 1996. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1928) 1929 Username/Password Authentication for SOCKS V5. M. Leech. March 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1931) 1932 IP over ATM: A Framework Document. R. Cole, D. Shur, C. Villamizar. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1932) 1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. April 1996. (Format: TXT, HTML) (Obsoleted by RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1933) 1934 Ascend's Multilink Protocol Plus (MP+). K. Smith. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1934) 1935 What is the Internet, Anyway?. J. Quarterman, S. Carl-Mitchell. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1935) 1936 Implementing the Internet Checksum in Hardware. J. Touch, B. Parham. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1936) 1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks. Y. Rekhter, D. Kandlur. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1937) 1938 A One-Time Password System. N. Haller, C. Metz. May 1996. (Format: TXT, HTML) (Obsoleted by RFC2289) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1938) 1939 Post Office Protocol - Version 3. J. Myers, M. Rose. May 1996. (Format: TXT, HTML) (Obsoletes RFC1725) (Updated by RFC1957, RFC2449, RFC6186, RFC8314) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1940) 1941 Frequently Asked Questions for Schools. J. Sellers, J. Robichaux. May 1996. (Format: TXT, HTML) (Obsoletes RFC1578) (Also FYI0022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1941) 1942 HTML Tables. D. Raggett. May 1996. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1943) 1944 Benchmarking Methodology for Network Interconnect Devices. S. Bradner, J. McQuaid. May 1996. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1945) 1946 Native ATM Support for ST2+. S. Jackowski. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1946) 1947 Greek Character Encoding for Electronic Mail Messages. D. Spinellis. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1947) 1948 Defending Against Sequence Number Attacks. S. Bellovin. May 1996. (Format: TXT, HTML) (Obsoleted by RFC6528) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1948) 1949 Scalable Multicast Key Distribution. A. Ballardie. May 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1949) 1950 ZLIB Compressed Data Format Specification version 3.3. P. Deutsch, J-L. Gailly. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1950) 1951 DEFLATE Compressed Data Format Specification version 1.3. P. Deutsch. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1951) 1952 GZIP file format specification version 4.3. P. Deutsch. May 1996. (Format: TXT, PS, PDF, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1954) 1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG. R. Hinden. June 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1955) 1956 Registration in the MIL Domain. D. Engebretson, R. Plzak. June 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1956) 1957 Some Observations on Implementations of the Post Office Protocol (POP3). R. Nelson. June 1996. (Format: TXT, HTML) (Updates RFC1939) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1957) 1958 Architectural Principles of the Internet. B. Carpenter, Ed.. June 1996. (Format: TXT, HTML) (Updated by RFC3439) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1958) 1959 An LDAP URL Format. T. Howes, M. Smith. June 1996. (Format: TXT, HTML) (Obsoleted by RFC2255) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1959) 1960 A String Representation of LDAP Search Filters. T. Howes. June 1996. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1961) 1962 The PPP Compression Control Protocol (CCP). D. Rand. June 1996. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1963) 1964 The Kerberos Version 5 GSS-API Mechanism. J. Linn. June 1996. (Format: TXT, HTML) (Updated by RFC4121, RFC6649) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1964) 1965 Autonomous System Confederations for BGP. P. Traina. June 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1967) 1968 The PPP Encryption Control Protocol (ECP). G. Meyer. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1968) 1969 The PPP DES Encryption Protocol (DESE). K. Sklower, G. Meyer. June 1996. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1970) 1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. August 1996. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1972) 1973 PPP in Frame Relay. W. Simpson. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1973) 1974 PPP Stac LZS Compression Protocol. R. Friend, W. Simpson. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1974) 1975 PPP Magnalink Variable Resource Compression. D. Schremp, J. Black, J. Weiss. August 1996. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1976) 1977 PPP BSD Compression Protocol. V. Schryver. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1977) 1978 PPP Predictor Compression Protocol. D. Rand. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1978) 1979 PPP Deflate Protocol. J. Woods. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1979) 1980 A Proposed Extension to HTML : Client-Side Image Maps. J. Seidman. August 1996. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC8201) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1981) 1982 Serial Number Arithmetic. R. Elz, R. Bush. August 1996. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1982) 1983 Internet Users' Glossary. G. Malkin, Ed.. August 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1988) 1989 PPP Link Quality Monitoring. W. Simpson. August 1996. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1717) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1990) 1991 PGP Message Exchange Formats. D. Atkins, W. Stallings, P. Zimmermann. August 1996. (Format: TXT, HTML) (Obsoleted by RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1991) 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. Steenstrup. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1992) 1993 PPP Gandalf FZA Compression Protocol. A. Barbir, D. Carr, W. Simpson. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1993) 1994 PPP Challenge Handshake Authentication Protocol (CHAP). W. Simpson. August 1996. (Format: TXT, HTML) (Obsoletes RFC1334) (Updated by RFC2484) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1994) 1995 Incremental Zone Transfer in DNS. M. Ohta. August 1996. (Format: TXT, HTML) (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, HTML) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1996) 1997 BGP Communities Attribute. R. Chandra, P. Traina, T. Li. August 1996. (Format: TXT, HTML) (Updated by RFC7606, RFC8642) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1998) 1999 Request for Comments Summary RFC Numbers 1900-1999. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1999) 2000 Internet Official Protocol Standards. J. Postel, Ed.. February 1997. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2001) 2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format: TXT, HTML) (Obsoleted by RFC3220) (Updated by RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2002) 2003 IP Encapsulation within IP. C. Perkins. October 1996. (Format: TXT, HTML) (Updated by RFC3168, RFC6864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2003) 2004 Minimal Encapsulation within IP. C. Perkins. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2004) 2005 Applicability Statement for IP Mobility Support. J. Solomon. October 1996. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2006) 2007 Catalogue of Network Training Materials. J. Foster, M. Isaacs, M. Prior. October 1996. (Format: TXT, HTML) (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, HTML) (Also BCP0007) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2008) 2009 GPS-Based Addressing and Routing. T. Imielinski, J. Navas. November 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2009) 2010 Operational Criteria for Root Name Servers. B. Manning, P. Vixie. October 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0008) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2014) 2015 MIME Security with Pretty Good Privacy (PGP). M. Elkins. October 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2017) 2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996. (Format: TXT, HTML) (Obsoletes RFC1072) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2018) 2019 Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2019) 2020 IEEE 802.12 Interface MIB. J. Flick. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2020) 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2. S. Waldbusser. January 1997. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2022) 2023 IP Version 6 over PPP. D. Haskin, E. Allen. October 1996. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2024) 2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2025) 2026 The Internet Standards Process -- Revision 3. S. Bradner. October 1996. (Format: TXT, HTML) (Obsoletes RFC1602, RFC1871) (Updated by RFC3667, RFC3668, RFC3932, RFC3978, RFC3979, RFC5378, RFC5657, RFC5742, RFC6410, RFC7100, RFC7127, RFC7475, RFC8179) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1769) (Obsoleted by RFC4330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2030) 2031 IETF-ISOC relationship. E. Huizer. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2031) 2032 RTP Payload Format for H.261 Video Streams. T. Turletti, C. Huitema. October 1996. (Format: TXT, HTML) (Obsoleted by RFC4587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2032) 2033 Local Mail Transfer Protocol. J. Myers. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2033) 2034 SMTP Service Extension for Returning Enhanced Error Codes. N. Freed. October 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2036) 2037 Entity MIB using SMIv2. K. McCloghrie, A. Bierman. October 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2040) 2041 Mobile Network Tracing. B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2041) 2042 Registering New BGP Attribute Types. B. Manning. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2042) 2043 The PPP SNA Control Protocol (SNACP). A. Fuqua. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2043) 2044 UTF-8, a transformation format of Unicode and ISO 10646. F. Yergeau. October 1996. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646, RFC3798, RFC5147, RFC6657, RFC8098) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2782) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2052) 2053 The AM (Armenia) Domain. E. Der-Danieliantz. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2053) 2054 WebNFS Client Specification. B. Callaghan. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2054) 2055 WebNFS Server Specification. B. Callaghan. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2055) 2056 Uniform Resource Locators for Z39.50. R. Denenberg, J. Kunze, D. Lynch. November 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2056) 2057 Source Directed Access Control on the Internet. S. Bradner. November 1996. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2058) 2059 RADIUS Accounting. C. Rigney. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2059) 2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. December 1996. (Format: TXT, HTML) (Obsoletes RFC1730) (Obsoleted by RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2060) 2061 IMAP4 Compatibility with IMAP2bis. M. Crispin. December 1996. (Format: TXT, HTML) (Obsoletes RFC1730) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2061) 2062 Internet Message Access Protocol - Obsolete Syntax. M. Crispin. December 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2062) 2063 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2722) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2063) 2064 Traffic Flow Measurement: Meter MIB. N. Brownlee. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2720) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2064) 2065 Domain Name System Security Extensions. D. Eastlake 3rd, C. Kaufman. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2535) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2065) 2066 TELNET CHARSET Option. R. Gellens. January 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2066) 2067 IP over HIPPI. J. Renwick. January 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2071) 2072 Router Renumbering Guide. H. Berkowitz. January 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2074) 2075 IP Echo Host Service. C. Partridge. January 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2075) 2076 Common Internet Message Headers. J. Palme. February 1997. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2077) 2078 Generic Security Service Application Program Interface, Version 2. J. Linn. January 1997. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2079) 2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2080) 2081 RIPng Protocol Applicability Statement. G. Malkin. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2081) 2082 RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2083) 2084 Considerations for Web Transaction Security. G. Bossert, S. Cooper, W. Drummond. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2084) 2085 HMAC-MD5 IP Authentication with Replay Prevention. M. Oehler, R. Glenn. February 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2085) 2086 IMAP4 ACL extension. J. Myers. January 1997. (Format: TXT, HTML) (Obsoleted by RFC4314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2086) 2087 IMAP4 QUOTA extension. J. Myers. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2087) 2088 IMAP4 non-synchronizing literals. J. Myers. January 1997. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2576) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2089) 2090 TFTP Multicast Option. A. Emberson. February 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2090) 2091 Triggered Extensions to RIP to Support Demand Circuits. G. Meyer, S. Sherry. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2091) 2092 Protocol Analysis for Triggered RIP. S. Sherry, G. Meyer. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2092) 2093 Group Key Management Protocol (GKMP) Specification. H. Harney, C. Muckenhirn. July 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2093) 2094 Group Key Management Protocol (GKMP) Architecture. H. Harney, C. Muckenhirn. July 1997. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2195) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2095) 2096 IP Forwarding Table MIB. F. Baker. January 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2098) 2099 Request for Comments Summary RFC Numbers 2000-2099. J. Elliott. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2099) 2100 The Naming of Hosts. J. Ashworth. 1 April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2100) 2101 IPv4 Address Behaviour Today. B. Carpenter, J. Crowcroft, Y. Rekhter. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2101) 2102 Multicast Support for Nimrod : Requirements and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2102) 2103 Mobility Support for Nimrod : Challenges and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2103) 2104 HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2105) 2106 Data Link Switching Remote Access Protocol. S. Chiang, J. Lee, H. Yasuda. February 1997. (Format: TXT, HTML) (Obsoleted by RFC2114) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2106) 2107 Ascend Tunnel Management Protocol - ATMP. K. Hamzeh. February 1997. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1516) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2108) 2109 HTTP State Management Mechanism. D. Kristol, L. Montulli. February 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2111) 2112 The MIME Multipart/Related Content-type. E. Levinson. March 1997. (Format: TXT, HTML) (Obsoletes RFC1872) (Obsoleted by RFC2387) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2112) 2113 IP Router Alert Option. D. Katz. February 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1315) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2115) 2116 X.500 Implementations Catalog-96. C. Apple, K. Rossen. April 1997. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2362) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2117) 2118 Microsoft Point-To-Point Compression (MPPC) Protocol. G. Pall. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2118) 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. (Format: TXT, HTML) (Updated by RFC8174) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2119) 2120 Managing the X.500 Root Naming Context. D. Chadwick. March 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2120) 2121 Issues affecting MARS Cluster Size. G. Armitage. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2121) 2122 VEMMI URL Specification. D. Mavrakis, H. Layec, K. Kartmann. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2122) 2123 Traffic Flow Measurement: Experiences with NeTraMet. N. Brownlee. March 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2125) 2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March 1997. (Format: TXT, HTML) (Updates RFC1006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2126) 2127 ISDN Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2127) 2128 Dial Control Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC6055) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2130) 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2133) 2134 Articles of Incorporation of Internet Society. ISOC Board of Trustees. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2134) 2135 Internet Society By-Laws. ISOC Board of Trustees. April 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2058) (Obsoleted by RFC2865) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2138) 2139 RADIUS Accounting. C. Rigney. April 1997. (Format: TXT, HTML) (Obsoletes RFC2059) (Obsoleted by RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2139) 2140 TCP Control Block Interdependence. J. Touch. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2140) 2141 URN Syntax. R. Moats. May 1997. (Format: TXT, HTML) (Obsoleted by RFC8141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2141) 2142 Mailbox Names for Common Services, Roles and Functions. D. Crocker. May 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2142) 2143 Encapsulating IP with the Small Computer System Interface. B. Elliston. May 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2143) 2144 The CAST-128 Encryption Algorithm. C. Adams. May 1997. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2145) 2146 U.S. Government Internet Domain Names. Federal Networking Council. May 1997. (Format: TXT, HTML) (Obsoletes RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2146) 2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2149) 2150 Humanities and Arts: Sharing Center Stage on the Internet. J. Max, W. Stickle. October 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1642) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2152) 2153 PPP Vendor Extensions. W. Simpson. May 1997. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2154) 2155 Definitions of Managed Objects for APPN using SMIv2. B. Clouston, B. Moore. June 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2157) 2158 X.400 Image Body Parts. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2158) 2159 A MIME Body Part for FAX. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2159) 2160 Carrying PostScript in X.400 and MIME. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2160) 2161 A MIME Body Part for ODA. H. Alvestrand. January 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2169) 2170 Application REQuested IP over ATM (AREQUIPA). W. Almesberger, J. Le Boudec, P. Oechslin. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2170) 2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2171) 2172 MAPOS Version 1 Assigned Numbers. M. Maruyama, K. Murakami. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2172) 2173 A MAPOS version 1 Extension - Node Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2173) 2174 A MAPOS version 1 Extension - Switch-Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2175) 2176 IPv4 over MAPOS Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Updated by RFC5494) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2176) 2177 IMAP4 IDLE command. B. Leiba. June 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2177) 2178 OSPF Version 2. J. Moy. July 1997. (Format: TXT, HTML) (Obsoletes RFC1583) (Obsoleted by RFC2328) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2178) 2179 Network Security For Trade Shows. A. Gwinn. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2179) 2180 IMAP4 Multi-Accessed Mailbox Practice. M. Gahrns. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2180) 2181 Clarifications to the DNS Specification. R. Elz, R. Bush. July 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2185) 2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2186) 2187 Application of Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2188) 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --. A. Ballardie. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2189) 2190 RTP Payload Format for H.263 Video Streams. C. Zhu. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2190) 2191 VENUS - Very Extensive Non-Unicast Service. G. Armitage. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2191) 2192 IMAP URL Scheme. C. Newman. September 1997. (Format: TXT, HTML) (Obsoleted by RFC5092) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2192) 2193 IMAP4 Mailbox Referrals. M. Gahrns. September 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2095) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2195) 2196 Site Security Handbook. B. Fraser. September 1997. (Format: TXT, HTML) (Obsoletes RFC1244) (Also FYI0008) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2196) 2197 SMTP Service Extension for Command Pipelining. N. Freed. September 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2199) 2200 Internet Official Protocol Standards. J. Postel. June 1997. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2201) 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1. P. Cheng, R. Glenn. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2202) 2203 RPCSEC_GSS Protocol Specification. M. Eisler, A. Chiu, L. Ling. September 1997. (Format: TXT, HTML) (Updated by RFC5403) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2203) 2204 ODETTE File Transfer Protocol. D. Nash. September 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2206) 2207 RSVP Extensions for IPSEC Data Flows. L. Berger, T. O'Malley. September 1997. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2208) 2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules. R. Braden, L. Zhang. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2209) 2210 The Use of RSVP with IETF Integrated Services. J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2210) 2211 Specification of the Controlled-Load Network Element Service. J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2211) 2212 Specification of Guaranteed Quality of Service. S. Shenker, C. Partridge, R. Guerin. September 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2214) 2215 General Characterization Parameters for Integrated Service Network Elements. S. Shenker, J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2215) 2216 Network Element Service Specification Template. S. Shenker, J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2216) 2217 Telnet Com Port Control Option. G. Clark. October 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2217) 2218 A Common Schema for the Internet White Pages Service. T. Genovese, B. Jennings. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2218) 2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. (Format: TXT, HTML) (Also BCP0017) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2219) 2220 The Application/MARC Content-type. R. Guenther. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2220) 2221 IMAP4 Login Referrals. M. Gahrns. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2221) 2222 Simple Authentication and Security Layer (SASL). J. Myers. October 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2224) 2225 Classical IP and ARP over ATM. M. Laubach, J. Halpern. April 1998. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2226) 2227 Simple Hit-Metering and Usage-Limiting for HTTP. J. Mogul, P. Leach. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2227) 2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2228) 2229 A Dictionary Server Protocol. R. Faith, B. Martin. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2229) 2230 Key Exchange Delegation Record for the DNS. R. Atkinson. November 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2232) 2233 The Interfaces Group MIB using SMIv2. K. McCloghrie, F. Kastenholz. November 1997. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC4234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2234) 2235 Hobbes' Internet Timeline. R. Zakon. November 1997. (Format: TXT, HTML) (Also FYI0032) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2235) 2236 Internet Group Management Protocol, Version 2. W. Fenner. November 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2239) 2240 A Legal Basis for Domain Name Allocation. O. Vaughan. November 1997. (Format: TXT, HTML) (Obsoleted by RFC2352) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2240) 2241 DHCP Options for Novell Directory Services. D. Provan. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2241) 2242 NetWare/IP Domain Name and Information. R. Droms, K. Fong. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2242) 2243 OTP Extended Responses. C. Metz. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2243) 2244 ACAP -- Application Configuration Access Protocol. C. Newman, J. G. Myers. November 1997. (Format: TXT, HTML) (Updated by RFC6075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2244) 2245 Anonymous SASL Mechanism. C. Newman. November 1997. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC4519, RFC4524) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2247) 2248 Network Services Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC1565) (Obsoleted by RFC2788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2248) 2249 Mail Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2741) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2257) 2258 Internet Nomenclator Project. J. Ordille. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2258) 2259 Simple Nomenclator Query Protocol (SNQP). J. Elliott, J. Ordille. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2259) 2260 Scalable Support for Multi-homed Multi-provider Connectivity. T. Bates, Y. Rekhter. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2260) 2261 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC2272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2262) 2263 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2827) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2267) 2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2268) 2269 Using the MARS Model in non-ATM NBMA Networks. G. Armitage. January 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2270) 2271 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC3401) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2276) 2277 IETF Policy on Character Sets and Languages. H. Alvestrand. January 1998. (Format: TXT, HTML) (Also BCP0018) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2277) 2278 IANA Charset Registration Procedures. N. Freed, J. Postel. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2978) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2278) 2279 UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2283) 2284 PPP Extensible Authentication Protocol (EAP). L. Blunk, J. Vollbrecht. March 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2285) 2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. J. Kapp. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2286) 2287 Definitions of System-Level Managed Objects for Applications. C. Krupczak, J. Saperia. February 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2288) 2289 A One-Time Password System. N. Haller, C. Metz, P. Nesser, M. Straw. February 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2291) 2292 Advanced Sockets API for IPv6. W. Stevens, M. Thomas. February 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2294) 2295 Transparent Content Negotiation in HTTP. K. Holtman, A. Mutz. March 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2295) 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. K. Holtman, A. Mutz. March 1998. (Format: TXT, HTML) (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, HTML) (Updates RFC1987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2297) 2298 An Extensible Message Format for Message Disposition Notifications. R. Fajman. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3798) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2298) 2299 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2299) 2300 Internet Official Protocol Standards. J. Postel. May 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC3302) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2302) 2303 Minimal PSTN address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3191) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2303) 2304 Minimal FAX address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2306) 2307 An Approach for Using LDAP as a Network Information Service. L. Howard. March 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2307) 2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Updated by RFC4035, RFC4033, RFC4034, RFC6604, RFC8020, RFC8499) (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, HTML) (Obsoleted by RFC7567) (Updated by RFC7141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2309) 2310 The Safe Response Header Field. K. Holtman. April 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2312) 2313 PKCS #1: RSA Encryption Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Obsoleted by RFC2437) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2313) 2314 PKCS #10: Certification Request Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Obsoleted by RFC2986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2314) 2315 PKCS #7: Cryptographic Message Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2315) 2316 Report of the IAB Security Architecture Workshop. S. Bellovin. April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2316) 2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P. Vixie. March 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2318) 2319 Ukrainian Character Set KOI8-U. KOI8-U Working Group. April 1998. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2320) 2321 RITA -- The Reliable Internetwork Troubleshooting Agent. A. Bressen. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2321) 2322 Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal, R. van Mook. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2322) 2323 IETF Identification and Security Guidelines. A. Ramos. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2323) 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. 1 April 1998. (Format: TXT, HTML) (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. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2325) 2326 Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R. Lanphier. April 1998. (Format: TXT, HTML) (Obsoleted by RFC7826) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2326) 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April 1998. (Format: TXT, HTML) (Obsoleted by RFC4566) (Updated by RFC3266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2327) 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2329) 2330 Framework for IP Performance Metrics. V. Paxson, G. Almes, J. Mahdavi, M. Mathis. May 1998. (Format: TXT, HTML) (Updated by RFC7312, RFC8468) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2332) 2333 NHRP Protocol Applicability Statement. D. Cansever. April 1998. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2334) 2335 A Distributed NHRP Service Using SCSP. J. Luciani. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2335) 2336 Classical IP and ARP over ATM to NHRP Transition. J. Luciani. July 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2340) 2341 Cisco Layer Two Forwarding (Protocol) "L2F". A. Valencia, M. Littlewood, T. Kolar. May 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2341) 2342 IMAP4 Namespace. M. Gahrns, C. Newman. May 1998. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2343) 2344 Reverse Tunneling for Mobile IP. G. Montenegro, Ed.. May 1998. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2345) 2346 Making Postscript and PDF International. J. Palme. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2346) 2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2347) 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2351) 2352 A Convention For Using Legal Names as Domain Names. O. Vaughan. May 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2353) 2354 Options for Repair of Streaming Media. C. Perkins, O. Hodson. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2354) 2355 TN3270 Enhancements. B. Kelly. June 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1650) (Obsoleted by RFC2665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2358) 2359 IMAP4 UIDPLUS extension. J. Myers. June 1998. (Format: TXT, HTML) (Obsoleted by RFC4315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2359) 2360 Guide for Internet Standards Writers. G. Scott. June 1998. (Format: TXT, HTML) (Also BCP0022) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2360) 2361 WAVE and AVI Codec Registries. E. Fleischman. June 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2364) 2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2367) 2368 The mailto URL scheme. P. Hoffman, L. Masinter, J. Zawinski. July 1998. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2369) 2370 The OSPF Opaque LSA Option. R. Coltun. July 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2372) 2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July 1998. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2073) (Obsoleted by RFC3587) (Status: HISTORIC) (DOI: 10.17487/RFC2374) 2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2375) 2376 XML Media Types. E. Whitehead, M. Murata. July 1998. (Format: TXT, HTML) (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, HTML) (Updated by RFC4519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2377) 2378 The CCSO Nameserver (Ph) Architecture. R. Hedberg, P. Pomes. September 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2378) 2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. (Format: TXT, HTML) (Also BCP0024) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2379) 2380 RSVP over ATM Implementation Requirements. L. Berger. August 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2382) 2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version. M. Suzuki. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2383) 2384 POP URL Scheme. R. Gellens. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2384) 2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A. Heffernan. August 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2386) 2387 The MIME Multipart/Related Content-type. E. Levinson. August 1998. (Format: TXT, HTML) (Obsoletes RFC2112) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2387) 2388 Returning Values from Forms: multipart/form-data. L. Masinter. August 1998. (Format: TXT, HTML) (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, HTML) (Also RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2389) 2390 Inverse Address Resolution Protocol. T. Bradley, C. Brown, A. Malis. September 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2391) 2392 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. August 1998. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC3173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2393) 2394 IP Payload Compression Using DEFLATE. R. Pereira. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2394) 2395 IP Payload Compression Using LZS. R. Friend, R. Monsour. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2395) 2396 Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2397) 2398 Some Testing Tools for TCP Implementors. S. Parker, C. Schmechel. August 1998. (Format: TXT, HTML) (Also FYI0033) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2398) 2399 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2399) 2400 Internet Official Protocol Standards. J. Postel, J. Reynolds. September 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2405) 2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2408) 2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2410) 2411 IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November 1998. (Format: TXT, HTML) (Obsoleted by RFC6071) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2411) 2412 The OAKLEY Key Determination Protocol. H. Orman. November 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2366) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2417) 2418 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1969) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2419) 2420 The PPP Triple-DES Encryption Protocol (3DESE). H. Kummert. September 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2420) 2421 Voice Profile for Internet Mail - version 2. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2425) 2426 vCard MIME Directory Profile. F. Dawson, T. Howes. September 1998. (Format: TXT, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2426) 2427 Multiprotocol Interconnect over Frame Relay. C. Brown, A. Malis. September 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2430) 2431 RTP Payload Format for BT.656 Video Encoding. D. Tynan. October 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2431) 2432 Terminology for IP Multicast Benchmarking. K. Dubray. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2432) 2433 Microsoft PPP CHAP Extensions. G. Zorn, S. Cobb. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2433) 2434 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. October 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2439) 2440 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R. Thayer. November 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2441) 2442 The Batch SMTP Media Type. N. Freed, D. Newman, J. Belissent, M. Hoy. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2442) 2443 A Distributed MARS Service Using SCSP. J. Luciani, A. Gallo. November 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2443) 2444 The One-Time-Password SASL Mechanism. C. Newman. October 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2448) 2449 POP3 Extension Mechanism. R. Gellens, C. Newman, L. Lundblade. November 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2450) 2451 The ESP CBC-Mode Cipher Algorithms. R. Pereira, R. Adams. November 1998. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC4022, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2452) 2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC4113, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2454) 2455 Definitions of Managed Objects for APPN. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2456) 2457 Definitions of Managed Objects for Extended Border Node. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1883) (Obsoleted by RFC8200) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1972) (Updated by RFC6085, RFC8064) (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, HTML) (Obsoleted by RFC4293, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2465) 2466 Management Information Base for IP Version 6: ICMPv6 Group. D. Haskin, S. Onishi. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4293, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2466) 2467 Transmission of IPv6 Packets over FDDI Networks. M. Crawford. December 1998. (Format: TXT, HTML) (Obsoletes RFC2019) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2467) 2468 I REMEMBER IANA. V. Cerf. October 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2470) 2471 IPv6 Testing Address Allocation. R. Hinden, R. Fink, J. Postel. December 1998. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1455, RFC1349) (Updates RFC0791) (Updated by RFC3168, RFC3260, RFC8436) (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, HTML) (Updated by RFC3260) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2475) 2476 Message Submission. R. Gellens, J. Klensin. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2476) 2477 Criteria for Evaluating Roaming Protocols. B. Aboba, G. Zorn. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2477) 2478 The Simple and Protected GSS-API Negotiation Mechanism. E. Baize, D. Pinkas. December 1998. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2479) 2480 Gateways and MIME Security Multiparts. N. Freed. January 1999. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC3168) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2481) 2482 Language Tagging in Unicode Plain Text. K. Whistler, G. Adams. January 1999. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2483) 2484 PPP LCP Internationalization Configuration Option. G. Zorn. January 1999. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2485) 2486 The Network Access Identifier. B. Aboba, M. Beadles. January 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also BCP0028) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2488) 2489 Procedure for Defining New DHCP Options. R. Droms. January 1999. (Format: TXT, HTML) (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, PS, PDF, HTML) (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, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2491) 2492 IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. January 1999. (Format: TXT, HTML) (Updated by RFC8064) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8064) (Also RFC1201) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2497) 2498 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. January 1999. (Format: TXT, HTML) (Obsoleted by RFC2678) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2498) 2499 Request for Comments Summary. A. Ramos. July 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2499) 2500 Internet Official Protocol Standards. J. Reynolds, R. Braden. June 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2502) 2503 MIME Types for Use with the ISO ILL Protocol. R. Moulton, M. Needleman. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2503) 2504 Users' Security Handbook. E. Guttman, L. Leong, G. Malkin. February 1999. (Format: TXT, HTML) (Also FYI0034) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2504) 2505 Anti-Spam Recommendations for SMTP MTAs. G. Lindberg. February 1999. (Format: TXT, HTML) (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, HTML) (Also BCP0031) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2506) 2507 IP Header Compression. M. Degermark, B. Nordgren, S. Pink. February 1999. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2508) 2509 IP Header Compression over PPP. M. Engan, S. Casner, C. Bormann. February 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2514) 2515 Definitions of Managed Objects for ATM Management. K. Tesink, Ed.. February 1999. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2516) 2517 Building Directories from DNS: Experiences from WWWSeeker. R. Moats, R. Huber. February 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2519) 2520 NHRP with Mobile NHCs. J. Luciani, H. Suzuki, N. Doraswamy, D. Horton. February 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2520) 2521 ICMP Security Failures Messages. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2521) 2522 Photuris: Session-Key Management Protocol. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2522) 2523 Photuris: Extended Schemes and Attributes. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2525) 2526 Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2528) 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2529) 2530 Indicating Supported Media Features Using Extensions to DSN and MDN. D. Wing. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2530) 2531 Content Feature Schema for Internet Fax. G. Klyne, L. McIntyre. March 1999. (Format: TXT, HTML) (Obsoleted by RFC2879) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2531) 2532 Extended Facsimile Using Internet Mail. L. Masinter, D. Wing. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2532) 2533 A Syntax for Describing Media Feature Sets. G. Klyne. March 1999. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2534) 2535 Domain Name System Security Extensions. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2539) 2540 Detached Domain Name System (DNS) Information. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2540) 2541 DNS Security Operational Considerations. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2541) 2542 Terminology and Goals for Internet Fax. L. Masinter. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2542) 2543 SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2545) 2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999. (Format: TXT, HTML) (Obsoleted by RFC2772) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2546) 2547 BGP/MPLS VPNs. E. Rosen, Y. Rekhter. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4364) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2547) 2548 Microsoft Vendor-specific RADIUS Attributes. G. Zorn. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2548) 2549 IP over Avian Carriers with Quality of Service. D. Waitzman. 1 April 1999. (Format: TXT, HTML) (Updates RFC1149) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2549) 2550 Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. 1 April 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2550) 2551 The Roman Standards Process -- Revision III. S. Bradner. 1 April 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC4954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2554) 2555 30 Years of RFCs. RFC Editor, et al.. April 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2562) 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients. R. Troll. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2563) 2564 Application Management MIB. C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. May 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC2911) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2566) 2567 Design Goals for an Internet Printing Protocol. F. Wright. April 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2585) 2586 The Audio/L16 MIME content type. J. Salsman, H. Alvestrand. May 1999. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC4523) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2587) 2588 IP Multicast and Firewalls. R. Finlayson. May 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2590) 2591 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2594) 2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. (Format: TXT, HTML) (Updated by RFC4616, RFC7817, RFC8314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2595) 2596 Use of Language Codes in LDAP. M. Wahl, T. Howes. May 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2599) 2600 Internet Official Protocol Standards. J. Reynolds, R. Braden. March 2000. (Format: TXT, HTML) (Obsoletes RFC2500) (Obsoleted by RFC2700) (Status: HISTORIC) (DOI: 10.17487/RFC2600) 2601 ILMI-Based Server Discovery for ATMARP. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2601) 2602 ILMI-Based Server Discovery for MARS. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2602) 2603 ILMI-Based Server Discovery for NHRP. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2603) 2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. June 1999. (Format: TXT, HTML) (Obsoleted by RFC2636) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2604) 2605 Directory Server Monitoring MIB. G. Mansfield, S. Kille. June 1999. (Format: TXT, HTML) (Obsoletes RFC1567) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2605) 2606 Reserved Top Level DNS Names. D. Eastlake 3rd, A. Panitz. June 1999. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2607) 2608 Service Location Protocol, Version 2. E. Guttman, C. Perkins, J. Veizades, M. Day. June 1999. (Format: TXT, HTML) (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, HTML) (Updates RFC2165) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2609) 2610 DHCP Options for Service Location Protocol. C. Perkins, E. Guttman. June 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2613) 2614 An API for Service Location. J. Kempf, E. Guttman. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2614) 2615 PPP over SONET/SDH. A. Malis, W. Simpson. June 1999. (Format: TXT, HTML) (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, PS, PDF, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC4668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2618) 2619 RADIUS Authentication Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4669) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2619) 2620 RADIUS Accounting Client MIB. B. Aboba, G. Zorn. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4670) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2620) 2621 RADIUS Accounting Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2623) 2624 NFS Version 4 Design Considerations. S. Shepler. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2624) 2625 IP and ARP over Fibre Channel. M. Rajagopal, R. Bhagwat, W. Rickard. June 1999. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2626) 2627 Key Management for Multicast: Issues and Architectures. D. Wallner, E. Harder, R. Agee. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2627) 2628 Simple Cryptographic Program Interface (Crypto API). V. Smyslov. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2628) 2629 Writing I-Ds and RFCs using XML. M. Rose. June 1999. (Format: TXT, HTML) (Obsoleted by RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2629) 2630 Cryptographic Message Syntax. R. Housley. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2630) 2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2631) 2632 S/MIME Version 3 Certificate Handling. B. Ramsdell, Ed.. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2632) 2633 S/MIME Version 3 Message Specification. B. Ramsdell, Ed.. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3851) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2633) 2634 Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June 1999. (Format: TXT, HTML) (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, HTML) (Also FYI0035) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2635) 2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. July 1999. (Format: TXT, PS, PDF, HTML) (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, HTML) (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, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2638) 2639 Internet Printing Protocol/1.0: Implementer's Guide. T. Hastings, C. Manros. July 1999. (Format: TXT, HTML) (Obsoleted by RFC3196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2639) 2640 Internationalization of the File Transfer Protocol. B. Curtin. July 1999. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2641) 2642 Cabletron's VLS Protocol Specification. L. Kane. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2642) 2643 Cabletron's SecureFast VLAN Operational Model. D. Ruffen, T. Len, J. Yanacek. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2643) 2644 Changing the Default for Directed Broadcasts in Routers. D. Senie. August 1999. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2645) 2646 The Text/Plain Format Parameter. R. Gellens, Ed.. August 1999. (Format: TXT, HTML) (Obsoleted by RFC3676) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2646) 2647 Benchmarking Terminology for Firewall Performance. D. Newman. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2647) 2648 A URN Namespace for IETF Documents. R. Moats. August 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2650) 2651 The Architecture of the Common Indexing Protocol (CIP). J. Allen, M. Mealling. August 1999. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2652) 2653 CIP Transport Protocols. J. Allen, P. Leach, R. Hedberg. August 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2655) 2656 Registration Procedures for SOIF Template Types. T. Hardie. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2656) 2657 LDAPv2 Client vs. the Index Mesh. R. Hedberg. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2657) 2658 RTP Payload Format for PureVoice(tm) Audio. K. McKay. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2658) 2659 Security Extensions For HTML. E. Rescorla, A. Schiffman. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2659) 2660 The Secure HyperText Transfer Protocol. E. Rescorla, A. Schiffman. August 1999. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2661) 2662 Definitions of Managed Objects for the ADSL Lines. G. Bathrick, F. Ly. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2662) 2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2666) 2667 IP Tunnel MIB. D. Thaler. August 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC4546) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2670) 2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999. (Format: TXT, HTML) (Obsoleted by RFC6891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2671) 2672 Non-Terminal DNS Name Redirection. M. Crawford. August 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC4363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2674) 2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2677) 2678 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. September 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2681) 2682 Performance Issues in VC-Merge Capable ATM LSRs. I. Widjaja, A. Elwalid. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2682) 2683 IMAP4 Implementation Recommendations. B. Leiba. September 1999. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1483) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2684) 2685 Virtual Private Networks Identifier. B. Fox, B. Gleeson. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2685) 2686 The Multi-Class Extension to Multi-Link PPP. C. Bormann. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2686) 2687 PPP in a Real-time Oriented HDLC-like Framing. C. Bormann. September 1999. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2688) 2689 Providing Integrated Services over Low-bitrate Links. C. Bormann. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2689) 2690 A Proposal for an MOU-Based ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2690) 2691 A Memorandum of Understanding for an ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2691) 2692 SPKI Requirements. C. Ellison. September 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2694) 2695 Authentication Mechanisms for ONC RPC. A. Chiu. September 1999. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2696) 2697 A Single Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2697) 2698 A Two Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2698) 2699 Request for Comments Summary RFC Numbers 2600-2699. S. Ginoza. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2699) 2700 Internet Official Protocol Standards. J. Reynolds, R. Braden. August 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2702) 2703 Protocol-independent Content Negotiation Framework. G. Klyne. September 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2707) 2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB. R. Bergman. November 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2708) 2709 Security Model with Tunnel-mode IPsec for NAT Domains. P. Srisuresh. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2709) 2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Format: TXT, HTML) (Updated by RFC3590, RFC3810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2710) 2711 IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2714) 2715 Interoperability Rules for Multicast Routing Protocols. D. Thaler. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2715) 2716 PPP EAP TLS Authentication Protocol. B. Aboba, D. Simon. October 1999. (Format: TXT, HTML) (Obsoleted by RFC5216) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2716) 2717 Registration Procedures for URL Scheme Names. R. Petke, I. King. November 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2719) 2720 Traffic Flow Measurement: Meter MIB. N. Brownlee. October 1999. (Format: TXT, HTML) (Obsoletes RFC2064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2720) 2721 RTFM: Applicability Statement. N. Brownlee. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2721) 2722 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. October 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2724) 2725 Routing Policy System Security. C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. December 1999. (Format: TXT, HTML) (Updated by RFC4012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2725) 2726 PGP Authentication for RIPE Database Updates. J. Zsako. December 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2729) 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP). S. Hanna, B. Patel, M. Shah. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2730) 2731 Encoding Dublin Core Metadata in HTML. J. Kunze. December 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC5109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2733) 2734 IPv4 over IEEE 1394. P. Johansson. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2734) 2735 NHRP Support for Virtual Private Networks. B. Fox, B. Petri. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2735) 2736 Guidelines for Writers of RTP Payload Format Specifications. M. Handley, C. Perkins. December 1999. (Format: TXT, HTML) (Updated by RFC8088) (Also BCP0036) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2736) 2737 Entity MIB (Version 2). K. McCloghrie, A. Bierman. December 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2739) 2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2742) 2743 Generic Security Service Application Program Interface Version 2, Update 1. J. Linn. January 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2746) 2747 RSVP Cryptographic Authentication. F. Baker, B. Lindell, M. Talwar. January 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2749) 2750 RSVP Extensions for Policy Control. S. Herzog. January 2000. (Format: TXT, HTML) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2750) 2751 Signaled Preemption Priority Policy Element. S. Herzog. January 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2753) 2754 RPS IANA Issues. C. Alaettinoglu, C. Villamizar, R. Govindan. January 2000. (Format: TXT, HTML) (Obsoleted by RFC6254) (Status: HISTORIC) (DOI: 10.17487/RFC2754) 2755 Security Negotiation for WebNFS. A. Chiu, M. Eisler, B. Callaghan. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2755) 2756 Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. January 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2756) 2757 Long Thin Networks. G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2757) 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring. K. White. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2758) 2759 Microsoft PPP CHAP Extensions, Version 2. G. Zorn. January 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2760) 2761 Terminology for ATM Benchmarking. J. Dunn, C. Martin. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2761) 2762 Sampling of the Group Membership in RTP. J. Rosenberg, H. Schulzrinne. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2762) 2763 Dynamic Hostname Exchange Mechanism for IS-IS. N. Shen, H. Smit. February 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2764) 2765 Stateless IP/ICMP Translation Algorithm (SIIT). E. Nordmark. February 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2768) 2769 Routing Policy System Replication. C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer. February 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2769) 2770 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. February 2000. (Format: TXT, HTML) (Obsoleted by RFC3180) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2770) 2771 An Abstract API for Multicast Address Allocation. R. Finlayson. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2771) 2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT, HTML) (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, HTML) (Updates RFC0959) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2773) 2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2774) 2775 Internet Transparency. B. Carpenter. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2775) 2776 Multicast-Scope Zone Announcement Protocol (MZAP). M. Handley, D. Thaler, R. Kermode. February 2000. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2776) 2777 Publicly Verifiable Nomcom Random Selection. D. Eastlake 3rd. February 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2778) 2779 Instant Messaging / Presence Protocol Requirements. M. Day, S. Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2052) (Updated by RFC6335, RFC8553) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2785) 2786 Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC6527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2787) 2788 Network Services Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT, HTML) (Obsoletes RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2788) 2789 Mail Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT, HTML) (Obsoletes RFC2249, RFC1566) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2789) 2790 Host Resources MIB. S. Waldbusser, P. Grillo. March 2000. (Format: TXT, HTML) (Obsoletes RFC1514) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2790) 2791 Scalable Routing Design Principles. J. Yu. July 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2792) 2793 RTP Payload for Text Conversation. G. Hellstrom. May 2000. (Format: TXT, HTML) (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, HTML) (Updates RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2794) 2795 The Infinite Monkey Protocol Suite (IMPS). S. Christey. 1 April 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC5272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2797) 2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith. April 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2799) 2800 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. May 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2802) 2803 Digest Values for DOM (DOMHASH). H. Maruyama, K. Tamura, N. Uramoto. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2803) 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2804) 2805 Media Gateway Control Protocol Architecture and Requirements. N. Greene, M. Ramalho, B. Rosen. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2805) 2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format: TXT, HTML) (Obsoleted by RFC3966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2806) 2807 XML Signature Requirements. J. Reagle. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2807) 2808 The SecurID(r) SASL Mechanism. M. Nystrom. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2808) 2809 Implementation of L2TP Compulsory Tunneling via RADIUS. B. Aboba, G. Zorn. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2809) 2810 Internet Relay Chat: Architecture. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2810) 2811 Internet Relay Chat: Channel Management. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2811) 2812 Internet Relay Chat: Client Protocol. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2812) 2813 Internet Relay Chat: Server Protocol. C. Kalt. April 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2816) 2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May 2000. (Format: TXT, HTML) (Updates RFC2616) (Updated by RFC7230, RFC7231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2817) 2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT, HTML) (Updated by RFC5785, RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2818) 2819 Remote Network Monitoring Management Information Base. S. Waldbusser. May 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2820) 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2823) 2824 Call Processing Language Framework and Requirements. J. Lennox, H. Schulzrinne. May 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2825) 2826 IAB Technical Comment on the Unique DNS Root. Internet Architecture Board. May 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2838) 2839 Internet Kermit Service. F. da Cruz, J. Altman. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2839) 2840 TELNET KERMIT OPTION. J. Altman, F. da Cruz. May 2000. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1852) (Status: HISTORIC) (DOI: 10.17487/RFC2841) 2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. May 2000. (Format: TXT, HTML) (Obsoleted by RFC3392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2842) 2843 Proxy-PAR. P. Droz, T. Przygienda. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2843) 2844 OSPF over ATM and Proxy-PAR. T. Przygienda, P. Droz, R. Haas. May 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2848) 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification. G. Good. June 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC3291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2851) 2852 Deliver By SMTP Service Extension. D. Newman. June 2000. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC5653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2853) 2854 The 'text/html' Media Type. D. Connolly, L. Masinter. June 2000. (Format: TXT, HTML) (Obsoletes RFC2070, RFC1980, RFC1942, RFC1867, RFC1866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2854) 2855 DHCP for IEEE 1394. K. Fujisawa. June 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2860) 2861 TCP Congestion Window Validation. M. Handley, J. Padhye, S. Floyd. June 2000. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2862) 2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2138) (Updated by RFC2868, RFC3575, RFC5080, RFC6929, RFC8044) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2865) 2866 RADIUS Accounting. C. Rigney. June 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC2865) (Updated by RFC3575) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2868) 2869 RADIUS Extensions. C. Rigney, W. Willats, P. Calhoun. June 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2876) 2877 5250 Telnet Enhancements. T. Murphy Jr., P. Rieth, J. Stevens. July 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2879) 2880 Internet Fax T.30 Feature Mapping. L. McIntyre, G. Klyne. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2880) 2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model. D. Mitton, M. Beadles. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2881) 2882 Network Access Servers Requirements: Extended RADIUS Practices. D. Mitton. July 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC3015) (Status: HISTORIC) (DOI: 10.17487/RFC2885) 2886 Megaco Errata. T. Taylor. August 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2887) 2888 Secure Remote Access with L2TP. P. Srisuresh. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2888) 2889 Benchmarking Methodology for LAN Switching Devices. R. Mandeville, J. Perser. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2889) 2890 Key and Sequence Number Extensions to GRE. G. Dommety. September 2000. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2891) 2892 The Cisco SRP MAC Layer Protocol. D. Tsiang, G. Suwala. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2892) 2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. August 2000. (Format: TXT, HTML) (Obsoletes RFC1933) (Obsoleted by RFC4213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2893) 2894 Router Renumbering for IPv6. M. Crawford. August 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2896) 2897 Proposal for an MGCP Advanced Audio Package. D. Cromwell. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2897) 2898 PKCS #5: Password-Based Cryptography Specification Version 2.0. B. Kaliski. September 2000. (Format: TXT, HTML) (Obsoleted by RFC8018) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2898) 2899 Request for Comments Summary RFC Numbers 2800-2899. S. Ginoza. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2899) 2900 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. August 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2906) 2907 MADCAP Multicast Scope Nesting State Option. R. Kermode. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2907) 2908 The Internet Multicast Address Allocation Architecture. D. Thaler, M. Handley, D. Estrin. September 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2912) 2913 MIME Content Types in Media Feature Expressions. G. Klyne. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2913) 2914 Congestion Control Principles. S. Floyd. September 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2917) 2918 Route Refresh Capability for BGP-4. E. Chen. September 2000. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2919) 2920 SMTP Service Extension for Command Pipelining. N. Freed. September 2000. (Format: TXT, HTML) (Obsoletes RFC2197) (Also STD0060) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2920) 2921 6BONE pTLA and pNLA Formats (pTLA). B. Fink. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2921) 2922 Physical Topology MIB. A. Bierman, K. Jones. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2922) 2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2923) 2924 Accounting Attributes and Record Formats. N. Brownlee, A. Blount. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2924) 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. K. White. September 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2926) 2927 MIME Directory Profile for LDAP Schema. M. Wahl. September 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2931) 2932 IPv4 Multicast Routing MIB. K. McCloghrie, D. Farinacci, D. Thaler. October 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2934) 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement. D. Eastlake 3rd, C. Smith. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2935) 2936 HTTP MIME Type Handler Detection. D. Eastlake 3rd, C. Smith, D. Soroka. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2936) 2937 The Name Service Search Option for DHCP. C. Smith. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2937) 2938 Identifying Composite Media Features. G. Klyne, L. Masinter. September 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2940) 2941 Telnet Authentication Option. T. Ts'o, Ed., J. Altman. September 2000. (Format: TXT, HTML) (Obsoletes RFC1416) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2941) 2942 Telnet Authentication: Kerberos Version 5. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2942) 2943 TELNET Authentication Using DSA. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2943) 2944 Telnet Authentication: SRP. T. Wu. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2944) 2945 The SRP Authentication and Key Exchange System. T. Wu. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2945) 2946 Telnet Data Encryption Option. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2946) 2947 Telnet Encryption: DES3 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2947) 2948 Telnet Encryption: DES3 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2948) 2949 Telnet Encryption: CAST-128 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2949) 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2950) 2951 TELNET Authentication Using KEA and SKIPJACK. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2951) 2952 Telnet Encryption: DES 64 bit Cipher Feedback. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2952) 2953 Telnet Encryption: DES 64 bit Output Feedback. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2953) 2954 Definitions of Managed Objects for Frame Relay Service. K. Rehbehn, D. Fowler. October 2000. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2955) 2956 Overview of 1999 IAB Network Layer Workshop. M. Kaat. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2956) 2957 The application/whoispp-query Content-Type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2957) 2958 The application/whoispp-response Content-type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2958) 2959 Real-Time Transport Protocol Management Information Base. M. Baugher, B. Strahm, I. Suconick. October 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2962) 2963 A Rate Adaptive Shaper for Differentiated Services. O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2963) 2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT, HTML) (Also BCP0044) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2964) 2965 HTTP State Management Mechanism. D. Kristol, L. Montulli. October 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2967) 2968 Mesh of Multiple DAG servers - Results from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2968) 2969 Wide Area Directory Deployment - Experiences from TISDAG. T. Eklof, L. Daigle. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2969) 2970 Architecture for Integrated Directory Services - Result from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2970) 2971 IMAP4 ID extension. T. Showalter. October 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2972) 2973 IS-IS Mesh Groups. R. Balay, D. Katz, J. Parker. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2973) 2974 Session Announcement Protocol. M. Handley, C. Perkins, E. Whelan. October 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2974) 2975 Introduction to Accounting Management. B. Aboba, J. Arkko, D. Harrington. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2975) 2976 The SIP INFO Method. S. Donovan. October 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2977) 2978 IANA Charset Registration Procedures. N. Freed, J. Postel. October 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2979) 2980 Common NNTP Extensions. S. Barber. October 2000. (Format: TXT, HTML) (Updated by RFC3977, RFC4643, RFC4644, RFC6048) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2980) 2981 Event MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2981) 2982 Distributed Management Expression MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2982) 2983 Differentiated Services and Tunnels. D. Black. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2983) 2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams. October 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2985) 2986 PKCS #10: Certification Request Syntax Specification Version 1.7. M. Nystrom, B. Kaliski. November 2000. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2987) 2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2989) 2990 Next Steps for the IP QoS Architecture. G. Huston. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2990) 2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D. Thaler, C. Hopps. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2991) 2992 Analysis of an Equal-Cost Multi-Path Algorithm. C. Hopps. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2992) 2993 Architectural Implications of NAT. T. Hain. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2993) 2994 A Description of the MISTY1 Encryption Algorithm. H. Ohta, M. Matsui. November 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2995) 2996 Format of the RSVP DCLASS Object. Y. Bernet. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2996) 2997 Specification of the Null Service Type. Y. Bernet, A. Smith, B. Davie. November 2000. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2998) 2999 Request for Comments Summary RFC Numbers 2900-2999. S. Ginoza. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2999) 3000 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, L. Shiota. November 2001. (Format: TXT, HTML) (Obsoletes RFC2900) (Obsoleted by RFC3300) (Status: HISTORIC) (DOI: 10.17487/RFC3000) 3001 A URN Namespace of Object Identifiers. M. Mealling. November 2000. (Format: TXT, HTML) (Obsoleted by RFC3061) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3001) 3002 Overview of 2000 IAB Wireless Internetworking Workshop. D. Mitzel. December 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3002) 3003 The audio/mpeg Media Type. M. Nilsson. November 2000. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3004) 3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3006) 3007 Secure Domain Name System (DNS) Dynamic Update. B. Wellington. November 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC3530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3010) 3011 The IPv4 Subnet Selection Option for DHCP. G. Waters. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3011) 3012 Mobile IPv4 Challenge/Response Extensions. C. Perkins, P. Calhoun. November 2000. (Format: TXT, HTML) (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, HTML) (Also BCP0046) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3013) 3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3017) 3018 Unified Memory Space Protocol Specification. A. Bogdanov. December 2000. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3021) 3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. (Format: TXT, HTML) (Obsoletes RFC1631) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3022) 3023 XML Media Types. M. Murata, S. St. Laurent, D. Kohn. January 2001. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3024) 3025 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. February 2001. (Format: TXT, HTML) (Obsoleted by RFC3115) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3025) 3026 Liaison to IETF/ISOC on ENUM. R. Blane. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3026) 3027 Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3027) 3028 Sieve: A Mail Filtering Language. T. Showalter. January 2001. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3029) 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. December 2000. (Format: TXT, HTML) (Obsoletes RFC1830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3030) 3031 Multiprotocol Label Switching Architecture. E. Rosen, A. Viswanathan, R. Callon. January 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3035) 3036 LDP Specification. L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5036) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3036) 3037 LDP Applicability. B. Thomas, E. Gray. January 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3040) 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8254) (Status: HISTORIC) (DOI: 10.17487/RFC3044) 3045 Storing Vendor Information in the LDAP root DSE. M. Meredith. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3045) 3046 DHCP Relay Agent Information Option. M. Patrick. January 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3048) 3049 TN3270E Service Location and Session Balancing. J. Naugle, K. Kasthurirangan, G. Ledford. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3049) 3050 Common Gateway Interface for SIP. J. Lennox, H. Schulzrinne, J. Rosenberg. January 2001. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3051) 3052 Service Management Architectures Issues and Review. M. Eder, S. Nag. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3052) 3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini, D. Lento. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3053) 3054 Megaco IP Phone Media Gateway Application Profile. P. Blatherwick, R. Bell, P. Holland. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3054) 3055 Management Information Base for the PINT Services Architecture. M. Krishnaswamy, D. Romascanu. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3055) 3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3058) 3059 Attribute List Extension for the Service Location Protocol. E. Guttman. February 2001. (Format: TXT, HTML) (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, HTML) (Updated by RFC3460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3060) 3061 A URN Namespace of Object Identifiers. M. Mealling. February 2001. (Format: TXT, HTML) (Obsoletes RFC3001) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3061) 3062 LDAP Password Modify Extended Operation. K. Zeilenga. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3062) 3063 MPLS Loop Prevention Mechanism. Y. Ohba, Y. Katsube, E. Rosen, P. Doolan. February 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3063) 3064 MGCP CAS Packages. B. Foster. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3064) 3065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. February 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3067) 3068 An Anycast Prefix for 6to4 Relay Routers. C. Huitema. June 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3070) 3071 Reflections on the DNS, RFC 1591, and Categories of Domains. J. Klensin. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3071) 3072 Structured Data Exchange Format (SDXF). M. Wildgrube. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3072) 3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration. J. Collins. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3073) 3074 DHC Load Balancing Algorithm. B. Volz, S. Gonczi, T. Lemon, R. Stevens. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3074) 3075 XML-Signature Syntax and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2001. (Format: TXT, HTML) (Obsoleted by RFC3275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3075) 3076 Canonical XML Version 1.0. J. Boyer. March 2001. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3077) 3078 Microsoft Point-To-Point Encryption (MPPE) Protocol. G. Pall, G. Zorn. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3078) 3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). G. Zorn. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3079) 3080 The Blocks Extensible Exchange Protocol Core. M. Rose. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3080) 3081 Mapping the BEEP Core onto TCP. M. Rose. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3081) 3082 Notification and Subscription for SLP. J. Kempf, J. Goldschmidt. March 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3084) 3085 URN Namespace for NewsML Resources. A. Coates, D. Allen, D. Rivers-Moore. March 2001. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3086) 3087 Control of Service Context using SIP Request-URI. B. Campbell, R. Sparks. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3087) 3088 OpenLDAP Root Service An experimental LDAP referral service. K. Zeilenga. April 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3088) 3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. H. Kitamura. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3089) 3090 DNS Security Extension Clarification on Zone Status. E. Lewis. March 2001. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3090) 3091 Pi Digit Generation Protocol. H. Kennedy. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3091) 3092 Etymology of "Foo". D. Eastlake 3rd, C. Manros, E. Raymond. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3092) 3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. 1 April 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3096) 3097 RSVP Cryptographic Authentication -- Updated Message Type Value. R. Braden, L. Zhang. April 2001. (Format: TXT, HTML) (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, HTML) (Also FYI0038) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3098) 3099 Request for Comments Summary RFC Numbers 3000-3099. S. Ginoza. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3099) 3100 Not Issued. 3101 The OSPF Not-So-Stubby Area (NSSA) Option. P. Murphy. January 2003. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3102) 3103 Realm Specific IP: Protocol Specification. M. Borella, D. Grabelsky, J. Lo, K. Taniguchi. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3103) 3104 RSIP Support for End-to-end IPsec. G. Montenegro, M. Borella. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3104) 3105 Finding an RSIP Server with SLP. J. Kempf, G. Montenegro. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3105) 3106 ECML v1.1: Field Specifications for E-Commerce. D. Eastlake 3rd, T. Goldstein. April 2001. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC8277) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3111) 3112 LDAP Authentication Password Schema. K. Zeilenga. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3112) 3113 3GPP-IETF Standardization Collaboration. K. Rosenbrock, R. Sanmugam, S. Bradner, J. Klensin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3113) 3114 Implementing Company Classification Policy with the S/MIME Security Label. W. Nicolls. May 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3114) 3115 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. April 2001. (Format: TXT, HTML) (Obsoletes RFC3025) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3115) 3116 Methodology for ATM Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3116) 3117 On the Design of Application Protocols. M. Rose. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3117) 3118 Authentication for DHCP Messages. R. Droms, Ed., W. Arbaugh, Ed.. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3118) 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. June 2001. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3120) 3121 A URN Namespace for OASIS. K. Best, N. Walsh. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3121) 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. A. Conta. June 2001. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3123) 3124 The Congestion Manager. H. Balakrishnan, S. Seshan. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3124) 3125 Electronic Signature Policies. J. Ross, D. Pinkas, N. Pope. September 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3127) 3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858). I. Miller. June 2001. (Format: TXT, HTML) (Updates RFC1858) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3128) 3129 Requirements for Kerberized Internet Negotiation of Keys. M. Thomas. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3129) 3130 Notes from the State-Of-The-Technology: DNSSEC. E. Lewis. June 2001. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3131) 3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement. J. Kempf. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3132) 3133 Terminology for Frame Relay Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3133) 3134 Terminology for ATM ABR Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3135) 3136 The SPIRITS Architecture. L. Slutsman, Ed., I. Faynberg, H. Lu, M. Weissman. June 2001. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC6987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3137) 3138 Extended Assignments in 233/8. D. Meyer. June 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3141) 3142 An IPv6-to-IPv4 Transport Relay Translator. J. Hagino, K. Yamamoto. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3142) 3143 Known HTTP Proxy/Caching Problems. I. Cooper, J. Dilley. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3143) 3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring. D. Romascanu. August 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3144) 3145 L2TP Disconnect Cause Information. R. Verma, M. Verma, J. Carlson. July 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3145) 3146 Transmission of IPv6 Packets over IEEE 1394 Networks. K. Fujisawa, A. Onoe. October 2001. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3146) 3147 Generic Routing Encapsulation over CLNS Networks. P. Christian. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3147) 3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics. M. Mathis, M. Allman. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3148) 3149 MGCP Business Phone Packages. A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram. September 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3151) 3152 Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC2015) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3156) 3157 Securely Available Credentials - Requirements. A. Arsenault, S. Farrell. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3157) 3158 RTP Testing Strategies. C. Perkins, J. Rosenberg, H. Schulzrinne. August 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC5816) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3161) 3162 RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. (Format: TXT, HTML) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3162) 3163 ISO/IEC 9798-3 Authentication SASL Mechanism. R. Zuccherato, M. Nystrom. August 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3163) 3164 The BSD Syslog Protocol. C. Lonvick. August 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3166) 3167 Request to Move RFC 1745 to Historic Status. D. Meyer, J. Scudder. August 2001. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2481) (Updates RFC2003, RFC2474, RFC2401, RFC0793) (Updated by RFC4301, RFC6040, RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3168) 3169 Criteria for Evaluating Network Access Server Protocols. M. Beadles, D. Mitton. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3169) 3170 IP Multicast Applications: Challenges and Solutions. B. Quinn, K. Almeroth. September 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3176) 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3178) 3179 Script MIB Extensibility Protocol Version 1.1. J. Schoenwaelder, J. Quittek. October 2001. (Format: TXT, HTML) (Obsoletes RFC2593) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3179) 3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001. (Format: TXT, HTML) (Obsoletes RFC2770) (Also BCP0053) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3180) 3181 Signaled Preemption Priority Policy Element. S. Herzog. October 2001. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2752) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3182) 3183 Domain Security Services using S/MIME. T. Dean, W. Ottaway. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3183) 3184 IETF Guidelines for Conduct. S. Harris. October 2001. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3185) 3186 MAPOS/PPP Tunneling mode. S. Shimizu, T. Kawano, K. Murakami, E. Beier. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3186) 3187 Using International Standard Book Numbers as Uniform Resource Names. J. Hakala, H. Walravens. October 2001. (Format: TXT, HTML) (Obsoleted by RFC8254) (Status: HISTORIC) (DOI: 10.17487/RFC3187) 3188 Using National Bibliography Numbers as Uniform Resource Names. J. Hakala. October 2001. (Format: TXT, HTML) (Obsoleted by RFC8458) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3190) 3191 Minimal GSTN address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC1715) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3194) 3195 Reliable Delivery for syslog. D. New, M. Rose. November 2001. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2639) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3196) 3197 Applicability Statement for DNS MIB Extensions. R. Austein. November 2001. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198) 3199 Request for Comments Summary RFC Numbers 3100-3199. S. Ginoza. February 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3202) 3203 DHCP reconfigure extension. Y. T'Joens, C. Hublet, P. De Schrijver. December 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also BCP0056) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3205) 3206 The SYS and AUTH POP Response Codes. R. Gellens. February 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3206) 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. P. Hoffman. February 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3210) 3211 Password-based Encryption for CMS. P. Gutmann. December 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3214) 3215 LDP State Machine. C. Boscher, P. Cheval, L. Wu, E. Gray. January 2002. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3216) 3217 Triple-DES and RC2 Key Wrapping. R. Housley. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3217) 3218 Preventing the Million Message Attack on Cryptographic Message Syntax. E. Rescorla. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3218) 3219 Telephony Routing over IP (TRIP). J. Rosenberg, H. Salama, M. Squire. January 2002. (Format: TXT, HTML) (Updated by RFC8602) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3219) 3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3221) 3222 Terminology for Forwarding Information Base (FIB) based Router Performance. G. Trotter. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3222) 3223 Not Issued. 3224 Vendor Extensions for Service Location Protocol, Version 2. E. Guttman. January 2002. (Format: TXT, HTML) (Updates RFC2608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3224) 3225 Indicating Resolver Support of DNSSEC. D. Conrad. December 2001. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3229) 3230 Instance Digests in HTTP. J. Mogul, A. Van Hoff. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3230) 3231 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. January 2002. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3232) 3233 Defining the IETF. P. Hoffman, S. Bradner. February 2002. (Format: TXT, HTML) (Also BCP0058) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3233) 3234 Middleboxes: Taxonomy and Issues. B. Carpenter, S. Brim. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3234) 3235 Network Address Translator (NAT)-Friendly Application Design Guidelines. D. Senie. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3235) 3236 The 'application/xhtml+xml' Media Type. M. Baker, P. Stark. January 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3240) 3241 Robust Header Compression (ROHC) over PPP. C. Bormann. April 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC3950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3250) 3251 Electricity over IP. B. Rajagopalan. 1 April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3251) 3252 Binary Lexical Octet Ad-hoc Transport. H. Kennedy. 1 April 2002. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3253) 3254 Definitions for talking about directories. H. Alvestrand. April 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3256) 3257 Stream Control Transmission Protocol Applicability Statement. L. Coene. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3257) 3258 Distributing Authoritative Name Servers via Shared Unicast Addresses. T. Hardie. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3258) 3259 A Message Bus for Local Coordination. J. Ott, C. Perkins, D. Kutscher. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3259) 3260 New Terminology and Clarifications for Diffserv. D. Grossman. April 2002. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2543) (Updated by RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC5621, RFC5626, RFC5630, RFC5922, RFC5954, RFC6026, RFC6141, RFC6665, RFC6878, RFC7462, RFC7463, RFC8217, RFC8591) (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, HTML) (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, HTML) (Obsoletes RFC2543) (Updated by RFC7984, RFC8553) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3270) 3271 The Internet is for Everyone. V. Cerf. April 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC5755) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3281) 3282 Content Language Headers. H. Alvestrand. May 2002. (Format: TXT, HTML) (Obsoletes RFC1766) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3282) 3283 Guide to Internet Calendaring. B. Mahoney, G. Babics, A. Taler. June 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3286) 3287 Remote Monitoring MIB Extensions for Differentiated Services. A. Bierman. July 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3293) 3294 General Switch Management Protocol (GSMP) Applicability. A. Doria, K. Sundell. June 2002. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3295) 3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories. K. Zeilenga. July 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3298) 3299 Request for Comments Summary RFC Numbers 3200-3299. S. Ginoza. December 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3305) 3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3310) 3311 The Session Initiation Protocol (SIP) UPDATE Method. J. Rosenberg. October 2002. (Format: TXT, HTML) (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, PS, PDF, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3313) 3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. M. Wasserman, Ed.. September 2002. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC8415) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3317) 3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie. March 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3321) 3322 Signaling Compression (SigComp) Requirements & Assumptions. H. Hannu. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3322) 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J. Peterson. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3323) 3324 Short Term Requirements for Network Asserted Identity. M. Watson. November 2002. (Format: TXT, HTML) (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, HTML) (Updated by RFC5876, RFC8217) (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, HTML) (Updated by RFC8606) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3329) 3330 Special-Use IPv4 Addresses. IANA. September 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC4666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3332) 3333 Not Issued. 3334 Policy-Based Accounting. T. Zseby, S. Zander, C. Carle. October 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3339) 3340 The Application Exchange Core. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3340) 3341 The Application Exchange (APEX) Access Service. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3342) 3343 The Application Exchange (APEX) Presence Service. M. Rose, G. Klyne, D. Crocker. April 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3343) 3344 IP Mobility Support for IPv4. C. Perkins, Ed.. August 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0059) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3349) 3350 Not Issued. 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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3351) 3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status. K. Zeilenga. March 2003. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3353) 3354 Internet Open Trading Protocol Version 2 Requirements. D. Eastlake 3rd. August 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3357) 3358 Optional Checksums in Intermediate System to Intermediate System (ISIS). T. Przygienda. August 2002. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3359) 3360 Inappropriate TCP Resets Considered Harmful. S. Floyd. August 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3367) 3368 The 'go' URI Scheme for the Common Name Resolution Protocol. M. Mealling. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3368) 3369 Cryptographic Message Syntax (CMS). R. Housley. August 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3374) 3375 Generic Registry-Registrar Protocol Requirements. S. Hollenbeck. September 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3378) 3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements. D. Pinkas, R. Housley. September 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3385) 3386 Network Hierarchy and Multilayer Survivability. W. Lai, Ed., D. McDysan, Ed.. November 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3389) 3390 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. October 2002. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3391) 3392 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. November 2002. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3393) 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad, R. Housley. September 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3398) 3399 Not Issued. 3400 Not Issued. 3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS. M. Mealling. October 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2611) (Obsoleted by RFC8141) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3406) 3407 Session Description Protocol (SDP) Simple Capability Declaration. F. Andreasen. October 2002. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3408) 3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression. K. Svanbro. December 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3419) 3420 Internet Media Type message/sipfrag. R. Sparks. November 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3424) 3425 Obsoleting IQUERY. D. Lawrence. November 2002. (Format: TXT, HTML) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3425) 3426 General Architectural and Policy Considerations. S. Floyd. November 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8591) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3429) 3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping. J. Schoenwaelder. December 2002. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3430) 3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3432) 3433 Entity Sensor Management Information Base. A. Bierman, D. Romascanu, K.C. Norseth. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3433) 3434 Remote Monitoring MIB Extensions for High Capacity Alarms. A. Bierman, K. McCloghrie. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3434) 3435 Media Gateway Control Protocol (MGCP) Version 1.0. F. Andreasen, B. Foster. January 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3444) 3445 Limiting the Scope of the KEY Resource Record (RR). D. Massey, S. Rose. December 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3453) 3454 Preparation of Internationalized Strings ("stringprep"). P. Hoffman, M. Blanchet. December 2002. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3456) 3457 Requirements for IPsec Remote Access Scenarios. S. Kelly, S. Ramamoorthi. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3457) 3458 Message Context for Internet Mail. E. Burger, E. Candell, C. Eliot, G. Klyne. January 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1891) (Updated by RFC3798, RFC3885, RFC5337, RFC6533, RFC8098) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC7336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3466) 3467 Role of the Domain Name System (DNS). J. Klensin. February 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC4201, RFC4328, RFC4872, RFC6002, RFC6003, RFC6205, RFC7074, RFC7699, RFC8359) (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, HTML) (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, HTML) (Updated by RFC4003, RFC4201, RFC4420, RFC4783, RFC4874, RFC4873, RFC4974, RFC5063, RFC5151, RFC5420, RFC6002, RFC6003, RFC6780, RFC8359) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3478) 3479 Fault Tolerance for the Label Distribution Protocol (LDP). A. Farrel, Ed.. February 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3483) 3484 Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format: TXT, HTML) (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, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3485) 3486 Compressing the Session Initiation Protocol (SIP). G. Camarillo. February 2003. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3487) 3488 Cisco Systems Router-port Group Management Protocol (RGMP). I. Wu, T. Eckert. February 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3498) 3499 Request for Comments Summary RFC Numbers 3400-3499. S. Ginoza. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3499) 3500 Not Issued. 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. M. Crispin. March 2003. (Format: TXT, HTML) (Obsoletes RFC2060) (Updated by RFC4466, RFC4469, RFC4551, RFC5032, RFC5182, RFC5738, RFC6186, RFC6858, RFC7817, RFC8314, RFC8437, RFC8474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3501) 3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension. M. Crispin. March 2003. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3503) 3504 Internet Open Trading Protocol (IOTP) Version 1, Errata. D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3504) 3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements. D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3505) 3506 Requirements and Design for Voucher Trading System (VTS). K. Fujimura, D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3506) 3507 Internet Content Adaptation Protocol (ICAP). J. Elson, A. Cerpa. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3507) 3508 H.323 Uniform Resource Locator (URL) Scheme Registration. O. Levin. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3508) 3509 Alternative Implementations of OSPF Area Border Routers. A. Zinin, A. Lindem, D. Yeung. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3509) 3510 Internet Printing Protocol/1.1: IPP URL Scheme. R. Herriot, I. McDonald. April 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3512) 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. (Format: TXT, HTML) (Obsoletes RFC2373) (Obsoleted by RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3513) 3514 The Security Flag in the IPv4 Header. S. Bellovin. 1 April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3514) 3515 The Session Initiation Protocol (SIP) Refer Method. R. Sparks. April 2003. (Format: TXT, HTML) (Updated by RFC7647, RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3515) 3516 IMAP4 Binary Content Extension. L. Nerenberg. April 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3521) 3522 The Eifel Detection Algorithm for TCP. R. Ludwig, M. Meyer. April 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3522) 3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology. J. Polk. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3523) 3524 Mapping of Media Streams to Resource Reservation Flows. G. Camarillo, A. Monrad. April 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3527) 3528 Mesh-enhanced Service Location Protocol (mSLP). W. Zhao, H. Schulzrinne, E. Guttman. April 2003. (Format: TXT, HTML) (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, HTML) (Updated by RFC8553) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3531) 3532 Requirements for the Dynamic Partitioning of Switching Elements. T. Anderson, J. Buerkle. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3532) 3533 The Ogg Encapsulation Format Version 0. S. Pfeiffer. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3533) 3534 The application/ogg Media Type. L. Walleij. May 2003. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3535) 3536 Terminology Used in Internationalization in the IETF. P. Hoffman. May 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3538) 3539 Authentication, Authorization and Accounting (AAA) Transport Profile. B. Aboba, J. Wood. June 2003. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3540) 3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D). A. Walsh. May 2003. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3542) 3543 Registration Revocation in Mobile IPv4. S. Glass, M. Chandra. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3543) 3544 IP Header Compression over PPP. T. Koren, S. Casner, C. Bormann. July 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, PS, PDF, HTML) (Obsoletes RFC1889) (Updated by RFC5506, RFC5761, RFC6051, RFC6222, RFC7022, RFC7160, RFC7164, RFC8083, RFC8108) (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, PS, PDF, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3554) 3555 MIME Type Registration of RTP Payload Formats. S. Casner, P. Hoschka. July 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC4788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3558) 3559 Multicast Address Allocation MIB. D. Thaler. June 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3561) 3562 Key Management Considerations for the TCP MD5 Signature Option. M. Leech. July 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3568) 3569 An Overview of Source-Specific Multicast (SSM). S. Bhattacharyya, Ed.. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3569) 3570 Content Internetworking (CDI) Scenarios. P. Rzewski, M. Day, D. Gilletti. July 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8064) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3573) 3574 Transition Scenarios for 3GPP Networks. J. Soininen, Ed.. August 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3574) 3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service). B. Aboba. July 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3581) 3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B. Black, V. Gill. August 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3586) 3587 IPv6 Global Unicast Address Format. R. Hinden, S. Deering, E. Nordmark. August 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3589) 3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol. B. Haberman. September 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3594) 3595 Textual Conventions for IPv6 Flow Label. B. Wijnen. September 2003. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3152, RFC1886) (Also STD0088) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3596) 3597 Handling of Unknown DNS Resource Record (RR) Types. A. Gustafsson. September 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3599) 3600 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. November 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3604) 3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). C. Huitema. October 2003. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3606) 3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool. M. Leech. September 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3609) 3610 Counter with CBC-MAC (CCM). D. Whiting, R. Housley, N. Ferguson. September 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3617) 3618 Multicast Source Discovery Protocol (MSDP). B. Fenner, Ed., D. Meyer, Ed.. October 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3618) 3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1. S. Shah, M. Yip. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3619) 3620 The TUNNEL Profile. D. New. October 2003. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3620) 3621 Power Ethernet MIB. A. Berger, D. Romascanu. December 2003. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3622) 3623 Graceful OSPF Restart. J. Moy, P. Pillay-Esnault, A. Lindem. November 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3626) 3627 Use of /127 Prefix Length Between Routers Considered Harmful. P. Savola. September 2003. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3628) 3629 UTF-8, a transformation format of ISO 10646. F. Yergeau. November 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8415) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3634) 3635 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick. September 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3648) 3649 HighSpeed TCP for Large Congestion Windows. S. Floyd. December 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3649) 3650 Handle System Overview. S. Sun, L. Lannom, B. Boesch. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3650) 3651 Handle System Namespace and Service Definition. S. Sun, S. Reilly, L. Lannom. November 2003. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3652) 3653 XML-Signature XPath Filter 2.0. J. Boyer, M. Hughes, J. Reagle. December 2003. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3654) 3655 Redefinition of DNS Authenticated Data (AD) bit. B. Wellington, O. Gudmundsson. November 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3657) 3658 Delegation Signer (DS) Resource Record (RR). O. Gudmundsson. December 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8622) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3662) 3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP). A. Newton. December 2003. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0076) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3666) 3667 IETF Rights in Contributions. S. Bradner. February 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3670) 3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3671) 3672 Subentries in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3672) 3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes. K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3673) 3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Obsoleted by RFC4512) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3674) 3675 .sex Considered Dangerous. D. Eastlake 3rd. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3675) 3676 The Text/Plain Format and DelSp Parameters. R. Gellens. February 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3678) 3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes. R. Droms. January 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3679) 3680 A Session Initiation Protocol (SIP) Event Package for Registrations. J. Rosenberg. March 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3684) 3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C. Daboo. February 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3687) 3688 The IETF XML Registry. M. Mealling. January 2004. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3689) 3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3690) 3691 Internet Message Access Protocol (IMAP) UNSELECT command. A. Melnikov. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3691) 3692 Assigning Experimental and Testing Numbers Considered Useful. T. Narten. January 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC6280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3694) 3695 Compact Forward Error Correction (FEC) Schemes. M. Luby, L. Vicisano. February 2004. (Format: TXT, HTML) (Obsoleted by RFC5445) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3695) 3696 Application Techniques for Checking and Transformation of Names. J. Klensin. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3696) 3697 IPv6 Flow Label Specification. J. Rajahalme, A. Conta, B. Carpenter, S. Deering. March 2004. (Format: TXT, HTML) (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, HTML) (Updates RFC2798) (Updated by RFC4517) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3698) 3699 Not Issued. 3700 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. July 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC4104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3703) 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3706) 3707 Cross Registry Internet Service Protocol (CRISP) Requirements. A. Newton. February 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC6170) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3709) 3710 An IESG charter. H. Alvestrand. February 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3714) 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements. B. Aboba, W. Dixon. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3715) 3716 The IETF in the Large: Administration and Execution. IAB Advisory Committee. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3716) 3717 IP over Optical Networks: A Framework. B. Rajagopalan, J. Luciani, D. Awduche. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3717) 3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access. R. McGowan. February 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0085) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3725) 3726 Requirements for Signaling Protocols. M. Brunner, Ed.. April 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3728) 3729 Application Performance Measurement MIB. S. Waldbusser. March 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3729) 3730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4930) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3730) 3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3731) 3732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3732) 3733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3733) 3734 Extensible Provisioning Protocol (EPP) Transport Over TCP. S. Hollenbeck. March 2004. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3735) 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT, HTML) (Obsoleted by RFC8415) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3039) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3739) 3740 The Multicast Group Security Architecture. T. Hardjono, B. Weis. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3740) 3741 Exclusive XML Canonicalization, Version 1.0. J. Boyer, D. Eastlake 3rd, J. Reagle. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3741) 3742 Limited Slow-Start for TCP with Large Congestion Windows. S. Floyd. March 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3746) 3747 The Differentiated Services Configuration MIB. H. Hazewinkel, Ed., D. Partain, Ed.. April 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8447) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3750) 3751 Omniscience Protocol Requirements. S. Bradner. 1 April 2004. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3752) 3753 Mobility Related Terminology. J. Manner, Ed., M. Kojo, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3753) 3754 IP Multicast in Differentiated Services (DS) Networks. R. Bless, K. Wehrle. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3754) 3755 Legacy Resolver Compatibility for Delegation Signer (DS). S. Weiler. May 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3758) 3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples. L-E. Jonsson. April 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3763) 3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record. J. Peterson. April 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also BCP0086) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3766) 3767 Securely Available Credentials Protocol. S. Farrell, Ed.. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3767) 3768 Virtual Router Redundancy Protocol (VRRP). R. Hinden, Ed.. April 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3772) 3773 High-Level Requirements for Internet Voice Mail. E. Candell. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3773) 3774 IETF Problem Statement. E. Davies, Ed.. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3774) 3775 Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8118) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3779) 3780 SMIng - Next Generation Structure of Management Information. F. Strauss, J. Schoenwaelder. May 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3796) 3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection. D. Eastlake 3rd. June 2004. (Format: TXT, HTML) (Obsoletes RFC2777) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3797) 3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil, Ed.. May 2004. (Format: TXT, HTML) (Obsoletes RFC2298) (Obsoleted by RFC8098) (Updates RFC3461, RFC2046) (Updated by RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3798) 3799 Not Issued. 3800 Not Issued. 3801 Voice Profile for Internet Mail - version 2 (VPIMv2). G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2422) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3802) 3803 Content Duration MIME Header Definition. G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (Obsoletes RFC2424) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3803) 3804 Voice Profile for Internet Mail (VPIM) Addressing. G. Parsons. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3804) 3805 Printer MIB v2. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT, HTML) (Obsoletes RFC1759) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3805) 3806 Printer Finishing MIB. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3806) 3807 V5.2-User Adaptation Layer (V5UA). E. Weilandt, N. Khanchandani, S. Rao. June 2004. (Format: TXT, HTML) (Updates RFC3057) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3807) 3808 IANA Charset MIB. I. McDonald. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3808) 3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN). A. Nagarajan, Ed.. June 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3817) 3818 IANA Considerations for the Point-to-Point Protocol (PPP). V. Schryver. June 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3820) 3821 Fibre Channel Over TCP/IP (FCIP). M. Rajagopal, E. Rodriguez, R. Weber. July 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3826) 3827 Additional Snoop Datalink Types. K. Sarcar. June 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3832) 3833 Threat Analysis of the Domain Name System (DNS). D. Atkins, R. Austein. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3833) 3834 Recommendations for Automatic Responses to Electronic Mail. K. Moore. August 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3844) 3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. J. Schlyter, Ed.. August 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC5306) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3847) 3848 ESMTP and LMTP Transmission Types Registration. C. Newman. July 2004. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3848) 3849 IPv6 Address Prefix Reserved for Documentation. G. Huston, A. Lord, P. Smith. July 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2633) (Obsoleted by RFC5751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3851) 3852 Cryptographic Message Syntax (CMS). R. Housley. July 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3855) 3856 A Presence Event Package for the Session Initiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3857) 3858 An Extensible Markup Language (XML) Based Format for Watcher Information. J. Rosenberg. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3858) 3859 Common Profile for Presence (CPP). J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3859) 3860 Common Profile for Instant Messaging (CPIM). J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3860) 3861 Address Resolution for Instant Messaging and Presence. J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3861) 3862 Common Presence and Instant Messaging (CPIM): Message Format. G. Klyne, D. Atkins. August 2004. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3863) 3864 Registration Procedures for Message Header Fields. G. Klyne, M. Nottingham, J. Mogul. September 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3869) 3870 application/rdf+xml Media Type Registration. A. Swartz. September 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3873) 3874 A 224-bit One-way Hash Function: SHA-224. R. Housley. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3874) 3875 The Common Gateway Interface (CGI) Version 1.1. D. Robinson, K. Coar. October 2004. (Format: TXT, PDF, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3876) 3877 Alarm Management Information Base (MIB). S. Chisholm, D. Romascanu. September 2004. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3878) 3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. September 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3881) 3882 Configuring BGP to Block Denial-of-Service Attacks. D. Turk. September 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3884) 3885 SMTP Service Extension for Message Tracking. E. Allman, T. Hansen. September 2004. (Format: TXT, HTML) (Updates RFC3461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3885) 3886 An Extensible Message Format for Message Tracking Responses. E. Allman. September 2004. (Format: TXT, HTML) (Updates RFC3463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3886) 3887 Message Tracking Query Protocol. T. Hansen. September 2004. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3887) 3888 Message Tracking Model and Requirements. T. Hansen. September 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3891) 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism. R. Sparks. September 2004. (Format: TXT, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3892) 3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format. J. Peterson. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3893) 3894 Sieve Extension: Copying Without Side Effects. J. Degener. October 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3898) 3899 Not Issued. 3900 Not Issued. 3901 DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3902) 3903 Session Initiation Protocol (SIP) Extension for Event State Publication. A. Niemi, Ed.. October 2004. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3904) 3905 A Template for IETF Patent Disclosures and Licensing Declarations. V. See, Ed.. September 2004. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3906) 3907 Not Issued. 3908 Not Issued. 3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation. K. Zeilenga. October 2004. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3910) 3911 The Session Initiation Protocol (SIP) "Join" Header. R. Mahy, D. Petrie. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3911) 3912 WHOIS Protocol Specification. L. Daigle. September 2004. (Format: TXT, HTML) (Obsoletes RFC0954, RFC0812) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3912) 3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification. D. Thaler. September 2004. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3913) 3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations. A. Barbir, A. Rousskov. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3914) 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. September 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3917) 3918 Methodology for IP Multicast Benchmarking. D. Stopp, B. Hickman. October 2004. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3919) 3920 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre, Ed.. October 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3929) 3930 The Protocol versus Document Points of View in Computer Protocols. D. Eastlake 3rd. October 2004. (Format: TXT, HTML) (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, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3931) 3932 The IESG and RFC Editor Documents: Procedures. H. Alvestrand. October 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3937) 3938 Video-Message Message-Context. T. Hansen. October 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3943) 3944 H.350 Directory Services. T. Johnson, S. Okubo, S. Campos. December 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3944) 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture. E. Mannie, Ed.. October 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3952) 3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services. J. Peterson. January 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3954) 3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX). S. Leinen. October 2004. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8553) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3960) 3961 Encryption and Checksum Specifications for Kerberos 5. K. Raeburn. February 2005. (Format: TXT, HTML) (Updated by RFC8429) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3961) 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5. K. Raeburn. February 2005. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3963) 3964 Security Considerations for 6to4. P. Savola, C. Patel. December 2004. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2305) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3965) 3966 The tel URI for Telephone Numbers. H. Schulzrinne. December 2004. (Format: TXT, HTML) (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, HTML) (Updated by RFC4897, RFC8067) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6494, RFC6495, RFC6980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3971) 3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3973) 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments. M. Nakamura, J. Hagino. January 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3974) 3975 OMA-IETF Standardization Collaboration. G. Huston, Ed., I. Leuca, Ed.. January 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3976) 3977 Network News Transfer Protocol (NNTP). C. Feather. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3668) (Obsoleted by RFC8179) (Updates RFC2026, RFC2028) (Updated by RFC4879) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3988) 3989 Middlebox Communications (MIDCOM) Protocol Semantics. M. Stiemerling, J. Quittek, T. Taylor. February 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3990) 3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package. B. Foster, F. Andreasen. February 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3991) 3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism. B. Foster, F. Andreasen. February 2005. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3993) 3994 Indication of Message Composition for Instant Messaging. H. Schulzrinne. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3994) 3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions. R. Herriot, T. Hastings. March 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3998) 3999 Not Issued. 4000 Not Issued. 4001 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. February 2005. (Format: TXT, HTML) (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, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4002) 4003 GMPLS Signaling Procedure for Egress Control. L. Berger. February 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8506) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4010) 4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal. March 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4014) 4015 The Eifel Response Algorithm for TCP. R. Ludwig, A. Gurtov. February 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC5332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4023) 4024 Voice Messaging Client Behaviour. G. Parsons, J. Maruszak. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4024) 4025 A Method for Storing IPsec Keying Material in DNS. M. Richardson. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4025) 4026 Provider Provisioned Virtual Private Network (VPN) Terminology. L. Andersson, T. Madsen. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4026) 4027 Domain Name System Media Types. S. Josefsson. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4027) 4028 Session Timers in the Session Initiation Protocol (SIP). S. Donovan, J. Rosenberg. April 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4031) 4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework. G. Camarillo, P. Kyzivat. March 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC4470, RFC6014, RFC6840, RFC8198) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4036) 4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core. A. Rousskov. March 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4039) 4040 RTP Payload Format for a 64 kbit/s Transparent Call. R. Kreuter. April 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4040) 4041 Requirements for Morality Sections in Routing Area Drafts. A. Farrel. 1 April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4041) 4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode. M. Crispin. 1 April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4042) 4043 Internet X.509 Public Key Infrastructure Permanent Identifier. D. Pinkas, T. Gindin. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4043) 4044 Fibre Channel Management MIB. K. McCloghrie. May 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4047) 4048 RFC 1888 Is Obsolete. B. Carpenter. April 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4050) 4051 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4056) 4057 IPv6 Enterprise Network Scenarios. J. Bound, Ed.. June 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4061) 4062 OSPF Benchmarking Terminology and Concepts. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4062) 4063 Considerations When Using Basic OSPF Convergence Benchmarks. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4063) 4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4. A. Patel, K. Leung. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4064) 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations. J. Kempf. July 2005. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4066) 4067 Context Transfer Protocol (CXTP). J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli. July 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4067) 4068 Fast Handovers for Mobile IPv6. R. Koodli, Ed.. July 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7268, RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4072) 4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS). R. Housley. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4073) 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses. Y. Morishita, T. Jinmei. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4074) 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6. V. Kalusivalingam. May 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4076) 4077 A Negative Acknowledgement Mechanism for Signaling Compression. A.B. Roach. May 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4078) 4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects. J. Peterson. July 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4080) 4081 Security Threats for Next Steps in Signaling (NSIS). H. Tschofenig, D. Kroeselberg. June 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4083) 4084 Terminology for Describing Internet Connectivity. J. Klensin. May 2005. (Format: TXT, HTML) (Also BCP0104) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4084) 4085 Embedding Globally-Routable Internet Addresses Considered Harmful. D. Plonka. June 2005. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1750) (Also BCP0106) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4086) 4087 IP Tunnel MIB. D. Thaler. June 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8271, RFC8537) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4093) 4094 Analysis of Existing Quality-of-Service Signaling Protocols. J. Manner, X. Fu. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4094) 4095 Attaching Meaning to Solicitation Class Keywords. C. Malamud. May 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4096) 4097 Middlebox Communications (MIDCOM) Protocol Evaluation. M. Barnes, Ed.. June 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4098) 4099 Not Issued. 4100 Not Issued. 4101 Writing Protocol Models. E. Rescorla, IAB. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4101) 4102 Registration of the text/red MIME Sub-Type. P. Jones. June 2005. (Format: TXT, HTML) (Updated by RFC6354) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4102) 4103 RTP Payload for Text Conversation. G. Hellstrom, P. Jones. June 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4106) 4107 Guidelines for Cryptographic Key Management. S. Bellovin, R. Housley. June 2005. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4108) 4109 Algorithms for Internet Key Exchange version 1 (IKEv1). P. Hoffman. May 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4110) 4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs). L. Fang, Ed.. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4111) 4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification. D. Eastlake 3rd. June 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4118) 4119 A Presence-based GEOPRIV Location Object Format. J. Peterson. December 2005. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1510) (Updated by RFC4537, RFC5021, RFC5896, RFC6111, RFC6112, RFC6113, RFC6649, RFC6806, RFC7751, RFC8062, RFC8129, RFC8429, RFC8553) (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, HTML) (Updates RFC1964) (Updated by RFC6112, RFC6542, RFC6649, RFC8062) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4122) 4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements. H. Schulzrinne, C. Agboh. July 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, PDF, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC5932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4132) 4133 Entity MIB (Version 3). A. Bierman, K. McCloghrie. August 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4134) 4135 Goals of Detecting Network Attachment in IPv6. JH. Choi, G. Daley. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4135) 4136 OSPF Refresh and Flooding Reduction in Stable Topologies. P. Pillay-Esnault. July 2005. (Format: TXT, HTML) (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, PDF, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4141) 4142 Full-mode Fax Profile for Internet Mail (FFPIM). D. Crocker, G. Klyne. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4142) 4143 Facsimile Using Internet Mail (IFAX) Service of ENUM. K. Toyoda, D. Crocker. November 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC4572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4145) 4146 Simple New Mail Notification. R. Gellens. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4146) 4147 Proposed Changes to the Format of the IANA IPv6 Registry. G. Huston. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4147) 4148 IP Performance Metrics (IPPM) Metrics Registry. E. Stephan. August 2005. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4149) 4150 Transport Performance Metrics MIB. R. Dietz, R. Cole. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4150) 4151 The 'tag' URI Scheme. T. Kindberg, S. Hawke. October 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4152) 4153 XML Voucher: Generic Voucher Language. K. Fujimura, M. Terada, D. Eastlake 3rd. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4153) 4154 Voucher Trading System Application Programming Interface (VTS-API). M. Terada, K. Fujimura. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4154) 4155 The application/mbox Media Type. E. Hall. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4155) 4156 The wais URI Scheme. P. Hoffman. August 2005. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4156) 4157 The prospero URI Scheme. P. Hoffman. August 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4158) 4159 Deprecation of "ip6.int". G. Huston. August 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4163) 4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles. G. Pelletier. August 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4166) 4167 Graceful OSPF Restart Implementation Report. A. Lindem. October 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4169) 4170 Tunneling Multiplexed Compressed RTP (TCRTP). B. Thompson, T. Koren, D. Wing. November 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4176) 4177 Architectural Approaches to Multi-homing for IPv6. G. Huston. September 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4179) 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files. Y. Shafranovich. October 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4183) 4184 RTP Payload Format for AC-3 Audio. B. Link, T. Hager, J. Flaks. October 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4190) 4191 Default Router Preferences and More-Specific Routes. R. Draves, D. Thaler. November 2005. (Format: TXT, HTML) (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, HTML) (Updates RFC2072) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4192) 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4193) 4194 The S Hexdump Format. J. Strombergson, L. Walleij, P. Faltstrom. October 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4197) 4198 A Uniform Resource Name (URN) Namespace for Federated Content. D. Tessman. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4198) 4199 Not Issued. 4200 Not Issued. 4201 Link Bundling in MPLS Traffic Engineering (TE). K. Kompella, Y. Rekhter, L. Berger. October 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4212) 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4216) 4217 Securing FTP with TLS. P. Ford-Hutchinson. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4217) 4218 Threats Relating to IPv6 Multihoming Solutions. E. Nordmark, T. Li. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4218) 4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About. E. Lear. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4219) 4220 Traffic Engineering Link Management Information Base. M. Dubuc, T. Nadeau, J. Lang. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4220) 4221 Multiprotocol Label Switching (MPLS) Management Overview. T. Nadeau, C. Srinivasan, A. Farrel. November 2005. (Format: TXT, HTML) (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, HTML) (Also BCP0112) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4222) 4223 Reclassification of RFC 1863 to Historic. P. Savola. October 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3288) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4227) 4228 Requirements for an IETF Draft Submission Toolset. A. Rousskov. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4228) 4229 HTTP Header Field Registrations. M. Nottingham, J. Mogul. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4229) 4230 RSVP Security Properties. H. Tschofenig, R. Graveman. December 2005. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4231) 4232 Not Issued. 4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. January 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4236) 4237 Voice Messaging Directory Service. G. Vaudreuil. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4237) 4238 Voice Message Routing Service. G. Vaudreuil. October 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4238) 4239 Internet Voice Messaging (IVM). S. McRae, G. Parsons. November 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8415) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4245) 4246 International Standard Audiovisual Number (ISAN) URN Definition. M. Dolan. February 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4247) 4248 The telnet URI Scheme. P. Hoffman. October 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4249) 4250 The Secure Shell (SSH) Protocol Assigned Numbers. S. Lehtinen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8268) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4250) 4251 The Secure Shell (SSH) Protocol Architecture. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4251) 4252 The Secure Shell (SSH) Authentication Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308, RFC8332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4252) 4253 The Secure Shell (SSH) Transport Layer Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC6668, RFC8268, RFC8308, RFC8332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4253) 4254 The Secure Shell (SSH) Connection Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4259) 4260 Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4262) 4263 Media Subtype Registration for Media Type text/troff. B. Lilly. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4263) 4264 BGP Wedgies. T. Griffin, G. Huston. November 2005. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4265) 4266 The gopher URI Scheme. P. Hoffman. November 2005. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4267) 4268 Entity State MIB. S. Chisholm, D. Perkins. November 2005. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC4009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4269) 4270 Attacks on Cryptographic Hashes in Internet Protocols. P. Hoffman, B. Schneier. November 2005. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1771) (Updated by RFC6286, RFC6608, RFC6793, RFC7606, RFC7607, RFC7705, RFC8212, RFC8654) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4271) 4272 BGP Security Vulnerabilities Analysis. S. Murphy. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4272) 4273 Definitions of Managed Objects for BGP-4. J. Haas, Ed., S. Hares, Ed.. January 2006. (Format: TXT, HTML) (Obsoletes RFC1269, RFC1657) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4273) 4274 BGP-4 Protocol Analysis. D. Meyer, K. Patel. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4274) 4275 BGP-4 MIB Implementation Survey. S. Hares, D. Hares. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4275) 4276 BGP-4 Implementation Report. S. Hares, A. Retana. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4276) 4277 Experience with the BGP-4 Protocol. D. McPherson, K. Patel. January 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4285) 4286 Multicast Router Discovery. B. Haberman, J. Martin. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4286) 4287 The Atom Syndication Format. M. Nottingham, Ed., R. Sayre, Ed.. December 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4290) 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT, HTML) (Obsoletes RFC3513) (Updated by RFC5952, RFC6052, RFC7136, RFC7346, RFC7371, RFC8064) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4291) 4292 IP Forwarding Table MIB. B. Haberman. April 2006. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2011, RFC2465, RFC2466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4293) 4294 IPv6 Node Requirements. J. Loughney, Ed.. April 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4298) 4299 Not Issued. 4300 Not Issued. 4301 Security Architecture for the Internet Protocol. S. Kent, K. Seo. December 2005. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4302) 4303 IP Encapsulating Security Payload (ESP). S. Kent. December 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4307) 4308 Cryptographic Suites for IPsec. P. Hoffman. December 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4313) 4314 IMAP4 Access Control List (ACL) Extension. A. Melnikov. December 2005. (Format: TXT, HTML) (Obsoletes RFC2086) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4314) 4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension. M. Crispin. December 2005. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4316) 4317 Session Description Protocol (SDP) Offer/Answer Examples. A. Johnston, R. Sparks. December 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4321) 4322 Opportunistic Encryption using the Internet Key Exchange (IKE). M. Richardson, D.H. Redelmeier. December 2005. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4323) 4324 Calendar Access Protocol (CAP). D. Royer, G. Babics, S. Mansour. December 2005. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3471) (Updated by RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4328) 4329 Scripting Media Types. B. Hoehrmann. April 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4336) 4337 MIME Type Registration for MPEG-4. Y Lim, D. Singer. March 2006. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3831, RFC2625) (Updated by RFC5494, RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4338) 4339 IPv6 Host Configuration of DNS Server Information Approaches. J. Jeong, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4339) 4340 Datagram Congestion Control Protocol (DCCP). E. Kohler, M. Handley, S. Floyd. March 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC8311) (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, HTML) (Updated by RFC5348, RFC6323, RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4342) 4343 Domain Name System (DNS) Case Insensitivity Clarification. D. Eastlake 3rd. January 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4352) 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP). J. Rosenberg. February 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4359) 4360 BGP Extended Communities Attribute. S. Sangli, D. Tappan, Y. Rekhter. February 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4370) 4371 BCP 101 Update for IPR Trust. B. Carpenter, Ed., L. Lynch, Ed.. January 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4373) 4374 The application/xv+xml Media Type. G. McCobb. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4374) 4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain. K. Carlberg. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4375) 4376 Requirements for Floor Control Protocols. P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu. February 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4378) 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. K. Kompella, G. Swallow. February 2006. (Format: TXT, HTML) (Obsoleted by RFC8029) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4383) 4384 BGP Communities for Data Collection. D. Meyer. February 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8553) (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, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4387) 4388 Dynamic Host Configuration Protocol (DHCP) Leasequery. R. Woundy, K. Kinnear. February 2006. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4389) 4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand. V. Kashyap. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4390) 4391 Transmission of IP over InfiniBand (IPoIB). J. Chu, V. Kashyap. April 2006. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4391) 4392 IP over InfiniBand (IPoIB) Architecture. V. Kashyap. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4392) 4393 MIME Type Registrations for 3GPP2 Multimedia Files. H. Garudadri. March 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4397) 4398 Storing Certificates in the Domain Name System (DNS). S. Josefsson. March 2006. (Format: TXT, HTML) (Obsoletes RFC2538) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4398) 4399 Not Issued. 4400 Not Issued. 4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API). N. Williams. February 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4405) 4406 Sender ID: Authenticating E-Mail. J. Lyon, M. Wong. April 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4406) 4407 Purported Responsible Address in E-Mail Messages. J. Lyon. April 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4410) 4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events. J. Polk. February 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC7134) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4412) 4413 TCP/IP Field Behavior. M. West, S. McCann. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4413) 4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS). A. Newton. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4414) 4415 IANA Registration for Enumservice Voice. R. Brandner, L. Conroy, R. Stastny. February 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4417) 4418 UMAC: Message Authentication Code using Universal Hashing. T. Krovetz, Ed.. March 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC8270) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4422) 4423 Host Identity Protocol (HIP) Architecture. R. Moskowitz, P. Nikander. May 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4428) 4429 Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4430) 4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record. M. Andrews, S. Weiler. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4431) 4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol. B. Harris. March 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4435) 4436 Detecting Network Attachment in IPv4 (DNAv4). B. Aboba, J. Carlson, S. Cheshire. March 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4440) 4441 The IEEE 802/IETF Relationship. B. Aboba, Ed.. March 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4443) 4444 Management Information Base for Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4444) 4445 A Proposed Media Delivery Index (MDI). J. Welch, J. Clark. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4445) 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3). L. Martini. April 2006. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC8077) (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, HTML) (Updated by RFC5462, RFC8469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4448) 4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key. C. Perkins. June 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4450) 4451 BGP MULTI_EXIT_DISC (MED) Considerations. D. McPherson, V. Gill. March 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4458) 4459 MTU and Fragmentation Issues with In-the-Network Tunneling. P. Savola. April 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4463) 4464 Signaling Compression (SigComp) Users' Guide. A. Surtees, M. West. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4464) 4465 Signaling Compression (SigComp) Torture Tests. A. Surtees, M. West. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4465) 4466 Collected Extensions to IMAP4 ABNF. A. Melnikov, C. Daboo. April 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC5092, RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4467) 4468 Message Submission BURL Extension. C. Newman. May 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4471) 4472 Operational Considerations and Issues with IPv6 DNS. A. Durand, J. Ihren, P. Savola. April 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8224) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4475) 4476 Attribute Certificate (AC) Policies Extension. C. Francis, D. Pinkas. May 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4477) 4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol. Y. Nir. April 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4478) 4479 A Data Model for Presence. J. Rosenberg. July 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4481) 4482 CIPID: Contact Information for the Presence Information Data Format. H. Schulzrinne. July 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4485) 4486 Subcodes for BGP Cease Notification Message. E. Chen, V. Gillet. April 2006. (Format: TXT, HTML) (Updated by RFC8203) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4487) 4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription. O. Levin. May 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8422) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0117) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4497) 4498 The Managed Object Aggregation MIB. G. Keeni. May 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4498) 4499 Not Issued. 4500 Not Issued. 4501 Domain Name System Uniform Resource Identifiers. S. Josefsson. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4501) 4502 Remote Network Monitoring Management Information Base Version 2. S. Waldbusser. May 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4503) 4504 SIP Telephony Device Requirements and Configuration. H. Sinnreich, Ed., S. Lass, C. Stredicke. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4504) 4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga. June 2006. (Format: TXT, HTML) (Obsoletes RFC2245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4505) 4506 XDR: External Data Representation Standard. M. Eisler, Ed.. May 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8217) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4509) 4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4518) 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications. A. Sciberras, Ed.. June 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2252, RFC2256, RFC2587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4523) 4524 COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4525) 4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4526) 4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4527) 4528 Lightweight Directory Access Protocol (LDAP) Assertion Control. K. Zeilenga. June 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4529) 4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4530) 4531 Lightweight Directory Access Protocol (LDAP) Turn Operation. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4531) 4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation. K. Zeilenga. June 2006. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4533) 4534 Group Security Policy Token v1. A Colegrove, H Harney. June 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4535) 4536 The application/smil and application/smil+xml Media Types. P. Hoschka. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4536) 4537 Kerberos Cryptosystem Negotiation Extension. L. Zhu, P. Leach, K. Jaganathan. June 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC1888, RFC4048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4548) 4549 Synchronization Operations for Disconnected IMAP4 Clients. A. Melnikov, Ed.. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4549) 4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile. S. Maes, A. Melnikov. June 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4553) 4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks. T. Chown. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4554) 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE). P. Eronen. June 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC6112, RFC8062, RFC8636) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4565) 4566 SDP: Session Description Protocol. M. Handley, V. Jacobson, C. Perkins. July 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4569) 4570 Session Description Protocol (SDP) Source Filters. B. Quinn, R. Finlayson. July 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8122) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4573) 4574 The Session Description Protocol (SDP) Label Attribute. O. Levin, G. Camarillo. August 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4580) 4581 Cryptographically Generated Addresses (CGA) Extension Field Format. M. Bagnulo, J. Arkko. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4583) 4584 Extension to Sockets API for Mobile IPv6. S. Chakrabarti, E. Nordmark. July 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC5506, RFC8108) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4586) 4587 RTP Payload Format for H.261 Video Streams. R. Even. August 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4588) 4589 Location Types Registry. H. Schulzrinne, H. Tschofenig. July 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4593) 4594 Configuration Guidelines for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT, HTML) (Updated by RFC5865, RFC8622) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4596) 4597 Conferencing Scenarios. R. Even, N. Ismail. August 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4598) 4599 Not Issued. 4600 Not Issued. 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. August 2006. (Format: TXT, PDF, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4609) 4610 Anycast-RP Using Protocol Independent Multicast (PIM). D. Farinacci, Y. Cai. August 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4615) 4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga, Ed.. August 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4619) 4620 IPv6 Node Information Queries. M. Crawford, B. Haberman, Ed.. August 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4620) 4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol. T. Kivinen, H. Tschofenig. August 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4623) 4624 Multicast Source Discovery Protocol (MSDP) MIB. B. Fenner, D. Thaler. October 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4624) 4625 Fibre Channel Routing Information MIB. C. DeSanti, K. McCloghrie, S. Kode, S. Gai. September 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4626) 4627 The application/json Media Type for JavaScript Object Notation (JSON). D. Crockford. July 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4633) 4634 US Secure Hash Algorithms (SHA and HMAC-SHA). D. Eastlake 3rd, T. Hansen. July 2006. (Format: TXT, HTML) (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, HTML) (Updates RFC2845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4635) 4636 Foreign Agent Error Extension for Mobile IPv4. C. Perkins. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4640) 4641 DNSSEC Operational Practices. O. Kolkman, R. Gieben. September 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC8143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4642) 4643 Network News Transfer Protocol (NNTP) Extension for Authentication. J. Vinocur, K. Murchison. October 2006. (Format: TXT, HTML) (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, HTML) (Updates RFC2980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4644) 4645 Initial Language Subtag Registry. D. Ewell. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4645) 4646 Tags for Identifying Languages. A. Phillips, M. Davis. September 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4649) 4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY). M. Euchner. September 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4653) 4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification. J. Widmer, M. Handley. August 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC7717, RFC7718, RFC8545) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4657) 4658 Not Issued. 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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4667) 4668 RADIUS Authentication Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2618) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4668) 4669 RADIUS Authentication Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4669) 4670 RADIUS Accounting Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2620) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4670) 4671 RADIUS Accounting Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4672) 4673 RADIUS Dynamic Authorization Server MIB. S. De Cnodder, N. Jonnala, M. Chiba. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4673) 4674 Requirements for Path Computation Element (PCE) Discovery. J.L. Le Roux, Ed.. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3160) (Obsoleted by RFC6722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4677) 4678 Server/Application State Protocol v1. A. Bivens. September 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4679) 4680 TLS Handshake Message for Supplemental Data. S. Santesson. October 2006. (Format: TXT, HTML) (Updates RFC4346) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4680) 4681 TLS User Mapping Extension. S. Santesson, A. Medvinsky, J. Ball. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4684) 4685 Atom Threading Extensions. J. Snell. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4685) 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM). J. Fenton. September 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4690) 4691 Guidelines for Acting as an IETF Liaison to Another Organization. L. Andersson, Ed.. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4691) 4692 Considerations on the IPv6 Host Density Metric. G. Huston. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4692) 4693 IETF Operational Notes. H. Alvestrand. October 2006. (Format: TXT, HTML) (Obsoleted by RFC6393) (Status: HISTORIC) (DOI: 10.17487/RFC4693) 4694 Number Portability Parameters for the "tel" URI. J. Yu. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4694) 4695 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4696) 4697 Observed DNS Resolution Misbehavior. M. Larson, P. Barber. October 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4698) 4699 Not Issued. 4700 Not Issued. 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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4704) 4705 GigaBeam High-Speed Radio Link Encryption. R. Housley, A. Corry. October 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4706) 4707 Netnews Administration System (NAS). P. Grau, V. Heinau, H. Schlichting, R. Schuettler. October 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4707) 4708 CellML Media Type. A. Miller. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4708) 4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers. J. Reschke. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4713) 4714 Requirements for IETF Technical Publication Service. A. Mankin, S. Hayes. October 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4715) 4716 The Secure Shell (SSH) Public Key File Format. J. Galbraith, R. Thayer. November 2006. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4717) 4718 IKEv2 Clarifications and Implementation Guidelines. P. Eronen, P. Hoffman. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4720) 4721 Mobile IPv4 Challenge/Response Extensions (Revised). C. Perkins, P. Calhoun, J. Bharatia. January 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8538) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4724) 4725 ENUM Validation Architecture. A. Mayrhofer, B. Hoeneisen. November 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4726) 4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. B. Fenner. November 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4731) 4732 Internet Denial-of-Service Considerations. M. Handley, Ed., E. Rescorla, Ed., IAB. December 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4736) 4737 Packet Reordering Metrics. A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser. November 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4740) 4741 NETCONF Configuration Protocol. R. Enns, Ed.. December 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4745) 4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange. T. Clancy, W. Arbaugh. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4746) 4747 The Virtual Fabrics MIB. S. Kipp, G. Ramkumar, K. McCloghrie. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4747) 4748 RFC 3978 Update to Recognize the IETF Trust. S. Bradner, Ed.. October 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4750) 4751 Not Issued. 4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism. A. Melnikov, Ed.. November 2006. (Format: TXT, HTML) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4752) 4753 ECP Groups For IKE and IKEv2. D. Fu, J. Solinas. January 2007. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4754) 4755 IP over InfiniBand: Connected Mode. V. Kashyap. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4755) 4756 Forward Error Correction Grouping Semantics in Session Description Protocol. A. Li. November 2006. (Format: TXT, HTML) (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, HTML) (Updated by RFC6649) (Status: HISTORIC) (DOI: 10.17487/RFC4757) 4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1. M. Nystroem. November 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC5462, RFC8395, RFC8614) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4764) 4765 The Intrusion Detection Message Exchange Format (IDMEF). H. Debar, D. Curry, B. Feinstein. March 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4765) 4766 Intrusion Detection Message Exchange Requirements. M. Wood, M. Erlinger. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4766) 4767 The Intrusion Detection Exchange Protocol (IDXP). B. Feinstein, G. Matthews. March 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4771) 4772 Security Implications of Using the Data Encryption Standard (DES). S. Kelly. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4772) 4773 Administration of the IANA Special Purpose IPv6 Address Block. G. Huston. December 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2877) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4777) 4778 Operational Security Current Practices in Internet Service Provider Environments. M. Kaeo. January 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4780) 4781 Graceful Restart Mechanism for BGP with MPLS. Y. Rekhter, R. Aggarwal. January 2007. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4782) 4783 GMPLS - Communication of Alarm Information. L. Berger, Ed.. December 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4785) 4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4790) 4791 Calendaring Extensions to WebDAV (CalDAV). C. Daboo, B. Desruisseaux, L. Dusseault. March 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4793) 4794 RFC 1264 Is Obsolete. B. Fenner. December 2006. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4795) 4796 The Session Description Protocol (SDP) Content Attribute. J. Hautakorpi, G. Camarillo. February 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4798) 4799 Not Issued. 4800 Not Issued. 4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4807) 4808 Key Change Strategies for TCP-MD5. S. Bellovin. March 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4809) 4810 Long-Term Archive Service Requirements. C. Wallace, U. Pordesch, R. Brandner. March 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4811) 4812 OSPF Restart Signaling. L. Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4817) 4818 RADIUS Delegated-IPv6-Prefix Attribute. J. Salowey, R. Droms. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4818) 4819 Secure Shell Public Key Subsystem. J. Galbraith, J. Van Dyke, J. Bright. March 2007. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4820) 4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4821) 4822 RIPv2 Cryptographic Authentication. R. Atkinson, M. Fanto. February 2007. (Format: TXT, HTML) (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, HTML) (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.. 1 April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4824) 4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). J. Rosenberg. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4825) 4826 Extensible Markup Language (XML) Formats for Representing Resource Lists. J. Rosenberg. May 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4829) 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4830) 4831 Goals for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4831) 4832 Security Threats to Network-Based Localized Mobility Management (NETLMM). C. Vogt, J. Kempf. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4832) 4833 Timezone Options for DHCP. E. Lear, P. Eggert. April 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4836) 4837 Managed Objects of Ethernet Passive Optical Networks (EPON). L. Khermosh. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4839) 4840 Multiple Encapsulation Methods Considered Harmful. B. Aboba, Ed., E. Davies, D. Thaler. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4840) 4841 RFC 4181 Update to Recognize the IETF Trust. C. Heard, Ed.. March 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4845) 4846 Independent Submissions to the RFC Editor. J. Klensin, Ed., D. Thaler, Ed.. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4848) 4849 RADIUS Filter Rule Attribute. P. Congdon, M. Sanchez, B. Aboba. April 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4852) 4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification. R. Housley. April 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4854) 4855 Media Type Registration of RTP Payload Formats. S. Casner. February 2007. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4856) 4857 Mobile IPv4 Regional Registration. E. Fogelstroem, A. Jonsson, C. Perkins. June 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2461) (Updated by RFC5942, RFC6980, RFC7048, RFC7527, RFC7559, RFC8028, RFC8319, RFC8425) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4861) 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT, HTML) (Obsoletes RFC2462) (Updated by RFC7527) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4862) 4863 Wildcard Pseudowire Type. L. Martini, G. Swallow. May 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4864) 4865 SMTP Submission Service Extension for Future Message Release. G. White, G. Vaudreuil. May 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4868) 4869 Suite B Cryptographic Suites for IPsec. L. Law, J. Solinas. May 2007. (Format: TXT, HTML) (Obsoleted by RFC6379) (Status: HISTORIC) (DOI: 10.17487/RFC4869) 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys). M. Delany. May 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3209, RFC3473) (Updated by RFC6001, RFC8390) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4878) 4879 Clarification of the Third Party Disclosure Procedure in RFC 3979. T. Narten. April 2007. (Format: TXT, HTML) (Obsoleted by RFC8179) (Updates RFC3979) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4881) 4882 IP Address Location Privacy and Mobile IPv6: Problem Statement. R. Koodli. May 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC0792, RFC4443) (Updated by RFC8335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4884) 4885 Network Mobility Support Terminology. T. Ernst, H-Y. Lach. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4885) 4886 Network Mobility Support Goals and Requirements. T. Ernst. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4886) 4887 Network Mobility Home Network Models. P. Thubert, R. Wakikawa, V. Devarapalli. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4889) 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E. Davies, J. Mohacsi. May 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4891) 4892 Requirements for a Mechanism Identifying a Name Server Instance. S. Woolf, D. Conrad. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4892) 4893 BGP Support for Four-octet AS Number Space. Q. Vohra, E. Chen. May 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4898) 4899 Not Issued. 4900 Not Issued. 4901 Protocol Extensions for Header Compression over MPLS. J. Ash, Ed., J. Hand, Ed., A. Malis, Ed.. June 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4902) 4903 Multi-Link Subnet Issues. D. Thaler. June 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4906) 4907 Architectural Implications of Link Indications. B. Aboba, Ed.. June 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4910) 4911 Encoding Instructions for the Robust XML Encoding Rules (RXER). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4911) 4912 Abstract Syntax Notation X (ASN.X). S. Legg. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4915) 4916 Connected Identity in the Session Initiation Protocol (SIP). J. Elwell. June 2007. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4917) 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). L. Dusseault, Ed.. June 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4920) 4921 Not Issued. 4922 Not Issued. 4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network. F. Baker, P. Bose. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4923) 4924 Reflections on Internet Transparency. B. Aboba, Ed., E. Davies. July 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4925) 4926 A URN Namespace for GEANT. T.Kalin, M.Molina. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0129) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4929) 4930 Extensible Provisioning Protocol (EPP). S. Hollenbeck. May 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4936) 4937 IANA Considerations for PPP over Ethernet (PPPoE). P. Arberg, V. Mammoliti. June 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4939) 4940 IANA Considerations for OSPF. K. Kompella, B. Fenner. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6282, RFC6775, RFC8025, RFC8066) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4945) 4946 Atom License Extension. J. Snell. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4948) 4949 Internet Security Glossary, Version 2. R. Shirey. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4951) 4952 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. July 2007. (Format: TXT, HTML) (Obsoleted by RFC6530) (Updated by RFC5336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4952) 4953 Defending TCP Against Spoofing Attacks. J. Touch. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4953) 4954 SMTP Service Extension for Authentication. R. Siemborski, Ed., A. Melnikov, Ed.. July 2007. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4955) 4956 DNS Security (DNSSEC) Opt-In. R. Arends, M. Kosters, D. Blacka. July 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4959) 4960 Stream Control Transmission Protocol. R. Stewart, Ed.. September 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4964) 4965 CableLabs - IETF Standardization Collaboration. J-F. Mule, W. Townsley. September 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4968) 4969 IANA Registration for vCard Enumservice. A. Mayrhofer. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7977, RFC8591) (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, HTML) (Updated by RFC7977, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4976) 4977 Problem Statement: Dual Stack Mobility. G. Tsirtsis, H. Soliman. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4977) 4978 The IMAP COMPRESS Extension. A. Gulbrandsen. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4978) 4979 IANA Registration for Enumservice 'XMPP'. A. Mayrhofer. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4986) 4987 TCP SYN Flooding Attacks and Common Mitigations. W. Eddy. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4987) 4988 Mobile IPv4 Fast Handovers. R. Koodli, C. Perkins. October 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4988) 4989 Not Issued. 4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks. K. Shiomoto, R. Papneja, R. Rabbat. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4990) 4991 A Common Schema for Internet Registry Information Service Transfer Protocols. A. Newton. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4991) 4992 XML Pipelining with Chunks for the Internet Registry Information Service. A. Newton. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4997) 4998 Evidence Record Syntax (ERS). T. Gondrom, R. Brandner, U. Pordesch. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4998) 4999 Not Issued. 5000 Internet Official Protocol Standards. RFC Editor. May 2008. (Format: TXT, HTML) (Obsoletes RFC3700) (Obsoleted by RFC7100) (Status: HISTORIC) (DOI: 10.17487/RFC5000) 5001 DNS Name Server Identifier (NSID) Option. R. Austein. August 2007. (Format: TXT, HTML) (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, HTML) (Updated by RFC8217) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5004) 5005 Feed Paging and Archiving. M. Nottingham. September 2007. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC6106) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5006) 5007 DHCPv6 Leasequery. J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. September 2007. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC6318) (Status: HISTORIC) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5010) 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors. M. StJohns. September 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5012) 5013 The Dublin Core Metadata Element Set. J. Kunze, T. Baker. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5015) 5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol. M. Thomas. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5016) 5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs). D. McWalter, Ed.. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5017) 5018 Connection Establishment in the Binary Floor Control Protocol (BFCP). G. Camarillo. September 2007. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5019) 5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute. K. Zeilenga. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5022) 5023 The Atom Publishing Protocol. J. Gregorio, Ed., B. de hOra, Ed.. October 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5023) 5024 ODETTE File Transfer Protocol 2.0. I. Friend. November 2007. (Format: TXT, HTML) (Obsoletes RFC2204) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5024) 5025 Presence Authorization Rules. J. Rosenberg. December 2007. (Format: TXT, HTML) (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, HTML) (Updated by RFC8553) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5032) 5033 Specifying New Congestion Control Algorithms. S. Floyd, M. Allman. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5037) 5038 The Label Distribution Protocol (LDP) Implementation Survey Results. B. Thomas, L. Andersson. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5038) 5039 The Session Initiation Protocol (SIP) and Spam. J. Rosenberg, C. Jennings. January 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5049) 5050 Bundle Protocol Specification. K. Scott, S. Burleigh. November 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5050) 5051 i;unicode-casemap - Simple Unicode Collation Algorithm. M. Crispin. October 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5051) 5052 Forward Error Correction (FEC) Building Block. M. Watson, M. Luby, L. Vicisano. August 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5055) 5056 On the Use of Channel Bindings to Secure Channels. N. Williams. November 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5056) 5057 Multiple Dialog Usages in the Session Initiation Protocol. R. Sparks. November 2007. (Format: TXT, HTML) (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, HTML) (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, PDF, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC2961, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5063) 5064 The Archived-At Message Header Field. M. Duerst. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5064) 5065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. August 2007. (Format: TXT, HTML) (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, HTML) (Updated by RFC7124) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5066) 5067 Infrastructure ENUM Requirements. S. Lind, P. Pfautz. November 2007. (Format: TXT, HTML) (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, HTML) (Updated by RFC8314) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5069) 5070 The Incident Object Description Exchange Format. R. Danyliw, J. Meijer, Y. Demchenko. December 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5071) 5072 IP Version 6 over PPP. S. Varada, Ed., D. Haskins, E. Allen. September 2007. (Format: TXT, HTML) (Obsoletes RFC2472) (Updated by RFC8064) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5073) 5074 DNSSEC Lookaside Validation (DLV). S. Weiler. November 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5074) 5075 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. November 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4507) (Obsoleted by RFC8446) (Updated by RFC8447) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5091) 5092 IMAP URL Scheme. A. Melnikov, Ed., C. Newman. November 2007. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5093) 5094 Mobile IPv6 Vendor Specific Option. V. Devarapalli, A. Patel, K. Leung. December 2007. (Format: TXT, HTML) (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, HTML) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5095) 5096 Mobile IPv6 Experimental Messages. V. Devarapalli. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5096) 5097 MIB for the UDP-Lite protocol. G. Renker, G. Fairhurst. January 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5098) 5099 Not Issued. 5100 Not Issued. 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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7728, RFC8082) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5104) 5105 ENUM Validation Token Format Definition. O. Lendl. December 2007. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5106) 5107 DHCP Server Identifier Override Suboption. R. Johnson, J. Kumarasamy, K. Kinnear, M. Stapp. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5107) 5108 Not Issued. 5109 RTP Payload Format for Generic Forward Error Correction. A. Li, Ed.. December 2007. (Format: TXT, HTML) (Obsoletes RFC2733, RFC3009) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5109) 5110 Overview of the Internet Multicast Routing Architecture. P. Savola. January 2008. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5111) 5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp). M. Garcia-Martin. January 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5113) 5114 Additional Diffie-Hellman Groups for Use with IETF Standards. M. Lepinski, S. Kent. January 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5115) 5116 An Interface and Algorithms for Authenticated Encryption. D. McGrew. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5116) 5117 RTP Topologies. M. Westerlund, S. Wenger. January 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8064) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5124) 5125 Reclassification of RFC 3525 to Historic. T. Taylor. February 2008. (Format: TXT, HTML) (Obsoletes RFC3525) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5125) 5126 CMS Advanced Electronic Signatures (CAdES). D. Pinkas, N. Pope, J. Ross. March 2008. (Format: TXT, HTML) (Obsoletes RFC3126) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5126) 5127 Aggregation of Diffserv Service Classes. K. Chan, J. Babiarz, F. Baker. February 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5128) 5129 Explicit Congestion Marking in MPLS. B. Davie, B. Briscoe, J. Tay. January 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5130) 5131 A MIB Textual Convention for Language Tags. D. McWalter, Ed.. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5131) 5132 IP Multicast MIB. D. McWalter, D. Thaler, A. Kessler. December 2007. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0135) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5135) 5136 Defining Network Capacity. P. Chimento, J. Ishac. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5136) 5137 ASCII Escaping of Unicode Characters. J. Klensin. February 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5144) 5145 Framework for MPLS-TE to GMPLS Migration. K. Shiomoto, Ed.. March 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5146) 5147 URI Fragment Identifiers for the text/plain Media Type. E. Wilde, M. Duerst. April 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5148) 5149 Service Selection for Mobile IPv6. J. Korhonen, U. Nilsson, V. Devarapalli. February 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6840, RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5155) 5156 Special-Use IPv6 Addresses. M. Blanchet. April 2008. (Format: TXT, HTML) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5156) 5157 IPv6 Implications for Network Scanning. T. Chown. March 2008. (Format: TXT, HTML) (Obsoleted by RFC7707) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5157) 5158 6to4 Reverse DNS Delegation Specification. G. Huston. March 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5160) 5161 The IMAP ENABLE Extension. A. Gulbrandsen, Ed., A. Melnikov, Ed.. March 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5161) 5162 IMAP4 Extensions for Quick Mailbox Resynchronization. A. Melnikov, D. Cridland, C. Wilson. March 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5163) 5164 Mobility Services Transport: Problem Statement. T. Melia, Ed.. March 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5165) 5166 Metrics for the Evaluation of Congestion Control Mechanisms. S. Floyd, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5166) 5167 Media Server Control Protocol Requirements. M. Dolly, R. Even. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5167) 5168 XML Schema for Media Control. O. Levin, R. Even, P. Hagendorf. March 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5170) 5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol. M. Foschiano. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5171) 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol. S. Varada, Ed.. March 2008. (Format: TXT, HTML) (Obsoletes RFC2472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5172) 5173 Sieve Email Filtering: Body Extension. J. Degener, P. Guenther. April 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5174) 5175 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. March 2008. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3576) (Updated by RFC8559) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5181) 5182 IMAP Extension for Referencing the Last SEARCH Result. A. Melnikov. March 2008. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5182) 5183 Sieve Email Filtering: Environment Extension. N. Freed. May 2008. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5184) 5185 OSPF Multi-Area Adjacency. S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal. May 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5186) 5187 OSPFv3 Graceful Restart. P. Pillay-Esnault, A. Lindem. June 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5197) 5198 Unicode Format for Network Interchange. J. Klensin, M. Padlipsky. March 2008. (Format: TXT, HTML) (Obsoletes RFC0698) (Updates RFC0854) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5198) 5199 Not Issued. 5200 Not Issued. 5201 Host Identity Protocol. R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. April 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8003) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5203) 5204 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. April 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8046) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5210) 5211 An Internet Transition Plan. J. Curran. July 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4214) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5214) 5215 RTP Payload Format for Vorbis Encoded Audio. L. Barbato. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5215) 5216 The EAP-TLS Authentication Protocol. D. Simon, B. Aboba, R. Hurst. March 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5217) 5218 What Makes for a Successful Protocol?. D. Thaler, B. Aboba. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5218) 5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. February 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5220) 5221 Requirements for Address Selection Mechanisms. A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5223) 5224 Diameter Policy Processing Application. M. Brenner. March 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2434) (Obsoleted by RFC8126) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5226) 5227 IPv4 Address Conflict Detection. S. Cheshire. July 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5230) 5231 Sieve Email Filtering: Relational Extension. W. Segmuller, B. Leiba. January 2008. (Format: TXT, HTML) (Obsoletes RFC3431) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5231) 5232 Sieve Email Filtering: Imap4flags Extension. A. Melnikov. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5232) 5233 Sieve Email Filtering: Subaddress Extension. K. Murchison. January 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5236) 5237 IANA Allocation Guidelines for the Protocol Field. J. Arkko, S. Bradner. February 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5238) 5239 A Framework for Centralized Conferencing. M. Barnes, C. Boulton, O. Levin. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5239) 5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB. B. Joshi, R. Bijlani. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5240) 5241 Naming Rights in IETF Protocols. A. Falk, S. Bradner. 1 April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5241) 5242 A Generalized Unified Character Code: Western European and CJK Sections. J. Klensin, H. Alvestrand. 1 April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5242) 5243 OSPF Database Exchange Summary List Optimization. R. Ogier. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5243) 5244 Definition of Events for Channel-Oriented Telephony Signalling. H. Schulzrinne, T. Taylor. June 2008. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC4091, RFC4092) (Obsoleted by RFC8445) (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, HTML) (Obsoletes RFC3268, RFC4346, RFC4366) (Obsoleted by RFC8446) (Updates RFC4492) (Updated by RFC5746, RFC5878, RFC6176, RFC7465, RFC7507, RFC7568, RFC7627, RFC7685, RFC7905, RFC7919, RFC8447) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5251) 5252 OSPF-Based Layer 1 VPN Auto-Discovery. I. Bryskin, L. Berger. July 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5254) 5255 Internet Message Access Protocol Internationalization. C. Newman, A. Gulbrandsen, A. Melnikov. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5255) 5256 Internet Message Access Protocol - SORT and THREAD Extensions. M. Crispin, K. Murchison. June 2008. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5257) 5258 Internet Message Access Protocol version 4 - LIST Command Extensions. B. Leiba, A. Melnikov. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5258) 5259 Internet Message Access Protocol - CONVERT Extension. A. Melnikov, Ed., P. Coates, Ed.. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5259) 5260 Sieve Email Filtering: Date and Index Extensions. N. Freed. July 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5263) 5264 Publication of Partial Presence Information. A. Niemi, M. Lonnfors, E. Leppanen. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5264) 5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways. S. Vaarala, E. Klovning. June 2008. (Format: TXT, HTML) (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, HTML) (Also BCP0136) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5266) 5267 Contexts for IMAP4. D. Cridland, C. King. July 2008. (Format: TXT, HTML) (Updated by RFC5465) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5267) 5268 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. June 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5270) 5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G. Dommety. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5271) 5272 Certificate Management over CMS (CMC). J. Schaad, M. Myers. June 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5274) 5275 CMS Symmetric Key Management and Distribution. S. Turner. June 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5276) 5277 NETCONF Event Notifications. S. Chisholm, H. Trevino. July 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3280, RFC4325, RFC4630) (Updated by RFC6818, RFC8398, RFC8399) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5283) 5284 User-Defined Errors for RSVP. G. Swallow, A. Farrel. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5284) 5285 A General Mechanism for RTP Header Extensions. D. Singer, H. Desineni. July 2008. (Format: TXT, HTML) (Obsoleted by RFC8285) (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, HTML) (Updated by RFC8518) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5289) 5290 Comments on the Usefulness of Simple Best-Effort Traffic. S. Floyd, M. Allman. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5290) 5291 Outbound Route Filtering Capability for BGP-4. E. Chen, Y. Rekhter. August 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5292) 5293 Sieve Email Filtering: Editheader Extension. J. Degener, P. Guenther. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5293) 5294 Host Threats to Protocol Independent Multicast (PIM). P. Savola, J. Lingard. August 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5295) 5296 EAP Extensions for EAP Re-authentication Protocol (ERP). V. Narayanan, L. Dondeti. August 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5298) 5299 Not Issued. 5300 Not Issued. 5301 Dynamic Hostname Exchange Mechanism for IS-IS. D. McPherson, N. Shen. October 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3373) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5303) 5304 IS-IS Cryptographic Authentication. T. Li, R. Atkinson. October 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5311) 5312 Not Issued. 5313 Not Issued. 5314 Not Issued. 5315 Not Issued. 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, HTML) (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, PDF, HTML) (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, HTML) (Updated by RFC8217) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5318) 5319 Not Issued. 5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL). F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5320) 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5324) 5325 Licklider Transmission Protocol - Motivation. S. Burleigh, M. Ramadas, S. Farrell. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5325) 5326 Licklider Transmission Protocol - Specification. M. Ramadas, S. Burleigh, S. Farrell. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5326) 5327 Licklider Transmission Protocol - Security Extensions. S. Farrell, M. Ramadas, S. Burleigh. September 2008. (Format: TXT, HTML) (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, HTML) (Updated by RFC7354, RFC8553) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5333) 5334 Ogg Media Types. I. Goncalves, S. Pfeiffer, C. Montgomery. September 2008. (Format: TXT, HTML) (Obsoletes RFC3534) (Updated by RFC7845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5334) 5335 Internationalized Email Headers. A. Yang, Ed.. September 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5339) 5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July 2008. (Format: TXT, HTML) (Obsoletes RFC2740) (Updated by RFC6845, RFC6860, RFC7503, RFC8362) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5344) 5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats. J. Schoenwaelder. October 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5346) 5347 Media Gateway Control Protocol Fax Package. F. Andreasen, D. Hancock. October 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5351) 5352 Aggregate Server Access Protocol (ASAP). R. Stewart, Q. Xie, M. Stillman, M. Tuexen. September 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5355) 5356 Reliable Server Pooling Policies. T. Dreibholz, M. Tuexen. September 2008. (Format: TXT, HTML) (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, HTML) (Updated by RFC5618, RFC5938, RFC6038, RFC7717, RFC7750, RFC8545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5357) 5358 Preventing Use of Recursive Nameservers in Reflector Attacks. J. Damas, F. Neves. October 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5360) 5361 A Document Format for Requesting Consent. G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5361) 5362 The Session Initiation Protocol (SIP) Pending Additions Event Package. G. Camarillo. October 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8262) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5368) 5369 Framework for Transcoding with the Session Initiation Protocol (SIP). G. Camarillo. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5369) 5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model. G. Camarillo. October 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5377) 5378 Rights Contributors Provide to the IETF Trust. S. Bradner, Ed., J. Contreras, Ed.. November 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3489) (Updated by RFC7350, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5389) 5390 Requirements for Management of Overload in the Session Initiation Protocol. J. Rosenberg. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5390) 5391 RTP Payload Format for ITU-T Recommendation G.711.1. A. Sollaud. November 2008. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5394) 5395 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. November 2008. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5396) 5397 WebDAV Current Principal Extension. W. Sanchez, C. Daboo. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5397) 5398 Autonomous System (AS) Number Reservation for Documentation Use. G. Huston. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5398) 5399 Not Issued. 5400 Not Issued. 5401 Multicast Negative-Acknowledgment (NACK) Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2008. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5402) 5403 RPCSEC_GSS Version 2. M. Eisler. February 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5404) 5405 Unicast UDP Usage Guidelines for Application Designers. L. Eggert, G. Fairhurst. November 2008. (Format: TXT, HTML) (Obsoleted by RFC8085) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5405) 5406 Guidelines for Specifying the Use of IPsec Version 2. S. Bellovin. February 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5412) 5413 SLAPP: Secure Light Access Point Protocol. P. Narasimhan, D. Harkins, S. Ponnuswamy. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5413) 5414 Wireless LAN Control Protocol (WiCoP). S. Iino, S. Govindan, M. Sugiura, H. Cheng. February 2010. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC5414) (Updated by RFC8553) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5422) 5423 Internet Message Store Events. R. Gellens, C. Newman. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5423) 5424 The Syslog Protocol. R. Gerhards. March 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5425) 5426 Transmission of Syslog Messages over UDP. A. Okmianski. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5426) 5427 Textual Conventions for Syslog Management. G. Keeni. March 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5428) 5429 Sieve Email Filtering: Reject and Extended Reject Extensions. A. Stone, Ed.. March 2009. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC6460) (Status: HISTORIC) (DOI: 10.17487/RFC5430) 5431 Diameter ITU-T Rw Policy Enforcement Interface Application. D. Sun. March 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5435) 5436 Sieve Notification Mechanism: mailto. B. Leiba, M. Haardt. January 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5437) 5438 Instant Message Disposition Notification (IMDN). E. Burger, H. Khartabil. February 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC7896, RFC8253, RFC8356) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5442) 5443 LDP IGP Synchronization. M. Jork, A. Atlas, L. Fang. March 2009. (Format: TXT, HTML) (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, HTML) (Updated by RFC7631, RFC8245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5444) 5445 Basic Forward Error Correction (FEC) Schemes. M. Watson. March 2009. (Format: TXT, HTML) (Obsoletes RFC3452, RFC3695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5445) 5446 Service Selection for Mobile IPv4. J. Korhonen, U. Nilsson. February 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5449) 5450 Transmission Time Offsets in RTP Streams. D. Singer, H. Desineni. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5450) 5451 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. April 2009. (Format: TXT, HTML) (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, HTML) (Updates RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5452) 5453 Reserved IPv6 Interface Identifiers. S. Krishnan. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5453) 5454 Dual-Stack Mobile IPv4. G. Tsirtsis, V. Park, H. Soliman. March 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5456) 5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2. E. Guy, Ed.. February 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5458) 5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support. A. Sollaud. January 2009. (Format: TXT, HTML) (Updates RFC4749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5459) 5460 DHCPv6 Bulk Leasequery. M. Stapp. February 2009. (Format: TXT, HTML) (Updated by RFC7653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5460) 5461 TCP's Reaction to Soft Errors. F. Gont. February 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5463) 5464 The IMAP METADATA Extension. C. Daboo. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5464) 5465 The IMAP NOTIFY Extension. A. Gulbrandsen, C. King, A. Melnikov. February 2009. (Format: TXT, HTML) (Updates RFC5267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5465) 5466 IMAP4 Extension for Named Searches (Filters). A. Melnikov, C. King. February 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5468) 5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS). P. Eronen, Ed.. February 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5475) 5476 Packet Sampling (PSAMP) Protocol Specifications. B. Claise, Ed., A. Johnson, J. Quittek. March 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5480) 5481 Packet Delay Variation Applicability Statement. A. Morton, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5481) 5482 TCP User Timeout Option. L. Eggert, F. Gont. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5482) 5483 ENUM Implementation Issues and Experiences. L. Conroy, K. Fujiwara. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5483) 5484 Associating Time-Codes with RTP Streams. D. Singer. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5484) 5485 Digital Signatures on Internet-Draft Documents. R. Housley. March 2009. (Format: TXT, HTML) (Updated by RFC8358) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5485) 5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology. D. Malas, Ed., D. Meyer, Ed.. March 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5493) 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP). J. Arkko, C. Pignataro. April 2009. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5495) 5496 The Reverse Path Forwarding (RPF) Vector TLV. IJ. Wijnands, A. Boers, E. Rosen. March 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5497) 5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols. I. Chakeres. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5498) 5499 Not Issued. 5500 Not Issued. 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, HTML) (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, HTML) (Updated by RFC8217, RFC8498) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5507) 5508 NAT Behavioral Requirements for ICMP. P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. April 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5512) 5513 IANA Considerations for Three Letter Acronyms. A. Farrel. 1 April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5513) 5514 IPv6 over Social Networks. E. Vyncke. 1 April 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5517) 5518 Vouch By Reference. P. Hoffman, J. Levine, A. Hathcock. April 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5518) 5519 Multicast Group Membership Discovery MIB. J. Chesterfield, B. Haberman, Ed.. April 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5522) 5523 OSPFv3-Based Layer 1 VPN Auto-Discovery. L. Berger. April 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5523) 5524 Extended URLFETCH for Binary and Converted Parts. D. Cridland. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5524) 5525 Reliable Server Pooling MIB Module Definition. T. Dreibholz, J. Mulik. April 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5529) 5530 IMAP Response Codes. A. Gulbrandsen. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5530) 5531 RPC: Remote Procedure Call Protocol Specification Version 2. R. Thurlow. May 2009. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5532) 5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6. E. Nordmark, M. Bagnulo. June 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5534) 5535 Hash-Based Addresses (HBA). M. Bagnulo. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5535) 5536 Netnews Article Format. K. Murchison, Ed., C. Lindsey, D. Kohn. November 2009. (Format: TXT, HTML) (Obsoletes RFC1036, RFC1849) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5536) 5537 Netnews Architecture and Protocols. R. Allbery, Ed., C. Lindsey. November 2009. (Format: TXT, HTML) (Obsoletes RFC1036, RFC1849) (Updated by RFC8315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5537) 5538 The 'news' and 'nntp' URI Schemes. F. Ellermann. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5538) 5539 NETCONF over Transport Layer Security (TLS). M. Badra. May 2009. (Format: TXT, HTML) (Obsoleted by RFC7589) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5539) 5540 40 Years of RFCs. RFC Editor. April 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5542) 5543 BGP Traffic Engineering Attribute. H. Ould-Brahim, D. Fedyk, Y. Rekhter. May 2009. (Format: TXT, HTML) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5543) 5544 Syntax for Binding Documents with Time-Stamps. A. Santoni. February 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4550) (Updates RFC4469, RFC4467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5550) 5551 Lemonade Notifications Architecture. R. Gellens, Ed.. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5551) 5552 SIP Interface to VoiceXML Media Services. D. Burke, M. Scott. May 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8553) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5557) 5558 Virtual Enterprise Traversal (VET). F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5558) 5559 Pre-Congestion Notification (PCN) Architecture. P. Eardley, Ed.. June 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5559) 5560 A One-Way Packet Duplication Metric. H. Uijterwaal. May 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5564) 5565 Softwire Mesh Framework. J. Wu, Y. Cui, C. Metz, E. Rosen. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5565) 5566 BGP IPsec Tunnel Encapsulation Attribute. L. Berger, R. White, E. Rosen. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5566) 5567 An Architectural Framework for Media Server Control. T. Melanchuk, Ed.. June 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5567) 5568 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. July 2009. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5569) 5570 Common Architecture Label IPv6 Security Option (CALIPSO). M. StJohns, R. Atkinson, G. Thomas. July 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5572) 5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP). M. Thomson. June 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8559) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5580) 5581 The Camellia Cipher in OpenPGP. D. Shaw. June 2009. (Format: TXT, HTML) (Updates RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5581) 5582 Location-to-URL Mapping Architecture and Framework. H. Schulzrinne. September 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5585) 5586 MPLS Generic Associated Channel. M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.. June 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5592) 5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension. N. Cook. June 2009. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5594) 5595 The Datagram Congestion Control Protocol (DCCP) Service Codes. G. Fairhurst. September 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also BCP0150) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5597) 5598 Internet Mail Architecture. D. Crocker. July 2009. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5598) 5599 Not Issued. 5600 Not Issued. 5601 Pseudowire (PW) Management Information Base (MIB). T. Nadeau, Ed., D. Zelig, Ed.. July 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5611) 5612 Enterprise Number for Documentation Use. P. Eronen, D. Harrington. August 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC7038) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5614) 5615 H.248/MEGACO Registration Procedures. C. Groves, Y. Lin. August 2009. (Format: TXT, HTML) (Also BCP0151) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5615) 5616 Streaming Internet Messaging Attachments. N. Cook. August 2009. (Format: TXT, HTML) (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, HTML) (Updated by RFC8553) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5619) 5620 RFC Editor Model (Version 1). O. Kolkman, Ed., IAB. August 2009. (Format: TXT, HTML) (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, HTML) (Updates RFC3204, RFC3261, RFC3459) (Updated by RFC8262) (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, HTML) (Updated by RFC6323, RFC8311) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5624) 5625 DNS Proxy Implementation Guidelines. R. Bellis. August 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5635) 5636 Traceable Anonymous Certificate. S. Park, H. Park, Y. Won, J. Lee, S. Kent. August 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5639) 5640 Load-Balancing for Mesh Softwires. C. Filsfils, P. Mohapatra, C. Pignataro. August 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5642) 5643 Management Information Base for OSPFv3. D. Joyal, Ed., V. Manral, Ed.. August 2009. (Format: TXT, HTML) (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, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5644) 5645 Update to the Language Subtag Registry. D. Ewell, Ed.. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5645) 5646 Tags for Identifying Languages. A. Phillips, Ed., M. Davis, Ed.. September 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5650) 5651 Layered Coding Transport (LCT) Building Block. M. Luby, M. Watson, L. Vicisano. October 2009. (Format: TXT, HTML) (Obsoletes RFC3451) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5651) 5652 Cryptographic Message Syntax (CMS). R. Housley. September 2009. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2853) (Obsoleted by RFC8353) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5659) 5660 IPsec Channels: Connection Latching. N. Williams. October 2009. (Format: TXT, HTML) (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, HTML) (Updated by RFC8178, RFC8434) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5662) 5663 Parallel NFS (pNFS) Block/Volume Layout. D. Black, S. Fridella, J. Glasgow. January 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5666) 5667 Network File System (NFS) Direct Data Placement. T. Talpey, B. Callaghan. January 2010. (Format: TXT, HTML) (Obsoleted by RFC8267) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5669) 5670 Metering and Marking Behaviour of PCN-Nodes. P. Eardley, Ed.. November 2009. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5671) 5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update. D. Crocker, Ed.. August 2009. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5673) 5674 Alarms in Syslog. S. Chisholm, R. Gerhards. October 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5678) 5679 Locating IEEE 802.21 Mobility Services Using DNS. G. Bajko. December 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5679) 5680 The Nominating Committee Process: Open Disclosure of Willing Nominees. S. Dawkins, Ed.. October 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5683) 5684 Unintended Consequences of NAT Deployments with Overlapping Address Space. P. Srisuresh, B. Ford. February 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5688) 5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV). C. Daboo. September 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5692) 5693 Application-Layer Traffic Optimization (ALTO) Problem Statement. J. Seedorf, E. Burger. October 2009. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5694) 5695 MPLS Forwarding Benchmarking Methodology for IP Flows. A. Akhter, R. Asati, C. Pignataro. November 2009. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC6660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5696) 5697 Other Certificates Extension. S. Farrell. November 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5698) 5699 Not Issued. 5700 Not Issued. 5701 IPv6 Address Specific BGP Extended Community Attribute. Y. Rekhter. November 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5703) 5704 Uncoordinated Protocol Development Considered Harmful. S. Bryant, Ed., M. Morrow, Ed., IAB. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5704) 5705 Keying Material Exporters for Transport Layer Security (TLS). E. Rescorla. March 2010. (Format: TXT, HTML) (Updated by RFC8446, RFC8447) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5706) 5707 Media Server Markup Language (MSML). A. Saleem, Y. Xin, G. Sharratt. February 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5713) 5714 IP Fast Reroute Framework. M. Shand, S. Bryant. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5714) 5715 A Framework for Loop-Free Convergence. M. Shand, S. Bryant. January 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5716) 5717 Partial Lock Remote Procedure Call (RPC) for NETCONF. B. Lengyel, M. Bjorklund. December 2009. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5718) 5719 Updated IANA Considerations for Diameter Command Code Allocations. D. Romascanu, H. Tschofenig. January 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5720) 5721 POP3 Support for UTF-8. R. Gellens, C. Newman. February 2010. (Format: TXT, HTML) (Obsoleted by RFC6856) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5721) 5722 Handling of Overlapping IPv6 Fragments. S. Krishnan. December 2009. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5725) 5726 Mobile IPv6 Location Privacy Solutions. Y. Qiu, F. Zhao, Ed., R. Koodli. February 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5729) 5730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. August 2009. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC4931) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5731) 5732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4932) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5732) 5733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC4934) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5734) 5735 Special Use IPv4 Addresses. M. Cotton, L. Vegoda. January 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC1166) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5737) 5738 IMAP Support for UTF-8. P. Resnick, C. Newman. March 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3850) (Obsoleted by RFC8550) (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, HTML) (Obsoletes RFC3851) (Obsoleted by RFC8551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5751) 5752 Multiple Signatures in Cryptographic Message Syntax (CMS). S. Turner, J. Schaad. January 2010. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3278) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5753) 5754 Using SHA2 Algorithms with Cryptographic Message Syntax. S. Turner. January 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: HISTORIC) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8155, RFC8553) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5768) 5769 Test Vectors for Session Traversal Utilities for NAT (STUN). R. Denis-Courmont. April 2010. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5770) 5771 IANA Guidelines for IPv4 Multicast Address Assignments. M. Cotton, L. Vegoda, D. Meyer. March 2010. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5772) 5773 Analysis of Inter-Domain Routing Requirements and History. E. Davies, A. Doria. February 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5780) 5781 The rsync URI Scheme. S. Weiler, D. Ward, R. Housley. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5781) 5782 DNS Blacklists and Whitelists. J. Levine. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5782) 5783 Congestion Control in the RFC Series. M. Welzl, W. Eddy. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5783) 5784 Sieve Email Filtering: Sieves and Display Directives in XML. N. Freed, S. Vedam. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5784) 5785 Defining Well-Known Uniform Resource Identifiers (URIs). M. Nottingham, E. Hammer-Lahav. April 2010. (Format: TXT, HTML) (Obsoleted by RFC8615) (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, HTML) (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, HTML) (Obsoleted by RFC6827) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5787) 5788 IMAP4 Keyword Registry. A. Melnikov, D. Cridland. March 2010. (Format: TXT, HTML) (Updated by RFC8621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5788) 5789 PATCH Method for HTTP. L. Dusseault, J. Snell. March 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5794) 5795 The RObust Header Compression (ROHC) Framework. K. Sandlund, G. Pelletier, L-E. Jonsson. March 2010. (Format: TXT, HTML) (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, HTML) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5796) 5797 FTP Command and Extension Registry. J. Klensin, A. Hoenes. March 2010. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3768) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5798) 5799 Not Issued. 5800 Not Issued. 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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5803) 5804 A Protocol for Remotely Managing Sieve Scripts. A. Melnikov, Ed., T. Martin. July 2010. (Format: TXT, HTML) (Updated by RFC7817, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5804) 5805 Lightweight Directory Access Protocol (LDAP) Transactions. K. Zeilenga. March 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5805) 5806 Diversion Indication in SIP. S. Levy, M. Mohali, Ed.. March 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5807) 5808 Requirements for a Location-by-Reference Mechanism. R. Marshall, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5808) 5809 Not Issued. 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, HTML) (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, HTML) (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, HTML) (Updated by RFC7408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5812) 5813 Forwarding and Control Element Separation (ForCES) MIB. R. Haas. March 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC6615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5815) 5816 ESSCertIDv2 Update for RFC 3161. S. Santesson, N. Pope. April 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7137) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5820) 5821 Not Issued. 5822 Not Issued. 5823 Not Issued. 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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5824) 5825 Displaying Downgraded Messages for Email Address Internationalization. K. Fujiwara, B. Leiba. April 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5830) 5831 GOST R 34.11-94: Hash Function Algorithm. V. Dolmatov, Ed.. March 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5834) 5835 Framework for Metric Composition. A. Morton, Ed., S. Van den Berghe, Ed.. April 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6969, RFC7949, RFC8362) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5840) 5841 TCP Option to Denote Packet Mood. R. Hay, W. Turkal. 1 April 2010. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5842) 5843 Additional Hash Algorithms for HTTP Instance Digests. A. Bryan. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5843) 5844 IPv4 Support for Proxy Mobile IPv6. R. Wakikawa, S. Gundavelli. May 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5847) 5848 Signed Syslog Messages. J. Kelsey, J. Callas, A. Clemm. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5848) 5849 The OAuth 1.0 Protocol. E. Hammer-Lahav, Ed.. April 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5853) 5854 The Metalink Download Description Format. A. Bryan, T. Tsujikawa, N. McNab, P. Poeml. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5854) 5855 Nameservers for IPv4 and IPv6 Reverse Zones. J. Abley, T. Manderson. May 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5858) 5859 TFTP Server Address Option for DHCPv4. R. Johnson. June 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5860) 5861 HTTP Cache-Control Extensions for Stale Content. M. Nottingham. May 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5863) 5864 DNS SRV Resource Records for AFS. R. Allbery. April 2010. (Format: TXT, HTML) (Updates RFC1183) (Updated by RFC8553) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5868) 5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF). H. Krawczyk, P. Eronen. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5869) 5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI). A. Mayrhofer, C. Spanring. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5870) 5871 IANA Allocation Guidelines for the IPv6 Routing Header. J. Arkko, S. Bradner. May 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5875) 5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP). J. Elwell. April 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5877) 5878 Transport Layer Security (TLS) Authorization Extensions. M. Brown, R. Housley. May 2010. (Format: TXT, HTML) (Updates RFC5246) (Updated by RFC8447) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5878) 5879 Heuristics for Detecting ESP-NULL Packets. T. Kivinen, D. McDonald. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5879) 5880 Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Updated by RFC7419, RFC7880, RFC8562) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5881) 5882 Generic Application of Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5882) 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths. D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5886) 5887 Renumbering Still Needs Work. B. Carpenter, R. Atkinson, H. Flinck. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5887) 5888 The Session Description Protocol (SDP) Grouping Framework. G. Camarillo, H. Schulzrinne. June 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5889) 5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. (Format: TXT, HTML) (Obsoletes RFC3490) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5890) 5891 Internationalized Domain Names in Applications (IDNA): Protocol. J. Klensin. August 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5893) 5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale. J. Klensin. August 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5898) 5899 Not Issued. 5900 Not Issued. 5901 Extensions to the IODEF-Document Class for Reporting Phishing. P. Cain, D. Jevans. July 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC1305, RFC4330) (Updated by RFC7822, RFC8573) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5905) 5906 Network Time Protocol Version 4: Autokey Specification. B. Haberman, Ed., D. Mills. June 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5907) 5908 Network Time Protocol (NTP) Server Option for DHCPv6. R. Gayraud, B. Lourdelet. June 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5913) 5914 Trust Anchor Format. R. Housley, S. Ashmore, C. Wallace. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5914) 5915 Elliptic Curve Private Key Structure. S. Turner, D. Brown. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5915) 5916 Device Owner Attribute. S. Turner. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5916) 5917 Clearance Sponsor Attribute. S. Turner. June 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5919) 5920 Security Framework for MPLS and GMPLS Networks. L. Fang, Ed.. July 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5924) 5925 The TCP Authentication Option. J. Touch, A. Mankin, R. Bonica. June 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5926) 5927 ICMP Attacks against TCP. F. Gont. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5927) 5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism. M. Petit-Huguenin. August 2010. (Format: TXT, HTML) (Updated by RFC7350, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5928) 5929 Channel Bindings for TLS. J. Altman, N. Williams, L. Zhu. July 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5930) 5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password. D. Harkins, G. Zorn. August 2010. (Format: TXT, HTML) (Updated by RFC8146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5931) 5932 Camellia Cipher Suites for TLS. A. Kato, M. Kanda, S. Kanno. June 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5935) 5936 DNS Zone Transfer Protocol (AXFR). E. Lewis, A. Hoenes, Ed.. June 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5938) 5939 Session Description Protocol (SDP) Capability Negotiation. F. Andreasen. September 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5943) 5944 IP Mobility Support for IPv4, Revised. C. Perkins, Ed.. November 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5951) 5952 A Recommendation for IPv6 Address Text Representation. S. Kawamura, M. Kawashima. August 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5954) 5955 The application/timestamped-data Media Type. A. Santoni. August 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC5256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5957) 5958 Asymmetric Key Packages. S. Turner. August 2010. (Format: TXT, HTML) (Obsoletes RFC5208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5958) 5959 Algorithms for Asymmetric Key Package Content Type. S. Turner. August 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5962) 5963 IPv6 Deployment in Internet Exchange Points (IXPs). R. Gagliano. August 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC6650) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5965) 5966 DNS Transport over TCP - Implementation Requirements. R. Bellis. August 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5968) 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification. W. Townsley, O. Troan. August 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5970) 5971 GIST: General Internet Signalling Transport. H. Schulzrinne, R. Hancock. October 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5978) 5979 NSIS Operation over IP Tunnels. C. Shen, H. Schulzrinne, S. Lee, J. Bang. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5982) 5983 Mailing Lists and Internationalized Email Addresses. R. Gellens. October 2010. (Format: TXT, HTML) (Obsoleted by RFC6783) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5983) 5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding. K-M. Moller. 1 April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5984) 5985 HTTP-Enabled Location Delivery (HELD). M. Barnes, Ed.. September 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8187) (Status: HISTORIC) (DOI: 10.17487/RFC5987) 5988 Web Linking. M. Nottingham. October 2010. (Format: TXT, HTML) (Obsoleted by RFC8288) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5990) 5991 Teredo Security Updates. D. Thaler, S. Krishnan, J. Hoagland. September 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC5996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5998) 5999 Not Issued. 6000 Not Issued. 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, HTML) (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, HTML) (Updates RFC3471, RFC3473, RFC3945, RFC4202, RFC4203, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6002) 6003 Ethernet Traffic Parameters. D. Papadimitriou. October 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8306) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6007) 6008 Authentication-Results Registration for Differentiating among Cryptographic Results. M. Kucherawy. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6008) 6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions. N. Freed. October 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6010) 6011 Session Initiation Protocol (SIP) User Agent Configuration. S. Lawrence, Ed., J. Elwell. October 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6012) 6013 TCP Cookie Transactions (TCPCT). W. Simpson. January 2011. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC6013) 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC. P. Hoffman. November 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6016) 6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field. K. Meadors, Ed.. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6017) 6018 IPv4 and IPv6 Greynets. F. Baker, W. Harrop, G. Armitage. September 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6020) 6021 Common YANG Data Types. J. Schoenwaelder, Ed.. October 2010. (Format: TXT, HTML) (Obsoleted by RFC6991) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6021) 6022 YANG Module for NETCONF Monitoring. M. Scott, M. Bjorklund. October 2010. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6023) 6024 Trust Anchor Management Requirements. R. Reddy, C. Wallace. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6024) 6025 ASN.1 Translation. C. Wallace, C. Gardiner. October 2010. (Format: TXT, HTML) (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, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6026) 6027 IPsec Cluster Problem Statement. Y. Nir. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6027) 6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension. G. Camarillo, A. Keranen. October 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6029) 6030 Portable Symmetric Key Container (PSKC). P. Hoyer, M. Pei, S. Machani. October 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6033) 6034 Unicast-Prefix-Based IPv4 Multicast Addresses. D. Thaler. October 2010. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6035) 6036 Emerging Service Provider Scenarios for IPv6 Deployment. B. Carpenter, S. Jiang. October 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6039) 6040 Tunnelling of Explicit Congestion Notification. B. Briscoe. November 2010. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6041) 6042 Transport Layer Security (TLS) Authorization Using KeyNote. A. Keromytis. October 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC7544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6044) 6045 Real-time Inter-network Defense (RID). K. Moriarty. November 2010. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC6546) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6046) 6047 iCalendar Message-Based Interoperability Protocol (iMIP). A. Melnikov, Ed.. December 2010. (Format: TXT, HTML) (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, HTML) (Updates RFC2980, RFC3977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6048) 6049 Spatial Composition of Metrics. A. Morton, E. Stephan. January 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6050) 6051 Rapid Synchronisation of RTP Flows. C. Perkins, T. Schierl. November 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC2130) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6055) 6056 Recommendations for Transport-Protocol Port Randomization. M. Larsen, F. Gont. January 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6057) 6058 Transient Binding for Proxy Mobile IPv6. M. Liebsch, Ed., A. Muhanna, O. Blume. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6058) 6059 Simple Procedures for Detecting Network Attachment in IPv6. S. Krishnan, G. Daley. November 2010. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6065) 6066 Transport Layer Security (TLS) Extensions: Extension Definitions. D. Eastlake 3rd. January 2011. (Format: TXT, HTML) (Obsoletes RFC4366) (Updated by RFC8446, RFC8449) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6066) 6067 BCP 47 Extension U. M. Davis, A. Phillips, Y. Umaoka. December 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6067) 6068 The 'mailto' URI Scheme. M. Duerst, L. Masinter, J. Zawinski. October 2010. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6069) 6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors. S. Josefsson. January 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6072) 6073 Segmented Pseudowire. L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui. January 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6080) 6081 Teredo Extensions. D. Thaler. January 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8407) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6087) 6088 Traffic Selectors for Flow Bindings. G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont. January 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6090) 6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication. N. Mavrogiannopoulos, D. Gillmor. February 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6092) 6093 On the Implementation of the TCP Urgent Mechanism. F. Gont, A. Yourtchenko. January 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6094) 6095 Extending YANG with Language Abstractions. B. Linowski, M. Ersue, S. Kuryla. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6095) 6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration. M. Tuexen, R. Stewart. January 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6098) 6099 Not Issued. 6100 Not Issued. 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0. A. Freier, P. Karlton, P. Kocher. August 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6101) 6102 Not Issued. 6103 Not Issued. 6104 Rogue IPv6 Router Advertisement Problem Statement. T. Chown, S. Venaas. February 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC5006) (Obsoleted by RFC8106) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7952) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6110) 6111 Additional Kerberos Naming Constraints. L. Zhu. April 2011. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6111) 6112 Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8062) (Updates RFC4120, RFC4121, RFC4556) (Status: HISTORIC) (DOI: 10.17487/RFC6112) 6113 A Generalized Framework for Kerberos Pre-Authentication. S. Hartman, L. Zhu. April 2011. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6113) 6114 The 128-Bit Blockcipher CLEFIA. M. Katagi, S. Moriai. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6114) 6115 Recommendation for a Routing Architecture. T. Li, Ed.. February 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6119) 6120 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre. March 2011. (Format: TXT, HTML) (Obsoletes RFC3920) (Updated by RFC7590, RFC8553) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6125) 6126 The Babel Routing Protocol. J. Chroboczek. April 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6127) 6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions. A. Begen. February 2011. (Format: TXT, HTML) (Updates RFC5760) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6128) 6129 The 'application/tei+xml' Media Type. L. Romary, S. Lundberg. February 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6131) 6132 Sieve Notification Using Presence Information. R. George, B. Leiba. July 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6133) 6134 Sieve Extension: Externally Stored Lists. A. Melnikov, B. Leiba. July 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6137) 6138 LDP IGP Synchronization for Broadcast Networks. S. Kini, Ed., W. Lu, Ed.. February 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6142) 6143 The Remote Framebuffer Protocol. T. Richardson, J. Levine. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6143) 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6144) 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6148) 6149 MD2 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (Obsoletes RFC1319) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6149) 6150 MD4 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6153) 6154 IMAP LIST Extension for Special-Use Mailboxes. B. Leiba, J. Nicolson. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3264) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6157) 6158 RADIUS Design Guidelines. A. DeKok, Ed., G. Weber. March 2011. (Format: TXT, HTML) (Updated by RFC6929, RFC8044) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6165) 6166 A Registry for PIM Message Types. S. Venaas. April 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6167) 6168 Requirements for Management of Name Servers for the DNS. W. Hardaker. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6168) 6169 Security Concerns with IP Tunneling. S. Krishnan, D. Thaler, J. Hoagland. April 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4369) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6173) 6174 Definition of IETF Working Group Document States. E. Juskevicius. March 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6175) 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0. S. Turner, T. Polk. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC3031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6178) 6179 The Internet Routing Overlay Network (IRON). F. Templin, Ed.. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6179) 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) 6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses. M. Bagnulo. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6185) 6186 Use of SRV Records for Locating Email Submission/Access Services. C. Daboo. March 2011. (Format: TXT, HTML) (Updates RFC1939, RFC3501) (Updated by RFC8314, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6186) 6187 X.509v3 Certificates for Secure Shell Authentication. K. Igoe, D. Stebila. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6190) 6191 Reducing the TIME-WAIT State Using TCP Timestamps. F. Gont. April 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6194) 6195 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6198) 6199 Not Issued. 6200 Not Issued. 6201 Device Reset Characterization. R. Asati, C. Pignataro, F. Calabria, C. Olvera. March 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6202) 6203 IMAP4 Extension for Fuzzy Search. T. Sirainen. March 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC3471) (Updated by RFC7699, RFC8359) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6207) 6208 Cloud Data Management Interface (CDMI) Media Types. K. Sankar, Ed., A. Jones. April 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6210) 6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute. J. Schaad. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6211) 6212 Authentication-Results Registration for Vouch by Reference Results. M. Kucherawy. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6212) 6213 IS-IS BFD-Enabled TLV. C. Hopps, L. Ginsberg. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6213) 6214 Adaptation of RFC 1149 for IPv6. B. Carpenter, R. Hinden. 1 April 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6216) 6217 Regional Broadcast Using an Atmospheric Link Layer. T. Ritter. 1 April 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6226) 6227 Design Goals for Scalable Internet Routing. T. Li, Ed.. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6227) 6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog. C. Holmberg. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6228) 6229 Test Vectors for the Stream Cipher RC4. J. Strombergson, S. Josefsson. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6229) 6230 Media Control Channel Framework. C. Boulton, T. Melanchuk, S. McGlashan. May 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4634) (Updates RFC3174) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6234) 6235 IP Flow Anonymization Support. E. Boschi, B. Trammell. May 2011. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6236) 6237 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. May 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6238) 6239 Suite B Cryptographic Suites for Secure Shell (SSH). K. Igoe. May 2011. (Format: TXT, HTML) (Status: HISTORIC) (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, HTML) (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, HTML) (Obsoletes RFC4741) (Updated by RFC7803, RFC8526) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6241) 6242 Using the NETCONF Protocol over Secure Shell (SSH). M. Wasserman. June 2011. (Format: TXT, HTML) (Obsoletes RFC4742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6242) 6243 With-defaults Capability for NETCONF. A. Bierman, B. Lengyel. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6243) 6244 An Architecture for Network Management Using NETCONF and YANG. P. Shafer. June 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6249) 6250 Evolution of the IP Model. D. Thaler. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6250) 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol. S. Josefsson. May 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6252) 6253 Host Identity Protocol Certificates. T. Heer, S. Varjonen. May 2011. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2754) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6254) 6255 Delay-Tolerant Networking Bundle Protocol IANA Registries. M. Blanchet. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6255) 6256 Using Self-Delimiting Numeric Values in Protocols. W. Eddy, E. Davies. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6256) 6257 Bundle Security Protocol Specification. S. Symington, S. Farrell, H. Weiss, P. Lovell. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6257) 6258 Delay-Tolerant Networking Metadata Extension Block. S. Symington. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6258) 6259 Delay-Tolerant Networking Previous-Hop Insertion Block. S. Symington. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6259) 6260 Compressed Bundle Header Encoding (CBHE). S. Burleigh. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6260) 6261 Encrypted Signaling Transport Modes for the Host Identity Protocol. A. Keranen. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6261) 6262 RTP Payload Format for IP-MR Speech Codec. S. Ikonin. August 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6264) 6265 HTTP State Management Mechanism. A. Barth. April 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6269) 6270 The 'tn3270' URI Scheme. M. Yevstifeyev. June 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6271) 6272 Internet Protocols for the Smart Grid. F. Baker, D. Meyer. June 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6273) 6274 Security Assessment of the Internet Protocol Version 4. F. Gont. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6274) 6275 Mobility Support in IPv6. C. Perkins, Ed., D. Johnson, J. Arkko. July 2011. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6276) 6277 Online Certificate Status Protocol Algorithm Agility. S. Santesson, P. Hallam-Baker. June 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4944) (Updated by RFC8066) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6287) 6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG). C. Reed. August 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Also BCP0161) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6291) 6292 Requirements for a Working Group Charter Tool. P. Hoffman. June 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6294) 6295 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. June 2011. (Format: TXT, HTML) (Obsoletes RFC4695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6295) 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. June 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6296) 6297 A Survey of Lower-than-Best-Effort Transport Protocols. M. Welzl, D. Ros. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6297) 6298 Computing TCP's Retransmission Timer. V. Paxson, M. Allman, J. Chu, M. Sargent. June 2011. (Format: TXT, HTML) (Obsoletes RFC2988) (Updates RFC1122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6298) 6299 Not Issued. 6300 Not Issued. 6301 A Survey of Mobility Support in the Internet. Z. Zhu, R. Wakikawa, L. Zhang. July 2011. (Format: TXT, HTML) (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, HTML) (Also BCP0162) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6302) 6303 Locally Served DNS Zones. M. Andrews. July 2011. (Format: TXT, HTML) (Also BCP0163) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6303) 6304 AS112 Nameserver Operations. J. Abley, W. Maton. July 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6305) 6306 Hierarchical IPv4 Framework. P. Frejborg. July 2011. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6307) 6308 Overview of the Internet Multicast Addressing Architecture. P. Savola. June 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6311) 6312 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. July 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6314) 6315 IANA Registration for Enumservice 'iax'. E. Guy, K. Darilion. July 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC5008) (Status: HISTORIC) (DOI: 10.17487/RFC6318) 6319 Issues Associated with Designating Additional Private IPv4 Address Space. M. Azinger, L. Vegoda. July 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC6327, RFC6439, RFC7172, RFC7177, RFC7357, RFC7179, RFC7180, RFC7455, RFC7780, RFC7783, RFC8139, RFC8249, RFC8361, RFC8377) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6330) 6331 Moving DIGEST-MD5 to Historic. A. Melnikov. July 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6339) 6340 Textual Conventions for the Representation of Floating-Point Numbers. R. Presuhn. August 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6341) 6342 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. August 2011. (Format: TXT, HTML) (Obsoletes RFC6312) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6342) 6343 Advisory Guidelines for 6to4 Deployment. B. Carpenter. August 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6346) 6347 Datagram Transport Layer Security Version 1.2. E. Rescorla, N. Modadugu. January 2012. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6348) 6349 Framework for TCP Throughput Testing. B. Constantine, G. Forget, R. Geib, R. Schrage. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6349) 6350 vCard Format Specification. S. Perreault. August 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC5953) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6353) 6354 Forward-Shifted RTP Redundancy Payload Support. Q. Xie. August 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6357) 6358 Additional Master Secret Inputs for TLS. P. Hoffman. January 2012. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6359) 6360 Conclusion of FYI RFC Sub-Series. R. Housley. August 2011. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6361) 6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT). K. Meadors, Ed.. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6362) 6363 Forward Error Correction (FEC) Framework. M. Watson, A. Begen, V. Roca. October 2011. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6364) 6365 Terminology Used in Internationalization in the IETF. P. Hoffman, J. Klensin. September 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6369) 6370 MPLS Transport Profile (MPLS-TP) Identifiers. M. Bocci, G. Swallow, E. Gray. September 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6373) 6374 Packet Loss and Delay Measurement for MPLS Networks. D. Frost, S. Bryant. September 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4871, RFC5672) (Updated by RFC8301, RFC8463, RFC8553, RFC8616) (Also STD0076) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6376) 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists. M. Kucherawy. September 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4869) (Status: HISTORIC) (DOI: 10.17487/RFC6379) 6380 Suite B Profile for Internet Protocol Security (IPsec). K. Burgin, M. Peck. October 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6380) 6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types. R. Gellens, D. Singer, P. Frojdh. August 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6389) 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6392) 6393 Moving RFC 4693 to Historic. M. Yevstifeyev. September 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6394) 6395 An Interface Identifier (ID) Hello Option for PIM. S. Gulrajani, S. Venaas. October 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6397) 6398 IP Router Alert Considerations and Usage. F. Le Faucheur, Ed.. October 2011. (Format: TXT, HTML) (Updates RFC2113, RFC2711) (Also BCP0168) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6398) 6399 Not Issued. 6400 Not Issued. 6401 RSVP Extensions for Admission Priority. F. Le Faucheur, J. Polk, K. Carlberg. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6401) 6402 Certificate Management over CMS (CMC) Updates. J. Schaad. November 2011. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6405) 6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture. D. Malas, Ed., J. Livingood, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6406) 6407 The Group Domain of Interpretation. B. Weis, S. Rowles, T. Hardjono. October 2011. (Format: TXT, HTML) (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, HTML) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6408) 6409 Message Submission for Mail. R. Gellens, J. Klensin. November 2011. (Format: TXT, HTML) (Obsoletes RFC4409) (Updated by RFC8314) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6413) 6414 Benchmarking Terminology for Protection Performance. S. Poretsky, R. Papneja, J. Karthik, S. Vapiwala. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6414) 6415 Web Host Metadata. E. Hammer-Lahav, Ed., B. Cook. October 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6417) 6418 Multiple Interfaces and Provisioning Domains Problem Statement. M. Blanchet, P. Seite. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6418) 6419 Current Practices for Multiple-Interface Hosts. M. Wasserman, P. Seite. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6419) 6420 PIM Multi-Topology ID (MT-ID) Join Attribute. Y. Cai, H. Ou. November 2011. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6421) 6422 Relay-Supplied DHCP Options. T. Lemon, Q. Wu. December 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8029) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6429) 6430 Email Feedback Report Type Value: not-spam. K. Li, B. Leiba. November 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6432) 6433 Requirements for a Working Group Milestones Tool. P. Hoffman. November 2011. (Format: TXT, HTML) (Updates RFC6292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6433) 6434 IPv6 Node Requirements. E. Jankiewicz, J. Loughney, T. Narten. December 2011. (Format: TXT, HTML) (Obsoletes RFC4294) (Obsoleted by RFC8504) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6436) 6437 IPv6 Flow Label Specification. S. Amante, B. Carpenter, S. Jiang, J. Rajahalme. November 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8139) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6440) 6441 Time to Remove Filters for Previously Unallocated IPv4 /8s. L. Vegoda. November 2011. (Format: TXT, HTML) (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, HTML) (Updated by RFC8262) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6447) 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message. R. Yount. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6448) 6449 Complaint Feedback Loop Operational Recommendations. J. Falk, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6449) 6450 Multicast Ping Protocol. S. Venaas. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6450) 6451 Location-to-Service Translation (LoST) Protocol Extensions. A. Forte, H. Schulzrinne. December 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6453) 6454 The Web Origin Concept. A. Barth. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6454) 6455 The WebSocket Protocol. I. Fette, A. Melnikov. December 2011. (Format: TXT, HTML) (Updated by RFC7936, RFC8307, RFC8441) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6459) 6460 Suite B Profile for Transport Layer Security (TLS). M. Salter, R. Housley. January 2012. (Format: TXT, HTML) (Obsoletes RFC5430) (Status: HISTORIC) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6461) 6462 Report from the Internet Privacy Workshop. A. Cooper. January 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6466) 6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2). T. Kivinen. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6467) 6468 Sieve Notification Mechanism: SIP MESSAGE. A. Melnikov, B. Leiba, K. Li. February 2012. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3189) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6469) 6470 Network Configuration Protocol (NETCONF) Base Notifications. A. Bierman. February 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also BCP0172) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6472) 6473 vCard KIND:application. P. Saint-Andre. December 2011. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6477) 6478 Pseudowire Status for Static Pseudowires. L. Martini, G. Swallow, G. Heron, M. Bocci. May 2012. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6479) 6480 An Infrastructure to Support Secure Internet Routing. M. Lepinski, S. Kent. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6480) 6481 A Profile for Resource Certificate Repository Structure. G. Huston, R. Loomans, G. Michaelson. February 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7318, RFC8209) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6492) 6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record. R. Bush. February 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6498) 6499 Not Issued. 6500 Not Issued. 6501 Conference Information Data Model for Centralized Conferencing (XCON). O. Novo, G. Camarillo, D. Morgan, J. Urpalainen. March 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6502) 6503 Centralized Conferencing Manipulation Protocol. M. Barnes, C. Boulton, S. Romano, H. Schulzrinne. March 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6505) 6506 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. February 2012. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6507) 6508 Sakai-Kasahara Key Encryption (SAKKE). M. Groves. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6508) 6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY). M. Groves. February 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6512) 6513 Multicast in MPLS/BGP IP VPNs. E. Rosen, Ed., R. Aggarwal, Ed.. February 2012. (Format: TXT, HTML) (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, HTML) (Updated by RFC6515, RFC6625, RFC7385, RFC7441, RFC7582, RFC7899, RFC7900, RFC7902, RFC7988, RFC8534) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6517) 6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines. G. Lebovitz, M. Bhatia. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6518) 6519 RADIUS Extensions for Dual-Stack Lite. R. Maglione, A. Durand. February 2012. (Format: TXT, HTML) (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, HTML) (Updated by RFC8447) (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, HTML) (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, HTML) (Obsoletes RFC3462) (Updated by RFC6533) (Also STD0073) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6522) 6523 Not Issued. 6524 Not Issued. 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration. R. Stewart, M. Tuexen, P. Lei. February 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2787) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6527) 6528 Defending against Sequence Number Attacks. F. Gont, S. Bellovin. February 2012. (Format: TXT, HTML) (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, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6529) 6530 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. February 2012. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6531) 6532 Internationalized Email Headers. A. Yang, S. Steele, N. Freed. February 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8341) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6536) 6537 Host Identity Protocol Distributed Hash Table Interface. J. Ahrenholz. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6537) 6538 The Host Identity Protocol (HIP) Experiment Report. T. Henderson, A. Gurtov. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6538) 6539 IBAKE: Identity-Based Authenticated Key Exchange. V. Cakulev, G. Sundaram, I. Broustis. March 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6542) 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6. S. Gundavelli. May 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6544) 6545 Real-time Inter-network Defense (RID). K. Moriarty. April 2012. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC6046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6546) 6547 RFC 3627 to Historic Status. W. George. February 2012. (Format: TXT, HTML) (Obsoletes RFC3627) (Updates RFC6164) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6547) 6548 Independent Submission Editor Model. N. Brownlee, Ed., IAB. June 2012. (Format: TXT, HTML) (Obsoletes RFC5620) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6548) 6549 OSPFv2 Multi-Instance Extensions. A. Lindem, A. Roy, S. Mirtorabi. March 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6554) 6555 Happy Eyeballs: Success with Dual-Stack Hosts. D. Wing, A. Yourtchenko. April 2012. (Format: TXT, HTML) (Obsoleted by RFC8305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6555) 6556 Testing Eyeball Happiness. F. Baker. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6556) 6557 Procedures for Maintaining the Time Zone Database. E. Lear, P. Eggert. February 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6559) 6560 One-Time Password (OTP) Pre-Authentication. G. Richards. April 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6562) 6563 Moving A6 to Historic Status. S. Jiang, D. Conrad, B. Carpenter. March 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6569) 6570 URI Template. J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard. March 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6572) 6573 The Item and Collection Link Relations. M. Amundsen. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6573) 6574 Report from the Smart Object Workshop. H. Tschofenig, J. Arkko. April 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6578) 6579 The 'disclosure' Link Relation Type. M. Yevstifeyev. March 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3782) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6582) 6583 Operational Neighbor Discovery Problems. I. Gashinsky, J. Jaeggli, W. Kumari. March 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6584) 6585 Additional HTTP Status Codes. M. Nottingham, R. Fielding. April 2012. (Format: TXT, HTML) (Updates RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6585) 6586 Experiences from an IPv6-Only Network. J. Arkko, A. Keranen. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6586) 6587 Transmission of Syslog Messages over TCP. R. Gerhards, C. Lonvick. April 2012. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6587) 6588 A URN Namespace for ucode. C. Ishikawa. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6588) 6589 Considerations for Transitioning Content to IPv6. J. Livingood. April 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6590) 6591 Authentication Failure Reporting Using the Abuse Reporting Format. H. Fontana. April 2012. (Format: TXT, HTML) (Updated by RFC6692) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6591) 6592 The Null Packet. C. Pignataro. 1 April 2012. (Format: TXT, HTML) (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. 1 April 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6595) 6596 The Canonical Link Relation. M. Ohye, J. Kupke. April 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC5735) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6598) 6599 Not Issued. 6600 Not Issued. 6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks. G. Ash, Ed., D. McDysan. April 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6603) 6604 xNAME RCODE and Status Bits Clarification. D. Eastlake 3rd. April 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6608) 6609 Sieve Email Filtering: Include Extension. C. Daboo, A. Stone. May 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6612) 6613 RADIUS over TCP. A. DeKok. May 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) 6621 Simplified Multicast Forwarding. J. Macker, Ed.. May 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC6514) (Updated by RFC7582, RFC7900, RFC8534) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6631) 6632 An Overview of the IETF Network Management Standards. M. Ersue, Ed., B. Claise. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6632) 6633 Deprecation of ICMP Source Quench Messages. F. Gont. May 2012. (Format: TXT, HTML) (Updates RFC0792, RFC1122, RFC1812) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6633) 6634 Not Issued. 6635 RFC Editor Model (Version 2). O. Kolkman, Ed., J. Halpern, Ed., IAB. June 2012. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6636) 6637 Elliptic Curve Cryptography (ECC) in OpenPGP. A. Jivsov. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6637) 6638 Scheduling Extensions to CalDAV. C. Daboo, B. Desruisseaux. June 2012. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6639) 6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions. W. George. June 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6643) 6644 Rebind Capability in DHCPv6 Reconfigure Messages. D. Evans, R. Droms, S. Jiang. July 2012. (Format: TXT, HTML) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6644) 6645 IP Flow Information Accounting and Export Benchmarking Methodology. J. Novak. July 2012. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6646) 6647 Email Greylisting: An Applicability Statement for SMTP. M. Kucherawy, D. Crocker. June 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6654) 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS). D. McGrew, D. Bailey. July 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6663) 6664 S/MIME Capabilities for Public Key Definitions. J. Schaad. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6664) 6665 SIP-Specific Event Notification. A.B. Roach. July 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6671) 6672 DNAME Redirection in the DNS. S. Rose, W. Wijngaards. June 2012. (Format: TXT, HTML) (Obsoletes RFC2672) (Updates RFC3363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6672) 6673 Round-Trip Packet Loss Metrics. A. Morton. August 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8311) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6687) 6688 Parallel NFS (pNFS) Block Disk Protection. D. Black, Ed., J. Glasgow, S. Faibish. July 2012. (Format: TXT, HTML) (Updates RFC5663) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6688) 6689 Usage of the RSVP ASSOCIATION Object. L. Berger. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6689) 6690 Constrained RESTful Environments (CoRE) Link Format. Z. Shelby. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6690) 6691 TCP Options and Maximum Segment Size (MSS). D. Borman. July 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6693) 6694 The "about" URI Scheme. S. Moonesamy, Ed.. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6694) 6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information. R. Asati. August 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7218, RFC7671) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6698) 6699 Not Issued. 6700 Not Issued. 6701 Sanctions Available for Application to Violators of IETF IPR Policy. A. Farrel, P. Resnick. August 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6703) 6704 Forcerenew Nonce Authentication. D. Miles, W. Dec, J. Bristow, R. Maglione. August 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6705) 6706 Asymmetric Extended Route Optimization (AERO). F. Templin, Ed.. August 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6708) 6709 Design Considerations for Protocol Extensions. B. Carpenter, B. Aboba, Ed., S. Cheshire. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6709) 6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities. A. Melnikov, K. Carlberg. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6710) 6711 An IANA Registry for Level of Assurance (LoA) Profiles. L. Johansson. August 2012. (Format: TXT, HTML) (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, HTML) (Updates RFC4210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6712) 6713 The 'application/zlib' and 'application/gzip' Media Types. J. Levine. August 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6715) 6716 Definition of the Opus Audio Codec. JM. Valin, K. Vos, T. Terriberry. September 2012. (Format: TXT, HTML) (Updated by RFC8251) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6717) 6718 Pseudowire Redundancy. P. Muley, M. Aissaoui, M. Bocci. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6718) 6719 The Minimum Rank with Hysteresis Objective Function. O. Gnawali, P. Levis. September 2012. (Format: TXT, HTML) (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, HTML) (Updates RFC5036) (Updated by RFC7552) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6720) 6721 The Atom "deleted-entry" Element. J. Snell. September 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8077) (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, HTML) (Obsoletes RFC3484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6724) 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates. S. Rose. August 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6728) 6729 Indicating Email Handling States in Trace Fields. D. Crocker, M. Kucherawy. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6729) 6730 Requirements for IETF Nominations Committee Tools. S. Krishnan, J. Halpern. September 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6731) 6732 6to4 Provider Managed Tunnels. V. Kuarsingh, Ed., Y. Lee, O. Vautrin. September 2012. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC3588, RFC5719) (Updated by RFC7075, RFC8553) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6734) 6735 Diameter Priority Attribute-Value Pairs. K. Carlberg, Ed., T. Taylor. October 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6736) 6737 The Diameter Capabilities Update Application. K. Jiao, G. Zorn. October 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6739) 6740 Identifier-Locator Network Protocol (ILNP) Architectural Description. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6740) 6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6745) 6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6748) 6749 The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. October 2012. (Format: TXT, HTML) (Obsoletes RFC5849) (Updated by RFC8252) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6751) 6752 Issues with Private IP Addressing in the Internet. A. Kirkham. September 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6754) 6755 An IETF URN Sub-Namespace for OAuth. B. Campbell, H. Tschofenig. October 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6760) 6761 Special-Use Domain Names. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Updates RFC1918, RFC2606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6761) 6762 Multicast DNS. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6762) 6763 DNS-Based Service Discovery. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Updated by RFC8553) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6767) 6768 ATM-Based xDSL Bonded Interfaces MIB. E. Beili. February 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4944) (Updated by RFC8505) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6781) 6782 Wireline Incremental IPv6. V. Kuarsingh, Ed., L. Howard. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6782) 6783 Mailing Lists and Non-ASCII Addresses. J. Levine, R. Gellens. November 2012. (Format: TXT, HTML) (Obsoletes RFC5983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6783) 6784 Kerberos Options for DHCPv6. S. Sakane, M. Ishiyama. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6784) 6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve. B. Leiba. November 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6786) 6787 Media Resource Control Protocol Version 2 (MRCPv2). D. Burnett, S. Shanmugham. November 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6796) 6797 HTTP Strict Transport Security (HSTS). J. Hodges, C. Jackson, A. Barth. November 2012. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6798) 6799 Not Issued. 6800 Not Issued. 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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6802) 6803 Camellia Encryption for Kerberos 5. G. Hudson. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6803) 6804 DISCOVER: Supporting Multicast DNS Queries. B. Manning. November 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8210) (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, HTML) (Updated by RFC8481) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6812) 6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis. J. Salowey, S. Hanna. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6813) 6814 Formally Deprecating Some IPv4 Options. C. Pignataro, F. Gont. November 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8202) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6822) 6823 Advertising Generic Information in IS-IS. L. Ginsberg, S. Previdi, M. Shand. December 2012. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC5787) (Updates RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6827) 6828 Content Splicing for RTP Sessions. J. Xia. January 2013. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC8029) (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, HTML) (Updated by RFC8113) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6832) 6833 Locator/ID Separation Protocol (LISP) Map-Server Interface. V. Fuller, D. Farinacci. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6833) 6834 Locator/ID Separation Protocol (LISP) Map-Versioning. L. Iannone, D. Saucez, O. Bonaventure. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6834) 6835 The Locator/ID Separation Protocol Internet Groper (LIG). D. Farinacci, D. Meyer. January 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6837) 6838 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin, T. Hansen. January 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6841) 6842 Client Identifier Option in DHCP Server Replies. N. Swamy, G. Halwasia, P. Jhingran. January 2013. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6843) 6844 DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, R. Stradling. January 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6849) 6850 Definitions of Managed Objects for Routing Bridges (RBridges). A. Rijhsinghani, K. Zebrose. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6850) 6851 Internet Message Access Protocol (IMAP) - MOVE Extension. A. Gulbrandsen, N. Freed, Ed.. January 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6852) 6853 DHCPv6 Redundancy Deployment Considerations. J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski. February 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC5721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6856) 6857 Post-Delivery Message Downgrading for Internationalized Email Messages. K. Fujiwara. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6857) 6858 Simplified POP and IMAP Downgrading for Internationalized Email. A. Gulbrandsen. March 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6863) 6864 Updated Specification of the IPv4 ID Field. J. Touch. February 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6867) 6868 Parameter Value Encoding in iCalendar and vCard. C. Daboo. February 2013. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6869) 6870 Pseudowire Preferential Forwarding Status Bit. P. Muley, Ed., M. Aissaoui, Ed.. February 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6879) 6880 An Information Model for Kerberos Version 5. L. Johansson. March 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6885) 6886 NAT Port Mapping Protocol (NAT-PMP). S. Cheshire, M. Krochmal. April 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4773, RFC5156, RFC5735, RFC5736) (Updated by RFC8190) (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, HTML) (Obsoletes RFC2671, RFC2673) (Also STD0075) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6891) 6892 The 'describes' Link Relation Type. E. Wilde. March 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6894) 6895 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. April 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6896) 6897 Multipath TCP (MPTCP) Application Interface Considerations. M. Scharf, A. Ford. March 2013. (Format: TXT, HTML) (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, HTML) (Updates RFC4204, RFC4207, RFC4209, RFC5818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6898) 6899 Not Issued. 6900 Not Issued. 6901 JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed., K. Zyp, M. Nottingham, Ed.. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6901) 6902 JavaScript Object Notation (JSON) Patch. P. Bryan, Ed., M. Nottingham, Ed.. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6902) 6903 Additional Link Relation Types. J. Snell. March 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6905) 6906 The 'profile' Link Relation Type. E. Wilde. March 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6914) 6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD). R. Bellis. April 2013. (Format: TXT, HTML) (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, HTML) (Also BCP0182) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6916) 6917 Media Resource Brokering. C. Boulton, L. Miniero, G. Munson. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6917) 6918 Formally Deprecating Some ICMPv4 Message Types. F. Gont, C. Pignataro. April 2013. (Format: TXT, HTML) (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. 1 April 2013. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6920) 6921 Design Considerations for Faster-Than-Light (FTL) Communication. R. Hinden. 1 April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6921) 6922 The application/sql Media Type. Y. Shafranovich. April 2013. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6923) 6924 Registration of Second-Level URN Namespaces under "ietf". B. Leiba. April 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6927) 6928 Increasing TCP's Initial Window. J. Chu, N. Dukkipati, Y. Cheng, M. Mathis. April 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6928) 6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions. A. DeKok, A. Lior. April 2013. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6930) 6931 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6932) 6933 Entity MIB (Version 4). A. Bierman, D. Romascanu, J. Quittek, M. Chandramouli. May 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6934) 6935 IPv6 and UDP Checksums for Tunneled Packets. M. Eubanks, P. Chimento, M. Westerlund. April 2013. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6936) 6937 Proportional Rate Reduction for TCP. M. Mathis, N. Dukkipati, Y. Cheng. May 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6942) 6943 Issues in Identifier Comparison for Security Purposes. D. Thaler, Ed.. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6943) 6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status. S. Rose. April 2013. (Format: TXT, HTML) (Obsoleted by RFC8624) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6945) 6946 Processing of IPv6 "Atomic" Fragments. F. Gont. May 2013. (Format: TXT, HTML) (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, HTML) (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, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6948) 6949 RFC Series Format Requirements and Future Development. H. Flanagan, N. Brownlee. May 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6954) 6955 Diffie-Hellman Proof-of-Possession Algorithms. J. Schaad, H. Prafullchandra. May 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8446) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6961) 6962 Certificate Transparency. B. Laurie, A. Langley, E. Kasper. June 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6962) 6963 A Uniform Resource Name (URN) Namespace for Examples. P. Saint-Andre. May 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6965) 6966 Not Issued. 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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6968) 6969 OSPFv3 Instance ID Registry Update. A. Retana, D. Cheng. July 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6974) 6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC). S. Crocker, S. Rose. July 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6976) 6977 Triggering DHCPv6 Reconfiguration from Relay Agents. M. Boucadair, X. Pougnard. July 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6977) 6978 A TCP Authentication Option Extension for NAT Traversal. J. Touch. July 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6979) 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery. F. Gont. August 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6981) 6982 Improving Awareness of Running Code: The Implementation Status Section. Y. Sheffer, A. Farrel. July 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6985) 6986 GOST R 34.11-2012: Hash Function. V. Dolmatov, Ed., A. Degtyarev. August 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6990) 6991 Common YANG Data Types. J. Schoenwaelder, Ed.. July 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6993) 6994 Shared Use of Experimental TCP Options. J. Touch. August 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6994) 6995 Not Issued. 6996 Autonomous System (AS) Reservation for Private Use. J. Mitchell. July 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6998) 6999 Not Issued. 7000 Not Issued. 7001 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. September 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, PDF, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7008) 7009 OAuth 2.0 Token Revocation. T. Lodderstedt, Ed., S. Dronia, M. Scurtescu. August 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7015) 7016 Adobe's Secure Real-Time Media Flow Protocol. M. Thornburgh. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7016) 7017 IMAP Access to IETF Email List Archives. R. Sparks. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7017) 7018 Auto-Discovery VPN Problem Statement and Requirements. V. Manral, S. Hanna. September 2013. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7019) 7020 The Internet Numbers Registry System. R. Housley, J. Curran, G. Huston, D. Conrad. August 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7028) 7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding. S. Hartman, M. Wasserman, D. Zhang. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7029) 7030 Enrollment over Secure Transport. M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed.. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7030) 7031 DHCPv6 Failover Requirements. T. Mrugalski, K. Kinnear. September 2013. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7032) 7033 WebFinger. P. Jones, G. Salgueiro, M. Jones, J. Smarr. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7033) 7034 HTTP Header Field X-Frame-Options. D. Ross, T. Gondrom. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7034) 7035 Relative Location Representation. M. Thomson, B. Rosen, D. Stanley, G. Bajko, A. Thomson. October 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7036) 7037 RADIUS Option for the DHCPv6 Relay Agent. L. Yeh, M. Boucadair. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7037) 7038 Use of OSPF-MDR in Single-Hop Broadcast Networks. R. Ogier. October 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7046) 7047 The Open vSwitch Database Management Protocol. B. Pfaff, B. Davie, Ed.. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7047) 7048 Neighbor Unreachability Detection Is Too Impatient. E. Nordmark, I. Gashinsky. January 2014. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7048) 7049 Concise Binary Object Representation (CBOR). C. Bormann, P. Hoffman. October 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7051) 7052 Locator/ID Separation Protocol (LISP) MIB. G. Schudel, A. Jain, V. Moreno. October 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7067) 7068 Diameter Overload Control Requirements. E. McMurry, B. Campbell. November 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7069) 7070 An Architecture for Reputation Reporting. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7070) 7071 A Media Type for Reputation Interchange. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7071) 7072 A Reputation Query Protocol. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7072) 7073 A Reputation Response Set for Email Identifiers. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7077) 7078 Distributing Address Selection Policy Using DHCPv6. A. Matsumoto, T. Fujisaki, T. Chown. January 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8415) (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, HTML) (Obsoletes RFC6204) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7084) 7085 Top-Level Domains That Are Already Dotless. J. Levine, P. Hoffman. December 2013. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7087) 7088 Session Initiation Protocol Service Example -- Music on Hold. D. Worley. February 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7092) 7093 Additional Methods for Generating Key Identifiers Values. S. Turner, S. Kent, J. Manger. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7093) 7094 Architectural Considerations of IP Anycast. D. McPherson, D. Oran, D. Thaler, E. Osterweil. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7094) 7095 jCard: The JSON Format for vCard. P. Kewisch. January 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7098) 7099 Not Issued. 7100 Retirement of the "Internet Official Protocol Standards" Summary Document. P. Resnick. December 2013. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7101) 7102 Terms Used in Routing for Low-Power and Lossy Networks. JP. Vasseur. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7102) 7103 Advice for Safe Handling of Malformed Messages. M. Kucherawy, G. Shapiro, N. Freed. January 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7106) 7107 Object Identifier Registry for the S/MIME Mail Security Working Group. R. Housley. January 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC6105) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7113) 7114 Creation of a Registry for smime-type Parameter Values. B. Leiba. January 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7119) 7120 Early IANA Allocation of Standards Track Code Points. M. Cotton. January 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7122) 7123 Security Implications of IPv6 on IPv4 Networks. F. Gont, W. Liu. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7123) 7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB. E. Beili. February 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7128) 7129 Authenticated Denial of Existence in the DNS. R. Gieben, W. Mekking. February 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7131) 7132 Threat Model for BGP Path Security. S. Kent, A. Chi. February 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7135) 7136 Significance of IPv6 Interface Identifiers. B. Carpenter, S. Jiang. February 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7140) 7141 Byte and Packet Congestion Notification. B. Briscoe, J. Manner. February 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7152) 7153 IANA Registries for BGP Extended Communities. E. Rosen, Y. Rekhter. March 2014. (Format: TXT, HTML) (Updates RFC4360, RFC5701) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7153) 7154 IETF Guidelines for Conduct. S. Moonesamy, Ed.. March 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7157) 7158 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. March 2014. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC4627, RFC7158) (Obsoleted by RFC8259) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC5031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7163) 7164 RTP and Leap Seconds. K. Gross, R. Brandenburg. March 2014. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7165) 7166 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. March 2014. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7167) 7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA). I. Nazar. 1 April 2014. (Format: TXT, HTML) (Updates RFC2324) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7168) 7169 The NSA (No Secrecy Afforded) Certificate Extension. S. Turner. 1 April 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8564) (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, HTML) (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, HTML) (Obsoletes RFC6327) (Updates RFC6325) (Updated by RFC7780, RFC8139, RFC8249, RFC8377, RFC8564) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7190) 7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types. R. Housley. April 2014. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7192) 7193 The application/cms Media Type. S. Turner, R. Housley, J. Schaad. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7193) 7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL. R. Hartmann. August 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7197) 7198 Duplicating RTP Streams. A. Begen, C. Perkins. April 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7200) 7201 Options for Securing RTP Sessions. M. Westerlund, C. Perkins. April 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7203) 7204 Requirements for Labeled NFS. T. Haynes. April 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7206) 7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging. M. Ortseifen, G. Dickfeld. April 2014. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC4408) (Updated by RFC7372, RFC8553, RFC8616) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7210) 7211 Operations Model for Router Keying. S. Hartman, D. Zhang. June 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7222) 7223 A YANG Data Model for Interface Management. M. Bjorklund. May 2014. (Format: TXT, HTML) (Obsoleted by RFC8343) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7223) 7224 IANA Interface Type YANG Module. M. Bjorklund. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7224) 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP). M. Boucadair. May 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7228) 7229 Object Identifiers for Test Certificate Policies. R. Housley. May 2014. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2145, RFC2616) (Updates RFC2817, RFC2818) (Updated by RFC8615) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7236) 7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations. J. Reschke. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7237) 7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. June 2014. (Format: TXT, HTML) (Obsoleted by RFC7538) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7238) 7239 Forwarded HTTP Extension. A. Petersson, M. Nilsson. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7239) 7240 Prefer Header for HTTP. J. Snell. June 2014. (Format: TXT, HTML) (Updated by RFC8144) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7248) 7249 Internet Numbers Registries. R. Housley. May 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7251) 7252 The Constrained Application Protocol (CoAP). Z. Shelby, K. Hartke, C. Bormann. June 2014. (Format: TXT, HTML) (Updated by RFC7959, RFC8613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7252) 7253 The OCB Authenticated-Encryption Algorithm. T. Krovetz, P. Rogaway. May 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7257) 7258 Pervasive Monitoring Is an Attack. S. Farrell, H. Tschofenig. May 2014. (Format: TXT, HTML) (Also BCP0188) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7258) 7259 The Jabber-ID Header Field. P. Saint-Andre. May 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7261) 7262 Requirements for Telepresence Multistreams. A. Romanow, S. Botzko, M. Barnes. June 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7264) 7265 jCal: The JSON Format for iCalendar. P. Kewisch, C. Daboo, M. Douglass. May 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC3580, RFC4072) (Updated by RFC8044) (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, HTML) (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, HTML) (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, HTML) (Updates RFC6378) (Updated by RFC8234) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7276) 7277 A YANG Data Model for IP Management. M. Bjorklund. June 2014. (Format: TXT, HTML) (Obsoleted by RFC8344) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7280) 7281 Authentication-Results Registration for S/MIME Signature Verification. A. Melnikov. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7281) 7282 On Consensus and Humming in the IETF. P. Resnick. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7282) 7283 Handling Unknown DHCPv6 Messages. Y. Cui, Q. Sun, T. Lemon. July 2014. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7283) 7284 The Profile URI Registry. M. Lanthaler. June 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7287) 7288 Reflections on Host Firewalls. D. Thaler. June 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC5996) (Updated by RFC7427, RFC7670, RFC8247) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7297) 7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication. D. Ovsienko. July 2014. (Format: TXT, HTML) (Updates RFC6126) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7298) 7299 Object Identifier Registry for the PKIX Working Group. R. Housley. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7299) 7300 Reservation of Last Autonomous System (AS) Numbers. J. Haas, J. Mitchell. July 2014. (Format: TXT, HTML) (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, HTML) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7301) 7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. July 2014. (Format: TXT, HTML) (Obsoleted by RFC7972) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7302) 7303 XML Media Types. H. Thompson, C. Lilley. July 2014. (Format: TXT, HTML) (Obsoletes RFC3023) (Updates RFC6839) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7303) 7304 A Method for Mitigating Namespace Collisions. W. Kumari. July 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7307) 7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE). E. Osborne. July 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC2918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7313) 7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option. M. Andrews. July 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7316) 7317 A YANG Data Model for System Management. A. Bierman, M. Bjorklund. August 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Also BCP0191) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7319) 7320 URI Design and Ownership. M. Nottingham. July 2014. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC4835) (Obsoleted by RFC8221) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7321) 7322 RFC Style Guide. H. Flanagan, S. Ginoza. September 2014. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC1323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7323) 7324 Updates to MPLS Transport Profile Linear Protection. E. Osborne. July 2014. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7325) 7326 Energy Management Framework. J. Parello, B. Claise, B. Schoening, J. Quittek. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7326) 7327 Not Issued. 7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML. R. Gieben. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7328) 7329 A Session Identifier for the Session Initiation Protocol (SIP). H. Kaplan. August 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7334) 7335 IPv4 Service Continuity Prefix. C. Byrne. August 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7338) 7339 Session Initiation Protocol (SIP) Overload Control. V. Gurbani, Ed., V. Hilt, H. Schulzrinne. September 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8078) (Status: PROPOSED STANDARD) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7345) 7346 IPv6 Multicast Address Scopes. R. Droms. August 2014. (Format: TXT, HTML) (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, PDF, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7348) 7349 LDP Hello Cryptographic Authentication. L. Zheng, M. Chen, M. Bhatia. August 2014. (Format: TXT, HTML) (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, HTML) (Updates RFC5389, RFC5928) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7350) 7351 A Media Type for XML Patch Operations. E. Wilde. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7351) 7352 Sieve Email Filtering: Detecting Duplicate Deliveries. S. Bosch. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7352) 7353 Security Requirements for BGP Path Validation. S. Bellovin, R. Bush, D. Ward. August 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7359) 7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS. A. DeKok. September 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7369) 7370 Updates to the IS-IS TLV Codepoints Registry. L. Ginsberg. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7370) 7371 Updates to the IPv6 Multicast Addressing Architecture. M. Boucadair, S. Venaas. September 2014. (Format: TXT, HTML) (Updates RFC3306, RFC3956, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7371) 7372 Email Authentication Status Codes. M. Kucherawy. September 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7374) 7375 Secure Telephone Identity Threat Model. J. Peterson. October 2014. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7376) 7377 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. October 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7383) 7384 Security Requirements of Time Protocols in Packet Switched Networks. T. Mizrahi. October 2014. (Format: TXT, HTML) (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, HTML) (Updates RFC6514) (Updated by RFC8317, RFC8338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7385) 7386 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7390) 7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions. J. Hadi Salim. October 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7395) 7396 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7398) 7399 Unanswered Questions in the Path Computation Element Architecture. A. Farrel, D. King. October 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7404) 7405 Case-Sensitive String Support in ABNF. P. Kyzivat. December 2014. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7406) 7407 A YANG Data Model for SNMP Configuration. M. Bjorklund, J. Schoenwaelder. December 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7407) 7408 Forwarding and Control Element Separation (ForCES) Model Extension. E. Haleplidis. November 2014. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7409) 7410 A Property Types Registry for the Authentication-Results Header Field. M. Kucherawy. December 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7412) 7413 TCP Fast Open. Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain. December 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7417) 7418 An IRTF Primer for IETF Participants. S. Dawkins, Ed.. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7418) 7419 Common Interval Support in Bidirectional Forwarding Detection. N. Akiya, M. Binderberger, G. Mirsky. December 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7422) 7423 Diameter Applications Design Guidelines. L. Morand, Ed., V. Fajardo, H. Tschofenig. November 2014. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7424) 7425 Adobe's RTMFP Profile for Flash Communication. M. Thornburgh. December 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7430) 7431 Multicast-Only Fast Reroute. A. Karan, C. Filsfils, IJ. Wijnands, Ed., B. Decraene. August 2015. (Format: TXT, HTML) (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, HTML) (Updated by RFC8584) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7434) 7435 Opportunistic Security: Some Protection Most of the Time. V. Dukhovni. December 2014. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3777, RFC5078, RFC5633, RFC5680, RFC6859) (Updated by RFC7776, RFC8318) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7439) 7440 TFTP Windowsize Option. P. Masotta. January 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7443) 7444 Security Labels in Internet Email. K. Zeilenga, A. Melnikov. February 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7446) 7447 Deprecation of BGP Entropy Label Capability Attribute. J. Scudder, K. Kompella. February 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7449) 7450 Automatic Multicast Tunneling. G. Bumgardner. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7450) 7451 Extension Registry for the Extensible Provisioning Protocol. S. Hollenbeck. February 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7453) 7454 BGP Operations and Security. J. Durand, I. Pepelnjak, G. Doering. February 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7460) 7461 Energy Object Context MIB. J. Parello, B. Claise, M. Chandramouli. March 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC3261, RFC4235) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7463) 7464 JavaScript Object Notation (JSON) Text Sequences. N. Williams. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7464) 7465 Prohibiting RC4 Cipher Suites. A. Popov. February 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7467) 7468 Textual Encodings of PKIX, PKCS, and CMS Structures. S. Josefsson, S. Leonard. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7468) 7469 Public Key Pinning Extension for HTTP. C. Evans, C. Palmer, R. Sleevi. April 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8223) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7476) 7477 Child-to-Parent Synchronization in DNS. W. Hardaker. March 2015. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7478) 7479 Using Ed25519 in SSHFP Resource Records. S. Moonesamy. March 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7481) 7482 Registration Data Access Protocol (RDAP) Query Format. A. Newton, S. Hollenbeck. March 2015. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7483) 7484 Finding the Authoritative Registration Data (RDAP) Service. M. Blanchet. March 2015. (Format: TXT, HTML) (Updated by RFC8521) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7485) 7486 HTTP Origin-Bound Authentication (HOBA). S. Farrell, P. Hoffman, M. Thomas. March 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8553, RFC8616) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7492) 7493 The I-JSON Message Format. T. Bray, Ed.. March 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7496) 7497 Rate Measurement Test Protocol Problem Statement and Requirements. A. Morton. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7497) 7498 Problem Statement for Service Function Chaining. P. Quinn, Ed., T. Nadeau, Ed.. April 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7502) 7503 OSPFv3 Autoconfiguration. A. Lindem, J. Arkko. April 2015. (Format: TXT, HTML) (Updates RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7503) 7504 SMTP 521 and 556 Reply Codes. J. Klensin. June 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7510) 7511 Scenic Routing for IPv6. M. Wilhelm. 1 April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7511) 7512 The PKCS #11 URI Scheme. J. Pechanec, D. Moffat. April 2015. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) 7514 Really Explicit Congestion Notification (RECN). M. Luckie. 1 April 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7514) 7515 JSON Web Signature (JWS). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7515) 7516 JSON Web Encryption (JWE). M. Jones, J. Hildebrand. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7516) 7517 JSON Web Key (JWK). M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7517) 7518 JSON Web Algorithms (JWA). M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7518) 7519 JSON Web Token (JWT). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8534) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3530) (Updated by RFC7931, RFC8587) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7533) 7534 AS112 Nameserver Operations. J. Abley, W. Sotomayor. May 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8029) (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, HTML) (Obsoletes RFC7238) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7538) 7539 ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8439) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7540) 7541 HPACK: Header Compression for HTTP/2. R. Peon, H. Ruellan. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7541) 7542 The Network Access Identifier. A. DeKok. May 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7545) 7546 Structure of the Generic Security Service (GSS) Negotiation Loop. B. Kaduk. May 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8415) (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, HTML) (Updated by RFC8537) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7554) 7555 Proxy MPLS Echo Request. G. Swallow, V. Lim, S. Aldrin. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7555) 7556 Multiple Provisioning Domain Architecture. D. Anipko, Ed.. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7556) 7557 Extension Mechanism for the Babel Routing Protocol. J. Chroboczek. May 2015. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7558) 7559 Packet-Loss Resiliency for Router Solicitations. S. Krishnan, D. Anipko, D. Thaler. May 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3454) (Obsoleted by RFC8264) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7564) 7565 The 'acct' URI Scheme. P. Saint-Andre. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7565) 7566 Enumservice Registration for 'acct' URI. L. Goix, K. Li. June 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7566) 7567 IETF Recommendations Regarding Active Queue Management. F. Baker, Ed., G. Fairhurst, Ed.. July 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7575) 7576 General Gap Analysis for Autonomic Networking. S. Jiang, B. Carpenter, M. Behringer. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7576) 7577 Definition of Managed Objects for Battery Monitoring. J. Quittek, R. Winter, T. Dietz. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7577) 7578 Returning Values from Forms: multipart/form-data. L. Masinter. July 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC6513, RFC6514, RFC6625) (Updated by RFC8534) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7592) 7593 The eduroam Architecture for Network Roaming. K. Wierenga, S. Winter, T. Wolniewicz. September 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4395) (Updated by RFC8615) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8539) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7600) 7601 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. August 2015. (Format: TXT, HTML) (Obsoletes RFC7001, RFC7410) (Obsoleted by RFC8601) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7602) 7603 Energy Management (EMAN) Applicability Statement. B. Schoening, M. Chandramouli, B. Nordman. August 2015. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7604) 7605 Recommendations on Using Assigned Transport Port Numbers. J. Touch. August 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC4013) (Obsoleted by RFC8265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7613) 7614 Explicit Subscriptions for the REFER Method. R. Sparks. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7614) 7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields. J. Reschke. September 2015. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7616) 7617 The 'Basic' HTTP Authentication Scheme. J. Reschke. September 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7625) 7626 DNS Privacy Considerations. S. Bortzmeyer. August 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7632) 7633 X.509v3 Transport Layer Security (TLS) Feature Extension. P. Hallam-Baker. October 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7637) 7638 JSON Web Key (JWK) Thumbprint. M. Jones, N. Sakimura. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7638) 7639 The ALPN HTTP Header Field. A. Hutton, J. Uberti, M. Thomson. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7639) 7640 Traffic Management Benchmarking. B. Constantine, R. Krishnan. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7640) 7641 Observing Resources in the Constrained Application Protocol (CoAP). K. Hartke. September 2015. (Format: TXT, HTML) (Updated by RFC8323) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7648) 7649 The Jabber Scribe Role at IETF Meetings. P. Saint-Andre, D. York. September 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7652) 7653 DHCPv6 Active Leasequery. D. Raghuvanshi, K. Kinnear, D. Kukrety. October 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7656) 7657 Differentiated Services (Diffserv) and Real-Time Communication. D. Black, Ed., P. Jones. November 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7659) 7660 Diameter Congestion and Filter Attributes. L. Bertz, S. Manning, B. Hirschman. October 2015. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC2861) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7661) 7662 OAuth 2.0 Token Introspection. J. Richer, Ed.. October 2015. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7663) 7664 Dragonfly Key Exchange. D. Harkins, Ed.. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7664) 7665 Service Function Chaining (SFC) Architecture. J. Halpern, Ed., C. Pignataro, Ed.. October 2015. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7666) 7667 RTP Topologies. M. Westerlund, S. Wenger. November 2015. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7668) 7669 Assigning Digital Object Identifiers to RFCs. J. Levine. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7669) 7670 Generic Raw Public-Key Support for IKEv2. T. Kivinen, P. Wouters, H. Tschofenig. January 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7673) 7674 Clarification of the Flowspec Redirect Extended Community. J. Haas, Ed.. October 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2680) (Also STD0082) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7680) 7681 Email Exchange of Secondary School Transcripts. J. Davin. October 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updated by RFC8581) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7684) 7685 A Transport Layer Security (TLS) ClientHello Padding Extension. A. Langley. October 2015. (Format: TXT, HTML) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7685) 7686 The ".onion" Special-Use Domain Name. J. Appelbaum, A. Muffett. October 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4071) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7691) 7692 Compression Extensions for WebSocket. T. Yoshino. December 2015. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7693) 7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding. J. Reschke. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7694) 7695 Distributed Prefix Assignment Algorithm. P. Pfister, B. Paterson, J. Arkko. November 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoleted by RFC8266) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7703) 7704 An IETF with Much Diversity and Professional Conduct. D. Crocker, N. Clark. November 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7706) 7707 Network Reconnaissance in IPv6 Networks. F. Gont, T. Chown. March 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7710) 7711 PKIX over Secure HTTP (POSH). M. Miller, P. Saint-Andre. November 2015. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7712) 7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements. M. Mathis, B. Briscoe. December 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC4656) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7718) 7719 DNS Terminology. P. Hoffman, A. Sullivan, K. Fujiwara. December 2015. (Format: TXT, HTML) (Obsoleted by RFC8499) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7719) 7720 DNS Root Name Service Protocol and Deployment Requirements. M. Blanchet, L-J. Liman. December 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC7188, RFC7631) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7722) 7723 Port Control Protocol (PCP) Anycast Addresses. S. Kiesel, R. Penno. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7723) 7724 Active DHCPv4 Lease Query. K. Kinnear, M. Stapp, B. Volz, N. Russell. December 2015. (Format: TXT, HTML) (Updates RFC6926) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7724) 7725 An HTTP Status Code to Report Legal Obstacles. T. Bray. February 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC6490) (Obsoleted by RFC8630) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7734) 7735 Tracking Reviews of Documents. R. Sparks, T. Kivinen. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7735) 7736 Content Delivery Network Interconnection (CDNI) Media Type Registration. K. Ma. December 2015. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7738) 7739 Security Implications of Predictable Fragment Identification Values. F. Gont. February 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7741) 7742 WebRTC Video Processing and Codec Requirements. A.B. Roach. March 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7744) 7745 XML Schemas for Reverse DNS Management. T. Manderson. January 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7747) 7748 Elliptic Curves for Security. A. Langley, M. Hamburg, S. Turner. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7748) 7749 The "xml2rfc" Version 2 Vocabulary. J. Reschke. February 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7754) 7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments. T. Anderson. February 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7756) 7757 Explicit Address Mappings for Stateless IP/ICMP Translation. T. Anderson, A. Leiva Popper. February 2016. (Format: TXT, HTML) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7757) 7758 Time Capability in NETCONF. T. Mizrahi, Y. Moses. February 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7762) 7763 The text/markdown Media Type. S. Leonard. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7763) 7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations. S. Leonard. March 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC5966) (Updates RFC1035, RFC1123) (Updated by RFC8490) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC6870) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7771) 7772 Reducing Energy Consumption of Router Advertisements. A. Yourtchenko, L. Colitti. February 2016. (Format: TXT, HTML) (Also BCP0202) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7772) 7773 Authentication Context Certificate Extension. S. Santesson. March 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Updates RFC5308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7775) 7776 IETF Anti-Harassment Procedures. P. Resnick, A. Farrel. March 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC7180) (Updates RFC6325, RFC7177, RFC7179) (Updated by RFC8249) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7785) 7786 TCP Modifications for Congestion Exposure (ConEx). M. Kuehlewind, Ed., R. Scheffenegger. May 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7786) 7787 Distributed Node Consensus Protocol. M. Stenberg, S. Barth. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7787) 7788 Home Networking Control Protocol. M. Stenberg, S. Barth, P. Pfister. April 2016. (Format: TXT, HTML) (Updated by RFC8375) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7796) 7797 JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. February 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7800) 7801 GOST R 34.12-2015: Block Cipher "Kuznyechik". V. Dolmatov, Ed.. March 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7806) 7807 Problem Details for HTTP APIs. M. Nottingham, E. Wilde. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7807) 7808 Time Zone Data Distribution Service. M. Douglass, C. Daboo. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7808) 7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference. C. Daboo. March 2016. (Format: TXT, HTML) (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, HTML) (Obsoleted by RFC8570) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7814) 7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation. T. Kivinen. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7815) 7816 DNS Query Name Minimisation to Improve Privacy. S. Bortzmeyer. March 2016. (Format: TXT, HTML) (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, HTML) (Updates RFC2595, RFC3207, RFC3501, RFC5804) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7817) 7818 URN Namespace for MEF Documents. M. Jethanandani. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7818) 7819 Privacy Considerations for DHCP. S. Jiang, S. Krishnan, T. Mrugalski. April 2016. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7820) 7821 UDP Checksum Complement in the Network Time Protocol (NTP). T. Mizrahi. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7821) 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields. T. Mizrahi, D. Mayer. March 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7823) 7824 Privacy Considerations for DHCPv6. S. Krishnan, T. Mrugalski, S. Jiang. May 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Obsoletes RFC2326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7826) 7827 The Role of the IRTF Chair. L. Eggert. March 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7829) 7830 The EDNS(0) Padding Option. A. Mayrhofer. May 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7831) 7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases. R. Smith, Ed.. May 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7834) 7835 Locator/ID Separation Protocol (LISP) Threat Analysis. D. Saucez, L. Iannone, O. Bonaventure. April 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7837) 7838 HTTP Alternative Services. M. Nottingham, P. McManus, J. Reschke. April 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC5334) (Updated by RFC8486) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7847) 7848 Mark and Signed Mark Objects Mapping. G. Lozano. June 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7853) 7854 BGP Monitoring Protocol (BMP). J. Scudder, Ed., R. Fernando, S. Stuart. June 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8310) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updated by RFC8178) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7863) 7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility. CJ. Bernardos, Ed.. May 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7868) 7869 The "vnc" URI Scheme. D. Warden, I. Iordanov. May 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7872) 7873 Domain Name System (DNS) Cookies. D. Eastlake 3rd, M. Andrews. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7873) 7874 WebRTC Audio Codec and Processing Requirements. JM. Valin, C. Bran. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7874) 7875 Additional WebRTC Audio Codecs for Interoperability. S. Proust, Ed.. May 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7886) 7887 Hierarchical Join/Prune Attributes. S. Venaas, J. Arango, I. Kouvelas. June 2016. (Format: TXT, HTML) (Updates RFC5384) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7887) 7888 IMAP4 Non-synchronizing Literals. A. Melnikov, Ed.. May 2016. (Format: TXT, HTML) (Obsoletes RFC2088) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7888) 7889 The IMAP APPENDLIMIT Extension. J. SrimushnamBoovaraghamoorthy, N. Bisht. May 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7892) 7893 Pseudowire Congestion Considerations. Y(J) Stein, D. Black, B. Briscoe. June 2016. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7893) 7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport. M. Pritikin, C. Wallace. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7894) 7895 YANG Module Library. A. Bierman, M. Bjorklund, K. Watsen. June 2016. (Format: TXT, HTML) (Obsoleted by RFC8525) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC6513, RFC6514, RFC6625) (Updated by RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7900) 7901 CHAIN Query Requests in DNS. P. Wouters. June 2016. (Format: TXT, HTML) (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, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7902) 7903 Windows Image Media Types. S. Leonard. September 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7906) 7907 Not Issued. 7908 Problem Definition and Classification of BGP Route Leaks. K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson. June 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7912) 7913 P-Access-Network-Info ABNF Update. C. Holmberg. June 2016. (Format: TXT, HTML) (Updates RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7913) 7914 The scrypt Password-Based Key Derivation Function. C. Percival, S. Josefsson. August 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7917) 7918 Transport Layer Security (TLS) False Start. A. Langley, N. Modadugu, B. Moeller. August 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7922) 7923 Requirements for Subscription to YANG Datastores. E. Voit, A. Clemm, A. Gonzalez Prieto. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7923) 7924 Transport Layer Security (TLS) Cached Information Extension. S. Santesson, H. Tschofenig. July 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7928) 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. P. Wouters. August 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7929) 7930 Larger Packets for RADIUS over TCP. S. Hartman. August 2016. (Format: TXT, HTML) (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, HTML) (Updates RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7931) 7932 Brotli Compressed Data Format. J. Alakuijala, Z. Szabadka. July 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7933) 7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July 2016. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC6485) (Updated by RFC8208, RFC8608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7935) 7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry. T. Hardie. July 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC6779) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7939) 7940 Representing Label Generation Rulesets Using XML. K. Davies, A. Freytag. August 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7943) 7944 Diameter Routing Message Priority. S. Donovan. August 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7948) 7949 OSPFv3 over IPv4 for IPv6 Transition. I. Chen, A. Lindem, R. Atkinson. August 2016. (Format: TXT, HTML) (Updates RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7949) 7950 The YANG 1.1 Data Modeling Language. M. Bjorklund, Ed.. August 2016. (Format: TXT, HTML) (Updated by RFC8342, RFC8526) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7950) 7951 JSON Encoding of Data Modeled with YANG. L. Lhotka. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7951) 7952 Defining and Using Metadata with YANG. L. Lhotka. August 2016. (Format: TXT, HTML) (Updates RFC6110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7952) 7953 Calendar Availability. C. Daboo, M. Douglass. August 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC7252) (Updated by RFC8323) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7969) 7970 The Incident Object Description Exchange Format Version 2. R. Danyliw. November 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7971) 7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. September 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7973) 7974 An Experimental TCP Option for Host Identification. B. Williams, M. Boucadair, D. Wing. October 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7980) 7981 IS-IS Extensions for Advertising Router Information. L. Ginsberg, S. Previdi, M. Chen. October 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Updates RFC7186) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7985) 7986 New Properties for iCalendar. C. Daboo. October 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC7329) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7989) 7990 RFC Format Framework. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7990) 7991 The "xml2rfc" Version 3 Vocabulary. P. Hoffman. December 2016. (Format: TXT, HTML) (Obsoletes RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7991) 7992 HTML Format for RFCs. J. Hildebrand, Ed., P. Hoffman. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7992) 7993 Cascading Style Sheets (CSS) Requirements for RFCs. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7993) 7994 Requirements for Plain-Text RFCs. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7994) 7995 PDF Format for RFCs. T. Hansen, Ed., L. Masinter, M. Hardy. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7995) 7996 SVG Drawings for RFCs: SVG 1.2 RFC. N. Brownlee. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7996) 7997 The Use of Non-ASCII Characters in RFCs. H. Flanagan, Ed.. December 2016. (Format: TXT, PDF, HTML) (Updates RFC7322) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7997) 7998 "xml2rfc" Version 3 Preparation Tool Description. P. Hoffman, J. Hildebrand. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7998) 7999 BLACKHOLE Community. T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7999) 8000 Requirements for NFSv4 Multi-Domain Namespace Deployment. A. Adamson, N. Williams. November 2016. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8001) 8002 Host Identity Protocol Certificates. T. Heer, S. Varjonen. October 2016. (Format: TXT, HTML) (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, HTML) (Obsoletes RFC5203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8003) 8004 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. October 2016. (Format: TXT, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8009) 8010 Internet Printing Protocol/1.1: Encoding and Transport. M. Sweet, I. McDonald. January 2017. (Format: TXT, HTML) (Obsoletes RFC2910, RFC3382) (Also STD0092) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8010) 8011 Internet Printing Protocol/1.1: Model and Semantics. M. Sweet, I. McDonald. January 2017. (Format: TXT, HTML) (Obsoletes RFC2911, RFC3381, RFC3382) (Also STD0092) (Status: INTERNET 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, HTML) (Updates RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8012) 8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB). D. Joachimpillai, J. Hadi Salim. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8013) 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, HTML) (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, HTML) (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, HTML) (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, HTML) (Obsoletes RFC3447) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8017) 8018 PKCS #5: Password-Based Cryptography Specification Version 2.1. K. Moriarty, Ed., B. Kaliski, A. Rusch. January 2017. (Format: TXT, HTML) (Obsoletes RFC2898) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8018) 8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks. Y. Nir, V. Smyslov. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8019) 8020 NXDOMAIN: There Really Is Nothing Underneath. S. Bortzmeyer, S. Huque. November 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8021) 8022 A YANG Data Model for Routing Management. L. Lhotka, A. Lindem. November 2016. (Format: TXT, HTML) (Obsoleted by RFC8349) (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, HTML) (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, HTML) (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, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8026) 8027 DNSSEC Roadblock Avoidance. W. Hardaker, O. Gudmundsson, S. Krishnaswamy. November 2016. (Format: TXT, HTML) (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, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8028) 8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures. K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen. March 2017. (Format: TXT, HTML) (Obsoletes RFC4379, RFC6424, RFC6829, RFC7537) (Updates RFC1122) (Updated by RFC8611) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8029) 8030 Generic Event Delivery Using HTTP Push. M. Thomson, E. Damaggio, B. Raymor, Ed.. December 2016. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8031) 8032 Edwards-Curve Digital Signature Algorithm (EdDSA). S. Josefsson, I. Liusvaara. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8032) 8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem. R. Pan, P. Natarajan, F. Baker, G. White. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8033) 8034 Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems. G. White, R. Pan. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8034) 8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing. C. Holmberg. November 2016. (Format: TXT, HTML) (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, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8036) 8037 CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE). I. Liusvaara. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8037) 8038 Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol. P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8038) 8039 Multipath Time Synchronization. A. Shpiner, R. Tse, C. Schelp, T. Mizrahi. December 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8039) 8040 RESTCONF Protocol. A. Bierman, M. Bjorklund, K. Watsen. January 2017. (Format: TXT, HTML) (Updated by RFC8527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8040) 8041 Use Cases and Operational Experience with Multipath TCP. O. Bonaventure, C. Paasch, G. Detal. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8041) 8042 OSPF Two-Part Metric. Z. Zhang, L. Wang, A. Lindem. December 2016. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8043) 8044 Data Types in RADIUS. A. DeKok. January 2017. (Format: TXT, HTML) (Updates RFC2865, RFC3162, RFC4072, RFC6158, RFC6572, RFC7268) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8044) 8045 RADIUS Extensions for IP Port Configuration and Reporting. D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8045) 8046 Host Mobility with the Host Identity Protocol. T. Henderson, Ed., C. Vogt, J. Arkko. February 2017. (Format: TXT, HTML) (Obsoletes RFC5206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8046) 8047 Host Multihoming with the Host Identity Protocol. T. Henderson, Ed., C. Vogt, J. Arkko. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8047) 8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence. P. Saint-Andre. December 2016. (Format: TXT, HTML) (Obsoletes RFC7248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8048) 8049 YANG Data Model for L3VPN Service Delivery. S. Litkowski, L. Tomotaki, K. Ogaki. February 2017. (Format: TXT, HTML) (Obsoleted by RFC8299) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8049) 8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions. C. Petrie, T. King. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8050) 8051 Applicability of a Stateful Path Computation Element (PCE). X. Zhang, Ed., I. Minei, Ed.. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8051) 8052 Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services. B. Weis, M. Seewald, H. Falk. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8052) 8053 HTTP Authentication Extensions for Interactive Clients. Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. January 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8053) 8054 Network News Transfer Protocol (NNTP) Extension for Compression. K. Murchison, J. Elie. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8054) 8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm. C. Holmberg, Y. Jiang. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8055) 8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping. J. Gould. January 2017. (Format: TXT, HTML) (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, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8057) 8058 Signaling One-Click Functionality for List Email Headers. J. Levine, T. Herkula. January 2017. (Format: TXT, HTML) (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, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8059) 8060 LISP Canonical Address Format (LCAF). D. Farinacci, D. Meyer, J. Snijders. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8060) 8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality. D. Farinacci, B. Weis. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8061) 8062 Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman, S. Emery, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC6112) (Updates RFC4120, RFC4121, RFC4556) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8062) 8063 Key Relay Mapping for the Extensible Provisioning Protocol. H.W. Ribbers, M.W. Groeneweg, R. Gieben, A.L.J. Verschuren. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8063) 8064 Recommendation on Stable IPv6 Interface Identifiers. F. Gont, A. Cooper, D. Thaler, W. Liu. February 2017. (Format: TXT, HTML) (Updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, RFC5121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8064) 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms. D. Thaler. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8065) 8066 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines. S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt. February 2017. (Format: TXT, HTML) (Updates RFC4944, RFC6282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8066) 8067 Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level. B. Leiba. January 2017. (Format: TXT, HTML) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8067) 8068 Session Initiation Protocol (SIP) Recording Call Flows. R. Ravindranath, P. Ravindran, P. Kyzivat. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8068) 8069 URN Namespace for IEEE. A. Thomas. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8069) 8070 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension. M. Short, Ed., S. Moore, P. Miller. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8070) 8071 NETCONF Call Home and RESTCONF Call Home. K. Watsen. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8071) 8072 YANG Patch Media Type. A. Bierman, M. Bjorklund, K. Watsen. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8072) 8073 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report. K. Moriarty, M. Ford. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8073) 8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) 8075 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP). A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8075) 8076 A Usage for Shared Resources in RELOAD (ShaRe). A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8076) 8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). L. Martini, Ed., G. Heron, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC4447, RFC6723) (Also STD0084) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8077) 8078 Managing DS Records from the Parent via CDS/CDNSKEY. O. Gudmundsson, P. Wouters. March 2017. (Format: TXT, HTML) (Updates RFC7344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8078) 8079 Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs). L. Miniero, S. Garcia Murillo, V. Pascual. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8079) 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC. O. Sury, R. Edmonds. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8080) 8081 The "font" Top-Level Media Type. C. Lilley. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8081) 8082 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs. S. Wenger, J. Lennox, B. Burman, M. Westerlund. March 2017. (Format: TXT, HTML) (Updates RFC5104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8082) 8083 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions. C. Perkins, V. Singh. March 2017. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8083) 8084 Network Transport Circuit Breakers. G. Fairhurst. March 2017. (Format: TXT, HTML) (Also BCP0208) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8084) 8085 UDP Usage Guidelines. L. Eggert, G. Fairhurst, G. Shepherd. March 2017. (Format: TXT, HTML) (Obsoletes RFC5405) (Also BCP0145) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8085) 8086 GRE-in-UDP Encapsulation. L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8086) 8087 The Benefits of Using Explicit Congestion Notification (ECN). G. Fairhurst, M. Welzl. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8087) 8088 How to Write an RTP Payload Format. M. Westerlund. May 2017. (Format: TXT, HTML) (Updates RFC2736) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8088) 8089 The "file" URI Scheme. M. Kerwin. February 2017. (Format: TXT, HTML) (Updates RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8089) 8090 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG). R. Housley. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8090) 8091 A Media Type Structured Syntax Suffix for JSON Text Sequences. E. Wilde. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8091) 8092 BGP Large Communities Attribute. J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8092) 8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243. J. Snijders. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8093) 8094 DNS over Datagram Transport Layer Security (DTLS). T. Reddy, D. Wing, P. Patil. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8094) 8095 Services Provided by IETF Transport Protocols and Congestion Control Mechanisms. G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8095) 8096 The IPv6-Specific MIB Modules Are Obsolete. B. Fenner. April 2017. (Format: TXT, HTML) (Obsoletes RFC2452, RFC2454, RFC2465, RFC2466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8096) 8097 BGP Prefix Origin Validation State Extended Community. P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8097) 8098 Message Disposition Notification. T. Hansen, Ed., A. Melnikov, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC3798) (Updates RFC2046, RFC3461) (Also STD0085) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8098) 8099 OSPF Topology-Transparent Zone. H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8099) 8100 Diffserv-Interconnection Classes and Practice. R. Geib, Ed., D. Black. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8100) 8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service. C. Holmberg, J. Axell. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8101) 8102 Remote-LFA Node Protection and Manageability. P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8102) 8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). R. Housley. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8103) 8104 Pseudowire (PW) Endpoint Fast Failure Protection. Y. Shen, R. Aggarwal, W. Henderickx, Y. Jiang. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8104) 8105 Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE). P. Mariager, J. Petersen, Ed., Z. Shelby, M. Van de Logt, D. Barthel. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8105) 8106 IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. March 2017. (Format: TXT, HTML) (Obsoletes RFC6106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8106) 8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition. J. Wold. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8107) 8108 Sending Multiple RTP Streams in a Single RTP Session. J. Lennox, M. Westerlund, Q. Wu, C. Perkins. March 2017. (Format: TXT, HTML) (Updates RFC3550, RFC4585) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8108) 8109 Initializing a DNS Resolver with Priming Queries. P. Koch, M. Larson, P. Hoffman. March 2017. (Format: TXT, HTML) (Also BCP0209) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8109) 8110 Opportunistic Wireless Encryption. D. Harkins, Ed., W. Kumari, Ed.. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8110) 8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT). V. Fuller, D. Lewis, V. Ermagan, A. Jain, A. Smirnov. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8111) 8112 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG). D. Farinacci, A. Jain, I. Kouvelas, D. Lewis. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8112) 8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations. M. Boucadair, C. Jacquenet. March 2017. (Format: TXT, HTML) (Updates RFC6830) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8113) 8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network. M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8114) 8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes. M. Boucadair, J. Qin, T. Tsou, X. Deng. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8115) 8116 Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2). T. Clausen, U. Herberg, J. Yi. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8116) 8117 Current Hostname Practice Considered Harmful. C. Huitema, D. Thaler, R. Winter. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8117) 8118 The application/pdf Media Type. M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey. March 2017. (Format: TXT, HTML) (Obsoletes RFC3778) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8118) 8119 SIP "cause" URI Parameter for Service Number Translation. M. Mohali, M. Barnes. March 2017. (Format: TXT, HTML) (Updates RFC4458) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8119) 8120 Mutual Authentication Protocol for HTTP. Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8120) 8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3). Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8121) 8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP). J. Lennox, C. Holmberg. March 2017. (Format: TXT, HTML) (Obsoletes RFC4572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8122) 8123 Requirements for Marking SIP Messages to be Logged. P. Dawes, C. Arunachalam. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8123) 8124 The Session Description Protocol (SDP) WebSocket Connection URI Attribute. R. Ravindranath, G. Salgueiro. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8124) 8125 Requirements for Password-Authenticated Key Agreement (PAKE) Schemes. J. Schmidt. April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8125) 8126 Guidelines for Writing an IANA Considerations Section in RFCs. M. Cotton, B. Leiba, T. Narten. June 2017. (Format: TXT, HTML) (Obsoletes RFC5226) (Also BCP0026) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8126) 8127 Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor. D. Patki, S. Gundavelli, J. Lee, Q. Fu, L. Bertz. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8127) 8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee. C. Morgan. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8128) 8129 Authentication Indicator in Kerberos Tickets. A. Jain, N. Kinder, N. McCallum. March 2017. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8129) 8130 RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec. V. Demjanenko, D. Satterlee. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8130) 8131 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing. X. Zhang, H. Zheng, Ed., R. Gandhi, Ed., Z. Ali, P. Brzozowski. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8131) 8132 PATCH and FETCH Methods for the Constrained Application Protocol (CoAP). P. van der Stok, C. Bormann, A. Sehgal. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8132) 8133 The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol. S. Smyshlyaev. Ed., E. Alekseev, I. Oshkin, V. Popov. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8133) 8134 Management Incident Lightweight Exchange (MILE) Implementation Report. C. Inacio, D. Miyamoto. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8134) 8135 Complex Addressing in IPv6. M. Danielson, M. Nilsson. 1 April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8135) 8136 Additional Transition Functionality for IPv6. B. Carpenter, R. Hinden. 1 April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8136) 8137 IEEE 802.15.4 Information Element for the IETF. T. Kivinen, P. Kinney. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8137) 8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header. P. Thubert, Ed., C. Bormann, L. Toutain, R. Cragie. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8138) 8139 Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders. D. Eastlake 3rd, Y. Li, M. Umair, A. Banerjee, F. Hu. June 2017. (Format: TXT, HTML) (Obsoletes RFC6439) (Updates RFC6325, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8139) 8140 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character. A. Farrel. 1 April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8140) 8141 Uniform Resource Names (URNs). P. Saint-Andre, J. Klensin. April 2017. (Format: TXT, HTML) (Obsoletes RFC2141, RFC3406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8141) 8142 GeoJSON Text Sequences. S. Gillies. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8142) 8143 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP). J. Elie. April 2017. (Format: TXT, HTML) (Updates RFC4642) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8143) 8144 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV). K. Murchison. April 2017. (Format: TXT, HTML) (Updates RFC7240) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8144) 8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC). D. Wessels, W. Kumari, P. Hoffman. April 2017. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8145) 8146 Adding Support for Salted Password Databases to EAP-pwd. D. Harkins. April 2017. (Format: TXT, HTML) (Updates RFC5931) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8146) 8147 Next-Generation Pan-European eCall. R. Gellens, H. Tschofenig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8147) 8148 Next-Generation Vehicle-Initiated Emergency Calls. R. Gellens, B. Rosen, H. Tschofenig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8148) 8149 RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs). T. Saad, Ed., R. Gandhi, Ed., Z. Ali, R. Venator, Y. Kamite. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8149) 8150 MPLS Transport Profile Linear Protection MIB. S. Kingston Smiler, M. Venkatesan, D. King, S. Aldrin, J. Ryoo. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8150) 8151 Use Cases for Data Center Network Virtualization Overlay Networks. L. Yong, L. Dunbar, M. Toy, A. Isaac, V. Manral. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8151) 8152 CBOR Object Signing and Encryption (COSE). J. Schaad. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8152) 8153 Digital Preservation Considerations for the RFC Series. H. Flanagan. April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8153) 8154 Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout. C. Hellwig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8154) 8155 Traversal Using Relays around NAT (TURN) Server Auto Discovery. P. Patil, T. Reddy, D. Wing. April 2017. (Format: TXT, HTML) (Updates RFC5766) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8155) 8156 DHCPv6 Failover Protocol. T. Mrugalski, K. Kinnear. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8156) 8157 Huawei's GRE Tunnel Bonding Protocol. N. Leymann, C. Heidemann, M. Zhang, B. Sarikaya, M. Cullen. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8157) 8158 IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events. S. Sivakumar, R. Penno. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8158) 8159 Keyed IPv6 Tunnel. M. Konstantynowicz, Ed., G. Heron, Ed., R. Schatzmayr, W. Henderickx. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8159) 8160 IUTF8 Terminal Mode in Secure Shell (SSH). S. Tatham, D. Tucker. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8160) 8161 Benchmarking the Neighbor Discovery Protocol. W. Cerveny, R. Bonica, R. Thomas. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8161) 8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME. P. Hoffman, J. Schlyter. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8162) 8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks. K. Lynn, Ed., J. Martocci, C. Neilson, S. Donaldson. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8163) 8164 Opportunistic Security for HTTP/2. M. Nottingham, M. Thomson. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8164) 8165 Design Considerations for Metadata Insertion. T. Hardie. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8165) 8166 Remote Direct Memory Access Transport for Remote Procedure Call Version 1. C. Lever, Ed., W. Simpson, T. Talpey. June 2017. (Format: TXT, HTML) (Obsoletes RFC5666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8166) 8167 Bidirectional Remote Procedure Call on RPC-over-RDMA Transports. C. Lever. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8167) 8168 DHCPv6 Prefix-Length Hint Issues. T. Li, C. Liu, Y. Cui. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8168) 8169 Residence Time Measurement in MPLS Networks. G. Mirsky, S. Ruffini, E. Gray, J. Drake, S. Bryant, A. Vainshtein. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8169) 8170 Planning for Protocol Adoption and Subsequent Transitions. D. Thaler, Ed.. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8170) 8171 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms. D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8171) 8172 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure. A. Morton. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8172) 8173 Precision Time Protocol Version 2 (PTPv2) Management Information Base. V. Shankarkumar, L. Montini, T. Frost, G. Dowd. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8173) 8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. May 2017. (Format: TXT, HTML) (Updates RFC2119) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8174) 8175 Dynamic Link Exchange Protocol (DLEP). S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8175) 8176 Authentication Method Reference Values. M. Jones, P. Hunt, A. Nadalin. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8176) 8177 YANG Data Model for Key Chains. A. Lindem, Ed., Y. Qu, D. Yeung, I. Chen, J. Zhang. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8177) 8178 Rules for NFSv4 Extensions and Minor Versions. D. Noveck. July 2017. (Format: TXT, HTML) (Updates RFC5661, RFC7862) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8178) 8179 Intellectual Property Rights in IETF Technology. S. Bradner, J. Contreras. May 2017. (Format: TXT, HTML) (Obsoletes RFC3979, RFC4879) (Updates RFC2026) (Also BCP0079) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8179) 8180 Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration. X. Vilajosana, Ed., K. Pister, T. Watteyne. May 2017. (Format: TXT, HTML) (Also BCP0210) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8180) 8181 A Publication Protocol for the Resource Public Key Infrastructure (RPKI). S. Weiler, A. Sonalker, R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8181) 8182 The RPKI Repository Delta Protocol (RRDP). T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8182) 8183 An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services. R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8183) 8184 Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires. W. Cheng, L. Wang, H. Li, S. Davari, J. Dong. June 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8184) 8185 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection. W. Cheng, L. Wang, H. Li, J. Dong, A. D'Alessandro. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8185) 8186 Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP). G. Mirsky, I. Meilik. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8186) 8187 Indicating Character Encoding and Language for HTTP Header Field Parameters. J. Reschke. September 2017. (Format: TXT, HTML) (Obsoletes RFC5987) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8187) 8188 Encrypted Content-Encoding for HTTP. M. Thomson. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8188) 8189 Multi-Cost Application-Layer Traffic Optimization (ALTO). S. Randriamasy, W. Roome, N. Schwan. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8189) 8190 Updates to the Special-Purpose IP Address Registries. R. Bonica, M. Cotton, B. Haberman, L. Vegoda. June 2017. (Format: TXT, HTML) (Updates RFC6890) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8190) 8191 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6). Z. Yan, J. Lee, X. Lee. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8191) 8192 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases. S. Hares, D. Lopez, M. Zarny, C. Jacquenet, R. Kumar, J. Jeong. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8192) 8193 Information Model for Large-Scale Measurement Platforms (LMAPs). T. Burbridge, P. Eardley, M. Bagnulo, J. Schoenwaelder. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8193) 8194 A YANG Data Model for LMAP Measurement Agents. J. Schoenwaelder, V. Bajpai. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8194) 8195 Use of BGP Large Communities. J. Snijders, J. Heasley, M. Schmidt. June 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8195) 8196 IS-IS Autoconfiguration. B. Liu, Ed., L. Ginsberg, B. Decraene, I. Farrer, M. Abrahamsson. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8196) 8197 A SIP Response Code for Unwanted Calls. H. Schulzrinne. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8197) 8198 Aggressive Use of DNSSEC-Validated Cache. K. Fujiwara, A. Kato, W. Kumari. July 2017. (Format: TXT, HTML) (Updates RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8198) 8199 YANG Module Classification. D. Bogdanovic, B. Claise, C. Moberg. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8199) 8200 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. July 2017. (Format: TXT, HTML) (Obsoletes RFC2460) (Also STD0086) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8200) 8201 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul, R. Hinden, Ed.. July 2017. (Format: TXT, HTML) (Obsoletes RFC1981) (Also STD0087) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8201) 8202 IS-IS Multi-Instance. L. Ginsberg, S. Previdi, W. Henderickx. June 2017. (Format: TXT, HTML) (Obsoletes RFC6822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8202) 8203 BGP Administrative Shutdown Communication. J. Snijders, J. Heitz, J. Scudder. July 2017. (Format: TXT, HTML) (Updates RFC4486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8203) 8204 Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV). M. Tahhan, B. O'Mahony, A. Morton. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8204) 8205 BGPsec Protocol Specification. M. Lepinski, Ed., K. Sriram, Ed.. September 2017. (Format: TXT, HTML) (Updated by RFC8206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8205) 8206 BGPsec Considerations for Autonomous System (AS) Migration. W. George, S. Murphy. September 2017. (Format: TXT, HTML) (Updates RFC8205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8206) 8207 BGPsec Operational Considerations. R. Bush. September 2017. (Format: TXT, HTML) (Also BCP0211) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8207) 8208 BGPsec Algorithms, Key Formats, and Signature Formats. S. Turner, O. Borchert. September 2017. (Format: TXT, HTML) (Obsoleted by RFC8608) (Updates RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8208) 8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests. M. Reynolds, S. Turner, S. Kent. September 2017. (Format: TXT, HTML) (Updates RFC6487) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8209) 8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1. R. Bush, R. Austein. September 2017. (Format: TXT, HTML) (Updates RFC6810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8210) 8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI). S. Kent, D. Ma. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8211) 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies. J. Mauch, J. Snijders, G. Hankins. July 2017. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8212) 8213 Security of Messages Exchanged between Servers and Relay Agents. B. Volz, Y. Pal. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8213) 8214 Virtual Private Wire Service Support in Ethernet VPN. S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8214) 8215 Local-Use IPv4/IPv6 Translation Prefix. T. Anderson. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8215) 8216 HTTP Live Streaming. R. Pantos, Ed., W. May. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8216) 8217 Clarifications for When to Use the name-addr Production in SIP Messages. R. Sparks. August 2017. (Format: TXT, HTML) (Updates RFC3261, RFC3325, RFC3515, RFC3892, RFC4508, RFC5002, RFC5318, RFC5360, RFC5502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8217) 8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2). J. Yi, B. Parrein. August 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8218) 8219 Benchmarking Methodology for IPv6 Transition Technologies. M. Georgescu, L. Pislaru, G. Lencse. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8219) 8220 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS). O. Dornon, J. Kotalwar, V. Hemige, R. Qiu, Z. Zhang. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8220) 8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH). P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen. October 2017. (Format: TXT, HTML) (Obsoletes RFC7321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8221) 8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery. A. Sullivan. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8222) 8223 Application-Aware Targeted LDP. S. Esale, R. Torvi, L. Jalil, U. Chunduri, K. Raza. August 2017. (Format: TXT, HTML) (Updates RFC7473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8223) 8224 Authenticated Identity Management in the Session Initiation Protocol (SIP). J. Peterson, C. Jennings, E. Rescorla, C. Wendt. February 2018. (Format: TXT, HTML) (Obsoletes RFC4474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8224) 8225 PASSporT: Personal Assertion Token. C. Wendt, J. Peterson. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8225) 8226 Secure Telephone Identity Credentials: Certificates. J. Peterson, S. Turner. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8226) 8227 MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology. W. Cheng, L. Wang, H. Li, H. van Helvoort, J. Dong. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8227) 8228 Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels. A. Freytag. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8228) 8229 TCP Encapsulation of IKE and IPsec Packets. T. Pauly, S. Touati, R. Mantha. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8229) 8230 Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages. M. Jones. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8230) 8231 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE. E. Crabbe, I. Minei, J. Medved, R. Varga. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8231) 8232 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE. E. Crabbe, I. Minei, J. Medved, R. Varga, X. Zhang, D. Dhody. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8232) 8233 Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs). D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8233) 8234 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode. J. Ryoo, T. Cheung, H. van Helvoort, I. Busi, G. Wen. August 2017. (Format: TXT, HTML) (Updates RFC7271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8234) 8235 Schnorr Non-interactive Zero-Knowledge Proof. F. Hao, Ed.. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8235) 8236 J-PAKE: Password-Authenticated Key Exchange by Juggling. F. Hao, Ed.. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8236) 8237 MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs. L. Martini, G. Swallow, E. Bellagamba. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8237) 8238 Data Center Benchmarking Terminology. L. Avramov, J. Rapp. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8238) 8239 Data Center Benchmarking Methodology. L. Avramov, J. Rapp. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8239) 8240 Report from the Internet of Things Software Update (IoTSU) Workshop 2016. H. Tschofenig, S. Farrell. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8240) 8241 Interface to the Routing System (I2RS) Security-Related Requirements. S. Hares, D. Migault, J. Halpern. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8241) 8242 Interface to the Routing System (I2RS) Ephemeral State Requirements. J. Haas, S. Hares. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8242) 8243 Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL). R. Perlman, D. Eastlake 3rd, M. Zhang, A. Ghanwani, H. Zhai. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8243) 8244 Special-Use Domain Names Problem Statement. T. Lemon, R. Droms, W. Kumari. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8244) 8245 Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444. T. Clausen, C. Dearlove, U. Herberg, H. Rogge. October 2017. (Format: TXT, HTML) (Updates RFC5444) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8245) 8246 HTTP Immutable Responses. P. McManus. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8246) 8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Nir, T. Kivinen, P. Wouters, D. Migault. September 2017. (Format: TXT, HTML) (Obsoletes RFC4307) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8247) 8248 Security Automation and Continuous Monitoring (SACM) Requirements. N. Cam-Winget, L. Lorenzin. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8248) 8249 Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation. M. Zhang, X. Zhang, D. Eastlake 3rd, R. Perlman, S. Chatterjee. September 2017. (Format: TXT, HTML) (Updates RFC6325, RFC7177, RFC7780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8249) 8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option. N. Elkins, R. Hamilton, M. Ackermann. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8250) 8251 Updates to the Opus Audio Codec. JM. Valin, K. Vos. October 2017. (Format: TXT, HTML) (Updates RFC6716) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8251) 8252 OAuth 2.0 for Native Apps. W. Denniss, J. Bradley. October 2017. (Format: TXT, HTML) (Updates RFC6749) (Also BCP0212) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8252) 8253 PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP). D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody. October 2017. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8253) 8254 Uniform Resource Name (URN) Namespace Registration Transition. J. Klensin, J. Hakala. October 2017. (Format: TXT, HTML) (Obsoletes RFC3044, RFC3187) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8254) 8255 Multiple Language Content Type. N. Tomkinson, N. Borenstein. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8255) 8256 Requirements for Hitless MPLS Path Segment Monitoring. A. D'Alessandro, L. Andersson, S. Ueno, K. Arai, Y. Koike. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8256) 8257 Data Center TCP (DCTCP): TCP Congestion Control for Data Centers. S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8257) 8258 Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI). D. Ceccarelli, L. Berger. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8258) 8259 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. December 2017. (Format: TXT, HTML) (Obsoletes RFC7159) (Also STD0090) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8259) 8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol. R. Stewart, M. Tuexen, S. Loreto, R. Seggelmann. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8260) 8261 Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets. M. Tuexen, R. Stewart, R. Jesup, S. Loreto. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8261) 8262 Content-ID Header Field in the Session Initiation Protocol (SIP). C. Holmberg, I. Sedlacek. October 2017. (Format: TXT, HTML) (Updates RFC5621, RFC5368, RFC6442) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8262) 8263 Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message. B. Weis, U. Mangla, T. Karl, N. Maheshwari. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8263) 8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols. P. Saint-Andre, M. Blanchet. October 2017. (Format: TXT, HTML) (Obsoletes RFC7564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8264) 8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords. P. Saint-Andre, A. Melnikov. October 2017. (Format: TXT, HTML) (Obsoletes RFC7613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8265) 8266 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames. P. Saint-Andre. October 2017. (Format: TXT, HTML) (Obsoletes RFC7700) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8266) 8267 Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1. C. Lever. October 2017. (Format: TXT, HTML) (Obsoletes RFC5667) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8267) 8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH). M. Baushke. December 2017. (Format: TXT, HTML) (Updates RFC4250, RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8268) 8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP). W. Kim, J. Lee, J. Park, D. Kwon, D. Kim. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8269) 8270 Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits. L. Velvindron, M. Baushke. December 2017. (Format: TXT, HTML) (Updates RFC4419) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8270) 8271 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs). M. Taillon, T. Saad, Ed., R. Gandhi, Ed., Z. Ali, M. Bhatia. October 2017. (Format: TXT, HTML) (Updates RFC4090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8271) 8272 TinyIPFIX for Smart Meters in Constrained Networks. C. Schmitt, B. Stiller, B. Trammell. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8272) 8273 Unique IPv6 Prefix per Host. J. Brzozowski, G. Van de Velde. December 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8273) 8274 Incident Object Description Exchange Format Usage Guidance. P. Kampanakis, M. Suzuki. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8274) 8275 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask. J. Fields, A. Gruenbacher. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8275) 8276 File System Extended Attributes in NFSv4. M. Naik, M. Eshel. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8276) 8277 Using BGP to Bind MPLS Labels to Address Prefixes. E. Rosen. October 2017. (Format: TXT, HTML) (Obsoletes RFC3107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8277) 8278 Mobile Access Gateway (MAG) Multipath Options. P. Seite, A. Yegin, S. Gundavelli. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8278) 8279 Multicast Using Bit Index Explicit Replication (BIER). IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, T. Przygienda, S. Aldrin. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8279) 8280 Research into Human Rights Protocol Considerations. N. ten Oever, C. Cath. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8280) 8281 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model. E. Crabbe, I. Minei, S. Sivabalan, R. Varga. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8281) 8282 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering. E. Oki, T. Takeda, A. Farrel, F. Zhang. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8282) 8283 An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control. A. Farrel, Ed., Q. Zhao, Ed., Z. Li, C. Zhou. December 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8283) 8284 Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages. S. Kille. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8284) 8285 A General Mechanism for RTP Header Extensions. D. Singer, H. Desineni, R. Even, Ed.. October 2017. (Format: TXT, HTML) (Obsoletes RFC5285) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8285) 8286 RTP/RTCP Extension for RTP Splicing Notification. J. Xia, R. Even, R. Huang, L. Deng. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8286) 8287 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes. N. Kumar, Ed., C. Pignataro, Ed., G. Swallow, N. Akiya, S. Kini, M. Chen. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8287) 8288 Web Linking. M. Nottingham. October 2017. (Format: TXT, HTML) (Obsoletes RFC5988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8288) 8289 Controlled Delay Active Queue Management. K. Nichols, V. Jacobson, A. McGregor, Ed., J. Iyengar, Ed.. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8289) 8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm. T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8290) 8291 Message Encryption for Web Push. M. Thomson. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8291) 8292 Voluntary Application Server Identification (VAPID) for Web Push. M. Thomson, P. Beverloo. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8292) 8293 A Framework for Multicast in Network Virtualization over Layer 3. A. Ghanwani, L. Dunbar, M. McBride, V. Bannai, R. Krishnan. January 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8293) 8294 Common YANG Data Types for the Routing Area. X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8294) 8295 EST (Enrollment over Secure Transport) Extensions. S. Turner. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8295) 8296 Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks. IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, J. Tantsura, S. Aldrin, I. Meilik. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8296) 8297 An HTTP Status Code for Indicating Hints. K. Oku. December 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8297) 8298 Self-Clocked Rate Adaptation for Multimedia. I. Johansson, Z. Sarker. December 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8298) 8299 YANG Data Model for L3VPN Service Delivery. Q. Wu, Ed., S. Litkowski, L. Tomotaki, K. Ogaki. January 2018. (Format: TXT, HTML) (Obsoletes RFC8049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8299) 8300 Network Service Header (NSH). P. Quinn, Ed., U. Elzur, Ed., C. Pignataro, Ed.. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8300) 8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM). S. Kitterman. January 2018. (Format: TXT, HTML) (Updates RFC6376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8301) 8302 Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization. Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8302) 8303 On the Usage of Transport Features Provided by IETF Transport Protocols. M. Welzl, M. Tuexen, N. Khademi. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8303) 8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite). G. Fairhurst, T. Jones. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8304) 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency. D. Schinazi, T. Pauly. December 2017. (Format: TXT, HTML) (Obsoletes RFC6555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8305) 8306 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths. Q. Zhao, D. Dhody, Ed., R. Palleti, D. King. November 2017. (Format: TXT, HTML) (Obsoletes RFC6006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8306) 8307 Well-Known URIs for the WebSocket Protocol. C. Bormann. January 2018. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8307) 8308 Extension Negotiation in the Secure Shell (SSH) Protocol. D. Bider. March 2018. (Format: TXT, HTML) (Updates RFC4251, RFC4252, RFC4253, RFC4254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8308) 8309 Service Models Explained. Q. Wu, W. Liu, A. Farrel. January 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8309) 8310 Usage Profiles for DNS over TLS and DNS over DTLS. S. Dickinson, D. Gillmor, T. Reddy. March 2018. (Format: TXT, HTML) (Updates RFC7858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8310) 8311 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation. D. Black. January 2018. (Format: TXT, HTML) (Updates RFC3168, RFC4341, RFC4342, RFC5622, RFC6679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8311) 8312 CUBIC for Fast Long-Distance Networks. I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8312) 8313 Use of Multicast across Inter-domain Peering Points. P. Tarapore, Ed., R. Sayko, G. Shepherd, T. Eckert, Ed., R. Krishnan. January 2018. (Format: TXT, HTML) (Also BCP0213) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8313) 8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. K. Moore, C. Newman. January 2018. (Format: TXT, HTML) (Updates RFC1939, RFC2595, RFC3501, RFC5068, RFC6186, RFC6409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8314) 8315 Cancel-Locks in Netnews Articles. M. Baeuerle. February 2018. (Format: TXT, HTML) (Updates RFC5537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8315) 8316 Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations. J. Nobre, L. Granville, A. Clemm, A. Gonzalez Prieto. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8316) 8317 Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN). A. Sajassi, Ed., S. Salam, J. Drake, J. Uttaro, S. Boutros, J. Rabadan. January 2018. (Format: TXT, HTML) (Updates RFC7385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8317) 8318 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee. S. Dawkins. January 2018. (Format: TXT, HTML) (Updates RFC7437) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8318) 8319 Support for Adjustable Maximum Router Lifetimes per Link. S. Krishnan, J. Korhonen, S. Chakrabarti, E. Nordmark, A. Yourtchenko. February 2018. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8319) 8320 LDP Extensions to Support Maximally Redundant Trees. A. Atlas, K. Tiruveedhula, C. Bowers, J. Tantsura, IJ. Wijnands. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8320) 8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring. G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8321) 8322 Resource-Oriented Lightweight Information Exchange (ROLIE). J. Field, S. Banghart, D. Waltermire. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8322) 8323 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed.. February 2018. (Format: TXT, HTML) (Updates RFC7641, RFC7959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8323) 8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?. J. Klensin. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8324) 8325 Mapping Diffserv to IEEE 802.11. T. Szigeti, J. Henry, F. Baker. February 2018. (Format: TXT, HTML) (Updated by RFC8622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8325) 8326 Graceful BGP Session Shutdown. P. Francois, Ed., B. Decraene, Ed., C. Pelsser, K. Patel, C. Filsfils. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8326) 8327 Mitigating the Negative Impact of Maintenance through BGP Session Culling. W. Hargrave, M. Griswold, J. Snijders, N. Hilliard. March 2018. (Format: TXT, HTML) (Also BCP0214) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8327) 8328 Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis, M. Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8328) 8329 Framework for Interface to Network Security Functions. D. Lopez, E. Lopez, L. Dunbar, J. Strassner, R. Kumar. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8329) 8330 OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth. H. Long, M. Ye, G. Mirsky, A. D'Alessandro, H. Shah. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8330) 8331 RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data. T. Edwards. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8331) 8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol. D. Bider. March 2018. (Format: TXT, HTML) (Updates RFC4252, RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8332) 8333 Micro-loop Prevention by Introducing a Local Convergence Delay. S. Litkowski, B. Decraene, C. Filsfils, P. Francois. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8333) 8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP). J. Gould, W. Tan, G. Brown. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8334) 8335 PROBE: A Utility for Probing Interfaces. R. Bonica, R. Thomas, J. Linkova, C. Lenart, M. Boucadair. February 2018. (Format: TXT, HTML) (Updates RFC4884) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8335) 8336 The ORIGIN HTTP/2 Frame. M. Nottingham, E. Nygren. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8336) 8337 Model-Based Metrics for Bulk Transport Capacity. M. Mathis, A. Morton. March 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8337) 8338 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP. S. Boutros, Ed., S. Sivabalan, Ed.. March 2018. (Format: TXT, HTML) (Updates RFC7385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8338) 8339 Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms. P. Jain, Ed., S. Boutros, S. Aldrin. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8339) 8340 YANG Tree Diagrams. M. Bjorklund, L. Berger, Ed.. March 2018. (Format: TXT, HTML) (Also BCP0215) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8340) 8341 Network Configuration Access Control Model. A. Bierman, M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC6536) (Also STD0091) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8341) 8342 Network Management Datastore Architecture (NMDA). M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2018. (Format: TXT, HTML) (Updates RFC7950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8342) 8343 A YANG Data Model for Interface Management. M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC7223) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8343) 8344 A YANG Data Model for IP Management. M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC7277) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8344) 8345 A YANG Data Model for Network Topologies. A. Clemm, J. Medved, R. Varga, N. Bahadur, H. Ananthakrishnan, X. Liu. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8345) 8346 A YANG Data Model for Layer 3 Topologies. A. Clemm, J. Medved, R. Varga, X. Liu, H. Ananthakrishnan, N. Bahadur. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8346) 8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP). X. Liu, Ed., A. Kyparlis, R. Parikh, A. Lindem, M. Zhang. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8347) 8348 A YANG Data Model for Hardware Management. A. Bierman, M. Bjorklund, J. Dong, D. Romascanu. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8348) 8349 A YANG Data Model for Routing Management (NMDA Version). L. Lhotka, A. Lindem, Y. Qu. March 2018. (Format: TXT, HTML) (Obsoletes RFC8022) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8349) 8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP). R. Zhang, R. Pazhyannur, S. Gundavelli, Z. Cao, H. Deng, Z. Du. April 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8350) 8351 The PKCS #8 EncryptedPrivateKeyInfo Media Type. S. Leonard. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8351) 8352 Energy-Efficient Features of Internet of Things Protocols. C. Gomez, M. Kovatsch, H. Tian, Z. Cao, Ed.. April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8352) 8353 Generic Security Service API Version 2: Java Bindings Update. M. Upadhyay, S. Malkani, W. Wang. May 2018. (Format: TXT, HTML) (Obsoletes RFC5653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8353) 8354 Use Cases for IPv6 Source Packet Routing in Networking (SPRING). J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, Ed., M. Townsley. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8354) 8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks. C. Filsfils, Ed., S. Previdi, Ed., B. Decraene, R. Shakir. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8355) 8356 Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP). D. Dhody, D. King, A. Farrel. March 2018. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8356) 8357 Generalized UDP Source Port for DHCP Relay. N. Shen, E. Chen. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8357) 8358 Update to Digital Signatures on Internet-Draft Documents. R. Housley. March 2018. (Format: TXT, HTML) (Updates RFC5485) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8358) 8359 Network-Assigned Upstream Label. X. Zhang, Ed., V. Beeram, Ed., I. Bryskin, D. Ceccarelli, O. Gonzalez de Dios. March 2018. (Format: TXT, HTML) (Updates RFC3471, RFC3473, RFC6205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8359) 8360 Resource Public Key Infrastructure (RPKI) Validation Reconsidered. G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw. April 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8360) 8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic. W. Hao, Y. Li, M. Durrani, S. Gupta, A. Qu. April 2018. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8361) 8362 OSPFv3 Link State Advertisement (LSA) Extensibility. A. Lindem, A. Roy, D. Goethals, V. Reddy Vallem, F. Baker. April 2018. (Format: TXT, HTML) (Updates RFC5340, RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8362) 8363 GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. Ceccarelli. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8363) 8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD). IJ. Wijnands, S. Venaas, M. Brig, A. Jonasson. March 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8364) 8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN). A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, J. Uttaro, W. Henderickx. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8365) 8366 A Voucher Artifact for Bootstrapping Protocols. K. Watsen, M. Richardson, M. Pritikin, T. Eckert. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8366) 8367 Wrongful Termination of Internet Protocol (IP) Packets. T. Mizrahi, J. Yallouz. 1 April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8367) 8368 Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM). T. Eckert, Ed., M. Behringer. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8368) 8369 Internationalizing IPv6 Using 128-Bit Unicode. H. Kaplan. 1 April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8369) 8370 Techniques to Improve the Scalability of RSVP-TE Deployments. V. Beeram, Ed., I. Minei, R. Shakir, D. Pacella, T. Saad. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8370) 8371 Mobile Node Identifier Types for MIPv6. C. Perkins, V. Devarapalli. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8371) 8372 MPLS Flow Identification Considerations. S. Bryant, C. Pignataro, M. Chen, Z. Li, G. Mirsky. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8372) 8373 Negotiating Human Language in Real-Time Communications. R. Gellens. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8373) 8374 BGPsec Design Choices and Summary of Supporting Discussions. K. Sriram, Ed.. April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8374) 8375 Special-Use Domain 'home.arpa.'. P. Pfister, T. Lemon. May 2018. (Format: TXT, HTML) (Updates RFC7788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8375) 8376 Low-Power Wide Area Network (LPWAN) Overview. S. Farrell, Ed.. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8376) 8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology. D. Eastlake 3rd, M. Zhang, A. Banerjee. July 2018. (Format: TXT, HTML) (Updates RFC6325, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8377) 8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast. V. Moreno, D. Farinacci. May 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8378) 8379 OSPF Graceful Link Shutdown. S. Hegde, P. Sarkar, H. Gredler, M. Nanduri, L. Jalil. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8379) 8380 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation. L. Dunbar, D. Eastlake 3rd, R. Perlman. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8380) 8381 Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol. D. Eastlake 3rd, Y. Li, W. Hao, A. Banerjee. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8381) 8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth. June 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8382) 8383 Transparent Interconnection of Lots of Links (TRILL): Address Flush Message. W. Hao, D. Eastlake 3rd, Y. Li, M. Umair. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8383) 8384 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes. R. Perlman, F. Hu, D. Eastlake 3rd, T. Liao. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8384) 8385 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS. M. Umair, S. Kingston Smiler, D. Eastlake 3rd, L. Yong. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8385) 8386 Privacy Considerations for Protocols Relying on IP Broadcast or Multicast. R. Winter, M. Faath, F. Weisshaar. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8386) 8387 Practical Considerations and Implementation Experiences in Securing Smart Object Networks. M. Sethi, J. Arkko, A. Keranen, H. Back. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8387) 8388 Usage and Applicability of BGP MPLS-Based Ethernet VPN. J. Rabadan, Ed., S. Palislamovic, W. Henderickx, A. Sajassi, J. Uttaro. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8388) 8389 Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E). Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8389) 8390 RSVP-TE Path Diversity Using Exclude Route. Z. Ali, Ed., G. Swallow, Ed., F. Zhang, Ed., D. Beller, Ed.. July 2018. (Format: TXT, HTML) (Updates RFC4874) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8390) 8391 XMSS: eXtended Merkle Signature Scheme. A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8391) 8392 CBOR Web Token (CWT). M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8392) 8393 Operating the Network Service Header (NSH) with Next Protocol "None". A. Farrel, J. Drake. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8393) 8394 Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements. Y. Li, D. Eastlake 3rd, L. Kreeger, T. Narten, D. Black. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8394) 8395 Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels. K. Patel, S. Boutros, J. Liste, B. Wen, J. Rabadan. June 2018. (Format: TXT, HTML) (Updates RFC4761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8395) 8396 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework. J. Peterson, T. McGarry. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8396) 8397 Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames. M. Zhang, D. Eastlake 3rd, R. Perlman, H. Zhai, D. Liu. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8397) 8398 Internationalized Email Addresses in X.509 Certificates. A. Melnikov, Ed., W. Chuang, Ed.. May 2018. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8398) 8399 Internationalization Updates to RFC 5280. R. Housley. May 2018. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8399) 8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection. H. Chen, A. Liu, T. Saad, F. Xu, L. Huang. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8400) 8401 Bit Index Explicit Replication (BIER) Support via IS-IS. L. Ginsberg, Ed., T. Przygienda, S. Aldrin, Z. Zhang. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8401) 8402 Segment Routing Architecture. C. Filsfils, Ed., S. Previdi, Ed., L. Ginsberg, B. Decraene, S. Litkowski, R. Shakir. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8402) 8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System. R. Geib, Ed., C. Filsfils, C. Pignataro, Ed., N. Kumar. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8403) 8404 Effects of Pervasive Encryption on Operators. K. Moriarty, Ed., A. Morton, Ed.. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8404) 8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs. B. Decraene, S. Litkowski, H. Gredler, A. Lindem, P. Francois, C. Bowers. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8405) 8406 Taxonomy of Coding Techniques for Efficient Network Communications. B. Adamson, C. Adjih, J. Bilbao, V. Firoiu, F. Fitzek, S. Ghanem, E. Lochin, A. Masucci, M-J. Montpetit, M. Pedersen, G. Peralta, V. Roca, Ed., P. Saxena, S. Sivakumar. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8406) 8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models. A. Bierman. October 2018. (Format: TXT, HTML) (Obsoletes RFC6087) (Also BCP0216) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8407) 8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages. S. Sivabalan, J. Tantsura, I. Minei, R. Varga, J. Hardwick. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8408) 8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types. I. Young, Ed., L. Johansson, S. Cantor. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8409) 8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure. S. Josefsson, J. Schaad. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8410) 8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range. J. Schaad, R. Andrews. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8411) 8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC. C. Schmidt, D. Haynes, C. Coffin, D. Waltermire, J. Fitzgerald-McKay. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8412) 8413 Framework for Scheduled Use of Resources. Y. Zhuang, Q. Wu, H. Chen, A. Farrel. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8413) 8414 OAuth 2.0 Authorization Server Metadata. M. Jones, N. Sakimura, J. Bradley. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8414) 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters. November 2018. (Format: TXT, HTML) (Obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, RFC7283, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8415) 8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM). D. Ma, D. Mandelberg, T. Bruijnzeels. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8416) 8417 Security Event Token (SET). P. Hunt, Ed., M. Jones, W. Denniss, M. Ansari. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8417) 8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS). R. Housley. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8418) 8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS). R. Housley. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8419) 8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Nir. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8420) 8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE). P. Martinsen, T. Reddy, P. Patil. July 2018. (Format: TXT, HTML) (Also BCP0217) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8421) 8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier. Y. Nir, S. Josefsson, M. Pegourie-Gonnard. August 2018. (Format: TXT, HTML) (Obsoletes RFC4492) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8422) 8423 Reclassification of Suite B Documents to Historic Status. R. Housley, L. Zieglar. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8423) 8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection. H. Chen, Ed., R. Torvi, Ed.. August 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8424) 8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags. O. Troan. July 2018. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8425) 8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence. H. Sitaraman, Ed., V. Beeram, I. Minei, S. Sivabalan. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8426) 8427 Representing DNS Messages in JSON. P. Hoffman. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8427) 8428 Sensor Measurement Lists (SenML). C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8428) 8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos. B. Kaduk, M. Short. October 2018. (Format: TXT, HTML) (Updates RFC3961, RFC4120) (Also BCP0218) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8429) 8430 RIB Information Model. N. Bahadur, Ed., S. Kini, Ed., J. Medved. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8430) 8431 A YANG Data Model for the Routing Information Base (RIB). L. Wang, M. Chen, A. Dass, H. Ananthakrishnan, S. Kini, N. Bahadur. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8431) 8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters. J. Ahlberg, Ed., M. Ye, Ed., X. Li, LM. Contreras, CJ. Bernardos. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8432) 8433 A Simpler Method for Resolving Alert-Info URNs. D. Worley. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8433) 8434 Requirements for Parallel NFS (pNFS) Layout Types. T. Haynes. August 2018. (Format: TXT, HTML) (Updates RFC5661) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8434) 8435 Parallel NFS (pNFS) Flexible File Layout. B. Halevy, T. Haynes. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8435) 8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry. G. Fairhurst. August 2018. (Format: TXT, HTML) (Updates RFC2474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8436) 8437 IMAP UNAUTHENTICATE Extension for Connection Reuse. C. Newman. August 2018. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8437) 8438 IMAP Extension for STATUS=SIZE. S. Bosch. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8438) 8439 ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley. June 2018. (Format: TXT, HTML) (Obsoletes RFC7539) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8439) 8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST. K. Murchison, B. Gondwana. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8440) 8441 Bootstrapping WebSockets with HTTP/2. P. McManus. September 2018. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8441) 8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2. J. Mattsson, D. Migault. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8442) 8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization. R. Singh, M. Dolly, S. Das, A. Nguyen. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8443) 8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER). P. Psenak, Ed., N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, S. Aldrin. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8444) 8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. A. Keranen, C. Holmberg, J. Rosenberg. July 2018. (Format: TXT, HTML) (Obsoletes RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8445) 8446 The Transport Layer Security (TLS) Protocol Version 1.3. E. Rescorla. August 2018. (Format: TXT, HTML) (Obsoletes RFC5077, RFC5246, RFC6961) (Updates RFC5705, RFC6066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8446) 8447 IANA Registry Updates for TLS and DTLS. J. Salowey, S. Turner. August 2018. (Format: TXT, HTML) (Updates RFC3749, RFC4680, RFC5077, RFC5246, RFC5705, RFC5878, RFC6520, RFC7301) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8447) 8448 Example Handshake Traces for TLS 1.3. M. Thomson. January 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8448) 8449 Record Size Limit Extension for TLS. M. Thomson. August 2018. (Format: TXT, HTML) (Updates RFC6066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8449) 8450 RTP Payload Format for VC-2 High Quality (HQ) Profile. J. Weaver. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8450) 8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API. V. Singh, R. Huang, R. Even, D. Romascanu, L. Deng. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8451) 8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption. S. Gueron, A. Langley, Y. Lindell. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8452) 8453 Framework for Abstraction and Control of TE Networks (ACTN). D. Ceccarelli, Ed., Y. Lee, Ed.. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8453) 8454 Information Model for Abstraction and Control of TE Networks (ACTN). Y. Lee, S. Belotti, D. Dhody, D. Ceccarelli, B. Yoon. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8454) 8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance. V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8455) 8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance. V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8456) 8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute. B. Leiba, Ed.. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8457) 8458 Using National Bibliography Numbers as Uniform Resource Names. J. Hakala. October 2018. (Format: TXT, HTML) (Obsoletes RFC3188) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8458) 8459 Hierarchical Service Function Chaining (hSFC). D. Dolson, S. Homma, D. Lopez, M. Boucadair. September 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8459) 8460 SMTP TLS Reporting. D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones, M. Risher. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8460) 8461 SMTP MTA Strict Transport Security (MTA-STS). D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, J. Jones. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8461) 8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW). N. Rooney, S. Dawkins, Ed.. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8462) 8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM). J. Levine. September 2018. (Format: TXT, HTML) (Updates RFC6376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8463) 8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID). R. Atarius. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8464) 8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID. R. Atarius, Ed.. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8465) 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery. B. Wen, G. Fioccola, Ed., C. Xie, L. Jalil. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8466) 8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0)). A. Mayrhofer. October 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8467) 8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework. A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde. November 2018. (Format: TXT, HTML) (Updates RFC2330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8468) 8469 Recommendation to Use the Ethernet Control Word. S. Bryant, A. Malis, I. Bagdonas. November 2018. (Format: TXT, HTML) (Updates RFC4448) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8469) 8470 Using Early Data in HTTP. M. Thomson, M. Nottingham, W. Tarreau. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8470) 8471 The Token Binding Protocol Version 1.0. A. Popov, Ed., M. Nystroem, D. Balfanz, J. Hodges. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8471) 8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation. A. Popov, Ed., M. Nystroem, D. Balfanz. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8472) 8473 Token Binding over HTTP. A. Popov, M. Nystroem, D. Balfanz, Ed., N. Harper, J. Hodges. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8473) 8474 IMAP Extension for Object Identifiers. B. Gondwana, Ed.. September 2018. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8474) 8475 Using Conditional Router Advertisements for Enterprise Multihoming. J. Linkova, M. Stucchi. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8475) 8476 Signaling Maximum SID Depth (MSD) Using OSPF. J. Tantsura, U. Chunduri, S. Aldrin, P. Psenak. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8476) 8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016. J. Jimenez, H. Tschofenig, D. Thaler. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8477) 8478 Zstandard Compression and the application/zstd Media Type. Y. Collet, M. Kucherawy, Ed.. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8478) 8479 Storing Validation Parameters in PKCS#8. N. Mavrogiannopoulos. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8479) 8480 6TiSCH Operation Sublayer (6top) Protocol (6P). Q. Wang, Ed., X. Vilajosana, T. Watteyne. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8480) 8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI). R. Bush. September 2018. (Format: TXT, HTML) (Updates RFC6811) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8481) 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY. J. Abley, O. Gudmundsson, M. Majkowski, E. Hunt. January 2019. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8482) 8483 Yeti DNS Testbed. L. Song, Ed., D. Liu, P. Vixie, A. Kato, S. Kerr. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8483) 8484 DNS Queries over HTTPS (DoH). P. Hoffman, P. McManus. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8484) 8485 Vectors of Trust. J. Richer, Ed., L. Johansson. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8485) 8486 Ambisonics in an Ogg Opus Container. J. Skoglund, M. Graczyk. October 2018. (Format: TXT, HTML) (Updates RFC7845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8486) 8487 Mtrace Version 2: Traceroute Facility for IP Multicast. H. Asaeda, K. Meyer, W. Lee. Ed.. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8487) 8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation. O. Muravskiy, T. Bruijnzeels. December 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8488) 8490 DNS Stateful Operations. R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. Lemon, T. Pusateri. March 2019. (Format: TXT, HTML) (Updates RFC1035, RFC7766) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8490) 8491 Signaling Maximum SID Depth (MSD) Using IS-IS. J. Tantsura, U. Chunduri, S. Aldrin, L. Ginsberg. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8491) 8492 Secure Password Ciphersuites for Transport Layer Security (TLS). D. Harkins, Ed.. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8492) 8493 The BagIt File Packaging Format (V1.0). J. Kunze, J. Littman, E. Madden, J. Scancella, C. Adams. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8493) 8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142. D. Wilson, A. Melnikov, Ed.. November 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8494) 8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP). J. Gould, K. Feher. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8495) 8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP). D. York, T. Asveren. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8496) 8497 Marking SIP Messages to Be Logged. P. Dawes, C. Arunachalam. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8497) 8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP). M. Mohali. February 2019. (Format: TXT, HTML) (Updates RFC5502) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8498) 8499 DNS Terminology. P. Hoffman, A. Sullivan, K. Fujiwara. January 2019. (Format: TXT, HTML) (Obsoletes RFC7719) (Updates RFC2308) (Also BCP0219) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8499) 8500 IS-IS Routing with Reverse Metric. N. Shen, S. Amante, M. Abrahamsson. February 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8500) 8501 Reverse DNS in IPv6 for Internet Service Providers. L. Howard. November 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8501) 8502 L2L3 VPN Multicast MIB. Z. Zhang, H. Tsunoda. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8502) 8503 BGP/MPLS Layer 3 VPN Multicast Management Information Base. H. Tsunoda. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8503) 8504 IPv6 Node Requirements. T. Chown, J. Loughney, T. Winters. January 2019. (Format: TXT, HTML) (Obsoletes RFC6434) (Also BCP0220) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8504) 8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery. P. Thubert, Ed., E. Nordmark, S. Chakrabarti, C. Perkins. November 2018. (Format: TXT, HTML) (Updates RFC6775) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8505) 8506 Diameter Credit-Control Application. L. Bertz, Ed., D. Dolson, Ed., Y. Lifshitz, Ed.. March 2019. (Format: TXT, HTML) (Obsoletes RFC4006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8506) 8507 Simple Internet Protocol (SIP) Specification. S. Deering, R. Hinden, Ed.. December 2018. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC8507) 8508 IMAP REPLACE Extension. S. Brandt. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8508) 8509 A Root Key Trust Anchor Sentinel for DNSSEC. G. Huston, J. Damas, W. Kumari. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8509) 8510 OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement. P. Psenak, Ed., K. Talaulikar, W. Henderickx, P. Pillay-Esnault. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8510) 8511 TCP Alternative Backoff with ECN (ABE). N. Khademi, M. Welzl, G. Armitage, G. Fairhurst. December 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8511) 8512 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT). M. Boucadair, Ed., S. Sivakumar, C. Jacquenet, S. Vinapamula, Q. Wu. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8512) 8513 A YANG Data Model for Dual-Stack Lite (DS-Lite). M. Boucadair, C. Jacquenet, S. Sivakumar. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8513) 8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension. S. Bosch. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8514) 8515 URN Namespace for ETSI Documents. M. Jethanandani, M.A. Reina Ortega. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8515) 8516 "Too Many Requests" Response Code for the Constrained Application Protocol. A. Keranen. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8516) 8517 An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective. D. Dolson, Ed., J. Snellman, M. Boucadair, Ed., C. Jacquenet. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8517) 8518 Selection of Loop-Free Alternates for Multi-Homed Prefixes. P. Sarkar, Ed., U. Chunduri, Ed., S. Hegde, J. Tantsura, H. Gredler. March 2019. (Format: TXT, HTML) (Updates RFC5286) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8518) 8519 YANG Data Model for Network Access Control Lists (ACLs). M. Jethanandani, S. Agarwal, L. Huang, D. Blair. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8519) 8520 Manufacturer Usage Description Specification. E. Lear, R. Droms, D. Romascanu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8520) 8521 Registration Data Access Protocol (RDAP) Object Tagging. S. Hollenbeck, A. Newton. November 2018. (Format: TXT, HTML) (Updates RFC7484) (Also BCP0221) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8521) 8522 Looking Glass Command Set. M. Stubbig. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8522) 8525 YANG Library. A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Obsoletes RFC7895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8525) 8526 NETCONF Extensions to Support the Network Management Datastore Architecture. M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Updates RFC6241, RFC7950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8526) 8527 RESTCONF Extensions to Support the Network Management Datastore Architecture. M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Updates RFC8040) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8527) 8528 YANG Schema Mount. M. Bjorklund, L. Lhotka. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8528) 8529 YANG Data Model for Network Instances. L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8529) 8530 YANG Model for Logical Network Elements. L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8530) 8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols. D. Kumar, Q. Wu, Z. Wang. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8531) 8532 Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications. D. Kumar, Z. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8532) 8533 A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications. D. Kumar, M. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8533) 8534 Explicit Tracking with Wildcard Routes in Multicast VPN. A. Dolganow, J. Kotalwar, E. Rosen, Ed., Z. Zhang. February 2019. (Format: TXT, HTML) (Updates RFC6514, RFC6625, RFC7524, RFC7582, RFC7900) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8534) 8536 The Time Zone Information Format (TZif). A. Olson, P. Eggert, K. Murchison. February 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8536) 8537 Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs). R. Gandhi, Ed., H. Shah, J. Whittaker. February 2019. (Format: TXT, HTML) (Updates RFC4090, RFC7551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8537) 8538 Notification Message Support for BGP Graceful Restart. K. Patel, R. Fernando, J. Scudder, J. Haas. March 2019. (Format: TXT, HTML) (Updates RFC4724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8538) 8539 Softwire Provisioning Using DHCPv4 over DHCPv6. I. Farrer, Q. Sun, Y. Cui, L. Sun. March 2019. (Format: TXT, HTML) (Updates RFC7598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8539) 8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960. R. Stewart, M. Tuexen, M. Proshin. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8540) 8541 Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops. S. Litkowski, B. Decraene, M. Horneffer. March 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8541) 8542 A YANG Data Model for Fabric Topology in Data-Center Networks. Y. Zhuang, D. Shi, R. Gu, H. Ananthakrishnan. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8542) 8543 Extensible Provisioning Protocol (EPP) Organization Mapping. L. Zhou, N. Kong, J. Yao, J. Gould, G. Zhou. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8543) 8544 Organization Extension for the Extensible Provisioning Protocol (EPP). L. Zhou, N. Kong, J. Wei, J. Yao, J. Gould. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8544) 8545 Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP). A. Morton, Ed., G. Mirsky, Ed.. March 2019. (Format: TXT, HTML) (Updates RFC4656, RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8545) 8546 The Wire Image of a Network Protocol. B. Trammell, M. Kuehlewind. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8546) 8547 TCP-ENO: Encryption Negotiation Option. A. Bittau, D. Giffin, M. Handley, D. Mazieres, E. Smith. May 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8547) 8548 Cryptographic Protection of TCP Streams (tcpcrypt). A. Bittau, D. Giffin, M. Handley, D. Mazieres, Q. Slack, E. Smith. May 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8548) 8549 Export of BGP Community Information in IP Flow Information Export (IPFIX). Z. Li, R. Gu, J. Dong. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8549) 8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling. J. Schaad, B. Ramsdell, S. Turner. April 2019. (Format: TXT, HTML) (Obsoletes RFC5750) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8550) 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification. J. Schaad, B. Ramsdell, S. Turner. April 2019. (Format: TXT, HTML) (Obsoletes RFC5751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8551) 8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves. D. Crocker. March 2019. (Format: TXT, HTML) (Also BCP0222) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8552) 8553 DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names. D. Crocker. March 2019. (Format: TXT, HTML) (Updates RFC2782, RFC3263, RFC3529, RFC3620, RFC3832, RFC3887, RFC3958, RFC4120, RFC4227, RFC4386, RFC4387, RFC4976, RFC5026, RFC5328, RFC5389, RFC5415, RFC5518, RFC5555, RFC5617, RFC5679, RFC5766, RFC5780, RFC5804, RFC5864, RFC5928, RFC6120, RFC6186, RFC6376, RFC6733, RFC6763, RFC7208, RFC7489, RFC8145) (Also BCP0222) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8553) 8554 Leighton-Micali Hash-Based Signatures. D. McGrew, M. Curcio, S. Fluhrer. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8554) 8555 Automatic Certificate Management Environment (ACME). R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8555) 8556 Multicast VPN Using Bit Index Explicit Replication (BIER). E. Rosen, Ed., M. Sivakumar, T. Przygienda, S. Aldrin, A. Dolganow. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8556) 8557 Deterministic Networking Problem Statement. N. Finn, P. Thubert. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8557) 8558 Transport Protocol Path Signals. T. Hardie, Ed.. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8558) 8559 Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol. A. DeKok, J. Korhonen. April 2019. (Format: TXT, HTML) (Updates RFC5176, RFC5580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8559) 8560 Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents. A. Sajassi, Ed., S. Salam, N. Del Regno, J. Rabadan. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8560) 8561 A YANG Data Model for Microwave Radio Link. J. Ahlberg, M. Ye, X. Li, D. Spreafico, M. Vaupotic. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8561) 8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks. D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. April 2019. (Format: TXT, HTML) (Updates RFC5880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8562) 8563 Bidirectional Forwarding Detection (BFD) Multipoint Active Tails. D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8563) 8564 Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL). M. Zhang, S. Pallagatti, V. Govindan. April 2019. (Format: TXT, HTML) (Updates RFC7175, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8564) 8565 Hypertext Jeopardy Protocol (HTJP/1.0). E. Fokschaner. 1 April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8565) 8567 Customer Management DNS Resource Records. E. Rye, R. Beverly. 1 April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8567) 8568 Network Virtualization Research Challenges. CJ. Bernardos, A. Rahman, JC. Zuniga, LM. Contreras, P. Aranda, P. Lynch. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8568) 8569 Content-Centric Networking (CCNx) Semantics. M. Mosko, I. Solis, C. Wood. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8569) 8570 IS-IS Traffic Engineering (TE) Metric Extensions. L. Ginsberg, Ed., S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. March 2019. (Format: TXT, HTML) (Obsoletes RFC7810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8570) 8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions. L. Ginsberg, Ed., S. Previdi, Q. Wu, J. Tantsura, C. Filsfils. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8571) 8572 Secure Zero Touch Provisioning (SZTP). K. Watsen, I. Farrer, M. Abrahamsson. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8572) 8573 Message Authentication Code for the Network Time Protocol. A. Malhotra, S. Goldberg. June 2019. (Format: TXT, HTML) (Updates RFC5905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8573) 8574 cite-as: A Link Relation to Convey a Preferred URI for Referencing. H. Van de Sompel, M. Nelson, G. Bilder, J. Kunze, S. Warner. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8574) 8575 YANG Data Model for the Precision Time Protocol (PTP). Y. Jiang, Ed., X. Liu, J. Xu, R. Cummings, Ed.. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8575) 8576 Internet of Things (IoT) Security: State of the Art and Challenges. O. Garcia-Morchon, S. Kumar, M. Sethi. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8576) 8577 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane. H. Sitaraman, V. Beeram, T. Parikh, T. Saad. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8577) 8578 Deterministic Networking Use Cases. E. Grossman, Ed.. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8578) 8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes. S. Bosch. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8579) 8580 Sieve Extension: File Carbon Copy (FCC). K. Murchison, B. Gondwana. May 2019. (Format: TXT, HTML) (Updates RFC5230, RFC5435) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8580) 8581 Diameter Agent Overload and the Peer Overload Report. S. Donovan. August 2019. (Format: TXT, HTML) (Updates RFC7683) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8581) 8582 Diameter Overload Rate Control. S. Donovan, Ed., E. Noel. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8582) 8583 Diameter Load Information Conveyance. B. Campbell, S. Donovan, Ed., JJ. Trottin. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8583) 8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility. J. Rabadan, Ed., S. Mohanty, Ed., A. Sajassi, J. Drake, K. Nagaraj, S. Sathappan. April 2019. (Format: TXT, HTML) (Updates RFC7432) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8584) 8585 Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service. J. Palet Martinez, H. M.-H. Liu, M. Kawashima. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8585) 8586 Loop Detection in Content Delivery Networks (CDNs). S. Ludin, M. Nottingham, N. Sullivan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8586) 8587 NFS Version 4.0 Trunking Update. C. Lever, Ed., D. Noveck. May 2019. (Format: TXT, HTML) (Updates RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8587) 8588 Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN). C. Wendt, M. Barnes. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8588) 8589 The 'leaptofrogans' URI Scheme. A. Tamas, B. Phister, Ed., J-E. Rodriguez. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8589) 8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP). J. Gould, K. Feher. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8590) 8591 SIP-Based Messaging with S/MIME. B. Campbell, R. Housley. April 2019. (Format: TXT, HTML) (Updates RFC3261, RFC3428, RFC4975) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8591) 8592 Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH). R. Browne, A. Chilikin, T. Mizrahi. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8592) 8593 Video Traffic Models for RTP Congestion Control Evaluations. X. Zhu, S. Mena, Z. Sarker. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8593) 8594 The Sunset HTTP Header Field. E. Wilde. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8594) 8595 An MPLS-Based Forwarding Plane for Service Function Chaining. A. Farrel, S. Bryant, J. Drake. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8595) 8596 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH). A. Malis, S. Bryant, J. Halpern, W. Henderickx. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8596) 8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS). LM. Contreras, CJ. Bernardos, D. Lopez, M. Boucadair, P. Iovanna. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8597) 8598 Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2). T. Pauly, P. Wouters. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8598) 8599 Push Notification with the Session Initiation Protocol (SIP). C. Holmberg, M. Arnold. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8599) 8600 Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange. N. Cam-Winget, Ed., S. Appala, S. Pope, P. Saint-Andre. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8600) 8601 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. May 2019. (Format: TXT, HTML) (Obsoletes RFC7601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8601) 8602 Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses. J. Arkko, T. Hardie. July 2019. (Format: TXT, HTML) (Updates RFC3219) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8602) 8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile. M. Jenkins, L. Zieglar. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8603) 8604 Interconnecting Millions of Endpoints with Segment Routing. C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., W. Henderickx, D. Cooper. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8604) 8605 vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP). S. Hollenbeck, R. Carney. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8605) 8606 ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field. R. Jesske. June 2019. (Format: TXT, HTML) (Updates RFC3326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8606) 8607 Calendaring Extensions to WebDAV (CalDAV): Managed Attachments. C. Daboo, A. Quillaud, K. Murchison, Ed.. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8607) 8608 BGPsec Algorithms, Key Formats, and Signature Formats. S. Turner, O. Borchert. June 2019. (Format: TXT, HTML) (Obsoletes RFC8208) (Updates RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8608) 8609 Content-Centric Networking (CCNx) Messages in TLV Format. M. Mosko, I. Solis, C. Wood. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8609) 8610 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures. H. Birkholz, C. Vigano, C. Bormann. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8610) 8611 Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces. N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, M. Chen. June 2019. (Format: TXT, HTML) (Updates RFC8029) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8611) 8612 DDoS Open Threat Signaling (DOTS) Requirements. A. Mortensen, T. Reddy, R. Moskowitz. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8612) 8613 Object Security for Constrained RESTful Environments (OSCORE). G. Selander, J. Mattsson, F. Palombini, L. Seitz. July 2019. (Format: TXT, HTML) (Updates RFC7252) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8613) 8614 Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS). R. Singh, K. Kompella, S. Palislamovic. June 2019. (Format: TXT, HTML) (Updates RFC4761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8614) 8615 Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. May 2019. (Format: TXT, HTML) (Obsoletes RFC5785) (Updates RFC7230, RFC7595) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8615) 8616 Email Authentication for Internationalized Mail. J. Levine. June 2019. (Format: TXT, HTML) (Updates RFC6376, RFC7208, RFC7489) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8616) 8617 The Authenticated Received Chain (ARC) Protocol. K. Andersen, B. Long, Ed., S. Blank, Ed., M. Kucherawy, Ed.. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8617) 8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture. J. Dickinson, J. Hague, S. Dickinson, T. Manderson, J. Bond. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8618) 8619 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF). R. Housley. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8619) 8620 The JSON Meta Application Protocol (JMAP). N. Jenkins, C. Newman. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8620) 8621 The JSON Meta Application Protocol (JMAP) for Mail. N. Jenkins, C. Newman. August 2019. (Format: TXT, HTML) (Updates RFC5788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8621) 8622 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services. R. Bless. June 2019. (Format: TXT, HTML) (Obsoletes RFC3662) (Updates RFC4594, RFC8325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8622) 8623 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs). U. Palle, D. Dhody, Y. Tanaka, V. Beeram. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8623) 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC. P. Wouters, O. Sury. June 2019. (Format: TXT, HTML) (Obsoletes RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8624) 8625 Ethernet Traffic Parameters with Availability Information. H. Long, M. Ye, Ed., G. Mirsky, Ed., A. D'Alessandro, H. Shah. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8625) 8627 RTP Payload Format for Flexible Forward Error Correction (FEC). M. Zanaty, V. Singh, A. Begen, G. Mandyam. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8627) 8628 OAuth 2.0 Device Authorization Grant. W. Denniss, J. Bradley, M. Jones, H. Tschofenig. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8628) 8629 Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension. B. Cheng, L. Berger, Ed.. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8629) 8630 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent, T. Bruijnzeels. August 2019. (Format: TXT, HTML) (Obsoletes RFC7730) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8630) 8631 Link Relation Types for Web Services. E. Wilde. July 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8631) 8632 A YANG Data Model for Alarm Management. S. Vallin, M. Bjorklund. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8632) 8633 Network Time Protocol Best Current Practices. D. Reilly, H. Stenn, D. Sibold. July 2019. (Format: TXT, HTML) (Also BCP0223) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8633) 8634 BGPsec Router Certificate Rollover. B. Weis, R. Gagliano, K. Patel. August 2019. (Format: TXT, HTML) (Also BCP0224) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8634) 8635 Router Keying for BGPsec. R. Bush, S. Turner, K. Patel. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8635) 8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility. L. Hornquist Astrand, L. Zhu, M. Cullen, G. Hudson. July 2019. (Format: TXT, HTML) (Updates RFC4556) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8636) 8637 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN). D. Dhody, Y. Lee, D. Ceccarelli. July 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8637) 8638 IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks. M. Xu, Y. Cui, J. Wu, S. Yang, C. Metz. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8638) 8639 Subscription to YANG Notifications. E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8639) 8640 Dynamic Subscription to YANG Events and Datastores over NETCONF. E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8640) 8641 Subscription to YANG Notifications for Datastore Updates. A. Clemm, E. Voit. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8641) 8642 Policy Behavior for Well-Known BGP Communities. J. Borkenhagen, R. Bush, R. Bonica, S. Bayraktar. August 2019. (Format: TXT, HTML) (Updates RFC1997) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8642) 8643 An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP). A. Johnston, B. Aboba, A. Hutton, R. Jesske, T. Stach. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8643) 8645 Re-keying Mechanisms for Symmetric Keys. S. Smyshlyaev, Ed.. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8645) 8649 Hash Of Root Key Certificate Extension. R. Housley. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8649) 8651 Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension. B. Cheng, D. Wiggins, L. Berger, Ed.. October 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8651) 8654 Extended Message Support for BGP. R. Bush, K. Patel, D. Ward. October 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8654) 8655 Deterministic Networking Architecture. N. Finn, P. Thubert, B. Varga, J. Farkas. October 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8655) ./rfc-index.xml0000644000764400076440005774270113555533564013015 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 RFC8318 BCP0011 RFC2028 BCP0012 BCP0013 RFC4289 RFC6838 BCP0014 RFC2119 RFC8174 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 RFC8126 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 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 RFC8179 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 RFC8067 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 RFC8085 BCP0146 RFC5406 BCP0147 RFC5407 BCP0148 RFC5508 BCP0149 RFC5589 BCP0150 RFC5597 BCP0151 RFC5615 BCP0152 RFC5625 BCP0153 RFC6598 RFC6890 RFC8190 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 BCP0208 RFC8084 BCP0209 RFC8109 BCP0210 RFC8180 BCP0211 RFC8207 BCP0212 RFC8252 BCP0213 RFC8313 BCP0214 RFC8327 BCP0215 RFC8340 BCP0216 RFC8407 BCP0217 RFC8421 BCP0218 RFC8429 BCP0219 RFC8499 BCP0220 RFC8504 BCP0221 RFC8521 BCP0222 RFC8552 RFC8553 BCP0223 RFC8633 BCP0224 RFC8634 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 HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0001 RFC0002 Host software B. Duvall April 1969 ASCII PDF HTML 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 HTML 2 RFC0010 UNKNOWN UNKNOWN Legacy 10.17487/RFC0003 RFC0004 Network timetable E.B. Shapiro March 1969 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0004 RFC0005 Decode Encode Language (DEL) J. Rulifson June 1969 ASCII HTML 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 HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0006 RFC0007 Host-IMP interface G. Deloche May 1969 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0007 RFC0008 ARPA Network Functional Specifications G. Deloche May 1969 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0008 RFC0009 Host Software G. Deloche May 1969 PDF HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0009 RFC0010 Documentation conventions S.D. Crocker July 1969 ASCII HTML 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 PDF HTML 23 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0011 RFC0012 IMP-Host interface flow diagrams M. Wingfield August 1969 ASCII PS PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0012 RFC0013 Zero Text Length EOF Message V. Cerf August 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0013 RFC0014 RFC0015 Network subsystem for time sharing hosts C.S. Carr September 1969 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0015 RFC0016 M.I.T S. Crocker August 1969 ASCII HTML 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 HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0017 RFC0018 IMP-IMP and HOST-HOST Control Links V. Cerf September 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0018 RFC0019 Two protocol suggestions to reduce congestion at swap bound nodes J.E. Kreznar October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0019 RFC0020 ASCII format for network interchange V.G. Cerf October 1969 ASCII PDF HTML 9 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0021 RFC0022 Host-host control message formats V.G. Cerf October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0022 RFC0023 Transmission of Multiple Control Messages G. Gregg October 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0023 RFC0024 Documentation Conventions S.D. Crocker November 1969 ASCII HTML 3 RFC0016 RFC0010 RFC0016 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0024 RFC0025 No High Link Numbers S.D. Crocker October 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0025 RFC0026 RFC0027 Documentation Conventions S.D. Crocker December 1969 ASCII HTML 3 RFC0010 RFC0016 RFC0024 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0027 RFC0028 Time Standards W.K. English January 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0028 RFC0029 Response to RFC 28 R.E. Kahn January 1970 ASCII HTML 1 RFC0028 UNKNOWN UNKNOWN Legacy 10.17487/RFC0029 RFC0030 Documentation Conventions S.D. Crocker February 1970 ASCII HTML 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 HTML 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 HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0032 RFC0033 New Host-Host Protocol S.D. Crocker February 1970 ASCII HTML 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0034 RFC0035 Network Meeting S.D. Crocker March 1970 ASCII HTML 1 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0035 RFC0036 Protocol Notes S.D. Crocker March 1970 ASCII HTML 8 RFC0033 RFC0039 RFC0044 UNKNOWN UNKNOWN Legacy 10.17487/RFC0036 RFC0037 Network Meeting Epilogue, etc S.D. Crocker March 1970 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0037 RFC0038 Comments on Network Protocol from NWG/RFC #36 S.M. Wolfe March 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0038 RFC0039 Comments on Protocol Re: NWG/RFC #36 E. Harslem J.F. Heafner March 1970 ASCII HTML 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0039 RFC0040 More Comments on the Forthcoming Protocol E. Harslem J.F. Heafner March 1970 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0040 RFC0041 IMP-IMP Teletype Communication J.T. Melvin March 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0041 RFC0042 Message Data Types E. Ancona March 1970 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0042 RFC0043 Proposed Meeting A.G. Nemeth April 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0043 RFC0044 Comments on NWG/RFC 33 and 36 A. Shoshani R. Long A. Landsberg April 1970 ASCII HTML 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0044 RFC0045 New Protocol is Coming J. Postel S.D. Crocker April 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0045 RFC0046 ARPA Network protocol notes E. Meyer April 1970 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0046 RFC0047 BBN's Comments on NWG/RFC #33 J. Postel S. Crocker April 1970 ASCII HTML 4 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0047 RFC0048 Possible protocol plateau J. Postel S.D. Crocker April 1970 ASCII HTML 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0048 RFC0049 Conversations with S. Crocker (UCLA) E. Meyer April 1970 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0049 RFC0050 Comments on the Meyer Proposal E. Harslen J. Heafner April 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0050 RFC0051 Proposal for a Network Interchange Language M. Elie May 1970 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0051 RFC0052 Updated distribution list J. Postel S.D. Crocker July 1970 ASCII HTML 3 RFC0069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0052 RFC0053 Official protocol mechanism S.D. Crocker June 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0053 RFC0054 Official Protocol Proffering S.D. Crocker J. Postel J. Newkirk M. Kraley June 1970 ASCII HTML 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 HTML 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 HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0056 RFC0057 Thoughts and Reflections on NWG/RFC 54 M. Kraley J. Newkirk June 1970 ASCII HTML 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0058 RFC0059 Flow Control - Fixed Versus Demand Allocation E. Meyer June 1970 ASCII HTML 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 HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0060 RFC0061 Note on Interprocess Communication in a Resource Sharing Computer Network D.C. Walden July 1970 ASCII HTML 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 HTML 20 RFC0061 UNKNOWN UNKNOWN Legacy 10.17487/RFC0062 RFC0063 Belated Network Meeting Report V.G. Cerf July 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0063 RFC0064 Getting rid of marking M. Elie July 1970 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0064 RFC0065 Comments on Host/Host Protocol document #1 D.C. Walden August 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0065 RFC0066 NIC - third level ideas and other noise S.D. Crocker August 1970 ASCII HTML 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 HTML 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0068 RFC0069 Distribution List Change for MIT A.K. Bhushan September 1970 ASCII HTML 1 RFC0052 UNKNOWN UNKNOWN Legacy 10.17487/RFC0069 RFC0070 Note on Padding S.D. Crocker October 1970 ASCII HTML 9 RFC0228 UNKNOWN UNKNOWN Legacy 10.17487/RFC0070 RFC0071 Reallocation in Case of Input Error T. Schipper September 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0071 RFC0072 Proposed Moratorium on Changes to Network Protocol R.D. Bressler September 1970 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0072 RFC0073 Response to NWG/RFC 67 S.D. Crocker September 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0073 RFC0074 Specifications for Network Use of the UCSB On-Line System J.E. White October 1970 ASCII PDF HTML 9 RFC0217 RFC0225 UNKNOWN UNKNOWN Legacy 10.17487/RFC0074 RFC0075 Network Meeting S.D. Crocker October 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0075 RFC0076 Connection by name: User oriented protocol J. Bouknight J. Madden G.R. Grossman October 1970 ASCII HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0076 RFC0077 Network meeting report J. Postel November 1970 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0077 RFC0078 NCP Status Report: UCSB/Rand E. Harslem J.F. Heafner J.E. White October 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0078 RFC0079 Logger Protocol error E. Meyer November 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0079 RFC0080 Protocols and Data Formats E. Harslem J.F. Heafner December 1970 ASCII HTML 9 RFC0123 RFC0066 RFC0093 UNKNOWN UNKNOWN Legacy 10.17487/RFC0080 RFC0081 Request for Reference Information J. Bouknight December 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0081 RFC0082 Network Meeting Notes E. Meyer December 1970 ASCII HTML 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0082 RFC0083 Language-machine for data reconfiguration R.H. Anderson E. Harslem J.F. Heafner December 1970 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0083 RFC0084 List of NWG/RFC's 1-80 J.B. North December 1970 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0084 RFC0085 Network Working Group meeting S.D. Crocker December 1970 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0091 RFC0092 RFC0093 Initial Connection Protocol A.M. McKenzie January 1971 ASCII HTML 1 RFC0066 RFC0080 UNKNOWN UNKNOWN Legacy 10.17487/RFC0093 RFC0094 Some thoughts on Network Graphics E. Harslem J.F. Heafner February 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0094 RFC0095 Distribution of NWG/RFC's through the NIC S. Crocker February 1971 ASCII HTML 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 HTML 5 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0096 RFC0097 First Cut at a Proposed Telnet Protocol J.T. Melvin R.W. Watson February 1971 ASCII PDF HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0097 RFC0098 Logger Protocol Proposal E. Meyer T. Skinner February 1971 ASCII HTML 10 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0098 RFC0099 Network Meeting P.M. Karp February 1971 ASCII HTML 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0099 RFC0100 Categorization and guide to NWG/RFCs P.M. Karp February 1971 ASCII HTML 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 HTML 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 HTML 4 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0102 RFC0103 Implementation of Interrupt Keys R.B. Kalin February 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0103 RFC0104 Link 191 J.B. Postel S.D. Crocker February 1971 ASCII HTML 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 HTML 9 RFC0217 UNKNOWN UNKNOWN Legacy 10.17487/RFC0105 RFC0106 User/Server Site Protocol Network Host Questionnaire T.C. O'Sullivan March 1971 ASCII HTML 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 HTML 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 HTML 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 PDF HTML 12 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 PDF HTML 4 RFC0135 UNKNOWN UNKNOWN Legacy 10.17487/RFC0110 RFC0111 Pressure from the Chairman S.D. Crocker March 1971 ASCII HTML 2 RFC0107 RFC0130 UNKNOWN UNKNOWN Legacy 10.17487/RFC0111 RFC0112 User/Server Site Protocol: Network Host Questionnaire T.C. O'Sullivan April 1971 ASCII PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0112 RFC0113 Network activity report: UCSB Rand E. Harslem J.F. Heafner J.E. White April 1971 ASCII HTML 2 RFC0227 UNKNOWN UNKNOWN Legacy 10.17487/RFC0113 RFC0114 File Transfer Protocol A.K. Bhushan April 1971 ASCII HTML 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 HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0115 RFC0116 Structure of the May NWG Meeting S.D. Crocker April 1971 ASCII HTML 1 RFC0099 RFC0131 RFC0156 UNKNOWN UNKNOWN Legacy 10.17487/RFC0116 RFC0117 Some comments on the official protocol J. Wong April 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0117 RFC0118 Recommendations for facility documentation R.W. Watson April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0118 RFC0119 Network Fortran Subprograms M. Krilanovich April 1971 ASCII PDF HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0119 RFC0120 Network PL1 subprograms M. Krilanovich April 1971 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0120 RFC0121 Network on-line operators M. Krilanovich April 1971 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0121 RFC0122 Network specifications for UCSB's Simple-Minded File System J.E. White April 1971 ASCII HTML 21 RFC0217 RFC0269 RFC0399 RFC0431 UNKNOWN UNKNOWN Legacy 10.17487/RFC0122 RFC0123 Proffered Official ICP S.D. Crocker April 1971 ASCII HTML 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 HTML 1 RFC0107 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=124 10.17487/RFC0124 RFC0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream J. McConnell April 1971 ASCII HTML 4 RFC0086 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0125 RFC0126 Graphics Facilities at Ames Research Center J. McConnell April 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0126 RFC0127 Comments on RFC 123 J. Postel April 1971 ASCII HTML 2 RFC0145 RFC0123 RFC0151 UNKNOWN UNKNOWN Legacy 10.17487/RFC0127 RFC0128 Bytes J. Postel April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0128 RFC0129 Request for comments on socket name structure E. Harslem J. Heafner E. Meyer April 1971 ASCII HTML 6 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0129 RFC0130 Response to RFC 111: Pressure from the chairman J.F. Heafner April 1971 ASCII HTML 1 RFC0111 UNKNOWN UNKNOWN Legacy 10.17487/RFC0130 RFC0131 Response to RFC 116: May NWG meeting E. Harslem J.F. Heafner April 1971 ASCII HTML 3 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0131 RFC0132 Typographical Error in RFC 107 J.E. White April 1971 ASCII HTML 1 RFC0154 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0132 RFC0133 File Transfer and Error Recovery R.L. Sunberg April 1971 ASCII HTML 4 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0133 RFC0134 Network Graphics meeting A. Vezza April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0134 RFC0135 Response to NWG/RFC 110 W. Hathaway April 1971 ASCII HTML 3 RFC0110 UNKNOWN UNKNOWN Legacy 10.17487/RFC0135 RFC0136 Host accounting and administrative procedures R.E. Kahn April 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0136 RFC0137 Telnet Protocol - a proposed document T.C. O'Sullivan April 1971 ASCII HTML 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 HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0138 RFC0139 Discussion of Telnet Protocol T.C. O'Sullivan May 1971 ASCII HTML 11 RFC0137 RFC0158 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0139 RFC0140 Agenda for the May NWG meeting S.D. Crocker May 1971 ASCII HTML 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 HTML 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0142 RFC0143 Regarding proffered official ICP W. Naylor J. Wong C. Kline J. Postel May 1971 ASCII HTML 4 RFC0165 RFC0123 RFC0145 UNKNOWN UNKNOWN Legacy 10.17487/RFC0143 RFC0144 Data sharing on computer networks A. Shoshani April 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0144 RFC0145 Initial Connection Protocol Control Commands J. Postel May 1971 ASCII PS PDF HTML 2 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 HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0146 RFC0147 Definition of a socket J.M. Winett May 1971 ASCII HTML 3 RFC0129 UNKNOWN UNKNOWN Legacy 10.17487/RFC0147 RFC0148 Comments on RFC 123 A.K. Bhushan May 1971 ASCII HTML 1 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0148 RFC0149 Best Laid Plans S.D. Crocker May 1971 ASCII HTML 1 RFC0140 UNKNOWN UNKNOWN Legacy 10.17487/RFC0149 RFC0150 Use of IPC Facilities: A Working Paper R.B. Kalin May 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0150 RFC0151 Comments on a proffered official ICP: RFCs 123, 127 A. Shoshani May 1971 ASCII HTML 2 RFC0127 UNKNOWN UNKNOWN Legacy 10.17487/RFC0151 RFC0152 SRI Artificial Intelligence status report M. Wilber May 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0152 RFC0153 SRI ARC-NIC status J.T. Melvin R.W. Watson May 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0153 RFC0154 Exposition Style S.D. Crocker May 1971 ASCII HTML 1 RFC0132 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0154 RFC0155 ARPA Network mailing lists J.B. North May 1971 ASCII HTML 13 RFC0095 RFC0168 UNKNOWN UNKNOWN Legacy 10.17487/RFC0155 RFC0156 Status of the Illinois site: Response to RFC 116 J. Bouknight April 1971 ASCII HTML 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0157 RFC0158 Telnet Protocol: A Proposed Document T.C. O'Sullivan May 1971 ASCII PDF HTML 11 RFC0495 RFC0139 RFC0318 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0158 RFC0159 RFC0160 RFC brief list Network Information Center. Stanford Research Institute May 1971 ASCII HTML 4 RFC0200 RFC0999 NIC6716 UNKNOWN UNKNOWN Legacy 10.17487/RFC0160 RFC0161 Solution to the race condition in the ICP A. Shoshani May 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0161 RFC0162 NETBUGGER3 M. Kampe May 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0162 RFC0163 Data transfer protocols V.G. Cerf May 1971 ASCII HTML 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 HTML 32 UNKNOWN UNKNOWN Legacy 10.17487/RFC0164 RFC0165 Proffered Official Initial Connection Protocol J. Postel May 1971 ASCII PDF HTML 5 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 HTML 20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0166 RFC0167 Socket conventions reconsidered A.K. Bhushan R.M. Metcalfe J.M. Winett May 1971 ASCII HTML 4 RFC0129 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0167 RFC0168 ARPA Network mailing lists J.B. North May 1971 ASCII HTML 7 RFC0155 RFC0211 UNKNOWN UNKNOWN Legacy 10.17487/RFC0168 RFC0169 COMPUTER NETWORKS S.D. Crocker May 1971 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0169 RFC0170 RFC List by Number Network Information Center. Stanford Research Institute June 1971 ASCII HTML 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 HTML 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 HTML 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0173 RFC0174 UCLA - Computer Science Graphics Overview J. Postel V.G. Cerf June 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0174 RFC0175 Comments on "Socket Conventions Reconsidered" E. Harslem J.F. Heafner June 1971 ASCII HTML 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 HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0176 RFC0177 Device independent graphical display description J. McConnell June 1971 ASCII HTML 9 RFC0125 RFC0181 UNKNOWN UNKNOWN Legacy 10.17487/RFC0177 RFC0178 Network graphic attention handling I.W. Cotton June 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0178 RFC0179 Link Number Assignments A.M. McKenzie June 1971 ASCII HTML 1 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0179 RFC0180 File system questionnaire A.M. McKenzie June 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0180 RFC0181 Modifications to RFC 177 J. McConnell July 1971 ASCII HTML 3 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0181 RFC0182 Compilation of list of relevant site reports J.B. North June 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0182 RFC0183 EBCDIC Codes and Their Mapping to ASCII J.M. Winett July 1971 ASCII PDF HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0183 RFC0184 Proposed graphic display modes K.C. Kelley July 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0184 RFC0185 NIC distribution of manuals and handbooks J.B. North July 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0185 RFC0186 Network graphics loader J.C. Michener July 1971 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0186 RFC0187 Network/440 Protocol Concept D.B. McKay D.P. Karp July 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0187 RFC0188 Data management meeting announcement P.M. Karp D.B. McKay January 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0188 RFC0189 Interim NETRJS specifications R.T. Braden July 1971 ASCII HTML 19 RFC0088 RFC0599 RFC0283 UNKNOWN UNKNOWN Legacy 10.17487/RFC0189 RFC0190 DEC PDP-10-IMLAC communications system L.P. Deutsch July 1971 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0190 RFC0191 Graphics implementation and conceptualization at Augmentation Research Center C.H. Irby July 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0191 RFC0192 Some factors which a Network Graphics Protocol must consider R.W. Watson July 1971 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0192 RFC0193 NETWORK CHECKOUT E. Harslem J.F. Heafner July 1971 ASCII HTML 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 HTML 18 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=194 10.17487/RFC0194 RFC0195 Data computers-data descriptions and access language G.H. Mealy July 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0195 RFC0196 Mail Box Protocol R.W. Watson July 1971 ASCII HTML 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0196 RFC0197 Initial Connection Protocol - Reviewed A. Shoshani E. Harslem July 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0197 RFC0198 Site Certification - Lincoln Labs 360/67 J.F. Heafner July 1971 ASCII HTML 1 RFC0193 RFC0214 RFC0193 UNKNOWN UNKNOWN Legacy 10.17487/RFC0198 RFC0199 Suggestions for a Network Data-Tablet Graphics Protocol T. Williams July 1971 ASCII PDF HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0199 RFC0200 RFC list by number J.B. North August 1971 ASCII HTML 7 RFC0170 RFC0160 NIC7724 UNKNOWN UNKNOWN Legacy 10.17487/RFC0200 RFC0201 RFC0202 Possible Deadlock in ICP S.M. Wolfe J. Postel July 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0202 RFC0203 Achieving reliable communication R.B. Kalin August 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0203 RFC0204 Sockets in use J. Postel August 1971 ASCII HTML 1 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0204 RFC0205 NETCRT - a character display protocol R.T. Braden August 1971 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0205 RFC0206 A User TELNET Description of an Initial Implementation J. White August 1971 ASCII PDF HTML 14 UNKNOWN UNKNOWN Legacy 10.17487/RFC0206 RFC0207 September Network Working Group meeting A. Vezza August 1971 ASCII HTML 2 RFC0212 UNKNOWN UNKNOWN Legacy 10.17487/RFC0207 RFC0208 Address tables A.M. McKenzie August 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0208 RFC0209 Host/IMP interface documentation B. Cosell August 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0209 RFC0210 Improvement of Flow Control W. Conrad August 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0210 RFC0211 ARPA Network Mailing Lists J.B. North August 1971 ASCII PDF HTML 13 RFC0168 RFC0300 UNKNOWN UNKNOWN Legacy 10.17487/RFC0211 RFC0212 NWG meeting on network usage Information Sciences Institute University of Southern California August 1971 ASCII HTML 2 RFC0207 RFC0222 UNKNOWN UNKNOWN Legacy 10.17487/RFC0212 RFC0213 IMP System change notification B. Cosell August 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0213 RFC0214 Network checkpoint E. Harslem August 1971 ASCII HTML 2 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0214 RFC0215 NCP, ICP, and Telnet: The Terminal IMP implementation A.M. McKenzie August 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0215 RFC0216 Telnet Access to UCSB's On-Line System J.E. White September 1971 ASCII PDF HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0216 RFC0217 Specifications changes for OLS, RJE/RJOR, and SMFS J.E. White September 1971 ASCII HTML 2 RFC0074 RFC0105 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0217 RFC0218 Changing the IMP status reporting facility B. Cosell September 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0218 RFC0219 User's View of the Datacomputer R. Winter September 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0219 RFC0220 RFC0221 Mail Box Protocol: Version 2 R.W. Watson August 1971 ASCII HTML 5 RFC0196 RFC0278 UNKNOWN UNKNOWN Legacy 10.17487/RFC0221 RFC0222 Subject: System programmer's workshop R.M. Metcalfe September 1971 ASCII HTML 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 HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0223 RFC0224 Comments on Mailbox Protocol A.M. McKenzie September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0224 RFC0225 Rand/UCSB network graphics experiment E. Harslem R. Stoughton September 1971 ASCII HTML 5 RFC0074 UNKNOWN UNKNOWN Legacy 10.17487/RFC0225 RFC0226 Standardization of host mnemonics P.M. Karp September 1971 ASCII HTML 1 RFC0247 UNKNOWN UNKNOWN Legacy 10.17487/RFC0226 RFC0227 Data transfer rates (Rand/UCLA) J.F. Heafner E. Harslem September 1971 ASCII HTML 2 RFC0113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0227 RFC0228 Clarification D.C. Walden September 1971 ASCII HTML 1 RFC0070 UNKNOWN UNKNOWN Legacy 10.17487/RFC0228 RFC0229 Standard host names J. Postel September 1971 ASCII HTML 3 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0229 RFC0230 Toward reliable operation of minicomputer-based terminals on a TIP T. Pyke September 1971 ASCII HTML 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 HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0231 RFC0232 Postponement of network graphics meeting A. Vezza September 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0232 RFC0233 Standardization of host call letters A. Bhushan R. Metcalfe September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0233 RFC0234 Network Working Group meeting schedule A. Vezza October 1971 ASCII HTML 1 RFC0222 RFC0204 UNKNOWN UNKNOWN Legacy 10.17487/RFC0234 RFC0235 Site status E. Westheimer September 1971 ASCII HTML 5 RFC0240 UNKNOWN UNKNOWN Legacy 10.17487/RFC0235 RFC0236 Standard host names J. Postel September 1971 ASCII HTML 2 RFC0229 UNKNOWN UNKNOWN Legacy 10.17487/RFC0236 RFC0237 NIC view of standard host names R.W. Watson October 1971 ASCII HTML 1 RFC0273 UNKNOWN UNKNOWN Legacy 10.17487/RFC0237 RFC0238 Comments on DTP and FTP proposals R.T. Braden September 1971 ASCII HTML 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 HTML 1 RFC0226 RFC0229 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0239 RFC0240 Site Status A.M. McKenzie September 1971 ASCII HTML 4 RFC0235 RFC0252 UNKNOWN UNKNOWN Legacy 10.17487/RFC0240 RFC0241 Connecting computers to MLC ports A.M. McKenzie September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0241 RFC0242 Data Descriptive Language for Shared Data L. Haibt A.P. Mullery July 1971 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0242 RFC0243 Network and data sharing bibliography A.P. Mullery October 1971 ASCII HTML 7 RFC0290 UNKNOWN UNKNOWN Legacy 10.17487/RFC0243 RFC0244 RFC0245 Reservations for Network Group meeting C. Falls October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0245 RFC0246 Network Graphics meeting A. Vezza October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0246 RFC0247 Proffered set of standard host names P.M. Karp October 1971 ASCII HTML 4 RFC0226 UNKNOWN UNKNOWN Legacy 10.17487/RFC0247 RFC0248 RFC0249 Coordination of equipment and supplies purchase R.F. Borelli October 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0249 RFC0250 Some thoughts on file transfer H. Brodie October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0250 RFC0251 Weather data D. Stern October 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0251 RFC0252 Network host status E. Westheimer October 1971 ASCII HTML 3 RFC0240 RFC0255 UNKNOWN UNKNOWN Legacy 10.17487/RFC0252 RFC0253 Second Network Graphics meeting details J.A. Moorer October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0253 RFC0254 Scenarios for using ARPANET computers A. Bhushan October 1971 ASCII PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0254 RFC0255 Status of network hosts E. Westheimer October 1971 ASCII HTML 2 RFC0252 RFC0266 UNKNOWN UNKNOWN Legacy 10.17487/RFC0255 RFC0256 IMPSYS change notification B. Cosell November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0256 RFC0257 RFC0258 RFC0259 RFC0260 RFC0261 RFC0262 RFC0263 "Very Distant" Host interface A.M. McKenzie December 1971 ASCII HTML 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 HTML 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 HTML 12 FTP RFC0172 RFC0354 RFC0281 RFC0294 RFC0310 RFC0264 UNKNOWN UNKNOWN Legacy 10.17487/RFC0265 RFC0266 Network host status E. Westheimer November 1971 ASCII HTML 2 RFC0255 RFC0267 UNKNOWN UNKNOWN Legacy 10.17487/RFC0266 RFC0267 Network Host Status E. Westheimer November 1971 ASCII HTML 4 RFC0266 RFC0287 UNKNOWN UNKNOWN Legacy 10.17487/RFC0267 RFC0268 Graphics facilities information J. Postel November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0268 RFC0269 Some Experience with File Transfer H. Brodie December 1971 ASCII HTML 3 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0269 RFC0270 Correction to BBN Report No. 1822 (NIC NO 7958) A.M. McKenzie January 1972 ASCII PDF HTML 1 NIC7959 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=270 10.17487/RFC0270 RFC0271 IMP System change notifications B. Cosell January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0271 RFC0272 RFC0273 More on standard host names R.W. Watson October 1971 ASCII HTML 3 RFC0237 UNKNOWN UNKNOWN Legacy 10.17487/RFC0273 RFC0274 Establishing a local guide for network usage E. Forman November 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0274 RFC0275 RFC0276 NIC course R.W. Watson November 1971 ASCII HTML 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 HTML 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0278 RFC0279 RFC0280 A Draft of Host Names R.W. Watson November 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0280 RFC0281 Suggested addition to File Transfer Protocol A.M. McKenzie December 1971 ASCII HTML 8 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0281 RFC0282 Graphics meeting report M.A. Padlipsky December 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0282 RFC0283 NETRJT: Remote Job Service Protocol for TIPS R.T. Braden December 1971 ASCII HTML 9 RFC0189 UNKNOWN UNKNOWN Legacy 10.17487/RFC0283 RFC0284 RFC0285 Network graphics D. Huff December 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0285 RFC0286 Network Library Information System E. Forman December 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0286 RFC0287 Status of Network Hosts E. Westheimer December 1971 ASCII HTML 5 RFC0267 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0287 RFC0288 Network host status E. Westheimer January 1972 ASCII HTML 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 HTML 3 RFC0384 UNKNOWN UNKNOWN Legacy 10.17487/RFC0289 RFC0290 Computer networks and data sharing: A bibliography A.P. Mullery January 1972 ASCII HTML 15 RFC0243 UNKNOWN UNKNOWN Legacy 10.17487/RFC0290 RFC0291 Data Management Meeting Announcement D.B. McKay January 1972 ASCII HTML 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 HTML 10 RFC0493 UNKNOWN UNKNOWN Legacy 10.17487/RFC0292 RFC0293 Network Host Status E. Westheimer January 1972 ASCII HTML 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 HTML 2 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0294 RFC0295 Report of the Protocol Workshop, 12 October 1971 J. Postel January 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0295 RFC0296 DS-1 Display System D.E. Liddle January 1972 ASCII PDF HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0296 RFC0297 TIP Message Buffers D.C. Walden January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0297 RFC0298 Network host status E. Westheimer February 1972 ASCII HTML 4 RFC0293 RFC0306 UNKNOWN UNKNOWN Legacy 10.17487/RFC0298 RFC0299 Information Management System D. Hopkin February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0299 RFC0300 ARPA Network mailing lists J.B. North January 1972 ASCII HTML 9 RFC0211 RFC0303 UNKNOWN UNKNOWN Legacy 10.17487/RFC0300 RFC0301 BBN IMP (#5) and NCC Schedule March 4, 1971 R. Alter February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0301 RFC0302 Exercising The ARPANET R.F. Bryan February 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0302 RFC0303 ARPA Network mailing lists Network Information Center. Stanford Research Institute March 1972 ASCII HTML 11 RFC0300 RFC0329 UNKNOWN UNKNOWN Legacy 10.17487/RFC0303 RFC0304 Data Management System Proposal for the ARPA Network D.B. McKay February 1972 ASCII PDF HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0304 RFC0305 Unknown Host Numbers R. Alter February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0305 RFC0306 Network host status E. Westheimer February 1972 ASCII HTML 4 RFC0298 RFC0315 UNKNOWN UNKNOWN Legacy 10.17487/RFC0306 RFC0307 Using network Remote Job Entry E. Harslem February 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0307 RFC0308 ARPANET host availability data M. Seriff March 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0308 RFC0309 Data and File Transfer Workshop Announcement A.K. Bhushan March 1972 ASCII HTML 6 FTP DTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0309 RFC0310 Another Look at Data and File Transfer Protocols A.K. Bhushan April 1972 ASCII HTML 7 FTP RFC0264 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0310 RFC0311 New Console Attachments to the USCB Host R.F. Bryan February 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0311 RFC0312 Proposed Change in IMP-to-Host Protocol A.M. McKenzie March 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0312 RFC0313 Computer based instruction T.C. O'Sullivan March 1972 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0313 RFC0314 Network Graphics Working Group Meeting I.W. Cotton March 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0314 RFC0315 Network Host Status E. Westheimer March 1972 ASCII HTML 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 HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0316 RFC0317 Official Host-Host Protocol Modification: Assigned Link Numbers J. Postel March 1972 ASCII HTML 1 RFC0604 UNKNOWN UNKNOWN Legacy 10.17487/RFC0317 RFC0318 Telnet Protocols J. Postel April 1972 ASCII HTML 16 RFC0158 RFC0435 RFC0139 RFC0158 UNKNOWN UNKNOWN Legacy 10.17487/RFC0318 RFC0319 Network Host Status E. Westheimer March 1972 ASCII HTML 4 RFC0315 RFC0326 UNKNOWN UNKNOWN Legacy 10.17487/RFC0319 RFC0320 Workshop on Hard Copy Line Graphics R. Reddy March 1972 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0320 RFC0321 CBI Networking Activity at MITRE P.M. Karp March 1972 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0321 RFC0322 Well known socket numbers V. Cerf J. Postel March 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0322 RFC0323 Formation of Network Measurement Group (NMG) V. Cerf March 1972 ASCII HTML 9 RFC0388 UNKNOWN UNKNOWN Legacy 10.17487/RFC0323 RFC0324 RJE Protocol meeting J. Postel April 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0324 RFC0325 Network Remote Job Entry program - NETRJS G. Hicks April 1972 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0325 RFC0326 Network Host Status E. Westheimer April 1972 ASCII HTML 4 RFC0330 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0326 RFC0327 Data and File Transfer workshop notes A.K. Bhushan April 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0327 RFC0328 Suggested Telnet Protocol Changes J. Postel April 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0328 RFC0329 ARPA Network Mailing Lists Network Information Center. Stanford Research Institute May 1972 ASCII HTML 13 RFC0303 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0329 RFC0330 Network Host Status E. Westheimer April 1972 ASCII HTML 3 RFC0326 RFC0332 UNKNOWN UNKNOWN Legacy 10.17487/RFC0330 RFC0331 IMP System Change Notification J.M. McQuillan April 1972 ASCII HTML 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0331 RFC0332 Network Host Status E. Westheimer April 1972 ASCII HTML 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 HTML 26 UNKNOWN UNKNOWN Legacy 10.17487/RFC0333 RFC0334 Network Use on May 8 A.M. McKenzie May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0334 RFC0335 New Interface - IMP/360 R.F. Bryan May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0335 RFC0336 Level 0 Graphic Input Protocol I.W. Cotton May 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0336 RFC0337 RFC0338 EBCDIC/ASCII Mapping for Network RJE R.T. Braden May 1972 ASCII PS PDF HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0338 RFC0339 MLTNET: A "Multi Telnet" Subsystem for Tenex R. Thomas May 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0339 RFC0340 Proposed Telnet Changes T.C. O'Sullivan May 1972 ASCII HTML 2 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0340 RFC0341 RFC0342 Network Host Status E. Westheimer May 1972 ASCII HTML 4 RFC0332 RFC0344 UNKNOWN UNKNOWN Legacy 10.17487/RFC0342 RFC0343 IMP System change notification A.M. McKenzie May 1972 ASCII HTML 2 RFC0331 RFC0359 UNKNOWN UNKNOWN Legacy 10.17487/RFC0343 RFC0344 Network Host Status E. Westheimer May 1972 ASCII HTML 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 HTML 1 MIP UNKNOWN UNKNOWN Legacy 10.17487/RFC0345 RFC0346 Satellite Considerations J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0346 RFC0347 Echo process J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0347 RFC0348 Discard Process J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0348 RFC0349 Proposed Standard Socket Numbers J. Postel May 1972 ASCII HTML 1 RFC0433 RFC0204 RFC0322 UNKNOWN UNKNOWN Legacy 10.17487/RFC0349 RFC0350 User Accounts for UCSB On-Line System R. Stoughton May 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0350 RFC0351 Graphics information form for the ARPANET graphics resources notebook D. Crocker June 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0351 RFC0352 TIP Site Information Form D. Crocker June 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0352 RFC0353 Network host status E. Westheimer June 1972 ASCII HTML 5 RFC0344 RFC0362 UNKNOWN UNKNOWN Legacy 10.17487/RFC0353 RFC0354 File Transfer Protocol A.K. Bhushan July 1972 ASCII HTML 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 HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0355 RFC0356 ARPA Network Control Center R. Alter June 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0356 RFC0357 Echoing strategy for satellite links J. Davidson June 1972 ASCII HTML 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 HTML 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0359 RFC0360 Proposed Remote Job Entry Protocol C. Holland June 1972 ASCII PDF HTML 18 RFC0407 UNKNOWN UNKNOWN Legacy 10.17487/RFC0360 RFC0361 Deamon Processes on Host 106 R.D. Bressler July 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0361 RFC0362 Network Host Status E. Westheimer June 1972 ASCII HTML 4 RFC0353 RFC0366 UNKNOWN UNKNOWN Legacy 10.17487/RFC0362 RFC0363 ARPA Network mailing lists Network Information Center. Stanford Research Institute August 1972 ASCII HTML 13 RFC0329 RFC0402 UNKNOWN UNKNOWN Legacy 10.17487/RFC0363 RFC0364 Serving remote users on the ARPANET M.D. Abrams July 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0364 RFC0365 Letter to All TIP Users D.C. Walden July 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0365 RFC0366 Network Host Status E. Westheimer July 1972 ASCII HTML 4 RFC0362 RFC0367 UNKNOWN UNKNOWN Legacy 10.17487/RFC0366 RFC0367 Network host status E. Westheimer July 1972 ASCII HTML 4 RFC0366 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0367 RFC0368 Comments on "Proposed Remote Job Entry Protocol" R.T. Braden July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0368 RFC0369 Evaluation of ARPANET services January-March, 1972 J.R. Pickens July 1972 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0369 RFC0370 Network Host Status E. Westheimer July 1972 ASCII HTML 5 RFC0367 RFC0376 UNKNOWN UNKNOWN Legacy 10.17487/RFC0370 RFC0371 Demonstration at International Computer Communications Conference R.E. Kahn July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0371 RFC0372 Notes on a Conversation with Bob Kahn on the ICCC R.W. Watson July 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0372 RFC0373 Arbitrary Character Sets J. McCarthy July 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0373 RFC0374 IMP System Announcement A.M. McKenzie July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0374 RFC0375 RFC0376 Network Host Status E. Westheimer August 1972 ASCII HTML 5 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0376 RFC0377 Using TSO via ARPA Network Virtual Terminal R.T. Braden August 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0377 RFC0378 Traffic statistics (July 1972) A.M. McKenzie August 1972 ASCII HTML 3 RFC0391 UNKNOWN UNKNOWN Legacy 10.17487/RFC0378 RFC0379 Using TSO at CCN R. Braden August 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0379 RFC0380 RFC0381 Three aids to improved network operation J.M. McQuillan July 1972 ASCII HTML 4 RFC0394 UNKNOWN UNKNOWN Legacy 10.17487/RFC0381 RFC0382 Mathematical Software on the ARPA Network L. McDaniel August 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0382 RFC0383 RFC0384 Official site idents for organizations in the ARPA Network J.B. North August 1972 ASCII HTML 4 RFC0289 UNKNOWN UNKNOWN Legacy 10.17487/RFC0384 RFC0385 Comments on the File Transfer Protocol A.K. Bhushan August 1972 ASCII HTML 6 FTP RFC0354 RFC0414 UNKNOWN UNKNOWN Legacy 10.17487/RFC0385 RFC0386 Letter to TIP users-2 B. Cosell D.C. Walden August 1972 ASCII HTML 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 HTML 5 RFC0401 UNKNOWN UNKNOWN Legacy 10.17487/RFC0387 RFC0388 NCP statistics V. Cerf August 1972 ASCII HTML 5 RFC0323 UNKNOWN UNKNOWN Legacy 10.17487/RFC0388 RFC0389 UCLA Campus Computing Network Liaison Staff for ARPA Network B. Noble August 1972 ASCII HTML 2 RFC0423 UNKNOWN UNKNOWN Legacy 10.17487/RFC0389 RFC0390 TSO Scenario R.T. Braden September 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0390 RFC0391 Traffic statistics (August 1972) A.M. McKenzie September 1972 ASCII HTML 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 HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0392 RFC0393 Comments on Telnet Protocol Changes J.M. Winett October 1972 ASCII HTML 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 HTML 3 RFC0381 UNKNOWN UNKNOWN Legacy 10.17487/RFC0394 RFC0395 Switch Settings on IMPs and TIPs J.M. McQuillan October 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0395 RFC0396 Network Graphics Working Group Meeting - Second Iteration S. Bunch November 1972 ASCII HTML 1 RFC0474 UNKNOWN UNKNOWN Legacy 10.17487/RFC0396 RFC0397 RFC0398 UCSB Online Graphics J.R. Pickens E. Faeh September 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0398 RFC0399 SMFS Login and Logout M. Krilanovich September 1972 ASCII HTML 2 RFC0431 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0399 RFC0400 Traffic Statistics (September 1972) A.M. McKenzie October 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0400 RFC0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates J. Hansen October 1972 ASCII HTML 2 RFC0387 UNKNOWN UNKNOWN Legacy 10.17487/RFC0401 RFC0402 ARPA Network Mailing Lists J.B. North October 1972 ASCII HTML 16 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0402 RFC0403 Desirability of a Network 1108 Service G. Hicks January 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0403 RFC0404 Host Address Changes Involving Rand and ISI A.M. McKenzie October 1972 ASCII HTML 1 RFC0405 UNKNOWN UNKNOWN Legacy 10.17487/RFC0404 RFC0405 Correction to RFC 404 A.M. McKenzie October 1972 ASCII HTML 1 RFC0404 UNKNOWN UNKNOWN Legacy 10.17487/RFC0405 RFC0406 Scheduled IMP Software Releases J.M. McQuillan October 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0406 RFC0407 Remote Job Entry Protocol R.D. Bressler R. Guida A.M. McKenzie October 1972 ASCII HTML 21 RJE RFC0360 HISTORIC HISTORIC Legacy 10.17487/RFC0407 RFC0408 NETBANK A.D. Owen J. Postel October 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0408 RFC0409 Tenex interface to UCSB's Simple-Minded File System J.E. White December 1972 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0409 RFC0410 Removal of the 30-Second Delay When Hosts Come Up J.M. McQuillan November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0410 RFC0411 New MULTICS Network Software Features M.A. Padlipsky November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0411 RFC0412 User FTP Documentation G. Hicks November 1972 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0412 RFC0413 Traffic statistics (October 1972) A.M. McKenzie November 1972 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0413 RFC0414 File Transfer Protocol (FTP) status and further comments A.K. Bhushan December 1972 ASCII HTML 5 RFC0385 UNKNOWN UNKNOWN Legacy 10.17487/RFC0414 RFC0415 Tenex bandwidth H. Murray November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0415 RFC0416 ARC System Will Be Unavailable for Use During Thanksgiving Week J.C. Norton November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0416 RFC0417 Link usage violation J. Postel C. Kline December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0417 RFC0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center W. Hathaway November 1972 PDF HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0418 RFC0419 To: Network liaisons and station agents A. Vezza December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0419 RFC0420 CCA ICCC weather demo H. Murray January 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0420 RFC0421 Software Consulting Service for Network Users A.M. McKenzie November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0421 RFC0422 Traffic statistics (November 1972) A.M. McKenzie December 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0422 RFC0423 UCLA Campus Computing Network Liaison Staff for ARPANET B. Noble December 1972 ASCII HTML 2 RFC0389 UNKNOWN UNKNOWN Legacy 10.17487/RFC0423 RFC0424 RFC0425 "But my NCP costs $500 a day" R.D. Bressler December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0425 RFC0426 Reconnection Protocol R. Thomas January 1973 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0426 RFC0427 RFC0428 RFC0429 Character Generator Process J. Postel December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0429 RFC0430 Comments on File Transfer Protocol R.T. Braden February 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0430 RFC0431 Update on SMFS Login and Logout M. Krilanovich December 1972 ASCII HTML 3 RFC0399 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0431 RFC0432 Network logical map N. Neigus December 1972 ASCII PDF PS HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0432 RFC0433 Socket number list J. Postel December 1972 ASCII HTML 5 RFC0349 RFC0503 UNKNOWN UNKNOWN Legacy 10.17487/RFC0433 RFC0434 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII HTML 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0434 RFC0435 Telnet issues B. Cosell D.C. Walden January 1973 ASCII HTML 10 RFC0318 UNKNOWN UNKNOWN Legacy 10.17487/RFC0435 RFC0436 Announcement of RJS at UCSB M. Krilanovich January 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0436 RFC0437 Data Reconfiguration Service at UCSB E. Faeh June 1973 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0437 RFC0438 FTP server-server interaction R. Thomas R. Clements January 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0438 RFC0439 PARRY encounters the DOCTOR V. Cerf January 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0439 RFC0440 Scheduled network software maintenance D.C. Walden January 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0440 RFC0441 Inter-Entity Communication - an experiment R.D. Bressler R. Thomas January 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0441 RFC0442 Current flow-control scheme for IMPSYS V. Cerf January 1973 ASCII HTML 7 RFC0449 UNKNOWN UNKNOWN Legacy 10.17487/RFC0442 RFC0443 Traffic statistics (December 1972) A.M. McKenzie January 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0443 RFC0444 RFC0445 IMP/TIP preventive maintenance schedule A.M. McKenzie January 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0445 RFC0446 Proposal to consider a network program resource notebook L.P. Deutsch January 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0446 RFC0447 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII HTML 2 RFC0434 RFC0476 UNKNOWN UNKNOWN Legacy 10.17487/RFC0447 RFC0448 Print files in FTP R.T. Braden February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0448 RFC0449 Current flow-control scheme for IMPSYS D.C. Walden January 1973 ASCII HTML 1 RFC0442 UNKNOWN UNKNOWN Legacy 10.17487/RFC0449 RFC0450 MULTICS sampling timeout change M.A. Padlipsky February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0450 RFC0451 Tentative proposal for a Unified User Level Protocol M.A. Padlipsky February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0451 RFC0452 TELNET Command at Host LL J. Winett February 1973 ASCII PDF HTML 14 UNKNOWN UNKNOWN Legacy 10.17487/RFC0452 RFC0453 Meeting announcement to discuss a network mail system M.D. Kudlick February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0453 RFC0454 File Transfer Protocol - meeting announcement and a new proposed document A.M. McKenzie February 1973 ASCII HTML 35 FTP RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0454 RFC0455 Traffic statistics (January 1973) A.M. McKenzie February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0455 RFC0456 Memorandum: Date change of mail meeting M.D. Kudlick February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0456 RFC0457 TIPUG D.C. Walden February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0457 RFC0458 Mail retrieval via FTP R.D. Bressler R. Thomas February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0458 RFC0459 Network questionnaires W. Kantrowitz February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0459 RFC0460 NCP survey C. Kline February 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0460 RFC0461 Telnet Protocol meeting announcement A.M. McKenzie February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0461 RFC0462 Responding to user needs J. Iseli D. Crocker February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0462 RFC0463 FTP comments and response to RFC 430 A.K. Bhushan February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0463 RFC0464 Resource notebook framework M.D. Kudlick February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0464 RFC0465 RFC0466 Telnet logger/server for host LL-67 J.M. Winett February 1973 ASCII HTML 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 HTML 7 RFC0492 UNKNOWN UNKNOWN Legacy 10.17487/RFC0467 RFC0468 FTP data compression R.T. Braden March 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0468 RFC0469 Network mail meeting summary M.D. Kudlick March 1973 ASCII HTML 10 network mail meeting UNKNOWN UNKNOWN Legacy 10.17487/RFC0469 RFC0470 Change in socket for TIP news facility R. Thomas March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0470 RFC0471 Workshop on multi-site executive programs R. Thomas March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0471 RFC0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925) S. Bunch March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0472 RFC0473 MIX and MIXAL? D.C. Walden February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0473 RFC0474 Announcement of NGWG meeting: Call for papers S. Bunch March 1973 ASCII HTML 2 RFC0396 UNKNOWN UNKNOWN Legacy 10.17487/RFC0474 RFC0475 FTP and Network Mail System A.K. Bhushan March 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0475 RFC0476 IMP/TIP memory retrofit schedule (rev 2) A.M. McKenzie March 1973 ASCII HTML 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0476 RFC0477 Remote Job Service at UCSB M. Krilanovich May 1973 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0477 RFC0478 FTP server-server interaction - II R.D. Bressler R. Thomas March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0478 RFC0479 Use of FTP by the NIC Journal J.E. White March 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0479 RFC0480 Host-dependent FTP parameters J.E. White March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0480 RFC0481 RFC0482 Traffic statistics (February 1973) A.M. McKenzie March 1973 ASCII HTML 4 RFC0497 UNKNOWN UNKNOWN Legacy 10.17487/RFC0482 RFC0483 Cancellation of the resource notebook framework meeting M.D. Kudlick March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0483 RFC0484 RFC0485 MIX and MIXAL at UCSB J.R. Pickens March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0485 RFC0486 Data transfer revisited R.D. Bressler March 1973 ASCII HTML 2 RJE FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0486 RFC0487 Free file transfer R.D. Bressler April 1973 ASCII HTML 2 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0487 RFC0488 NLS classes at network sites M.F. Auerbach March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0488 RFC0489 Comment on resynchronization of connection status proposal J. Postel March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0489 RFC0490 Surrogate RJS for UCLA-CCN J.R. Pickens March 1973 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0490 RFC0491 What is "Free"? M.A. Padlipsky April 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0491 RFC0492 Response to RFC 467 E. Meyer April 1973 ASCII HTML 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 PDF HTML 28 RFC0292 UNKNOWN UNKNOWN Legacy 10.17487/RFC0493 RFC0494 Availability of MIX and MIXAL in the Network D.C. Walden April 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0494 RFC0495 Telnet Protocol specifications A.M. McKenzie May 1973 ASCII HTML 2 RFC0158 RFC0562 UNKNOWN UNKNOWN Legacy 10.17487/RFC0495 RFC0496 TNLS quick reference card is available M.F. Auerbach April 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0496 RFC0497 Traffic Statistics (March 1973) A.M. McKenzie April 1973 ASCII PDF HTML 4 RFC0482 UNKNOWN UNKNOWN Legacy 10.17487/RFC0497 RFC0498 On mail service to CCN R.T. Braden April 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0498 RFC0499 Harvard's network RJE B.R. Reussow April 1973 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0499 RFC0500 Integration of data management systems on a computer network A. Shoshani I. Spiegler April 1973 PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0500 RFC0501 Un-muddling "free file transfer" K.T. Pogran May 1973 ASCII HTML 5 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0501 RFC0502 RFC0503 Socket number list N. Neigus J. Postel April 1973 ASCII HTML 8 RFC0433 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0503 RFC0504 Distributed resources workshop announcement R. Thomas April 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0504 RFC0505 Two solutions to a file transfer access problem M.A. Padlipsky June 1973 ASCII HTML 3 FTP free UNKNOWN UNKNOWN Legacy 10.17487/RFC0505 RFC0506 FTP command naming problem M.A. Padlipsky June 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0506 RFC0507 RFC0508 Real-time data transmission on the ARPANET L. Pfeifer J. McAfee May 1973 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0508 RFC0509 Traffic statistics (April 1973) A.M. McKenzie April 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0509 RFC0510 Request for network mailbox addresses J.E. White May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0510 RFC0511 Enterprise phone service to NIC from ARPANET sites J.B. North May 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0511 RFC0512 More on lost message detection W. Hathaway May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0512 RFC0513 Comments on the new Telnet specifications W. Hathaway May 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0513 RFC0514 Network make-work W. Kantrowitz June 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0514 RFC0515 Specifications for Datalanguage, Version 0/9 R. Winter June 1973 ASCII HTML 31 UNKNOWN UNKNOWN Legacy 10.17487/RFC0515 RFC0516 Lost message detection J. Postel May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0516 RFC0517 RFC0518 ARPANET accounts N. Vaughan E.J. Feinler June 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0518 RFC0519 Resource Evaluation J.R. Pickens June 1973 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0519 RFC0520 Memo to FTP group: Proposal for File Access Protocol J.D. Day June 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0520 RFC0521 Restricted use of IMP DDT A.M. McKenzie May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0521 RFC0522 Traffic Statistics (May 1973) A.M. McKenzie June 1973 ASCII PDF HTML 4 RFC0509 UNKNOWN UNKNOWN Legacy 10.17487/RFC0522 RFC0523 SURVEY is in operation again A.K. Bhushan June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0523 RFC0524 Proposed Mail Protocol J.E. White June 1973 ASCII HTML 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 PS PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0525 RFC0526 Technical meeting: Digital image processing software systems W.K. Pratt June 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0526 RFC0527 ARPAWOCKY R. Merryman May 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0527 RFC0528 Software checksumming in the IMP and network reliability J.M. McQuillan June 1973 ASCII HTML 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 HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0529 RFC0530 Report on the Survey Project A.K. Bhushan June 1973 PDF HTML 0 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0531 RFC0532 UCSD-CC Server-FTP facility R.G. Merryman July 1973 ASCII HTML 4 FTP server UNKNOWN UNKNOWN Legacy 10.17487/RFC0532 RFC0533 Message-ID numbers D.C. Walden July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0533 RFC0534 Lost message detection D.C. Walden July 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0534 RFC0535 Comments on File Access Protocol R. Thomas July 1973 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0535 RFC0536 RFC0537 Announcement of NGG meeting July 16-17 S. Bunch June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0537 RFC0538 Traffic statistics (June 1973) A.M. McKenzie July 1973 ASCII HTML 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 HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0539 RFC0540 RFC0541 RFC0542 File Transfer Protocol N. Neigus August 1973 ASCII HTML 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 HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0543 RFC0544 Locating on-line documentation at SRI-ARC N.D. Meyer K. Kelley July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0544 RFC0545 Of what quality be the UCSB resources evaluators? J.R. Pickens July 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0545 RFC0546 Tenex load averages for July 1973 R. Thomas August 1973 ASCII PS PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0546 RFC0547 Change to the Very Distant Host specification D.C. Walden August 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0547 RFC0548 Hosts using the IMP Going Down message D.C. Walden August 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0548 RFC0549 Minutes of Network Graphics Group meeting, 15-17 July 1973 J.C. Michener July 1973 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0549 RFC0550 NIC NCP experiment L.P. Deutsch August 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0550 RFC0551 NYU, ANL, and LBL Joining the Net Y. Feinroth R. Fink August 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0551 RFC0552 Single access to standard protocols A.D. Owen July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0552 RFC0553 Draft design for a text/graphics protocol C.H. Irby K. Victor July 1973 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0553 RFC0554 RFC0555 Responses to critiques of the proposed mail protocol J.E. White July 1973 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0555 RFC0556 Traffic Statistics (July 1973) A.M. McKenzie August 1973 ASCII PDF HTML 4 RFC0538 UNKNOWN UNKNOWN Legacy 10.17487/RFC0556 RFC0557 REVELATIONS IN NETWORK HOST MEASUREMENTS B.D. Wessler August 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0557 RFC0558 RFC0559 Comments on The New Telnet Protocol and its Implementation A.K. Bushan August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0559 RFC0560 Remote Controlled Transmission and Echoing Telnet option D. Crocker J. Postel August 1973 ASCII PDF HTML 12 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 HTML 3 RFC0680 UNKNOWN UNKNOWN Legacy 10.17487/RFC0561 RFC0562 Modifications to the TELNET Specification A.M. McKenzie August 1973 ASCII PDF HTML 2 RFC0495 UNKNOWN UNKNOWN Legacy 10.17487/RFC0562 RFC0563 Comments on the RCTE Telnet option J. Davidson August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0563 RFC0564 RFC0565 Storing network survey data at the datacomputer D. Cantor August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0565 RFC0566 Traffic statistics (August 1973) A.M. McKenzie September 1973 ASCII HTML 4 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0566 RFC0567 Cross Country Network Bandwidth L.P. Deutsch September 1973 ASCII HTML 1 RFC0568 UNKNOWN UNKNOWN Legacy 10.17487/RFC0567 RFC0568 Response to RFC 567 - cross country network bandwidth J.M. McQuillan September 1973 ASCII HTML 3 RFC0567 UNKNOWN UNKNOWN Legacy 10.17487/RFC0568 RFC0569 NETED: A Common Editor for the ARPA Network M.A. Padlipsky October 1973 ASCII HTML 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 PS PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0570 RFC0571 TENEX FTP PROBLEM R. Braden November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0571 RFC0572 RFC0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS A. Bhushan September 1973 ASCII PDF HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0573 RFC0574 Announcement of a Mail Facility at UCSB M. Krilanovich September 1973 ASCII PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0574 RFC0575 RFC0576 Proposal for modifying linking K. Victor September 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0576 RFC0577 Mail priority D. Crocker October 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0577 RFC0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle A.K. Bhushan N.D. Ryan October 1973 ASCII PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0578 RFC0579 Traffic statistics (September 1973) A.M. McKenzie November 1973 ASCII PDF HTML 5 RFC0566 RFC0586 UNKNOWN UNKNOWN Legacy 10.17487/RFC0579 RFC0580 Note to Protocol Designers and Implementers J. Postel October 1973 ASCII HTML 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 PDF HTML 5 RFC0560 UNKNOWN UNKNOWN Legacy 10.17487/RFC0581 RFC0582 Comments on RFC 580: Machine readable protocols R. Clements November 1973 ASCII HTML 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 HTML 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 HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0585 RFC0586 Traffic statistics (October 1973) A.M. McKenzie November 1973 ASCII PDF HTML 5 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0586 RFC0587 Announcing New Telnet Options J. Postel November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0587 RFC0588 London Node Is Now Up A. Stokes October 1973 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0588 RFC0589 CCN NETRJS server messages to remote user R.T. Braden November 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0589 RFC0590 MULTICS address change M.A. Padlipsky November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0590 RFC0591 Addition to the Very Distant Host specifications D.C. Walden November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0591 RFC0592 Some thoughts on system design to facilitate resource sharing R.W. Watson November 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0592 RFC0593 Telnet and FTP implementation schedule change A.M. McKenzie J. Postel November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0593 RFC0594 Speedup of Host-IMP interface J.D. Burchfiel December 1973 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0594 RFC0595 Second thoughts in defense of the Telnet Go-Ahead W. Hathaway December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0595 RFC0596 Second thoughts on Telnet Go-Ahead E.A. Taft December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0596 RFC0597 Host status N. Neigus E.J. Feinler December 1973 ASCII HTML 6 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0597 RFC0598 RFC index - December 5, 1973 Network Information Center. Stanford Research Institute December 1973 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0598 RFC0599 Update on NETRJS R.T. Braden December 1973 ASCII HTML 9 RFC0189 RFC0740 UNKNOWN UNKNOWN Legacy 10.17487/RFC0599 RFC0600 Interfacing an Illinois plasma terminal to the ARPANET A. Berggreen November 1973 ASCII PDF HTML 3

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 HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0601 RFC0602 "The stockings were hung by the chimney with care" R.M. Metcalfe December 1973 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0612 RFC0613 Network connectivity: A response to RFC 603 A.M. McKenzie January 1974 ASCII HTML 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 HTML 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 HTML 4 RFC0645 UNKNOWN UNKNOWN Legacy 10.17487/RFC0615 RFC0616 LATEST NETWORK MAPS D. Walden February 1973 ASCII PDF HTML 1 Network maps UNKNOWN UNKNOWN Legacy 10.17487/RFC0616 RFC0617 Note on socket number assignment E.A. Taft February 1974 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 3

Modification of previous policy.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0622 RFC0623 Comments on on-line host name service M. Krilanovich February 1974 ASCII HTML 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 HTML 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 HTML 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 HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0626 RFC0627 ASCII text file of hostnames M.D. Kudlick E.J. Feinler March 1974 ASCII HTML 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 HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0628 RFC0629 Scenario for using the Network Journal J.B. North March 1974 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0629 RFC0630 FTP error code usage for more reliable mail service J. Sussman April 1974 ASCII HTML 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 HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0631 RFC0632 Throughput degradations for single packet messages H. Opderbeck May 1974 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0632 RFC0633 IMP/TIP preventive maintenance schedule A.M. McKenzie March 1974 ASCII HTML 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 HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0634 RFC0635 Assessment of ARPANET protocols V. Cerf April 1974 ASCII PDF HTML 1

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 HTML 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 HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0637 RFC0638 IMP/TIP preventive maintenance schedule A.M. McKenzie April 1974 ASCII HTML 4

Corrects RFC 633.

 RFC0633 UNKNOWN UNKNOWN Legacy 10.17487/RFC0638 RFC0639 RFC0640 Revised FTP reply codes J. Postel June 1974 ASCII HTML 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 HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0642 RFC0643 Network Debugging Protocol E. Mader July 1974 ASCII HTML 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 HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0644 RFC0645 Network Standard Data Specification syntax D. Crocker June 1974 ASCII PDF HTML 9

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 PDF HTML 20

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 HTML 2 RFC0859 UNKNOWN UNKNOWN Legacy 10.17487/RFC0651 RFC0652 Telnet output carriage-return disposition option D. Crocker October 1974 ASCII HTML 4 TOPT-OCRD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0652 RFC0653 Telnet output horizontal tabstops option D. Crocker October 1974 ASCII HTML 1 TOPT-OHT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0653 RFC0654 Telnet output horizontal tab disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OHTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0654 RFC0655 Telnet output formfeed disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OFD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0655 RFC0656 Telnet output vertical tabstops option D. Crocker October 1974 ASCII HTML 1 TOPT-OVT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0656 RFC0657 Telnet output vertical tab disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OVTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0657 RFC0658 Telnet output linefeed disposition D. Crocker October 1974 ASCII HTML 2 TOPT-OLD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0658 RFC0659 Announcing additional Telnet options J. Postel October 1974 ASCII HTML 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 HTML 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 PDF HTML 21

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 HTML 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 HTML 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 HTML 19

Discusses and proposes a common command language.

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

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 PDF HTML 3

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 PDF HTML 9

Experience with implementation in RSEXEC context.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0671 RFC0672 Multi-site data collection facility R. Schantz December 1974 ASCII HTML 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 HTML 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 HTML 70

The first detailed specification of TCP; see RFC 793.

 RFC7805 HISTORIC UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=675 10.17487/RFC0675 RFC0676 RFC0677 Maintenance of duplicate databases P.R. Johnson R. Thomas January 1975 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0677 RFC0678 Standard file formats J. Postel December 1974 ASCII HTML 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 PDF HTML 3

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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0688 RFC0689 Tenex NCP finite state machine for connections R. Clements May 1975 ASCII HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 36

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 HTML 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 PDF HTML 2

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 HTML 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 HTML 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 HTML 9 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0699 RFC0700 Protocol experiment E. Mader W.W. Plummer R.S. Tomlinson August 1974 ASCII HTML 7 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0700 RFC0701 August, 1974, survey of New-Protocol Telnet servers D.W. Dodds August 1974 ASCII HTML 1 RFC0702 UNKNOWN UNKNOWN Legacy 10.17487/RFC0701 RFC0702 September, 1974, survey of New-Protocol Telnet servers D.W. Dodds September 1974 ASCII HTML 3 RFC0701 RFC0669 UNKNOWN UNKNOWN Legacy 10.17487/RFC0702 RFC0703 July, 1975, survey of New-Protocol Telnet Servers D.W. Dodds July 1975 ASCII HTML 3 RFC0679 UNKNOWN UNKNOWN Legacy 10.17487/RFC0703 RFC0704 IMP/Host and Host/IMP Protocol change P.J. Santos September 1975 ASCII HTML 2 RFC0687 UNKNOWN UNKNOWN Legacy 10.17487/RFC0704 RFC0705 Front-end Protocol B6700 version R.F. Bryan November 1975 ASCII HTML 39 UNKNOWN UNKNOWN Legacy 10.17487/RFC0705 RFC0706 On the junk mail problem J. Postel November 1975 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0706 RFC0707 High-level framework for network-based resource sharing J.E. White December 1975 ASCII HTML 29 UNKNOWN UNKNOWN Legacy 10.17487/RFC0707 RFC0708 Elements of a Distributed Programming System J.E. White January 1976 ASCII HTML 30 UNKNOWN UNKNOWN Legacy 10.17487/RFC0708 RFC0709 RFC0710 RFC0711 RFC0712 Distributed Capability Computing System (DCCS) J.E. Donnelley February 1976 ASCII PDF HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0712 RFC0713 MSDTP-Message Services Data Transmission Protocol J. Haverty April 1976 ASCII HTML 21 UNKNOWN UNKNOWN Legacy 10.17487/RFC0713 RFC0714 Host-Host Protocol for an ARPANET-Type Network A.M. McKenzie April 1976 ASCII PDF HTML 22 UNKNOWN UNKNOWN Legacy 10.17487/RFC0714 RFC0715 RFC0716 Interim Revision to Appendix F of BBN 1822 D.C. Walden J. Levin May 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0716 RFC0717 Assigned Network Numbers J. Postel July 1976 ASCII HTML 1 HISTORIC UNKNOWN Legacy 10.17487/RFC0717 RFC0718 Comments on RCTE from the Tenex Implementation Experience J. Postel June 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0718 RFC0719 Discussion on RCTE J. Postel July 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0719 RFC0720 Address Specification Syntax for Network Mail D. Crocker August 1976 ASCII HTML 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 HTML 7 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0721 RFC0722 Thoughts on Interactions in Distributed Services J. Haverty September 1976 ASCII HTML 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 HTML 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 HTML 27 UNKNOWN UNKNOWN Legacy 10.17487/RFC0725 RFC0726 Remote Controlled Transmission and Echoing Telnet option J. Postel D. Crocker March 1977 ASCII HTML 16 TOPT-REM PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0726 RFC0727 Telnet logout option M.R. Crispin April 1977 ASCII HTML 3 TOPT-LOGO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0727 RFC0728 Minor pitfall in the Telnet Protocol J.D. Day April 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0728 RFC0729 Telnet byte macro option D. Crocker May 1977 ASCII HTML 3 RFC0735 UNKNOWN UNKNOWN Legacy 10.17487/RFC0729 RFC0730 Extensible field addressing J. Postel May 1977 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0730 RFC0731 Telnet Data Entry Terminal option J.D. Day June 1977 ASCII HTML 28 RFC0732 UNKNOWN UNKNOWN Legacy 10.17487/RFC0731 RFC0732 Telnet Data Entry Terminal option J.D. Day September 1977 ASCII HTML 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 HTML 38 RFC0724 RFC0822 UNKNOWN UNKNOWN Legacy 10.17487/RFC0733 RFC0734 SUPDUP Protocol M.R. Crispin October 1977 ASCII HTML 13 SUPDUP HISTORIC HISTORIC Legacy 10.17487/RFC0734 RFC0735 Revised Telnet byte macro option D. Crocker R.H. Gumpertz November 1977 ASCII HTML 5 TOPT-BYTE RFC0729 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0735 RFC0736 Telnet SUPDUP option M.R. Crispin October 1977 ASCII HTML 1 TOPT-SUP PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0736 RFC0737 FTP extension: XSEN K. Harrenstien October 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0737 RFC0738 Time server K. Harrenstien October 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0738 RFC0739 Assigned numbers J. Postel November 1977 ASCII HTML 11 RFC0604 RFC0503 RFC0750 HISTORIC UNKNOWN Legacy 10.17487/RFC0739 RFC0740 NETRJS Protocol R.T. Braden November 1977 ASCII HTML 19 NETRJS RFC0599 HISTORIC HISTORIC Legacy 10.17487/RFC0740 RFC0741 Specifications for the Network Voice Protocol (NVP) D. Cohen November 1977 ASCII HTML 34 UNKNOWN UNKNOWN Legacy 10.17487/RFC0741 RFC0742 NAME/FINGER Protocol K. Harrenstien December 1977 ASCII HTML 7 RFC1288 RFC1196 RFC1194 UNKNOWN UNKNOWN Legacy 10.17487/RFC0742 RFC0743 FTP extension: XRSQ/XRCP K. Harrenstien December 1977 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0743 RFC0744 MARS - a Message Archiving and Retrieval Service J. Sattley January 1978 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0744 RFC0745 JANUS interface specifications M. Beeler March 1978 ASCII HTML 10 JANUS interface specifications UNKNOWN UNKNOWN Legacy 10.17487/RFC0745 RFC0746 SUPDUP graphics extension R. Stallman March 1978 ASCII HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0746 RFC0747 Recent extensions to the SUPDUP Protocol M.R. Crispin March 1978 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0747 RFC0748 Telnet randomly-lose option M.R. Crispin April 1 1978 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0748 RFC0749 Telnet SUPDUP-Output option B. Greenberg September 1978 ASCII HTML 4 TOPT-SUPO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0749 RFC0750 Assigned numbers J. Postel September 1978 ASCII HTML 12 RFC0739 RFC0755 HISTORIC UNKNOWN Legacy 10.17487/RFC0750 RFC0751 Survey of FTP mail and MLFL P.D. Lebling December 1978 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0751 RFC0752 Universal host table M.R. Crispin January 1979 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0752 RFC0753 Internet Message Protocol J. Postel March 1979 ASCII HTML 62 UNKNOWN UNKNOWN Legacy 10.17487/RFC0753 RFC0754 Out-of-net host addresses for mail J. Postel April 1979 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0754 RFC0755 Assigned numbers J. Postel May 1979 ASCII HTML 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 HTML 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 HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0757 RFC0758 Assigned numbers J. Postel August 1979 ASCII HTML 12 RFC0755 RFC0762 HISTORIC UNKNOWN Legacy 10.17487/RFC0758 RFC0759 Internet Message Protocol J. Postel August 1980 ASCII HTML 77 MPM HISTORIC HISTORIC Legacy 10.17487/RFC0759 RFC0760 DoD standard Internet Protocol J. Postel January 1980 ASCII HTML 46 IEN123 RFC0791 RFC0777 UNKNOWN UNKNOWN Legacy 10.17487/RFC0760 RFC0761 DoD standard Transmission Control Protocol J. Postel January 1980 ASCII HTML 88 TCP RFC0793 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0761 RFC0762 Assigned numbers J. Postel January 1980 ASCII HTML 13 RFC0758 RFC0770 HISTORIC UNKNOWN Legacy 10.17487/RFC0762 RFC0763 Role mailboxes M.D. Abrams May 1980 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0763 RFC0764 Telnet Protocol specification J. Postel June 1980 ASCII HTML 15 RFC0854 UNKNOWN UNKNOWN Legacy 10.17487/RFC0764 RFC0765 File Transfer Protocol specification J. Postel June 1980 ASCII HTML 70 RFC0542 RFC0959 UNKNOWN UNKNOWN Legacy 10.17487/RFC0765 RFC0766 Internet Protocol Handbook: Table of contents J. Postel July 1980 ASCII HTML 2 RFC0774 UNKNOWN UNKNOWN Legacy 10.17487/RFC0766 RFC0767 Structured format for transmission of multi-media documents J. Postel August 1980 ASCII HTML 40 UNKNOWN UNKNOWN Legacy 10.17487/RFC0767 RFC0768 User Datagram Protocol J. Postel August 1980 ASCII HTML 3 UDP UDP STD0006 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0768 RFC0769 Rapicom 450 facsimile file format J. Postel September 1980 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0769 RFC0770 Assigned numbers J. Postel September 1980 ASCII HTML 15 RFC0762 RFC0776 HISTORIC UNKNOWN Legacy 10.17487/RFC0770 RFC0771 Mail transition plan V.G. Cerf J. Postel September 1980 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0771 RFC0772 Mail Transfer Protocol S. Sluizer J. Postel September 1980 ASCII HTML 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 HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0773 RFC0774 Internet Protocol Handbook: Table of contents J. Postel October 1980 ASCII HTML 3 RFC0766 UNKNOWN UNKNOWN Legacy 10.17487/RFC0774 RFC0775 Directory oriented FTP commands D. Mankins D. Franklin A.D. Owen December 1980 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0775 RFC0776 Assigned numbers J. Postel January 1981 ASCII HTML 13 RFC0770 RFC0790 HISTORIC UNKNOWN Legacy 10.17487/RFC0776 RFC0777 Internet Control Message Protocol J. Postel April 1981 ASCII HTML 14 RFC0792 RFC0760 UNKNOWN UNKNOWN Legacy 10.17487/RFC0777 RFC0778 DCNET Internet Clock Service D.L. Mills April 1981 ASCII HTML 4 CLOCK HISTORIC HISTORIC Legacy 10.17487/RFC0778 RFC0779 Telnet send-location option E. Killian April 1981 ASCII HTML 2 TOPT-SNDL PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0779 RFC0780 Mail Transfer Protocol S. Sluizer J. Postel May 1981 ASCII HTML 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 HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0781 RFC0782 Virtual Terminal management model J. Nabielsky A.P. Skelton January 1981 ASCII HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0782 RFC0783 TFTP Protocol (revision 2) K.R. Sollins June 1981 ASCII HTML 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 HTML 3 MTP email UNKNOWN UNKNOWN Legacy 10.17487/RFC0784 RFC0785 Mail Transfer Protocol: ISI TOPS20 file definitions S. Sluizer J. Postel July 1981 ASCII HTML 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 HTML 2 MTP NIMAIL TOPS20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0786 RFC0787 Connectionless data transmission survey/tutorial A.L. Chapin July 1981 ASCII HTML 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 HTML 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 HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0789 RFC0790 Assigned numbers J. Postel September 1981 ASCII HTML 15 RFC0776 RFC0820 HISTORIC UNKNOWN Legacy 10.17487/RFC0790 RFC0791 Internet Protocol J. Postel September 1981 ASCII HTML 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 HTML 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 HTML 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 HTML 2 IEN125 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0794 RFC0795 Service mappings J. Postel September 1981 ASCII HTML 4 HISTORIC UNKNOWN Legacy 10.17487/RFC0795 RFC0796 Address mappings J. Postel September 1981 ASCII HTML 7 IEN115 HISTORIC UNKNOWN Legacy 10.17487/RFC0796 RFC0797 Format for Bitmap files A.R. Katz September 1981 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0797 RFC0798 Decoding facsimile data from the Rapicom 450 A.R. Katz September 1981 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0798 RFC0799 Internet name domains D.L. Mills September 1981 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0799 RFC0800 Request For Comments summary notes: 700-799 J. Postel J. Vernon November 1982 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware D. Plummer November 1982 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=864 10.17487/RFC0864 RFC0865 Quote of the Day Protocol J. Postel May 1983 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 18 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0899 RFC0900 Assigned Numbers J.K. Reynolds J. Postel June 1984 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 Newman Laboratories July 1984 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 22 RFC0160 RFC1000 UNKNOWN UNKNOWN Legacy 10.17487/RFC0999 RFC1000 Request For Comments reference guide J.K. Reynolds J. Postel August 1987 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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. Distribution of this memo is unlimited.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1018 RFC1019 Report of the Workshop on Environments for Computational Mathematics D. Arnon September 1987 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8482 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 HTML 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 RFC8482 RFC8490 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1099 RFC1100 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1989 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 1 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 HTML 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 HTML 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 HTML 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 RFC8029 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 HTML 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 PS PDF HTML 1

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 PS PDF HTML 21

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 HTML 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 HTML 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 PS PDF HTML 1

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 PS PDF HTML 1 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 HTML 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 PS PDF HTML 1

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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 517 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 HTML 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 PS PDF HTML 49 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 HTML 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 HTML 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 PS PDF HTML 177

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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 18

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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS HTML 85 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 48

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 HTML 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 HTML 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 HTML 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 PS PDF HTML 17 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 12 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 PS PDF HTML 31 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 PS PDF HTML 189 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 3

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 PS HTML 17

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 PS HTML 12 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 PS HTML 7 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 PS PDF HTML 15 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS HTML 10 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1299 RFC1300 Remembrances of Things Past S. Greenfield February 1992 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 109 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 80 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 HTML 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 PS PDF HTML 10 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 PS PDF HTML 9 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 HTML 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 HTML 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 PS PDF HTML 8

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.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1347 RFC1348 DNS NSAP RRs B. Manning July 1992 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 12 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1399 RFC1400 Transition and Modernization of the Internet Registration Service S. Williamson March 1993 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 33 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=1438 10.17487/RFC1438 RFC1439 The Uniqueness of Unique Identifiers C. Finseth March 1993 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=1464 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=1498 10.17487/RFC1498 RFC1499 Summary of 1400-1499 J. Elliott January 1997 ASCII HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1499 RFC1500 Internet Official Protocol Standards J. Postel August 1993 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 81 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=1522 10.17487/RFC1522 RFC1523 The text/enriched MIME Content-type N. Borenstein September 1993 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=1557 10.17487/RFC1557 RFC1558 A String Representation of LDAP Search Filters T. Howes December 1993 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 16 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 216 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 PS PDF HTML 102 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1599 RFC1600 Internet Official Protocol Standards J. Postel March 1994 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=1606 10.17487/RFC1606 RFC1607 A VIEW FROM THE 21ST CENTURY V. Cerf April 1 1994 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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.

 HISTORIC INFORMATIONAL IETF int pip 10.17487/RFC1621 RFC1622 Pip Header Processing P. Francis May 1994 ASCII HTML 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.

 HISTORIC INFORMATIONAL IETF int pip 10.17487/RFC1622 RFC1623 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz May 1994 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 33 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 6 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 PS PDF HTML 14 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 12 TMUX Internet Protocol IP

One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1692 RFC1693 An Extension to TCP : Partial Order Service T. Connolly P. Amer P. Conrad November 1994 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1699 RFC1700 Assigned Numbers J. Reynolds J. Postel October 1994 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1707 RFC1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3 D. Gowin October 1994 ASCII HTML 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 PS PDF HTML 26 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 46 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8089 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1799 RFC1800 Internet Official Protocol Standards J. Postel Editor July 1995 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC EXPERIMENTAL IETF int st2 10.17487/RFC1819 RFC1820 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 6 encryption secure hash algorithm RFC2841 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1852 RFC1853 IP in IP Tunneling W. Simpson October 1995 ASCII HTML 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 HTML 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 HTML 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 HTML 17 tools performance utilization INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1856 RFC1857 A Model for Common Operational Statistics M. Lambert October 1995 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS HTML 21 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 HTML 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 HTML 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 HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1899 RFC1900 Renumbering Needs Work B. Carpenter Y. Rekhter February 1996 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=1912 10.17487/RFC1912 RFC1913 Architecture of the Whois++ Index Service C. Weider J. Fullton S. Spero February 1996 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8314 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 11 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 PS PDF HTML 17 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 PS PDF HTML 12 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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]

 RFC8201 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8642 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 HTML 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 HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1999 RFC2000 Internet Official Protocol Standards J. Postel Editor February 1997 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2006 10.17487/RFC2006 RFC2007 Catalogue of Network Training Materials J. Foster M. Isaacs M. Prior October 1996 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8179 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8098 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 21 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2099 RFC2100 The Naming of Hosts J. Ashworth April 1 1997 ASCII HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2100 10.17487/RFC2100 RFC2101 IPv4 Address Behaviour Today B. Carpenter J. Crowcroft Y. Rekhter February 1997 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8174 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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]

 RFC8141 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2199 RFC2200 Internet Official Protocol Standards J. Postel June 1997 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 10.17487/RFC2241 RFC2242 NetWare/IP Domain Name and Information R. Droms K. Fong November 1997 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2299 RFC2300 Internet Official Protocol Standards J. Postel May 1998 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8499 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2322 10.17487/RFC2322 RFC2323 IETF Identification and Security Guidelines A. Ramos April 1 1998 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8468 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2399 RFC2400 Internet Official Protocol Standards J. Postel J. Reynolds September 1998 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2428 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2452 RFC2453 RIP Version 2 G. Malkin November 1998 ASCII HTML 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 HTML 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 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2454 RFC2455 Definitions of Managed Objects for APPN B. Clouston B. Moore November 1998 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8200 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 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 HTML 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 RFC8096 HISTORIC 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 HTML 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 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2466 RFC2467 Transmission of IPv6 Packets over FDDI Networks M. Crawford December 1998 ASCII HTML 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 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2467 RFC2468 I REMEMBER IANA V. Cerf October 1998 ASCII HTML 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 HTML 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 HTML 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]

 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2470 RFC2471 IPv6 Testing Address Allocation R. Hinden R. Fink J. Postel December 1998 ASCII HTML 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 HTML 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 HTML 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 HTML 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 RFC8436 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2488 10.17487/RFC2488 RFC2489 Procedure for Defining New DHCP Options R. Droms January 1999 ASCII HTML 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 PS PDF HTML 31 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 HTML 44 IPv6-NBMA internet protocol routing host

This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]

 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2491 RFC2492 IPv6 over ATM Networks G. Armitage P. Schulter M. Jork January 1999 ASCII HTML 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]

 RFC8064 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 RFC1201 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2497 RFC2498 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson January 1999 ASCII HTML 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 HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2499 RFC2500 Internet Official Protocol Standards J. Reynolds R. Braden June 1999 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 Editor February 1999 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8314 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 HTML 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 HTML 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 HTML 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 HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2599 RFC2600 Internet Official Protocol Standards J. Reynolds R. Braden March 2000 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 176 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 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.

 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 HTML 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 PS PDF HTML 26 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 http://www.rfc-editor.org/errata_search.php?rfc=2638 10.17487/RFC2638 RFC2639 Internet Printing Protocol/1.0: Implementer's Guide T. Hastings C. Manros July 1999 ASCII HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2640 10.17487/RFC2640 RFC2641 Cabletron's VlanHello Protocol Specification Version 4 D. Hamilton D. Ruffen August 1999 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2662 10.17487/RFC2662 RFC2663 IP Network Address Translator (NAT) Terminology and Considerations P. Srisuresh M. Holdrege August 1999 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2694 10.17487/RFC2694 RFC2695 Authentication Mechanisms for ONC RPC A. Chiu September 1999 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2699 RFC2700 Internet Official Protocol Standards J. Reynolds R. Braden August 2000 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2712 10.17487/RFC2712 RFC2713 Schema for Representing Java(tm) Objects in an LDAP Directory V. Ryan S. Seligman R. Lee October 1999 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8088 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2799 RFC2800 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza May 2001 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8044 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8018 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 HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2899 RFC2900 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza August 2001 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=2962 10.17487/RFC2962 RFC2963 A Rate Adaptive Shaper for Differentiated Services O. Bonaventure S. De Cnodder October 2000 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2999 RFC3000 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza L. Shiota November 2001 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8254 HISTORIC INFORMATIONAL Legacy 10.17487/RFC3044 RFC3045 Storing Vendor Information in the LDAP root DSE M. Meredith January 2001 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3091 10.17487/RFC3091 RFC3092 Etymology of "Foo" D. Eastlake 3rd C. Manros E. Raymond April 1 2001 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 25 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3099 RFC3100 RFC3101 The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy January 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8277 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3146 RFC3147 Generic Routing Encapsulation over CLNS Networks P. Christian July 2001 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8044 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8311 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8254 HISTORIC INFORMATIONAL Legacy 10.17487/RFC3187 RFC3188 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2001 ASCII HTML 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 RFC8458 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3218 10.17487/RFC3218 RFC3219 Telephony Routing over IP (TRIP) J. Rosenberg H. Salama M. Squire January 2002 ASCII HTML 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 RFC8602 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8217 RFC8591 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 30 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 HTML 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 HTML 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 HTML 101 internet protocol parameters addresses draft-ietf-dhc-dhcpv6-28 RFC8415 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 22 privacy service draft-ietf-sip-privacy-general-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3323 10.17487/RFC3323 RFC3324 Short Term Requirements for Network Asserted Identity M. Watson November 2002 ASCII HTML 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 HTML 18 trust domain draft-ietf-sip-asserted-identity-01 RFC5876 RFC8217 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 HTML 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 RFC8606 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC3333 RFC3334 Policy-Based Accounting T. Zseby S. Zander C. Carle October 2002 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 18 gregorian calendar iso

This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.

 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 6 beep draft-mrose-beep-transientid-02 BCP0059 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3349 RFC3350 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3380 10.17487/RFC3380 RFC3381 Internet Printing Protocol (IPP): Job Progress Attributes T. Hastings H. Lewis R. Bergman September 2002 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC3399 RFC3400 RFC3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS M. Mealling October 2002 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8141 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8591 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8098 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8359 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 HTML 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 HTML 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 RFC8359 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 38 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3499 RFC3500 RFC3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 M. Crispin March 2003 ASCII HTML 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 RFC8314 RFC8437 RFC8474 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8217 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 HTML 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 IETF NON WORKING GROUP 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3534 RFC3535 Overview of the 2002 IAB Network Management Workshop J. Schoenwaelder May 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3540 RFC3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D) A. Walsh May 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PS PDF HTML 104 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 RFC8083 RFC8108 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 PS PDF HTML 44 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3563 RFC3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering F. Le Faucheur W. Lai July 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3572 RFC3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) I. Goyret July 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3587 10.17487/RFC3587 RFC3588 Diameter Base Protocol P. Calhoun J. Loughney E. Guttman G. Zorn J. Arkko September 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF ops opsawg 10.17487/RFC3595 RFC3596 DNS Extensions to Support IP Version 6 S. Thomson C. Huitema V. Ksinant M. Souissi October 2003 ASCII HTML 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 STD0088 INTERNET STANDARD DRAFT STANDARD IETF int dnsext 10.17487/RFC3596 RFC3597 Handling of Unknown DNS Resource Record (RR) Types A. Gustafsson September 2003 ASCII HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3598 RFC3599 Request for Comments Summary RFC Numbers 3500-3599 S. Ginoza December 2003 ASCII HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3601 RFC3602 The AES-CBC Cipher Algorithm and Its Use with IPsec S. Frankel R. Glenn S. Kelly September 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec idwg 10.17487/RFC3620 RFC3621 Power Ethernet MIB A. Berger D. Romascanu December 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3626 10.17487/RFC3626 RFC3627 Use of /127 Prefix Length Between Routers Considered Harmful P. Savola September 2003 ASCII HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3629 RFC3630 Traffic Engineering (TE) Extensions to OSPF Version 2 D. Katz K. Kompella D. Yeung September 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 RFC8415 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3641 RFC3642 Common Elements of Generic String Encoding Rules (GSER) Encodings S. Legg October 2003 ASCII HTML 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 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3642 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8622 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3662 RFC3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) A. Newton December 2003 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3671 RFC3672 Subentries in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 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 IETF NON WORKING GROUP 10.17487/RFC3672 RFC3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes K. Zeilenga December 2003 ASCII HTML 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 IETF NON WORKING GROUP 10.17487/RFC3673 RFC3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 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 IETF NON WORKING GROUP 10.17487/RFC3674 RFC3675 .sex Considered Dangerous D. Eastlake 3rd February 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3681 RFC3682 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer February 2004 ASCII HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3683 RFC3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) R. Ogier F. Templin M. Lewis February 2004 ASCII HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3685 RFC3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) R. Housley January 2004 ASCII HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3687 RFC3688 The IETF XML Registry M. Mealling January 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3698 RFC3699 RFC3700 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor July 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3716 10.17487/RFC3716 RFC3717 IP over Optical Networks: A Framework B. Rajagopalan J. Luciani D. Awduche March 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8415 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3743 10.17487/RFC3743 RFC3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol G. Clemm J. Reschke E. Sedlar J. Whitehead May 2004 ASCII HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3746 10.17487/RFC3746 RFC3747 The Differentiated Services Configuration MIB H. Hazewinkel Editor D. Partain Editor April 2004 ASCII HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3748 10.17487/RFC3748 RFC3749 Transport Layer Security Protocol Compression Methods S. Hollenbeck May 2004 ASCII HTML 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 RFC8447 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3771 RFC3772 Point-to-Point Protocol (PPP) Vendor Protocol J. Carlson R. Winslow May 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8118 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8098 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 RFC3799 RFC3800 RFC3801 Voice Profile for Internet Mail - version 2 (VPIMv2) G. Vaudreuil G. Parsons June 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF NON WORKING GROUP 10.17487/RFC3826 RFC3827 Additional Snoop Datalink Types K. Sarcar June 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 IETF rai simple 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 HTML 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 IETF rai simple 10.17487/RFC3857 RFC3858 An Extensible Markup Language (XML) Based Format for Watcher Information J. Rosenberg August 2004 ASCII HTML 13 Extensible Markup Language 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 IETF NON WORKING GROUP 10.17487/RFC3858 RFC3859 Common Profile for Presence (CPP) J. Peterson August 2004 ASCII HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3859 10.17487/RFC3859 RFC3860 Common Profile for Instant Messaging (CPIM) J. Peterson August 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 36 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8217 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC3899 RFC3900 RFC3901 DNS IPv6 Transport Operational Guidelines A. Durand J. Ihren September 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC3907 RFC3908 RFC3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation K. Zeilenga October 2004 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3947 10.17487/RFC3947 RFC3948 UDP Encapsulation of IPsec ESP Packets A. Huttunen B. Swander V. Volpe L. DiBurro M. Stenberg January 2005 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 RFC8429 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8067 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8179 RFC2026 RFC2028 RFC4879 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=3996 10.17487/RFC3996 RFC3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications T. Hastings Editor R. K. deBry H. Lewis March 2005 ASCII HTML 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 HTML 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 RFC3999 RFC4000 RFC4001 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder February 2005 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8506 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8198 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8044 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8271 RFC8537 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4099 RFC4100 RFC4101 Writing Protocol Models E. Rescorla IAB June 2005 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8062 RFC8129 RFC8429 RFC8553 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 HTML 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 RFC8062 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 25 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 51 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=4180 10.17487/RFC4180 RFC4181 Guidelines for Authors and Reviewers of MIB Documents C. Heard Editor September 2005 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=4194 10.17487/RFC4194 RFC4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum W. Kameyama October 2005 ASCII HTML 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 HTML 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 HTML 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 HTML 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 RFC4199 RFC4200 RFC4201 Link Bundling in MPLS Traffic Engineering (TE) K. Kompella Y. Rekhter L. Berger October 2005 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4232 RFC4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom January 2006 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8415 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8268 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 HTML 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 RFC8308 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 HTML 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 RFC8308 RFC8332 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 HTML 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 RFC8268 RFC8308 RFC8332 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 HTML 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 RFC8308 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8212 RFC8654 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=4290 10.17487/RFC4290 RFC4291 IP Version 6 Addressing Architecture R. Hinden S. Deering February 2006 ASCII HTML 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 RFC8064 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4299 RFC4300 RFC4301 Security Architecture for the Internet Protocol S. Kent K. Seo December 2005 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8247 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 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 HTML 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 HTML 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 HTML 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 RFC8311 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 HTML 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 RFC8311 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8029 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4387 RFC4388 Dynamic Host Configuration Protocol (DHCP) Leasequery R. Woundy K. Kinnear February 2006 ASCII HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4391 RFC4392 IP over InfiniBand (IPoIB) Architecture V. Kashyap April 2006 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4399 RFC4400 RFC4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) N. Williams February 2006 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8270 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4419 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 STD0089 INTERNET 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8077 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 HTML 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 RFC8469 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8119 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8224 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8203 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8422 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4499 RFC4500 RFC4501 Domain Name System Uniform Resource Identifiers S. Josefsson May 2006 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8217 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8062 RFC8636 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8122 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8108 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8622 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4599 RFC4600 RFC4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas August 2006 ASCII PDF HTML 150 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8143 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8545 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 HTML 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 RFC4658 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8447 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4699 RFC4700 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=4707 10.17487/RFC4707 RFC4708 CellML Media Type A. Miller October 2006 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8538 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4751 RFC4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism A. Melnikov Editor November 2006 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8395 RFC8614 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4799 RFC4800 RFC4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management T. Nadeau Editor A. Farrel Editor February 2007 ASCII HTML 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 Editor February 2007 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=4827 10.17487/RFC4827 RFC4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant S. Floyd E. Kohler April 2007 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8319 RFC8425 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8390 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8179 RFC3979 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8335 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4899 RFC4900 RFC4901 Protocol Extensions for Header Compression over MPLS J. Ash Editor J. Hand Editor A. Malis Editor June 2007 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4921 RFC4922 RFC4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network F. Baker P. Bose August 2007 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8066 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8591 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4989 RFC4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks K. Shiomoto R. Papneja R. Rabbat September 2007 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC4999 RFC5000 Internet Official Protocol Standards RFC Editor May 2008 ASCII HTML 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 HTML 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 HTML 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 RFC8217 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5019 10.17487/RFC5019 RFC5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute K. Zeilenga August 2007 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 42 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8314 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8446 RFC8447 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5099 RFC5100 RFC5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information B. Claise Editor January 2008 ASCII HTML 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 HTML 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 HTML 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 HTML 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 RFC8082 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5104 RFC5105 ENUM Validation Token Format Definition O. Lendl December 2007 ASCII HTML 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 HTML 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 HTML 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 RFC5108 RFC5109 RTP Payload Format for Generic Forward Error Correction A. Li Editor December 2007 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8064 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8559 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5199 RFC5200 RFC5201 Host Identity Protocol R. Moskowitz P. Nikander P. Jokela Editor T. Henderson April 2008 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5205 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 HTML 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 RFC8046 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8126 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5228 10.17487/RFC5228 RFC5229 Sieve Email Filtering: Variables Extension K. Homme January 2008 ASCII HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5229 10.17487/RFC5229 RFC5230 Sieve Email Filtering: Vacation Extension T. Showalter N. Freed Editor January 2008 ASCII HTML 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 RFC8580 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5232 10.17487/RFC5232 RFC5233 Sieve Email Filtering: Subaddress Extension K. Murchison January 2008 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8445 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 HTML 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 RFC8446 RFC4492 RFC5746 RFC5878 RFC6176 RFC7465 RFC7507 RFC7568 RFC7627 RFC7685 RFC7905 RFC7919 RFC8447 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8398 RFC8399 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8285 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 HTML 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 RFC8518 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 HTML 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 HTML 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 HTML 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 PROPOSED STANDARD INFORMATIONAL IETF sec tls 10.17487/RFC5289 RFC5290 Comments on the Usefulness of Simple Best-Effort Traffic S. Floyd M. Allman July 2008 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5299 RFC5300 RFC5301 Dynamic Hostname Exchange Mechanism for IS-IS D. McPherson N. Shen October 2008 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5309 10.17487/RFC5309 RFC5310 IS-IS Generic Cryptographic Authentication M. Bhatia V. Manral T. Li R. Atkinson R. White M. Fanto February 2009 ASCII HTML 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 HTML 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 RFC5312 RFC5313 RFC5314 RFC5315 RFC5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan December 2008 ASCII HTML 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 PDF HTML 10 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 HTML 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 RFC8217 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5318 10.17487/RFC5318 RFC5319 RFC5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL) F. Templin Editor February 2010 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8362 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8545 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 HTML 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 HTML 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 HTML 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 RFC8217 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8262 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5378 10.17487/RFC5378 RFC5379 Guidelines for Using the Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba February 2010 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5399 RFC5400 RFC5401 Multicast Negative-Acknowledgment (NACK) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2008 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8085 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5408 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5429 10.17487/RFC5429 RFC5430 Suite B Profile for Transport Layer Security (TLS) M. Salter E. Rescorla R. Housley March 2009 ASCII HTML 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 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5430 RFC5431 Diameter ITU-T Rw Policy Enforcement Interface Application D. Sun March 2009 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8580 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5435 RFC5436 Sieve Notification Mechanism: mailto B. Leiba M. Haardt January 2009 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8253 RFC8356 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8245 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5453 10.17487/RFC5453 RFC5454 Dual-Stack Mobile IPv4 G. Tsirtsis V. Park H. Soliman March 2009 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8358 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5499 RFC5500 RFC5501 Requirements for Multicast Support in Virtual Private LAN Services Y. Kamite Editor Y. Wada Y. Serbest T. Morin L. Fang March 2009 ASCII HTML 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 HTML 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 RFC8217 RFC8498 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8315 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5549 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8559 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5580 10.17487/RFC5580 RFC5581 The Camellia Cipher in OpenPGP D. Shaw June 2009 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 54 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 RFC5599 RFC5600 RFC5601 Pseudowire (PW) Management Information Base (MIB) T. Nadeau Editor D. Zelig Editor July 2009 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8262 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 HTML 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 RFC8311 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5646 10.17487/RFC5646 RFC5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol K. Igoe J. Solinas August 2009 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8353 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8178 RFC8434 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8166 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 HTML 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 RFC8267 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5699 RFC5700 RFC5701 IPv6 Address Specific BGP Extended Community Attribute Y. Rekhter November 2009 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8446 RFC8447 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8550 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 HTML 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 RFC8551 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8155 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8615 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 HTML 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 HTML 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 HTML 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 RFC8621 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5788 RFC5789 PATCH Method for HTTP L. Dusseault J. Snell March 2010 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5799 RFC5800 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5805 10.17487/RFC5805 RFC5806 Diversion Indication in SIP S. Levy M. Mohali Editor March 2010 ASCII HTML 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 HTML 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 HTML 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 RFC5809 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5817 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 HTML 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 HTML 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 HTML 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 RFC5821 RFC5822 RFC5823 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8362 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5869 10.17487/RFC5869 RFC5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI) A. Mayrhofer C. Spanring June 2010 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8447 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 HTML 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 HTML 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 RFC8562 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5884 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5896 10.17487/RFC5896 RFC5897 Identification of Communications Services in the Session Initiation Protocol (SIP) J. Rosenberg June 2010 ASCII HTML 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 HTML 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 RFC5899 RFC5900 RFC5901 Extensions to the IODEF-Document Class for Reporting Phishing P. Cain D. Jevans July 2010 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8573 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5926 10.17487/RFC5926 RFC5927 ICMP Attacks against TCP F. Gont July 2010 ASCII HTML 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 HTML 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 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC5928 RFC5929 Channel Bindings for TLS J. Altman N. Williams L. Zhu July 2010 ASCII HTML 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 HTML 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 HTML 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 RFC8146 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=5984 10.17487/RFC5984 RFC5985 HTTP-Enabled Location Delivery (HELD) M. Barnes Editor September 2010 ASCII HTML 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 HTML 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 HTML 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 RFC8187 HISTORIC PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5987 RFC5988 Web Linking M. Nottingham October 2010 ASCII HTML 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 RFC8288 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC5999 RFC6000 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8306 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6022 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6047 10.17487/RFC6047 RFC6048 Network News Transfer Protocol (NNTP) Additions to LIST Command J. Elie November 2010 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6052 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8446 RFC8449 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6083 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8407 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6099 RFC6100 RFC6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 A. Freier P. Karlton P. Kocher August 2011 ASCII HTML 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 RFC6102 RFC6103 RFC6104 Rogue IPv6 Router Advertisement Problem Statement T. Chown S. Venaas February 2011 ASCII HTML 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 HTML 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 HTML 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 RFC8106 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8062 RFC4120 RFC4121 RFC4556 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6152 10.17487/RFC6152 RFC6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery S. Das G. Bajko February 2011 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8044 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6176 10.17487/RFC6176 RFC6177 IPv6 Address Assignment to End Sites T. Narten G. Huston L. Roberts March 2011 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8314 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6199 RFC6200 RFC6201 Device Reset Characterization R. Asati C. Pignataro F. Calabria C. Olvera March 2011 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8359 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6218 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 127

Federal Information Processing Standard, FIPS

 draft-eastlake-sha2b-07 RFC4634 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6234 10.17487/RFC6234 RFC6235 IP Flow Anonymization Support E. Boschi B. Trammell May 2011 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 RFC8526 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6242 10.17487/RFC6242 RFC6243 With-defaults Capability for NETCONF A. Bierman B. Lengyel June 2011 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8066 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6299 RFC6300 RFC6301 A Survey of Mobility Support in the Internet Z. Zhu R. Wakikawa L. Zhang July 2011 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8139 RFC8249 RFC8361 RFC8377 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6330 10.17487/RFC6330 RFC6331 Moving DIGEST-MD5 to Historic A. Melnikov July 2011 ASCII HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6333 10.17487/RFC6333 RFC6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite D. Hankins T. Mrugalski August 2011 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8301 RFC8463 RFC8553 RFC8616 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 HTML 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 HTML 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 HTML 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 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6379 RFC6380 Suite B Profile for Internet Protocol Security (IPsec) K. Burgin M. Peck October 2011 ASCII HTML 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 HISTORIC 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6381 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6399 RFC6400 RFC6401 RSVP Extensions for Admission Priority F. Le Faucheur J. Polk K. Carlberg October 2011 ASCII HTML 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8314 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8029 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8504 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8139 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 HTML 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 HTML 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 HTML 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 RFC8262 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8307 RFC8441 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6458 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 HTML 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 HTML 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 HISTORIC 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6480 10.17487/RFC6480 RFC6481 A Profile for Resource Certificate Repository Structure G. Huston R. Loomans G. Michaelson February 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8209 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6499 RFC6500 RFC6501 Conference Information Data Model for Centralized Conferencing (XCON) O. Novo G. Camarillo D. Morgan J. Urpalainen March 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8534 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6515 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8447 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 HTML 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 HTML 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 RFC6523 RFC6524 RFC6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration R. Stewart M. Tuexen P. Lei February 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6531 10.17487/RFC6531 RFC6532 Internationalized Email Headers A. Yang S. Steele N. Freed February 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8341 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8305 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6558 10.17487/RFC6558 RFC6559 A Reliable Transport Mechanism for PIM D. Farinacci IJ. Wijnands S. Venaas M. Napierala March 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8044 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6572 RFC6573 The Item and Collection Link Relations M. Amundsen April 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6599 RFC6600 RFC6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks G. Ash Editor D. McDysan April 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6625 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6634 RFC6635 RFC Editor Model (Version 2) O. Kolkman Editor J. Halpern Editor IAB June 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6672 10.17487/RFC6672 RFC6673 Round-Trip Packet Loss Metrics A. Morton August 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8311 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 26 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6699 RFC6700 RFC6701 Sanctions Available for Application to Violators of IETF IPR Policy A. Farrel P. Resnick August 2012 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8251 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8077 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8252 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6750 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6761 10.17487/RFC6761 RFC6762 Multicast DNS S. Cheshire M. Krochmal February 2013 ASCII HTML 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 HTML 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 RFC8553 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8505 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6799 RFC6800 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8210 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 HTML 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 RFC8481 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8202 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8029 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 HTML 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 RFC8113 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8190 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6899 RFC6900 RFC6901 JavaScript Object Notation (JSON) Pointer P. Bryan Editor K. Zyp M. Nottingham Editor April 2013 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8624 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 HTML 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 HTML 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 HTML 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 PDF HTML 11

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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6956 10.17487/RFC6956 RFC6957 Duplicate Address Detection Proxy F. Costa J-M. Combes Editor X. Pougnard H. Li June 2013 ASCII HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=6960 10.17487/RFC6960 RFC6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension Y. Pettersen June 2013 ASCII HTML 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 RFC8446 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6966 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC6995 RFC6996 Autonomous System (AS) Reservation for Private Use J. Mitchell July 2013 ASCII HTML 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 HTML 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 HTML 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 RFC6999 RFC7000 RFC7001 Message Header Field for Indicating Message Authentication Status M. Kucherawy September 2013 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 22 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7050 10.17487/RFC7050 RFC7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix J. Korhonen Editor T. Savolainen Editor November 2013 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8415 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC7099 RFC7100 Retirement of the "Internet Official Protocol Standards" Summary Document P. Resnick December 2013 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7111 10.17487/RFC7111 RFC7112 Implications of Oversized IPv6 Header Chains F. Gont V. Manral R. Bonica January 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7115 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7121 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7126 10.17487/RFC7126 RFC7127 Characterization of Proposed Standards O. Kolkman S. Bradner S. Turner January 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7130 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8259 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7162 10.17487/RFC7162 RFC7163 URN for Country-Specific Emergency Services C. Holmberg I. Sedlacek March 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7170 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8564 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 HTML 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 HTML 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 RFC8139 RFC8249 RFC8377 RFC8564 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7182 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 RFC8616 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8343 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8615 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7232 10.17487/RFC7232 RFC7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests R. Fielding Editor Y. Lafon Editor J. Reschke Editor June 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7239 10.17487/RFC7239 RFC7240 Prefer Header for HTTP J. Snell June 2014 ASCII HTML 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 RFC8144 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7250 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 HTML 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 HTML 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 RFC8613 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7254 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8044 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7270 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 HTML 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 RFC8234 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8344 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7282 10.17487/RFC7282 RFC7283 Handling Unknown DHCPv6 Messages Y. Cui Q. Sun T. Lemon July 2014 ASCII HTML 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 RFC8415 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7283 RFC7284 The Profile URI Registry M. Lanthaler June 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8247 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7301 10.17487/RFC7301 RFC7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux July 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7307 10.17487/RFC7307 RFC7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) E. Osborne July 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8221 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7321 RFC7322 RFC Style Guide H. Flanagan S. Ginoza September 2014 ASCII HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7322 10.17487/RFC7322 RFC7323 TCP Extensions for High Performance D. Borman B. Braden V. Jacobson R. Scheffenegger Editor September 2014 ASCII HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7323 10.17487/RFC7323 RFC7324 Updates to MPLS Transport Profile Linear Protection E. Osborne July 2014 ASCII HTML 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 HTML 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 HTML 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 RFC7327 RFC7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML R. Gieben August 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8078 PROPOSED STANDARD 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 HTML 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 HTML 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 PDF HTML 32

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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7348 10.17487/RFC7348 RFC7349 LDP Hello Cryptographic Authentication L. Zheng M. Chen M. Bhatia August 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8317 RFC8338 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7385 RFC7386 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7405 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7408 10.17487/RFC7408 RFC7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization E. Haleplidis J. Halpern November 2014 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7421 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7426 10.17487/RFC7426 RFC7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) T. Kivinen J. Snyder January 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8584 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8318 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7464 10.17487/RFC7464 RFC7465 Prohibiting RC4 Cipher Suites A. Popov February 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8223 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7482 10.17487/RFC7482 RFC7483 JSON Responses for the Registration Data Access Protocol (RDAP) A. Newton S. Hollenbeck March 2015 ASCII HTML 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 HTML 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 RFC8521 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7484 10.17487/RFC7484 RFC7485 Inventory and Analysis of WHOIS Registration Objects L. Zhou N. Kong S. Shen S. Sheng A. Servin March 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8553 RFC8616 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7493 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7508 10.17487/RFC7508 RFC7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics R. Huang V. Singh May 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7519 10.17487/RFC7519 RFC7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) M. Miller May 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8534 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8587 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8029 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 HTML 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 HTML 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 RFC8439 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7542 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8415 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 HTML 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 RFC8537 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7552 10.17487/RFC7552 RFC7553 The Uniform Resource Identifier (URI) DNS Resource Record P. Faltstrom O. Kolkman June 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8264 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7567 10.17487/RFC7567 RFC7568 Deprecating Secure Sockets Layer Version 3.0 R. Barnes M. Thomson A. Pironti A. Langley June 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8534 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7585 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7593 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 HTML 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 HTML 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 RFC8615 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 HTML 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 HTML 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 HTML 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 RFC8539 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7599 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 HTML 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 HTML 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 RFC8601 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8265 PROPOSED STANDARD PROPOSED STANDARD IETF art precis 10.17487/RFC7613 RFC7614 Explicit Subscriptions for the REFER Method R. Sparks August 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7634 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7636 10.17487/RFC7636 RFC7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation P. Garg Editor Y. Wang Editor September 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8323 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7643 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7659 10.17487/RFC7659 RFC7660 Diameter Congestion and Filter Attributes L. Bertz S. Manning B. Hirschman October 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7664 10.17487/RFC7664 RFC7665 Service Function Chaining (SFC) Architecture J. Halpern Editor C. Pignataro Editor October 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7672 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8581 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7692 10.17487/RFC7692 RFC7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) M-J. Saarinen Editor J-P. Aumasson November 2015 ASCII HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7696 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8266 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7707 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7714 10.17487/RFC7714 RFC7715 Multipoint LDP (mLDP) Node Protection IJ. Wijnands Editor K. Raza A. Atlas J. Tantsura Q. Zhao January 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8499 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 HTML 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 IETF IESG 10.17487/RFC7720 RFC7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms A. Cooper F. Gont D. Thaler March 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7725 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7728 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7729 10.17487/RFC7729 RFC7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent January 2016 ASCII HTML 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 RFC8630 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7761 10.17487/RFC7761 RFC7762 Initial Assignment for the Content Security Policy Directives Registry M. West January 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8490 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7774 10.17487/RFC7774 RFC7775 IS-IS Route Preference for Extended IP and IPv6 Reachability L. Ginsberg S. Litkowski S. Previdi February 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8249 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8375 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7804 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7807 10.17487/RFC7807 RFC7808 Time Zone Data Distribution Service M. Douglass C. Daboo March 2016 ASCII HTML 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 HTML 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 HTML 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 RFC8570 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=7810 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8486 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7848 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7855 10.17487/RFC7855 RFC7856 Softwire Mesh Management Information Base (MIB) Y. Cui J. Dong P. Wu M. Xu A. Yla-Jaaski May 2016 ASCII HTML 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 HTML 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 HTML 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 RFC8310 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive http://www.rfc-editor.org/errata_search.php?rfc=7858 10.17487/RFC7858 RFC7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols C. Dearlove May 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 RFC8178 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7868 10.17487/RFC7868 RFC7869 The "vnc" URI Scheme D. Warden I. Iordanov May 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7880 10.17487/RFC7880 RFC7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS C. Pignataro D. Ward N. Akiya July 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7889 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 HTML 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 HTML 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 HTML 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 PDF HTML 27 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 HTML 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 HTML 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 RFC8525 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7900 RFC7901 CHAIN Query Requests in DNS P. Wouters June 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7905 10.17487/RFC7905 RFC7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes P. Timmel R. Housley S. Turner June 2016 ASCII HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7906 10.17487/RFC7906 RFC7907 RFC7908 Problem Definition and Classification of BGP Route Leaks K. Sriram D. Montgomery D. McPherson E. Osterweil B. Dickson June 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7914 10.17487/RFC7914 RFC7915 IP/ICMP Translation Algorithm C. Bao X. Li F. Baker T. Anderson F. Gont June 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8208 RFC8608 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7935 10.17487/RFC7935 RFC7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry T. Hardie July 2016 ASCII HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7938 10.17487/RFC7938 RFC7939 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres T. Clausen August 2016 ASCII HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7940 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7946 10.17487/RFC7946 RFC7947 Internet Exchange BGP Route Server E. Jasinska N. Hilliard R. Raszuk N. Bakker September 2016 ASCII HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7948 10.17487/RFC7948 RFC7949 OSPFv3 over IPv4 for IPv6 Transition I. Chen A. Lindem R. Atkinson August 2016 ASCII HTML 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 HTML 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 RFC8342 RFC8526 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7953 10.17487/RFC7953 RFC7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block L. Iannone D. Lewis D. Meyer V. Fuller September 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8323 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7970 10.17487/RFC7970 RFC7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations M. Stiemerling S. Kiesel M. Scharf H. Seidel S. Previdi October 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7976 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=7986 10.17487/RFC7986 RFC7987 IS-IS Minimum Remaining Lifetime L. Ginsberg P. Wells B. Decraene T. Przygienda H. Gredler October 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 PDF HTML 15 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=8006 10.17487/RFC8006 RFC8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers R. Murray B. Niven-Jenkins December 2016 ASCII HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=8007 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 HTML 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 HTML 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 HTML 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 STD0092 INTERNET 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 HTML 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 STD0092 INTERNET 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 HTML 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 RFC8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB) D. Joachimpillai J. Hadi Salim February 2017 ASCII HTML 25 ForCES Inter-FE

This document describes how to extend the Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (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.

 draft-ietf-forces-interfelfb-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8013 10.17487/RFC8013 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 HTML 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 HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=8017 10.17487/RFC8017 RFC8018 PKCS #5: Password-Based Cryptography Specification Version 2.1 K. Moriarty Editor B. Kaliski A. Rusch January 2017 ASCII HTML 40 password-based encryption password-based key derivation salt

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 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.

 draft-moriarty-pkcs5-v2dot1-04 RFC2898 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8018 10.17487/RFC8018 RFC8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks Y. Nir V. Smyslov November 2016 ASCII HTML 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 HTML 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 HTML 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 HTML 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 RFC8349 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 HTML 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 RFC8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures K. Kompella G. Swallow C. Pignataro Editor N. Kumar S. Aldrin M. Chen March 2017 ASCII HTML 78 MPLS echo request MPLS echo reply

This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.

This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.

 draft-ietf-mpls-rfc4379bis-09 RFC4379 RFC6424 RFC6829 RFC7537 RFC1122 RFC8611 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8029 10.17487/RFC8029 RFC8030 Generic Event Delivery Using HTTP Push M. Thomson E. Damaggio B. Raymor Editor December 2016 ASCII HTML 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 HTML 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 RFC8032 Edwards-Curve Digital Signature Algorithm (EdDSA) S. Josefsson I. Liusvaara January 2017 ASCII HTML 60 signature digital signature EdDSA

This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.

 draft-irtf-cfrg-eddsa-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8032 10.17487/RFC8032 RFC8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem R. Pan P. Natarajan F. Baker G. White February 2017 ASCII HTML 30 active queue management AQM

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 queuing 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.

 draft-ietf-aqm-pie-10 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm http://www.rfc-editor.org/errata_search.php?rfc=8033 10.17487/RFC8033 RFC8034 Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems G. White R. Pan February 2017 ASCII HTML 17 latency access network bufferbloat

Cable modems based on Data-Over-Cable Service Interface Specifications (DOCSIS) 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 AQM that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems.

 draft-ietf-aqm-docsis-pie-02 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC8034 RFC8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing C. Holmberg November 2016 ASCII HTML 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 HTML 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 RFC8037 CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) I. Liusvaara January 2017 ASCII HTML 14 Ed25519 Ed448 X25519 X448

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 JSON Object Signing and Encryption (JOSE).

 draft-ietf-jose-cfrg-curves-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=8037 10.17487/RFC8037 RFC8038 Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol P. Aitken Editor B. Claise S. B S C. McDowall J. Schoenwaelder May 2017 ASCII HTML 85 IPFIX MIB SNMP

This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.

Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.

 draft-ietf-ipfix-mib-variable-export-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8038 RFC8039 Multipath Time Synchronization A. Shpiner R. Tse C. Schelp T. Mizrahi December 2016 ASCII HTML 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 RFC8040 RESTCONF Protocol A. Bierman M. Bjorklund K. Watsen January 2017 ASCII HTML 137 YANG NETCONF REST HTTP

This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).

 draft-ietf-netconf-restconf-18 RFC8527 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8040 10.17487/RFC8040 RFC8041 Use Cases and Operational Experience with Multipath TCP O. Bonaventure C. Paasch G. Detal January 2017 ASCII HTML 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 HTML 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 HTML 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 RFC8044 Data Types in RADIUS A. DeKok January 2017 ASCII HTML 35

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 Types" 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 RFCs 2865, 3162, 4072, 6158, 6572, and 7268.

 draft-ietf-radext-datatypes-08 RFC2865 RFC3162 RFC4072 RFC6158 RFC6572 RFC7268 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC8044 RFC8045 RADIUS Extensions for IP Port Configuration and Reporting D. Cheng J. Korhonen M. Boucadair S. Sivakumar January 2017 ASCII HTML 43 address sharing address continuity CGN NAT IP assignment port assignment port control port accounting port set port range IP/Port Limit Provider Wi-Fi Port forwarding Internal port External port Port mapping

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 IP Flow Information Export (IPFIX) Information Element identifiers.

 draft-ietf-radext-ip-port-radius-ext-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=8045 10.17487/RFC8045 RFC8046 Host Mobility with the Host Identity Protocol T. Henderson Editor C. Vogt J. Arkko February 2017 ASCII HTML 37 hip multihoming extensions mobility extensions locator

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 (as specified in RFC 8047). This document obsoletes RFC 5206.

 draft-ietf-hip-rfc5206-bis-14 RFC5206 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8046 RFC8047 Host Multihoming with the Host Identity Protocol T. Henderson Editor C. Vogt J. Arkko February 2017 ASCII HTML 22 hip multihoming extensions mobility extensions locator

This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.

 draft-ietf-hip-multihoming-12 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8047 RFC8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre December 2016 ASCII HTML 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 RFC8049 YANG Data Model for L3VPN Service Delivery S. Litkowski L. Tomotaki K. Ogaki February 2017 ASCII HTML 157 YANG l3sm l3vpn service model

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. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.

 draft-ietf-l3sm-l3vpn-service-model-19 RFC8299 PROPOSED STANDARD PROPOSED STANDARD IETF ops l3sm 10.17487/RFC8049 RFC8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions C. Petrie T. King May 2017 ASCII HTML 6

This document extends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by supporting the advertisement of multiple paths in BGP extensions.

 draft-ietf-grow-mrt-add-paths-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8050 RFC8051 Applicability of a Stateful Path Computation Element (PCE) X. Zhang Editor I. Minei Editor January 2017 ASCII HTML 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 RFC8052 Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services B. Weis M. Seewald H. Falk June 2017 ASCII HTML 25

The IEC 61850 power utility automation family of standards describes 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.

 draft-weis-gdoi-iec62351-9-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8052 RFC8053 HTTP Authentication Extensions for Interactive Clients Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku January 2017 ASCII HTML 28

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 such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. 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.

 draft-ietf-httpauth-extension-09 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8053 RFC8054 Network News Transfer Protocol (NNTP) Extension for Compression K. Murchison J. Elie January 2017 ASCII HTML 23 NNTP Usenet NetNews COMPRESS DEFLATE compression

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.

 draft-murchison-nntp-compress-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8054 RFC8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm C. Holmberg Y. Jiang January 2017 ASCII HTML 13 SIP Via transit realm

This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.

 draft-holmberg-dispatch-received-realm-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8055 RFC8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping J. Gould January 2017 ASCII HTML 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 HTML 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 HTML 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 http://www.rfc-editor.org/errata_search.php?rfc=8058 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 HTML 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 RFC8060 LISP Canonical Address Format (LCAF) D. Farinacci D. Meyer J. Snijders February 2017 ASCII HTML 36 Locator/ID Separation Protocol

This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.

 draft-ietf-lisp-lcaf-22 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8060 RFC8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality D. Farinacci B. Weis February 2017 ASCII HTML 18 lcaf

This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). 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.

 draft-ietf-lisp-crypto-10 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8061 RFC8062 Anonymity Support for Kerberos L. Zhu P. Leach S. Hartman S. Emery Editor February 2017 ASCII HTML 18

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.

 draft-ietf-kitten-rfc6112bis-03 RFC6112 RFC4120 RFC4121 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8062 RFC8063 Key Relay Mapping for the Extensible Provisioning Protocol H.W. Ribbers M.W. Groeneweg R. Gieben A.L.J. Verschuren February 2017 ASCII HTML 16 Extensible Provisioning Protocol

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 RFC 5730.

This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.

 draft-ietf-eppext-keyrelay-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8063 RFC8064 Recommendation on Stable IPv6 Interface Identifiers F. Gont A. Cooper D. Thaler W. Liu February 2017 ASCII HTML 9

This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.

 draft-ietf-6man-default-iids-16 RFC2464 RFC2467 RFC2470 RFC2491 RFC2492 RFC2497 RFC2590 RFC3146 RFC3572 RFC4291 RFC4338 RFC4391 RFC5072 RFC5121 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8064 RFC8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms D. Thaler February 2017 ASCII HTML 10

This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.

 draft-ietf-6lo-privacy-considerations-04 INFORMATIONAL INFORMATIONAL IETF int 6lo 10.17487/RFC8065 RFC8066 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines S. Chakrabarti G. Montenegro R. Droms J. Woodyatt February 2017 ASCII HTML 9

RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document.

 draft-ietf-6lo-dispatch-iana-registry-07 RFC4944 RFC6282 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8066 RFC8067 Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level B. Leiba January 2017 ASCII HTML 3 downref maturity last call

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.

 draft-leiba-3967upd-downref-03 RFC3967 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8067 RFC8068 Session Initiation Protocol (SIP) Recording Call Flows R. Ravindranath P. Ravindran P. Kyzivat February 2017 ASCII HTML 34 sipreq

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).

 draft-ietf-siprec-callflows-08 INFORMATIONAL INFORMATIONAL IETF art siprec 10.17487/RFC8068 RFC8069 URN Namespace for IEEE A. Thomas February 2017 ASCII HTML 6

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.

 draft-ieee-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8069 RFC8070 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension M. Short Editor S. Moore P. Miller February 2017 ASCII HTML 9

This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange.

 draft-ietf-kitten-pkinit-freshness-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8070 RFC8071 NETCONF Call Home and RESTCONF Call Home K. Watsen February 2017 ASCII HTML 13 call-home

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.

 draft-ietf-netconf-call-home-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8071 RFC8072 YANG Patch Media Type A. Bierman M. Bjorklund K. Watsen February 2017 ASCII HTML 39 RESTCONF

This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.

 draft-ietf-netconf-yang-patch-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8072 10.17487/RFC8072 RFC8073 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report K. Moriarty M. Ford March 2017 ASCII HTML 16

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.

 draft-iab-carisreport-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8073 RFC8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario J. Bi G. Yao J. Halpern E. Levy-Abegnoli Editor February 2017 ASCII HTML 12 SAVI-DHCP FCFS SAVI SEND SAVI

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 how collisions are resolved when the same binding entry is discovered by two or more methods.

 draft-ietf-savi-mix-15 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC8074 RFC8075 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) A. Castellani S. Loreto A. Rahman T. Fossati E. Dijk February 2017 ASCII HTML 40 CoAP HTTP-CoAP mapping HTTP-CoAP translation proxy implementation

This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). 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 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.

 draft-ietf-core-http-mapping-17 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8075 RFC8076 A Usage for Shared Resources in RELOAD (ShaRe) A. Knauf T. Schmidt Editor G. Hege M. Waehlisch March 2017 ASCII HTML 22 P2PSIP SIP Conferencing Voice over IP Peer-to-Peer Access Control Group Management Rendezvous

This document defines a REsource LOcation And Discovery (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 that is useful whenever peer-independent rendezvous processes are required.

 draft-ietf-p2psip-share-10 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC8076 RFC8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) L. Martini Editor G. Heron Editor February 2017 ASCII HTML 35

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 (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and 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 other documents.

This document is a rewrite of RFC 4447 for publication as an Internet Standard.

 draft-ietf-pals-rfc4447bis-05 RFC4447 RFC6723 STD0084 INTERNET STANDARD INTERNET STANDARD IETF rtg pals http://www.rfc-editor.org/errata_search.php?rfc=8077 10.17487/RFC8077 RFC8078 Managing DS Records from the Parent via CDS/CDNSKEY O. Gudmundsson P. Wouters March 2017 ASCII HTML 10 dnssec trust maintenance

RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a 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 a 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.

 draft-ietf-dnsop-maintain-ds-06 RFC7344 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8078 10.17487/RFC8078 RFC8079 Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs) L. Miniero S. Garcia Murillo V. Pascual February 2017 ASCII HTML 16

SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol (RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, 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 acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.

 draft-ietf-straw-b2bua-rtcp-17 PROPOSED STANDARD PROPOSED STANDARD IETF art straw 10.17487/RFC8079 RFC8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC O. Sury R. Edmonds February 2017 ASCII HTML 7 DNSSEC EdDSA ed25519 ed448

This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448.

 draft-ietf-curdle-dnskey-eddsa-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8080 10.17487/RFC8080 RFC8081 The "font" Top-Level Media Type C. Lilley February 2017 ASCII HTML 18 Internet Media Types MIME

This memo serves to register and document the "font" top-level media type, under which 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.

 draft-ietf-justfont-toplevel-06 PROPOSED STANDARD PROPOSED STANDARD IETF art justfont 10.17487/RFC8081 RFC8082 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs S. Wenger J. Lennox B. Burman M. Westerlund March 2017 ASCII HTML 11 Layered Codec Full Intra Request FIR Decoder Refresh Point

This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description 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 of 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 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.

 draft-ietf-avtext-avpf-ccm-layered-04 RFC5104 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC8082 RFC8083 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions C. Perkins V. Singh March 2017 ASCII HTML 25

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 by 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.

 draft-ietf-avtcore-rtp-circuit-breakers-18 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8083 RFC8084 Network Transport Circuit Breakers G. Fairhurst March 2017 ASCII HTML 24 Congestion control CC UDP Tunnel Encapsulation Transport Protocol Congestion Control

This document explains what is meant by the term "network transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.

 draft-ietf-tsvwg-circuit-breaker-15 BCP0208 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC8084 RFC8085 UDP Usage Guidelines L. Eggert G. Fairhurst G. Shepherd March 2017 ASCII HTML 55 UDP guidelines

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 Explicit Congestion Notification (ECN), Differentiated Services Code Points (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 RFC 5405 and adds guidelines for multicast UDP usage.

 draft-ietf-tsvwg-rfc5405bis-19 RFC5405 BCP0145 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC8085 RFC8086 GRE-in-UDP Encapsulation L. Yong Editor E. Crabbe X. Xu T. Herbert March 2017 ASCII HTML 27

This document specifies a method of encapsulating network protocol packets 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 Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.

 draft-ietf-tsvwg-gre-in-udp-encap-19 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=8086 10.17487/RFC8086 RFC8087 The Benefits of Using Explicit Congestion Notification (ECN) G. Fairhurst M. Welzl March 2017 ASCII HTML 19 ecn aqm sctp tcp

The goal of this document is to describe the potential benefits of applications using 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.

 draft-ietf-aqm-ecn-benefits-08 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC8087 RFC8088 How to Write an RTP Payload Format M. Westerlund May 2017 ASCII HTML 65 RTP Payload format Process

This document contains information on how best to 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.

 draft-ietf-payload-rtp-howto-14 RFC2736 INFORMATIONAL INFORMATIONAL IETF art payload 10.17487/RFC8088 RFC8089 The "file" URI Scheme M. Kerwin February 2017 ASCII HTML 19 uniform resource identifier URL

This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.

It defines a common syntax that 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.

 draft-ietf-appsawg-file-scheme-16 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC8089 RFC8090 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) R. Housley February 2017 ASCII HTML 7

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.

 draft-iab-ccg-appoint-process-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8090 RFC8091 A Media Type Structured Syntax Suffix for JSON Text Sequences E. Wilde February 2017 ASCII HTML 5

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.

 draft-wilde-json-seq-suffix-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8091 RFC8092 BGP Large Communities Attribute J. Heitz Editor J. Snijders Editor K. Patel I. Bagdonas N. Hilliard February 2017 ASCII HTML 8 BGP large communities four-octet

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 (ASNs) including four-octet ASNs.

 draft-ietf-idr-large-community-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=8092 10.17487/RFC8092 RFC8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 J. Snijders February 2017 ASCII HTML 3

This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as "Deprecated".

 draft-ietf-idr-deprecate-30-31-129-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8093 RFC8094 DNS over Datagram Transport Layer Security (DTLS) T. Reddy D. Wing P. Patil February 2017 ASCII HTML 13

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 the DTLS handshake size. The proposed mechanism runs over port 853.

 draft-ietf-dprive-dnsodtls-15 EXPERIMENTAL EXPERIMENTAL IETF int dprive 10.17487/RFC8094 RFC8095 Services Provided by IETF Transport Protocols and Congestion Control Mechanisms G. Fairhurst Editor B. Trammell Editor M. Kuehlewind Editor March 2017 ASCII HTML 54 Transmission Control Protocol (TCP) Multipath TCP (MPTCP) Stream Control Transmission Protocol (SCTP) User Datagram Protocol (UDP) UDP-Lite Datagram Congestion Control Protocol (DCCP) Internet Control Message Protocol (ICMP) Real-Time Transport Protocol (RTP) File Delivery over Unidirectional Transport/Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast NACK-Oriented Reliable Multicast (NORM) Transport Layer Security (TLS) Datagram TLS (DTLS) Hypertext Transport Protocol (HTTP) TAPS

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 Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, 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.

 draft-ietf-taps-transports-14 INFORMATIONAL INFORMATIONAL IETF tsv taps http://www.rfc-editor.org/errata_search.php?rfc=8095 10.17487/RFC8095 RFC8096 The IPv6-Specific MIB Modules Are Obsolete B. Fenner April 2017 ASCII HTML 65

In 2005-2006, 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. This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic.

 draft-ietf-6man-ipv6-mibs-obsolete-02 RFC2452 RFC2454 RFC2465 RFC2466 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC8096 RFC8097 BGP Prefix Origin Validation State Extended Community P. Mohapatra K. Patel J. Scudder D. Ward R. Bush March 2017 ASCII HTML 6

This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process.

 draft-ietf-sidr-origin-validation-signaling-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8097 RFC8098 Message Disposition Notification T. Hansen Editor A. Melnikov Editor February 2017 ASCII HTML 37 delivery notification mdn

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 are 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 multiprotocol 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 is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement).

 draft-ietf-appsawg-mdn-3798bis-16 RFC3798 RFC2046 RFC3461 STD0085 INTERNET STANDARD INTERNET STANDARD IETF art appsawg 10.17487/RFC8098 RFC8099 OSPF Topology-Transparent Zone H. Chen R. Li A. Retana Y. Yang Z. Liu February 2017 ASCII HTML 27 IGP OSPF TTZ

This document presents a Topology-Transparent Zone (TTZ) in an OSPF area. A TTZ 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.

 draft-ietf-ospf-ttz-06 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC8099 RFC8100 Diffserv-Interconnection Classes and Practice R. Geib Editor D. Black March 2017 ASCII HTML 21 Diffserv Interconnection PHB Treatment Aggregate MPLS Short Pipe

This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol 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 Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.

 draft-ietf-tsvwg-diffserv-intercon-14 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC8100 RFC8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service C. Holmberg J. Axell March 2017 ASCII HTML 6 Resource-Priority namespace Resource-priorith 3GPP IMS MCPTT

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the 3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.

 draft-holmberg-dispatch-mcptt-rp-namespace-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8101 RFC8102 Remote-LFA Node Protection and Manageability P. Sarkar Editor S. Hegde C. Bowers H. Gredler S. Litkowski March 2017 ASCII HTML 22 LFA Remote-LFA IGP Node Protection

The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (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 specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.

 draft-ietf-rtgwg-rlfa-node-protection-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8102 RFC8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) R. Housley February 2017 ASCII HTML 9

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.

 draft-ietf-curdle-cms-chacha20-poly1305-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8103 10.17487/RFC8103 RFC8104 Pseudowire (PW) Endpoint Fast Failure Protection Y. Shen R. Aggarwal W. Henderickx Y. Jiang March 2017 ASCII HTML 43 pseudowire PW protection local repair fast reroute

This document specifies a fast mechanism for protecting pseudowires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.

 draft-ietf-pals-endpoint-fast-protection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8104 RFC8105 Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) P. Mariager J. Petersen Editor Z. Shelby M. Van de Logt D. Barthel May 2017 ASCII HTML 22 6LoWPAN ETSI IoT and Internet of Things

Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.

The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.

DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.

This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.

 draft-ietf-6lo-dect-ule-09 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8105 RFC8106 IPv6 Router Advertisement Options for DNS Configuration J. Jeong S. Park L. Beloeil S. Madanapalli March 2017 ASCII HTML 19 DNS Service DNS Option Recursive DNS Server Address DNS Search List Stateless Autoconfiguration

This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.

This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.

 draft-ietf-6man-rdnss-rfc6106bis-16 RFC6106 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8106 RFC8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition J. Wold March 2017 ASCII HTML 7

Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) "adid" for Ad-IDs.

 draft-adid-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8107 RFC8108 Sending Multiple RTP Streams in a Single RTP Session J. Lennox M. Westerlund Q. Wu C. Perkins March 2017 ASCII HTML 29

This memo expands and clarifies the behavior 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 regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.

 draft-ietf-avtcore-rtp-multi-stream-11 RFC3550 RFC4585 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8108 RFC8109 Initializing a DNS Resolver with Priming Queries P. Koch M. Larson P. Hoffman March 2017 ASCII HTML 7

This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers.

 draft-ietf-dnsop-resolver-priming-11 BCP0209 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8109 RFC8110 Opportunistic Wireless Encryption D. Harkins Editor W. Kumari Editor March 2017 ASCII HTML 12 opportunistic encryption wireless

This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.

 draft-harkins-owe-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8110 10.17487/RFC8110 RFC8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) V. Fuller D. Lewis V. Ermagan A. Jain A. Smirnov May 2017 ASCII HTML 44 LISP DDT EID Locator Mapping System Map-Server Map-Referral Referral

This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.

 draft-ietf-lisp-ddt-09 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8111 RFC8112 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG) D. Farinacci A. Jain I. Kouvelas D. Lewis May 2017 ASCII HTML 11

A simple tool called the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP- DDT hierarchy. This document describes how the "rig" tool works.

 draft-farinacci-lisp-rig-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8112 RFC8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations M. Boucadair C. Jacquenet March 2017 ASCII HTML 6 Shared Experiment Code LISP codepoints Experiment Identifier Experiment ID LISP Experimental Registry LISP Extension Extending LISP

This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.

 draft-ietf-lisp-type-iana-06 RFC6830 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8113 RFC8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network M. Boucadair C. Qin C. Jacquenet Y. Lee Q. Wang March 2017 ASCII HTML 23 Multicast DS-Lite IPv4-IPv6 Interconnection PREFIX64 SSM ASM IPv4 service continuity Multicast service continuity IPv6-only IPv6-only multicast PIM MLD IGMP A+P MAP MAP-E address-sharing CGN NAT64 IPv4 over IPv6 IPv6 Address Synthesis Any-Source Multicast Source-Specific Multicast

This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite).

 draft-ietf-softwire-dslite-multicast-18 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8114 RFC8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes M. Boucadair J. Qin T. Tsou X. Deng March 2017 ASCII HTML 9 PREFIX64 SSM ASM Prefix Discovery IPv4-Converted IPv6 Addresses IPv4 service continuity IPv6 Address Synthesis Any-Source Multicast Source-Specific Multicast PIM IPv4-IPv6 interconnection IPv4 over IPv6 A+P MAP MAP-E address-sharing CGN NAT64

This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.

 draft-ietf-softwire-multicast-prefix-option-15 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8115 RFC8116 Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) T. Clausen U. Herberg J. Yi May 2017 ASCII HTML 26 MANET

This document analyzes common security threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated.

 draft-ietf-manet-olsrv2-sec-threats-04 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC8116 RFC8117 Current Hostname Practice Considered Harmful C. Huitema D. Thaler R. Winter March 2017 ASCII HTML 12

Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.

There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.

 draft-ietf-intarea-hostname-practice-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC8117 RFC8118 The application/pdf Media Type M. Hardy L. Masinter D. Markovic D. Johnson M. Bailey March 2017 ASCII HTML 12 Portable Document Format MIME type

The Portable Document Format (PDF) is an ISO standard (ISO 32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993. This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778.

 draft-hardy-pdf-mime-05 RFC3778 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8118 RFC8119 SIP "cause" URI Parameter for Service Number Translation M. Mohali M. Barnes March 2017 ASCII HTML 12 Cause

RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document updates RFC 4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.

 draft-mohali-dispatch-cause-for-service-number-14 RFC4458 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8119 RFC8120 Mutual Authentication Protocol for HTTP Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku April 2017 ASCII HTML 53 HTTP authentication

This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. 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.

 draft-ietf-httpauth-mutual-11 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8120 RFC8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3) Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku April 2017 ASCII HTML 17 HTTP authentication

This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).

 draft-ietf-httpauth-mutual-algo-07 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8121 RFC8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) J. Lennox C. Holmberg March 2017 ASCII HTML 18 SDP TLS Fingerprint Offer Answer

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 the 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 obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.

 draft-ietf-mmusic-4572-update-13 RFC4572 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic http://www.rfc-editor.org/errata_search.php?rfc=8122 10.17487/RFC8122 RFC8123 Requirements for Marking SIP Messages to be Logged P. Dawes C. Arunachalam March 2017 ASCII HTML 11 logme troubleshooting debug logging

SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.

This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.

 draft-ietf-insipid-logme-reqs-12 INFORMATIONAL INFORMATIONAL IETF art insipid 10.17487/RFC8123 RFC8124 The Session Description Protocol (SDP) WebSocket Connection URI Attribute R. Ravindranath G. Salgueiro March 2017 ASCII HTML 12 Secure WebSocket Uniform Resource Identifier

The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.

 draft-ietf-bfcpbis-sdp-ws-uri-09 PROPOSED STANDARD PROPOSED STANDARD IETF art bfcpbis 10.17487/RFC8124 RFC8125 Requirements for Password-Authenticated Key Agreement (PAKE) Schemes J. Schmidt April 2017 ASCII HTML 10 Password Key Agreement Password-Authenticated Key Agreement Cryptographic Protocol

Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-pake-reqs-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8125 RFC8126 Guidelines for Writing an IANA Considerations Section in RFCs M. Cotton B. Leiba T. Narten June 2017 ASCII HTML 47 internet assigned numbers authority values implementations code point protocol constant protocol parameter codepoint

Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).

To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.

This is the third edition of this document; it obsoletes RFC 5226.

 draft-leiba-cotton-iana-5226bis-20 RFC5226 BCP0026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8126 10.17487/RFC8126 RFC8127 Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor D. Patki S. Gundavelli J. Lee Q. Fu L. Bertz August 2017 ASCII HTML 14 Binding Refresh Heartbeat

This specification defines a new extension, LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters.

 draft-ietf-dmm-lma-controlled-mag-params-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8127 RFC8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee C. Morgan March 2017 ASCII HTML 5

This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).

 draft-iab-rzerc-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8128 RFC8129 Authentication Indicator in Kerberos Tickets A. Jain N. Kinder N. McCallum March 2017 ASCII HTML 6

This document updates RFC 4120, as it specifies an extension in the Kerberos protocol. It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.

 draft-ietf-kitten-krb-auth-indicator-07 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8129 RFC8130 RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec V. Demjanenko D. Satterlee March 2017 ASCII HTML 30 MELP MELPe MELP2400 MELP1200 MELP600 SCIP-210 SCIP210

This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frame sizes are supported. Comfort noise procedures and packet loss concealment are described in detail.

 draft-ietf-payload-melpe-06 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC8130 RFC8131 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing X. Zhang H. Zheng Editor R. Gandhi Editor Z. Ali P. Brzozowski March 2017 ASCII HTML 15 Association Object LSP Reversion LSP Recovery GMPLS Make-Before-Break GMPLS 1+R GMPLS 1+1+R

In non-packet transport networks, there are requirements where the Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.

This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.

 draft-ietf-teas-gmpls-resource-sharing-proc-08 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8131 RFC8132 PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) P. van der Stok C. Bormann A. Sehgal April 2017 ASCII HTML 21 CoAP

The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.

This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.

 draft-ietf-core-etch-04 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8132 RFC8133 The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol S. Smyshlyaev. Ed. E. Alekseev I. Oshkin V. Popov March 2017 ASCII HTML 51 cryptography secure channel elliptic curve

This document describes the Security Evaluated Standardized Password- Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information. The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects.

 draft-smyshlyaev-sespake-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8133 RFC8134 Management Incident Lightweight Exchange (MILE) Implementation Report C. Inacio D. Miyamoto May 2017 ASCII HTML 16 IODEF RID SCI INCH MILE Implementation

This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups.

 draft-ietf-mile-implementreport-10 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC8134 RFC8135 Complex Addressing in IPv6 M. Danielson M. Nilsson April 1 2017 ASCII HTML 16

The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges.

 draft-danielson-complexaddress-latest-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8135 10.17487/RFC8135 RFC8136 Additional Transition Functionality for IPv6 B. Carpenter R. Hinden April 1 2017 ASCII HTML 7

This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.

 draft-carpenter-addtransfunc-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8136 RFC8137 IEEE 802.15.4 Information Element for the IETF T. Kivinen P. Kinney May 2017 ASCII HTML 7 IE

IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes.

 draft-kivinen-802-15-ie-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8137 RFC8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header P. Thubert Editor C. Bormann L. Toutain R. Cragie April 2017 ASCII HTML 37

This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.

 draft-ietf-roll-routing-dispatch-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=8138 10.17487/RFC8138 RFC8139 Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders D. Eastlake 3rd Y. Li M. Umair A. Banerjee F. Hu June 2017 ASCII HTML 41 DRB VLAN mapping inhibition port shutdown trill TRansparent Interconnection of Lots of Links

TRILL (Transparent Interconnection of Lots of Links) supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439.

 draft-ietf-trill-rfc6439bis-05 RFC6439 RFC6325 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8139 RFC8140 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character A. Farrel April 1 2017 ASCII HTML 16

Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.

Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International Trade Mark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".

This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.

 draft-farrel-ascii-art-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8140 10.17487/RFC8140 RFC8141 Uniform Resource Names (URNs) P. Saint-Andre J. Klensin April 2017 ASCII HTML 40 Uniform Resource Name URN Uniform Resource Identifier URI

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.

 draft-ietf-urnbis-rfc2141bis-urn-22 RFC2141 RFC3406 PROPOSED STANDARD PROPOSED STANDARD IETF art urnbis 10.17487/RFC8141 RFC8142 GeoJSON Text Sequences S. Gillies April 2017 ASCII HTML 5 JSON Geospatial JavaScript Object Notation

This document describes the GeoJSON text sequence format and "application/geo+json-seq" media type. This format is based on JavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence.

 draft-ietf-geojson-text-sequence-05 PROPOSED STANDARD PROPOSED STANDARD IETF art geojson 10.17487/RFC8142 RFC8143 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) J. Elie April 2017 ASCII HTML 13 NNTP Usenet NetNews TLS STARTTLS

This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642.

 draft-elie-nntp-tls-recommendations-05 RFC4642 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8143 RFC8144 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) K. Murchison April 2017 ASCII HTML 28 http prefer webav caldav

This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth-noroot" preference.

 draft-murchison-webdav-prefer-14 RFC7240 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8144 RFC8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) D. Wessels W. Kumari P. Hoffman April 2017 ASCII HTML 13 DNS DNSSEC Trust Anchor

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 verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.

 draft-ietf-dnsop-edns-key-tag-05 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8145 RFC8146 Adding Support for Salted Password Databases to EAP-pwd D. Harkins April 2017 ASCII HTML 11 Password-Authenticated Key Exchange PAKE Dictionary Attack Authentication EAP

EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys and double hashing of a password in the style of Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd.

 draft-harkins-salted-eap-pwd-08 RFC5931 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8146 10.17487/RFC8146 RFC8147 Next-Generation Pan-European eCall R. Gellens H. Tschofenig May 2017 ASCII HTML 43 emergency call calls emergency call emergency calls vehicle acn aacn automatic crash notification automatic collision notification advanced automatic crash notification advanced automatic collision notification crash vehicle-initiated

This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in-vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.

This document also registers MIME media types and an Emergency Call Data Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.

Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions.

 draft-ietf-ecrit-ecall-27 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC8147 RFC8148 Next-Generation Vehicle-Initiated Emergency Calls R. Gellens B. Rosen H. Tschofenig May 2017 ASCII HTML 40 emergency call calls emergency call emergency calls vehicle acn aacn automatic crash notification automatic collision notification advanced automatic crash notification advanced automatic collision notification crash vehicle-initiated ecall

This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data.

This document also registers a MIME media type and Emergency Call Data Type for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document.

This document reuses the technical aspects of next-generation Pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions). However, this document specifies use of a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context.

 draft-ietf-ecrit-car-crash-23 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC8148 RFC8149 RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) T. Saad Editor R. Gandhi Editor Z. Ali R. Venator Y. Kamite April 2017 ASCII HTML 17 RSVP fragmentation RSVP fragment identifier P2MP-TE tree reoptimization P2MP-TE tree re-evaluation Preferable P2MP-TE tree Inter-domain P2MP-TE

The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.

 draft-ietf-teas-p2mp-loose-path-reopt-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8149 RFC8150 MPLS Transport Profile Linear Protection MIB S. Kingston Smiler M. Venkatesan D. King S. Aldrin J. Ryoo April 2017 ASCII HTML 48 Network Management Management Information Base MIB SMIv2

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing Multiprotocol Label Switching - Transport Profile (MPLS-TP) linear protection.

 draft-ietf-mpls-tp-linear-protection-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8150 RFC8151 Use Cases for Data Center Network Virtualization Overlay Networks L. Yong L. Dunbar M. Toy A. Isaac V. Manral May 2017 ASCII HTML 16

This document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications.

 draft-ietf-nvo3-use-case-17 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8151 RFC8152 CBOR Object Signing and Encryption (COSE) J. Schaad July 2017 ASCII HTML 121 CoAP ECC Elliptic Curve

Concise Binary Object Representation (CBOR) is a 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) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.

 draft-ietf-cose-msg-24 PROPOSED STANDARD PROPOSED STANDARD IETF sec cose http://www.rfc-editor.org/errata_search.php?rfc=8152 10.17487/RFC8152 RFC8153 Digital Preservation Considerations for the RFC Series H. Flanagan April 2017 ASCII HTML 18 archive archiving

The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice.

 draft-iab-rfc-preservation-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8153 RFC8154 Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout C. Hellwig May 2017 ASCII HTML 30 NFSv4

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 Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices.

 draft-ietf-nfsv4-scsi-layout-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8154 RFC8155 Traversal Using Relays around NAT (TURN) Server Auto Discovery P. Patil T. Reddy D. Wing April 2017 ASCII HTML 16

Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.

This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.

 draft-ietf-tram-turn-server-discovery-12 RFC5766 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8155 RFC8156 DHCPv6 Failover Protocol T. Mrugalski K. Kinnear June 2017 ASCII HTML 96 DHCPv6 Failover

DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC 3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031).

 draft-ietf-dhc-dhcpv6-failover-protocol-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8156 RFC8157 Huawei's GRE Tunnel Bonding Protocol N. Leymann C. Heidemann M. Zhang B. Sarikaya M. Cullen May 2017 ASCII HTML 44 Hybrid Access Bandwidth Aggregation Bonding Tunnel GRE Channel Hybrid Access Aggregation Point Home Gateway

There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.

In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE Tunnel Bonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.

 draft-zhang-gre-tunnel-bonding-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8157 RFC8158 IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events S. Sivakumar R. Penno December 2017 ASCII HTML 34 template

Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events.

 draft-ietf-behave-ipfix-nat-logging-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8158 RFC8159 Keyed IPv6 Tunnel M. Konstantynowicz Editor G. Heron Editor R. Schatzmayr W. Henderickx May 2017 ASCII HTML 12 L2TPv3 pseudowire

This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane.

 draft-ietf-l2tpext-keyed-ipv6-tunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2tpext 10.17487/RFC8159 RFC8160 IUTF8 Terminal Mode in Secure Shell (SSH) S. Tatham D. Tucker April 2017 ASCII HTML 4 Secure Shell SSH

This document specifies a new opcode in the Secure Shell terminal modes encoding. The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding.

 draft-sgtatham-secsh-iutf8-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8160 RFC8161 Benchmarking the Neighbor Discovery Protocol W. Cerveny R. Bonica R. Thomas May 2017 ASCII HTML 17 IPv6 Scaling NDP

This document provides benchmarking procedures for the Neighbor Discovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.

 draft-ietf-bmwg-ipv6-nd-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8161 RFC8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME P. Hoffman J. Schlyter May 2017 ASCII HTML 11

This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.

 draft-ietf-dane-smime-16 EXPERIMENTAL EXPERIMENTAL IETF sec dane 10.17487/RFC8162 RFC8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks K. Lynn Editor J. Martocci C. Neilson S. Donaldson May 2017 ASCII HTML 27

Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.

 draft-ietf-6lo-6lobac-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8163 RFC8164 Opportunistic Security for HTTP/2 M. Nottingham M. Thomson May 2017 ASCII HTML 10 Opportunistic Security HTTP

This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.

 draft-ietf-httpbis-http2-encryption-11 EXPERIMENTAL EXPERIMENTAL IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8164 10.17487/RFC8164 RFC8165 Design Considerations for Metadata Insertion T. Hardie May 2017 ASCII HTML 7 surveillance proxy proxying middlebox

The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.

 draft-hardie-privsec-metadata-insertion-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8165 RFC8166 Remote Direct Memory Access Transport for Remote Procedure Call Version 1 C. Lever Editor W. Simpson T. Talpey June 2017 ASCII HTML 55 RPC-over-RDMA

This document specifies a protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA). This protocol is referred to as the RPC-over- RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666.

 draft-ietf-nfsv4-rfc5666bis-11 RFC5666 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8166 RFC8167 Bidirectional Remote Procedure Call on RPC-over-RDMA Transports C. Lever June 2017 ASCII HTML 13 NFS-over-RDMA RPC-over-RDMA

Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection. This document describes how RPC transport endpoints capable of Remote Direct Memory Access (RDMA) convey RPCs in both directions on a single connection.

 draft-ietf-nfsv4-rpcrdma-bidirection-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8167 RFC8168 DHCPv6 Prefix-Length Hint Issues T. Li C. Liu Y. Cui May 2017 ASCII HTML 9 DHCPv6 Dynamic Host Configuration Protocol IPv6 Prefix Prefix Delegation Prefix Length Hint Address Allocation

DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations.

 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8168 RFC8169 Residence Time Measurement in MPLS Networks G. Mirsky S. Ruffini E. Gray J. Drake S. Bryant A. Vainshtein May 2017 ASCII HTML 30 G-ACh Resident Time MPLS

This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.

Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message.

 draft-ietf-mpls-residence-time-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8169 RFC8170 Planning for Protocol Adoption and Subsequent Transitions D. Thaler Editor May 2017 ASCII HTML 22 transition plan

Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.

 draft-iab-protocol-transitions-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8170 RFC8171 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms D. Eastlake 3rd L. Dunbar R. Perlman Y. Li June 2017 ASCII HTML 55 Push Pull ESADI ES-IS

This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses.

 draft-ietf-trill-directory-assist-mechanisms-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8171 RFC8172 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure A. Morton July 2017 ASCII HTML 15

The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware.

 draft-ietf-bmwg-virtual-net-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8172 RFC8173 Precision Time Protocol Version 2 (PTPv2) Management Information Base V. Shankarkumar L. Montini T. Frost G. Dowd June 2017 ASCII HTML 64

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.

This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions.

 draft-ietf-tictoc-ptp-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF int tictoc 10.17487/RFC8173 RFC8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words B. Leiba May 2017 ASCII HTML 4

RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

 draft-leiba-rfc2119-update-02 RFC2119 BCP0014 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8174 10.17487/RFC8174 RFC8175 Dynamic Link Exchange Protocol (DLEP) S. Ratliff S. Jury D. Satterwhite R. Taylor B. Berry June 2017 ASCII HTML 82

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics.

 draft-ietf-manet-dlep-29 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8175 RFC8176 Authentication Method Reference Values M. Jones P. Hunt A. Nadalin June 2017 ASCII HTML 15 Authentication Method Reference Authentication Method,

The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.

 draft-ietf-oauth-amr-values-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8176 RFC8177 YANG Data Model for Key Chains A. Lindem Editor Y. Qu D. Yeung I. Chen J. Zhang June 2017 ASCII HTML 25

This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.

 draft-ietf-rtgwg-yang-key-chain-24 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8177 RFC8178 Rules for NFSv4 Extensions and Minor Versions D. Noveck July 2017 ASCII HTML 26

This document describes the rules relating to the extension of the NFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions.

 draft-ietf-nfsv4-versioning-11 RFC5661 RFC7862 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8178 RFC8179 Intellectual Property Rights in IETF Technology S. Bradner J. Contreras May 2017 ASCII HTML 26 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 as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out 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 document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.

 draft-bradner-rfc3979bis-13 RFC3979 RFC4879 RFC2026 BCP0079 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8179 10.17487/RFC8179 RFC8180 Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration X. Vilajosana Editor K. Pister T. Watteyne May 2017 ASCII HTML 28

This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.

 draft-ietf-6tisch-minimal-21 BCP0210 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int 6tisch http://www.rfc-editor.org/errata_search.php?rfc=8180 10.17487/RFC8180 RFC8181 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) S. Weiler A. Sonalker R. Austein July 2017 ASCII HTML 21 SIDR

This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs.

 draft-ietf-sidr-publication-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8181 RFC8182 The RPKI Repository Delta Protocol (RRDP) T. Bruijnzeels O. Muravskiy B. Weber R. Austein July 2017 ASCII HTML 24

In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.

 draft-ietf-sidr-delta-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8182 RFC8183 An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services R. Austein July 2017 ASCII HTML 23 RPKI

This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.

This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships.

 draft-ietf-sidr-rpki-oob-setup-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8183 RFC8184 Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires W. Cheng L. Wang H. Li S. Davari J. Dong June 2017 ASCII HTML 11 mpls mpls-tp

This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used. A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs. This PW dual-homing local protection mechanism is complementary to existing PW protection mechanisms.

 draft-ietf-pals-mpls-tp-dual-homing-protection-06 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC8184 RFC8185 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection W. Cheng L. Wang H. Li J. Dong A. D'Alessandro June 2017 ASCII HTML 17 mpls mpls-tp

In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs) (RFC 5921) may be statically configured when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the Packet Switched Network (PSN). The framework and typical scenarios of dual- homing PW local protection are described in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual- homing PEs for dual-homing PW local protection.

 draft-ietf-pals-mpls-tp-dual-homing-coordination-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8185 RFC8186 Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) G. Mirsky I. Meilik June 2017 ASCII HTML 8 IPPM TWAMP IEEE 1588 PTPv2

This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.

 draft-ietf-ippm-twamp-time-format-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8186 RFC8187 Indicating Character Encoding and Language for HTTP Header Field Parameters J. Reschke September 2017 ASCII HTML 13

By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.

This document obsoletes RFC 5987.

 draft-ietf-httpbis-rfc5987bis-05 RFC5987 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8187 RFC8188 Encrypted Content-Encoding for HTTP M. Thomson June 2017 ASCII HTML 16 http content coding content encoding encryption aead

This memo introduces a content coding for HTTP that allows message payloads to be encrypted.

 draft-ietf-httpbis-encryption-encoding-09 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8188 10.17487/RFC8188 RFC8189 Multi-Cost Application-Layer Traffic Optimization (ALTO) S. Randriamasy W. Roome N. Schwan October 2017 ASCII HTML 29 ALTO Information Resources Network Map PID Filtered Network Map Endpoint Property Service Endpoint Cost Service Multi-Cost Filtered Multi-Cost Map Multi-Cost Data Format Testable Cost Types or-constraints

The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.

This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.

 draft-ietf-alto-multi-cost-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8189 RFC8190 Updates to the Special-Purpose IP Address Registries R. Bonica M. Cotton B. Haberman L. Vegoda June 2017 ASCII HTML 6

This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries.

This memo updates RFC 6890.

 draft-bchv-rfc6890bis-07 RFC6890 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8190 RFC8191 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) Z. Yan J. Lee X. Lee August 2017 ASCII HTML 10 PMIPv6 HNP HNP renumbering LMA handover

In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification.

 draft-ietf-dmm-hnprenum-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8191 RFC8192 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases S. Hares D. Lopez M. Zarny C. Jacquenet R. Kumar J. Jeong July 2017 ASCII HTML 29 I2NSF

This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases.

 draft-ietf-i2nsf-problem-and-use-cases-16 INFORMATIONAL INFORMATIONAL IETF sec i2nsf 10.17487/RFC8192 RFC8193 Information Model for Large-Scale Measurement Platforms (LMAPs) T. Burbridge P. Eardley M. Bagnulo J. Schoenwaelder August 2017 ASCII HTML 53

This Information Model applies to the Measurement Agent within an LMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols.

 draft-ietf-lmap-information-model-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops lmap 10.17487/RFC8193 RFC8194 A YANG Data Model for LMAP Measurement Agents J. Schoenwaelder V. Bajpai August 2017 ASCII HTML 59 LMAP YANG

This document defines a data model for Large-Scale Measurement Platforms (LMAPs). The data model is defined using the YANG data modeling language.

 draft-ietf-lmap-yang-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops lmap 10.17487/RFC8194 RFC8195 Use of BGP Large Communities J. Snijders J. Heasley M. Schmidt June 2017 ASCII HTML 15 large BGP communities

This document presents examples and inspiration for operator application of BGP Large Communities. Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy. Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire.

 draft-ietf-grow-large-communities-usage-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC8195 RFC8196 IS-IS Autoconfiguration B. Liu Editor L. Ginsberg B. Decraene I. Farrer M. Abrahamsson July 2017 ASCII HTML 15 isis auto-configuration

This document specifies IS-IS autoconfiguration mechanisms. The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution. These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected.

 draft-ietf-isis-auto-conf-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC8196 RFC8197 A SIP Response Code for Unwanted Calls H. Schulzrinne July 2017 ASCII HTML 8 SIP robocall unwanted response code

This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.

 draft-ietf-sipcore-status-unwanted-06 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8197 RFC8198 Aggressive Use of DNSSEC-Validated Cache K. Fujiwara A. Kato W. Kumari July 2017 ASCII HTML 13 Negative cache NCACHE NSEC NSEC3

The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.

This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.

 draft-ietf-dnsop-nsec-aggressiveuse-10 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8198 RFC8199 YANG Module Classification D. Bogdanovic B. Claise C. Moberg July 2017 ASCII HTML 11 service element standard vendor user controller orchestrator

The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.

A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups.

This document describes a set of concepts and associated terms to support consistent classification of YANG modules.

 draft-ietf-netmod-yang-model-classification-08 INFORMATIONAL INFORMATIONAL IETF ops netmod 10.17487/RFC8199 RFC8200 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden July 2017 ASCII HTML 42 IPv6 internet protocol next generation ipng flow label

This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.

 draft-ietf-6man-rfc2460bis-13 RFC2460 STD0086 INTERNET STANDARD INTERNET STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=8200 10.17487/RFC8200 RFC8201 Path MTU Discovery for IP version 6 J. McCann S. Deering J. Mogul R. Hinden Editor July 2017 ASCII HTML 19 MTU-IPv6 Internet Protocol IPv6 link MTU path MTU PMTU Path MTU Discovery

This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.

 draft-ietf-6man-rfc1981bis-08 RFC1981 STD0087 INTERNET STANDARD INTERNET STANDARD IETF int 6man 10.17487/RFC8201 RFC8202 IS-IS Multi-Instance L. Ginsberg S. Previdi W. Henderickx June 2017 ASCII HTML 16

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.

This document obsoletes RFC 6822.

 draft-ietf-isis-mi-bis-03 RFC6822 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC8202 RFC8203 BGP Administrative Shutdown Communication J. Snijders J. Heitz J. Scudder July 2017 ASCII HTML 6 BGP cease shutdown

This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486.

 draft-ietf-idr-shutdown-10 RFC4486 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8203 RFC8204 Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) M. Tahhan B. O'Mahony A. Morton September 2017 ASCII HTML 24

This memo describes the contributions of the Open Platform for NFV (OPNFV) project on Virtual Switch Performance (VSPERF), particularly in the areas of test setups and configuration parameters for the system under test. This project has extended the current and completed work of the Benchmarking Methodology Working Group in the IETF and references existing literature. The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo describes the additional considerations when virtual switches are implemented on general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the "telco" infrastructure.

 draft-ietf-bmwg-vswitch-opnfv-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8204 RFC8205 BGPsec Protocol Specification M. Lepinski Editor K. Sriram Editor September 2017 ASCII HTML 45 BGP BGPsec BGP AS-path protection BGP Security

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 AS 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.

 draft-ietf-sidr-bgpsec-protocol-23 RFC8206 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8205 RFC8206 BGPsec Considerations for Autonomous System (AS) Migration W. George S. Murphy September 2017 ASCII HTML 16 as-migration SIDR BGPsec AS_PATH

This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.

 draft-ietf-sidr-as-migration-06 RFC8205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8206 RFC8207 BGPsec Operational Considerations R. Bush September 2017 ASCII HTML 10 BGP RPKI Routing Security

Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed.

 draft-ietf-sidr-bgpsec-ops-16 BCP0211 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC8207 RFC8208 BGPsec Algorithms, Key Formats, and Signature Formats S. Turner O. Borchert September 2017 ASCII HTML 19

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").

This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

 draft-ietf-sidr-bgpsec-algs-18 RFC8608 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8208 RFC8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests M. Reynolds S. Turner S. Kent September 2017 ASCII HTML 15

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 AS. 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 Resource extension. An EE certificate of this type asserts that the router or routers 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 document updates the RPKI Resource Certificates Profile (RFC 6487).

 draft-ietf-sidr-bgpsec-pki-profiles-21 RFC6487 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8209 RFC8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 R. Bush R. Austein September 2017 ASCII HTML 35

In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.

This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.

 draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 RFC6810 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8210 RFC8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) S. Kent D. Ma September 2017 ASCII HTML 26 BGP Security

This document analyzes actions by or against a Certification Authority (CA) or an 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 an 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.

 draft-ietf-sidr-adverse-actions-04 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC8211 RFC8212 Default External BGP (EBGP) Route Propagation Behavior without Policies J. Mauch J. Snijders G. Hankins July 2017 ASCII HTML 7 reject BGP EBGP

This document updates RFC 4271 by defining the default behavior of a BGP speaker when there is no Import or Export Policy associated with an External BGP session.

 draft-ietf-grow-bgp-reject-08 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8212 RFC8213 Security of Messages Exchanged between Servers and Relay Agents B. Volz Y. Pal August 2017 ASCII HTML 8

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.

 draft-ietf-dhc-relay-server-security-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8213 RFC8214 Virtual Private Wire Service Support in Ethernet VPN S. Boutros A. Sajassi S. Salam J. Drake J. Rabadan August 2017 ASCII HTML 17

This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.

 draft-ietf-bess-evpn-vpws-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8214 10.17487/RFC8214 RFC8215 Local-Use IPv4/IPv6 Translation Prefix T. Anderson August 2017 ASCII HTML 7 IPv6 transition IVI MAP NAT64 SIIT SIIT-DC Transition

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.

 draft-ietf-v6ops-v4v6-xlat-prefix-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC8215 RFC8216 HTTP Live Streaming R. Pantos Editor W. May August 2017 ASCII HTML 60 HTML streaming media

This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 7 of this protocol.

 draft-pantos-http-live-streaming-23 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8216 10.17487/RFC8216 RFC8217 Clarifications for When to Use the name-addr Production in SIP Messages R. Sparks August 2017 ASCII HTML 6

RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.

This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502).

 draft-ietf-sipcore-name-addr-guidance-02 RFC3261 RFC3325 RFC3515 RFC3892 RFC4508 RFC5002 RFC5318 RFC5360 RFC5502 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8217 RFC8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) J. Yi B. Parrein August 2017 ASCII HTML 26 MANET

This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained.

 draft-ietf-manet-olsrv2-multipath-15 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC8218 RFC8219 Benchmarking Methodology for IPv6 Transition Technologies M. Georgescu L. Pislaru G. Lencse August 2017 ASCII HTML 30 Single Translation Technologies Double Translation Technologies Encapsulation Technologies NAT64 DNS64 MAP-E MAP-T DSLite 464XLAT 6PE DNS Resolution Performance Overload Scalability Typical Latency Worst Case Latency PDV IPDV

Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability.

 draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8219 RFC8220 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) O. Dornon J. Kotalwar V. Hemige R. Qiu Z. Zhang September 2017 ASCII HTML 43 multicast

This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.

With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.

This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.

 draft-ietf-pals-vpls-pim-snooping-06 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC8220 RFC8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) P. Wouters D. Migault J. Mattsson Y. Nir T. Kivinen October 2017 ASCII HTML 15 IPsec IKE

This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.

 draft-ietf-ipsecme-rfc7321bis-06 RFC7321 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8221 RFC8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery A. Sullivan September 2017 ASCII HTML 11 DNS mDNS DNS-SD

Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services. Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets. This is of particular relevance where some environments use DNS labels that conform to Internationalized Domain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8). In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner.

 draft-ietf-dnssd-mdns-dns-interop-04 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC8222 RFC8223 Application-Aware Targeted LDP S. Esale R. Torvi L. Jalil U. Chunduri K. Raza August 2017 ASCII HTML 18

Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with any Label Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the Targeted Application Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session.

 draft-ietf-mpls-app-aware-tldp-09 RFC7473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8223 10.17487/RFC8223 RFC8224 Authenticated Identity Management in the Session Initiation Protocol (SIP) J. Peterson C. Jennings E. Rescorla C. Wendt February 2018 ASCII HTML 46 SIP Secure Origin Identification Communication Security RTCWeb Certificates Real-Time Communication

The baseline 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 requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.

This document obsoletes RFC 4474.

 draft-ietf-stir-rfc4474bis-16 RFC4474 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8224 10.17487/RFC8224 RFC8225 PASSporT: Personal Assertion Token C. Wendt J. Peterson February 2018 ASCII HTML 25

This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.

 draft-ietf-stir-passport-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8225 10.17487/RFC8225 RFC8226 Secure Telephone Identity Credentials: Certificates J. Peterson S. Turner February 2018 ASCII HTML 24 TNAuthorizationList JWTClaimConstraints

In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.

 draft-ietf-stir-certificates-17 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8226 10.17487/RFC8226 RFC8227 MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology W. Cheng L. Wang H. Li H. van Helvoort J. Dong August 2017 ASCII HTML 56 wrapping protection short-wrapping protection steering protection ring protection shared ring protection protection switching

This document describes requirements, architecture, and solutions for MPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring.

 draft-ietf-mpls-tp-shared-ring-protection-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8227 RFC8228 Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels A. Freytag August 2017 ASCII HTML 24 LGR Variant IDN

Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets (LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways to design LGRs to support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants. The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940.

 draft-freytag-lager-variant-rules-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8228 10.17487/RFC8228 RFC8229 TCP Encapsulation of IKE and IPsec Packets T. Pauly S. Touati R. Mantha August 2017 ASCII HTML 25 IKE IKEv2 IPsec TCP

This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.

 draft-ietf-ipsecme-tcp-encaps-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=8229 10.17487/RFC8229 RFC8230 Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages M. Jones September 2017 ASCII HTML 12 Cryptography Digital Signature Encryption

The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. Encodings are specified for the use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys.

 draft-jones-cose-rsa-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8230 RFC8231 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE E. Crabbe I. Minei J. Medved R. Varga September 2017 ASCII HTML 57 Stateful PCE

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.

Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.

 draft-ietf-pce-stateful-pce-21 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8231 10.17487/RFC8231 RFC8232 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE E. Crabbe I. Minei J. Medved R. Varga X. Zhang D. Dhody September 2017 ASCII HTML 26 Stateful PCE state synchronization optimization

A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.

 draft-ietf-pce-stateful-sync-optimizations-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8232 RFC8233 Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) D. Dhody Q. Wu V. Manral Z. Ali K. Kumaki September 2017 ASCII HTML 31 PCE PCEP service-aware metric BU LBU LRBU

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 Client (PCC) 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.

 draft-ietf-pce-pcep-service-aware-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8233 10.17487/RFC8233 RFC8234 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode J. Ryoo T. Cheung H. van Helvoort I. Busi G. Wen August 2017 ASCII HTML 9 APS mode initialization mpls-tp linear protection

This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup.

 draft-ietf-mpls-tp-aps-updates-04 RFC7271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8234 RFC8235 Schnorr Non-interactive Zero-Knowledge Proof F. Hao Editor September 2017 ASCII HTML 13 Zero-Knowledge Proof Schnorr NIZK proof Identification protocol

This document describes the Schnorr non-interactive zero-knowledge (NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings.

 draft-hao-schnorr-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8235 RFC8236 J-PAKE: Password-Authenticated Key Exchange by Juggling F. Hao Editor September 2017 ASCII HTML 15

This document specifies a Password-Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.

 draft-hao-jpake-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8236 RFC8237 MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs L. Martini G. Swallow E. Bellagamba October 2017 ASCII HTML 20

This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more PWs carried on the LSP.

The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP.

 draft-ietf-pals-status-reduction-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8237 RFC8238 Data Center Benchmarking Terminology L. Avramov J. Rapp August 2017 ASCII HTML 20

The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

 draft-ietf-bmwg-dcbench-terminology-19 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8238 RFC8239 Data Center Benchmarking Methodology L. Avramov J. Rapp August 2017 ASCII HTML 19

The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

 draft-ietf-bmwg-dcbench-methodology-18 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=8239 10.17487/RFC8239 RFC8240 Report from the Internet of Things Software Update (IoTSU) Workshop 2016 H. Tschofenig S. Farrell September 2017 ASCII HTML 27 Security Firmware Updates Software Updates Internet of Things

This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards 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.

 draft-iab-iotsu-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8240 RFC8241 Interface to the Routing System (I2RS) Security-Related Requirements S. Hares D. Migault J. Halpern September 2017 ASCII HTML 20

This document presents security-related requirements for the Interface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. One such reuse is of the security features of a secure transport (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport.

 draft-ietf-i2rs-protocol-security-requirements-17 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8241 RFC8242 Interface to the Routing System (I2RS) Ephemeral State Requirements J. Haas S. Hares September 2017 ASCII HTML 12

"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System (I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol.

 draft-ietf-i2rs-ephemeral-state-23 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8242 RFC8243 Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL) R. Perlman D. Eastlake 3rd M. Zhang A. Ghanwani H. Zhai September 2017 ASCII HTML 29 aggregaged nickname unique nickname

Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?

This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.

 draft-ietf-trill-rbridge-multilevel-07 INFORMATIONAL INFORMATIONAL IETF rtg trill 10.17487/RFC8243 RFC8244 Special-Use Domain Names Problem Statement T. Lemon R. Droms W. Kumari October 2017 ASCII HTML 25 SUN SUTLD RFC6761

The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.

This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.

 draft-ietf-dnsop-sutld-ps-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8244 RFC8245 Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 T. Clausen C. Dearlove U. Herberg H. Rogge October 2017 ASCII HTML 29 MANET

RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexed MANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers.

 draft-ietf-manet-rfc5444-usage-07 RFC5444 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8245 RFC8246 HTTP Immutable Responses P. McManus September 2017 ASCII HTML 6

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

 draft-ietf-httpbis-immutable-03 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8246 RFC8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Nir T. Kivinen P. Wouters D. Migault September 2017 ASCII HTML 19 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) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).

 draft-ietf-ipsecme-rfc4307bis-18 RFC4307 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8247 RFC8248 Security Automation and Continuous Monitoring (SACM) Requirements N. Cam-Winget L. Lorenzin September 2017 ASCII HTML 20 posture assessment posture validation software integrity network authorization software compliance

This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632.

 draft-ietf-sacm-requirements-18 INFORMATIONAL INFORMATIONAL IETF sec sacm 10.17487/RFC8248 RFC8249 Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation M. Zhang X. Zhang D. Eastlake 3rd R. Perlman S. Chatterjee September 2017 ASCII HTML 15

The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325, 7177, and 7780.

 draft-ietf-trill-mtu-negotiation-08 RFC6325 RFC7177 RFC7780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8249 RFC8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option N. Elkins R. Hamilton M. Ackermann September 2017 ASCII HTML 30

To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.

 draft-ietf-ippm-6man-pdm-option-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8250 RFC8251 Updates to the Opus Audio Codec JM. Valin K. Vos October 2017 ASCII HTML 12

This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in Appendix A of RFC 6716. The changes fix real and potential security-related issues, as well as minor quality-related issues.

 draft-ietf-codec-opus-update-10 RFC6716 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC8251 RFC8252 OAuth 2.0 for Native Apps W. Denniss J. Bradley October 2017 ASCII HTML 21

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.

 draft-ietf-oauth-native-apps-12 RFC6749 BCP0212 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8252 10.17487/RFC8252 RFC8253 PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) D. Lopez O. Gonzalez de Dios Q. Wu D. Dhody October 2017 ASCII HTML 26 PCE PCEP PCEPS security authentication encryption TLS

The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.

This document updates RFC 5440 in regards to the PCEP initialization phase procedures.

 draft-ietf-pce-pceps-18 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8253 10.17487/RFC8253 RFC8254 Uniform Resource Name (URN) Namespace Registration Transition J. Klensin J. Hakala October 2017 ASCII HTML 9 ISBN ISSN NBN national bibliography number

The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces. This document clarifies the status of relevant older RFCs and confirms and documents advice to IANA about selected existing registrations. This document also obsoletes RFCs 3044 and 3187 and moves them to Historic status. These RFCs describe the ISSN and ISBN namespaces, which are now outdated because the descriptions reside in registration templates.

 draft-ietf-urnbis-ns-reg-transition-08 RFC3044 RFC3187 PROPOSED STANDARD PROPOSED STANDARD IETF art urnbis 10.17487/RFC8254 RFC8255 Multiple Language Content Type N. Tomkinson N. Borenstein October 2017 ASCII HTML 19 multiple language multi lingual content type email mime

This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings.

 draft-ietf-slim-multilangcontent-14 PROPOSED STANDARD PROPOSED STANDARD IETF art slim 10.17487/RFC8255 RFC8256 Requirements for Hitless MPLS Path Segment Monitoring A. D'Alessandro L. Andersson S. Ueno K. Arai Y. Koike October 2017 ASCII HTML 16 HPSM MPLS MPLS Transport Profile mpls-tp OAM monitoring Hitless Path Segment Monitoring Path Segment Monitoring HPSM

One of the most important Operations, Administration, and Maintenance (OAM) capabilities for transport-network operation is fault localization. An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints. However, the current segment monitoring approach defined for MPLS (including the MPLS Transport Profile (MPLS-TP)) in RFC 6371 "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support Hitless Path Segment Monitoring (HPSM).

 draft-ietf-mpls-tp-temporal-hitless-psm-14 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8256 RFC8257 Data Center TCP (DCTCP): TCP Congestion Control for Data Centers S. Bensley D. Thaler P. Balasubramanian L. Eggert G. Judd October 2017 ASCII HTML 17 TCP ECN DCTCP congestion control

This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures.

 draft-ietf-tcpm-dctcp-10 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC8257 RFC8258 Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) D. Ceccarelli L. Berger October 2017 ASCII HTML 7 OSPF-TE GMPLS

This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) fields. This "Generalized SCSI" can be used with routing protocols that define GMPLS ISCDs and any specific technology. This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards.

 draft-ietf-teas-gmpls-scsi-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8258 RFC8259 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor December 2017 ASCII HTML 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-jsonbis-rfc7159bis-04 RFC7159 STD0090 INTERNET STANDARD INTERNET STANDARD IETF art jsonbis http://www.rfc-editor.org/errata_search.php?rfc=8259 10.17487/RFC8259 RFC8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol R. Stewart M. Tuexen S. Loreto R. Seggelmann November 2017 ASCII HTML 23

The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.

Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving.

 draft-ietf-tsvwg-sctp-ndata-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8260 RFC8261 Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets M. Tuexen R. Stewart R. Jesup S. Loreto November 2017 ASCII HTML 10

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.

 draft-ietf-tsvwg-sctp-dtls-encaps-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8261 RFC8262 Content-ID Header Field in the Session Initiation Protocol (SIP) C. Holmberg I. Sedlacek October 2017 ASCII HTML 14 SIP

This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). This document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.

This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.

 draft-ietf-sipcore-content-id-10 RFC5621 RFC5368 RFC6442 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8262 RFC8263 Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message B. Weis U. Mangla T. Karl N. Maheshwari November 2017 ASCII HTML 17 multicast security

The Group Domain of Interpretation (GDOI) includes the ability of a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method.

 draft-weis-gdoi-rekey-ack-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8263 RFC8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols P. Saint-Andre M. Blanchet October 2017 ASCII HTML 43 internationalization i18n Stringprep

Application protocols using Unicode code points 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 code points and thus is more 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 7564.

 draft-ietf-precis-7564bis-10 RFC7564 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=8264 10.17487/RFC8264 RFC8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords P. Saint-Andre A. Melnikov October 2017 ASCII HTML 26 Username Password Unicode Internationalization i18n Authentication SASLprep

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. This document obsoletes RFC 7613.

 draft-ietf-precis-7613bis-11 RFC7613 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=8265 10.17487/RFC8265 RFC8266 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames P. Saint-Andre October 2017 ASCII HTML 13 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. This document obsoletes RFC 7700.

 draft-ietf-precis-7700bis-10 RFC7700 PROPOSED STANDARD PROPOSED STANDARD IETF art precis 10.17487/RFC8266 RFC8267 Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 C. Lever October 2017 ASCII HTML 21 NFS-over-RDMA

This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667.

 draft-ietf-nfsv4-rfc5667bis-13 RFC5667 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8267 RFC8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) M. Baushke December 2017 ASCII HTML 8 Public Key Private Key group14 group15 group16 group17 groupt18 2048-bit 3072-bit 4096-bit 6144-bit 8192-bit

This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.

 draft-ietf-curdle-ssh-modp-dh-sha2-09 RFC4250 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8268 RFC8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) W. Kim J. Lee J. Park D. Kwon D. Kim October 2017 ASCII HTML 19 ARIA SRTP DTLS-SRTP MIKEY

This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA.

 draft-ietf-avtcore-aria-srtp-11 INFORMATIONAL INFORMATIONAL IETF art avtcore 10.17487/RFC8269 RFC8270 Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits L. Velvindron M. Baushke December 2017 ASCII HTML 5 SSH DH

The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits. Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updates RFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size.

 draft-ietf-curdle-ssh-dh-group-exchange-06 RFC4419 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8270 10.17487/RFC8270 RFC8271 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) M. Taillon T. Saad Editor R. Gandhi Editor Z. Ali M. Bhatia October 2017 ASCII HTML 24 Co-routed LSPs Bypass assignment coordinate Restore co-routing

This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane.

 draft-ietf-teas-gmpls-lsp-fastreroute-12 RFC4090 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8271 RFC8272 TinyIPFIX for Smart Meters in Constrained Networks C. Schmitt B. Stiller B. Trammell November 2017 ASCII HTML 30 TinyIPFIX Smart Meters Constrained Networks

This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944). TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks. This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device.

 draft-schmitt-ipfix-tiny-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8272 10.17487/RFC8272 RFC8273 Unique IPv6 Prefix per Host J. Brzozowski G. Van de Velde December 2017 ASCII HTML 10

This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.

 draft-ietf-v6ops-unique-ipv6-prefix-per-host-13 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8273 RFC8274 Incident Object Description Exchange Format Usage Guidance P. Kampanakis M. Suzuki November 2017 ASCII HTML 33 IODEF best practices IODEF implementation recommendations IODEF examples IODEF practical recommendations

The Incident Object Description Exchange Format (IODEF) v2 (RFC7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged by Computer Security Incident Response Teams (CSIRTs) . Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being used. This document aims to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by CSIRTs around the world.

 draft-ietf-mile-iodef-guidance-11 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC8274 RFC8275 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask J. Fields A. Gruenbacher December 2017 ASCII HTML 7 NFSv4

In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that.

 draft-ietf-nfsv4-umask-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8275 10.17487/RFC8275 RFC8276 File System Extended Attributes in NFSv4 M. Naik M. Eshel December 2017 ASCII HTML 28

This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects.

 draft-ietf-nfsv4-xattrs-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8276 10.17487/RFC8276 RFC8277 Using BGP to Bind MPLS Labels to Address Prefixes E. Rosen October 2017 ASCII HTML 23 asynchronous transfer mode AAL syntax adaption layer

This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.

 draft-ietf-mpls-rfc3107bis-04 RFC3107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8277 RFC8278 Mobile Access Gateway (MAG) Multipath Options P. Seite A. Yegin S. Gundavelli January 2018 ASCII HTML 15 Proxy Mobile IPv6 (PMIPv6) multihoming Multiple WAN accesses

This specification defines extensions to the Proxy Mobile IPv6 (PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA. This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic. This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option.

 draft-ietf-dmm-mag-multihoming-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8278 RFC8279 Multicast Using Bit Index Explicit Replication (BIER) IJ. Wijnands Editor E. Rosen Editor A. Dolganow T. Przygienda S. Aldrin November 2017 ASCII HTML 43 Multicast

This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.

 draft-ietf-bier-architecture-08 PROPOSED STANDARD EXPERIMENTAL IETF rtg bier 10.17487/RFC8279 RFC8280 Research into Human Rights Protocol Considerations N. ten Oever C. Cath October 2017 ASCII HTML 81 human rights IETF protocols guidelines considerations freedom of expression

This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.

This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.

 draft-irtf-hrpc-research-14 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8280 10.17487/RFC8280 RFC8281 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model E. Crabbe I. Minei S. Sivabalan R. Varga December 2017 ASCII HTML 20

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.

The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.

 draft-ietf-pce-pce-initiated-lsp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8281 RFC8282 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering E. Oki T. Takeda A. Farrel F. Zhang December 2017 ASCII HTML 22 Multi-layer Multi-domain Inter-domain Traffic Engineering

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.

The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.

 draft-ietf-pce-inter-layer-ext-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8282 RFC8283 An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control A. Farrel Editor Q. Zhao Editor Z. Li C. Zhou December 2017 ASCII HTML 25 PCE SDN

The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.

PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).

SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.

This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.

This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.

 draft-ietf-teas-pce-central-control-05 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8283 RFC8284 Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages S. Kille November 2017 ASCII HTML 6

The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of Jabber IDs (JIDs). The Lightweight Directory Access Protocol (LDAP) enables provision of a white pages service with a schema relating to users and support for Internet protocols. This specification defines a schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications.

 draft-kille-ldap-xmpp-schema-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8284 RFC8285 A General Mechanism for RTP Header Extensions D. Singer H. Desineni R. Even Editor October 2017 ASCII HTML 25

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 decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285.

 draft-ietf-avtcore-rfc5285-bis-14 RFC5285 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8285 RFC8286 RTP/RTCP Extension for RTP Splicing Notification J. Xia R. Even R. Huang L. Deng October 2017 ASCII HTML 22

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that 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 RTP Control Protocol (RTCP) packet that conveys the information out of band.

 draft-ietf-avtext-splicing-notification-09 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC8286 RFC8287 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes N. Kumar Editor C. Pignataro Editor G. Swallow N. Akiya S. Kini M. Chen December 2017 ASCII HTML 25 MPLS LSP Ping SPRING Segment Routing SR

A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.

The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.

 draft-ietf-mpls-spring-lsp-ping-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8287 10.17487/RFC8287 RFC8288 Web Linking M. Nottingham October 2017 ASCII HTML 24 link relation

This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").

It also defines the serialisation of such links in HTTP headers with the Link header field.

 draft-nottingham-rfc5988bis-08 RFC5988 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8288 10.17487/RFC8288 RFC8289 Controlled Delay Active Queue Management K. Nichols V. Jacobson A. McGregor Editor J. Iyengar Editor January 2018 ASCII HTML 25 CoDel AQM Active Queue Management

This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments.

 draft-ietf-aqm-codel-10 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm 10.17487/RFC8289 RFC8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm T. Hoeiland-Joergensen P. McKenney D. Taht J. Gettys E. Dumazet January 2018 ASCII HTML 25 bufferbloat aqm fq_codel fq-codel

This memo presents the FQ-CoDel hybrid packet scheduler and Active Queue Management (AQM) 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.

 draft-ietf-aqm-fq-codel-06 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm 10.17487/RFC8290 RFC8291 Message Encryption for Web Push M. Thomson November 2017 ASCII HTML 13 web push notification http encryption

This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent.

 draft-ietf-webpush-encryption-09 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush http://www.rfc-editor.org/errata_search.php?rfc=8291 10.17487/RFC8291 RFC8292 Voluntary Application Server Identification (VAPID) for Web Push M. Thomson P. Beverloo November 2017 ASCII HTML 14 authentication restricted restriction signature

An application server can use the Voluntary Application Server Identification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server.

 draft-ietf-webpush-vapid-04 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush 10.17487/RFC8292 RFC8293 A Framework for Multicast in Network Virtualization over Layer 3 A. Ghanwani L. Dunbar M. McBride V. Bannai R. Krishnan January 2018 ASCII HTML 17 NVO3 VXLAN Geneve NVGRE

This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3). Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms.

 draft-ietf-nvo3-mcast-framework-11 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8293 RFC8294 Common YANG Data Types for the Routing Area X. Liu Y. Qu A. Lindem C. Hopps L. Berger December 2017 ASCII HTML 43 Network Management Routing YANG

This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.

 draft-ietf-rtgwg-routing-types-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8294 RFC8295 EST (Enrollment over Secure Transport) Extensions S. Turner January 2018 ASCII HTML 54 Firmware TAMP Asymmetric Keys Symmetric Keys Product Availability List

The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services.

 draft-turner-est-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8295 RFC8296 Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks IJ. Wijnands Editor E. Rosen Editor A. Dolganow J. Tantsura S. Aldrin I. Meilik January 2018 ASCII HTML 24 Multicast

Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.

 draft-ietf-bier-mpls-encapsulation-12 PROPOSED STANDARD EXPERIMENTAL IETF rtg bier http://www.rfc-editor.org/errata_search.php?rfc=8296 10.17487/RFC8296 RFC8297 An HTTP Status Code for Indicating Hints K. Oku December 2017 ASCII HTML 7 push preload

This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.

 draft-ietf-httpbis-early-hints-05 EXPERIMENTAL EXPERIMENTAL IETF art httpbis 10.17487/RFC8297 RFC8298 Self-Clocked Rate Adaptation for Multimedia I. Johansson Z. Sarker December 2017 ASCII HTML 36 Cellular Network Congestion Control RTP

This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.

 draft-ietf-rmcat-scream-cc-13 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8298 RFC8299 YANG Data Model for L3VPN Service Delivery Q. Wu Editor S. Litkowski L. Tomotaki K. Ogaki January 2018 ASCII HTML 188

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. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.

This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.

 draft-wu-l3sm-rfc8049bis-11 RFC8049 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8299 10.17487/RFC8299 RFC8300 Network Service Header (NSH) P. Quinn Editor U. Elzur Editor C. Pignataro Editor January 2018 ASCII HTML 40 Service Function Chaining Network Service Header SFC NSH Network Service Function

This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).

 draft-ietf-sfc-nsh-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc 10.17487/RFC8300 RFC8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) S. Kitterman January 2018 ASCII HTML 5 email authentication

The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.

 draft-ietf-dcrup-dkim-usage-06 RFC6376 PROPOSED STANDARD PROPOSED STANDARD IETF art dcrup 10.17487/RFC8301 RFC8302 Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization Y. Li D. Eastlake 3rd L. Dunbar R. Perlman M. Umair January 2018 ASCII HTML 18 proxy RARP duplicate address DAD DHCP flooding

This document describes mechanisms to optimize the Address Resolution Protocol (ARP) and Neighbor Discovery (ND) traffic in a Transparent Interconnection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of IP / Media Access Control (MAC) address / Data Label bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edge Routing Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it. Such optimization reduces packet flooding over a TRILL campus.

 draft-ietf-trill-arp-optimization-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8302 RFC8303 On the Usage of Transport Features Provided by IETF Transport Protocols M. Welzl M. Tuexen N. Khademi February 2018 ASCII HTML 56

This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.

 draft-ietf-taps-transports-usage-09 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8303 RFC8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) G. Fairhurst T. Jones February 2018 ASCII HTML 20 UDP Transport

This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.

 draft-ietf-taps-transports-usage-udp-07 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8304 RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency D. Schinazi T. Pauly December 2017 ASCII HTML 15 IPv6 IPv4 TCP DNS NAT64

Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.

 draft-ietf-v6ops-rfc6555bis-07 RFC6555 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC8305 RFC8306 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Q. Zhao D. Dhody Editor R. Palleti D. King November 2017 ASCII HTML 43

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.

This document obsoletes RFC 6006.

 draft-ietf-pce-rfc6006bis-04 RFC6006 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8306 10.17487/RFC8306 RFC8307 Well-Known URIs for the WebSocket Protocol C. Bormann January 2018 ASCII HTML 3 URI Web metadata well-known WebSocket ws wss

RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs. It was specifically defined for the "http" and "https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes.

 draft-bormann-hybi-ws-wk-00 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8307 RFC8308 Extension Negotiation in the Secure Shell (SSH) Protocol D. Bider March 2018 ASCII HTML 14 ext-info ext-info-s ext-info-c SSH_MSG_EXT_INFO SSH_MSG_NEWCOMPRESS server-sig-algs delay-compression no-flow-control elevation delay compression delayed compression flow control elevated

This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.

 draft-ietf-curdle-ssh-ext-info-15 RFC4251 RFC4252 RFC4253 RFC4254 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8308 RFC8309 Service Models Explained Q. Wu W. Liu A. Farrel January 2018 ASCII HTML 23 YANG NETCONF RESTCONF Data Model SDN Software Defined Network Service Orchestrator

The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.

A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).

This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.

 draft-ietf-opsawg-service-model-explained-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC8309 RFC8310 Usage Profiles for DNS over TLS and DNS over DTLS S. Dickinson D. Gillmor T. Reddy March 2018 ASCII HTML 27 DNS transport

This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858.

 draft-ietf-dprive-dtls-and-tls-profiles-11 RFC7858 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC8310 RFC8311 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation D. Black January 2018 ASCII HTML 20 ECN

This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.

 draft-ietf-tsvwg-ecn-experimentation-08 RFC3168 RFC4341 RFC4342 RFC5622 RFC6679 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=8311 10.17487/RFC8311 RFC8312 CUBIC for Fast Long-Distance Networks I. Rhee L. Xu S. Ha A. Zimmermann L. Eggert R. Scheffenegger February 2018 ASCII HTML 18

CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC.

 draft-ietf-tcpm-cubic-07 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC8312 RFC8313 Use of Multicast across Inter-domain Peering Points P. Tarapore Editor R. Sayko G. Shepherd T. Eckert Editor R. Krishnan January 2018 ASCII HTML 44 multicast security multicast troubleshooting multicast routing multicast tunneling PIM PIM-SSM SSM Source Specific Multicast AMT GRE Automatic Multicast Tunneling BGP MBGP M-BGP MP-BGP exchange exchange point NNI content distribution video streaming anycast

This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.

 draft-ietf-mboned-interdomain-peering-bcp-14 BCP0213 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC8313 RFC8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access K. Moore C. Newman January 2018 ASCII HTML 26 POP IMAP SMTP MSP mail submission STARTTLS DANE TLSA

This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409.

 draft-ietf-uta-email-deep-12 RFC1939 RFC2595 RFC3501 RFC5068 RFC6186 RFC6409 PROPOSED STANDARD PROPOSED STANDARD IETF art uta http://www.rfc-editor.org/errata_search.php?rfc=8314 10.17487/RFC8314 RFC8315 Cancel-Locks in Netnews Articles M. Baeuerle February 2018 ASCII HTML 20 Usenet Netnews Cancel-Lock

This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles. This document updates RFC 5537.

 draft-baeuerle-netnews-cancel-lock-09 RFC5537 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8315 RFC8316 Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations J. Nobre L. Granville A. Clemm A. Gonzalez Prieto February 2018 ASCII HTML 16 Autonomic Networking SLA P2P

This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements (SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.

This document is a product of the IRTF Network Management Research Group (NMRG). It is published for informational purposes.

 draft-irtf-nmrg-autonomic-sla-violation-detection-13 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8316 RFC8317 Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) A. Sajassi Editor S. Salam J. Drake J. Uttaro S. Boutros J. Rabadan January 2018 ASCII HTML 23

The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly.

 draft-ietf-bess-evpn-etree-14 RFC7385 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8317 RFC8318 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee S. Dawkins January 2018 ASCII HTML 9 nomcom IAOC

This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee (NomCom) about the operations of the IETF Administrative Oversight Committee (IAOC).

This document updates RFC 7437.

 draft-dawkins-iesg-nomcom-advisor-iaoc-03 RFC7437 BCP0010 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8318 RFC8319 Support for Adjustable Maximum Router Lifetimes per Link S. Krishnan J. Korhonen S. Chakrabarti E. Nordmark A. Yourtchenko February 2018 ASCII HTML 7

The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements (RAs) from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.

This document specifies updates to the IPv6 Neighbor Discovery Protocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime.

 draft-ietf-6man-maxra-04 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8319 RFC8320 LDP Extensions to Support Maximally Redundant Trees A. Atlas K. Tiruveedhula C. Bowers J. Tantsura IJ. Wijnands February 2018 ASCII HTML 21 fast-reroute MRT MRT-FRR

This document specifies extensions to the Label Distribution Protocol (LDP) to support the creation of Label Switched Paths (LSPs) for Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as "MRT-FRR".

The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) and Label Edge Routers (LERs) advertising the MRT Capability.

MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.

 draft-ietf-mpls-ldp-mrt-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8320 RFC8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring G. Fioccola Editor A. Capello M. Cociglio L. Castaldelli M. Chen L. Zheng G. Mirsky T. Mizrahi January 2018 ASCII HTML 33 Alternate Marking Marking Method Coloring Technique

This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on an Alternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.

 draft-ietf-ippm-alt-mark-14 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8321 RFC8322 Resource-Oriented Lightweight Information Exchange (ROLIE) J. Field S. Banghart D. Waltermire February 2018 ASCII HTML 43 syndication atom atom publishing protocol atom syndication format rest information sharing security automation

This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.

 draft-ietf-mile-rolie-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8322 RFC8323 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets C. Bormann S. Lemay H. Tschofenig K. Hartke B. Silverajan B. Raymor Editor February 2018 ASCII HTML 54 CoAP Constrained Application Protocol REST IoT Internet of Things NAT Traversal CoAP in Browsers

The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.

 draft-ietf-core-coap-tcp-tls-11 RFC7641 RFC7959 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8323 RFC8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? J. Klensin February 2018 ASCII HTML 29 domain name DNS functions DNS extensions

The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.

 draft-klensin-dns-function-considerations-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8324 10.17487/RFC8324 RFC8325 Mapping Diffserv to IEEE 802.11 T. Szigeti J. Henry F. Baker February 2018 ASCII HTML 37 quality of service QoS QoS classes mapping DSCP Diffserv Access Category AC User Priority UP 802.11 Wi-Fi

As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks.

 draft-ietf-tsvwg-ieee-802-11-11 RFC8622 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8325 RFC8326 Graceful BGP Session Shutdown P. Francois Editor B. Decraene Editor C. Pelsser K. Patel C. Filsfils March 2018 ASCII HTML 12

This document standardizes a new well-known BGP community, GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths. This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance.

 draft-ietf-grow-bgp-gshut-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=8326 10.17487/RFC8326 RFC8327 Mitigating the Negative Impact of Maintenance through BGP Session Culling W. Hargrave M. Griswold J. Snijders N. Hilliard March 2018 ASCII HTML 10 BGP culling EBGP sessions

This document outlines an approach to mitigate the negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions that will be affected by maintenance are forcefully torn down before the actual maintenance activities commence.

 draft-ietf-grow-bgp-session-culling-05 BCP0214 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=8327 10.17487/RFC8327 RFC8328 Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA) W. Liu C. Xie J. Strassner G. Karagiannis M. Klyus J. Bi Y. Cheng D. Zhang March 2018 ASCII HTML 15 Information models YANG data models Event Condition Action policy rules GPIM EPRIM declarative policy intent-based policy

The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy. These models point to device-, technology-, and service-specific YANG data models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements, and interfaces.

 draft-liu-policy-based-management-framework-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8328 RFC8329 Framework for Interface to Network Security Functions D. Lopez E. Lopez L. Dunbar J. Strassner R. Kumar February 2018 ASCII HTML 25 security policy security capability

This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.

 draft-ietf-i2nsf-framework-10 INFORMATIONAL INFORMATIONAL IETF sec i2nsf 10.17487/RFC8329 RFC8330 OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth H. Long M. Ye G. Mirsky A. D'Alessandro H. Shah February 2018 ASCII HTML 10 microwave copper Generalized SCSI-TLV

A network may contain links with variable discrete bandwidth, e.g., microwave and copper. The bandwidth of such links may change discretely in response to a changing external environment. The word "availability" is typically used to describe such links during network planning. This document defines a new type of Generalized Switching Capability-Specific Information (SCSI) TLV to extend the Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note that this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology-specific documents will reference this document to describe specific uses.

 draft-ietf-ccamp-ospf-availability-extension-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8330 RFC8331 RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data T. Edwards February 2018 ASCII HTML 20 SDI video captions timecode ANC

This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1. SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD).

 draft-ietf-payload-rtp-ancillary-14 PROPOSED STANDARD PROPOSED STANDARD IETF art payload http://www.rfc-editor.org/errata_search.php?rfc=8331 10.17487/RFC8331 RFC8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol D. Bider March 2018 ASCII HTML 9 rsa-sha2-256 rsa-sha2-512 ssh-rsa publickey server-sig-algs signature authentication

This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.

 draft-ietf-curdle-rsa-sha2-12 RFC4252 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8332 RFC8333 Micro-loop Prevention by Introducing a Local Convergence Delay S. Litkowski B. Decraene C. Filsfils P. Francois March 2018 ASCII HTML 26

This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.

Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.

The mechanism is limited to the link-down event in order to keep the mechanism simple.

Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops.

 draft-ietf-rtgwg-uloop-delay-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8333 RFC8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) J. Gould W. Tan G. Brown March 2018 ASCII HTML 58 EPP Sunrise Landrush Trademark Clearinghouse Trademark Claims domain name registry launch phase

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry.

 draft-ietf-regext-launchphase-07 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8334 RFC8335 PROBE: A Utility for Probing Interfaces R. Bonica R. Thomas J. Linkova C. Lenart M. Boucadair February 2018 ASCII HTML 19 Ping ICMP

This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884.

 draft-ietf-intarea-probe-10 RFC4884 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC8335 RFC8336 The ORIGIN HTTP/2 Frame M. Nottingham E. Nygren March 2018 ASCII HTML 11 connection coalescing HTTP

This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.

 draft-ietf-httpbis-origin-frame-06 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8336 10.17487/RFC8336 RFC8337 Model-Based Metrics for Bulk Transport Capacity M. Mathis A. Morton March 2018 ASCII HTML 55 performance bulk capacity BTC diagnostic statistics

This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.

Model-Based Metrics rely on mathematical models to specify a Targeted IP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.

For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications.

 draft-ietf-ippm-model-based-metrics-13 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8337 RFC8338 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP S. Boutros Editor S. Sivabalan Editor March 2018 ASCII HTML 20

This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type.

 draft-ietf-pals-p2mp-pw-04 RFC7385 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8338 RFC8339 Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms P. Jain Editor S. Boutros S. Aldrin March 2018 ASCII HTML 10

Label Switched Path (LSP) Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PWs) using LSP Ping.

 draft-ietf-pals-p2mp-pw-lsp-ping-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8339 RFC8340 YANG Tree Diagrams M. Bjorklund L. Berger Editor March 2018 ASCII HTML 13

This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.

 draft-ietf-netmod-yang-tree-diagrams-06 BCP0215 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops netmod 10.17487/RFC8340 RFC8341 Network Configuration Access Control Model A. Bierman M. Bjorklund March 2018 ASCII HTML 58 NETCONF RESTCONF YANG XML

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol 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 or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.

This document obsoletes RFC 6536.

 draft-ietf-netconf-rfc6536bis-09 RFC6536 STD0091 INTERNET STANDARD INTERNET STANDARD IETF ops netconf 10.17487/RFC8341 RFC8342 Network Management Datastore Architecture (NMDA) M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2018 ASCII HTML 44 YANG NETCONF RESTCONF Network Management

Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.

 draft-ietf-netmod-revised-datastores-10 RFC7950 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8342 10.17487/RFC8342 RFC8343 A YANG Data Model for Interface Management M. Bjorklund March 2018 ASCII HTML 49

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 definitions for configuration and system state (status information and counters for the collection of statistics).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document obsoletes RFC 7223.

 draft-ietf-netmod-rfc7223bis-03 RFC7223 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8343 RFC8344 A YANG Data Model for IP Management M. Bjorklund March 2018 ASCII HTML 34

This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.

The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.

This document obsoletes RFC 7277.

 draft-ietf-netmod-rfc7277bis-03 RFC7277 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8344 RFC8345 A YANG Data Model for Network Topologies A. Clemm J. Medved R. Varga N. Bahadur H. Ananthakrishnan X. Liu March 2018 ASCII HTML 57 topology

This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.

 draft-ietf-i2rs-yang-network-topo-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8345 RFC8346 A YANG Data Model for Layer 3 Topologies A. Clemm J. Medved R. Varga X. Liu H. Ananthakrishnan N. Bahadur March 2018 ASCII HTML 35 topology

This document defines a YANG data model for Layer 3 network topologies.

 draft-ietf-i2rs-yang-l3-topology-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8346 RFC8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) X. Liu Editor A. Kyparlis R. Parikh A. Lindem M. Zhang March 2018 ASCII HTML 45 Network Management Routing YANG

This document describes a data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered.

 draft-ietf-rtgwg-yang-vrrp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8347 RFC8348 A YANG Data Model for Hardware Management A. Bierman M. Bjorklund J. Dong D. Romascanu March 2018 ASCII HTML 60 ENTITY-MIB

This document defines a YANG data model for the management of hardware on a single server.

 draft-ietf-netmod-entity-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8348 RFC8349 A YANG Data Model for Routing Management (NMDA Version) L. Lhotka A. Lindem Y. Qu March 2018 ASCII HTML 80 configuration IPv6 Router Advertisements NETCONF RESTCONF

This document specifies 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.

The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.

 draft-ietf-netmod-rfc8022bis-11 RFC8022 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8349 RFC8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) R. Zhang R. Pazhyannur S. Gundavelli Z. Cao H. Deng Z. Du April 2018 ASCII HTML 29 Wi-Fi WLAN PMIP GRE

Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP Data Channel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP.

 draft-ietf-opsawg-capwap-alt-tunnel-12 EXPERIMENTAL EXPERIMENTAL IETF ops opsawg 10.17487/RFC8350 RFC8351 The PKCS #8 EncryptedPrivateKeyInfo Media Type S. Leonard June 2018 ASCII HTML 7

This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value.

 draft-seantek-pkcs8-encrypted-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8351 RFC8352 Energy-Efficient Features of Internet of Things Protocols C. Gomez M. Kovatsch H. Tian Z. Cao Editor April 2018 ASCII HTML 24 IoT Radio Duty Cycling 6LoWPAN 6Lo CoAP RPL

This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.

 draft-ietf-lwig-energy-efficient-08 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC8352 RFC8353 Generic Security Service API Version 2: Java Bindings Update M. Upadhyay S. Malkani W. Wang May 2018 ASCII HTML 96 JGSS GSS-API

The Generic Security Services Application Programming 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 Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fail, it has a chance to emit an error token that can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version.

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 (SPKM)" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121).

 draft-ietf-kitten-rfc5653bis-07 RFC5653 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8353 RFC8354 Use Cases for IPv6 Source Packet Routing in Networking (SPRING) J. Brzozowski J. Leddy C. Filsfils R. Maglione Editor M. Townsley March 2018 ASCII HTML 9

The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in an IPv6-only environment.

 draft-ietf-spring-ipv6-use-cases-12 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8354 RFC8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks C. Filsfils Editor S. Previdi Editor B. Decraene R. Shakir March 2018 ASCII HTML 13 SEGMENT ROUTING RESILIENCY PROTECTION CONVERGENCE

This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks.

 draft-ietf-spring-resiliency-use-cases-12 INFORMATIONAL INFORMATIONAL IETF rtg spring http://www.rfc-editor.org/errata_search.php?rfc=8355 10.17487/RFC8355 RFC8356 Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) D. Dhody D. King A. Farrel March 2018 ASCII HTML 7 PCE PCEP IANA Experimental

IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.

This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.

 draft-ietf-pce-pcep-exp-codepoints-05 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8356 RFC8357 Generalized UDP Source Port for DHCP Relay N. Shen E. Chen March 2018 ASCII HTML 10

This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications. The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.

 draft-ietf-dhc-relay-port-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8357 RFC8358 Update to Digital Signatures on Internet-Draft Documents R. Housley March 2018 ASCII HTML 9 cms cryptographic message syntax detached signature

RFC 5485 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.

The RFC Editor recently published the first RFC that includes non- ASCII characters in a text file. The conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.

This document updates RFC 5485.

 draft-housley-id-sig-update-03 RFC5485 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8358 10.17487/RFC8358 RFC8359 Network-Assigned Upstream Label X. Zhang Editor V. Beeram Editor I. Bryskin D. Ceccarelli O. Gonzalez de Dios March 2018 ASCII HTML 10

This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object.

 draft-ietf-teas-network-assigned-upstream-label-12 RFC3471 RFC3473 RFC6205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8359 RFC8360 Resource Public Key Infrastructure (RPKI) Validation Reconsidered G. Huston G. Michaelson C. Martinez T. Bruijnzeels A. Newton D. Shaw April 2018 ASCII HTML 29

This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.

The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.

It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.

This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.

Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.

 draft-ietf-sidr-rpki-validation-reconsidered-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=8360 10.17487/RFC8360 RFC8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic W. Hao Y. Li M. Durrani S. Gupta A. Qu April 2018 ASCII HTML 17 TRILL RBridge CMT LAALP

In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325). To avoid RPF check failure on an RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325.

 draft-ietf-trill-centralized-replication-13 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8361 RFC8362 OSPFv3 Link State Advertisement (LSA) Extensibility A. Lindem A. Roy D. Goethals V. Reddy Vallem F. Baker April 2018 ASCII HTML 33

OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.

This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.

 draft-ietf-ospf-ospfv3-lsa-extend-23 RFC5340 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8362 RFC8363 GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks X. Zhang H. Zheng R. Casellas O. Gonzalez de Dios D. Ceccarelli May 2018 ASCII HTML 17 flexi-grid OSPF-TE central frequency frequency slot channel spacing

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 channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as "flexi-grid".

Based on the characteristics of flexi-grid defined in G.694.1 and in RFCs 7698 and 7699, this document describes the Open Shortest Path First - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.

 draft-ietf-ccamp-flexible-grid-ospf-ext-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8363 RFC8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD) IJ. Wijnands S. Venaas M. Brig A. Jonasson March 2018 ASCII HTML 18 Multicast

Protocol Independent Multicast - Sparse Mode (PIM-SM) uses a Rendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM Flooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets.

 draft-ietf-pim-source-discovery-bsr-12 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC8364 RFC8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) A. Sajassi Editor J. Drake Editor N. Bitar R. Shekhar J. Uttaro W. Henderickx March 2018 ASCII HTML 33 EVPN Control Plane with VxLAN Encapsulation EVPN Control Plane with NvGRE Encapsulation

This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.

 draft-ietf-bess-evpn-overlay-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8365 10.17487/RFC8365 RFC8366 A Voucher Artifact for Bootstrapping Protocols K. Watsen M. Richardson M. Pritikin T. Eckert May 2018 ASCII HTML 23 voucher

This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.

 draft-ietf-anima-voucher-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops anima 10.17487/RFC8366 RFC8367 Wrongful Termination of Internet Protocol (IP) Packets T. Mizrahi J. Yallouz April 1 2018 ASCII HTML 6

Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them.

 draft-tj-wrongful-termination-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8367 RFC8368 Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) T. Eckert Editor M. Behringer May 2018 ASCII HTML 24

Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.

Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.

This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.

 draft-ietf-anima-stable-connectivity-10 INFORMATIONAL INFORMATIONAL IETF ops anima 10.17487/RFC8368 RFC8369 Internationalizing IPv6 Using 128-Bit Unicode H. Kaplan April 1 2018 ASCII HTML 11

It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future 128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6.

 draft-kaplan-unicode-ipv6-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8369 10.17487/RFC8369 RFC8370 Techniques to Improve the Scalability of RSVP-TE Deployments V. Beeram Editor I. Minei R. Shakir D. Pacella T. Saad May 2018 ASCII HTML 11 RSVP-TE Scaling RI-RSVP Per-Peer Flow Control

Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.

This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.

 draft-ietf-teas-rsvp-te-scaling-rec-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8370 RFC8371 Mobile Node Identifier Types for MIPv6 C. Perkins V. Devarapalli July 2018 ASCII HTML 16 Mobility IPv6 Authentication

This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283.

 draft-ietf-dmm-4283mnids-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8371 RFC8372 MPLS Flow Identification Considerations S. Bryant C. Pignataro M. Chen Z. Li G. Mirsky May 2018 ASCII HTML 11 OAM performance monitoring flow identification

This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.

 draft-ietf-mpls-flow-ident-07 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8372 RFC8373 Negotiating Human Language in Real-Time Communications R. Gellens May 2018 ASCII HTML 13 SDP language human language SIP SLIM

Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).

This document describes the need as well as a solution that uses new SDP media attributes.

 draft-ietf-slim-negotiating-human-language-24 PROPOSED STANDARD PROPOSED STANDARD IETF art slim http://www.rfc-editor.org/errata_search.php?rfc=8373 10.17487/RFC8373 RFC8374 BGPsec Design Choices and Summary of Supporting Discussions K. Sriram Editor April 2018 ASCII HTML 50 Internet Routing Security

This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification). The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes.

 draft-sriram-bgpsec-design-choices-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8374 RFC8375 Special-Use Domain 'home.arpa.' P. Pfister T. Lemon May 2018 ASCII HTML 12 Homenet TLD RFC6761 .home.arpa

This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.

 draft-ietf-homenet-dot-14 RFC7788 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC8375 RFC8376 Low-Power Wide Area Network (LPWAN) Overview S. Farrell Editor May 2018 ASCII HTML 43 Low Power Wide Area Network Overview

Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.

 draft-ietf-lpwan-overview-10 INFORMATIONAL INFORMATIONAL IETF int lpwan 10.17487/RFC8376 RFC8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology D. Eastlake 3rd M. Zhang A. Banerjee July 2018 ASCII HTML 20

This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177.

 draft-ietf-trill-multi-topology-06 RFC6325 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8377 RFC8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast V. Moreno D. Farinacci May 2018 ASCII HTML 21 LISP deployment

When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.

 draft-ietf-lisp-signal-free-multicast-09 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8378 RFC8379 OSPF Graceful Link Shutdown S. Hegde P. Sarkar H. Gredler M. Nanduri L. Jalil May 2018 ASCII HTML 17 MPLS IGP OSPF

When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.

It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.

This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.

 draft-ietf-ospf-link-overload-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8379 RFC8380 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation L. Dunbar D. Eastlake 3rd R. Perlman May 2018 ASCII HTML 10 Directory Nickname

This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service.

 draft-ietf-trill-directory-assisted-encap-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8380 RFC8381 Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol D. Eastlake 3rd Y. Li W. Hao A. Banerjee May 2018 ASCII HTML 11 OUI CID

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges (Routing Bridges). TRILL includes a general mechanism, called an RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor-specific messages over the RBridge Channel facility.

 draft-ietf-trill-vendor-channel-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8381 RFC8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media D. Hayes Editor S. Ferlin M. Welzl K. Hiorth June 2018 ASCII HTML 25 SBD

This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed.

 draft-ietf-rmcat-sbd-11 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8382 RFC8383 Transparent Interconnection of Lots of Links (TRILL): Address Flush Message W. Hao D. Eastlake 3rd Y. Li M. Umair May 2018 ASCII HTML 20 convergence VLAN data label FGL

The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.

This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting (see Section 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change.

 draft-ietf-trill-address-flush-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8383 RFC8384 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes R. Perlman F. Hu D. Eastlake 3rd T. Liao July 2018 ASCII HTML 17 TRILL Smart Endnode

This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that are Fine-Grained Label (FGL) aware.

 draft-ietf-trill-smart-endnodes-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8384 RFC8385 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS M. Umair S. Kingston Smiler D. Eastlake 3rd L. Yong June 2018 ASCII HTML 16 VPLS VPTS TIR

This document specifies methods to interconnect multiple TRILL (Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (Virtual Private LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network.

 draft-ietf-trill-transport-over-mpls-08 INFORMATIONAL INFORMATIONAL IETF rtg trill 10.17487/RFC8385 RFC8386 Privacy Considerations for Protocols Relying on IP Broadcast or Multicast R. Winter M. Faath F. Weisshaar May 2018 ASCII HTML 13 IP broadcasts multicast privacy considerations

A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content. Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols.

 draft-ietf-intarea-broadcast-consider-09 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC8386 RFC8387 Practical Considerations and Implementation Experiences in Securing Smart Object Networks M. Sethi J. Arkko A. Keranen H. Back May 2018 ASCII HTML 33 IoT security integrity signing ECC CoAP asymmetric cryptography

This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource- constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches.

 draft-ietf-lwig-crypto-sensors-06 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC8387 RFC8388 Usage and Applicability of BGP MPLS-Based Ethernet VPN J. Rabadan Editor S. Palislamovic W. Henderickx A. Sajassi J. Uttaro May 2018 ASCII HTML 31 EVPN

This document discusses the usage and applicability of BGP MPLS-based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.

 draft-ietf-bess-evpn-usage-09 INFORMATIONAL INFORMATIONAL IETF rtg bess 10.17487/RFC8388 RFC8389 Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E) Y. Fu S. Jiang B. Liu J. Dong Y. Chen December 2018 ASCII HTML 16 IPv6 MAP

This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols.

 draft-ietf-softwire-map-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8389 RFC8390 RSVP-TE Path Diversity Using Exclude Route Z. Ali Editor G. Swallow Editor F. Zhang Editor D. Beller Editor July 2018 ASCII HTML 26 LSP diversity

RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject (EXRS).

For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing (reference) LSP, before the new path is established, is not considered.

 draft-ietf-teas-lsp-diversity-10 RFC4874 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8390 RFC8391 XMSS: eXtended Merkle Signature Scheme A. Huelsing D. Butin S. Gazdag J. Rijneveld A. Mohaisen May 2018 ASCII HTML 74 Digital signature cryptography post-quantum cryptography Hash-based signatures Merkle signatures Merkle tree hash function Winternitz Winternitz one-time signature scheme WOTS W-OTS WOTS+ W-OTS+ XMSS-MT multi-tree XMSS

This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.

 draft-irtf-cfrg-xmss-hash-based-signatures-12 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8391 10.17487/RFC8391 RFC8392 CBOR Web Token (CWT) M. Jones E. Wahlstroem S. Erdtman H. Tschofenig May 2018 ASCII HTML 25 JSON Web Token JWT Claims Concise Binary Object Representation CBOR CBOR Object Signing and Encryption COSE OAuth ACE

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.

 draft-ietf-ace-cbor-web-token-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace http://www.rfc-editor.org/errata_search.php?rfc=8392 10.17487/RFC8392 RFC8393 Operating the Network Service Header (NSH) with Next Protocol "None" A. Farrel J. Drake May 2018 ASCII HTML 12 Service Function Chaining Network Service Header Metadata

This document describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None".

This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.

 draft-farrel-sfc-convent-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc 10.17487/RFC8393 RFC8394 Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements Y. Li D. Eastlake 3rd L. Kreeger T. Narten D. Black May 2018 ASCII HTML 26 NVO3 VDP

In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.

One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements.

 draft-ietf-nvo3-hpvr2nve-cp-req-17 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8394 RFC8395 Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels K. Patel S. Boutros J. Liste B. Wen J. Rabadan June 2018 ASCII HTML 9

This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks (L2VPNs). This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.

 draft-ietf-bess-fat-pw-bgp-04 RFC4761 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8395 RFC8396 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework J. Peterson T. McGarry July 2018 ASCII HTML 23 SIP Problem Statement Real-Time Communication

The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs.

 draft-ietf-modern-problem-framework-04 INFORMATIONAL INFORMATIONAL IETF art modern 10.17487/RFC8396 RFC8397 Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames M. Zhang D. Eastlake 3rd R. Perlman H. Zhai D. Liu May 2018 ASCII HTML 16 Aggregated Global Tree Local Tree

TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.

 draft-ietf-trill-multilevel-unique-nickname-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8397 RFC8398 Internationalized Email Addresses in X.509 Certificates A. Melnikov Editor W. Chuang Editor May 2018 ASCII HTML 12 EAI PKIX emal address

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.

This document updates RFC 5280.

 draft-ietf-lamps-eai-addresses-18 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=8398 10.17487/RFC8398 RFC8399 Internationalization Updates to RFC 5280 R. Housley May 2018 ASCII HTML 9

The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.

 draft-ietf-lamps-rfc5280-i18n-update-04 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8399 RFC8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection H. Chen A. Liu T. Saad F. Xu L. Huang June 2018 ASCII HTML 21 FRR Fast Reroute

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP).

 draft-ietf-teas-rsvp-egress-protection-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas http://www.rfc-editor.org/errata_search.php?rfc=8400 10.17487/RFC8400 RFC8401 Bit Index Explicit Replication (BIER) Support via IS-IS L. Ginsberg Editor T. Przygienda S. Aldrin Z. Zhang June 2018 ASCII HTML 12

This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.

 draft-ietf-bier-isis-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8401 RFC8402 Segment Routing Architecture C. Filsfils Editor S. Previdi Editor L. Ginsberg B. Decraene S. Litkowski R. Shakir July 2018 ASCII HTML 32

Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.

SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.

SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.

 draft-ietf-spring-segment-routing-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC8402 RFC8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System R. Geib Editor C. Filsfils C. Pignataro Editor N. Kumar July 2018 ASCII HTML 19 Segment based Routing OAM LSP surveillance MPLS monitoring

This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.

 draft-ietf-spring-oam-usecase-10 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8403 RFC8404 Effects of Pervasive Encryption on Operators K. Moriarty Editor A. Morton Editor July 2018 ASCII HTML 53 NETCONF RESTCONF Monitoring Management Security Management Operations

Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.

 draft-mm-wg-effect-encrypt-25 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8404 RFC8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs B. Decraene S. Litkowski H. Gredler A. Lindem P. Francois C. Bowers June 2018 ASCII HTML 14

This document defines a standard algorithm to temporarily postpone or "back off" link-state IGP Shortest Path First (SPF) computations. This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.

Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally close IGP events.

 draft-ietf-rtgwg-backoff-algo-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8405 RFC8406 Taxonomy of Coding Techniques for Efficient Network Communications B. Adamson C. Adjih J. Bilbao V. Firoiu F. Fitzek S. Ghanem E. Lochin A. Masucci M-J. Montpetit M. Pedersen G. Peralta V. Roca Editor P. Saxena S. Sivakumar June 2018 ASCII HTML 15 Network Coding Taxonomy

This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents on Network Coding. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.

 draft-irtf-nwcrg-network-coding-taxonomy-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8406 RFC8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models A. Bierman October 2018 ASCII HTML 63 NETMOD NETCONF RESTCONF

This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.

 draft-ietf-netmod-rfc6087bis-20 RFC6087 BCP0216 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8407 10.17487/RFC8407 RFC8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages S. Sivabalan J. Tantsura I. Minei R. Varga J. Hardwick July 2018 ASCII HTML 12

A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.

 draft-ietf-pce-lsp-setup-type-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8408 RFC8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types I. Young Editor L. Johansson S. Cantor August 2018 ASCII HTML 12 REFEDS

This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.

This document is a product of the working group process of the Research and Education FEDerations (REFEDS) group.

 draft-young-entity-category-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8409 RFC8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure S. Josefsson J. Schaad August 2018 ASCII HTML 20 Elliptic Curve Cryptography Curve25519 Curve448 Goldilocks X.509 PKIX PKI OID ASN.1 EdDSA Ed25519 Ed448 X25519 X448

This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.

 draft-ietf-curdle-pkix-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8410 10.17487/RFC8410 RFC8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range J. Schaad R. Andrews August 2018 ASCII HTML 5

When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.

 draft-schaad-curdle-oid-registry-03 INFORMATIONAL INFORMATIONAL IETF sec curdle 10.17487/RFC8411 RFC8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC C. Schmidt D. Haynes C. Coffin D. Waltermire J. Fitzgerald-McKay July 2018 ASCII HTML 101 SWID PA-TNC NEA Software inventory

This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).

 draft-ietf-sacm-nea-swima-patnc-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec sacm 10.17487/RFC8412 RFC8413 Framework for Scheduled Use of Resources Y. Zhuang Q. Wu H. Chen A. Farrel July 2018 ASCII HTML 22 Traffic Engineering TE Label Switched Path LSP MPLS Path Computation Element PCE Software Defined Networking SDN

Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.

 draft-ietf-teas-scheduled-resources-07 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8413 RFC8414 OAuth 2.0 Authorization Server Metadata M. Jones N. Sakimura J. Bradley June 2018 ASCII HTML 23 OAuth Discovery Metadata Discovery Metadata Configuration Information Authorization Server WebFinger JavaScript Object Notation JSON JSON Web Token JWT

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

 draft-ietf-oauth-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8414 RFC8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) T. Mrugalski M. Siodelski B. Volz A. Yourtchenko M. Richardson S. Jiang T. Lemon T. Winters November 2018 ASCII HTML 154 DHCPv6 IPv6 DHCP

This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).

This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.

 draft-ietf-dhc-rfc3315bis-13 RFC3315 RFC3633 RFC3736 RFC4242 RFC7083 RFC7283 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8415 RFC8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM) D. Ma D. Mandelberg T. Bruijnzeels August 2018 ASCII HTML 17 RPKI Local Trust Anchor BGPsec

The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.

 draft-ietf-sidr-slurm-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8416 RFC8417 Security Event Token (SET) P. Hunt Editor M. Jones W. Denniss M. Ansari July 2018 ASCII HTML 28 Identity Security Event Token Claims JSON JSON Web Token JWT

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.

 draft-ietf-secevent-token-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec secevent 10.17487/RFC8417 RFC8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) R. Housley August 2018 ASCII HTML 18

This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).

 draft-ietf-curdle-cms-ecdh-new-curves-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8418 RFC8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) R. Housley August 2018 ASCII HTML 9

This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS.

 draft-ietf-curdle-cms-eddsa-signatures-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8419 10.17487/RFC8419 RFC8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Nir August 2018 ASCII HTML 5

This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).

 draft-ietf-ipsecme-eddsa-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8420 RFC8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) P. Martinsen T. Reddy P. Patil July 2018 ASCII HTML 9

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 backward compatible with the original ICE specification (see RFC 5245).

 draft-ietf-ice-dualstack-fairness-07 BCP0217 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art ice 10.17487/RFC8421 RFC8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Y. Nir S. Josefsson M. Pegourie-Gonnard August 2018 ASCII HTML 34 ECDSA EdDSA

This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.

This document obsoletes RFC 4492.

 draft-ietf-tls-rfc4492bis-17 RFC4492 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8422 10.17487/RFC8422 RFC8423 Reclassification of Suite B Documents to Historic Status R. Housley L. Zieglar July 2018 ASCII HTML 8 x.509 v3 certificates x.509 v2 certificate revocation lists crl UI suites user interface suites elliptic curve ike cryptographic algorithm policy security application suite b cryptography cmc suite b x.509 public key certificates cryptographic algorithm policy nsa

This document reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239, 6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430.

 draft-housley-suite-b-to-historic-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8423 10.17487/RFC8423 RFC8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection H. Chen Editor R. Torvi Editor August 2018 ASCII HTML 28 Head Protection

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.

 draft-ietf-teas-rsvp-ingress-protection-17 EXPERIMENTAL EXPERIMENTAL IETF rtg teas 10.17487/RFC8424 RFC8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags O. Troan July 2018 ASCII HTML 4

The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861.

 draft-ietf-6man-ndpioiana-04 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8425 RFC8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence H. Sitaraman Editor V. Beeram I. Minei S. Sivabalan July 2018 ASCII HTML 12

Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.

 draft-ietf-teas-sr-rsvp-coexistence-rec-04 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8426 RFC8427 Representing DNS Messages in JSON P. Hoffman July 2018 ASCII HTML 15

Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.

 draft-hoffman-dns-in-json-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8427 10.17487/RFC8427 RFC8428 Sensor Measurement Lists (SenML) C. Jennings Z. Shelby J. Arkko A. Keranen C. Bormann August 2018 ASCII HTML 54 IoT data model

This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.

 draft-ietf-core-senml-16 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8428 RFC8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos B. Kaduk M. Short October 2018 ASCII HTML 10 GSS-API GSS

The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.

 draft-ietf-curdle-des-des-des-die-die-die-05 RFC3961 RFC4120 BCP0218 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec curdle 10.17487/RFC8429 RFC8430 RIB Information Model N. Bahadur Editor S. Kini Editor J. Medved September 2018 ASCII HTML 28 RIB info model

Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.

 draft-ietf-i2rs-rib-info-model-17 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8430 RFC8431 A YANG Data Model for the Routing Information Base (RIB) L. Wang M. Chen A. Dass H. Ananthakrishnan S. Kini N. Bahadur September 2018 ASCII HTML 71

This document defines a YANG data model for the Routing Information Base (RIB) that aligns with the Interface to the Routing System (I2RS) RIB information model.

 draft-ietf-i2rs-rib-data-model-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8431 RFC8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters J. Ahlberg Editor M. Ye Editor X. Li LM. Contreras CJ. Bernardos October 2018 ASCII HTML 20 Microwave millimeter waves YANG Model interface management

The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.

This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG data model.

The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology.

 draft-ietf-ccamp-microwave-framework-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC8432 RFC8433 A Simpler Method for Resolving Alert-Info URNs D. Worley August 2018 ASCII HTML 45 Alert-Info audio signals call signaling call transfer resolution signaling signals SIP URN visual signals

The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.

RFC 7462 describes a non-normative algorithm for signal selection. This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.

 draft-worley-alert-info-fsm-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8433 RFC8434 Requirements for Parallel NFS (pNFS) Layout Types T. Haynes August 2018 ASCII HTML 17 NFSv4

This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.

 draft-ietf-nfsv4-layout-types-13 RFC5661 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8434 RFC8435 Parallel NFS (pNFS) Flexible File Layout B. Halevy T. Haynes August 2018 ASCII HTML 42 NFSv4

Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.

 draft-ietf-nfsv4-flex-files-19 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8435 RFC8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry G. Fairhurst August 2018 ASCII HTML 7 Diffserv DSCP

The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.

This update to RFC 2474 changes the IANA registration policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes.

 draft-ietf-tsvwg-iana-dscp-registry-08 RFC2474 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8436 RFC8437 IMAP UNAUTHENTICATE Extension for Connection Reuse C. Newman August 2018 ASCII HTML 11 IMAP unauthenticate SASL login authenticate authentication

This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.

 draft-ietf-extra-imap-unauth-01 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8437 RFC8438 IMAP Extension for STATUS=SIZE S. Bosch August 2018 ASCII HTML 6 imap status size

This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.

 draft-ietf-extra-imap-status-size-02 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8438 RFC8439 ChaCha20 and Poly1305 for IETF Protocols Y. Nir A. Langley June 2018 ASCII HTML 46 CHACHA CHACHA20 POLY1305 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.

RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.

 draft-nir-cfrg-rfc7539bis-04 RFC7539 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8439 10.17487/RFC8439 RFC8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST K. Murchison B. Gondwana August 2018 ASCII HTML 6 IMAP4 LIST MYRIGHTS

This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.

 draft-ietf-extra-imap-list-myrights-07 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8440 RFC8441 Bootstrapping WebSockets with HTTP/2 P. McManus September 2018 ASCII HTML 8 CONNECT SETTINGS

This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.

 draft-ietf-httpbis-h2-websockets-07 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8441 10.17487/RFC8441 RFC8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2 J. Mattsson D. Migault September 2018 ASCII HTML 7

This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integrity protection.

 draft-ietf-tls-ecdhe-psk-aead-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8442 RFC8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization R. Singh M. Dolly S. Das A. Nguyen August 2018 ASCII HTML 10 SIP Resource-Priority Resource Priority Header (rph) JSON Web Token Claim Identity header Authentication Service Assertion Verification Service

This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.

 draft-ietf-stir-rph-06 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC8443 RFC8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER) P. Psenak Editor N. Kumar IJ. Wijnands A. Dolganow T. Przygienda J. Zhang S. Aldrin November 2018 ASCII HTML 12

Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.

This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.

 draft-ietf-bier-ospf-bier-extensions-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8444 RFC8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal A. Keranen C. Holmberg J. Rosenberg July 2018 ASCII HTML 100 NAT

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. 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).

This document obsoletes RFC 5245.

 draft-ietf-ice-rfc5245bis-20 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF art ice 10.17487/RFC8445 RFC8446 The Transport Layer Security (TLS) Protocol Version 1.3 E. Rescorla August 2018 ASCII HTML 160 international data algorithm symmetric transport protocol layer authentication privacy

This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.

This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

 draft-ietf-tls-tls13-28 RFC5077 RFC5246 RFC6961 RFC5705 RFC6066 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8446 10.17487/RFC8446 RFC8447 IANA Registry Updates for TLS and DTLS J. Salowey S. Turner August 2018 ASCII HTML 20

This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.

This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.

 draft-ietf-tls-iana-registry-updates-05 RFC3749 RFC4680 RFC5077 RFC5246 RFC5705 RFC5878 RFC6520 RFC7301 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8447 RFC8448 Example Handshake Traces for TLS 1.3 M. Thomson January 2019 ASCII HTML 68

This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.

 draft-ietf-tls-tls13-vectors-07 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8448 10.17487/RFC8448 RFC8449 Record Size Limit Extension for TLS M. Thomson August 2018 ASCII HTML 8 TLS record IoT encryption

An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.

This replaces the maximum fragment length extension defined in RFC 6066.

 draft-ietf-tls-record-limit-03 RFC6066 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8449 RFC8450 RTP Payload Format for VC-2 High Quality (HQ) Profile J. Weaver October 2018 ASCII HTML 24 rtp vc-2 VC2 dirac

This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.

The HQ profile of VC-2 is intended for low-latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).

 draft-ietf-payload-rtp-vc2hq-08 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC8450 RFC8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API V. Singh R. Huang R. Even D. Romascanu L. Deng September 2018 ASCII HTML 18 Web real-time communication

This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTP Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and Extended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.

 draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-10 INFORMATIONAL INFORMATIONAL IETF art xrblock 10.17487/RFC8451 RFC8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption S. Gueron A. Langley Y. Lindell April 2019 ASCII HTML 42 authenticated encryption aead aes gcm siv

This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.

This document is the product of the Crypto Forum Research Group.

 draft-irtf-cfrg-gcmsiv-09 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8452 10.17487/RFC8452 RFC8453 Framework for Abstraction and Control of TE Networks (ACTN) D. Ceccarelli Editor Y. Lee Editor August 2018 ASCII HTML 42 SDN Orchestration

Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.

Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.

This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.

 draft-ietf-teas-actn-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8453 RFC8454 Information Model for Abstraction and Control of TE Networks (ACTN) Y. Lee S. Belotti D. Dhody D. Ceccarelli B. Yoon September 2018 ASCII HTML 23

This document provides an information model for Abstraction and Control of TE Networks (ACTN).

 draft-ietf-teas-actn-info-model-10 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8454 RFC8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance V. Bhuvaneswaran A. Basil M. Tassinari V. Manral S. Banks October 2018 ASCII HTML 23

This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.

 draft-ietf-bmwg-sdn-controller-benchmark-term-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8455 RFC8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance V. Bhuvaneswaran A. Basil M. Tassinari V. Manral S. Banks October 2018 ASCII HTML 64

This document defines methodologies for benchmarking the control-plane performance of Software-Defined Networking (SDN) Controllers. The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.

 draft-ietf-bmwg-sdn-controller-benchmark-meth-09 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8456 RFC8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute B. Leiba Editor September 2018 ASCII HTML 11 IMAP attributes

RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788.

 draft-ietf-extra-specialuse-important-04 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8457 RFC8458 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2018 ASCII HTML 18 Network Working Group National bibliography numbers Uniform resource names

National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such as International Standard Book Number (ISBN).

A Uniform Resource Name (URN) namespace for NBNs was established in 2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems.

This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included.

 draft-hakala-urn-nbn-rfc3188bis-02 RFC3188 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8458 RFC8459 Hierarchical Service Function Chaining (hSFC) D. Dolson S. Homma D. Lopez M. Boucadair September 2018 ASCII HTML 29 Scalability SFC-enabled domain multiple control domains SFC complexity Hierarchy service delivery service complications service offering differentiated services large scale network

Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.

The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.

 draft-ietf-sfc-hierarchical-11 EXPERIMENTAL EXPERIMENTAL IETF rtg sfc 10.17487/RFC8459 RFC8460 SMTP TLS Reporting D. Margolis A. Brotman B. Ramakrishnan J. Jones M. Risher September 2018 ASCII HTML 34 DANE MTA-STS

A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.

 draft-ietf-uta-smtp-tlsrpt-23 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC8460 RFC8461 SMTP MTA Strict Transport Security (MTA-STS) D. Margolis M. Risher B. Ramakrishnan A. Brotman J. Jones September 2018 ASCII HTML 29 SMTP STARTTLS Mail Security

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

 draft-ietf-uta-mta-sts-21 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC8461 RFC8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) N. Rooney S. Dawkins Editor October 2018 ASCII HTML 28 Networks

The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.

The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and Content Delivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.

A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.

 draft-iab-marnew-report-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8462 RFC8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) J. Levine September 2018 ASCII HTML 7 DKIM ed25519 cryptography

This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm.

 draft-ietf-dcrup-dkim-crypto-14 RFC6376 PROPOSED STANDARD PROPOSED STANDARD IETF art dcrup 10.17487/RFC8463 RFC8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID) R. Atarius September 2018 ASCII HTML 10 MEID instance ID IMS

This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.

 draft-atarius-dispatch-meid-urn-18 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8464 RFC8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID R. Atarius Editor September 2018 ASCII HTML 8 MEID instance ID IMS

This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID 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-atarius-dispatch-meid-urn-as-instanceid-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8465 RFC8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery B. Wen G. Fioccola Editor C. Xie L. Jalil October 2018 ASCII HTML 158 L2SM Service Model L2VPN SM L2VPN Service Model

This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.

The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.

The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.

 draft-ietf-l2sm-l2vpn-service-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops l2sm http://www.rfc-editor.org/errata_search.php?rfc=8466 10.17487/RFC8466 RFC8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0)) A. Mayrhofer October 2018 ASCII HTML 9 security

RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.

 draft-ietf-dprive-padding-policy-06 EXPERIMENTAL EXPERIMENTAL IETF int dprive 10.17487/RFC8467 RFC8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework A. Morton J. Fabini N. Elkins M. Ackermann V. Hegde November 2018 ASCII HTML 15 Measurement Methodology Standard-Formed Packet Type-P Minimal Packet IPv6 Transition

This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation.

 draft-ietf-ippm-2330-ipv6-06 RFC2330 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC8468 RFC8469 Recommendation to Use the Ethernet Control Word S. Bryant A. Malis I. Bagdonas November 2018 ASCII HTML 9 pseudowire PW CW ECMP MAC address out of order ordering

The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR). This may lead to the selection of the wrong equal-cost multipath (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.

This document updates RFC 4448.

 draft-ietf-pals-ethernet-cw-07 RFC4448 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8469 RFC8470 Using Early Data in HTTP M. Thomson M. Nottingham W. Tarreau September 2018 ASCII HTML 12 HTTP TLS replay retry 0-RTT early data status code

Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.

 draft-ietf-httpbis-replay-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8470 RFC8471 The Token Binding Protocol Version 1.0 A. Popov Editor M. Nystroem D. Balfanz J. Hodges October 2018 ASCII HTML 18 Token cookie TLS export replay

This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.

 draft-ietf-tokbind-protocol-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8471 RFC8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation A. Popov Editor M. Nystroem D. Balfanz October 2018 ASCII HTML 8 Cookie TLS export replay

This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document.

 draft-ietf-tokbind-negotiation-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8472 RFC8473 Token Binding over HTTP A. Popov M. Nystroem D. Balfanz Editor N. Harper J. Hodges October 2018 ASCII HTML 25 Cookie TLS OAuth export replay

This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.

We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.

Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.

This document is a companion document to "The Token Binding Protocol Version 1.0" (RFC 8471).

 draft-ietf-tokbind-https-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8473 RFC8474 IMAP Extension for Object Identifiers B. Gondwana Editor September 2018 ASCII HTML 16 IMAP email

This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.

 draft-ietf-extra-imap-objectid-08 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8474 RFC8475 Using Conditional Router Advertisements for Enterprise Multihoming J. Linkova M. Stucchi October 2018 ASCII HTML 21 ipv6

This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.

 draft-ietf-v6ops-conditional-ras-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8475 RFC8476 Signaling Maximum SID Depth (MSD) Using OSPF J. Tantsura U. Chunduri S. Aldrin P. Psenak December 2018 ASCII HTML 11 BGP-LS SID MSD OSPF

This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.

 draft-ietf-ospf-segment-routing-msd-25 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8476 RFC8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016 J. Jimenez H. Tschofenig D. Thaler October 2018 ASCII HTML 18 data model

This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the 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-iotsi-workshop-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8477 RFC8478 Zstandard Compression and the application/zstd Media Type Y. Collet M. Kucherawy Editor October 2018 ASCII HTML 54 Compression

Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME).

Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.

 draft-kucherawy-dispatch-zstd-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8478 10.17487/RFC8478 RFC8479 Storing Validation Parameters in PKCS#8 N. Mavrogiannopoulos September 2018 ASCII HTML 8 private keys validation parameters PKCS#8

This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information Syntax Specification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-Key Information Syntax Specification as defined in RFC 5958.

The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard.

 draft-mavrogiannopoulos-pkcs8-validated-parameters-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8479 RFC8480 6TiSCH Operation Sublayer (6top) Protocol (6P) Q. Wang Editor X. Vilajosana T. Watteyne November 2018 ASCII HTML 50 schedule management distributed scheduling time synchronized channel hopping scheduling

This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.

 draft-ietf-6tisch-6top-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 6tisch 10.17487/RFC8480 RFC8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) R. Bush September 2018 ASCII HTML 5 security routing

Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.

 draft-ietf-sidrops-ov-clarify-05 RFC6811 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8481 RFC8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY J. Abley O. Gudmundsson M. Majkowski E. Hunt January 2019 ASCII HTML 10 DNS ANY REFUSE DDOS ABUSE

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.

This document updates RFCs 1034 and 1035.

 draft-ietf-dnsop-refuse-any-07 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8482 RFC8483 Yeti DNS Testbed L. Song Editor D. Liu P. Vixie A. Kato S. Kerr October 2018 ASCII HTML 39 Root Server DNSSEC IPv6

Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet's Domain Name System is designed and built).

 draft-song-yeti-testbed-experience-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8483 RFC8484 DNS Queries over HTTPS (DoH) P. Hoffman P. McManus October 2018 ASCII HTML 21 DNS HTTP DoH

This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

 draft-ietf-doh-dns-over-https-14 PROPOSED STANDARD PROPOSED STANDARD IETF art doh http://www.rfc-editor.org/errata_search.php?rfc=8484 10.17487/RFC8484 RFC8485 Vectors of Trust J. Richer Editor L. Johansson October 2018 ASCII HTML 21

This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction.

 draft-richer-vectors-of-trust-15 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8485 RFC8486 Ambisonics in an Ogg Opus Container J. Skoglund M. Graczyk October 2018 ASCII HTML 10 spatial audio lossy compression

This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.

 draft-ietf-codec-ambisonics-10 RFC7845 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC8486 RFC8487 Mtrace Version 2: Traceroute Facility for IP Multicast H. Asaeda K. Meyer W. Lee. Ed. October 2018 ASCII HTML 41 multicast mtrace mtrace2 traceroute PIM

This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.

 draft-ietf-mboned-mtrace-v2-26 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC8487 RFC8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation O. Muravskiy T. Bruijnzeels December 2018 ASCII HTML 17 RPKI validation RRDP

This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.

 draft-ietf-sidrops-rpki-tree-validation-03 INFORMATIONAL INFORMATIONAL IETF ops sidrops 10.17487/RFC8488 RFC8490 DNS Stateful Operations R. Bellis S. Cheshire J. Dickinson S. Dickinson T. Lemon T. Pusateri March 2019 ASCII HTML 64

This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.

 draft-ietf-dnsop-session-signal-20 RFC1035 RFC7766 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8490 RFC8491 Signaling Maximum SID Depth (MSD) Using IS-IS J. Tantsura U. Chunduri S. Aldrin L. Ginsberg November 2018 ASCII HTML 10 BGP-LS SID MSD IS-IS

This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.

 draft-ietf-isis-segment-routing-msd-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8491 RFC8492 Secure Password Ciphersuites for Transport Layer Security (TLS) D. Harkins Editor February 2019 ASCII HTML 40 Password Authenticated Key Exchange Dictionary Attack Authentication TLS

This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.

 draft-harkins-tls-dragonfly-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8492 10.17487/RFC8492 RFC8493 The BagIt File Packaging Format (V1.0) J. Kunze J. Littman E. Madden J. Scancella C. Adams October 2018 ASCII HTML 25

This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive metadata "tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer.

 draft-kunze-bagit-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8493 10.17487/RFC8493 RFC8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142 D. Wilson A. Melnikov Editor November 2018 ASCII HTML 19 P_MUL

Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).

This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.

This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.

 draft-melnikov-email-over-pmul-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8494 RFC8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP) J. Gould K. Feher November 2018 ASCII HTML 17

This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and "transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".

 draft-ietf-regext-allocation-token-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8495 RFC8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP) D. York T. Asveren October 2018 ASCII HTML 11 p-header

This text documents the current usage of P-Charge-Info, an existing Session Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged. This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA.

 draft-york-p-charge-info-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8496 RFC8497 Marking SIP Messages to Be Logged P. Dawes C. Arunachalam November 2018 ASCII HTML 46 SIP logme troubleshooting debug debugging logging

SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.

This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.

 draft-ietf-insipid-logme-marking-13 PROPOSED STANDARD PROPOSED STANDARD IETF art insipid 10.17487/RFC8497 RFC8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) M. Mohali February 2019 ASCII HTML 15 SIP RFC5502 P- 3GPP IMS Served-User orig-cdiv

The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.

 draft-ietf-sipcore-originating-cdiv-parameter-08 RFC5502 INFORMATIONAL INFORMATIONAL IETF art sipcore 10.17487/RFC8498 RFC8499 DNS Terminology P. Hoffman A. Sullivan K. Fujiwara January 2019 ASCII HTML 50 vocabulary domain name system

The Domain Name System (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.

This document obsoletes RFC 7719 and updates RFC 2308.

 draft-ietf-dnsop-terminology-bis-14 RFC7719 RFC2308 BCP0219 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8499 RFC8500 IS-IS Routing with Reverse Metric N. Shen S. Amante M. Abrahamsson February 2019 ASCII HTML 15 IGP IS-IS Metric Reverse-Metric IIH

This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router.

 draft-ietf-isis-reverse-metric-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8500 RFC8501 Reverse DNS in IPv6 for Internet Service Providers L. Howard November 2018 ASCII HTML 15 IPv6 PTR rDNS Reverse DNS

In IPv4, Internet Service Providers (ISPs) commonly provide IN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.

 draft-ietf-dnsop-isp-ip6rdns-07 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8501 RFC8502 L2L3 VPN Multicast MIB Z. Zhang H. Tsunoda December 2018 ASCII HTML 20 MVPN BGP MPLS P-tunnel PMSI Tunnel attribute SNMP monitor management

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 two MIB modules that will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast.

 draft-ietf-bess-l2l3-vpn-mcast-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8502 RFC8503 BGP/MPLS Layer 3 VPN Multicast Management Information Base H. Tsunoda December 2018 ASCII HTML 57 MVPN PE router P-tunnel PMSI MIB SNMP monitor

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 Multicast communication over IP Virtual Private Networks (VPNs) supported by the Multiprotocol Label Switching/Border Gateway Protocol (MPLS/BGP) on a Provider Edge (PE) router.

 draft-ietf-bess-mvpn-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8503 RFC8504 IPv6 Node Requirements T. Chown J. Loughney T. Winters January 2019 ASCII HTML 42 IPv6 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 obsoletes RFC 6434, and in turn RFC 4294.

 draft-ietf-6man-rfc6434-bis-09 RFC6434 BCP0220 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int 6man 10.17487/RFC8504 RFC8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery P. Thubert Editor E. Nordmark S. Chakrabarti C. Perkins November 2018 ASCII HTML 47 Wi-Fi

This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.

 draft-ietf-6lo-rfc6775-update-21 RFC6775 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo http://www.rfc-editor.org/errata_search.php?rfc=8505 10.17487/RFC8505 RFC8506 Diameter Credit-Control Application L. Bertz Editor D. Dolson Editor Y. Lifshitz Editor March 2019 ASCII HTML 130 Diameter charging

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. The Diameter Credit- Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations.

 draft-ietf-dime-rfc4006bis-12 RFC4006 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8506 RFC8507 Simple Internet Protocol (SIP) Specification S. Deering R. Hinden Editor December 2018 ASCII HTML 26 IPv6 IPng

This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF's Next Generation (IPng) work that became IPv6.

The publication date of the original Internet-Draft was November 10, 1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.

The paragraph that follows is the Abstract from the original draft.

This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.

 draft-historic-simple-ip-03 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC8507 RFC8508 IMAP REPLACE Extension S. Brandt January 2019 ASCII HTML 11

This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.

 draft-ietf-extra-imap-replace-03 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8508 RFC8509 A Root Key Trust Anchor Sentinel for DNSSEC G. Huston J. Damas W. Kumari December 2018 ASCII HTML 19 DNSSEC KSK RFC5011 DNS rollover root-key-sentinel-is-ta- root-key-sentinel-not-ta- root key security

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 verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key.

 draft-ietf-dnsop-kskroll-sentinel-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8509 RFC8510 OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement P. Psenak Editor K. Talaulikar W. Henderickx P. Pillay-Esnault January 2019 ASCII HTML 8 IGP OSPF

Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID).

This document describes the extensions to OSPF link-local signaling (LLS) to advertise the Local Interface ID.

 draft-ietf-ospf-lls-interface-id-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8510 RFC8511 TCP Alternative Backoff with ECN (ABE) N. Khademi M. Welzl G. Armitage G. Fairhurst December 2018 ASCII HTML 12

Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.

 draft-ietf-tcpm-alternativebackoff-ecn-12 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC8511 RFC8512 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) M. Boucadair Editor S. Sivakumar C. Jacquenet S. Vinapamula Q. Wu January 2019 ASCII HTML 94 address sharing address depletion IPv4 service continuity NETCONF programmability automation service automation NPTv6 SIIT NAT64 CLAT Destination NAT Port Restricted NAT Port Range

This document defines a YANG module for the Network Address Translation (NAT) function.

Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document.

 draft-ietf-opsawg-nat-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC8512 RFC8513 A YANG Data Model for Dual-Stack Lite (DS-Lite) M. Boucadair C. Jacquenet S. Sivakumar January 2019 ASCII HTML 21 IPv4 service continuity IPv4 address exhaustion Service Availability Address sharing IPv6 Reliability IPv4 over IPv6

This document defines a YANG module for the Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements.

 draft-ietf-softwire-dslite-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8513 RFC8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension S. Bosch January 2019 ASCII HTML 7 imap savedate

This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria.

 draft-ietf-extra-imap-savedate-01 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8514 RFC8515 URN Namespace for ETSI Documents M. Jethanandani M.A. Reina Ortega February 2019 ASCII HTML 7 YANG NETCONF RESTCONF

This document describes the Namespace Identifier (NID) "etsi" for Uniform Resource Names (URNs) used to identify resources published by the European Telecommunications Standards Institute (http://etsi.org). ETSI 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 ETSI Protocol Naming and Numbering Service (PNNS).

 draft-mahesh-etsi-urn-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8515 RFC8516 "Too Many Requests" Response Code for the Constrained Application Protocol A. Keranen January 2019 ASCII HTML 6 CoAP

A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests.

 draft-ietf-core-too-many-reqs-06 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8516 RFC8517 An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective D. Dolson Editor J. Snellman M. Boucadair Editor C. Jacquenet February 2019 ASCII HTML 21 address sharing NAT firewall Service Function transport service delivery Internet architecture TCP QUIC Path Layer UDP Substrate

This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".

RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.

 draft-dolson-transport-middlebox-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8517 RFC8518 Selection of Loop-Free Alternates for Multi-Homed Prefixes P. Sarkar Editor U. Chunduri Editor S. Hegde J. Tantsura H. Gredler March 2019 ASCII HTML 20 LFA Multi-homed Prefix IGP

Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects.

 draft-ietf-rtgwg-multihomed-prefix-lfa-09 RFC5286 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8518 RFC8519 YANG Data Model for Network Access Control Lists (ACLs) M. Jethanandani S. Agarwal L. Huang D. Blair March 2019 ASCII HTML 60 ACE ACL Firewall PBR NMDA

This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.

 draft-ietf-netmod-acl-model-21 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8519 10.17487/RFC8519 RFC8520 Manufacturer Usage Description Specification E. Lear R. Droms D. Romascanu March 2019 ASCII HTML 60 MUD IoT Security Access Policy

This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.

This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.

 draft-ietf-opsawg-mud-25 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=8520 10.17487/RFC8520 RFC8521 Registration Data Access Protocol (RDAP) Object Tagging S. Hollenbeck A. Newton November 2018 ASCII HTML 13 RDAP Entity Bootstrap

The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries.

 draft-ietf-regext-rdap-object-tag-05 RFC7484 BCP0221 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art regext 10.17487/RFC8521 RFC8522 Looking Glass Command Set M. Stubbig February 2019 ASCII HTML 20 Looking Glass

This document introduces a command set standard to the web-based "Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.

The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format.

 draft-mst-lgapi-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8522 RFC8525 YANG Library A. Bierman M. Bjorklund J. Schoenwaelder K. Watsen R. Wilton March 2019 ASCII HTML 32 NMDA

This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.

 draft-ietf-netconf-rfc7895bis-07 RFC7895 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8525 RFC8526 NETCONF Extensions to Support the Network Management Datastore Architecture M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2019 ASCII HTML 23 NMDA

This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new <get-data> and <edit-data> operations and augments existing <lock>, <unlock>, and <validate> operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) by NETCONF servers implementing the NMDA.

 draft-ietf-netconf-nmda-netconf-08 RFC6241 RFC7950 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8526 RFC8527 RESTCONF Extensions to Support the Network Management Datastore Architecture M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2019 ASCII HTML 9

This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA.

 draft-ietf-netconf-nmda-restconf-05 RFC8040 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8527 RFC8528 YANG Schema Mount M. Bjorklund L. Lhotka March 2019 ASCII HTML 28

This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module.

 draft-ietf-netmod-schema-mount-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8528 10.17487/RFC8528 RFC8529 YANG Data Model for Network Instances L. Berger C. Hopps A. Lindem D. Bogdanovic X. Liu March 2019 ASCII HTML 44 VRF VSI VPN

This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

 draft-ietf-rtgwg-ni-model-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8529 RFC8530 YANG Model for Logical Network Elements L. Berger C. Hopps A. Lindem D. Bogdanovic X. Liu March 2019 ASCII HTML 49 VRF VSI VPN

This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture (NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342.

 draft-ietf-rtgwg-lne-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8530 RFC8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols D. Kumar Q. Wu Z. Wang April 2019 ASCII HTML 54

This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).

The YANG data model in this document conforms to the Network Management Datastore Architecture.

 draft-ietf-lime-yang-connection-oriented-oam-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime http://www.rfc-editor.org/errata_search.php?rfc=8531 10.17487/RFC8531 RFC8532 Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications D. Kumar Z. Wang Q. Wu Editor R. Rahman S. Raghavan April 2019 ASCII HTML 59

This document presents a base YANG Data model for the management of Operations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using the YANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details.

There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same level through a unified interface).

 draft-ietf-lime-yang-connectionless-oam-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime 10.17487/RFC8532 RFC8533 A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications D. Kumar M. Wang Q. Wu Editor R. Rahman S. Raghavan April 2019 ASCII HTML 41 CL OAM Retrieval Methods

This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology- specific details. There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface).

 draft-ietf-lime-yang-connectionless-oam-methods-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime 10.17487/RFC8533 RFC8534 Explicit Tracking with Wildcard Routes in Multicast VPN A. Dolganow J. Kotalwar E. Rosen Editor Z. Zhang February 2019 ASCII HTML 21 Multicast MVPN

The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, 7524, 7582, and 7900.

 draft-ietf-bess-mvpn-expl-track-13 RFC6514 RFC6625 RFC7524 RFC7582 RFC7900 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8534 RFC8536 The Time Zone Information Format (TZif) A. Olson P. Eggert K. Murchison February 2019 ASCII HTML 34 time zone tzdata tzif

This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined.

 draft-murchison-tzdist-tzif-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8536 RFC8537 Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) R. Gandhi Editor H. Shah J. Whittaker February 2019 ASCII HTML 16 RSVP-TE LSP

Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document updates the fast reroute procedures defined in RFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event.

 draft-ietf-teas-assoc-corouted-bidir-frr-07 RFC4090 RFC7551 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8537 RFC8538 Notification Message Support for BGP Graceful Restart K. Patel R. Fernando J. Scudder J. Haas March 2019 ASCII HTML 10 IDR BGP

The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGP NOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode for BGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart.

 draft-ietf-idr-bgp-gr-notification-16 RFC4724 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8538 RFC8539 Softwire Provisioning Using DHCPv4 over DHCPv6 I. Farrer Q. Sun Y. Cui L. Sun March 2019 ASCII HTML 18 Provisioning Softwire DHCP 4o6 IPv4 over IPv6 IPv4 service continuity IPv4 address depletion IPv4 over IPv6 MAP Lightweight 4over6

DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.

"DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's Option Request Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server.

 draft-ietf-dhc-dhcp4o6-saddr-opt-08 RFC7598 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8539 RFC8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960 R. Stewart M. Tuexen M. Proshin February 2019 ASCII HTML 94

This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 4960 and is organized in a time-ordered way. The issues are listed in the order in which 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 deltas, a description of each problem and the details of the solution for each are also provided.

 draft-ietf-tsvwg-rfc4960-errata-08 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC8540 RFC8541 Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops S. Litkowski B. Decraene M. Horneffer March 2019 ASCII HTML 15 IS-IS OSPF

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 document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies.

 draft-ietf-rtgwg-spf-uloop-pb-statement-10 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC8541 RFC8542 A YANG Data Model for Fabric Topology in Data-Center Networks Y. Zhuang D. Shi R. Gu H. Ananthakrishnan March 2019 ASCII HTML 32 YANG Fabric Topology Data-Center Networks

This document defines a YANG data model for fabric topology in data- center networks and represents one possible view of the data-center fabric. This document focuses on the data model only and does not endorse any kind of network design that could be based on the abovementioned model.

 draft-ietf-i2rs-yang-dc-fabric-network-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8542 RFC8543 Extensible Provisioning Protocol (EPP) Organization Mapping L. Zhou N. Kong J. Yao J. Gould G. Zhou March 2019 ASCII HTML 43 epp registry organization object mapping

This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository.

 draft-ietf-regext-org-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8543 RFC8544 Organization Extension for the Extensible Provisioning Protocol (EPP) L. Zhou N. Kong J. Wei J. Yao J. Gould April 2019 ASCII HTML 22 epp organization mapping extension

This document describes an extension to Extensible Provisioning Protocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects.

 draft-ietf-regext-org-ext-11 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8544 RFC8545 Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) A. Morton Editor G. Mirsky Editor March 2019 ASCII HTML 11 OWAMP TWAMP

This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry.

This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.

 draft-ietf-ippm-port-twamp-test-04 RFC4656 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8545 RFC8546 The Wire Image of a Network Protocol B. Trammell M. Kuehlewind April 2019 ASCII HTML 10

This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.

 draft-iab-wire-image-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8546 RFC8547 TCP-ENO: Encryption Negotiation Option A. Bittau D. Giffin M. Handley D. Mazieres E. Smith May 2019 ASCII HTML 31 tcp encryption

Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.

 draft-ietf-tcpinc-tcpeno-19 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpinc 10.17487/RFC8547 RFC8548 Cryptographic Protection of TCP Streams (tcpcrypt) A. Bittau D. Giffin M. Handley D. Mazieres Q. Slack E. Smith May 2019 ASCII HTML 32 tcp encryption

This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted. However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection.

 draft-ietf-tcpinc-tcpcrypt-15 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpinc 10.17487/RFC8548 RFC8549 Export of BGP Community Information in IP Flow Information Export (IPFIX) Z. Li R. Gu J. Dong April 2019 ASCII HTML 18 community BGP IPFIX

By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export (IPFIX) to export BGP community information, including the BGP Standard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092. According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering.

 draft-ietf-opsawg-ipfix-bgp-community-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC8549 RFC8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling J. Schaad B. Ramsdell S. Turner April 2019 ASCII HTML 29 S/MIME

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 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 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (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 5750.

 draft-ietf-lamps-rfc5750-bis-08 RFC5750 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8550 RFC8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification J. Schaad B. Ramsdell S. Turner April 2019 ASCII HTML 63 S/MIME

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. 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 5751.

 draft-ietf-lamps-rfc5751-bis-11 RFC5751 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8551 RFC8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves D. Crocker March 2019 ASCII HTML 15 DNS Domain Name System

Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.

 draft-ietf-dnsop-attrleaf-16 BCP0222 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8552 10.17487/RFC8552 RFC8553 DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names D. Crocker March 2019 ASCII HTML 15 DNS Domain Name System

Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.

 draft-ietf-dnsop-attrleaf-fix-07 RFC2782 RFC3263 RFC3529 RFC3620 RFC3832 RFC3887 RFC3958 RFC4120 RFC4227 RFC4386 RFC4387 RFC4976 RFC5026 RFC5328 RFC5389 RFC5415 RFC5518 RFC5555 RFC5617 RFC5679 RFC5766 RFC5780 RFC5804 RFC5864 RFC5928 RFC6120 RFC6186 RFC6376 RFC6733 RFC6763 RFC7208 RFC7489 RFC8145 BCP0222 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8553 RFC8554 Leighton-Micali Hash-Based Signatures D. McGrew M. Curcio S. Fluhrer April 2019 ASCII HTML 61 LMS HSS stateful

This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them.

 draft-mcgrew-hash-sigs-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8554 RFC8555 Automatic Certificate Management Environment (ACME) R. Barnes J. Hoffman-Andrews D. McCarney J. Kasten March 2019 ASCII HTML 95 certificate HTTPS PKI X.509

Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.

 draft-ietf-acme-acme-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme http://www.rfc-editor.org/errata_search.php?rfc=8555 10.17487/RFC8555 RFC8556 Multicast VPN Using Bit Index Explicit Replication (BIER) E. Rosen Editor M. Sivakumar T. Przygienda S. Aldrin A. Dolganow April 2019 ASCII HTML 17 Multicast

The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.

 draft-ietf-bier-mvpn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8556 RFC8557 Deterministic Networking Problem Statement N. Finn P. Thubert May 2019 ASCII HTML 11

This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.

 draft-ietf-detnet-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC8557 RFC8558 Transport Protocol Path Signals T. Hardie Editor April 2019 ASCII HTML 10

This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.

 draft-iab-path-signals-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=8558 10.17487/RFC8558 RFC8559 Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol A. DeKok J. Korhonen April 2019 ASCII HTML 21 RADIUS Change of Authorization CoA-Request Disconnect-Request

RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets.

 draft-ietf-radext-coa-proxy-10 RFC5176 RFC5580 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC8559 RFC8560 Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents A. Sajassi Editor S. Salam N. Del Regno J. Rabadan May 2019 ASCII HTML 16 EVPN VPLS PBB-EVPN PBB-VPLS Ethernet Virtual Private Networks Virtual Private LAN Services Provider Backbone Bridging

This document specifies mechanisms for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPN Provider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks. This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media Access Control (MAC) mobility operation. This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN PEs.

 draft-ietf-bess-evpn-vpls-seamless-integ-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8560 RFC8561 A YANG Data Model for Microwave Radio Link J. Ahlberg M. Ye X. Li D. Spreafico M. Vaupotic June 2019 ASCII HTML 53 microwaveRadioLinkTerminal microwaveCarrierTermination

This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well.

 draft-ietf-ccamp-mw-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8561 RFC8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks D. Katz D. Ward S. Pallagatti Editor G. Mirsky Editor April 2019 ASCII HTML 23 BFD Multipoint BFD

This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.

This document updates RFC 5880.

 draft-ietf-bfd-multipoint-19 RFC5880 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC8562 RFC8563 Bidirectional Forwarding Detection (BFD) Multipoint Active Tails D. Katz D. Ward S. Pallagatti Editor G. Mirsky Editor April 2019 ASCII HTML 20

This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks.

 draft-ietf-bfd-multipoint-active-tail-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC8563 RFC8564 Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL) M. Zhang S. Pallagatti V. Govindan April 2019 ASCII HTML 8 data center network switch multicast

Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection of Lots of Links (TRILL). Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel messages. This document updates RFCs 7175 and 7177.

 draft-ietf-trill-p2mp-bfd-09 RFC7175 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8564 RFC8565 Hypertext Jeopardy Protocol (HTJP/1.0) E. Fokschaner April 1 2019 ASCII HTML 11

The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.

 draft-fokschaner-htjp-latest-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8565 RFC8567 Customer Management DNS Resource Records E. Rye R. Beverly April 1 2019 ASCII HTML 11

Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.

This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.

 draft-ietf-cust-mgmt-dns-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8567 RFC8568 Network Virtualization Research Challenges CJ. Bernardos A. Rahman JC. Zuniga LM. Contreras P. Aranda P. Lynch April 2019 ASCII HTML 42

This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG).

 draft-irtf-nfvrg-gaps-network-virtualization-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8568 RFC8569 Content-Centric Networking (CCNx) Semantics M. Mosko I. Solis C. Wood July 2019 ASCII HTML 40 Content Centric Networking

This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.

The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.

This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.

 draft-irtf-icnrg-ccnxsemantics-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC8569 RFC8570 IS-IS Traffic Engineering (TE) Metric Extensions L. Ginsberg Editor S. Previdi Editor S. Giacalone D. Ward J. Drake Q. Wu March 2019 ASCII HTML 21 IGP IS-IS

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). These extensions provide a way to distribute and collect network-performance information 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.

This document obsoletes RFC 7810.

 draft-ietf-lsr-isis-rfc7810bis-05 RFC7810 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8570 RFC8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions L. Ginsberg Editor S. Previdi Q. Wu J. Tantsura C. Filsfils March 2019 ASCII HTML 10

This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.

 draft-ietf-idr-te-pm-bgp-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8571 RFC8572 Secure Zero Touch Provisioning (SZTP) K. Watsen I. Farrer M. Abrahamsson April 2019 ASCII HTML 87 zerotouch bootstrap sztp ztp

This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.

 draft-ietf-netconf-zerotouch-29 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8572 RFC8573 Message Authentication Code for the Network Time Protocol A. Malhotra S. Goldberg June 2019 ASCII HTML 5 NTP

The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.

 draft-ietf-ntp-mac-06 RFC5905 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC8573 RFC8574 cite-as: A Link Relation to Convey a Preferred URI for Referencing H. Van de Sompel M. Nelson G. Bilder J. Kunze S. Warner April 2019 ASCII HTML 17 persistent identifier PID

A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference.

 draft-vandesompel-citeas-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8574 10.17487/RFC8574 RFC8575 YANG Data Model for the Precision Time Protocol (PTP) Y. Jiang Editor X. Liu J. Xu R. Cummings Editor May 2019 ASCII HTML 30

This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).

 draft-ietf-tictoc-1588v2-yang-11 PROPOSED STANDARD PROPOSED STANDARD IETF int tictoc 10.17487/RFC8575 RFC8576 Internet of Things (IoT) Security: State of the Art and Challenges O. Garcia-Morchon S. Kumar M. Sethi April 2019 ASCII HTML 50 IoT Internet of Things M2M Machine-to-machine Machine-type communication MTC Security Privacy Trustworthy Lifecycle

The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.

This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).

 draft-irtf-t2trg-iot-seccons-16 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8576 RFC8577 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane H. Sitaraman V. Beeram T. Parikh T. Saad April 2019 ASCII HTML 24 Segment Routed RSVP-TE tunnels TE link labels RSVP-TE shared labels

As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.

However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.

This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.

 draft-ietf-mpls-rsvp-shared-labels-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8577 10.17487/RFC8577 RFC8578 Deterministic Networking Use Cases E. Grossman Editor May 2019 ASCII HTML 97 DetNet AVB TSN SRP

This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.

 draft-ietf-detnet-use-cases-20 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC8578 RFC8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes S. Bosch May 2019 ASCII HTML 12 sieve mailbox special-use

The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute.

 draft-ietf-extra-sieve-special-use-05 PROPOSED STANDARD PROPOSED STANDARD IETF art extra http://www.rfc-editor.org/errata_search.php?rfc=8579 10.17487/RFC8579 RFC8580 Sieve Extension: File Carbon Copy (FCC) K. Murchison B. Gondwana May 2019 ASCII HTML 12 Sieve Vacation Notify

The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.

This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively.

 draft-ietf-extra-sieve-fcc-09 RFC5230 RFC5435 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8580 RFC8581 Diameter Agent Overload and the Peer Overload Report S. Donovan August 2019 ASCII HTML 19 Diameter Overload

This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.

 draft-ietf-dime-agent-overload-11 RFC7683 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8581 RFC8582 Diameter Overload Rate Control S. Donovan Editor E. Noel August 2019 ASCII HTML 20 Diameter Overload

This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution, which is defined in RFC 7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node.

 draft-ietf-dime-doic-rate-control-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8582 RFC8583 Diameter Load Information Conveyance B. Campbell S. Donovan Editor JJ. Trottin August 2019 ASCII HTML 23 Diameter load

RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information.

 draft-ietf-dime-load-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8583 RFC8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility J. Rabadan Editor S. Mohanty Editor A. Sajassi J. Drake K. Nagaraj S. Sathappan April 2019 ASCII HTML 32

An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).

 draft-ietf-bess-evpn-df-election-framework-09 RFC7432 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8584 RFC8585 Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service J. Palet Martinez H. M.-H. Liu M. Kawashima May 2019 ASCII HTML 21 IPv6 transition CE requirements IPv4aaS

This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.

Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet.

 draft-ietf-v6ops-transition-ipv4aas-15 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8585 RFC8586 Loop Detection in Content Delivery Networks (CDNs) S. Ludin M. Nottingham N. Sullivan April 2019 ASCII HTML 6 CDN-Loop,

This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop.

 draft-ietf-httpbis-cdn-loop-02 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8586 10.17487/RFC8586 RFC8587 NFS Version 4.0 Trunking Update C. Lever Editor D. Noveck May 2019 ASCII HTML 22 NFSv4.0 migration replication trunking fs_locations transparent state migration

In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530.

 draft-ietf-nfsv4-mv0-trunking-update-05 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8587 RFC8588 Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) C. Wendt M. Barnes May 2019 ASCII HTML 9

This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network.

 draft-ietf-stir-passport-shaken-08 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC8588 RFC8589 The 'leaptofrogans' URI Scheme A. Tamas B. Phister Editor J-E. Rodriguez May 2019 ASCII HTML 9 Frogans leaptofrogans OP3FT URI scheme

This document describes the 'leaptofrogans' Uniform Resource Identifier (URI) scheme, which enables applications to launch Frogans Player on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software that enables end users to browse Frogans sites.

 draft-op3ft-leaptofrogans-uri-scheme-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8589 RFC8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP) J. Gould K. Feher May 2019 ASCII HTML 20

This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.

 draft-ietf-regext-change-poll-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8590 RFC8591 SIP-Based Messaging with S/MIME B. Campbell R. Housley April 2019 ASCII HTML 39 MSRP CPIM

Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFCs 3261, 3428, and 4975.

 draft-campbell-sip-messaging-smime-05 RFC3261 RFC3428 RFC4975 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8591 RFC8592 Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH) R. Browne A. Chilikin T. Mizrahi May 2019 ASCII HTML 27 Timestamp Timestamping QoS service chain

This document describes methods of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.

 draft-browne-sfc-nsh-kpi-stamp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8592 RFC8593 Video Traffic Models for RTP Congestion Control Evaluations X. Zhu S. Mena Z. Sarker May 2019 ASCII HTML 19 Multimedia Congestion Control

This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model.

 draft-ietf-rmcat-video-traffic-model-07 INFORMATIONAL INFORMATIONAL IETF tsv rmcat 10.17487/RFC8593 RFC8594 The Sunset HTTP Header Field E. Wilde May 2019 ASCII HTML 11

This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.

 draft-wilde-sunset-header-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8594 RFC8595 An MPLS-Based Forwarding Plane for Service Function Chaining A. Farrel S. Bryant J. Drake June 2019 ASCII HTML 32 SFC MPLS Service Function Chaining NSH Network Service Header MPLS Multiprotocol Label Switching

This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.

 draft-ietf-mpls-sfc-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8595 RFC8596 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) A. Malis S. Bryant J. Halpern W. Henderickx June 2019 ASCII HTML 9 label label stack service function forwarder (SFF)

This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node.

 draft-ietf-mpls-sfc-encapsulation-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8596 RFC8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS) LM. Contreras CJ. Bernardos D. Lopez M. Boucadair P. Iovanna May 2019 ASCII HTML 21 SDN Control Programmability Intelligence Transport Service Flexibility Cooperation

Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.

This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.

 draft-contreras-layered-sdn-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8597 RFC8598 Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) T. Pauly P. Wouters May 2019 ASCII HTML 16 IKEv2 DNS

This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations.

 draft-ietf-ipsecme-split-dns-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8598 RFC8599 Push Notification with the Session Initiation Protocol (SIP) C. Holmberg M. Arnold May 2019 ASCII HTML 40 SIP Push Notification

This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.

 draft-ietf-sipcore-sip-push-29 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8599 RFC8600 Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange N. Cam-Winget Editor S. Appala S. Pope P. Saint-Andre June 2019 ASCII HTML 28 publish subscribe pubsub grid iodef xmpp-grid information sharing

This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).

 draft-ietf-mile-xmpp-grid-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8600 RFC8601 Message Header Field for Indicating Message Authentication Status M. Kucherawy May 2019 ASCII HTML 54 DKIM SPF 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.

This document obsoletes RFC 7601.

 draft-ietf-dmarc-rfc7601bis-06 RFC7601 PROPOSED STANDARD PROPOSED STANDARD IETF art dmarc 10.17487/RFC8601 RFC8602 Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses J. Arkko T. Hardie July 2019 ASCII HTML 3

This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.

This memo updates RFC 3219.

 draft-arkko-trip-registry-update-01 RFC3219 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8602 RFC8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile M. Jenkins L. Zieglar May 2019 ASCII HTML 13

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 Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

 draft-jenkins-cnsa-cert-crl-profile-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8603 RFC8604 Interconnecting Millions of Endpoints with Segment Routing C. Filsfils Editor S. Previdi G. Dawra Editor W. Henderickx D. Cooper June 2019 ASCII HTML 11

This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document.

 draft-filsfils-spring-large-scale-interconnect-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8604 RFC8605 vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP) S. Hollenbeck R. Carney May 2019 ASCII HTML 7 RDAP vCard

This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.

 draft-hollenbeck-vcarddav-icann-rdap-extensions-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8605 RFC8606 ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field R. Jesske June 2019 ASCII HTML 7 Reason Call Location

The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose.

 draft-ietf-sipcore-reason-q850-loc-07 RFC3326 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8606 RFC8607 Calendaring Extensions to WebDAV (CalDAV): Managed Attachments C. Daboo A. Quillaud K. Murchison Editor June 2019 ASCII HTML 34 CalDAV calendaring attachment ATTACH

This specification adds an extension to the Calendaring Extensions to WebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.

This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP.

 draft-ietf-calext-caldav-attachments-04 INFORMATIONAL INFORMATIONAL IETF art calext 10.17487/RFC8607 RFC8608 BGPsec Algorithms, Key Formats, and Signature Formats S. Turner O. Borchert June 2019 ASCII HTML 21 BGPsec BGPsec Algorithms Crypto Algorithms ECDSA Cryptography

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.

This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05 RFC8208 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8608 RFC8609 Content-Centric Networking (CCNx) Messages in TLV Format M. Mosko I. Solis C. Wood July 2019 ASCII HTML 46

Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.

This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.

 draft-irtf-icnrg-ccnxmessages-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC8609 RFC8610 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures H. Birkholz C. Vigano C. Bormann June 2019 ASCII HTML 64 binary format data interchange format description language schema language tree grammar

This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.

 draft-ietf-cbor-cddl-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC8610 RFC8611 Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces N. Akiya G. Swallow S. Litkowski B. Decraene J. Drake M. Chen June 2019 ASCII HTML 29 MPLS LSP Ping

This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).

This document updates RFC 8029.

 draft-ietf-mpls-lsp-ping-lag-multipath-08 RFC8029 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8611 RFC8612 DDoS Open Threat Signaling (DOTS) Requirements A. Mortensen T. Reddy R. Moskowitz May 2019 ASCII HTML 22

This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.

 draft-ietf-dots-requirements-22 INFORMATIONAL INFORMATIONAL IETF sec dots 10.17487/RFC8612 RFC8613 Object Security for Constrained RESTful Environments (OSCORE) G. Selander J. Mattsson F. Palombini L. Seitz July 2019 ASCII HTML 94

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.

 draft-ietf-core-object-security-16 RFC7252 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8613 RFC8614 Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) R. Singh K. Kompella S. Palislamovic June 2019 ASCII HTML 9

This document updates the meaning of the Control Flags field in the "Layer2 Info Extended Community" used for BGP Virtual Private LAN Service (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761.

 draft-ietf-bess-bgp-vpls-control-flags-08 RFC4761 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8614 RFC8615 Well-Known Uniform Resource Identifiers (URIs) M. Nottingham May 2019 ASCII HTML 12

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.

In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.

 draft-nottingham-rfc5785bis-11 RFC5785 RFC7230 RFC7595 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8615 RFC8616 Email Authentication for Internationalized Mail J. Levine June 2019 ASCII HTML 6 email internationalization

Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.

 draft-ietf-dmarc-eaiauth-06 RFC6376 RFC7208 RFC7489 PROPOSED STANDARD PROPOSED STANDARD IETF art dmarc 10.17487/RFC8616 RFC8617 The Authenticated Received Chain (ARC) Protocol K. Andersen B. Long Editor S. Blank Editor M. Kucherawy Editor July 2019 ASCII HTML 35 DKIM DMARC signature email domian authentication email authentication

The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.

ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.

ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.

 draft-ietf-dmarc-arc-protocol-23 EXPERIMENTAL EXPERIMENTAL IETF art dmarc 10.17487/RFC8617 RFC8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture J. Dickinson J. Hague S. Dickinson T. Manderson J. Bond September 2019 ASCII HTML 79 DNS

This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic- monitoring applications.

 draft-ietf-dnsop-dns-capture-format-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8618 RFC8619 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) R. Housley June 2019 ASCII HTML 6 HKDF Algorithm Identifier

RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.

 draft-housley-hkdf-oids-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8619 RFC8620 The JSON Meta Application Protocol (JMAP) N. Jenkins C. Newman July 2019 ASCII HTML 90 JMAP JSON

This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.

 draft-ietf-jmap-core-17 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap http://www.rfc-editor.org/errata_search.php?rfc=8620 10.17487/RFC8620 RFC8621 The JSON Meta Application Protocol (JMAP) for Mail N. Jenkins C. Newman August 2019 ASCII HTML 108 JMAP JSON email

This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.

 draft-ietf-jmap-mail-16 RFC5788 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap 10.17487/RFC8621 RFC8622 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services R. Bless June 2019 ASCII HTML 18 Lower Effort Per-Hop Behavior Scavenger Service

This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.

This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.

 draft-ietf-tsvwg-le-phb-10 RFC3662 RFC4594 RFC8325 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8622 RFC8623 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) U. Palle D. Dhody Y. Tanaka V. Beeram June 2019 ASCII HTML 33

The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.

 draft-ietf-pce-stateful-pce-p2mp-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8623 RFC8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC P. Wouters O. Sury June 2019 ASCII HTML 11

The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944.

 draft-ietf-dnsop-algorithm-update-10 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8624 RFC8625 Ethernet Traffic Parameters with Availability Information H. Long M. Ye Editor G. Mirsky Editor A. D'Alessandro H. Shah August 2019 ASCII HTML 13 GMPLS RSVP-TE microwave variable bandwidth link

A packet-switching network may contain links with variable bandwidths (e.g., copper and radio). The bandwidth of such links is sensitive to the external environment (e.g., climate). Availability is typically used to describe these links when doing network planning. This document introduces an optional Bandwidth Availability TLV in RSVP-TE signaling. This extension can be used to set up a GMPLS Label Switched Path (LSP) in conjunction with the Ethernet SENDER_TSPEC object.

 draft-ietf-ccamp-rsvp-te-bandwidth-availability-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8625 RFC8627 RTP Payload Format for Flexible Forward Error Correction (FEC) M. Zanaty V. Singh A. Begen G. Mandyam July 2019 ASCII HTML 41 FEC forward error correction

This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.

 draft-ietf-payload-flexible-fec-scheme-20 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC8627 RFC8628 OAuth 2.0 Device Authorization Grant W. Denniss J. Bradley M. Jones H. Tschofenig August 2019 ASCII HTML 21 Security Area OAuth Security Authorization Smart Objects IoT Internet of Things Internet of Things Security OAuth for Constrained Devices OAuth IoT Security

The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

 draft-ietf-oauth-device-flow-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8628 10.17487/RFC8628 RFC8629 Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension B. Cheng L. Berger Editor July 2019 ASCII HTML 10

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.

 draft-ietf-manet-dlep-multi-hop-extension-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8629 RFC8630 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent T. Bruijnzeels August 2019 ASCII HTML 11

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.

This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme.

 draft-ietf-sidrops-https-tal-08 RFC7730 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8630 RFC8631 Link Relation Types for Web Services E. Wilde July 2019 ASCII HTML 10 API Documentation Description Metadata Status

Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.

 draft-wilde-service-link-rel-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8631 RFC8632 A YANG Data Model for Alarm Management S. Vallin M. Bjorklund September 2019 ASCII HTML 82 Monitoring Fault Management

This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards.

 draft-ietf-ccamp-alarm-module-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8632 RFC8633 Network Time Protocol Best Current Practices D. Reilly H. Stenn D. Sibold July 2019 ASCII HTML 26 NTP

The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.

 draft-ietf-ntp-bcp-13 BCP0223 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int ntp 10.17487/RFC8633 RFC8634 BGPsec Router Certificate Rollover B. Weis R. Gagliano K. Patel August 2019 ASCII HTML 11

Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost.

 draft-ietf-sidrops-bgpsec-rollover-04 BCP0224 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops sidrops 10.17487/RFC8634 RFC8635 Router Keying for BGPsec R. Bush S. Turner K. Patel August 2019 ASCII HTML 21

BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.

 draft-ietf-sidrops-rtr-keying-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8635 RFC8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility L. Hornquist Astrand L. Zhu M. Cullen G. Hudson July 2019 ASCII HTML 21

This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.

These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms.

 draft-ietf-kitten-pkinit-alg-agility-08 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8636 RFC8637 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) D. Dhody Y. Lee D. Ceccarelli July 2019 ASCII HTML 22 PCE ACTN

Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.

The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).

This document examines the applicability of PCE to the ACTN framework.

 draft-ietf-pce-applicability-actn-12 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8637 RFC8638 IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks M. Xu Y. Cui J. Wu S. Yang C. Metz September 2019 ASCII HTML 19 Multicast Mesh SSM ASM

During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running another IP address family (referred to as the external IP or E-IP family). In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.

This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ. The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario.

 draft-ietf-softwire-mesh-multicast-25 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8638 RFC8639 Subscription to YANG Notifications E. Voit A. Clemm A. Gonzalez Prieto E. Nilsen-Nygaard A. Tripathy September 2019 ASCII HTML 77 telemetry YANG-Push

This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.

 draft-ietf-netconf-subscribed-notifications-26 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8639 RFC8640 Dynamic Subscription to YANG Events and Datastores over NETCONF E. Voit A. Clemm A. Gonzalez Prieto E. Nilsen-Nygaard A. Tripathy September 2019 ASCII HTML 19 telemetry

This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.

 draft-ietf-netconf-netconf-event-notifications-22 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8640 RFC8641 Subscription to YANG Notifications for Datastore Updates A. Clemm E. Voit September 2019 ASCII HTML 58 YANG-Push Streaming telemetry

This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.

 draft-ietf-netconf-yang-push-25 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8641 RFC8642 Policy Behavior for Well-Known BGP Communities J. Borkenhagen R. Bush R. Bonica S. Bayraktar August 2019 ASCII HTML 7 Operations Inter-Provider Communication

Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators. Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely, BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997.

 draft-ietf-grow-wkc-behavior-08 RFC1997 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8642 RFC8643 An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) A. Johnston B. Aboba A. Hutton R. Jesske T. Stach August 2019 ASCII HTML 8 srtp opportunistic security encryption best effort osrtp

Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance and is not required. OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for Secure RTP (SRTP). OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state.

 draft-ietf-sipbrandy-osrtp-10 INFORMATIONAL INFORMATIONAL IETF art sipbrandy 10.17487/RFC8643 RFC8645 Re-keying Mechanisms for Symmetric Keys S. Smyshlyaev Editor August 2019 ASCII HTML 69 re-keying key key lifetime encryption mode mode of operation

A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

 draft-irtf-cfrg-re-keying-17 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8645 RFC8649 Hash Of Root Key Certificate Extension R. Housley August 2019 ASCII HTML 10 trust anchor

This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.

 draft-ietf-lamps-hash-of-root-key-cert-extn-07 INFORMATIONAL INFORMATIONAL IETF sec lamps 10.17487/RFC8649 RFC8651 Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension B. Cheng D. Wiggins L. Berger Editor October 2019 HTML TEXT PDF XML 12 DLEP Flow control Pause

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router.

 draft-ietf-manet-dlep-pause-extension-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8651 RFC8654 Extended Message Support for BGP R. Bush K. Patel D. Ward October 2019 HTML TEXT PDF XML 7 border gateway protocol address family identifiers afi

The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages.

 draft-ietf-idr-bgp-extended-messages-36 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8654 RFC8655 Deterministic Networking Architecture N. Finn P. Thubert B. Varga J. Farkas October 2019 HTML TEXT PDF XML 38 TSN Bounded Latency Reliable Networking Available Networking

This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.

 draft-ietf-detnet-architecture-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC8655 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 An 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 STD0084 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) RFC8077 STD0085 Message Disposition Notification RFC8098 STD0086 Internet Protocol, Version 6 (IPv6) Specification RFC8200 STD0087 Path MTU Discovery for IP version 6 RFC8201 STD0088 DNS Extensions to Support IP Version 6 RFC3596 STD0089 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC4443 STD0090 The JavaScript Object Notation (JSON) Data Interchange Format RFC8259 STD0091 Network Configuration Access Control Model RFC8341 STD0092 Internet Printing Protocol/1.1 RFC8010 RFC8011 ./update-package.include0000644000764400076440000001415013555642745014610 0ustar iustyiustydraft-ietf-rtcweb-data-channel-13.txt draft-ietf-rtcweb-data-protocol-09.txt draft-ietf-rtcweb-rtp-usage-26.txt draft-ietf-bfcpbis-rfc4582bis-16.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-17.txt draft-ietf-mmusic-mux-exclusive-12.txt draft-ietf-clue-data-model-schema-17.txt draft-ietf-tsvwg-rtcweb-qos-18.txt draft-ietf-avtext-rid-09.txt draft-ietf-rtcweb-transports-17.txt draft-ietf-mmusic-sdp-mux-attributes-17.txt draft-ietf-bfcpbis-bfcp-websocket-15.txt draft-ietf-clue-rtp-mapping-14.txt draft-ietf-mmusic-sctp-sdp-26.txt draft-ietf-isis-l2bundles-07.txt draft-ietf-avtext-lrr-07.txt draft-ietf-anima-grasp-15.txt draft-ietf-ospf-encapsulation-cap-09.txt draft-ietf-mmusic-dtls-sdp-32.txt draft-ietf-rtcweb-overview-19.txt draft-ietf-ospf-segment-routing-extensions-27.txt draft-ietf-rtgwg-yang-rip-11.txt draft-ietf-rtcweb-jsep-26.txt draft-ietf-bess-dci-evpn-overlay-10.txt draft-ietf-trill-ecn-support-07.txt draft-ietf-netmod-syslog-model-26.txt draft-ietf-pim-yang-17.txt draft-ietf-mmusic-rid-15.txt draft-ietf-ice-trickle-21.txt draft-ietf-bess-evpn-prefix-advertisement-11.txt draft-ietf-mmusic-sdp-bundle-negotiation-54.txt draft-ietf-mmusic-trickle-ice-sip-18.txt draft-ietf-mmusic-sdp-simulcast-14.txt draft-ietf-ippm-twamp-yang-13.txt draft-ietf-mpls-spring-entropy-label-12.txt draft-ietf-dnssd-hybrid-10.txt draft-ietf-bfd-yang-17.txt draft-ietf-idr-bgp-prefix-sid-27.txt draft-ietf-spring-segment-routing-ldp-interop-15.txt draft-ietf-homenet-babel-profile-07.txt draft-ietf-bfcpbis-rfc4583bis-27.txt draft-ietf-ospf-ospfv3-segment-routing-extensions-23.txt draft-ietf-lisp-rfc8113bis-03.txt draft-ietf-softwire-yang-16.txt draft-ietf-pce-segment-routing-16.txt draft-ietf-pce-wson-rwa-ext-17.txt draft-ietf-tram-stunbis-21.txt draft-ietf-idr-bgpls-segment-routing-epe-19.txt draft-ietf-mmusic-data-channel-sdpneg-28.txt draft-ietf-spring-segment-routing-mpls-22.txt draft-ietf-pce-hierarchy-extensions-11.txt draft-ietf-isis-segment-routing-extensions-25.txt draft-ietf-perc-private-media-framework-12.txt draft-ietf-lamps-rfc6844bis-07.txt draft-ietf-pim-igmp-mld-yang-15.txt draft-ietf-softwire-iftunnel-07.txt draft-ietf-softwire-map-radius-26.txt draft-ietf-tsvwg-tinymt32-06.txt draft-ietf-tsvwg-rlc-fec-scheme-16.txt draft-ietf-tsvwg-fecframe-ext-08.txt draft-ietf-acme-caa-10.txt draft-ietf-mpls-sr-over-ip-07.txt draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt draft-ietf-roll-useofrplinfo-31.txt draft-ietf-roll-efficient-npdao-16.txt draft-ietf-rtcweb-ip-handling-12.txt draft-ietf-rtcweb-security-12.txt draft-ietf-sipcore-rejected-09.txt draft-ietf-rtcweb-fec-10.txt draft-ietf-teas-yang-te-topo-22.txt draft-ietf-oauth-token-exchange-19.txt draft-ietf-mptcp-rfc6824bis-18.txt draft-ietf-lamps-pkix-shake-15.txt draft-ietf-rtcweb-security-arch-20.txt draft-ietf-tram-turnbis-29.txt draft-ietf-mpls-egress-protection-framework-07.txt draft-ietf-pce-association-group-10.txt draft-ietf-uta-smtp-require-tls-09.txt draft-ietf-curdle-gss-keyex-sha2-10.txt draft-ietf-netconf-restconf-notif-15.txt draft-ietf-ipwave-ipv6-over-80211ocb-52.txt draft-ietf-mmusic-sdp-uks-07.txt draft-ietf-dots-data-channel-31.txt draft-ietf-mmusic-ice-sip-sdp-39.txt draft-ietf-mmusic-rfc4566bis-37.txt draft-ietf-grow-bmp-adj-rib-out-07.txt draft-ietf-alto-xdom-disc-06.txt draft-ietf-lamps-cms-mix-with-psk-07.txt draft-ietf-ospf-yang-29.txt draft-ietf-ospf-xaf-te-07.txt draft-ietf-perc-double-12.txt draft-ietf-mpls-rfc8287-len-clarification-04.txt draft-ietf-lamps-cms-shakes-18.txt draft-ietf-curdle-ssh-curves-12.txt draft-ietf-oauth-resource-indicators-08.txt draft-ietf-oauth-mtls-17.txt draft-ietf-curdle-ssh-ed25519-ed448-11.txt draft-ietf-manet-dlep-lid-extension-06.txt draft-ietf-lsr-isis-rfc5306bis-09.txt draft-ietf-lamps-cms-hash-sig-10.txt draft-ietf-core-multipart-ct-04.txt draft-ietf-pim-reserved-bits-04.txt draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt draft-ietf-cbor-sequence-02.txt draft-ietf-6lo-deadline-time-05.txt draft-ietf-acme-ip-08.txt draft-ietf-acme-tls-alpn-07.txt draft-ietf-isis-yang-isis-cfg-42.txt draft-ietf-httpbis-http2-tls13-03.txt draft-ietf-pce-lsp-control-request-11.txt draft-ietf-cbor-array-tags-08.txt draft-ietf-pce-stateful-path-protection-11.txt draft-ietf-6man-segment-routing-header-26.txt draft-ietf-acme-star-11.txt draft-ietf-rmcat-cc-requirements-09.txt draft-ietf-lisp-introduction-13.txt draft-ietf-lwig-cellular-06.txt draft-ietf-rmcat-coupled-cc-09.txt draft-ietf-anima-prefix-management-07.txt draft-ietf-spring-segment-routing-central-epe-10.txt draft-ietf-mtgvenue-iaoc-venue-selection-process-16.txt draft-ietf-mtgvenue-meeting-policy-07.txt draft-ietf-taps-minset-11.txt draft-ietf-iasa2-trust-rationale-03.txt draft-ietf-iasa2-trust-update-03.txt draft-ietf-anima-reference-model-10.txt draft-ietf-spring-segment-routing-msdc-11.txt draft-ietf-httpbis-expect-ct-08.txt draft-ietf-hip-rfc4423-bis-20.txt draft-ietf-iasa2-consolidated-upd-07.txt draft-ietf-iasa2-rfc4071bis-11.txt draft-ietf-clue-datachannel-18.txt draft-ietf-sipbrandy-rtpsec-08.txt draft-ietf-rmcat-eval-test-10.txt draft-ietf-v6ops-nat64-deployment-08.txt draft-ietf-iasa2-rfc7437bis-09.txt draft-ietf-dmm-ondemand-mobility-18.txt draft-ietf-pce-inter-area-as-applicability-08.txt draft-ietf-rtgwg-enterprise-pa-multihoming-12.txt draft-ietf-tls-grease-04.txt draft-ietf-httpbis-rand-access-live-04.txt draft-ietf-iasa2-rfc2031bis-08.txt draft-ietf-opsec-urpf-improvements-04.txt draft-ietf-rmcat-nada-13.txt draft-ietf-iasa2-rfc5377bis-03.txt draft-ietf-iasa2-rfc7776bis-03.txt draft-ietf-curdle-rc4-die-die-die-17.txt draft-ietf-intarea-frag-fragile-17.txt draft-ietf-oauth-jwt-bcp-07.txt draft-ietf-pce-stateful-hpce-15.txt draft-iab-rfc7500-bis-00.txt draft-iab-fiftyyears-01.txt draft-ribose-asciirfc-08.txt draft-kanugovi-intarea-mams-framework-04.txt draft-jenkins-cnsa-cmc-profile-05.txt draft-trossen-sfc-name-based-sff-07.txt draft-aranda-dispatch-q4s-10.txt draft-sheffer-tls-pinning-ticket-12.txt draft-sekar-dns-llq-06.txt draft-nottingham-safe-hint-11.txt draft-ise-iana-policy-03.txt draft-bruckert-brainpool-for-tls13-07.txt